summaryrefslogtreecommitdiff
path: root/31
diff options
context:
space:
mode:
authorLuke Dashjr <luke@dashjr.org>2021-03-15 02:51:46 +0000
committerbitcoindev <bitcoindev@gnusha.org>2021-03-15 02:53:10 +0000
commit23d34b79bf72821442b8f387a29eab5bbfee5bc6 (patch)
tree12d61b76fd970808f95cfb106d022699fe4a9307 /31
parent2a96fbdacf2502d74dd9b9ed12696f4e40d3cfe7 (diff)
downloadpi-bitcoindev-23d34b79bf72821442b8f387a29eab5bbfee5bc6.tar.gz
pi-bitcoindev-23d34b79bf72821442b8f387a29eab5bbfee5bc6.zip
Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
Diffstat (limited to '31')
-rw-r--r--31/a07f4050a257b743d758b0cd849e5fafa52a18328
1 files changed, 328 insertions, 0 deletions
diff --git a/31/a07f4050a257b743d758b0cd849e5fafa52a18 b/31/a07f4050a257b743d758b0cd849e5fafa52a18
new file mode 100644
index 000000000..510f7d190
--- /dev/null
+++ b/31/a07f4050a257b743d758b0cd849e5fafa52a18
@@ -0,0 +1,328 @@
+Return-Path: <luke@dashjr.org>
+Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
+ by lists.linuxfoundation.org (Postfix) with ESMTP id 81B3CC0001
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 15 Mar 2021 02:53:10 +0000 (UTC)
+Received: from localhost (localhost [127.0.0.1])
+ by smtp3.osuosl.org (Postfix) with ESMTP id 705BD6F4A4
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 15 Mar 2021 02:53:10 +0000 (UTC)
+X-Virus-Scanned: amavisd-new at osuosl.org
+X-Spam-Flag: NO
+X-Spam-Score: 0.599
+X-Spam-Level:
+X-Spam-Status: No, score=0.599 tagged_above=-999 required=5
+ tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
+ DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001,
+ RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
+ autolearn=ham autolearn_force=no
+Authentication-Results: smtp3.osuosl.org (amavisd-new);
+ dkim=pass (1024-bit key) header.d=dashjr.org
+Received: from smtp3.osuosl.org ([127.0.0.1])
+ by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
+ with ESMTP id DHInJZ74x-bJ
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 15 Mar 2021 02:53:09 +0000 (UTC)
+X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
+Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
+ by smtp3.osuosl.org (Postfix) with ESMTP id D6AB56F49F
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 15 Mar 2021 02:53:08 +0000 (UTC)
+Received: from ishibashi.lan (unknown [12.190.236.207])
+ (Authenticated sender: luke-jr)
+ by zinan.dashjr.org (Postfix) with ESMTPSA id 6D8EE38A00AC;
+ Mon, 15 Mar 2021 02:51:50 +0000 (UTC)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
+ t=1615776785; bh=g3lNhGnTH1BakWcgaPpowfApkKT0Vh4gbiJ5eDDgUzc=;
+ h=From:To:Subject:Date:References:In-Reply-To;
+ b=c/mJUE9iwhf+2kDRc0IfcVcQnHEazplmT1gpbE7VJveWADrVCaoL8VTeItuTnATuW
+ BDMIseo1ee4lP0qlw0Q1SQHUTqX7WdECTYmBy8QeqFtBbm4cw8hFcXlUrFFyUz4jNH
+ Re6BBnORq9AHXvYyVEvNYN/4MO/C4C1Ti7ZVaL60=
+X-Hashcash: 1:25:210315:bitcoin-dev@lists.linuxfoundation.org::WgWmJ0fJB/=zJ4qa:lv3U
+X-Hashcash: 1:25:210315:achow101-lists@achow101.com::VpFtRpMcNmhg5H/u:e6Ssc
+From: Luke Dashjr <luke@dashjr.org>
+To: bitcoin-dev@lists.linuxfoundation.org,
+ Andrew Chow <achow101-lists@achow101.com>
+Date: Mon, 15 Mar 2021 02:51:46 +0000
+User-Agent: KMail/1.9.10
+References: <20210306034343.fhwrxmq6gbb2os5m@ganymede>
+ <5be46169-8f38-da73-4112-fba2aff6dfcb@achow101.com>
+In-Reply-To: <5be46169-8f38-da73-4112-fba2aff6dfcb@achow101.com>
+X-KMail-QuotePrefix: >
+MIME-Version: 1.0
+Content-Type: Text/Plain;
+ charset="iso-8859-1"
+Content-Transfer-Encoding: 7bit
+Content-Disposition: inline
+Message-Id: <202103150251.46902.luke@dashjr.org>
+Subject: Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
+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: Mon, 15 Mar 2021 02:53:10 -0000
+
+The last period before timeoutheight here overlaps with the current BIP8(True)
+deployment plan. So if this period specifically were to reach 90% signalling,
+nodes would activate Taproot at height 697536, but ST-only nodes would still
+wait until 709632 instead.
+
+Probably the best solution is to just move this ST window 1 period earlier?
+
+Luke
+
+
+On Saturday 06 March 2021 06:04:22 Andrew Chow via bitcoin-dev wrote:
+> I like this idea.
+>
+> In terms of actual parameters, I propose that we base this Speedy Trial
+> off of BIP 8 with the following parameters:
+> * start height = 681408
+> * timeout height = 695520
+> * lockinontimeout = False
+> * signaling bit = 2
+> * threshold = 1815/2016 blocks (90%)
+>
+> For the extended lockin period, I propose 14112 blocks, which is 7
+> retarget periods. Thus the earliest activation height will be 697536 and
+> the latest activation height will be 709632.
+>
+> This will give us an approximate start time of May 1st 2021 and an
+> approximate timeout time of August 7th 2021, for a total activation
+> period of just over 3 months. The extended lockin period is the same
+> number of blocks as the activation period so that will also be just over
+> 3 months, giving us the latest activation time of November 13th, 2021.
+> If miners activated as soon as possible, the earliest activation time
+> would be August 21st 2021.
+>
+> Additionally, this timeline assumes a mid-April release of Bitcoin Core
+> 0.21.1 containing these parameters. They could be changed to move up if
+> the expected release date were sooner.
+>
+>
+> Andrew Chow
+>
+> On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev wrote:
+> > On the ##taproot-activation IRC channel, Russell O'Connor recently
+> > proposed a modification of the "Let's see what happens" activation
+> > proposal.[1] The idea received significant discussion and seemed
+> > acceptable to several people who could not previously agree on a
+> > proposal (although this doesn't necessarily make it their first
+> > choice). The following is my attempt at a description.
+> >
+> > 1. Start soon: shortly after the release of software containing this
+> > proposed activation logic, nodes will begin counting blocks towards
+> > the 90% threshold required to lock in taproot.[2]
+> >
+> > 2. Stop soon: if the lockin threshold isn't reached within approximately
+> > three months, the activation attempt fails. There is no mandatory
+> > activation and everyone is encouraged to try again using different
+> > activation parameters.
+> >
+> > 2. Delayed activation: in the happy occasion where the lockin threshold
+> > is reached, taproot is guaranteed to eventually activate---but not
+> > until approximately six months after signal tracking started.
+> >
+> > ## Example timeline
+> >
+> > (All dates approximate; see the section below about BIP9 vs BIP8.)
+> >
+> > - T+0: release of one or more full nodes with activation code
+> > - T+14: signal tracking begins
+> > - T+28: earliest possible lock in
+> > - T+104: locked in by this date or need to try a different activation
+> > process - T+194: activation (if lockin occurred)
+> >
+> > ## Analysis
+> >
+> > The goal of Speedy Trial is to allow a taproot activation attempt to
+> > either quickly succeed or quickly fail---without compromising safety in
+> > either case. Details below:
+> >
+> > ### Mitigating the problems of early success
+> >
+> > New rules added in a soft fork need to be enforced by a large part of
+> > the economy or there's a risk that a long chain of blocks breaking the
+> > rules will be accepted by some users and rejected by others, causing a
+> > chain split that can result in large direct losses to transaction
+> > receivers and potentially even larger indirect losses to holders due to
+> > reduced confidence in the safety of the Bitcoin system.
+> >
+> > One step developers have taken in the past to ensure widespread adoption
+> > of new consensus rules is programming in a delay between the time
+> > software with those rules is expected to be released and when the
+> > software starts tracking which blocks signal for activation. For
+> > example:
+> >
+> > Soft fork | Release | Start | Delta
+> > -----------------+------------+------------+----------
+> > BIP68 (v0.12.1) | 2016-04-15 | 2016-05-11 | 26 days
+> > BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
+> >
+> > Sources: BitcoinCore.org,
+> > https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
+> >
+> > Speedy Trial replaces most of that upfront delay with a backend delay.
+> > No matter how fast taproot's activation threshold is reached by miners,
+> > there will be six months between the time signal tracking starts and when
+> > nodes will begin enforcing taproot's rules. This gives the userbase even
+> > more time to upgrade than if we had used the most recently proposed start
+> > date for a BIP8 activation (~July 23rd).[2]
+> >
+> > ### Succeed, or fail fast
+> >
+> > The earlier version of this proposal was documented over 200 days ago[3]
+> > and taproot's underlying code was merged into Bitcoin Core over 140 days
+> > ago.[4] If we had started Speedy Trial at the time taproot
+> > was merged (which is a bit unrealistic), we would've either be less than
+> > two months away from having taproot or we would have moved on to the
+> > next activation attempt over a month ago.
+> >
+> > Instead, we've debated at length and don't appear to be any closer to
+> > what I think is a widely acceptable solution than when the mailing list
+> > began discussing post-segwit activation schemes over a year ago.[5] I
+> > think Speedy Trial is a way to generate fast progress that will either
+> > end the debate (for now, if activation is successful) or give us some
+> > actual data upon which to base future taproot activation proposals.
+> >
+> > Of course, for those who enjoy the debate, discussion can continue while
+> > waiting for the results of Speedy Trial.
+> >
+> > ### Base activation protocol
+> >
+> > The idea can be implemented on top of either Bitcoin Core's existing
+> > BIP9 code or its proposed BIP8 patchset.[6]
+> >
+> > - BIP9 uses two time-based[7] parameters, starttime and timeout. Using
+> > these values plus a time-based parameter for the minimum activation
+> > delay would give three months for miners to activate taproot, but some
+> > of that time near the start or the end might not be usable due to
+> > signals only being measured in full retarget periods. However, the
+> > six month time for users to upgrade their node would be not be
+> > affected by either slow or fast block production.
+> >
+> > BIP9 is already part of Bitcoin Core and I think the changes being
+> > proposed would be relatively small, resulting in a small patch that
+> > could be easy to review.
+> >
+> > - BIP8 uses two height-based parameters, startheight and timeoutheight.
+> > Using height values would ensure miners had a certain number of
+> > retarget periods (6) to lock in taproot and that there'd be a certain
+> > number of blocks (about 24,000) until activation, although latest lock
+> > in and expected activation could occur moderately earlier or later
+> > than the estimated three and six months.
+> >
+> > BIP8 would likely be used if Speedy Trial fails, so it could be
+> > advantageous to base this proposal on BIP8 so that we gain
+> > experience running that code in production.
+> >
+> > For additional discussion about using times versus heights, see today's
+> > log for ##taproot-activation.[11]
+> >
+> > ### Additional concerns
+> >
+> > - Encourages false signaling: false signaling is when miners signal
+> > readiness to enforce rules that their nodes don't actually support.
+> > This was partially responsible for a six-block reorg shortly after the
+> > final BIP66 activation[8] and was found to still be a problem during
+> > the BIP68 lockin period despite BIP9 being designed to avoid it.[9]
+> >
+> > Because Speedy Trial only gives miners a maximum of three months to
+> > signal support for taproot, it may encourage such false signaling. If
+> > taproot locks in as a result of their signaling but most of them fail
+> > to upgrade by the activation date several months later, unprepared
+> > miners could lose large amounts of money and users could see long
+> > reorgs (with unupgraded nodes and SPV lite clients potentially losing
+> > money).
+> >
+> > Compared to other activation proposals, I think the only difference is
+> > Speedy Trial's short timeline. False signaling is possible with any
+> > other proposal and the same problems can occur if miners fail to
+> > upgrade for any mandatory activation.
+> >
+> > ### Additional advantages
+> >
+> > - No mandatory signaling: at no time are miners required to signal by
+> > Speedy Trial. This includes no mandatory signaling during the
+> > locked_in period(s), although such signaling will be encouraged (as it
+> > was with BIP9[10]).
+> >
+> > - Party time: to a lesser degree, a benefit mentioned for flag day
+> > activation may also apply here: we could get up to six months
+> > advanced notice of taproot activation, allowing users, developers, and
+> > organizations to prepare software, announcements, and celebrations for
+> > that event.
+> >
+> > ## Implementation details and next steps
+> >
+> > Initial discussion about implementation may be found in today's
+> > ##taproot-activation log.[11] If it appears Speedy Trial may have
+> > traction, Russell O'Connor has offered to work on a patch against BIP8
+> > implementing it.
+> >
+> > ## Acknowledgments
+> >
+> > The original idea for a short-duration attempt was discussed in the
+> > ##taproot-activation IRC channel last July and the revised idea saw
+> > additional evaluation there this week. Despite growing frustration,
+> > discussion has been overwhelmingly constructive, for which all the
+> > contributors should be commended. Although this should not in any way
+> > imply endorsement, I'm grateful for the review and comments on a draft
+> > of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,
+> > Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell
+> > O'Connor, and IRC users maybehuman and proofofkeags
+> >
+> > ## Footnotes
+> >
+> > [1]
+> > https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see
+> >_what_happens.2C_BIP8.28false.2C_3m.29
+> >
+> > [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period
+> > seemed to have near-universal support during the 2021-02-16 IRC
+> > meeting. See:
+> > https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
+> >
+> > [3]
+> > https://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&oldi
+> >d=68062
+> >
+> > [4] https://github.com/bitcoin/bitcoin/pull/19953
+> >
+> > [5]
+> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/0175
+> >47.html
+> >
+> > [6] https://github.com/bitcoin/bitcoin/pull/19573
+> >
+> > [7] BIP9's times are based on the median of the past 11 blocks, which
+> > usually trails UTC by about 90 minutes but which can trail behind
+> > realtime significantly if miners are doing weird things.
+> >
+> > [8] https://en.bitcoin.it/wiki/July_2015_chain_forks
+> >
+> > [9] https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32
+> >
+> > [10]
+> > https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c735f330482df0bf
+> >9348f3a/src/test/versionbits_tests.cpp#L337-L339
+> >
+> > [11] http://gnusha.org/taproot-activation/2021-03-05.log
+> > _______________________________________________
+> > 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
+
+
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-13 04:22:22 +0000