Is blockexplorer's total bitcoins in existance accurate?

[dree12]

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

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?

[John Tobey]

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

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.

[TiagoTiago]

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

[John Tobey]

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.

[piuk]

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

//After 28th September don't accept coinbase transactions with a duplicate hash (see tx 00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec)
if (GetBlockTime() > 1317197222 && (mapTransactions.count(vtx[0].hash) || mapOrphanTransactions.count(vtx[0].hash) || txdb.ContainsTx(vtx[0].hash)))
        return error("CheckBlock() : duplicate coinbase transaction");

[theymos]

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

[piuk]

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?

[theymos]

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.

[piuk]

Surely as a method of coin destruction it should be patched?

The destruction of someone else's coins does not cause harm to you, nor does it cause harm to the Bitcoin system. It only causes loss to the person whose coins are destroyed. Everyone else's coins become more valuable.

The person who is destroying their own coins (by generating duplicate coinbase transactions) is free to fix their own faulty software, so that they don't do it again. There's no reason why the Bitcoin client needs to care about it.

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?

[ShadowOfHarbringer]

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.

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.

[ShadowOfHarbringer]

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.

If a mining pool is generating blocks that yield 0 BTC, this is going to be noticed immediately and fixed quickly. Adding complexity to the client to reject those blocks doesn't help the mining pool in any way.

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 ?

[pc]

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.

[piuk]

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.

[kjj]

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.

[theymos]

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.

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.

[piuk]

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.

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.

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.

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.

[kjj]

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.

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.

Birthday 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.

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.

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.

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.

[piuk]

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

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.

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.

[Pieter Wuille]

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.

[kjj]

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

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?

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.

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.

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?