Topic: Security update: duplicate transaction vulnerability fix - page 2. (Read 14543 times)

Maybe the person who owns http://bitcoinwatch.com/ could post this thread in the "Latest news" section of their website?

I have updated the second post with a list of pools from whom I have received confirmation they will update. I will keep that list up-to-date as I receive more confirmations.

This thread really needs to be more visible:  Perhaps a giant bold red link at the top of the forum?

BTC Guild will be pushing the patch tomorrow, and my understanding is both Slush & Deepbit will be shortly as well, which means the chain will have majority support.  That doesn't solve the problem of the other 30-40% of bitcoin miners that may not even know about the issue due to lack of visibility.

Nice explained. Thanks!

It has been known for quite a while that a new coinbase with the same hash as an old coinbase was possible and not handled at all.  But since they are referenced by their (identical) hashes, there was no way to specify which one you meant to redeem, so redeeming one would redeem all of them.  This is not in any way a security problem, and can only be used to lose money.  There are faster and easier ways to lose money.

What was only recently discovered was that if you spend a coinbase, and then generate another identical one, you can then spend the second one too.  Spending a transaction doesn't mark that hash invalid for all time, it just removes it from the list of unspent transactions.  Another one can show up and be accepted.  This is, again, not a security problem, and doesn't, by itself, make it possible for people to lose coins unintentionally.

The list of all used transactions isn't readily available, and once pruning shows up, it might not even exist at all.  So, it only makes sense to compare the new coinbase to the list of transaction hashes that are unspent at the time, which aren't subject to pruning.  This also preserves the old behavior of being able to generate and spend multiple identical coinbases, so long as they are spent before the next one shows up.  And finally, it gives us a really short and simple patch, that anyone can read and understand without having to worry that a new side effect has snuck in.

I understand the "IF NEWER THAN SOMEDATE" in code, this is to prevent invalidating the entire chain since when first duplicate transaction appeared.

But, with this date switch implemented, why to check for spent/unspent transactions, instead of simply comparing the hash against all previous (just for blocks after the switch)?

That is basically what happens: a block with a duplicate transaction will become invalid, and thus will be ignored.

EDIT: obviously, this does not happen to blocks with existing duplicate transactions, as that would require invalidating the entire chain since then.

@casascius: you are right that technically a specification is needed for what to do with duplicate transactions in blocks before the switchover point. However, there is no formal specification of bitcoin's network rules currently either (only the code...), and the BIP only specifies the changes to the current rules. The current rules are: the transaction index is overwritten for a duplicate transaction, and a reorganisation removes the relevant transaction index entries.

For all the paranoid people, here is the patch for everyone to read. The red lines came out and the green lines were added.

https://github.com/sipa/bitcoin/commit/a206b0ea12eb4606b93323268fc81a4f1f952531

My guess is because of duplicate transactions already on the block chain.  Discarding the old blocks would discard half the block chain and half of the bitcoins in existence with it.

I don't see very much as unlikely when you're talking about challenging the global banking cartel.

Also (all?) of the coders are known by real name. If they f*ckup bitcoin, they will be known by everyone as the person who screwed things up.
That would be the same as destroying many peoples money, and time invested and many companies and that is not like something you would like to do, ofcourse there is allways the possibility that they are threatened by jail or whatever unless they do this. But in this case its far from very likely.

The bitcoins in block 91812 coinbase have not been spent.  My understanding is the current client will only allow them to be spent once.  If the block chain spec is being amended to say that duplicate coinbases are valid prior to March 15 2012, it should also explicitly address the bitcoins in the duplicate block 91842 and formally declare them as a valid block containing an invalid/unspendable transaction, otherwise there is an ambiguity that may be implemented by future clients/utilities the wrong way.

This is true, no one is forced. But people have a tendency to lose their way.

I just hope Bitcoin doesn't lose its way over time.

It's not just 8 days. The fix was developed for some time now and the process was open so it already was under scrutiny. But even if it was just 8 days it's still enough.


No one is forced to download the updated client. That's the fialsafe in Bitcoin in general.

Anyone can read the code and verify that it really does what it claims. It's like 10 lines of code.


They won't be touched. The new rules only apply to blocks with a time after March 15.

Two more questions then:

Is 8 days really enough time to vet a potentially nefarious plan?

What if a few people DO see something nefarious in it, will they be listened to, or ignored?

My understanding is that there already exists such duplicate coinbase transactions in the production block chain.  (I first learned of this issue when someone came on the forums and pointed out how they "whoops" sent 50 BTC to never never land by mining a duplicate coinbase).  If I find that reference, I'll come back, but I'd like to think this was around block 90000-100000 or so.

EDIT: to include the specific block numbers: 91842 has a duplicate coinbase of 91812.
http://blockexplorer.com/b/91812
http://blockexplorer.com/b/91842

Can the proposal be amended to explain exactly what will happen to these transactions?  Or at the very least acknowledge such transactions exist (assuming I'm not mistaken)?  I assume they must remain valid (so as to not invalidate the entire block chain coming after them).  Anyone reimplementing the Bitcoin protocol will have to account for the fact that these transactions are valid and later ones just like them are not, and there will need to be very clear rules to determine what constitutes a valid transaction.

Simple. As long as the process is completely transparent and open there's really nothing anyone could "sneak" past everyone else in order to cause damage. And if you checked the OP, it pretty much doesn't get any more transparent then how they're going about with this fix. I mean you can even read the mailing list how the devs formulated the fix..

All of this technical stuff is way over my head, but I'd like to share my ignorant thoughts anyways.

It seems to me that 8 days is not enough time for people to really do their research on the matter. If I were a miner, or the operator of a mining pool, I would want to know EXACTLY what I'm doing before I made any serious changes.

Secondly, even if 8 days is enough time there is something unsettling about this. What you essentially have is a few highly skilled coders in the know. If they can dupe the mining community into something, anything, nefarious it could destroy Bitcoin. Obviously, I'm not saying that they will, but posit this:

Imagine highly skilled feds, or any other criminal organization, infiltrated the upper echelon of Bitcoin coders. They spent long hours making it better and building a reputation for themselves, slowly but surely dominating the entire field of coders. Then, one day, it's time to destroy Bitcoin and they issue some sort of scenario similar to the one we're dealing with now, for the mining community to go to a new blockchain or something, and the mining community takes their word for it, and BAM, Bitcoin is hashed forever.

I understand this is conspiracy theory stuff, but can anyone unsettle my fears about this scenario?

One block forks happen all the time.   Meh.