Write an android application What is the best way for me to go about writing a new Bitcoin wallet application? Is piggybacking off API's like blockchain.info or coinbase a good tactic? Would the application then be OK to distribute (are said services open source?). Are there alternatives? Can I run my own Bitcoin server and write my own API to go with it instead? What would the steps be involved in that? Would your average punter trust a (legitimate!) wallet that I create or would they feel safer using an app that is built upon a renowned service?

You can fork Bitcoin Wallet, an SPV implementation of the Bitcoin protocol:

https://github.com/schildbach/bitcoin-wallet

It's GPL licensed.


Ripple paper wallaet from Rippley (https://ripply.eu/) code check / safe? This question is about Ripple, but I hope it's still okay to ask this question on Bitcoin StackExchange:

I am eager to put my Ripple in a paper wallet, and from searching the web I found Rippley.eu (https://ripply.eu/).

I was wondering if anyone has done a code check of this website, and can verify that it's safe to use for generating paper wallets for Ripple storage?

Try http://www.ripplepaperwallet.com that should be safe.  If you can disconnect it from the internet and still generate an address in your browser while offline, then yes it is safe.


Whats are "non-final transactions"? Killerstorm mentioned "non-final transactions" as something Satoshi talked envisioned. Can anyone elaborate what this means?

Well, a very simple case is mentioned in "Providing a deposit" contract, but there are many other uses, and many contracts depend on such transactions.

I also provided a brief description in this comment:

  Transaction with nLockTime in future cannot get into blockchain before that time.

  Previously it was the case that it was stored in memory pool, but now they can't even get into mempool. And it is OK, actually.
  Basically, nLockTime gives you an ability to back off after some delay, and that delay penalizes abuse or gives some time for negotiations.

  For example, suppose there is a service provider and a customer. They do not trust each other very much, so they will put money into 2-signature transaction, with nLockTime'd rollback in future. If customer is satisfied with service, he will release money to service provider. If service provider agrees that he screwed it up, he will release money back to customer. However, if they disagree (e.g. service provider think he did great job but customer thinks it's shit), money can be released by nLockTime'd transaction, say, year from now. In that case customer suffers because he cannot use money for a year, but service provider doesn't get money for shitty job he have done.

But, well, a complete answer will be a rather lengthy article...


Is there any reason to invest on GPU based system these days? (March 2013) I wonder whether I should spend around 1000$ - 1500$ for buying a GPU based system that will mine at 2GH/s. Is it still worth it? What will happen when all those ASIC machines will arrive? will i still be mining at a decent rate?

Thanks.

As of today (April 6, 2013) mining profitability on GPUs is at the highest levels ever, but that is only because the exchange rate has rocketed up so fast.

http://blockchain.info/charts/miners-operating-profit-margin

At the same time, mining difficulty has been skyrocketing and that pace of growth will likely outpace the increase in the exchange rate.

http://bitcoin.sipa.be/speed-lin-10k.png

But there are probably two or three difficulty adjustment cycles remaining where mining bitcoins using GPUs is still profitable.   Enjoy it while it lasts because in a little over a month it should be all over for GPUs.   The expected rate of difficulty increase was not unexpected so further investment in GPU mining has been discouraged however the rise in the BTC/USD from the low teens to 10X that level has caused that call to be simply premature by a few months.


History behind the scripting language in Bitcoin? What is the history of the current existing scripting language in Bitcoin?

Satoshi's original whitepaper on Bitcoin makes no mention of a stack based scripting language. So who was the first person to propose this idea and implement it? And why did they decide to choose a stack based language?

Script was in the first version of Bitcoin. Satoshi developed Bitcoin in private before releasing the fully-usable Bitcoin 0.1, and he said very little about his thought-process, so we'll probably never know exactly why many things were done the way they were.

Script had several serious bugs when Bitcoin was first released, and some bugs still exist. It's clear that Satoshi didn't thoroughly test Script before releasing Bitcoin.  And while it contains a lot of complexity, it is still too incomplete for most opcodes to be of any real use. In light of this, it's often speculated that Script was something of an afterthought. Perhaps Satoshi's design originally sent bitcoins only directly to public keys, but when adding support for Bitcoin addresses and thinking about future transaction types, he realized that a scripting language would be useful for forward-compatibility.

A stack-based language is the natural choice here. Script processing is dead simple and very fast: just keep reading opcodes from the script and evaluating them until the script is complete. Each opcode is pretty much self-contained. It's also easy to analyze scripts due to the fact that everything to the right of a certain point in a script can be considered a function. You can know for sure that any scriptPubKey that starts with OP_RETURN will always fail validation, and that any script which ends with <pubKey> OP_CHECKSIG will always require the signature of that public key, regardless of what the rest of the script contains.

This functional aspect of Script was especially important when scripts were still evaluated by directly concatenating the scriptSig and scriptPubKey instead of evaluating them separately as is done today. In theory, you could put anything in the scriptPubKey and be sure that no matter what was in the scriptSig, your scriptPubKey would behave as a function taking an appropriate number of arguments from the stack. However, the opcode OP_RETURN originally just caused the script to end early instead of fail, so you could steal anyone's bitcoins by simply using the scriptSig OP_TRUE OP_RETURN. It was also possible to put a pushdata opcode right at the end of a scriptSig to turn the entire scriptPubKey into a constant (which evaluates to true). Satoshi fixed these bugs by changing the behavior of OP_RETURN to cause the transaction to immediately fail and making it so that scriptSig and scriptPubKey are evaluated in two separate steps.


What happens with the transactions a miner didn't include in a block? Let's say a miner pulls from the node the available transactions to be included in the next block. He receives transactions A, B and C. For whatever reason he discards transaction B and so he mines a block that includes only A and C. Meantime, before the miner pushes the new block, the node has received a new transaction D.

What happens with the transactions B and D? I suppose the node verifies which transactions were not included in the mined block and keeps them available for the next block, is that correct?

Transactions A,B,C will be validated and added to the miners memory pool just like any other node does. If A and B are the only ones added to the next block then c will remain in the memory pool and will later be joined by D. So C and D will remain in the memory pool until they are added to a new block while A and B will form part of the new block. If the miner is successful in solving the proof of work then his block will be propagated to other nodes and if it is accepted it will added to a chain. When the miner receives a new block from the network, then the software does check if the new block has transactions that are in its memory pool and will remove any transactions from the memory pool if it is in the new block.


Using Bitcoin for Bond Certificates I have a product that is in development and I want to allow people to buy something like bonds to raise money for the project. I was thinking to develop my own protocol for defining these bond certificates but first I want to check if Bitcoin provides something for it.

Some of the requirements are:

Bonds are sold sequentially and have serial numbers. Each subsequent bond is a little bit (a fraction of a penny) more expensive than the previous bond sold.
Bonds have to be splitable just like share splits.
People should be able to buy anonymously and receive a bond certificate without providing an email, or any identifiable addresses.
Should be able to validate bond certificates with a public key.
At the bond's maturity time, the shareholder (bond owner) should be able to claim that they own in with a private key.

Are there any Bitcoin features to help with this?

Thanks!

OpenAssets and CounterParty are the most similar projects I can think of, but I'm sure it doesn't have all of the features you are looking for. You may also be interested in Overstock's Medici project.


How does Electrum make a keypair out of a seed? Electrum uses a seed of 12 words to generate a keypair and then hierarchically generates addresses out of that keypair.

I know how to generate hierarchic addresses from a keypair, but what I don't understand is how Electrum generates a keypair from the seed. I understand the seed consists of words coming from a 2048 length wordlist, but after that it is unclear to me how it starts to generate the sequence of addresses.

I'd like to do the HD generation in either Java / C++ / Python or C#.
If I can understand the process, I might be able to reproduce it myself and generate hierarchical addresses from a seed.

EDIT:

A day later I find this Java implementation... Thanks for the answers!

https://github.com/harningt/atomun-mnemonic

Wallets created by Electrum 1.x have seeds containing 12 words (24 words is also possible for custom-created seeds). Given a zero-based array of seed_words of that length, this pseudocode calculates the master_private_key:

i = 0
while i < length(seed_words):
    # convert each word into an int in the range [0,1625]
    # based on the word's position in the sorted word list
    seed_ints[i] = lookup_seed_word(seed_words[i])
    i = i + 1

num_words  = 1626
num_words2 = num_words * num_words
seed_hex_str = ""
i = 0
while i < length(seed_words):
    # (hex8 converts an int into an ASCII string of
    # exactly 8 zero-padded lowercase hex digits;
    # % is the integer remainder operator
    seed_hex_str = seed_hex_str + hex8( seed_ints[i    ]
                    + num_words  * (   (seed_ints[i + 1] - seed_ints[i    ]) % num_words )
                    + num_words2 * (   (seed_ints[i + 2] - seed_ints[i + 1]) % num_words ))
    i = i + 3

unstretched_seed = ascii_string_to_byte_array(seed_hex_str)
seed = byte_array()  # an empty byte array
i = 0
while i < 100000:
    # sha256 operates on and produces byte arrays
    seed = sha256(seed + unstretched_seed)
    i = i + 1

master_private_key = byte_array_to_int(seed, order=big_endian)

In case you're wondering, it seems that the reason the seed_ints calculation looks overly complex may be to avoid infringing on a patent.

For comparison, wallets created by Electrum 2.x typically have seeds containing 13 words, however they will on occasion have fewer. (It's technically possible to construct seeds of nearly any length which will be accepted when restoring an Electrum 2.x wallet.) Here's the pseudocode which calculates a BIP-32 extended master private key:

# Electrum 2.x doesn't separate mnemonic words with spaces in sentences for any CJK
# scripts when calculating the checksum or deriving a binary seed (even though this
# seems inappropriate for some CJK scripts such as Hiragana as used by the ja wordlist)
if language is CJK:
    space = ""
else:
    space = " "

seed_phrase = ""
i = 0
do:
    word = seed_words[i]
    normalize_unicode(word, normalization=nfkd)
    remove_unicode_combining_marks(word)  # e.g. accent marks
    seed_phrase = seed_phrase + word
    i = i + 1
    if i ≥ length(seed_words):
        exit-loop
    seed_phrase = seed_phrase + space

seed_utf8 = unicode_to_byte_array(seed_phrase, format=utf8)

if hmac_sha512(key="Seed version", message=seed_utf8)[0] ≠ 1:
    fail("invalid checksum")

stretched_seed = pbkdf2_hmac_sha512(password=seed_utf8, salt="electrum", iterations=2048, output_length=64)
seed_bytes = hmac_sha512(key="Bitcoin seed", message=stretched_seed)

private_key        = byte_array_to_int(seed_bytes[0..31], order=big_endian)
chain_code_bytes   = seed_bytes[32..63]
master_private_key = create_bip32_extended_private_key(private_key, chain_code_bytes)

BIP-39, an alternative derivation technique, is similar to Electrum 2.x but not identical.


How will the Lightning Network handle most money being pushed towards specific nodes? Are there simulations of scenarios taking into consideration that most payments in LN will go into specific nodes (say, Amazon or Ebay)? The majority of payments we make are not towards our friends, but towards big entities that sell stuff.

So the number of nodes making payments will always outweigh the nodes receiving them - this seems like the law of business if you ask me.

I'm not sure how the graph will behave when all the money is always pushed towards few nodes. Have simulations been done for these sort of scenarios?

EDIT

To clarify, my main concern is about how money would flow through hops if, like I said, we're mostly paying these big nodes in the graph. My concern is that a route may be harder to find if the typology of the network pushes all the money towards these specific areas of the graph -- we might end up with not many routing possibilities because most channels in a route might be exhausted in that direction.

Payment routing could handle this. Any business has operational costs and will have to make outgoing payments.

If your concern is that channels will mostly consist of payments in a single direction (i.e. from customers to larger businesses), and that this will lead to a high frequency of channel closings or on-chain settlements, then we can consider the theory of Six Degrees of Separation.

The theory of Six Degrees of Separation postulates "that all living things and everything else in the world are six or fewer steps away from each other". In regards to the Lightning Network, we can postulate the theory that any user will be able to pay any other user through approximately six other users.

So if you have a source of incoming payments on the Lightning network (i.e. your wage), and the larger business has outgoing payments (i.e. their employee's wages), then through the six degrees of separation you may be able to pay the larger business through already existing payment channels you have open with your contacts.

Successful payment routing should ensure that payment channels operate bidirectionally and that payment channel closing or on-chain settlement should be of a low relative frequency.

Edit: Put Alternatively

Customers may never directly make payment channels with large businesses, but instead create routed payments through payment channels they have open with exchanges or other Lightning Network intermediaries.

Users may create payment channels with an exchange. A large business may create a payment channel with the same exchange. Users make payments to the large business routed through the payment channels they have open with the exchange. The large business decides to sell some bitcoin through the exchange. It makes a payment using the payment channel it already has open with the exchange. This process continues indefinitely such that there is a bidirectional flow of bitcoin along the open payment channels.


Why block height is required in coinbase? While reading bitcoin source I found this short comment:

// Height first in coinbase required for block.version=2

(From https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L338).

Why this is required? Does it prevent some misuse or attack?

I found that this change was introduced in BIP-0034. In relevant pull request it is justified by following points:

  Putting the height in the coinbase is desired for at least two reasons:

  It guarantees that every subsequent block and transaction hash is unique.
  It can be used to better reason about plausible difficulty for not-yet-connected blocks.

But for me this explains nothing: I don't see how adding height guarantees unique block hashes and I don't understand what is "plausible difficulty for not-yet-connected blocks".

In his comment @amaclin pointed to BIP-30 which provides motivation for BIP-34.

I still don't understand what is "to better reason about plausible difficulty for not-yet-connected blocks" but it seems that the sole point of BIP-34 is to prevent intentional creation of duplicate coinbase transactions.

According BIP-30 they can be used in several attacks:

  Recently, an attack that exploits the reference implementation's dealing with duplicate transactions was described and demonstrated. It allows reverting fully-confirmed transactions to a single confirmation, making them vulnerable to become unspendable entirely. Another attack is possible that allows forking the block chain for a subset of the network.

This answer by Pieter Wuille explains blockchain forking in more detail.

Contrary to the explanation in BIP-34 pull request, adding block height to coinbase does not guarantee that every subsequent transaction hash is unique. It only makes harder to create transactions with same hash intentionally. There is still possibility that some unrelated transactions will clash.


How do I know I can trust the head of the blockchain I'm trying to understand how the mining process works. Specifically, my understanding is the local miner works on blocks and add them to their local blockchain if they succeed. It may turn out that this isn't the longest chain of blocks (because there are other miners working in parallel) and when that longest chain arrives at the miner, the miner will discard its local (shorter) subchain in favor of the new one.

My question is if the local node (who's also a miner) is asked for information from the block chain before that longest chain arrives, how would it know that these blocks may still change in the future and shouldn't necessarily be trusted?

I apologize if the whole question seems confused. It's only a reflection of my own confusion on the topic.

Your node doesn't know for sure. Actually, nobody ever knows for sure that the current chain-tip will be in the chain with the most work, it just becomes increasingly likely as more time passes and additional blocks build on-top.

Once a sufficient number of blocks have been built on top of the observed block, it will be sufficiently unlikely that the observed block will end up in a stale chain-tip, and you can trust it.

Users make different judgment calls about the number of blocks they wait for: some don't wait for another block and accept at first confirmation, some wait three blocks, some require six. The extreme is likely to be the 100 block waiting period the network requires before mining rewards may be spent.

However, until proven wrong, the node will assume that he has the newest information: after all finding a block is an unlikely event, and thus will respond with information about his block when queried for the blockchain-tip.


How does CoinJoin affect the total transaction size? As I understand it, CoinJoin is a method to aggregate multiple transactions into a single transaction, mostly for privacy purposes.

How does this aggregation affect the total size of the transactions? I believe it contains the same number of inputs and outputs, but I wonder if the total size decreases due to reducing some overhead.
How many transactions can be aggregated? I believe there is a cap on the transaction size, which will limit the total number of inputs and outputs.
For the maximal number of inputs/outputs, what will be the total size with and without CoinJoin?
Are there additional factors which might affect the CoinJoin transaction size?

Status Quo

The CoinJoin transaction only has a minimally reduced blockspace requirement in comparison to the unaggregated transactions:

Transaction sizes (example is P2PKH) can be calculated by the following formula:

 size = #inputs * 148 bytes + #outputs * 34 bytes + 10 bytes

By combining multiple transactions only the 10 bytes of the transaction overhead will be saved, the inputs and outputs will require the same amount of space as in the separate transactions before.

The transaction size is limited by the blocksize, however transactions bigger than 100kB are non-standard.

Outlook Schnorr Signatures

The latter will change with the planned introduction of Schnorr signatures and the subsequent possibility of signature aggregation. Schnorr signatures have the nice feature that multiple signatures can be combined into one.

Hence, more inputs on one transaction would reduce the blockspace requirement in the following fashion. Assuming the signature is about half of the input size (it's 72 bytes of 148 for P2PKH) you would get:

inputSizeTotal(n inputs) = 1 * inputSize + (n - 1) * ¹/₂ * inputSize

For n → ∞ you'd half the inputSizeTotal. ;)


bitcoin back-end blockchain storage bitcoin uses blockchain
so blockchain is peer to peer,
every peer stores the data

so I wonder where does the data of all the bitcoins is stored?
who is peer in case of bitcoin?
so that peer gets data related to bitcoins all over the world?

as the bitcoins grow isnt it becomes slower and slower to retrieve information?

Each non-pruning full node (peer) stores a complete copy of the blockchain - pruned nodes store a complete copy of the current state, but may not have all historical blocks available.

When a node validates a transaction or a block, it is only validating it against its local view of the blockchain - this means that looking up data is pretty fast, since all of it is available locally.

As the blockchain grows, access time for most data still remains mostly the same due to the nature of the key-value store used by bitcoind - look up times for a key value store are roughly constant, although data that is cached in memory can naturally be accessed faster.


When are you charged a withdraw fee? I'm a bitcoin newbie and think that I am missing something.  I'm based in Australia although I'm not sure if that matters.  I would like to buy and hold for an extended period some bitcoin and ether.  I would prefer not to use the exchange's wallet or storage.  Will I be charged a fee to withdrawl and use my own cold storage?

There isn't really a notion of "withdrawing" from cold storage.  Bitcoin isn't a bank and you don't make deposits and withdrawals.  You have some coins in an address, that's all, and you can spend them any time you like.  The only difference with cold storage is that you are storing your private key on a piece of paper / USB stick / offline computer / etc, so you will have to do a little more work to spend the coins.

Spending coins from cold storage just requires a transaction, and every transaction requires a transaction fee.  But this would be the same fee no matter whether you were keeping your keys in cold storage or in a web wallet or on your smartphone.

(You might find older resources suggesting that coins which have stayed in the same address for a long time can be spent without fee, due to the transactions being higher "priority".  This is not true anymore due to the current shortage of block space.)


What you're spending is a P2SH output. To spend those, the last element of the ScriptSig must be the script (encoded with a push opcode, not the script itself) that produces that P2SH address when hashed.

See BIP16, especially rule #1.

  Validation fails if there are any operations other than "push data" operations in the scriptSig


Is it possible to mine bitcoins faster on CPUs with this strategy? This guy on bitcointalk.org suggested a potentially faster method for mining bitcoins using CPUs: https://bitcointalk.org/index.php?topic=265759.0

To quote from the author:

"Rather than computationally solving for SHA256(SHA256(block_header)), the approach is to solve it symbolically.   What I mean by this is, rather than treating the block header input bits as 0 or 1, treat each input bit as an individual symbolic variable (640 in total).   Next, perform the double SHA256, and produce a set of equations that represents each bit in the final hash.  These will obviously be huge, but you can PolynomialReduce after each step of the hashing to reduce the equation size.

The SHA256 output is 32 bytes, so what you end up with is a system of 256 equations, consisting of 640 variables each (which include all the logical operators applied from the double hash.)  For the purposes of mining at difficulty 1, you can discard all but the first 32 equations.

Now to mine using this method:  You have to collapse the equations and simplify.   Take the current, real block_header in question, and fill in actual values in your 32 equations for every bit except for the 32-bit nonce (608 in total.)  Reduce.

Now you have a system of 32 equations, and 32 unknowns.   Set all 32 equations equal to one another, and solve the system of equations.

What you end up with are 3 possible solutions: A nonce that produces 32 "0" bits (what we want), a nonce that produces all "1" bits (discard) or no solution (increment extraNonce.)

Note to make reduction and solving the system of equations simpler, convert the logical operators (xor, or, and) into arithmetic operations and do the reduction and solving in the modulo 2 number ring, for example:

a^b == (a+b)%2
(a | b) == ( (a*b)%2 + a%2 + b%2 );
(a & b) == (a * b) % 2 "

Now, I'm not a math guy, but from what I can gather, this strategy takes up a lot of computing memory. Therefore, my question is - is this strategy theoretically feasible? Can it be as efficient as ASIC mining?

It's not clear what the strategy is. It just says "and solve the system of equations".

The entire structure of cryptographic hashes like SHA256 is carefully designed to make doing this as difficult as possible, and there's not even a hint of how to solve that system of equations.

This is precisely what ordinary miners do, except they try to solve the system of equations by guessing possible solutions and seeing if they solve the equations. If there is a simpler way to solve them, what is it?


The elliptic curve is secp256k1: y2 = x3 + 7 (mod p)
where the field size is
p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F.
The curve order of secp256k1 is:
n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
The public key P (point) is calculated by multiplying the private key d (scalar) by the generator point G (point) where
P = d (mod n).G
The n (N) you state is not the field size p, it is the curve order
n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
This curve order n is such that nG = point at infinity. This is a property of the curve and cannot be changed.
Thanks to Pieter Wuille for the corrections.


I've read that bitcoin addresses are never destroyed, but do they get recycled/reassigned? What happens to old bitcoin addresses? I've read that they never get destroyed, but do they get reassigned?
The story is I sent some bitcoin to an exchange using an address I've used with them before, but then found out that they had just retired/stopped using that address. I saw the transaction coming through though. Where did the bitcoin go?? Is there an official network that manages bitcoin addresses? Please help, it is a rather large sum.
Address in question:
12aAEnfc6192cm4KLfV5eY13jYRqy684Ym
transaction ID:
0db1e2f9f4233592b5f6ac5c881727e3c5694cfbd21af1744bfb11d069a1ae2d

What happens to old bitcoin addresses? I've read that they never get destroyed, but do they get reassigned?

Bitcoin addresses are not reused or reassigned to anybody under any circumstances.

The story is I sent some bitcoin to an exchange using an address I've used with them before, but then found out that they had just retired/stopped using that address.

This is almost certainly a scam. There is no reason to ever "stop using" an address, especially as the one you're referencing contains over half a million dollars of value. If they had lost access to their own funds that's not really your responsibility, but that seems like a highly unlikely story.

Is there an official network that manages bitcoin addresses?

No.


Can an invalid Omni transaction be confirmed by bitcoin miners? Is it possible that a well formed Omni transaction (with valid Omni layer data) be valid for Bitcoin miners while being invalid for the Omni token being used ?

Yes, Bitcoin miners don't perform any validation beyond the Bitcoin validity rules. Omni transactions rely on OP_RETURN values, which don't matter to the Bitcoin miners.

As long as a tx is a valid Bitcoin tx, miners are free to include it in their blocks.

When an omni node sees such an invalid transaction, it will simply ignore any asset movements the tx claims to perform.


Can I lower fees with stratagy Say I have two accounts in my wallet. Account A has one address, account B though has 5 address. Each address in account B has a dust amount of coin in it. If I were to use the rpc 'move' command, moving each piece of dust from the respective address in account B over to one lump in account A

  Accounts, exist only within the Bitcoin Core client. They are just a bookkeeping device to group your funds. You can move coins between accounts with the move command in the Bitcoin Core console. This updates the client's internal records to adjust the balances of those accounts, but doesn't actually cause any coins to move between addresses, so it has no fee.

How is that valid, as account A would have the one primary address? Does this mean that I am sending to another account owned by me so the coin dust is landing in the account ignoring the primary address?

And say for example I then used the lump in account A to buy some new boots. Wouldn't that make the next fee that account A would pay higher as it was made from a collection of dust(s)?

Would I have to wait a considerable amount of time to lower the fee? Is there another strategy I could use to bring the fee down? Like importing an external key from an compressed pubkey from another wallet (C), paying to to C from A. I don't yet fully understand public keys and compression but as I understand sending to them is considerably cheaper (something to do with inputs?.. not too sure what exactly those are)

I feel sort of like I am understanding more, can someone please clarify a little and/or correct me?

Edit-1

What if I wait a while then as Tim S suggests... Account B has 5 addresses, lets look at one of them (an address with piece of dust in it). Lets say that some more dust payments were sent to that address making the 'dust pile' grow.

At what point is it not dusty?
Are there still too many inputs?

(Am I confused by the term 'inputs': "inputs from many addresses in your wallet" or "inputs from many payments to the one address")

Say I waited 3 days after all the dust came in and settled until it gained priority, then sent the whole dust pile (from that account B address only) to another address. Would it be more worth sending / have I made the situation better?

Regardless of what accounts they are in in your wallet, consolidating/spending your dust may require substantial transaction fees - maybe even exceeding the value of the dust. The major factor that comes into play is the size added to a transaction by each additional input. You can read a lot of info on the Bitcoin wiki about transaction fees.

Here are some strategies for reducing/eliminating the fees:

Include some dust in a free transaction. How much you'll be able to include without lowering your priority below the minimum for a free transaction depends on the coin-age you're spending in the transaction (large, old balance = high priority).
Include some dust in a paid transaction. The 0.0001 BTC per thousand bytes means that if you have a transaction that's only, say, 250 bytes you can add up to 750 bytes of extra data (in this case, dust inputs) for no additional cost.
Transmit your transactions directly to a free transaction relay/low-fee pool. For example, Eligius only requires 0.1 TBC (0.00004096 BTC) per 512 bytes.
Wait it out. If the value of a bitcoin rises substantially, the transaction fee limits will likely be lowered to account for that, so your dust will not be so dusty-looking.

If these all sound like a bit of a pain, that's because Bitcoin isn't really designed for micro-transactions, and much is in place to discourage spamming in the form of "dust".


Set lower limit to incoming new channels in LND For now, any remote node can open a channel to my LND node and my node will always happily accept the channel.

However, I've seen in the past that other nodes would have limits in what channel sizes they accept. E.G. a node might not accept any channel that's smaller than 2'000'000 sats.

How can I setup my node to behave in a similar way?

If you look at lnd.conf (or in particular at the sample-lnd.conf line 138) you will see the following:

; The smallest channel size (in satoshis) that we should accept. Incoming
; channels smaller than this will be rejected, default value 20000.
; minchansize=

which means if you remove the ; and set a value in satoshis your node will reject smaller channels.

After changing lnd.conf you have to restart your node and then it should behave in the way you want


Using Bitcoin or another Altcoin for Decentralized Database Storage I was wondering has there been any attempts on using the blockchain as a decentralized database storage system? Would it be feasible to use it on Bitcoin or another Altcoin and if so which altcoin would suit it best? I would imagine Bitcoin would have the most redundancy as it has the most nodes.

Say for example I have my CMS and I wanted to store my user records in a blockchain. Or is there another practical example when using blockchain for storing database records?

Yes there have been some proposed ideas such as FileCoin, Storj and probably others. However, I'm not sure how well these systems work because there would need to be a way to prove to other peers that you actually are serving the piece of data. Some call it proof-of-storage, others proof-of-retrievability. But it's still an open problem that nobody seems to have solved yet. I mean, this is probably why both projects I mentioned above aren't ready yet.

From a technical point of view the idea of a P2P storage system is that if you upload a piece of content on this cloud, you'd expect it to be there all the time. That's the whole point of a cloud; you upload it, and can download it from anywhere in the world at any time. I'm not sure that P2P is a good solution to this issue. A client-server model, from an entity that you trust and pay directly which has reputation (say Dropbox), is probably a better mechanism of doing this.

In a P2P system, all the nodes that were holding your data could simply go offline for no particular reason and your data would be unreachable. Furthermore, even if the nodes were incentivized to keep sharing your data (perhaps being compensated through some form of cryptocurrency), there's still no way to figure out how the incentive would work exactly. For example, how would you stop yourself from serving your own data using another computer, and therefore getting all the crypto yourself?

It's a very interesting problem and I think we're slowly getting there, but we really need to get the incentives right, and it's a really hard problem in a P2P system. But hey, there's hope, just look at Bitcoin!


Importing private keys creates different address How does importing private keys work?

I have previously imported the private key for a 1Archive... address into Bitcoin Core and noted then it added an address like 1AXbRq...  and I didn't follow it up further.

Today I have exported the private key for a 3... address from Bitcoin Core and imported it in Electrum. Electrum adds a 1... address and doesn't see any of the transactions.

How does this work? I understand that there is an underlying 1... address behind a SegWit address but how would I spend any BTC if it is not showing in my wallet balance? What else should I do?

If there is an answered question for this already on Bitcoin.SE I could not find it.

My private key begins with L.

Prepend "p2wpkh-p2sh:" to the private key before importing it into Electrum. For example:

p2wpkh-p2sh:5Kkzs8XrJNAmf9VQDFeGBfaRvSByAvPK6DbDXw5BVqswWaXSG2Y


Can someone explain this weird mining activity? I can't figure why this block has 0 coinbase with 0 transactions... however still a valid block? Or it it empty? According to whalepanda this coinbase was sacrificed by unknown miner.

See the block at height
    501,726

It has no transactions other than the coinbase transaction. However, the transaction's coinbase output is 0 BTC. Here's the valuable piece of information that you are looking for:

  Coinbase outputs may be set lower than the max. value (12.5 currently), and the block will be valid (if the difficulty is lower than the target, as always)

Also look at: https://btc.com/0000000000004c78956f8643262f3622acf22486b120421f893c0553702ba7b5

BTW, the miner loses money, for the price of being "cool".


What do the different .dat files contain? What data do different Bitcoin .dat files contain? How about the other files in the same folder?

The wallet.dat file is somewhat documented and there are some ways to convert it to human-readable form, but I don't think the same can be said about the other files. What data do they store and how is it encoded?

wallet.dat, addr.dat and blkindex.dat are Berkeley Database files. They can be read using standard tools, but aren't human readable by themselves. blk0001.dat (and additional blk000n.dat blocks) contain the blockchain itself, that's just a binary concatenation of the blocks.

wallet.dat contains your private keys, your address book, a copy of the transactions that send coins from or to one of your addresses, accounts, reserve keys, personal settings, and a pointer to the current best block.
addr.dat contains IP addresses of peers, both those you've connected to yourself or those you've only heard about. It has been replaced by peers.dat since 0.7.0
peers.dat contains the same information as addr.dat, but using an efficient custom format.
blkindex.dat contains an index of the blocks and transactions that can be found in all the blk000n.dat files.

I don't know about any standalone tools that convert addr.dat and blkindex.dat to human-readable form, although blockexplorer.com can be used to inspect the blockchain, and addr.dat just contains IP addresses.

Update: the data above is only valid before v0.8.0. As of v0.8.0, a new database structure (with associated filesystem layout) is used for blocks and indexes.


What to do when funded channel node disappears I would like to test this scenario on a testnet.

I funded a channel with one testnet node.

Assume that node suddenly vanishes and doesn't come back up for, say, another 4 weeks, or never.

What is supposed to happen? How am I supposed to detect and react to this?

Generally your lightning node will be able to tell which peers are online (in clightning with listpeers command)

If the other node is offline you can force close the channel by publishing your channel state.. Since the other node has signed your commitment tx as part of the protocol there is no need for it to be online or to help closing the channel.


how large a block can grow? I was looking for a blockchain exchange but I didn't see so I am posting this in Bitcoin group. Apologize if it's too naïve.
I've started to learn about bitcoin and blockchains. I don't understand how the whole network transactions can be assembled into blocks and then all these blocks validated and broadcast. Is that efficient? It's basically a block that grows in size every second. How this large data is going to be processed, stored and broadcasted efficiently? I am sure I'm missing something as this is obvious.

A blockchain is composed of many blocks. The bitcoin blockchain has 660,000+ blocks currently. Bitcoin blocks are limited by the Bitcoin rules to be at most 4KWU (kilo weight units). This is equivalent to 1MB of data per block, however, thanks to the Segwit upgrade, additional information can be stored in each block, making the maximum possible data per block be 4MB. The average block contains ~1.3MB of data.
The blockchain itself keeps growing as more and more blocks are added to it, so yes, storage requirements are rising 1.3MB / 10 minutes. Currently, a computer which stores the entire blockchain (all blocks) plus extra metadata and other indexes, takes up around 330GB - 400 GB.


What was the vulnerability in v0.3.4 that allowed an attacker to steal coins? Reference: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5141

What was the specific exploit in the Tx script evaluation process?

Explanation by Mike Hearn:
https://bitcointalk.org/index.php?topic=152470.msg1620493#msg1620493

  When Bitcoin was first released, it contained two completely fatal
  bugs that made the entire system worthless. Fortunately, they were
  found and fixed before Bitcoin  actually had any serious value.

  The first bug was that scripts were concatenated before being run
  instead of just using a shared stack. This meant that anyone could
  write a scriptSig that always evaluated to true and claim anyone elses
  coins. Fixed here in v0.3.2:

  https://github.com/bitcoin/bitcoin/commit/73aa262647ff9948eaf95e83236ec323347e95d0

...

  Needless to say, if somebody when this version was first released
  actually wrote such a scriptSig and stole some coins, that would have
  caused a chain split between old and new versions. Nobody did because,
  why bother? I'm not even sure Mt Gox existed back then, iirc that came
  some months later. Many script opcodes were disabled around this time
  (which is also a hard-forking change).


Will this Transaction still arrive or was it stolen? Was this Transaction stolen or did i make a mistake? ae6f689cb77a5eceea9eed5a91ce51f940fef2b8832946e747d0d0d788c3d9b3

The transaction ae6f689cb77a5eceea9eed5a91ce51f940fef2b8832946e747d0d0d788c3d9b3 was confirmed in block 594768, paying a total of 0.00520707 BTC to the bitcoin address 37wefhkU2JDzQWJpmkTAB73AiQxBRXFQe.

This transaction is confirmed, and at this point has several days worth of blocks on top of it, so it can definitely be considered immutable at this point.

If someone asked you to pay some BTC to this address, and now is pretending that it "didn't arrive", "was stolen", "can't be accessed without some payment", etc, then you should be extremely wary of dealing with that individual in the future. This 37wefhkU2JDzQWJpmkTAB73AiQxBRXFQe address did receive payment, it is not possible that it was "stolen before being delivered" or something like that.


What is the Big-O complexity to retrieve the balance for a user? Here is the Q/A related to: How is a wallet's balance computed?.

Based on this:

[Q] What is the Big-O complexity to retrieve the balance for a user?

Is it O(n), so basically do I have to iterate all utxoset to find matching outputs which correspond to public keys that it has the private key for ("your keys")? or is there any hash machanism that returns all outputs when I just provide my public-key?

Thank you for your valuable time and help.

It depends on what data structure you have put the UTXO set into. Different implementations do this in different ways, there is no one way to have the UTXO set.

For instance, one implementation may not maintain a UTXO set but rather iterates through the entire blockchain. This would be O(n) where n is the number of TXOs in the blockchain.

Other implementations may have the UTXO set in a list, so finding a balance would still be O(n) where n is the number of UTXOs because it has to iterate through the list.

An implementation could also make a map keyed on the scriptPubKey. The value would be a list of corresponding outputs (i.e. the amount and location). Then finding the balance of an address would be O(1+k) where k is the number of UTXOs for that address. This is significantly less than O(n) since looking up which UTXOs is O(1), but you still have to iterate through all of them.

So the time complexity of this really depends on the implementation, there is no one way to do it that all software use. In most implementations though, it is probably going to be O(n).


How to make a payment processor like Bitpay? There are some payment processors such as BIPS, BitPagos, BTCMerch, and a few more like them.

In detail, what do I require to get a website like that going?

Can you clarify whether you just need the ability to handle bitcoin-only transactions, or does your service need to be able to trade fiat currencies such as USD or EURO for bitcoins? If so, then you will need to invest in lawyers and find yourself a bank that is willing to extend you a loan, or supply your own funds to get it up and running.

If you're only needing to deal with bitcoins transactions, then I would suggest you learn about how blocks and transactions work at a low level. This is a good site for learning the nitty-gritty of how the blockchain stores data

http://codesuppository.blogspot.com/2014/01/how-to-parse-bitcoin-blockchain.html

Beyond that, understand how to set up a bitcoind server, and send JSON-RPC commands to it using the API explain here

https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

Once you know how these commands work, you'll be able to build software that will accept payments. Again, if you need to get fiat currencies involved that's you'll have to deal with legal/regulatory concerns, but it is possible.


What clients use version number "2" and version number "1" in their block headers? Is Bitcoin Core the only protocol that uses these version numbers?

Does anyone know what ABC and Unlimited use?

Is there a place where I can see the raw version numbers for each client easily?

Bitcoin clients no longer use version 2 or version 1 in the block headers. Block version is now defined as per BIP-9, and miners use specific bits in the block version number to signal their support for specific soft-forks in the bitcoin protocol. The top 3 bits of the blocks must be 001, so the range of actually possible nVersion values is from 0x20000000 to 0x3FFFFFFF, both inclusive.


How is transaction fee calculated? Some says that transaction fee is calculated based on the size of transactions.

In short, does it mean based on the number of utxos? To be precise, does it mean depending on the size of all of input scripts and output scripts? I know senders can set the fee as they like. But usually bitcoin users don't do that, just use wallet app, so this question is about general cases.

e.g. transaction (A) fee is cheaper than (B) because of the I/O scripts size.

(A) https://blockchain.info/ja/tx/6687d3e1c48901f6571ea70e2a94175af993fd934d51b82b5eb20a93d2dd98cf

(B) https://blockchain.info/en/tx/31b36d45323a8dd4b33832c561c8e5d8703c324ee5850924f20373222e80b529

My question is whether another factor affects the price of the fee or not.

Transactions compete with each other in regard to the fee they offer to the miner divided by the amount of blockspace they require to be included in a block.

Where does the fee come from?

When you craft a transaction, you first determine the amount that you want to send. After creating the sending outputs, you collect inputs that have sufficient value to pay for the sending outputs as well as that. Your software then crafts a payment order (transaction) that lists the inputs to be consumed authenticated by the corresponding signatures, as well as the outputs to be created. If the inputs total value exceeds what you wanted to send, you will often create an additional change output to send back the remainder to an address that you control.
 Obviously, you may not create outputs worth more than the inputs that you spend, but the opposite is required: The difference between the sum of the inputs and the sum of the outputs, i.e. the value that you have not reassigned to a recipient, is free-floating and may be collected by the miners in the coinbase transaction of the confirming block.

How big is a transaction?

The amount of blockspace required, is dependent on the type of script that you use in your input. e.g.:

a P2PKH input has 147 or 148 bytes
a P2SH 2 of 3 multisignature input has 295 bytes
variable for custom P2SH scripts

As far as I know, all outputs right now are 34 bytes.

To calculate the whole transaction size, you add up the transaction header (10 bytes), the inputs with their corresponding size (n*148 bytes for P2PKH), and the outputs (m*34 bytes).

Fee Rate

The fee rate is now the amount of freefloating fee in satoshis per the size of the transaction in bytes:

feeRate [sat/byte] = fee [sat] / txsize [byte]

Miners will generally select transactions by order of highest fee rate first.


How to do paper backup and restore for bitcoin core Since bitcoin core is HD wallet, it should be possible to make "seed" like backup for it and there should be way to restore the wallet from it as well. I know there is dumpprivkey, but it needs to be done after every transaction to be safe. Other wallets have nice seed backup and restore methods, I suppose core should have one as well.

There is xprv method mentioned in comments, but I'm still missing restore method. Also I would like to do it from console only, since my wallet is on remote server without graphics.

I'm interested in "string" backup mainly because I want to store it in trezor hardware password manager, which does not support files

Bitcoin Core does not allow you to restore from a given seed or master private key (xprv). There is currently no mechanism for importing seeds or master private keys and no mechanism for exporting seeds (and a convoluted workaround for exporting master private keys).

Note that you can import individual private keys, not just seeds, mnemonics, or master private keys. These can be imported with importmulti or importprivkey and can be exported with dumpprivkey.


How to move bitcoins from an exchange into my wallet? Completely new to this. Bought some Bitcoins from Bitcoin.de and received confirmation that the trade has been completed and they show me my balance.

Downloaded a wallet from Bitcoin-QT. That's fine. Now, how do I get the Bitcoins I've bought into the wallet I've downloaded? And how do I then use them to buy something online?

First thing, encrypt the wallet with a good passphrase.

You will want to go to the receive tab in Bitcoin-QT,  and create a new receiving address for yourself. You may want to create a new address for every transaction for anonymity purposes. Copy the address to your clipboard and then go to bitcoin.de, and send the coins from your account to that address.  It may take an hour or so for the transaction to complete so just leave the client running and be patient.

HINT: Be sure that bitcoin-qt is finished syncing with the blockchain before you send yourself the coins or you may not be able to accesss your coins  for the 24-48+ hours this process can initially take!  If you need it faster, might want to temporarily use either electrum or blockchain.info wallet until the client is completely synced.


Coinbase denies transaction: Please complete verifications to send money I use coinbase to transfer BTC for few monthes.

Everything used to be ok up to today.

I suddenly got message "Please complete verifications to send money".
I did not ever get this message before. Googling gives nothing.
My phone number is verified and nothing in the settings page explains what exactly is the problem.

Please, share your thoughts - what could this be and what should I do?

P.S.

Of course I wrote to support, but no response yet...

I finally got assistance from the support agent David. He has explained the situation in details and helped me to solve the problem.

To pass verifications, I needed to confirm email & phone on this page

https://www.coinbase.com/verifications

Then I uploaded my ID photo on this page:

https://www.coinbase.com/verifications/documents/new

After that I have filled the following form with correct address & credentials:

https://www.coinbase.com/settings/personal_details

After that I was finally able to send the BTC.

Thanks for patiance a assistance, David!


Custom receive payments method? So it's a known problem that blockchain.info's api only allows a gap of 20 unpaid addresses, which sucks and makes their api almost completely worthless. But I was thinking how could I make my own receive payments method with their other not so restricting API's. and I came up with this Idea but I'm not sure if it'll work and I need someone who has expierance with their api to tell if it will.
so here's my idea:

First I create a new address for when a user creates an account
I save the new deposit address to the users database entry
when the user views the deposit address the user is able to press a refresh    button to check if the transaction is arrived with the needed confirmations.
or the client sends a request to the server every 10mins to see if the transaction was sent and confirmed.
if it arrived we create a new address and save this as the new deposit address and add the amount sent to the balance.
the loop continues without any gap problems!

will this work or am I missing something. thank you.

Why not just use Electrum instead? It's easy enough to integrate with an Electrum wallet, and it has a customisable lookup gap that can be as big as you need it to be.


Android BTC clients that remotely use my Bitcoin Core wallet? Are there any Android BTC clients that remotely use my Bitcoin Core wallet so I don't have to use another wallet specific for my phone? I am running my own BTC node.

No. Something like that would be problematic security wise because it means you have to open up your computer running Bitcoin Core to the rest of the internet. Having two seperate wallets is not really much of an inconvenience because it is easy to send bitcoins between them.


who actually amasses or builds the blocks ... and how do they get passed to miners? The question is not about the block being included on the block chain, but
who actually creates a block? Like what is the process here.
Can someone walk me through this? I do know that blocks are summarized in form of a block header and contain a list of transactions.

Who selects the transactions to go into this block? If not a person, where in the Core is this included
How do they then get bundled as a block?
How do they get passed on then to the miners?

Who selects the transactions to go into this block? If not a person, where in the Core is this included

Miner select them. More specifically, node software that miners run select the transactions. Most miners use Bitcoin Core or some variation of it.

  How do they then get bundled as a block?
  How do they get passed on then to the miners?

When the node software selects transactions, it creates a hexadecimal string for each transaction that represents each of the fields. That hex string follows the same format used for serializing transactions for sending over the network, just as the hex representation of the bytes instead of the bytes themselves. This is then packaged together with some other information into a JSON object in the getblocktemplate format and provided over a JSON-RPC interface to mining software.

The mining software then takes the information provided by getblocktemplate, adds their own additional information (e.g. the nonce) and constructs a serialized block. Serialized blocks are byte arrays containing all of the information in a block and are the same format as sent over the network. If the block is valid, the miner sends the serialized block back to the node which then sends it to the rest of the Bitcoin network.

Here is a step by step example of how a miner Alice mines a block.

Alice runs Bitcoin Core which constantly receives, validates, and relays transactions and other blocks.
Alice runs a mining software (such as cgminer) and connects here hashing machines (e.g. an Antminer S9) to that.
Alice also provides to her instance of cgminer the credentials to the JSON-RPC interface for her Bitcoin Core node.
cgminer will use getblocktemplate and send a request for a block template to Bitcoin Core.
Bitcoin Core receives the getblocktemplate request and chooses transactions from its pool of valid and unconfirmed transactions that it has stored in memory. The transactions are typically selected by their fee rates, highest fee rate being selected first.
Bitcoin Core constructs a block template using the selected transactions and adds any additional information required.
Bitcoin Core responds back to cgminer over the JSON-RPC interface with the completed block template.
cgminer receives the block template and uses it to construct a serialized block header in a form that is acceptable to the hashing hardware
cgminer sends whatever data it has serialized to the hashing hardware and the  hardware computes SHA256 hashes on it while incrementing some data in the data.
The hashing hardware (or cgminer) checks whether a hash has a valid proof of work. If it does, skip to step 14.
Once the hardware exhausts all possible combinations it can try using the data given and responds back to cgminer
cgminer, when the hashing hardware can no longer continue with its data, sends another getblocktemplate request to Bitcoin Core for a new set of transactions and block data to try.
Repeat steps 4 through 12 until the hashing hardware finds a hash with a valid proof of work in setp 10.
Once a hash with a valid proof of work has been found, cgminer takes the data that was hashed for that valid proof of work and combines it with the serialized transactions.
The serialized block is converted into a hexadecimal string and sent to Bitcoin Core using the submitblock RPC command.
Bitcoin Core takes the hexadecimal string representing the block, converts it into a byte array, checks that the block is valid, and if it is, sends the block to the nodes that it is connected to.


Can i create wallet services of bitcoin core wallet Is it possible to create wallet url services for bitcoin core wallet

Is it possible to create wallet url services for bitcoin core wallet

Yes it is possible.
It is possible because Bitcoin core has a Remote Procedure Call (RPC) interface usable with many different programming languages, including those popular for creating back-end web-services accessible from web-browsers.
The developer reference says:

The Bitcoin Core RPC service listens for HTTP POST requests on port 8332 in mainnet mode or 18332 in testnet or regtest mode. The port number can be changed by setting rpcport in bitcoin.conf. By default the RPC service binds to your server’s localhost loopback network interface so it’s not accessible from other servers. Authentication is implemented using HTTP basic authentication. RPC HTTP requests must include a Content-Type header set to text/plain and a Content-Length header set to the size of the request body.
The format of the request body and response data is based on version 1.0 of the JSON-RPC specification. Specifically, the HTTP POST data of a request must be a JSON object

Exactly how you would write new software to use this is a software-development/programming question. For example see How to communicate between Java and bitcoind?

URL services of wallet so that i can run in web

No, the API is RPC based. Maybe you are looking for something with a RESTful interface accessible from an ordinary web-browser or a ready-made custodial-wallet HTTP service - in that case I suggest searching using an Internet search engine of your choice.


Can Bitcoin software be used to create a private currency (single issuer) I understand Bitcoin software can be used for private currencies. Can it be used to create a private currency (the NewCurrency) where there is only one issuer of NewCurrency and any monies raised are invested. So that investments "belong" to the holders of the NewCurrency, and any returns on the investments benefit the holders of the NewCurrency (i.e. improve exchange rates against other currencies). Issuer of NewCurrency can quote the net asset value of the investments daily (like for open ended funds), which supports the value (i.e. exchange rate) of the NewCurrency?

Does Bitcoin software/infrastructure support implementation of this?

If I understand you correctly, the answer is yes. You could use a Bitcoin-like system simply to track the movement of 'shares' or 'units'. All the 'coins' could start out pre-mined, and the system's sole purpose could be to track the movement of those units.

However, there would be a lot of reasons why this would be a bad idea. The primary one is this: the Bitcoin system makes a lot of trade-offs to get the benefit of decentralization (nobody needs to trust anyone else at all ever). If you want to have one central authority anyway, you are trading off all those things for nothing.

Securing the block chain requires sufficient hashing power such that a malicious organization can't easily muster 51% of it. So to keep the system secure on a day-to-day basis, you'd need some way to fund that massive amount of computing power. It's hard to see what benefit you'd get back for that cost.

There are systems, even cryptographic ones with similar properties, that are more suitable for a centralized currency. The basic design change would be that instead of having a block chain, you'd simply have the central authority (or authorities) sign all transactions.

For example, if I had 50 units of this currency, I could request a signed and dated statement from the central authority saying that I had those coins and showing my public key. If I want to transfer 10 units to you, I make a signed statement saying so and get the central authority to sign it. You can now prove you have those 10 coins with that signed statement. I can prove I have 40 coins by showing the signed statements and the central authority can't argue I made a transaction I didn't make because I have to sign them. So you get the same security properties and don't need all the CPU power.


How to get balance history of a bitcoin address using BCOIN node Is there any way to get history balance of an address. Balance is unspent transaction outputs (UTXOs).
I am using BCOIN node.
Bcoin has given a API for /coin/address/:address but it is giving current balance as a result instead of history.

Looking at the docs, you're using the HTTP api incorrectly.

Try this in your terminal. Make sure to define or change the $url variable.

address0='RQKEexR9ZufYP6AKbwhzdv8iuiMFDh4sNZ';
address1='RHpAA3ZmmmWF6FW8qSfaEvh1jR1nUmVYnj';

curl $url/coin/address \
  -H 'Content-Type: application/json' \
  -X POST \
  --data '{ "addresses":[ "'$address0'", "'$address1'" ]}'


Script. OP_PICK/OP_ROLL OP_PICK should take the nth element from the back of the stack and take it on top:
for input
xn ... x2 x1 x0
gives
xn ... x2 x1 x0 xn

I have used it in some scripts, but I've noticed some strange behaviour.

For instance, using the tool in:
http://webbtc.com/script
an input script
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3
and an output script
19 OP_PICK
produces an error.
However 18 OP_PICK works. For 25 elements in the stack it should work in both cases.
The problem doesn't seem to be the number 19. If I add one input
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3
the scripts works fine.

I have tried looking at the source code, but in
https://github.com/bitcoin/bitcoin/blob/ce56f5621a94dcc2159ebe57e43da727eab18e6c/src/script/interpreter.cpp
around line 551 I find:

            case OP_OVER:
            {
                // (x1 x2 -- x1 x2 x1)
                if (stack.size() < 2)
                    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
                valtype vch = stacktop(-2);
                stack.push_back(vch);
            }
            break;

            case OP_PICK:
            case OP_ROLL:
            {
                // (xn ... x2 x1 x0 n - xn ... x2 x1 x0 xn)
                // (xn ... x2 x1 x0 n - ... x2 x1 x0 xn)
                if (stack.size() < 2)
                    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
                int n = CScriptNum(stacktop(-1), fRequireMinimal).getint();
                popstack(stack);

I'm not really sure how OP_PICK is implemented. Can anyone point me to the code for OP_PICK or explain the errors?

Here's that source code, annotated. Each annotation refers to the code after it.

This means that this part of the code handles both OP_PICK and OP_ROLL. This is because OP_PICK and OP_ROLL are very similar. The only difference is that PICK copies and ROLL moves.

            case OP_PICK:
            case OP_ROLL:
            {

These are two examples of the stack before and after. This is sometimes called a 'precondition' and a 'postcondition.'

This one documents OP_PICK.

Precondition: xn ... x2 x1 x0 n

Postcondition: xn ... x2 x1 x0 xn

                // (xn ... x2 x1 x0 n - xn ... x2 x1 x0 xn)

This one documents OP_ROLL.

Precondition: xn ... x2 x1 x0 n

Postcondition: ... x2 x1 x0 xn (Note the lack of xn at the beginning.

                // (xn ... x2 x1 x0 n - ... x2 x1 x0 xn)

You need to have at least two elements on the stack, or this operation makes no sense.

                if (stack.size() < 2)
                    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);

Copy (but do not remove) the top element on the stack. Interpret it as a number. Convert it to a 32-bit integer, so it's easier to work with.

                int n = CScriptNum(stacktop(-1), fRequireMinimal).getint();

Now remove the top element on the stack. (Which should be n, remember.)

                popstack(stack);

If n is negative, fail. If n is larger than the stack, fail. (This is where I think your script is having an error.)

                if (n < 0 || n >= (int)stack.size())
                    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);

Copy the value we're after. Remember, 1 2 3 0 OP_PICK should get the element just below n, 3. Also, stacktop(-1) refers to the top. So therefore, we need to invert n and subtract 1.

                valtype vch = stacktop(-n-1);

Remember, OP_ROLL deletes the element from where it was originally. This code is not executed for OP_PICK.

                if (opcode == OP_ROLL)
                    stack.erase(stack.end()-n-1);

Now add the element that we just got back on the top of the stack.

                stack.push_back(vch);

We're done handling this case.

            }
            break;

Does that help?


I accidentally sent bitcoins twice to the same address Accidentally, I have transfered BTC from my one wallet to another twice on the same address. First transaction was successful, but in the second case the BTC got deducted from one of my wallet but not credited into my other wallet.

Help how to get my bitcoins back?

It is not clear what exactly happened.

If you've made two subsequent transactions to the same address that should not be a problem. Addresses can be used more than once to receive money.
If you created two transactions that spend the same transaction outputs, there is no problem, because only one of them can confirm.
If your transaction simply didn't get confirmed yet, there is little to no problem: Transactions either have confirmed or have not. Since both wallets are your own, the money is still in your sending wallet until it is in your receiving wallet. If you wish to get help about fixing a stuck unconfirmed transaction please refer to: Why is my transaction not getting confirmed and what can I do about it?

If your question is not covered by these three scenarios, please edit your post to clarify what you're asking.


Installing bitcoind as a dependency on travis-ci I'm trying to install bitcoind as a dependency on travis-ci. Here is my .travis.yml file:

language: scala
scala:
  - 2.11.7

notifications:
  on_success: change
  on_failure: change

before_install:
  - sudo apt-add-repository ppa:bitcoin/bitcoin -y
  - sudo apt-get update -qq
  - sudo apt-get install bitcoind -y

apt_packages:
  - bitcoind

before_script:
  - mkdir -p /home/travis/.bitcoin && cp bitcoin.conf /home/travis/.bitcoin/bitcoin.conf
  - dpkg -L bitcoind
  - /usr/bin/bitcoind -regtest -daemon

script: "sbt clean coverage test"
after_success: "sbt coverageReport coveralls"

and here is a link to the build failure:

https://travis-ci.org/bitcoin-s/bitcoin-s-rpc-client/builds/236451398

notice that dpkg -L returns the following

$ dpkg -L bitcoind

/.

/usr

/usr/share

/usr/share/doc

/usr/share/doc/bitcoind

/usr/share/doc/bitcoind/examples

/usr/share/doc/bitcoind/examples/bitcoin.conf.gz

/usr/share/doc/bitcoind/copyright

/usr/share/doc/bitcoind/changelog.Debian.gz

/usr/share/lintian

/usr/share/lintian/overrides

/usr/share/lintian/overrides/bitcoind

/usr/share/man

/usr/share/man/man1

/usr/share/man/man1/bitcoin-cli.1.gz

/usr/share/man/man1/bitcoind.1.gz

/usr/share/man/man5

/usr/share/man/man5/bitcoin.conf.5.gz

0.00s$ /usr/bin/bitcoind -regtest -daemon

/home/travis/.travis/job_stages: line 54: /usr/bin/bitcoind: No such file or directory

There isn't anything installed in /bin/. Any suggestions?

Note: If I just specify bitcoind instead of /usr/bin/bitcoind I get the same problem

https://travis-ci.org/bitcoin-s/bitcoin-s-rpc-client/builds/236438191

Ubuntu Precise is no longer supported by the Bitcoin PPA team, as the listing showed the .deb package contains no binary. The package description says:

  Bitcoin dummy package - please upgrade to a newer distro for an
  up-to-date Bitcoin package.

  Due to change in Bitcoin Core 0.13.0, we can no longer reasonably ship
  Bitcoin Core for Ubuntu 12.04 LTS. You can either upgrade Ubuntu or
  download the statically-linked Bitcoin Core binaries from bitcoin.org

On the PPA mirror you can see that Trusty (14.04 LTS), Xenial (16.04 LTS), Yakkety (16.10) and Zesty (17.04) are all supported (they have reasonable file sizes). I'd recommend going with Xenial as that has LTS (Long Term Support).

The other option - as the description says - is downloading the binary from the official bitcoin site, unzipping it and using that instead. For the current version:

wget https://bitcoin.org/bin/bitcoin-core-0.14.2/bitcoin-0.14.2-x86_64-linux-gnu.tar.gz
cat bitcoin-0.14.2-x86_64-linux-gnu.tar.gz| gzip -d | tar -xv
./bitcoin-0.14.2/bin/bitcoind


No submitblock in altcoin? I'm trying to figure out how I'd submit a block in many alt-coins. I originally found this issue in bbqcoin but have since found it in many others. I have bbqcoin (and others) installed from gihub source on Ubuntu 12.04.4

root@ubuntu-hp:~# bbqcoind help
addmultisigaddress <nrequired> <'["key","key"]'> [account]
backupwallet <destination>
dumpprivkey <bbqcoinaddress>
encryptwallet <passphrase>
getaccount <bbqcoinaddress>
getaccountaddress <account>
getaddressesbyaccount <account>
getbalance [account] [minconf=1]
getblock <hash> [decompositions]
getblockcount
getblockhash <index>
getconnectioncount
getdifficulty
getgenerate
gethashespersec
getinfo
getmemorypool [data]
getmininginfo
getnetworkhashps [blocks]
getnewaddress [account]
getpeerinfo
getrawmempool
getreceivedbyaccount <account> [minconf=1]
getreceivedbyaddress <bbqcoinaddress> [minconf=1]
gettransaction <txid> [decompositions]
getwork [data]
getworkex [data, coinbase]
help [command]
importprivkey <bbqcoinprivkey> [label]
keypoolrefill
listaccounts [minconf=1]
listreceivedbyaccount [minconf=1] [includeempty=false]
listreceivedbyaddress [minconf=1] [includeempty=false]
listsinceblock [blockhash] [target-confirmations]
listtransactions [account] [count=10] [from=0]
move <fromaccount> <toaccount> <amount> [minconf=1] [comment]
sendfrom <fromaccount> <tobbqcoinaddress> <amount> [minconf=1] [comment] [comment-to]
sendmany <fromaccount> {address:amount,...} [minconf=1] [comment]
sendrawtx <hex string>
sendtoaddress <bbqcoinaddress> <amount> [comment] [comment-to]
setaccount <bbqcoinaddress> <account>
setgenerate <generate> [genproclimit]
setmininput <amount>
settxfee <amount>
signmessage <bbqcoinaddress> <message>
stop
validateaddress <bbqcoinaddress>
verifymessage <bbqcoinaddress> <signature> <message>

Best I can figure, the closest thing would be sendrawtx.. but that can't be right, can it? I'm thinking at this point I should have taken advantage of the checkout feature, but it's hard to tell what version each coin is on.

Edit: I've found that many coins have this issue as described here: https://github.com/Crypto-Expert/stratum-mining/issues/72

So looks like the solution is to build it yourself, there is a hail-mary workaround which might do the trick but is heavily undocumented. I found reference that you can submit a block through getblocktemplate, https://github.com/moopless/stratum-mining-litecoin/issues/48

When trying with some data I go a json parse error.. has anyone used getblocktemplate submit?

Ok, took some doing but I figured it out!

It seems there a lot of which do not have submitblock in the source. Whether this is intended (mining advantages vs noobs) or just pure incompetence is not sure, but the solution requires minimal changes to the source.

I found this which should help if you're having this issue: https://github.com/earthcoinproject/earthcoin/commit/0b862e499e05386e333563656f84e99bad1b0290

Hope this helps another frustrated developer :)


Why is the data format for block height in coinbase scriptSigs inconsistent for heights 1-16? BIP-34 claims that in coinbase transactions, the scriptSig should contain the block height. It says the format of this is "serialized CScript", i.e. a byte indicating the length of the number (n), and then n bytes in little-endian format.
This works if you look at e.g. the most recent block as of this writing—block 640037—whose coinbase scriptSig begins with these 4 bytes: 0x0325c409. 0x03 indicates the length, and then we have (0x25=37 * 256^0) + (0xc4=196 * 256^1) + (0x09=9 * 256^2), or 37 + 50176 + 589824 = 640037.
For obvious reasons mainnet and testnet will never need to encode heights 1-16 in their coinbase. But regtest nodes will. When I run a fresh regtest node (v0.19.1) and generate a couple blocks, I get coinbase scriptSigs that look like this:
height 1: 0x510101
height 2: 0x520101
...
height 16: 0x600101

Clearly it's not serialized CScript, at least in the format described in BIP-34. If it were, those first bytes would indicate data lengths of 81, 82, and 96 respectively, clearly ridiculous. The actual encodings of 1, 2, and 16 in serialized CScript are 0x0101, 0x0102, and 0x0110. It looks to me like the format is height+80 followed by 0x0101. And for some reason this only persists for the first 16 blocks, as 17's scriptSig is 0x01110101.
I tried looking through the bitcoin source code, but I don't write much C++ so it's hard to tell what's going on. No documentation—in the source (as far as I can tell) or the PR for BIP-34 or in the BIP itself seems to indicate that heights 1-16 would have a different format from every other height.
Why is this happening?

The actual encodings of the numbers 1-16 are 0x51, 0x52, etc. This is because the numbers 1-16 are special in Bitcoin script and have their own explicit opcodes. OP_1 is 0x51, OP_2 is 0x52, etc. The correct way to write numbers with their own opcodes is to use those opcodes instead of using a pushdata opcode followed by the number.


How can we access all transactions, including spent transactions, through bitcoind? We are running bitcoind version v0.8.2-332-gf19eda1-beta.

Our goal is to parse all transactions in a given block.

To begin we call "bitcoind getblock ", which gives us a list of associated txid's.

We then call "bitcoind getrawtransaction " on each of these.

Unfortunately, getrawtransaction occasionally fails with:

error: {"code":-5,"message":"No information available about transaction"}

It is failing because the given transaction is not unspent, and the database which getrawtransactions relies on does not need to track such transactions.

This is explained in detail here on github:
https://github.com/bitcoin/bitcoin/issues/2077

"there is never need for more information than unspent transactions outputs, so that is the only piece of data that is kept"

Are we forced to parse the blockchain database which bitcoind maintains on disk ourselves?
Is there some way to extract the information we want through bitcoind?

Shouldn't bitcoind provide an interface to all blockchain information?
It recently changed its underlying database and may do so again.

The problem begins by the fact that bitcoid doesn't keep that kind of information for spent txs, which however serves the typical QT user.

All you have to do to obtain a record for spent txs is:

run ONCE ONLY bitcoind with arguments: -reindex=1 -txindex=1, allow it quite some time to complete, add -debug -printtoconsole if you want to see the re-indexing progress in real-time
add: txindex=1 to bitcoin.conf


Which cloud server provider is best for accepting bitcoin payments with BTCPay Server? This video shows someone using lunanode for their BTCPayServer cloud server. What are the other top reputable and reliable cloud servers out there for running an online store that wants to act as its own payment processor via BTCPay?

Actually, it's my video :D
Lunanode provides easy "1 click install" process. You can host btcpay server on any other VPS server (like azure, aws, digitalocean etc.) but the process will be just a bit more complicated, and will require downloading and configuring btcpayserver.
As always any solution will have some tradeoffs, like cost or how easy it is to use, how reputable is the provider, etc.
All methods of hosting are presented in this document.


What happens when an attacker completely controlls your Internet connection? Bitcoin assumes that everybody sees the same ledger. However, what if your ISP is evil, and modifies your view of the Bitcoin network? Is it possible for such an evil ISP to make your own transactions not go to the real Bitcoin network, while returning results that make you believe that everything is fine? Your local blockchain could end up extremely badly out of sync with the global blockchain.

Is this scenario possible? If so, what happens when you finally sync back with the real blockchain? As far as I understand, Bitcoin always chooses the longest blockchain, but couldn't your evil ISP simulate a really busy Bitcoin network to you so that your fake blockchain is even longer?

Does this mean that applications like Satoshi Proof and Namecoin aren't really secure if networks can be maliciously partitioned? In Namecoin, for example, wouldn't it be possible for a bad ISP to simulate a blockchain that contains wrong domain information?

Yes, the scenario is possible. The attacker has two possibilities: censoring data sent to the network (likely your transactions) and censoring what the nodes sees from the network.

In the first case the isolated node will attempt to resend transactions that belong to it until they get invalidated or committed into the blockchain.

In the second case the isolated node will not receive incoming transactions and eventually will not receive blocks (if these contain censored transactions). It is however not possible to fool the node into considering transactions as confirmed without the attacker also producing a valid proof-of-work.

The same argument is valid for Satoshi Proof and Namecoin, you can hide transactions, facts and domains, but you cannot inject wrong information.

Once reconnected the node will synchronize with the network (download blockchain & send its transactions) and eventually be up to date.


Can anyone help me understand why my transaction won't confirm https://blockchain.info/tx/23bddd7a323f5e772d4e3cb24c1c0687c8fcfa79066a0986082a8c101f1ce648?show_adv=true
I have a high transaction fee, and not double spending. Any Ideas?

Your transaction is confirmed now. The blockchain link shows it took 214 minutes to be confirmed.


How does BIP 0070 work for me, the user? BIP 0070 (the payment protocol) is included in Bitcoin-core 0.9.0. The main idea behind it is to simplify the sending of bitcoins to a service by making it a more p2p thing.

My question is this, from the user's perspective, how would this work? Does a website give me a link or button to click and then I authorize a payment?

Right now with bip-0021 it is possible to define bitcoin URIs to make payments like this:

bitcoin:1JfzSVJV44AALQrNrLCehznQLvbhUcr5mB?label=tip-erasmospunk

so if you put this URI in an HTML anchor:

tip me!!!

and click it the bitcoin wallet opens and it is preloaded with my bitcoin address together with the label "tip-erasmospunk".

One of the problems with this approach is that when I pay, it will take many seconds until the transaction propagates properly in the bitcoin network and the merchant receives it (we are talking only about the merchant seeing the transaction, not about conformation that can take many minutes). So if you want to pay the metro ticket, you need to do it as fast as possible.

So with bip0072 the above URI scheme is extended with the r parameter that points to the merchant's server. The wallet ignores the other parameters (address, label, etc) and speaks with the server by using the bip-0070 Payment Protocol. This protocol allows the merchant to receive your signed transaction directly from you and confirm the transaction faster.

The faster transaction times are one of the benefits, here is the full list:

Human-readable, secure payment destinations-- customers will be asked to authorize payment to "website.com" instead of an inscrutable, 34-character bitcoin address.
Secure proof of payment, which the customer can use in case of a dispute with the merchant.
Resistance from man-in-the-middle attacks that replace a merchant's bitcoin address with an attacker's address before a transaction is authorized with a hardware wallet.
Payment received messages, so the customer knows immediately that the merchant has received, and has processed (or is processing) their payment.
Refund addresses, automatically given to the merchant by the customer's wallet software, so merchants do not have to contact customers before refunding overpayments or orders that cannot be fulfilled for some reason.


Why did my transaction not include the fee? I moved 0.30 BTC from Bitcoin Wallet for Android to a new Coinbase wallet I had created, I have waited and waited – now it’s been 29 hours.

It turns out the transaction doesn’t include a fee, which was why it’s taking so long. I was surprised, because Bitcoin Wallet for Android doesn't have a feature to opt out of sending a fee. I don’t think any android based application wallet has? I checked right through the app and the fee is automatically taken every transaction (as it should be IMHO).

So, how come this one transaction did not include a fee, while each of the past 50,000 transactions I've done have, including two since this incident using the exact same wallet to the exact same Coinbase wallet in an attempt to force my other one to be confirmed.

I've spoke with the Bitcoin devs and it’s not a bug with the wallet, or if it is, then this is literally the only case this has happened in.

Why and what could cause this? How long do I wait? Is my 0.30 coins in limbo never to be seen again? Is there any way I can just cancel this transaction and try again? Is there any way to manually pay the fee? Or confirm it myself somehow?

Coinbase says my 0.30 BTC is pending and will be confirmed in 30 minutes; it has said that the whole time.

I don't know why your wallet didn't include a fee, and it would probably require a fair amount of debugging to figure out what went wrong.  Here are my suggestions for following up on this problem:

Make sure your transaction really didn't include a fee.  Open your wallet, find the transaction is the list of outgoing transactions, and press-and-hold on it to get the extra menu, and open it in the block chain explorer (BitEasy in Bitcoin Wallet For Android).

In the block chain explorer, look at the details and make sure it didn't really include a transaction fee.  If there is a fee, Coinbase support got something wrong---so contact them again.  If there really is no fee, go to the next step.
See what wallet you use.  From your description, it sounds like you use Bitcoin Wallet For Android, developed by Andreas Schildbach and based on BitcoinJ by Mike Hearn.  I've worked with both of them, and they're both very responsive to user problems.

If that is in fact the wallet you use, open a new issue on their issue tracker.  Here is the information you should provide them:

A link to this question.
The link to the page on BitEasy that shows your transaction had no fee.  Note: this may reduce your privacy (but it won't put your bitcoins directly at risk); if you uncomfortable with that, ask them if you can send them that link by email---I'm sure they'll accept.
What version of Android you use (Settings→Device Information→Version) and whether you use the latest version of Bitcoin Wallet For Android from the Google Play store.
Whether or not you completely emptied the balance of your wallet.  I think there's some special code that gets run when that happens.
Anything else unusual that you noticed.
You may also want to provide a copy of the text from the email Coinbase support sent you after removing any personal information.

If you use a different wallet, you'll need to follow the same basic steps but at a different URL.  Let me know the full name of your wallet in a comment below, and I'll find the most appropriate link.
Read the response from the developers closely and respond as best you can.  Please note that Andreas, Mike, and everyone else who works on Bitcoin Wallet For Android are all volunteers, so it sometimes takes them a while to get to new issues---please be patient.

This may seem like a fair amount of work, but filing issues is one of the ways you can support great open source software like Bitcoin Wallet For Android.


Building a Bitcoin IPN. Need unique identifier I am building a Bitcoin IPN to poll bitcoind every 5 minutes, find new payments with at least 1 confirm, and notify a server.

It looks like I am going to have to load them all up with 'listtransactions' every time and parse out new ones.  Inelegant, but I don't see any other option.

So the next problem is that I need a unique identifier of payments so that I can see if it has already sent a notice.  I have read that txid can change?  Well, that is not a bloody ID then, is it?!  How can I identify a payment?  sha1(address . amount . time) ?  What is the difference between 'time' and 'timereceived'? Are they static?

The best discussion I found about this is here but it doesn't look like it went anywhere;

https://bitcointalk.org/index.php?topic=3092.0

Cheers.

TXIDs cannot change. TXIDs are simply hashes of the transaction. It is possible for two different transactions to have the same TXID - that's called a hash collision. However, the chances of that happening are so low and I believe you will actually win prize money if you find a collision.


Migrate wallet from Bitcoin Core to Armory I have installed Armory.  I have created a wallet within the Armory.  I however would like to use a wallet I have with bitcoin core.  I am unsure how to do this.  Thank you for the help.

All I have is the wallet.dat

I have uninstalled bitcoin core and when I reinstall I have no idea how to use the wallet there either.  Ultimately I have wallet.dat and I'm unsure how to get that file into the Armory.

The easiest way is to simply send them from the bitcoin core wallet to an address in armory wallet.

The other option would require you to use dumpprivkey on each address and then importprivkey on armory.


What is the most expensive Bitcoin purchase ever made? Relying only on publicly disclosed data, what is the most expensive Bitcoin purchase that has ever occurred?

"Expensive" can be determined either by:

Highest purchase price in Bitcoins
Highest fiat value equivalent at the time

If you mean the greatest amount of bitcoin spent,  the "bitcoin pizza" comes to mind. At a whopping 10k BTC spent.

Pizza for bitcoins? (bitcointalk.org)


Why is a minimum transaction fee for 0.01 BTC *sometimes* enforced I have read Why would Bitcoin-QT attempt to charge a processing fee, when I have my transaction fees set to zero? but I still have a question.

I am sending 0.01 BTC from my wallet to my Ethereum intermediate address and then back again, so as to verify recoverability.

Sending 0.01 BTC worked fine without transaction fees. When sending it back I get "The total exceeds your balance when the 0.0001 BTC transaction fee is included." although fees are set to zero.

Why is there a fee requirement in one direction only?

This depends on the priority of a transaction. If an input (coins you received from an earlier transaction) was not used for a longer time, its coin-age (equal to confirmations) increases and therefore the priority.

If the priority is equal or above middle-priority (thats what the bitcoin-core client and the blockchain.info side calls it) it does not require fees. So when you send your first bitcoins, those had a high enough priority to get shipped for free. Then you tried to send them back immediately, with a low priority, so you were forced to set a transaction fee.


Backup wallet of single account As far as i know that online wallets as Blockchain.info is a Bitcoind instance that gives each user an Account and each account related to multiple addresses through JSON-RPC calls, how blockchain.info backup wallet of individual account ? i imagine that all accounts are stored in a single wallet.dat ! or does blockchain.info has wallet.dat for every account ?

Nobody really knows how it's implemented, other than the developers of the site, but I doubt they keep a single wallet.dat file. They don't store the keys of each address so it could very well be that they don't even use bitcoind.

They could use their own implementation which would allow for better concurrency since they have lots of users accessing their wallets at once.

You can build a bitcoin wallet however you'd like. It doesn't have to be a wallet.dat file. You could even put the information of the transactions in a basic MySQL database (which is good at concurrency) and have something like PHP process and send out the transaction, and you'd have a wallet represented within a MySQL database.

To answer your question, I'm sure of course they do have proper backup routines of their database, just like any other website.


New to Bitcoin - tips on securing my server I regard myself as being a competent programmer and have good general IT knowledge; however I know very little about BTC. I just want to make sure that my setup is "generally secure" and that I'm grasping as much of the low hanging fruit as possible (from a security point of view).

So I installed bitcoin-cli on my Ubuntu 14.04 VPS (I am quite trustworthy of the company who provide the VPS):

sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install bitcoind

Here's my init script:

description "bitcoind"

start on filesystem
stop on runlevel [!2345]
oom never
expect daemon
respawn
respawn limit 10 60 # 10 times in 60 seconds

script
exec 2>>/var/log/bitcoind.log
set -x
user=eamorr
home=/home/$user
cmd=/usr/bin/bitcoind
pidfile=$home/.bitcoin/bitcoind.pid
# Don't change anything below here unless you know what you're doing
[[ -e $pidfile && ! -d "/proc/$(cat $pidfile)" ]] && rm $pidfile
[[ -e $pidfile && "$(cat /proc/$(cat $pidfile)/cmdline)" != $cmd* ]] && rm $pidfile
exec start-stop-daemon --start -c $user --chdir $home --pidfile $pidfile --startas $cmd -b -m
end script

Saved init script to /etc/init/bitcoind.conf

service bitcoind start

OK great.

* Now what? *

(Bearing in mind that I don't want to use a third party website)

Do I need to open port 8333 on my firewall? Is that ok?

Is there some "private key" I should store somewhere safe? Do I need to store this on my VPS?

Is there anything else I should do?

I want to buy €50 of BTC. I guess I need an address. How do I create an address? I will tell the folks at bittylicious.com to send €50 worth of BTC to my newly created address, right?

Finally, how do I create multiple BTC addresses, receive money at those and transfer into my "master" BTC address?

Here's some command outputs for your information:

>> bitcoin-cli getnetworkinfo
{
    "version" : 90201,
    "protocolversion" : 70002,
    "timeoffset" : 0,
    "connections" : 8,
    "proxy" : "",
    "relayfee" : 0.00001000,
    "localaddresses" : [
        {
            "address" : "xxxxxxxxxxxxxxx - IPv4 address",
            "port" : 8333,
            "score" : 9
        },
        {
            "address" : "xxxxxxxxxxxxxxx - IPv6 address",
            "port" : 8333,
            "score" : 1
        }
    ]
}

>> bitcoin-cli getinfo
{
    "version" : 90201,
    "protocolversion" : 70002,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "blocks" : 172082,
    "timeoffset" : 0,
    "connections" : 10,
    "proxy" : "",
    "difficulty" : 1498294.36281651,
    "testnet" : false,
    "keypoololdest" : 1409306527,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "relayfee" : 0.00001000,
    "errors" : ""
}

>> bitcoin-cli listaccounts
{
    "" : 0.00000000
}

>> bitcoin-cli listreceivedbyaddress
[
]

Thanks for your help guys,

Update:

There's an init script for Debian (works on my Ubuntu 14.04) in the offical repo:

https://github.com/bitcoin/bitcoin/blob/master/contrib/init/bitcoind.conf

So, all you have to do to get bitcoin up and running headless (from a fresh install) is:

sudo apt-add-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install bitcoind
sudo curl https://github.com/bitcoin/bitcoin/blob/master/contrib/init/bitcoind.conf > /etc/init/bitcoind.conf
sudo vim /etc/init/bitcoin.conf
#Delete the line "disablewallet" (part of "exec start-stop-daemon" command) - don't delete if you don't want a wallet
adduser bitcoin
sudo mkdir /var/run/bitcoind
sudo chown bitcoin:bitcoin /var/run/bitcoind
sudo mkdir /var/lib/bitcoind
sudo chown bitcoin:bitcoin /var/lib/bitcoind
sudo mkdir /etc/bitcoin
sudo touch /etc/bitcoin/bitcoin.conf   #put your config in here: rpcuser, rpcpassword, etc.
sudo apt-get install ufw
sudo ufw allow 22
sudo ufw enable

This installation is maintainable and gives a "good" level of security.

First of all, I'd suggest to create a separate user account for this:

adduser bitcoin

And use that account to run your bitcoind from.

You can open the port 8333 on your firewall if you want to provide a "full-node" to the network, but do not open the port 8332 (that's for RPC).

For better security though, I don't recommend using the same bitcoind instance for both wallet-storage and as a public node. If you can afford two machines, set up the wallet on one of them (this will be a "private" instance) and a "border-router" instance on another. Then make sure the private one only connects to the border-router (use connect=<border_IP>) configuration option. Then you can feel safe to enable port 8333 on the public border-router machine and as an optimization, you can disable the wallet on it (-disablewallet).

Once you have it all set up, you can proceed to creating an address. Run:

bitcoin-cli getaccountaddress myaccount (use any account name you like)

Here you can find a nice command reference.


What would happen if there are more blockchain imitators like Factom? I was referring to this question.

Apparently Factom creates its own "chain" for timestamping purposes, "hashes" the entries, and then stores these hashes on the blockchain, to create an unalterable record.

What would happen if "everyone" in the world did this? Could the blockchain support a million (or a billion) more "Factoms?"

The way Factom works, they store the merkle root of the various hashes on the blockchain in an OP_RETURN output. This amounts to 80 bytes in the OP_RETURN and the actual transaction is going to be on the order of 500 bytes. The way they scale is that they store the actual merkle tree elsewhere and only put the root into the blockchain, about once per block.

Assuming that everyone uses Factom, this would mean that the blockchain would only get one Factom transaction per block, which is what it's already doing. If there were a million other services using OP_RETURN, then no, currently, the block size is limited to 1MB per block, which can only take about 2000 such transactions per block.