"out":[
{
"value":"1.00000000",
"scriptPubKey":"OP_DUP OP_HASH160 ad4c20d5b1956015ea626f02afdaebe8ed17e1a8 OP_EQUALVERIFY OP_CHECKSIG"[/b]
},
{
"value":"1.00000000",
"scriptPubKey":"OP_DUP OP_HASH160 ad4c20d5b1956015ea626f02afdaebe8ed17e1a8 OP_EQUALVERIFY OP_CHECKSIG"[/b]
}
]
}
Constructing a transaction like this is:
1. Either identical to sending the destination 2 BTC, in that clients consider the transaction to be adding 2BTC to the balance as one output (Bitcoin can't differentiate which output of these two might later have been spent, because they are identical with an identical transaction hash),
or
2. A good way to lose half your money because Bitcoin can't differentiate between which output of these two might later have been spent, because they are identical with an identical transaction hash.
https://en.bitcoin.it/wiki/BIP_0030So far, the Bitcoin reference implementation always assumed duplicate transactions (transactions with the same identifier) didn't exist.
No, you are confusing transactions with outputs. Transaction with duplicate hashes are no longer allowed, but duplicate outputs are. The reason is that the transaction hash is the sole transaction identifier, while an output is identified by both the transaction hash and the output sequence number. In this case, even though the transaction has two identical outputs, one is named
.0 and the other is named
.1.
In normal operation, the reference client hides the coin details from the user, and will present it to the user as a 2 BTC payment. But behind the scenes, it knows that there are two outputs there and will act correctly, fully capable of redeeming and spending them one at a time.