[bitcoin-dev] LOT=False is dangerous and shouldn't be used

[bitcoin-dev] LOT=False is dangerous and shouldn't be used

[Luke Dashjr]

(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

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[Anthony Towns]

On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev wrote:
> 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. 

To the contrary, we saw in 2017 that miners could *not* successfully
veto a BIP 9 activation. It was certainly more effort and risk than was
desirable to override the attempted veto, but the attempt at vetoing
nevertheless failed.

> It wouldn't be much different than adding back the inflation bug 
> (CVE-2018-17144) and trusting miners not to exploit it.

That is ridiculous FUD.

> With LOT=False in the picture, however, things can get messy:

LOT=false is always in the picture if we are talking about a soft-fork:
the defining feature of a soft-fork is that old node software continues
to work, and old node software will be entirely indifferent to whether
activation is signalled or not.

> some users will 
> enforce Taproot(eg) (those running LOT=True), while others will not (those 
> with LOT=False)

If you are following bip8 with lockinontimeout=false, you will enforce
taproot rules if activation occurs, you will simply not reject blocks if
activation does not occur.

> 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.

This assumes anyone mining the chain where taproot does not activate is
not able to avoid a reorg, despite having majority hashpower (as implied
by the lot=true chain having to overtake them repeatedly). That's absurd;
avoiding a reorg is trivially achieved via running "invalidateblock", or
via pool software examining block headers, or via a patch along the lines
of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
here's a sketch of such a patch:

https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f

> For 2 weeks, users with LOT=False would not have a usable network.

That's also ridiculous FUD.

If it were true, it would mean the activation mechanism was not
acceptable, as non-upgraded nodes would also not have a usable network
for the same reason.

Fortunately, it's not true.

More generally, if miners are willing to lose significant amounts of
money mining orphan blocks, they can do that at any time. If they're
not inclined to do so, it's incredibly straightforward for them to avoid
doing so, whatever a minority of other miners might do.

> 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.

LOT=false is the default behaviour of everything single piece of node
software out there. That behaviour doesn't need to be introduced, it's
already universal.

Cheers,
aj

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[yanmaani]

How about a compromise?

With LOT=false, taproot will be activated if at least 95% of the miners 
vote yes.
With LOT=true, taproot will be activated if at least 0% of the miners 
vote yes.
...with LOT=maybe, taproot will be activated if at least ~some% of the 
miners vote yes?

If you want the 'emergency cancel' feature without binding yourself to 
it, couldn't you have some middle-of-the-road solution? "Taproot will be 
enabled if miner support ever goes above 95%, or on flag day if miner 
support is >20% then". That would prevent obstreperous miners from doing 
too much damage, while still hopefully making it possible to bail out of 
a disaster.

On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:
> On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev 
> wrote:
>> 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.
> 
> To the contrary, we saw in 2017 that miners could *not* successfully
> veto a BIP 9 activation. It was certainly more effort and risk than was
> desirable to override the attempted veto, but the attempt at vetoing
> nevertheless failed.
> 
>> It wouldn't be much different than adding back the inflation bug
>> (CVE-2018-17144) and trusting miners not to exploit it.
> 
> That is ridiculous FUD.
> 
>> With LOT=False in the picture, however, things can get messy:
> 
> LOT=false is always in the picture if we are talking about a soft-fork:
> the defining feature of a soft-fork is that old node software continues
> to work, and old node software will be entirely indifferent to whether
> activation is signalled or not.
> 
>> some users will
>> enforce Taproot(eg) (those running LOT=True), while others will not 
>> (those
>> with LOT=False)
> 
> If you are following bip8 with lockinontimeout=false, you will enforce
> taproot rules if activation occurs, you will simply not reject blocks 
> if
> activation does not occur.
> 
>> 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.
> 
> This assumes anyone mining the chain where taproot does not activate is
> not able to avoid a reorg, despite having majority hashpower (as 
> implied
> by the lot=true chain having to overtake them repeatedly). That's 
> absurd;
> avoiding a reorg is trivially achieved via running "invalidateblock", 
> or
> via pool software examining block headers, or via a patch along the 
> lines
> of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
> here's a sketch of such a patch:
> 
> https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f
> 
>> For 2 weeks, users with LOT=False would not have a usable network.
> 
> That's also ridiculous FUD.
> 
> If it were true, it would mean the activation mechanism was not
> acceptable, as non-upgraded nodes would also not have a usable network
> for the same reason.
> 
> Fortunately, it's not true.
> 
> More generally, if miners are willing to lose significant amounts of
> money mining orphan blocks, they can do that at any time. If they're
> not inclined to do so, it's incredibly straightforward for them to 
> avoid
> doing so, whatever a minority of other miners might do.
> 
>> 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.
> 
> LOT=false is the default behaviour of everything single piece of node
> software out there. That behaviour doesn't need to be introduced, it's
> already universal.
> 
> Cheers,
> aj
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 4714 bytes --]

