diff options
| author | Matt Corallo <lf-lists@mattcorallo.com> | 2021-04-06 20:46:16 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-04-07 00:46:20 +0000 |
| commit | 847a02c3b9d709975570059941d9bd98d5a771f5 (patch) | |
| tree | e43c7eaf0308934e22f06d8cf84097f26bb91a16 | |
| parent | 35a150d0f4e8729337221603a0cda998d2580f21 (diff) | |
| download | pi-bitcoindev-847a02c3b9d709975570059941d9bd98d5a771f5.tar.gz pi-bitcoindev-847a02c3b9d709975570059941d9bd98d5a771f5.zip | |
Re: [bitcoin-dev] Response to Rusty Russell from Github
| -rw-r--r-- | a5/5b6bfc9e747c551e657ab41979da7f37022578 | 164 |
1 files changed, 164 insertions, 0 deletions
diff --git a/a5/5b6bfc9e747c551e657ab41979da7f37022578 b/a5/5b6bfc9e747c551e657ab41979da7f37022578 new file mode 100644 index 000000000..643929071 --- /dev/null +++ b/a5/5b6bfc9e747c551e657ab41979da7f37022578 @@ -0,0 +1,164 @@ +Return-Path: <lf-lists@mattcorallo.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 484ABC000A + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 7 Apr 2021 00:46:20 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with UTF8SMTP id 2198560681 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 7 Apr 2021 00:46:20 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -0.201 +X-Spam-Level: +X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 + tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp3.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=mattcorallo.com +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with UTF8SMTP id U1FkaunXan_U + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 7 Apr 2021 00:46:19 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +Received: from mail.as397444.net (mail.as397444.net + [IPv6:2620:6e:a000:dead:beef:15:bad:f00d]) + by smtp3.osuosl.org (Postfix) with UTF8SMTPS id DBBD06060A + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 7 Apr 2021 00:46:18 +0000 (UTC) +Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 222FB5198B2; + Wed, 7 Apr 2021 00:46:17 +0000 (UTC) +X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; + s=1617754864; t=1617756377; + bh=3Fkm6GbSZedByipcUPL1orwQgJC+rlZqm7axTKEGt+Y=; + h=Date:Subject:To:References:From:In-Reply-To:From; + b=bi+expxRX1Cq5CLs+CFhaTRtVWONXWu8/0EeDi4J92Fpk5gU2SrrZafc+ZCyG0lVj + DV+7LNmnxSQMwvnJQpFG/n7yZmuqvlGvP5x0Y+Py1LnDoXzhhKJXMGzo4VO3DpPF4B + N5NNKqx/Pknv3yQy18cO/prpaaUVg1Ed6U36C7GDqZ+idLLQTY023G/HkzGLRimfzW + wuAHrX+kRu8QAPdSgYJxdSdi+knzMnq2OXywV63u+GfdsYUO6XNFoIkF/C1ferCBAr + yTn/bA+MnZpW/vg1M0hjd1QMufuAENl4aPORo1WOGg8VOEfosriofm0BiXisPusWfd + kss0AXraNKu6A== +Message-ID: <a496407f-f58c-8099-355b-e32e4e97c6cb@mattcorallo.com> +Date: Tue, 6 Apr 2021 20:46:16 -0400 +MIME-Version: 1.0 +Content-Language: en-US +To: Rusty Russell <rusty@rustcorp.com.au>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + Jeremy <jlrubin@mit.edu> +References: <CAD5xwhh=E00DVxqhZc7gDTBXtA-_HgybEaP_ysnA4n6AAVbWsA@mail.gmail.com> + <87o8esja94.fsf@rustcorp.com.au> +From: Matt Corallo <lf-lists@mattcorallo.com> +In-Reply-To: <87o8esja94.fsf@rustcorp.com.au> +Content-Type: text/plain; charset=UTF-8; format=flowed +Content-Transfer-Encoding: 7bit +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: Wed, 07 Apr 2021 00:46:20 -0000 + +I'm somewhat gobsmacked that this entire conversation hasn't included the word "market" in it at all. If there's one +thing we can all agree we learned from Segwit2x, BCH, BSV, BU, etc, its that, ultimately, the market decides. Not only +does the market decide, but there's lots of money to be made by being the market maker or operator letting the market +make its voice heard. There is nothing we can, or should, do to ensure the market can make its voice heard - it always will. + +We don't need to bend over backwards to make sure individual users are forced to try to form consensus among themselves +via options or chain splits, we can just let the market decide. Within reason, the market will probably decide "yep, +what the brains are doing looks good, Bitcoin needs to stay in consensus, no point in trying to nitpick something or +we'll never come to consensus about anything". If what's being proposed is ever disagreed with by some small-ish but +nontrivial group, futures markets are going to decide the fate of the system no matter what the consensus rules or +activation method is, why do we need to do very much else? + +Matt + +On 4/6/21 00:40, Rusty Russell via bitcoin-dev wrote: +> 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. +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + |