path: root/a2/62302fc29605fdf2805e986bd7ce93aea86749

Return-Path: <yanmaani@cock.li>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CC552C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 22:58:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id BEF864BAFA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 22:58:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 3.604
X-Spam-Level: ***
X-Spam-Status: No, score=3.604 tagged_above=-999 required=5
 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
 DKIM_VALID_EF=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.246,
 RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,
 RCVD_IN_RP_RNBL=1.284, RDNS_NONE=1.274, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=cock.li
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id iwuhOYYx31oA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 22:58:20 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.cock.li (unknown [37.120.193.123])
 by smtp4.osuosl.org (Postfix) with ESMTPS id C4CF04B7CF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 22:58:19 +0000 (UTC)
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail;
 t=1614812291; bh=LMEyEQGROedWRxp7PtnVeZPUIxkCyExkFLF2BHhrsDE=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=gIhgj/C6zCzfehGGI7vBcp4dhdB9mOQbWbmBJSsmUw0yVXoVux5MkVmHfZecBuOfx
 yrFH2MAgx6Rmg7TMKT1doq0As0jkLcOq6rSM6ucaSwfQaASvAAkXRlH227Ea+H7cmp
 zuunAA/jYGe7aOjKe0tZX5zyHdrb6zW2ujmlkP4Uwgp+nasLAQ9viFE6Pd41jr5sUj
 NWNMZw/r4AMhc803Bb5QIOnBUoaMOqLDSMs8flnd+2FYYCOVI1eRZpR/pTOVI+3cM/
 H4mFO4vRphvKDDM444SbTm4jHadKrKOzU63+D9T78rHX9UvzvKBYbfXJqTXMtK4Y1a
 aOW6UAe2sxJNw==
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 03 Mar 2021 22:58:10 +0000
From: yanmaani@cock.li
To: Erik Aronesty <erik@q32.com>
In-Reply-To: <CAJowKgLWfc8WJF9guy_3nztBm=iJ9+jWRMEg-Vadj9cdXGvkFA@mail.gmail.com>
References: <202102281933.30691.luke@dashjr.org>
 <20210301150614.vz557ssn2epxknjn@erisian.com.au>
 <86f87c6e5e4fd05c2295de2209694771@cock.li>
 <CAJowKgLWfc8WJF9guy_3nztBm=iJ9+jWRMEg-Vadj9cdXGvkFA@mail.gmail.com>
Message-ID: <57ab51611ab99f29f82f7355bb936f67@cock.li>
X-Sender: yanmaani@cock.li
User-Agent: Roundcube Webmail/1.3.15
X-Mailman-Approved-At: Wed, 03 Mar 2021 22:59:34 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2021 22:58:24 -0000

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