This is the declining percentage of signaling activation.

It has all the benefits of both.

Eventually it becomes a LOT=true, so any argument for LOT=true holds

And all of the arguments for LOT=false are satisfied by the cool down
period.



On Mon, Mar 1, 2021, 12:05 PM yanmaani--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> How about a compromise?
>
> With LOT=false, taproot will be activated if at least 95% of the miners
> vote yes.
> With LOT=true, taproot will be activated if at least 0% of the miners
> vote yes.
> ...with LOT=maybe, taproot will be activated if at least ~some% of the
> miners vote yes?
>
> If you want the 'emergency cancel' feature without binding yourself to
> it, couldn't you have some middle-of-the-road solution? "Taproot will be
> enabled if miner support ever goes above 95%, or on flag day if miner
> support is >20% then". That would prevent obstreperous miners from doing
> too much damage, while still hopefully making it possible to bail out of
> a disaster.
>
> On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:
> > On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev
> > wrote:
> >> 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.
> >
> > To the contrary, we saw in 2017 that miners could *not* successfully
> > veto a BIP 9 activation. It was certainly more effort and risk than was
> > desirable to override the attempted veto, but the attempt at vetoing
> > nevertheless failed.
> >
> >> It wouldn't be much different than adding back the inflation bug
> >> (CVE-2018-17144) and trusting miners not to exploit it.
> >
> > That is ridiculous FUD.
> >
> >> With LOT=False in the picture, however, things can get messy:
> >
> > LOT=false is always in the picture if we are talking about a soft-fork:
> > the defining feature of a soft-fork is that old node software continues
> > to work, and old node software will be entirely indifferent to whether
> > activation is signalled or not.
> >
> >> some users will
> >> enforce Taproot(eg) (those running LOT=True), while others will not
> >> (those
> >> with LOT=False)
> >
> > If you are following bip8 with lockinontimeout=false, you will enforce
> > taproot rules if activation occurs, you will simply not reject blocks
> > if
> > activation does not occur.
> >
> >> 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.
> >
> > This assumes anyone mining the chain where taproot does not activate is
> > not able to avoid a reorg, despite having majority hashpower (as
> > implied
> > by the lot=true chain having to overtake them repeatedly). That's
> > absurd;
> > avoiding a reorg is trivially achieved via running "invalidateblock",
> > or
> > via pool software examining block headers, or via a patch along the
> > lines
> > of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
> > here's a sketch of such a patch:
> >
> >
> https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f
> >
> >> For 2 weeks, users with LOT=False would not have a usable network.
> >
> > That's also ridiculous FUD.
> >
> > If it were true, it would mean the activation mechanism was not
> > acceptable, as non-upgraded nodes would also not have a usable network
> > for the same reason.
> >
> > Fortunately, it's not true.
> >
> > More generally, if miners are willing to lose significant amounts of
> > money mining orphan blocks, they can do that at any time. If they're
> > not inclined to do so, it's incredibly straightforward for them to
> > avoid
> > doing so, whatever a minority of other miners might do.
> >
> >> 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.
> >
> > LOT=false is the default behaviour of everything single piece of node
> > software out there. That behaviour doesn't need to be introduced, it's
> > already universal.
> >
> > Cheers,
> > aj
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6520 bytes --]

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[yanmaani]

No, it's not the same. This approach is not guaranteed to activate. On 
flag day, it'd check for (say) 20% miner support, and activate if so. If 
 >80% of miners oppose, it'd fail. LOT=true (and declining percentage) will activate unconditionally.

Also, the day before lock-in, this would still have 95% as the limit, 
not a linear interpolation between 95% and the lock-in limit.

This checks: if miner support > 95% support it (ever) or miner support > 
X% (on flag day), activate
DP checks: if miner support > lerp(95%, 0%) (ever), activate
LOT=true checks: on flag day, activate unconditionally

