From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 23A5CC002D for ; Wed, 11 May 2022 15:15:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 1269C83E28 for ; Wed, 11 May 2022 15:15:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_IMGUR=1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3MnpfWcb3AF for ; Wed, 11 May 2022 15:15:24 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) by smtp1.osuosl.org (Postfix) with ESMTPS id 18B8483E23 for ; Wed, 11 May 2022 15:15:23 +0000 (UTC) Date: Wed, 11 May 2022 15:15:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1652282120; bh=j0XMyRzvVmZxSRC29q2lwz9XtPMSLeFVaczv5w4LCww=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=INsGzCsLT3SjoyTC+0DxM7YOgEaiiWJAPwCHaZ+E6hL1qGiTi21eSZC6DXi9Opfgl SAapPDO4IxVd3dY3cL+mvipyhYUNg3HroKuCb/Z6IsRKMTNJMqUmyE+KxAbxNiTMou ++oVD9OKs0+EsE8iz1gU+X/DIp/h3x0qSz98uGJlOETBSB/t0TgKVO3KfQYyRDJwVr THVA9msjvmdCnpNcTq4YXRra5dwaODXW5ABwqMU2Nw7sjZr2GQ4iDblpi5ka0FIwC1 bP0CMLjzS70cEeJ4Xht04ZcIOSMiEiRkffi7iCqNZsk0OPAOz6Pgse/6O5vLYIyFN5 31azYz2bw7OFA== To: Billy Tetrud From: alicexbt Reply-To: alicexbt Message-ID: In-Reply-To: References: <8ZKbVUejj2P32rYfjnMaE6sLpiSUdQNHI-cNNpQ2KZiDT-TYrXrKUxJidZH0O5U1jMMllgpF2qiYuahUBeCBQ8ZAIKhIvIgZJ7PM9_b2t64=@protonmail.com> Feedback-ID: 40602938:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 11 May 2022 15:19:26 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Improving BIP 8 soft fork activation X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2022 15:15:25 -0000 Hi Billy, Thanks for the feedback. I agree with everything and=C2=A0bip-trinary-versi= on-signaling looks interesting. > A primary difference from both BIP8 and BIP9 is that this proposal uses t= ri-state version signaling (rather than binary version bits) that can encod= e both active support as well as active opposition to an active soft fork. I think 'support' and 'opposition' can be replaced with readiness. Miners s= hould not consider signaling as voting. > The meaning for each ternary value is as follows: 0 - No signal 1 - Ready for new consensus rules 2 - Not ready for new consensus rules The concept of a minimum and maximum threshold sounds intriguing, and I'm i= nterested to read what other developers have to say about it. Concept ACK on removing LOT, using tri-state version signaling,=C2=A0min/ma= x threshold and required threshold calculation. /dev/fd0 Sent with ProtonMail secure email. ------- Original Message ------- On Tuesday, May 10th, 2022 at 9:01 PM, Billy Tetrud billy.tetrud@gmail.com = wrote: > I think this is a useful proposal. There are certainly things about BIP9 = that BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but= a BIP spec was never produced for it afaik. A possibly unhelpful comment: > > > minimum_activation_height > > I think a minor improvement would be to specify this as minimum_activat= ion_blocks, ie a number of blocks passed the start_height. Slightly easier = to reason about and change when necessary. I proposed semantics like that h= ere. > > In any case, I'll give this a concept ACK. I would very much like futur= e soft forks to use a previously specified activation mechanism rather than= rolling out a rushed unspeced thing as part of the (very orthogonal) soft = fork implementation. > > On Tue, May 10, 2022 at 9:02 AM alicexbt via bitcoin-dev bitcoin-dev@li= sts.linuxfoundation.org wrote: > > > Hi Bitcoin Developers, > > > > There were some disagreements with speedy trial activation method recen= tly and BIP 8 became controversial because of LOT earlier. I have tried to = solve these two problems after reading some arguments for/against different= activation methods by removing LOT from BIP 8 and calculating MUST_SIGNAL = state based on threshold reached. > > > > BIP draft with no code and some changes in BIP 8: https://gist.github.c= om/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1 > > > > State transitions diagram: https://i.imgur.com/dj4bFVK.png > > > > This proposal removes lockinontimeout flag, activation never fails alth= ough MUST_SIGNAL can be longer if miners signaling does not reach the thres= hold. Longer period for MUST_SIGNAL state is useful for coordination if LOC= KED_IN was not reached. > > > > MUST_SIGNAL =3D ((100-t)/10)*2016 blocks, where t is threshold reached = and blocks that fail to signal in MUST_SIGNAL phase are invalid. > > > > Example: > > > > - This activation method is used for a soft fork > > - Only 60% miners signaled readiness and timeout height was reached > > - MUST_SIGNAL phase starts and will last for 4*2016 blocks > > - LOCKED_IN and ACTIVE states remain same as BIP 8 > > - Soft fork is activated with a delay of 2 months > > > > /dev/fd0 > > > > Sent with ProtonMail secure email._____________________________________= __________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev