From: Emil Pfeffer <emu@emuadmin•com>
To: Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used
Date: Mon, 1 Mar 2021 17:52:54 +0000 [thread overview]
Message-ID: <20210301175254.qjuz6vjppgkzcti7@www01.emuadmin.com> (raw)
In-Reply-To: <20210301150614.vz557ssn2epxknjn@erisian.com.au>
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.
--
next prev parent reply other threads:[~2021-03-01 18:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-28 19:33 Luke Dashjr
2021-03-01 15:06 ` Anthony Towns
2021-03-01 16:54 ` yanmaani
2021-03-02 6:11 ` Erik Aronesty
2021-03-03 22:58 ` yanmaani
2021-03-01 17:52 ` Emil Pfeffer [this message]
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=20210301175254.qjuz6vjppgkzcti7@www01.emuadmin.com \
--to=emu@emuadmin$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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