Topic: same mrkl hash value in two differnt blocks (Read 1968 times)
Why does this matter? Wouldnt the previous block hash still be different?
If you consider that both of these blocks contain the exact same single transaction - which is "Give the newly created 50 BTC to address xxxx" it seems completely plausible that these can be duplicates.
I guess what that means is each address can only be used for mining once (at least when the amounts are identical).
I guess what that means is each address can only be used for mining once (at least when the amounts are identical).
The block contained a transaction of 20BTC too. The problem is that all the transactions were identical. I'm not savvy with this but if the miner indeed hashed a fresh block with the same transactions in it, it seems he simply included the 20BTC transaction on his own, instead of creating a new tx from the API. Don't quote me on this but I presume the API would have provided the tx with a new hash, which his included tx didn't have, and the problem would have been avoided.
If you consider that both of these blocks contain the exact same single transaction - which is "Give the newly created 50 BTC to address xxxx" it seems completely plausible that these can be duplicates.
I guess what that means is each address can only be used for mining once (at least when the amounts are identical).
I guess what that means is each address can only be used for mining once (at least when the amounts are identical).
See this thread for previous discussion on the topic:
http://forum.bitcoin.org/index.php?topic=1814.0
http://forum.bitcoin.org/index.php?topic=1814.0
Ooh! Ooh! 50 more bitcoins for the "Bitcoins Lost Forever" thread!
Does that mean if I post a btc address you'll send me 50btc? ;-)
I found it while establishing the block chain in a normalized db. Where I thought hash values shouldn't (unless collision) be used twice they were given a unique index.
This leads me to my next question. How strong is the input sanitizing of the block protocol in the bitcoind application? or another way to ask is, more specifically how did this happen?
Thanks for your time.
Ooh! Ooh! 50 more bitcoins for the "Bitcoins Lost Forever" thread!
From my understanding this isn't a case of hash collision, both blocks were mined with exactly the same transactions list. This is why the Merkle root is identical.
This may show my ignorance but mrkl hash --> d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
Is found in block 91842 and 91812
I guess it's not clear to me exactly how the mrkl tree works, but I was under the impression that provided there wasn't a collision that these values would not be repeated.
When you look up block 91812 on block explorer you find this:
This transaction is an exact copy of http://blockexplorer.com/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599 This is usually caused by flawed custom miner code that rarely changes the keys used by generations, and is therefore likely to produce a generation transaction with the exact same data as a previous one by the same person. The network sees duplicate transactions as the same: only one can be redeemed.
Is found in block 91842 and 91812
I guess it's not clear to me exactly how the mrkl tree works, but I was under the impression that provided there wasn't a collision that these values would not be repeated.
When you look up block 91812 on block explorer you find this:
This transaction is an exact copy of http://blockexplorer.com/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599 This is usually caused by flawed custom miner code that rarely changes the keys used by generations, and is therefore likely to produce a generation transaction with the exact same data as a previous one by the same person. The network sees duplicate transactions as the same: only one can be redeemed.
Jump to: