diff options
| author | Rusty Russell <rusty@rustcorp.com.au> | 2021-04-06 14:10:55 +0930 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-04-06 23:49:13 +0000 |
| commit | 1a883968516f76e10a0b570ca50dc762668193ed (patch) | |
| tree | 65259874a204a8a462ab587e2a58f10848de778d | |
| parent | 5ae0e4acf8a2eb7ea786449d4cb38a4d81c7fea5 (diff) | |
| download | pi-bitcoindev-1a883968516f76e10a0b570ca50dc762668193ed.tar.gz pi-bitcoindev-1a883968516f76e10a0b570ca50dc762668193ed.zip | |
Re: [bitcoin-dev] Response to Rusty Russell from Github
| -rw-r--r-- | 73/bd1bb025c1267df8b6bdc315a91f9bb35e7ce8 | 127 |
1 files changed, 127 insertions, 0 deletions
diff --git a/73/bd1bb025c1267df8b6bdc315a91f9bb35e7ce8 b/73/bd1bb025c1267df8b6bdc315a91f9bb35e7ce8 new file mode 100644 index 000000000..e49dfe6ae --- /dev/null +++ b/73/bd1bb025c1267df8b6bdc315a91f9bb35e7ce8 @@ -0,0 +1,127 @@ +Return-Path: <rusty@ozlabs.org> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 9D87EC000A + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 6 Apr 2021 23:49:13 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 92FCE401F0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 6 Apr 2021 23:49:13 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -0.604 +X-Spam-Level: +X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, + HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_PASS=-0.001, + SPF_PASS=-0.001] autolearn=no autolearn_force=no +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id SoBL_D6N-QZl + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 6 Apr 2021 23:49:12 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +Received: from ozlabs.org (ozlabs.org [203.11.71.1]) + by smtp2.osuosl.org (Postfix) with ESMTPS id 9C42840172 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 6 Apr 2021 23:49:12 +0000 (UTC) +Received: by ozlabs.org (Postfix, from userid 1011) + id 4FFPPf1Kcbz9sWD; Wed, 7 Apr 2021 09:49:10 +1000 (AEST) +From: Rusty Russell <rusty@rustcorp.com.au> +To: Jeremy <jlrubin@mit.edu>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org> +In-Reply-To: <CAD5xwhh=E00DVxqhZc7gDTBXtA-_HgybEaP_ysnA4n6AAVbWsA@mail.gmail.com> +References: <CAD5xwhh=E00DVxqhZc7gDTBXtA-_HgybEaP_ysnA4n6AAVbWsA@mail.gmail.com> +Date: Tue, 06 Apr 2021 14:10:55 +0930 +Message-ID: <87o8esja94.fsf@rustcorp.com.au> +MIME-Version: 1.0 +Content-Type: text/plain +Subject: Re: [bitcoin-dev] Response to Rusty Russell from Github +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: Tue, 06 Apr 2021 23:49:13 -0000 + +Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes: +> Where I disagree is that I do not believe that BIP8 with LOT configuration +> is the improved long term option we should ossify around either. I +> understand the triumvirate model you desire to achieve, but BIP8 with an +> individually set LOT configuration does not formalize how economic nodes +> send a network legible signal ahead of a chain split. A regular flag day, +> with no signalling, but communally released and communicated openly most +> likely better achieves the goal of providing users choice. + +You're ignoring the role of infrastructure. It's similar to saying that +there is no need for elections: if things are bad enough, citizens can +rise up and overthrow their government. + +> 1. Developers release, but do not activate +> 2. Miners signal +> 3. Users may override by compiling and releasing a patched Bitcoin with +> moderate changes that activates Taproot at a later date. While this might +> *seem* more complicated a procedure than configurable LOT, here are four +> reasons why it may be simpler (and safer) to just do a fresh release: + +Users may indeed, fire the devs and replace them, as this implies. This +is not empowering users, but in effect risks reducing their role to "beg +the devs or beg the miners". + +> A. No time-based consensus sensitivity on when LOT must be set (e.g., what +> happens if mid final signal period users decide to set LOT? Do all users +> set it at the same time? Or different times and end up causing nodes to ban +> each other for various reasons?) + +Yes, this Schelling point is important. If you read BIP-8, you will see +that LOT=true activates at the last moment for this very reason. + +> B. No "missed window" if users don't coordinate on setting LOT before the +> final period -- release whenever ready. + +Of course there is: they need to upgrade in time. + +> C. ST fails fast, permitting users ample time to prepare an alternative +> release + +You'd think so, but given the confusion surrounding Segwit, it seems a +year was barely time to debate, decide and coordinate. You want this +ready to go at the *beginning* of the 1 year process, not being decided, +debated, build and deployed once the crisis is upon us. That existing +deployment is a vital stake in the calculus of those who might try to +disrupt the process for any reason. + +> D. If miners continue to mine without signalling, and users abandon a +> LOT=true setting, their node will have already marked those blocks invalid +> and they will need to figure out how to re-validate the block. + +This is true, in fact, of any soft fork: a Luke points out, our lack of +revalidation of blocks after upgrade is a bug. Which should be fixed: +IMHO a decent PR to make LOT runtime configurable would reevaluate any +blocks >= timeoutheight-2016 when it is altered. + +> RE: point 3, is it as easy as it *could* be? No, but I don't have any +> genius ideas on how to make it easier either. (Note that I've previously +> argued for adding configurable LOT=true on the basis that a user-run script +> could emulate LOT without any software change as a harm reduction, but I +> did not advocate that particular technique be formalized as a part of the +> activation process) + +BIP-8 (with the recent modifications to allow maximal number of +non-signalling blocks) is technically as fork-preventative as we can +seek to make it. + +I am hopeful that our ecosystem will remain harmonious and we won't have +to use it. But I am significantly more hopeful that we won't have to +use it if we have it deployed and ready. + +Cheers, +Rusty. + |