Bitcoin Forum

Bitcoin test-net
See  http://blockexplorer.com/testnet/address/mtoKs9V381UAhUia3d7Vb9GNak8Qvmcsme
Received BTC: 152.7792
Sent BTC: 202.7792
50BTC sent to more than got it!?!?

Doesn't that mean you gave it to the miner?

before anyone misunderstands ... this is on testnet and not the bitcoin blockchain

lol :D

What is the difference of the Bitcoin and  Bitcoin TestNet? Technically, nothing! So it can happen in Bitcoin

50 BTC block reward. 

Are they testing out a new BIP? This could be due to a bug in a BIP someone is trying to implement and why I am an advocate of an excessive level of testing on testnet before it ever makes it to the real bitcoind.

negative balance.. oh dear

bip -1
to compete with the banking system, bitcoin now supports overdrafts.   any overdraft will cost you in fees enough to pad a new bonus system to overly compensate the bitcoin executives at the top.

seriously though ..., this is a problem somewhere, right?  (but is isolated to whatever code blockexplorer is using for testnet only, right?)

Don't panic.

roconnor has been experimenting with spending "duplicate coinbase transactions" on the testnet.  Block explorer is confused, and isn't seeing the 50 bitcoins generated to that address in testnet block 45,442 (because the generation transaction has the same ID as the generation transaction in block 45,333).

Expect code changes before the 0.6 release is final to discourage and eventually prohibit accepting blocks with duplicate coinbase transactions; although we can't see a way to exploit this weirdness to cheat anybody (it is easy to cheat yourself out of bitcoins using duplicate coinbase transactions that cannot be spent), it's definitely not a good thing.

No worries.

Notice that tx 0018417e23... and fae8bfd6a2... on that address ledger spend the exact same output. It looks like a double-spend, but it's actually a less severe bug in the protocol that probably doesn't allow for any easy attacks. (Because the bug causes very strange behavior, though, it might allow for attacks that have not been thought of yet.)

These transactions actually broke Bitcoin Block Explorer when they first appeared because there was a database constraint preventing double-spends from being inserted into the database. I "fixed" it by removing the constraint, but this causes BBE to display these transactions strangely. A lot of code would need to be changed, but I might fix it fully some day.

Good job Gavin!! Testnet is... FOR TEST!!!   ;)

That sounds pretty terrible. :o

Technical explanation:

When you create a block, the coinbase transaction which generates 50 BTC can easily be made to exactly equal a past coinbase transaction: it just needs to pay out to the same address and have the same (arbitrary) scriptSig. Unfortunately, this transaction will then have the exact same hash as another transaction in the chain. Satoshi did not anticipate this, so it's allowed by the protocol and it confuses the Bitcoin code.

In this case, roconnor:
- Generated a block containing a normal coinbase transaction.
- Spend the BTC generated in the coinbase transaction. Bitcoin nodes mark the coinbase transaction's output as spent.
- Created a block containing a duplicate of the first coinbase transaction. Bitcoin nodes will now overwrite the first coinbase transaction in the transaction database. The output of the coinbase transaction is marked as unspent. The transaction spending the original coinbase output is not affected and is still considered valid.
- Spent the BTC generated in the second coinbase. There are now two transactions spending the "same" output.

Do you lose the original if it isn't spent when you make the new identical one? Because when you spend either now it'll be marked as spent?

Right. This has happened a few times on the main network, actually. Not sure if anyone realized until recently that it was possible to spend both, though.

:o

Anyway, now this guys will solve a bug!

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 :D

Well, I think that ANY overwrite is serious...

But you got a point!

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

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

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.

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 (http://en.wikipedia.org/wiki/Hash_function) rather than cryptographic hash (http://en.wikipedia.org/wiki/Cryptographic_hash_function).

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.

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

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.

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.

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.

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

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


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