📅 Original date posted:2012-03-01
📝 Original message: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.
Is there a reason not to disallow duplicate coinbases entirely?
On Thu, Mar 1, 2012 at 10:15 AM, Ben Reeves <support at pi.uk.com> wrote:
> Yes you are right. Any fix in DisconnectBlock() has the same potential issues.
>
> I think the exchanges and major merchants need to be made aware that
> they must also upgrade. Maybe bundle both BIP16 and BIP30 in 0.6 and
> issue an advisory stating that this is a mandatory upgrade for
> everyone.
>
> It also might be prudent to have a blockchain repair script ready,
> which checks the db for missing coinbase transactions and downloads
> them from another peer or block explorer if necessary.
>
> Thank You,
> Ben Reeves
> www.blockchain.info
>
> On Wed, Feb 29, 2012 at 11:45 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
>> On Wed, Feb 29, 2012 at 11:00:42PM +0000, Ben Reeves wrote:
>>> I'm not sure. What if they use a coinbase of a block that has already matured?
>>
>> Indeed; duplicate an old coinbase, fork chain without dupe, and spend the old coinbase.
>> The 100-blocks maturity will not help against is.
>>
>> I'm not sure how you intend to fix DisconnectBlock() to prevent this in a backward-
>> compatible way, though.
>>
>> --
>> Pieter
Ben Reeves [ARCHIVE] /
npub1t2…pvrwu
2023-06-07 03:10:41
in reply to nevent1q…p5ds
Author Public Key
npub1t26xr0r383eh8xkmc4pluqs42wkqyml33eszv7sfn829llwr49psfpvrwuPublished at
2023-06-07 03:10:41Event JSON
{
"id": "0c202c1b6e011dcfe9ca8aca636f49f10b7c19cb3d432b3d67adebf273c4bc65",
"pubkey": "5ab461bc713c73739adbc543fe021553ac026ff18e60267a0999d45ffdc3a943",
"created_at": 1686107441,
"kind": 1,
"tags": [
[
"e",
"8d0fea15cf3bf2dd4fc4c205df6cc3e36626b119cb7ed7093b876376c9879239",
"",
"root"
],
[
"e",
"79db99bbcbbfe345667010eb8be747c5b40e50f5f003da2672214dd5066c80cc",
"",
"reply"
],
[
"p",
"5ab461bc713c73739adbc543fe021553ac026ff18e60267a0999d45ffdc3a943"
]
],
"content": "📅 Original date posted:2012-03-01\n📝 Original message:One more thing to add. The implementation in the reference patch fixes\nthe blockchain forking issue however by still allowing spent coinbases\nto be disconnected patched clients are still vulnerable to blockchain\ncorruption. While not an immediate issue it would mean\nLoadBlockIndex() would error on restart and could cause problems for\nnew clients during the initial blockchain download.\n\nIs there a reason not to disallow duplicate coinbases entirely?\n\nOn Thu, Mar 1, 2012 at 10:15 AM, Ben Reeves \u003csupport at pi.uk.com\u003e wrote:\n\u003e Yes you are right. Any fix in DisconnectBlock() has the same potential issues.\n\u003e\n\u003e I think the exchanges and major merchants need to be made aware that\n\u003e they must also upgrade. Maybe bundle both BIP16 and BIP30 in 0.6 and\n\u003e issue an advisory stating that this is a mandatory upgrade for\n\u003e everyone.\n\u003e\n\u003e It also might be prudent to have a blockchain repair script ready,\n\u003e which checks the db for missing coinbase transactions and downloads\n\u003e them from another peer or block explorer if necessary.\n\u003e\n\u003e Thank You,\n\u003e Ben Reeves\n\u003e www.blockchain.info\n\u003e\n\u003e On Wed, Feb 29, 2012 at 11:45 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e wrote:\n\u003e\u003e On Wed, Feb 29, 2012 at 11:00:42PM +0000, Ben Reeves wrote:\n\u003e\u003e\u003e I'm not sure. What if they use a coinbase of a block that has already matured?\n\u003e\u003e\n\u003e\u003e Indeed; duplicate an old coinbase, fork chain without dupe, and spend the old coinbase.\n\u003e\u003e The 100-blocks maturity will not help against is.\n\u003e\u003e\n\u003e\u003e I'm not sure how you intend to fix DisconnectBlock() to prevent this in a backward-\n\u003e\u003e compatible way, though.\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e Pieter",
"sig": "44bef63711ee76b773b2e1a71d1e4a13dc74c12c563ffe44d0039e88228a954cdcb5cc80faeb583a1608cc1586765a706d92903ee96464add2e3009d4ceea0c7"
}