public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: yanmaani@cock.li
To: Anthony Towns <aj@erisian.com.au>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used
Date: Mon, 01 Mar 2021 16:54:07 +0000	[thread overview]
Message-ID: <86f87c6e5e4fd05c2295de2209694771@cock.li> (raw)
In-Reply-To: <20210301150614.vz557ssn2epxknjn@erisian.com.au>

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


  reply	other threads:[~2021-03-01 17:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-28 19:33 [bitcoin-dev] LOT=False is dangerous and shouldn't be used Luke Dashjr
2021-03-01 15:06 ` Anthony Towns
2021-03-01 16:54   ` yanmaani [this message]
2021-03-02  6:11     ` Erik Aronesty
2021-03-03 22:58       ` yanmaani
2021-03-01 17:52   ` Emil Pfeffer
2021-03-02 18:21 ` Chris Belcher
2021-03-02 20:07   ` Eric Voskuil
2021-03-03 16:27   ` Emil Pfeffer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86f87c6e5e4fd05c2295de2209694771@cock.li \
    --to=yanmaani@cock.li \
    --cc=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox