Bitcoin Forum

The reason I ask is that it (http://blockexplorer.com/q/totalbc) is a nice round number, but there are at least 20 nanobitcoin which have been literally "destroyed", or removed from existance forever. http://blockexplorer.com/block/0000000000004c78956f8643262f3622acf22486b120421f893c0553702ba7b5 (http://blockexplorer.com/block/0000000000004c78956f8643262f3622acf22486b120421f893c0553702ba7b5) gives an example of this. So unless an entire 0.99999998 have also been destroyed (which is unlikely), am I correct in assuming that this number is an upper limit to the amount of bitcoins in existance and not an exact amount?

Yes, it's the total number of bitcoins generated; not the number if bitcoins "available".

It's the upper limit. If you remove coins that have been obviously destroyed in that way, the number would be 200.01000001 less than the upper limit (at the moment).

Okay, thanks. How did you obtain that number: ran a script over the blockchain? ABE?

I queried the BBE database. It currently takes like 10 minutes to compute, though, which is why I don't make it available on any page.

You wasted 10 minutes to help me - I'm honored! I sent a tiny donation as a token of thanks.

Sorry for the stupid question, but how did 20 nanobitcoins get destroyed in that block? I thought bitcoins never gets destroyed, they can only become irretrievable?

Did you not see that the generated coins were 49.99999999 instead of 50?

More important questions:

1. Was that expected when the Bitcoin protocol was designed, or is this something new ?
2. Is it proper for a block to generate 49.99999999 bitcoins instead of the usual 50 ? Where did the 0.00000001 bitcoins go ?
3. If it is not proper, why wouldn't the network reject such a block ?

No, I missed it.

So how did this happen? Did a miner intentionally reduce his profits? Was it a bug in his code? How come all other nodes accepted this block?

@ShadowOfHarbringer: those 0.00000002 BTC were never generated. Transactions are allowed to have fewer TxOut than TxIn--the difference is the Tx fee. Does the Satoshi client allow for the same discrepancy in the generating transaction? That would be news to me but explain what's going on here. The miner is failing to claim as many BTC as they are entitled to, resulting in fewer BTC generated for that block than would be expected. So this isn't really a case of coins being destroyed as much as new coins not being minted--but if the miner set the generator Tx0ut to zero, those transaction fees would be destroyed.

Anyone know why this happened? Looks like a buggy miner subtracted the Tx fee instead of adding it--but why was the block accepted by the network?

@theymos: that's an awfully round number. Are there 4 blocks that didn't generate bitcoins at all?

Exactly. That could be a serious weakness in the protocol.
Why would all other clients accept such blocks ?

Shoudn't there be a rule that only allows relaying/accepting of completely valid and "full" blocks ?

For example: if a huge mining pool suddenly breaks down and starts producing blocks which earn 0 BTC to the network, then a lot of BTC could be lost in the process.

At least two blocks didn't generate any BTC:
http://blockexplorer.com/block/00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec
http://blockexplorer.com/block/00000000000743f190a18c5577a3c2d2a1f610ae9601ac046a38084ccb7cd721

I'm not sure where where the other BTC was lost. My current database structure doesn't allow me to easily get the particulars. It's also possible my calculation was incorrect.

Interesting, thanks.

Yeah, I was definitely off by 100 BTC. The number lost is actually 100.01000001. All losses are accounted for, then: 100 BTC from duplicates and 0.01000001 from the transaction dree12 linked to (0.01 fee that BBE mishandles plus the satoshi dropped purposefully by the miner).


Thanks!

According to my database (it only stores bitcoins in txouts not spent, that takes only 1.86 seconds to get the result), I get 727699999899998 satoshi's available after 145542 blocks, which means there are 100.00100002 "lost".
2x 50 coins are "lost" due to duplicate transactions in generation, which my database didn't like at first (because it has a unique tx hash index).
Didn't know up to know if the others where rounding errors on my side, but it seems the 2 satoshi's are indeed from block 124724.
So that's only 0.001 bitcoin not yet accounted for... ???

I think those are the transaction fees that are available in that block but unclaimed by the miner.

What could cause this to happen and how could it be prevented?

Are you sure it's not a problem with your database theymos? The other block explorers report the 50 BTC generated ok

http://pi.uk.com/bitcoin/block-index/92507/00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec

http://pident.artefact2.com/block/00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec

http://abe.john-edwin-tobey.org/block/00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec

That's because the 50 BTC was, indeed, generated ok. It's just not possible to spend the duplicate transactions since the Bitcoin client considers the two transactions to be one and the same.

How exactly is it possible for two transactions to be the same? Or is this only possible with "Generated" transactions?

Indeed two pairs of blocks contain duplicate coinbase transactions, as I confirmed by querying Abe's database.  I believe some miner failed to configure a new output address for each block, and when it solved two blocks with the same "reward" (50 BTC in this case) and the same coinbase script (collision in the "extra nonce" field and lack of other distinguishing data), this resulted in bitwise identical transactions.  I would consider this a bug in the program that assembles blocks for the miner.

Abe currently deducts for lower-than-deserved rewards but fails to notice duplicate transactions.  Abe also deducts when a coin goes to the public key hash consisting of all zero bits, which can not be reclaimed if our assumptions about crypto strength hold.

In the end, is this of any concern for the general Bitcoin using public or just a technical curiosity?

It is a curiosity.  If a majority wanted to stop us from creating more duplicate coinbase transactions, someone could easily patch the code so as to reject such blocks.  But I doubt that enough people care enough to overcome well-placed conservatism and inertia among pool operators, miners, and core developers.  I personally would tend to oppose such a change for the BTC chain, though I might revisit it when starting a competing chain.

Ok I see, I think adding the following to CheckBlock() would be enough to patch it.

There's no point in adding new code the prevent duplicates. Only generation transactions can be duplicates, and they don't harm the network.

But can they not prevent new coins from coming into existence? Surely as a method of coin destruction it should be patched?

You can't stop people from destroying coins. People can just lose their private keys if they want to destroy BTC.

Then why bother checking to see if a block has a coinbase transaction at all.

Would the following not be a potential issue.

1) You receive a block over the network with valid coinbase whose hash is a duplicate a of an existing normal transaction
2) The block is accepted and saved to disk
3) The chain is rescanned and the block is read back from disk
4) the block will now have a normal transaction in it's coinbase slot

Will it then be rejected?

So you are saying that we should allow miners to generate tons of invalid blocks with 0 BTC as output ?

What about if a mining pool gets hacked and produces thousands of blocks of which each will yield 0 BTC ? This is a possible attack vector.

Still, shouldn't Bitcoin protocol be more predictable, like there will be exactly X coins in circulation at specified time ?

Not allowing miners to generate more than 50 BTC, while simulataneously allowing them to generate less than 50 BTC is little weird from programmer's point of view. Why should  < 50 BTC blocks be counted as valid, while blocks > 50 BTC be counted as invalid ?

Why wouldn't this work both ways ?

The miner could just as easily generate a block with 40 BTC to an address they control when they could have claimed 50 BTC and so have 10 BTC just not there, as generate a block with 40 BTC to an address they control and 10 BTC to an address they don't control like 1111111111111111111114oLvT2, or even generate a block with 40 BTC to an address they control and 10 BTC to another address they control that they then delete the private key of. It does the same thing either way, and there is just as much BTC "in circulation" either way. Having the client reject some of these possibilities doesn't help any "attack" scenario, since one can do the same thing in another way just as easily.

Destroying BTC if you control its generation or its private key is very easy: Just send it to an address that nobody has the private key for, or just delete your private key yourself. This doesn't hurt anybody but yourself. And in most cases, I'd expect an attacker that had control over a pool generation or over a private key that had coins would just send the money to themselves rather than just outright destroying it.

There is no way you can be a 100% sure that nobody owns the private key of a particular address, so you don't know for certain if they are destroyed or not. There is also the possibility that in future a collision maybe generated and the coins reclaimed. With this this method you can be 100% certain that the coins are destroyed and there is no way they can possibly be reclaimed.

To fix the (rare but not impossible) bug i described either CheckBlock() should allow blocks with no coinbase at all or coinbase transaction hashes must be unique.

The "bug" you described is a collision in SHA256(SHA256(x)).  If such a thing can be made, we have much bigger problems than someone overwriting a coinbase with a transaction.

Miners (or anyone) can also destroy coins irredeemably by sending generated coins to "OP_FALSE" or to any other script that can never return true.

