📅 Original date posted:2016-11-16
📝 Original message:I would suggest that, before discussing how best to fork the chain to meet this objective, we consider the objective.
The implementers have acknowledged that this does not represent a performance improvement. Especially given that this was apparently not initially understood, that alone is good reason for them to reconsider.
The remaining stated objective is reduction of code complexity. Let us be very clear, a proposal to change the protocol must be considered independently of any particular implementation of the protocol. While the implementation of BIP34 style activation may be hugely complex in the satoshi code, it is definitely not complex as a matter of necessity.
Activation constitutes maybe a dozen lines of additional code in libbitcoin. The need to hit the chain (or cache) to obtain historical header info will remain for proof of work, so this change doesn't even accomplish some sort of beneficial isolation from blockchain history.
So, at best, we are talking about various ways to introduce a consensus fork so that a well designed implementation can remove a tiny amount of already-written code and associated tests. In my opinion this is embarrassingly poor reasoning. It would be much more productive to reduce satoshi code complexity in ways that do not impact the protocol. There are a *huge* number of such opportunities, and in fact activation is one of them. Once that is done, we can talk about forking to reduce source code complexity.
These fork suggestions actually increase *necessary* complexity for any implantation that takes a rational approach to forks. By rational I mean *additive*. Deleting rules from Bitcoin code is simply bad design. Rules are never removed, they are added. A new rule to modify an old rule is simply a new rule. This is new and additional code. So please don't assume in this "proposal" that this makes development simpler for other implementations, that is not a necessary conclusion.
e
> On Nov 16, 2016, at 1:01 PM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Wed, Nov 16, 2016 at 09:32:24AM -0500, Alex Morcos via bitcoin-dev wrote:
>> I think we are misunderstanding the effect of this change.
>> It's still "OK" for a 50k re-org to happen.
>> We're just saying that if it does, we will now have potentially introduced
>> a hard fork between new client and old clients if the reorg contains
>> earlier signaling for the most recent ISM soft fork and then blocks which
>> do not conform to that soft fork before the block height encoded activation.
>>
>> I think the argument is this doesn't substantially add to the confusion or
>> usability of the system as its likely that old software won't even handle
>> 50k block reorgs cleanly anyway and there will clearly have to be human
>> coordination at the time of the event. In the unlikely event that the new
>> chain does cause such a hard fork, that coordination can result in everyone
>> upgrading to software that supports the new rules anyway.
>>
>> So no, I don't think we should add a checkpoint. I think we should all
>> just agree to a hard fork that only has a very very slim chance of any
>> practical effect.
>
> So, conceptually, another way to deal with this is to hardcode a blockhash
> where we allow blocks in a chain ending with that blockhash to _not_ follow
> BIP65, up until that blockhash, and any blockchain without that blockhash must
> respect BIP65 for all blocks in the chain.
>
> This is a softfork: we've only added rules that made otherwise valid chains
> invalid, and at the same time we are still accepting large reorgs (albeit under
> stricter rules than before).
>
> I'd suggest we call this a exemption hash - we've exempted a particular
> blockchains from a soft-forked rule that we would otherwise enforce.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 17:54:19
in reply to nevent1q…lflx
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cPublished at
2023-06-07 17:54:19Event JSON
{
"id": "5f57a6ce4341e39bad69a2f043650a474c30caeefe095711d982872e1da2e122",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686160459,
"kind": 1,
"tags": [
[
"e",
"50cde70d11f9c69cc787e52010ba0256918f920ad1f9811ad6566a1543ec1282",
"",
"root"
],
[
"e",
"296564c48e3d125eb1c04da08bc3992dc1875435b7f21be3b4a4d5ea4f2e984b",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2016-11-16\n📝 Original message:I would suggest that, before discussing how best to fork the chain to meet this objective, we consider the objective.\n\nThe implementers have acknowledged that this does not represent a performance improvement. Especially given that this was apparently not initially understood, that alone is good reason for them to reconsider.\n\nThe remaining stated objective is reduction of code complexity. Let us be very clear, a proposal to change the protocol must be considered independently of any particular implementation of the protocol. While the implementation of BIP34 style activation may be hugely complex in the satoshi code, it is definitely not complex as a matter of necessity.\n\nActivation constitutes maybe a dozen lines of additional code in libbitcoin. The need to hit the chain (or cache) to obtain historical header info will remain for proof of work, so this change doesn't even accomplish some sort of beneficial isolation from blockchain history.\n\nSo, at best, we are talking about various ways to introduce a consensus fork so that a well designed implementation can remove a tiny amount of already-written code and associated tests. In my opinion this is embarrassingly poor reasoning. It would be much more productive to reduce satoshi code complexity in ways that do not impact the protocol. There are a *huge* number of such opportunities, and in fact activation is one of them. Once that is done, we can talk about forking to reduce source code complexity.\n\nThese fork suggestions actually increase *necessary* complexity for any implantation that takes a rational approach to forks. By rational I mean *additive*. Deleting rules from Bitcoin code is simply bad design. Rules are never removed, they are added. A new rule to modify an old rule is simply a new rule. This is new and additional code. So please don't assume in this \"proposal\" that this makes development simpler for other implementations, that is not a necessary conclusion.\n\ne\n\n\u003e On Nov 16, 2016, at 1:01 PM, Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e\u003e On Wed, Nov 16, 2016 at 09:32:24AM -0500, Alex Morcos via bitcoin-dev wrote:\n\u003e\u003e I think we are misunderstanding the effect of this change.\n\u003e\u003e It's still \"OK\" for a 50k re-org to happen.\n\u003e\u003e We're just saying that if it does, we will now have potentially introduced\n\u003e\u003e a hard fork between new client and old clients if the reorg contains\n\u003e\u003e earlier signaling for the most recent ISM soft fork and then blocks which\n\u003e\u003e do not conform to that soft fork before the block height encoded activation.\n\u003e\u003e \n\u003e\u003e I think the argument is this doesn't substantially add to the confusion or\n\u003e\u003e usability of the system as its likely that old software won't even handle\n\u003e\u003e 50k block reorgs cleanly anyway and there will clearly have to be human\n\u003e\u003e coordination at the time of the event. In the unlikely event that the new\n\u003e\u003e chain does cause such a hard fork, that coordination can result in everyone\n\u003e\u003e upgrading to software that supports the new rules anyway.\n\u003e\u003e \n\u003e\u003e So no, I don't think we should add a checkpoint. I think we should all\n\u003e\u003e just agree to a hard fork that only has a very very slim chance of any\n\u003e\u003e practical effect.\n\u003e \n\u003e So, conceptually, another way to deal with this is to hardcode a blockhash\n\u003e where we allow blocks in a chain ending with that blockhash to _not_ follow\n\u003e BIP65, up until that blockhash, and any blockchain without that blockhash must\n\u003e respect BIP65 for all blocks in the chain.\n\u003e \n\u003e This is a softfork: we've only added rules that made otherwise valid chains\n\u003e invalid, and at the same time we are still accepting large reorgs (albeit under\n\u003e stricter rules than before).\n\u003e \n\u003e I'd suggest we call this a exemption hash - we've exempted a particular\n\u003e blockchains from a soft-forked rule that we would otherwise enforce.\n\u003e \n\u003e -- \n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "159425db04d7f047802f495a5e865d588e160554139fc2126badeb7765b4dca3c3069d7eb3fbfe2685d88385111b9b3958e23ffa9e3d40a9fa38d74615f3d461"
}