Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 59870C0001 for ; Wed, 3 Mar 2021 17:30:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 327264A483 for ; Wed, 3 Mar 2021 17:30:31 +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 Q79X9VjGiy_2 for ; Wed, 3 Mar 2021 17:30:29 +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 B59254A254 for ; Wed, 3 Mar 2021 17:30:29 +0000 (UTC) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail; t=1614792620; bh=BnIRvaUQpWw1QzwcYuiq1iLB1mbNSiZDjBCLcufn5gs=; h=Date:From:To:Subject:In-Reply-To:References:From; b=kQSB/pfFFIfniNUSCk9nDQZOWIqCK5fZRgwL5homIws/TlknPQib+iWok8+Q+f22K hZtPKFFN8lKIJlGWkU7rthR6y+bgZV1PVDimOImfXgqrpZj2Mg55gYepDd3KrnOvId yAleAvTvh/3k1pxiZTi5VG+tK5iNxvfJwn2FDRP6siDRX2Vi7sAl5CEBZsvR/zqVWS v4QeloMiFIPGucAZyFaCvGNmsKe3cNf6QfXdOoJfQWyXIjL8gop7s60PkOQUhTYkxG P0+B9ce28IQHIU22lvFNysJAKvVgJ7yLQ1F8D2V3zi3d3EUZk115cjpyYM96AeAA+P XSmx2rAAdtc4A== Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 03 Mar 2021 17:30:20 +0000 From: yanmaani@cock.li To: Chris Belcher , Bitcoin Protocol Discussion In-Reply-To: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net> References: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net> Message-ID: <85745a38e4464541d6357408fae1cfed@cock.li> X-Sender: yanmaani@cock.li User-Agent: Roundcube Webmail/1.3.15 X-Mailman-Approved-At: Wed, 03 Mar 2021 17:50:41 +0000 Subject: Re: [bitcoin-dev] Making the case for flag day activation of taproot 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, 03 Mar 2021 17:30:31 -0000 On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote: > Enter flag day activation. With a flag day there can be no > brinksmanship. A social media blitz cant do anything except have its > own > followers fork away. Crucially, miner signalling cant be used to change > the activation date for nodes that didn't choose to and just passively > follow signalling. Changing the activation date requires all those > users > to actually run different node software. Is that supposed to be a good thing? "We should do X because it'll work" doesn't prove X is actually good. These things can be evil, but they can also be legitimate opposition to a change. Taking away the power of a "social media blitz" is not guaranteed to be a good thing! > What if one day the Core developer team uses the flag > day method to do something bad? The bitcoin user > community who wants to resist this can create their own > counter-soft-fork full node. This forces a chain > split. The real bitcoin which most people follow will be > the chain without censorship. [edited for brevity] That will only work for really egregious changes. In practice, most people will trust Core on all other (non-egregious) decisions, because of the inertia inherent in disobeying them. What you suggest may be an efficient way to ram taproot through, but is it inherently good? Nothing is free. This seems like de-facto forcing people to go along with you, because you're convinced you're right. In this case, you are, but you'd be convinced you'd be right even if you weren't so. You're right in suggesting that it will work, but the reason why it will work is because nobody wants to disobey Core. It seems immoral to exploit this fact. At least you shouldn't hard-code it and require dissenters to fork away. I exhort you to consider making all this controversial stuff settings that can be changed by RPC command or command-line flag; set the default value sure, but requiring a fork to change it is, in my opinion, oppressive. (Also consider some compromise, such as ">95% miner support before flag day or >33% on flag day") Best wishes Yanmaani