It could be a collision with any previous transaction hash, so the odds are increased the bigger the chain grows. I still think it's better not to leave things to chance, when it can be patched fairly easily.


This is a design flaw which can't be fixed, the other issue can be. I must admit it seems to me like scripts create a lot more problems than they solve.

Birthday problem (http://en.wikipedia.org/wiki/Birthday_problem#Cast_as_a_collision_problem)

In general, we expect a collision in the hash output once every 2¹²⁸ hashes.  That is 3.4*10³⁸.  That means that 100 billion people, each generating 100 billion hashes per second for 1 billion years will generate on average one collision.


In that case, you probably don't really understand what scripts are or what they do.  In my opinion, they are the most important feature of bitcoin for the long run.

That assuming SHA256 is a perfect hashing algorithm. Besides the coin destruction problem still exists.


Please explain what could be done in a script than couldn't be done if each client had a set of known methods to sign a transaction and a simple varint was included in a transaction to identify which method to use. At the moment scripts add a large amount of size to the block chain for little purpose.

Types of transactions we haven't thought of yet.

The script system is rather flexible, and allows us to add new types of transactions in the future, without requiring the entire network including miners to upgrade to a new version.

No hashing system is perfect, but we keep getting better at it.  MD5 was pretty good.  SHA is much better.  And even if the distribution of outputs from SHA256 is only a tenth as good as perfect (which we totally would have noticed by now, but whatever), that just means that the next collision will happen in a mere 100 million years rather than a billion years (as per my totally exaggerated example from before).

Coin destruction certainly exists, but it isn't a problem.  So far, no one but you seems to have taken any offense to it.  Why do you think it is a problem?


Peter gave the big picture.  Let me give an example of a specific scenario that can be done with the scripting system, but not with simple signatures.

You want to protect your wallet.  You use a secure offline computer to generate a bunch of keys and print them out for safekeeping in a bank box.  You also sign up with an online service that gives you a series of keys (or just one key, or a seed to generate a sequence yourself, whatever).  You create another set of keys yourself, and then combine them with a script that can be satisfied under the conditions (A and B) or C, where C is one of the keys in your safe, A is one of the keys from the service, and B is just an ordinary key.

In that way, whenever you want to spend coins, you sign it with your B key and forward it to your online service.  The service consults a set of policy rules associated with your account and sends a SMS to your phone asking for verification.  You reply to the SMS, and the service signs the transaction with their A key, and broadcasts it to the network.  Since the transaction has both A and B keys, the script can be completed, and the transaction will spend as usual.

Someone that gets access to your computer can't spend your money unless they can also get the key from the service.  Also, someone that gets access to the service can't spend your money unless they can also get your keys.

If the service is attacked and you lose faith in it, or if they shut down, or if you lose your B keys, you go to the vault and pick up your stack of paper, so that you can transfer your funds to a new safe location by using just the C keys that you printed earlier.

All of this can be done using the scripting system, and without anyone in the entire network having to update their client to allow it specifically.

Do you understand the value now?

Because a) it's good to know exactly how many coins will be/are in circulation b) the number of bitcoins has a hard capped limit and if enough are destroyed it will make it difficult to function properly as a currency. Why are you so against fixing the issue?


You could do this fairly easily with Shamir's secret sharing algorithm. Just generate 4 shares of a single SHA256 private key with 2 shares required for reconstruction. You keep one, the bank keeps one and two go in the vault.

Or even more straight forward just code this type of transaction into the client. Yes you will need to update, but i expect the scripting will require updates as well. At the moment not even the main bitcoin client has all the script operands enabled, Bitcoinj only supports 7. As different clients become more popular it will be difficult to ensure scripts are fully supported.

a) true, but so what?  Also, impossible.
b) false, so long as destroyed < 100%

It is a pointless change.  Yes, I said change.  Not a problem.  Not an issue.  A change.


Yes, this one example can be done in many ways.  But I think you missed the key point of my previous post.  I'll repeat it here:


The scripts allow anyone, anywhere to devise their own systems without seeking permission from the rest of the world.  I guess if you don't see that as a useful feature, I'm not going to waste any time trying to convince you.  But then again, I don't need to either.  You are the one asking the world to change.

By the way, these two topics have been discussed to death on these forums.  Search for "demurrage" and "script".