📅 Original date posted:2012-03-01
📝 Original message:>I am not following you here, can you explain what you're thinking?
If I mine a duplicate coinbase of an old block (whether spent or not)
if that block is then invalidated DisconnectBlock() will erase both
the coinbase of the new block and of the old block. This leaves the
blockchain is in an inconsistent state because with the coinbase
missing the old block will no longer pass CheckBlock().
When affected clients are restarted LoadBlockIndex() will try and
verify all blocks in the main chain, failing at the block with the
missing coinbase.
1) If an attacker was to do this with an early block it would force
all affected clients to redownload the majority of the blockchain.
2) If the attacker was able to do this on a block after the March 1st
deadline (future block A). If they mined a fake copy of block A (block
B) with the same coinbase but a different hash clients who received
block B before block A will refuse to accept block A because of the
unspent duplicate coinbase in block B. The attacker can then fork the
chain at this point despite the real chain being longer.
I am just think out load here so I could be wrong, but maybe it would
be better to go for the full block height fix now?
On Thu, Mar 1, 2012 at 2:27 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves <support at pi.uk.com> wrote:
>> One more thing to add. The implementation in the reference patch fixes
>> the blockchain forking issue however by still allowing spent coinbases
>> to be disconnected patched clients are still vulnerable to blockchain
>> corruption. While not an immediate issue it would mean
>> LoadBlockIndex() would error on restart and could cause problems for
>> new clients during the initial blockchain download.
>
> I am not following you here, can you explain what you're thinking?
>
>> Is there a reason not to disallow duplicate coinbases entirely?
>
> Because this would make it impossible for nodes to prune the vaules.
> They'd all forever have to keep a set of all the coinbase hashes in
> order to perform the test. The height-in-coinbase BIP will make
> duplicates effectively impossible to create, which is a much more
> clean behavior.
Ben Reeves [ARCHIVE] /
npub1t2…pvrwu
2023-06-07 03:10:47
in reply to nevent1q…2km3
Author Public Key
npub1t26xr0r383eh8xkmc4pluqs42wkqyml33eszv7sfn829llwr49psfpvrwuPublished at
2023-06-07 03:10:47Event JSON
{
"id": "a486b252a644a550457b9905d7dc5b7350941510c73c5fc5d98072f0362f88c9",
"pubkey": "5ab461bc713c73739adbc543fe021553ac026ff18e60267a0999d45ffdc3a943",
"created_at": 1686107447,
"kind": 1,
"tags": [
[
"e",
"8d0fea15cf3bf2dd4fc4c205df6cc3e36626b119cb7ed7093b876376c9879239",
"",
"root"
],
[
"e",
"fdefd8ef8d4d2b01087710899487523212c577dc206fc9bd902e081137da8499",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2012-03-01\n📝 Original message:\u003eI am not following you here, can you explain what you're thinking?\n\nIf I mine a duplicate coinbase of an old block (whether spent or not)\nif that block is then invalidated DisconnectBlock() will erase both\nthe coinbase of the new block and of the old block. This leaves the\nblockchain is in an inconsistent state because with the coinbase\nmissing the old block will no longer pass CheckBlock().\n\nWhen affected clients are restarted LoadBlockIndex() will try and\nverify all blocks in the main chain, failing at the block with the\nmissing coinbase.\n\n1) If an attacker was to do this with an early block it would force\nall affected clients to redownload the majority of the blockchain.\n2) If the attacker was able to do this on a block after the March 1st\ndeadline (future block A). If they mined a fake copy of block A (block\nB) with the same coinbase but a different hash clients who received\nblock B before block A will refuse to accept block A because of the\nunspent duplicate coinbase in block B. The attacker can then fork the\nchain at this point despite the real chain being longer.\n\nI am just think out load here so I could be wrong, but maybe it would\nbe better to go for the full block height fix now?\n\nOn Thu, Mar 1, 2012 at 2:27 PM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\u003e On Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves \u003csupport at pi.uk.com\u003e wrote:\n\u003e\u003e One more thing to add. The implementation in the reference patch fixes\n\u003e\u003e the blockchain forking issue however by still allowing spent coinbases\n\u003e\u003e to be disconnected patched clients are still vulnerable to blockchain\n\u003e\u003e corruption. While not an immediate issue it would mean\n\u003e\u003e LoadBlockIndex() would error on restart and could cause problems for\n\u003e\u003e new clients during the initial blockchain download.\n\u003e\n\u003e I am not following you here, can you explain what you're thinking?\n\u003e\n\u003e\u003e Is there a reason not to disallow duplicate coinbases entirely?\n\u003e\n\u003e Because this would make it impossible for nodes to prune the vaules.\n\u003e They'd all forever have to keep a set of all the coinbase hashes in\n\u003e order to perform the test. The height-in-coinbase BIP will make\n\u003e duplicates effectively impossible to create, which is a much more\n\u003e clean behavior.",
"sig": "f3af75390109308297a43bf3433183b6e5337c931ec012e32c39e55b7694c53e7ac217b6b472ffcd56098679cbe3a0482186aff46025af2882cd52b38a943eda"
}