(Erik: I forgot to hit reply all on my last e-mail, that's why you're 
seeing this twice)

On 2021-03-02 06:11, Erik Aronesty wrote:
> This is the declining percentage of signaling activation.
> 
> It has all the benefits of both.
> 
> Eventually it becomes a LOT=true, so any argument for LOT=true holds
> 
> And all of the arguments for LOT=false are satisfied by the cool down
> period.
> 
> On Mon, Mar 1, 2021, 12:05 PM yanmaani--- via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> How about a compromise?
>> 
>> With LOT=false, taproot will be activated if at least 95% of the
>> miners
>> vote yes.
>> With LOT=true, taproot will be activated if at least 0% of the
>> miners
>> vote yes.
>> ...with LOT=maybe, taproot will be activated if at least ~some% of
>> the
>> miners vote yes?
>> 
>> If you want the 'emergency cancel' feature without binding yourself
>> to
>> it, couldn't you have some middle-of-the-road solution? "Taproot
>> will be
>> enabled if miner support ever goes above 95%, or on flag day if
>> miner
>> support is >20% then". That would prevent obstreperous miners from
>> doing
>> too much damage, while still hopefully making it possible to bail
>> out of
>> a disaster.
>> 
>> On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:
>>> On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via
>> bitcoin-dev
>>> wrote:
>>>> 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.
>>> 
>>> To the contrary, we saw in 2017 that miners could *not*
>> successfully
>>> veto a BIP 9 activation. It was certainly more effort and risk
>> than was
>>> desirable to override the attempted veto, but the attempt at
>> vetoing
>>> nevertheless failed.
>>> 
>>>> It wouldn't be much different than adding back the inflation bug
>>>> (CVE-2018-17144) and trusting miners not to exploit it.
>>> 
>>> That is ridiculous FUD.
>>> 
>>>> With LOT=False in the picture, however, things can get messy:
>>> 
>>> LOT=false is always in the picture if we are talking about a
>> soft-fork:
>>> the defining feature of a soft-fork is that old node software
>> continues
>>> to work, and old node software will be entirely indifferent to
>> whether
>>> activation is signalled or not.
>>> 
>>>> some users will
>>>> enforce Taproot(eg) (those running LOT=True), while others will
>> not
>>>> (those
>>>> with LOT=False)
>>> 
>>> If you are following bip8 with lockinontimeout=false, you will
>> enforce
>>> taproot rules if activation occurs, you will simply not reject
>> blocks
>>> if
>>> activation does not occur.
>>> 
>>>> 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.
>>> 
>>> This assumes anyone mining the chain where taproot does not
>> activate is
>>> not able to avoid a reorg, despite having majority hashpower (as
>>> implied
>>> by the lot=true chain having to overtake them repeatedly). That's
>>> absurd;
>>> avoiding a reorg is trivially achieved via running
>> "invalidateblock",
>>> or
>>> via pool software examining block headers, or via a patch along
>> the
>>> lines
>>> of MUST_SIGNAL enforcement, but doing the opposite. For
>> concreteness,
>>> here's a sketch of such a patch:
>>> 
>>> 
>> 
> https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f
>>> 
>>>> For 2 weeks, users with LOT=False would not have a usable
>> network.
>>> 
>>> That's also ridiculous FUD.
>>> 
>>> If it were true, it would mean the activation mechanism was not
>>> acceptable, as non-upgraded nodes would also not have a usable
>> network
>>> for the same reason.
>>> 
>>> Fortunately, it's not true.
>>> 
>>> More generally, if miners are willing to lose significant amounts
>> of
>>> money mining orphan blocks, they can do that at any time. If
>> they're
>>> not inclined to do so, it's incredibly straightforward for them to
>> 
>>> avoid
>>> doing so, whatever a minority of other miners might do.
>>> 
>>>> 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.
>>> 
>>> LOT=false is the default behaviour of everything single piece of
>> node
>>> software out there. That behaviour doesn't need to be introduced,
>> it's
>>> already universal.
>>> 
>>> Cheers,
>>> aj
>>> 
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[Emil Pfeffer]

On Tue, Mar 02, 2021 at 01:06:14AM +1000, Anthony Towns via bitcoin-dev wrote:
> On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev wrote:
> > 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. 
> 
> To the contrary, we saw in 2017 that miners could *not* successfully
> veto a BIP 9 activation. It was certainly more effort and risk than was
> desirable to override the attempted veto, but the attempt at vetoing
> nevertheless failed.

You cannot prove a statement to be false by making another statement.

> 
> > It wouldn't be much different than adding back the inflation bug 
> > (CVE-2018-17144) and trusting miners not to exploit it.
> 
> That is ridiculous FUD.

That is an analogy not FUD. A strong one nevertheless but still an analogy.

> 
> > With LOT=False in the picture, however, things can get messy:
> 
> LOT=false is always in the picture if we are talking about a soft-fork:
> the defining feature of a soft-fork is that old node software continues
> to work, and old node software will be entirely indifferent to whether
> activation is signalled or not.
> 

That is the correct description of how soft-forks should work in principle.

> > some users will 
> > enforce Taproot(eg) (those running LOT=True), while others will not (those 
> > with LOT=False)
> 
> If you are following bip8 with lockinontimeout=false, you will enforce
> taproot rules if activation occurs, you will simply not reject blocks if
> activation does not occur.

Also correct in principle.


> > 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.
> 
> This assumes anyone mining the chain where taproot does not activate is
> not able to avoid a reorg, despite having majority hashpower (as implied
> by the lot=true chain having to overtake them repeatedly). That's absurd;
> avoiding a reorg is trivially achieved via running "invalidateblock", or
> via pool software examining block headers, or via a patch along the lines
> of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
> here's a sketch of such a patch:
> 
> https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f

If lot=true has majority of hashpower it wins.
Having to overtake them repeatedly assumes a 50/50 split one chain taking
over the other repeatedly.
In which case OP's statement that the LOT=True chain is safer holds true.

> 
> > For 2 weeks, users with LOT=False would not have a usable network.
> 
> That's also ridiculous FUD.

In context thats not FUD and most certainly it's not ridiculous FUD.
Assuming a 50/50 hashpower split the Lot=False chain has no stability
till difficulty re-adjustment. 

> 
> If it were true, it would mean the activation mechanism was not
> acceptable, as non-upgraded nodes would also not have a usable network
> for the same reason.
> 
> Fortunately, it's not true.

In the split scenario non-upgraded nodes don't play, right? aka they're part of
both chains.

> 
> More generally, if miners are willing to lose significant amounts of
> money mining orphan blocks, they can do that at any time. If they're
> not inclined to do so, it's incredibly straightforward for them to avoid
> doing so, whatever a minority of other miners might do.

Except that when incentives change so does miner behavior.

> 
> > 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.
> 
> LOT=false is the default behaviour of everything single piece of node
> software out there. That behaviour doesn't need to be introduced, it's
> already universal.

You are again making an "in principle" statement.

> 
> Cheers,
> aj

If you meant this to be a rebuttal, it is not.
It is mostly blanket statements and attacking OP.

-- 

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[Chris Belcher]

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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[Eric Voskuil]

To clarify, it is the soft fork enforcement by majority hash power that is the 51% attack, not the stopping of it. Majority hash power censors non-conforming transactions. To counter it requires only a non-censoring majority to continue mining.

It is correct that the purpose of supermajority signaling is to reduce the chance of a chain split. It is misleading to call it a bug and to imply that user activation isn’t actually intended to create, or at least threaten, a chain split. It’s a game of chicken.

e

> On Mar 2, 2021, at 10:22, Chris Belcher via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[Emil Pfeffer]

On Tue, Mar 02, 2021 at 06:21:59PM +0000, Chris Belcher via bitcoin-dev wrote:
> It is wrong to say that using miner signalling alone for activation
> (LOT=false) is a bug.

That depends on the definition you choose to work with but since the community
had to produce a fix that implies something was broken so we can call it a
bug in a broad sense.

> 
> 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.

Certainly and neither did the OP.

> 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.

That is true but this would happen for both chains and cannot be used
to put either one of them in a better light.

> 
> 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.

No, the LOT=false chain is also vulnerable to this and reorgs.

> Both chains suffer if a chain split happens which is why they
> are pretty important to avoid.

That's correct however that is worst case scenario and it can happen regardless
of which lot bitcoin ships with.

> That's why its inaccurate to portray LOT=true chain as safe 
> with no downsides at all.

It was not, it was portrayed as safer which holds true.

> 
> 
> 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@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--