📅 Original date posted:2021-03-02
📝 Original message:It is wrong to say that using miner signalling alone for activation
(LOT=false) is a bug.
As we vividly saw in the events of the 2017 UASF, the purpose of miner
signalling isn't to activate or enforce the new rules but to stop a
chain split. A majority of miners can stop a chain split by essentially
doing a 51% attack. Such attacks have been known about since day one,
and even the whitepaper writes about them.
So they are not a bug but an inherent part of the way bitcoin works. If
fixing this issue was a simple as setting a consensus rule parameter
then bitcoin would have been invented decades earlier than it was.
And certainly miner signalling cannot be compared to an inflation bug.
The inflation rules are enforced by the economy using full nodes, but
chain splits or lack of them is enforced by miners. They are two
different parts of the bitcoin system. Back in 2010 there was an
inflation bug CVE-2010-5139 (the "Value overflow incident") which proves
my point. Even though miners created a block which printed 184 billion
bitcoins, the economy quickly adopted a patch which fixed the bug and
miners switched over to the correct chain which soon overtook the bugged
chain (there was a reorg of 53 blocks).
Also another point: in a hypothetical chain split it's true that the
LOT=false chain would be vulnerable to reorgs, but it's also true that
the LOT=true would suffer from slow blocks.
So for example, imagine trading bitcoin for cash in person, but instead
of waiting on average 10 minutes for a confirmation you have to wait 2
hours. Imagine depositing coins to an exchange which requires 3
confirmation, then instead of waiting ~30 minutes you have to actually
wait 6 hours. This is a significant degradation in usability. The
situation is a mirror image of how the LOT=false chain is vulnerable to
reorgs. Both chains suffer if a chain split happens which is why they
are pretty important to avoid. That's why its inaccurate to portray
LOT=true chain as safe with no downsides at all.
On 28/02/2021 19:33, Luke Dashjr via bitcoin-dev wrote:
> (Note: I am writing this as a general case against LOT=False, but using
> Taproot simply as an example softfork. Note that this is addressing
> activation under the assumption that the softfork is ethical and has
> sufficient community support. If those criteria have not been met, no
> activation should be deployed at all, of any type.)
>
> As we saw in 2017 with BIP 9, coordinating activation by miner signal alone,
> despite its potential benefits, also leaves open the door to a miner veto.
> This was never the intended behaviour, and a bug, which took a rushed
> deployment of BIP148 to address. LOT=False would reintroduce that same bug.
> It wouldn't be much different than adding back the inflation bug
> (CVE-2018-17144) and trusting miners not to exploit it.
>
> Some have tried to spin LOT=True as some kind of punishment for miners or
> reactive "counter-attack". Rather, it is simply a fallback to avoid
> regression on this and other bugs. "Flag day" activation is not fundamentally
> flawed or dangerous, just slow since everyone needs time to upgrade.
> BIP 8(LOT=True) combines the certainty of such a flag day, with the speed
> improvement of a MASF, so that softforks can be activated both reasonably
> quick and safely.
>
> In the normal path, and that which BIP8(True) best incentivises, miners will
> simply upgrade and signal, and activation can occur as soon as the economic
> majority is expected to have had time to upgrade. In the worst-case path, the
> behaviour of LOT=True is the least-harmful result: unambiguous activation and
> enforcement by the economy, with miners either deciding to make an
> anti-Taproot(eg) altcoin, or continue mining Bitcoin. Even if ALL the miners
> revolt against the softfork, the LOT=True nodes are simply faced with a
> choice to hardfork (replacing the miners with a PoW change) or concede - they
> do not risk vulnerability or loss.
>
> With LOT=False in the picture, however, things can get messy: some users will
> enforce Taproot(eg) (those running LOT=True), while others will not (those
> with LOT=False). Users with LOT=True will still get all the safety thereof,
> but those with LOT=False will (in the event of miners deciding to produce a
> chain split) face an unreliable chain, being replaced by the LOT=True chain
> every time it overtakes the LOT=False chain in work. For 2 weeks, users with
> LOT=False would not have a usable network. The only way to resolve this would
> be to upgrade to LOT=True or to produce a softfork that makes an activated
> chain invalid (thereby taking the anti-Taproot path). Even if nobody ran
> LOT=True (very unlikely), LOT=False would still fail because users would be
> faced with either accepting the loss of Taproot(eg), or re-deploying from
> scratch with LOT=True. It accomplishes nothing compared to just deploying
> LOT=True from the beginning. Furthermore, this process creates a lot of
> confusion for users ("Yep, I upgraded for Taproot(eg). Wait, you mean I have
> to do it AGAIN?"), and in some scenarios additional code may be needed to
> handle the subsequent upgrade cleanly.
>
> To make matters worse for LOT=False, giving miners a veto also creates an
> incentive to second-guess the decision to activate and/or hold the activation
> hostage. This is a direct result of the bug giving them a power they weren't
> intended to have. Even if we trust miners to act ethically, that does not
> justify sustaining the bug creating both a possibility and incentive to
> behave unethically.
>
> So in all possible scenarios, LOT=False puts users and the network at
> significant risk. In all possible scenarios, LOT=True minimises risk to
> everyone and has no risk to users running LOT=True.
>
> The overall risk is maximally reduced by LOT=True being the only deployed
> parameter, and any introduction of LOT=False only increases risk probability
> and severity.
>
> For all these reasons, I regret adding LOT as an option to BIP 8, and think it
> would be best to remove it entirely, with all deployments in the future
> behaving as LOT=True. I do also recognise that there is not yet consensus on
> this, and for that reason I have not taken action (nor intend to) to remove
> LOT from BIP 8. However, the fact remains that LOT=False should not be used,
> and it is best if every softfork is deployed with LOT=True.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Chris Belcher [ARCHIVE] /
npub1ek…lnm2u
2023-06-07 18:29:44
in reply to nevent1q…cu4q
Author Public Key
npub1ekvnqhww3aagwuj9t55dgj5y29u8cxdjllfv3vgppt8vc0zljhrs6lnm2uPublished at
2023-06-07 18:29:44Event JSON
{
"id": "de247edd07b845686a873f3c06d1e8d000bb701ffcb66dd6caae5906f80eebf6",
"pubkey": "cd99305dce8f7a8772455d28d44a8451787c19b2ffd2c8b1010acecc3c5f95c7",
"created_at": 1686162584,
"kind": 1,
"tags": [
[
"e",
"1efc5c024bb223fd42ab55a53ebe6d4c8ea7afd3c43372e51f1349e4a84772a1",
"",
"root"
],
[
"e",
"d070dbf409b997bc0af2e178283ce11d9782fdd9dbcae352df81d25508de8305",
"",
"reply"
],
[
"p",
"ae6c94e362d5371da69e6dcb8be7e4d809fe071824f9f97324a351b7358b31b9"
]
],
"content": "📅 Original date posted:2021-03-02\n📝 Original message:It is wrong to say that using miner signalling alone for activation\n(LOT=false) is a bug.\n\nAs we vividly saw in the events of the 2017 UASF, the purpose of miner\nsignalling isn't to activate or enforce the new rules but to stop a\nchain split. A majority of miners can stop a chain split by essentially\ndoing a 51% attack. Such attacks have been known about since day one,\nand even the whitepaper writes about them.\n\nSo they are not a bug but an inherent part of the way bitcoin works. If\nfixing this issue was a simple as setting a consensus rule parameter\nthen bitcoin would have been invented decades earlier than it was.\n\nAnd certainly miner signalling cannot be compared to an inflation bug.\nThe inflation rules are enforced by the economy using full nodes, but\nchain splits or lack of them is enforced by miners. They are two\ndifferent parts of the bitcoin system. Back in 2010 there was an\ninflation bug CVE-2010-5139 (the \"Value overflow incident\") which proves\nmy point. Even though miners created a block which printed 184 billion\nbitcoins, the economy quickly adopted a patch which fixed the bug and\nminers switched over to the correct chain which soon overtook the bugged\nchain (there was a reorg of 53 blocks).\n\n\n\n\nAlso another point: in a hypothetical chain split it's true that the\nLOT=false chain would be vulnerable to reorgs, but it's also true that\nthe LOT=true would suffer from slow blocks.\n\nSo for example, imagine trading bitcoin for cash in person, but instead\nof waiting on average 10 minutes for a confirmation you have to wait 2\nhours. Imagine depositing coins to an exchange which requires 3\nconfirmation, then instead of waiting ~30 minutes you have to actually\nwait 6 hours. This is a significant degradation in usability. The\nsituation is a mirror image of how the LOT=false chain is vulnerable to\nreorgs. Both chains suffer if a chain split happens which is why they\nare pretty important to avoid. That's why its inaccurate to portray\nLOT=true chain as safe with no downsides at all.\n\n\n\n\nOn 28/02/2021 19:33, Luke Dashjr via bitcoin-dev wrote:\n\u003e (Note: I am writing this as a general case against LOT=False, but using \n\u003e Taproot simply as an example softfork. Note that this is addressing \n\u003e activation under the assumption that the softfork is ethical and has \n\u003e sufficient community support. If those criteria have not been met, no \n\u003e activation should be deployed at all, of any type.)\n\u003e \n\u003e As we saw in 2017 with BIP 9, coordinating activation by miner signal alone, \n\u003e despite its potential benefits, also leaves open the door to a miner veto. \n\u003e This was never the intended behaviour, and a bug, which took a rushed \n\u003e deployment of BIP148 to address. LOT=False would reintroduce that same bug.\n\u003e It wouldn't be much different than adding back the inflation bug \n\u003e (CVE-2018-17144) and trusting miners not to exploit it.\n\u003e \n\u003e Some have tried to spin LOT=True as some kind of punishment for miners or \n\u003e reactive \"counter-attack\". Rather, it is simply a fallback to avoid \n\u003e regression on this and other bugs. \"Flag day\" activation is not fundamentally \n\u003e flawed or dangerous, just slow since everyone needs time to upgrade.\n\u003e BIP 8(LOT=True) combines the certainty of such a flag day, with the speed \n\u003e improvement of a MASF, so that softforks can be activated both reasonably \n\u003e quick and safely.\n\u003e \n\u003e In the normal path, and that which BIP8(True) best incentivises, miners will \n\u003e simply upgrade and signal, and activation can occur as soon as the economic \n\u003e majority is expected to have had time to upgrade. In the worst-case path, the \n\u003e behaviour of LOT=True is the least-harmful result: unambiguous activation and \n\u003e enforcement by the economy, with miners either deciding to make an \n\u003e anti-Taproot(eg) altcoin, or continue mining Bitcoin. Even if ALL the miners \n\u003e revolt against the softfork, the LOT=True nodes are simply faced with a \n\u003e choice to hardfork (replacing the miners with a PoW change) or concede - they \n\u003e do not risk vulnerability or loss.\n\u003e \n\u003e With LOT=False in the picture, however, things can get messy: some users will \n\u003e enforce Taproot(eg) (those running LOT=True), while others will not (those \n\u003e with LOT=False). Users with LOT=True will still get all the safety thereof, \n\u003e but those with LOT=False will (in the event of miners deciding to produce a \n\u003e chain split) face an unreliable chain, being replaced by the LOT=True chain \n\u003e every time it overtakes the LOT=False chain in work. For 2 weeks, users with \n\u003e LOT=False would not have a usable network. The only way to resolve this would \n\u003e be to upgrade to LOT=True or to produce a softfork that makes an activated \n\u003e chain invalid (thereby taking the anti-Taproot path). Even if nobody ran \n\u003e LOT=True (very unlikely), LOT=False would still fail because users would be \n\u003e faced with either accepting the loss of Taproot(eg), or re-deploying from \n\u003e scratch with LOT=True. It accomplishes nothing compared to just deploying \n\u003e LOT=True from the beginning. Furthermore, this process creates a lot of \n\u003e confusion for users (\"Yep, I upgraded for Taproot(eg). Wait, you mean I have \n\u003e to do it AGAIN?\"), and in some scenarios additional code may be needed to \n\u003e handle the subsequent upgrade cleanly.\n\u003e \n\u003e To make matters worse for LOT=False, giving miners a veto also creates an \n\u003e incentive to second-guess the decision to activate and/or hold the activation \n\u003e hostage. This is a direct result of the bug giving them a power they weren't \n\u003e intended to have. Even if we trust miners to act ethically, that does not \n\u003e justify sustaining the bug creating both a possibility and incentive to \n\u003e behave unethically.\n\u003e \n\u003e So in all possible scenarios, LOT=False puts users and the network at \n\u003e significant risk. In all possible scenarios, LOT=True minimises risk to \n\u003e everyone and has no risk to users running LOT=True.\n\u003e \n\u003e The overall risk is maximally reduced by LOT=True being the only deployed \n\u003e parameter, and any introduction of LOT=False only increases risk probability \n\u003e and severity.\n\u003e \n\u003e For all these reasons, I regret adding LOT as an option to BIP 8, and think it \n\u003e would be best to remove it entirely, with all deployments in the future \n\u003e behaving as LOT=True. I do also recognise that there is not yet consensus on \n\u003e this, and for that reason I have not taken action (nor intend to) to remove \n\u003e LOT from BIP 8. However, the fact remains that LOT=False should not be used, \n\u003e and it is best if every softfork is deployed with LOT=True.\n\u003e \n\u003e Luke\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\n\u003e",
"sig": "629b3e78a9a6d47d1c8b3cadad82fe562f2044d6544267eb8b035915432c2dd45d4b72f5f03dd273ac61d8677f8cca21dca8f3d4ef3c6ca2d16cdad6754b9e53"
}