From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4B929C0001 for ; Sun, 7 Mar 2021 13:33:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 3565E43018 for ; Sun, 7 Mar 2021 13:33:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.802 X-Spam-Level: X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001] autolearn=ham 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 V3SGprdhstqI for ; Sun, 7 Mar 2021 13:33:49 +0000 (UTC) X-Greylist: delayed 03:29:59 by SQLgrey-1.8.0 Received: from smtprelay.hostedemail.com (smtprelay0066.hostedemail.com [216.40.44.66]) by smtp2.osuosl.org (Postfix) with ESMTPS id 6686F43033 for ; Sun, 7 Mar 2021 13:33:49 +0000 (UTC) Received: from smtprelay.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by smtpgrave05.hostedemail.com (Postfix) with ESMTP id 817BC1801BB9E for ; Sun, 7 Mar 2021 09:58:35 +0000 (UTC) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id 753FF181D2FC1 for ; Sun, 7 Mar 2021 09:58:32 +0000 (UTC) X-Session-Marker: 6361726C6F407370696C6C65722E636F6D X-Spam-Summary: 10, 1, 0, , d41d8cd98f00b204, carlo@spiller.com, , RULES_HIT:41:152:355:379:854:973:988:989:1260:1277:1311:1313:1314:1345:1381:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1777:1792:2194:2199:2393:2559:2562:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:4250:5007:6670:7903:7996:8957:9010:9108:10004:10400:10848:11658:11914:12050:12297:12660:12663:12760:13069:13071:13311:13357:14096:14097:14180:14685:21060:21080:21627:21795:21809:21888:21939:30051:30054:30056, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:1, LUA_SUMMARY:none X-HE-Tag: blood12_1f121cb276e7 X-Filterd-Recvd-Size: 2134 Received: from Carlos-Mac-Mini.local (bbcs-93-229.pub.wingo.ch [144.2.93.229]) (Authenticated sender: carlo@spiller.com) by omf09.hostedemail.com (Postfix) with ESMTPA for ; Sun, 7 Mar 2021 09:58:31 +0000 (UTC) To: bitcoin-dev@lists.linuxfoundation.org From: Carlo Spiller Message-ID: <5a779c13-8ebf-5052-5bf7-846f970c21ef@spiller.com> Date: Sun, 7 Mar 2021 10:58:30 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 07 Mar 2021 14:37:17 +0000 Subject: [bitcoin-dev] Yet another Taproot activation logic 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: Sun, 07 Mar 2021 13:33:50 -0000 Hi everybody I'm new to this list, but not new to Bitcoin, having skin in the game since 2014. I was there for the scaling war and the drama around SegWit, as a simple user. This time, I run my own full node and follow development. I hope to bring something new to the table. Having witnessed the miner's unwillingness to activate SegWit truly makes me concerened for a simple LOT=false. After reading the discussion now for some time and thinking about it myself, I have come to the following proposal. Initially deploy with LOT=false and an activation threshold of 95% of miner signaling. *IFF* after 6 months Taproot is not activated by MASF, BUT at least 80% of hashpower signaled for the upgrade, LOT gets a lock-in date another 6 months later and the threshold for MASF is lowered to 90%. If after the initial 6 months of signaling with LOT=false, 80% is not reached, the proposal expires. This way, a small percent of hashpower does not get to stall activation, rather, 80% of hashpower can activate LOT=true, and later, 90% can activate Taproot. If a flaw is found in Taproot in the first six months (unlikely anyway), miners simply don't signal and the proposal expires. If miners don't signal at all, only six months are lost, before a new activation logic can be deployed. Don't mind this if something similar was already proposed somewhere else. Best Carlo