Bitcoin in danger!? Received <Sent!?!

[payb.tc]

would it be possible to see exactly how many times this occurred on the main network?

[1714165519]

1714165519

[1714165519]

1714165519

[1714165519]

1714165519

[bittenbob]

My guess would be never at all. Testnet is where new code is tested out before it is released.

[theymos]

so to clarify, the main consequence of the bug was that a block reward could become lost forever?

still... turning 100 BTC into 50 is less serious of a bug than being able to turn 50 BTC into 100

More serious issues might be possible when there is a reorg. For example, when one coinbase is disconnected, all of its duplicates will also be disconnected.

[payb.tc]

My guess would be never at all. Testnet is where new code is tested out before it is released.

oh, did satoshi test out his very first attempt on the test network before creating the main genesis block?

i thought we were talking about a bug in satoshi's creation, as old as bitcoin itself.

[kjj]

My guess would be never at all. Testnet is where new code is tested out before it is released.

oh, did satoshi test out his very first attempt on the test network before creating the main genesis block?

i thought we were talking about a bug in satoshi's creation, as old as bitcoin itself.

My guess is that there were several genesis blocks while he was working on it, and once everything was ready he released it and the last one he made became The Genesis Block.

As to the overwrite issue, it might be better to think of this as a hash collision.  Think hash function rather than cryptographic hash.

Cryptographic hashes are intentionally very hard to collide, and the default client uses a new address for each generation, so in a way the default client had solved the problem.  But, it didn't expect that someone else might use different software to reuse the same inputs to the hash and end up with the same transaction id.

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction.  And in the future, they will set it to reject blocks that include duplicates, which would be a de facto protocol change, and a good one.

[malevolent]

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction. 

I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.

[makomk]

More serious issues might be possible when there is a reorg. For example, when one coinbase is disconnected, all of its duplicates will also be disconnected.

Yeah, which in theory means that all the nodes that had the block containing that duplicate coinbase in their main chain would wrongly treat an attempt to spend it as invalid and all those that hadn't would correctly consider it valid. This may be usable to create a persistent fork in Bitcoin - that is to say, one that can never actually resolve itself without a huge amount of manual intervention by everyone involved.

[kjj]

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction. 

I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.

No, those are in the past; it is too late for them.  This would apply only when your node creates a new candidate block in response to a getwork request, and then later when a brand new block comes in over the network, fresh from some dude's GPU.

[kjj]

More serious issues might be possible when there is a reorg. For example, when one coinbase is disconnected, all of its duplicates will also be disconnected.

Yeah, which in theory means that all the nodes that had the block containing that duplicate coinbase in their main chain would wrongly treat an attempt to spend it as invalid and all those that hadn't would correctly consider it valid. This may be usable to create a persistent fork in Bitcoin - that is to say, one that can never actually resolve itself without a huge amount of manual intervention by everyone involved.

That would take quite a bit of planning and effort, and the attacker would need to have huge amounts of hashing power plus incredibly good timing.  Oh, and they would only get one shot getting it right, since that fork is only possible during the moment when the network changes rules.  Plus, I'm not sure what anyone could possibly hope to gain by doing it.

And if it even looked like it was possible that someone might do it, we could randomize the rule change time.  Instead of coding it so that the rules change starting with block # X, we could say that the new rules take effect on the first block following # X where the last 8 bits of the header hash are all zero.  That would be totally unambiguous on the network, but still impossible to predict.

Note that under the current rules, if you generate two coinbases with the same transaction and wish to spend both of them, you must spend the first one before you generate the second one.  The duplicates in the past can't be fixed.  All in all, this is a very strange quirk of the system that needs to be fixed, but not a security issue.

[RaggedMonk]

Please edit the title of the OP. Bitcoin is NOT in danger.  You misunderstood.

[runeks]

My guess would be never at all. Testnet is where new code is tested out before it is released.

It has happened on the main network. The following transaction is present in both block 91812 and 91842: http://blockexplorer.com/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction. 

I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction. 

I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.

No, those are in the past; it is too late for them.  This would apply only when your node creates a new candidate block in response to a getwork request, and then later when a brand new block comes in over the network, fresh from some dude's GPU.

In order to check if a generation transaction with the same transaction ID is already existant in the block chain we will obviously have to check past generation transactions. Luckily, only one is created circa every 10 minutes, so even in a 1000 years, we will only have to check around 90 million transactions for duplicates (which can probably be done in a fraction of a pico second in the year 3012).

[kjj]

My guess would be never at all. Testnet is where new code is tested out before it is released.

It has happened on the main network. The following transaction is present in both block 91812 and 91842: http://blockexplorer.com/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction. 

I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction. 

I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.

No, those are in the past; it is too late for them.  This would apply only when your node creates a new candidate block in response to a getwork request, and then later when a brand new block comes in over the network, fresh from some dude's GPU.

In order to check if a generation transaction with the same transaction ID is already existant in the block chain we will obviously have to check past generation transactions. Luckily, only one is created circa every 10 minutes, so even in a 1000 years, we will only have to check around 90 million transactions for duplicates (which can probably be done in a fraction of a pico second in the year 3012).

The absolute worst case for a binary tree search over 256 bits is 256 comparisons.  BDB uses something better, probably a btree (I'm too lazy to look it up).  After 90 million coinbases, the typical search will probably take less than 30 comparisons.  Both of these numbers are trivial and won't add more than a couple of microseconds to block processing time (not counting I/O if the index isn't in memory for some bizarre reason).