Duplicate transaction exploit?

[theymos]

Take a look at this block on testnet:
http://blockexplorer.com/testnet/block/000000000a055d58b55d9e2c4914480cdeba5f66d0fb285ad2d1510e4e1d607f

It's full of duplicate transactions, and the generator then collects fees (again) on these duplicates. Hopefully I'm processing this wrong, or there is a very serious bug in Bitcoin...

[1715103614]

1715103614

[1715103614]

1715103614

[1715103614]

1715103614

[1715103614]

1715103614

[Raulo]

Something funny but much less sinister happened. The chain split and the longer chain prevailed. Then the transactions from the orphaned chain were included again. The 13368 block in the current chain no longer have these transactions:

Code:

getblockbycount 13368
{
    "hash" : "0000000012bd7874110bd80709495ca18b8d7d1bd2361becde7fadccadfd4d60",
    "version" : 1,
    "prev_block" : "000000001aa60465a56117e1970a7155243f5a4abe1c050406aaca9e0066fe99",
    "mrkl_root" : "e8016a2839fdc1e5627ee2e579e6961d75cda1da15e1f0355676e514214e7228",
    "time" : 1302590964,
    "bits" : 471724584,
    "nonce" : 3997175119,
    "n_tx" : 1,
    "size" : 215,
    "tx" : [
        {
            "hash" : "e8016a2839fdc1e5627ee2e579e6961d75cda1da15e1f0355676e514214e7228",
            "version" : 1,
            "lock_time" : 0,
            "size" : 134,
            "in" : [
                {
                    "prev_out" : {
                        "hash" : "0000000000000000000000000000000000000000000000000000000000000000",
                        "n" : 4294967295
                    },
                    "coinbase" : "0428f21d1c011c"
                }
            ],
            "out" : [
                {
                    "value" : 50.00000000,
                    "scriptPubKey" : "040d5d595d5e16c567994b98a5ede4d58cc9f139776070fc404bca98f420e9cf670152eeb6ee4dbed9652b1df3ae2f6db5905faff36834c5196dc8940d91ce9630 OP_CHECKSIG"
                }
            ]
        }
    ],
    "mrkl_tree" : [
        "e8016a2839fdc1e5627ee2e579e6961d75cda1da15e1f0355676e514214e7228"
    ]
}

The blockexplorer must have missed the chain split.

[theymos]

Thanks. That was the cause. I fixed the block.

Now I have to figure out how a reorg was missed...

[caveden]

I didn't follow... how did the block reorganization created a block with double-spending?

[Steve]

I didn't follow... how did the block reorganization created a block with double-spending?

If I understand correctly, there was no block created with any double spending...there was a split in the block chain and there were actually two concurrent blocks (both having the same parent) that had a number of the same transactions in them.  The split corrected itself as it is designed to do, but blockexplorer was showing both of the blocks (probably a bug in blockexplorer, not bitcoin).

[theymos]

Yeah, it was a problem with Bitcoin Block Explorer. Some blocks were not updated after a very large chain split (~8 blocks), which made the block chain wrong.

The large split was detected:

Code:

Tue, 12 Apr 2011 07:04:07 +0000

Starting block update: 13371 to 13377

BLOCK
Num: 13371$
Hash: 000000000c8b1c402c31fa803084aedf8b20d2f3f757bb3d6c47e42426516e2e$
Prev: 00000000111f7c4035234f6406c97a2983188fb5d7eb99b3d3a36e8daf5faf8b$
Root: 705d451e642b051ba98c132555ae84521436824b1dc68deb3e3fa4ae2f6d19d7$
Bits: 471724584$
Nonce: 762625496$
Timestamp: 1302591425$
Size: 215$
***Deleting conflicting block***INPUT
Type: Generation$
Value: 50$
Prev: $
TxHash: 705d451e642b051ba98c132555ae84521436824b1dc68deb3e3fa4ae2f6d19d7$
Index: $
ScriptSig: 0428f21d1c0104$
Hash160: $
OUTPUT
Hash160: c418e6c01bd8a9956af410c68297b37c8d1acb02$
Type: Pubkey$
Index: 0$
Value: 50.00000000$
Scriptpubkey: 0446fa90919dfe5305beb9a741bbc05f2864a72692822c147eb8e754c8211af2e0
7f9d2b5974c72140313d3162721d5e9c0854820c28ac4c7ee3c485bbdae2e4e6 OP_CHECKSIG$
Total value: 50.00000000$
Transactions: 1$
Error: Updating blocks too far back

BBE should have then turned itself off to prevent further damage. However, I haven't yet set up a system where only testnet can turn off, and previously testnet would take down mainnet, so I made testnet incapable of turning itself off. So it kept updating:

Code:

Tue, 12 Apr 2011 07:06:07 +0000

Starting block update: 13371 to 13378

BLOCK
Num: 13371$
Hash: 000000000c8b1c402c31fa803084aedf8b20d2f3f757bb3d6c47e42426516e2e$
Prev: 00000000111f7c4035234f6406c97a2983188fb5d7eb99b3d3a36e8daf5faf8b$
Root: 705d451e642b051ba98c132555ae84521436824b1dc68deb3e3fa4ae2f6d19d7$
Bits: 471724584$
Nonce: 762625496$
Timestamp: 1302591425$
Size: 215$
Already have this block
BLOCK
Num: 13372$
Hash: 00000000001212c841a0fe178666bb0f03cb16eda2d6cdc5917acbda01831f50$
Prev: 000000000c8b1c402c31fa803084aedf8b20d2f3f757bb3d6c47e42426516e2e$
Root: bf99ed83ed2f89f6e9d730f68c3f8d752f952422515e2a8c1daad2faf9551832$
Bits: 471724584$
Nonce: 2981433388$
Timestamp: 1302591435$
Size: 215$
***Deleting conflicting block***INPUT
Type: Generation$
Value: 50$
Prev: $
TxHash: bf99ed83ed2f89f6e9d730f68c3f8d752f952422515e2a8c1daad2faf9551832$
Index: $
ScriptSig: 0428f21d1c0108$
Hash160: $
OUTPUT
Hash160: a096f906cb7c73f5dabd57593ae7c3cc9ccae87b$
Type: Pubkey$
Index: 0$
Value: 50.00000000$
Scriptpubkey: 0480dad04b64362bd1217a5a812451963569e758c5084b2347aec9e1d85fc73b1d
e1f3f5bc784348a04f95b6b5afe6ac1438d06ce5e6b698fe39645fbb10c158ec OP_CHECKSIG$
...

A few blocks before 13371 were then wrong, but the later blocks were still being updated. This resulted in a block containing transactions that had previously appeared in the now-orphan blocks. These appeared to be duplicates to BBE, but they actually weren't.

The massive fee amount made me think it was a real exploit rather than just a BBE processing error, and this was corroborated by my analysis of BBE rawblock data, which was obviously also wrong.

Testnet now looks back 10 blocks, which should make this more rare. I've also been planning a more elegant update control system that will allow testnet to turn itself off without taking down mainnet.

[bitcoinex]

Incident like that will cause a transactional fee? As described in this topic.