diff options
| author | Billy Tetrud <billy.tetrud@gmail.com> | 2022-05-02 19:04:45 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-05-03 00:05:08 +0000 |
| commit | 14dcfecdb3c57a8c2f3e51e73f8af7598af0f314 (patch) | |
| tree | 93c307ca85fd0bffc1a44d67926e26e5184855d8 | |
| parent | a2bd3b4e8a4fe8867294e9fb7c2cf284a01479c7 (diff) | |
| download | pi-bitcoindev-14dcfecdb3c57a8c2f3e51e73f8af7598af0f314.tar.gz pi-bitcoindev-14dcfecdb3c57a8c2f3e51e73f8af7598af0f314.zip | |
Re: [bitcoin-dev] Working Towards Consensus
| -rw-r--r-- | 2d/d3f7f3d20def0f61083ec99d7824dbe51b8ab7 | 1125 |
1 files changed, 1125 insertions, 0 deletions
diff --git a/2d/d3f7f3d20def0f61083ec99d7824dbe51b8ab7 b/2d/d3f7f3d20def0f61083ec99d7824dbe51b8ab7 new file mode 100644 index 000000000..ac2d4f376 --- /dev/null +++ b/2d/d3f7f3d20def0f61083ec99d7824dbe51b8ab7 @@ -0,0 +1,1125 @@ +Return-Path: <fresheneesz@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 68BDCC002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 3 May 2022 00:05:08 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 3CFC2416E2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 3 May 2022 00:05:08 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp4.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +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 92HzGKp7-s_h + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 3 May 2022 00:05:05 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com + [IPv6:2607:f8b0:4864:20::52a]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 1307A416E0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 3 May 2022 00:05:04 +0000 (UTC) +Received: by mail-pg1-x52a.google.com with SMTP id g3so12834043pgg.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 02 May 2022 17:05:04 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to; + bh=UY+5onnl+wNF1fwU3uGa5ncp+Z7svZMiA0jxnmi1Db0=; + b=e5NDqhJmAS2Cqc1T1zrWKwgM0l2KhKF9Qf2VYgxJSdXEQQxDQ6EBz5No2u6LM+lqmq + fH80/L2AE/nNxTcjhGzeRezti3o11lEkUcnn4EteiJq6z0+9k9NXpR8gOdU16tI1T79h + aRGxfTRQWYIvrrONDU1FVhxFD8Icvt6vh4o5HYUR5+BOtg+Lp5noKQgV0bvepr8fL0aM + QV8iypkiaabe9x2SrIMJvoRH2fBPHGnvP3ZTme0Q4ukW/MziTkfDpSqW0aZAOkA7+IXM + /9QfGpVTlZVypvENaUeo3z5vVx9yB75IPEsE1FuUU2rA881YC5wbR7xU9SD0y1fHzWvE + B7rg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to; + bh=UY+5onnl+wNF1fwU3uGa5ncp+Z7svZMiA0jxnmi1Db0=; + b=eL8bfDCaPKxvIGEin3xyF5o0Ioenh1X7LDvDbWpgu6lMp/JlloR7htXVgtVM6p1ws6 + cgTUBDtMyUfnEAcef/9YuT2VWwVUBB/TO00nBu+krHmAWTngL4gpZFcysCTGVr/y/0qq + ifaSsnULKWUv/PnFSr2bmEVJ2NqTW+PzyrsEBY0shqSInl5lh31dKEBhCFfCRag2Zb/i + s3VqmgC/nTW35Ta2WKuvpqfIXofpNSTEpQ2hytMaOtAc90QtcH56W3PRIeFBngidxeUk + WLSBabP7JSrrS58P+79bQ+deAexgKWRnYR/6naIH372GIOdL+ZRAxhZoDNqg+dsOMmBm + SDUg== +X-Gm-Message-State: AOAM531hYX9gEO0fTvINiU5ia5Yvdc91X0bIr42I6JqQc8QzhUY02+C7 + FIal1fJwJw4lcbO7g3lWNS4DD/vOIFZmFT90N5gOgqFK +X-Google-Smtp-Source: ABdhPJyDIELwC+4YKdumYR6siaDfXBfxCeayAhwZQYObspxIN5e/aFg0K8DRC7vf2+AYLq+2eZBl9opPtLllp7lxoWs= +X-Received: by 2002:a63:2b90:0:b0:3aa:b1df:df69 with SMTP id + r138-20020a632b90000000b003aab1dfdf69mr11729151pgr.497.1651536304077; Mon, 02 + May 2022 17:05:04 -0700 (PDT) +MIME-Version: 1.0 +References: <mailman.51682.1651459425.8511.bitcoin-dev@lists.linuxfoundation.org> + <CAHTn92z3HaTu47O_3metXAhFEVN3QnLdug1BVt66a9GZGx6t=Q@mail.gmail.com> +In-Reply-To: <CAHTn92z3HaTu47O_3metXAhFEVN3QnLdug1BVt66a9GZGx6t=Q@mail.gmail.com> +From: Billy Tetrud <billy.tetrud@gmail.com> +Date: Mon, 2 May 2022 19:04:45 -0500 +Message-ID: <CAGpPWDbRp8ZoT+JWV6mKBPQT=86rxcSD9vELFsTMyU96S3D4kw@mail.gmail.com> +To: John Carvalho <john@synonym.to>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000bd004a05de1042b5" +X-Mailman-Approved-At: Tue, 03 May 2022 08:33:09 +0000 +Subject: Re: [bitcoin-dev] Working Towards Consensus +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: Tue, 03 May 2022 00:05:08 -0000 + +--000000000000bd004a05de1042b5 +Content-Type: text/plain; charset="UTF-8" + +John, + +> The path to consensus is to propose things that everyone needs. + +If there's an insight here, it isn't clear what it is to me. As stated, +this is something I can only 100% disagree with. Its possible that +literally nothing about bitcoin is something that "everyone needs". Its +pretty clear that not "everyone needs" taproot. Its even questionable +whether "everyone needs" bitcoin. Are you really saying that no change +should be added to bitcoin unless it is something literally all bitcoin +users are currently asking for, or maybe just will want to use sometime +soon? The majority of bitcoin users don't even custody their own funds, so +practically all features are something those users aren't using. If you +want to convince people of whatever argument you're making, you're going to +have to get a little more specific and rather less hyperbolic. + +> Designers (engineers) solve problems with designs, but when they +speculate and lead the process, they create problems instead. + +How do you expect any improvement to ever happen to bitcoin if designers +can't design things unless end-users have asked for it. Every good product +designer knows that users do not know how to design products. Users have +problems, designers create solutions. Companies that have implemented +features that users directly ask for end up with awful bloated confusing +products. Surely this isn't what you're suggesting we do in bitcoin, right? + +> Seek simplicity and efficiency, not complication. + +This is an extraordinarily ironic thing to say to Jeremy Rubin, who +designed CTV with exactly that in mind. It is an incredibly simple opcode +that doesn't allow recursive covenants or various other things that people +have been worried about in the past about covenants. I'm 99% confident that +there is no simpler, more efficient, and less complicated covenant opcode +than CTV that can even possibly be designed. The only one on par is +TXHASH+CSFS and that has more complex implications than CTV. + +There are MANY people out there that would like more complex, more powerful +covenants. "The market" is in fact demanding it. And yet because we must +move carefully in Bitcoin, CTV is a compromise that focuses on simplicity +and incremental change rather than radical change. + +Do you really disagree that CTV was intended to be as simple as possible +and achieves that goal? + +> There is simply no urgency or problem that any of the proposed soft fork +features are trying to address. + +That is pretty subjective, and very debatable. But ignoring the +debatableness of it, why is urgency even necessary for an improvement to +bitcoin? Should we wait until a problem is urgent to fix it? Or should we +get ahead of it so we don't risk making hasty mistakes? + +> Your aggression to your purpose is the antithesis of consensus, as it +indicates your incentives are external to it. + +This is a personal attack John, and there have been too many of those +lately. This is a completely unacceptable thing to say on this mailing +list. I ask that you take your words back and apologize. Please be more +objective and temper your strong emotions. + +You know what is antithetical to consensus? People throwing around personal +attacks, asserting that consensus is something without evidence, and +failing to acknowledge the many opinions out there that are different from +theirs. You write your email as if there's only one person in this world +who wants CTV. You know this isn't the case. + + +On Mon, May 2, 2022 at 3:56 AM John Carvalho via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Jeremy, +> +> The path to consensus is to propose things that everyone needs. Demand +> comes from the market, not the designers. +> +> Designers (engineers) solve problems with designs, but when they speculate +> and lead the process, they create problems instead. Bitcoin is not a place +> for speculative feature additions. Bitcoin cannot afford a culture of +> additive features no one is asking for. Bitcoin thrives in a culture of +> "NO." Rejection of change is Bitcoin's primary feature. +> +> There is NO HOPE of EVER getting the majority of Bitcoin users to be able +> to grasp, audit, and meaningfully consent to complicated new features, nor +> to assess how they may interact with existing features in undesirable ways +> or affect Bitcoin's incentive structure. To ignore this is a selfish +> egomania that too many devs succumb to. The public already trusts Core devs +> more than they probably should, and it is unwise to lean on that trust. +> +> You are of course welcome to try and research and document all of the +> details about how this plays out in practice, but you will fail to specify +> a path to approval or any sort of clear governance structure for ensuring +> that speculative features get into Bitcoin. You will seek and only see a +> bias that allows you to get what YOU want. Until you focus on what everyone +> wants, you will not reach consensus on anything. +> +> Bitcoin changes should solve obvious problems and provide easy wins on +> optimization, security, and privacy. Seek simplicity and efficiency, not +> complication. +> +> We have yet to saturate usage of the features we have added already in the +> past 5 years. Use those. It is becoming apparent over time that many +> features can be accomplished off-chain, or without a blockchain, or by +> merely anchoring into currently available bitcoin transaction types. +> +> There is simply no urgency or problem that any of the proposed soft fork +> features are trying to address. This includes APO, CTV, sidechain +> proposals, etc, etc. +> +> Your aggression to your purpose is the antithesis of consensus, as it +> indicates your incentives are external to it. +> +> -- +> John Carvalho +> CEO, Synonym.to <http://synonym.to/> +> +> +> On Mon, May 2, 2022 at 3:43 AM < +> bitcoin-dev-request@lists.linuxfoundation.org> wrote: +> +>> Send bitcoin-dev mailing list submissions to +>> bitcoin-dev@lists.linuxfoundation.org +>> +>> To subscribe or unsubscribe via the World Wide Web, visit +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> or, via email, send a message with subject or body 'help' to +>> bitcoin-dev-request@lists.linuxfoundation.org +>> +>> You can reach the person managing the list at +>> bitcoin-dev-owner@lists.linuxfoundation.org +>> +>> When replying, please edit your Subject line so it is more specific +>> than "Re: Contents of bitcoin-dev digest..." +>> +>> +>> Today's Topics: +>> +>> 1. Re: What to do when contentious soft fork activations are +>> attempted (Billy Tetrud) +>> 2. Working Towards Consensus (Jeremy Rubin) +>> +>> +>> ---------------------------------------------------------------------- +>> +>> Message: 1 +>> Date: Sun, 1 May 2022 14:14:29 -0500 +>> From: Billy Tetrud <billy.tetrud@gmail.com> +>> To: alicexbt <alicexbt@protonmail.com>, Bitcoin Protocol Discussion +>> <bitcoin-dev@lists.linuxfoundation.org> +>> Subject: Re: [bitcoin-dev] What to do when contentious soft fork +>> activations are attempted +>> Message-ID: +>> < +>> CAGpPWDb-T4OB0NKv7O5k9yhDQJtmag1QLqM1jJN9fQMoNTPLug@mail.gmail.com> +>> Content-Type: text/plain; charset="utf-8" +>> +>> +1 alicexbt +>> +>> We of course want knowledgeable bitcoiners who aren't knowledgeable about +>> a +>> certain proposal to be skeptical. But what we don't want is for that +>> natural skepticism-from-ignorance to be interpreted as opposition, or +>> really a strong signal of any kind. Any thoughts from ignorance, whether +>> self-aware or not, should be given small weight. It seems the vast +>> majority +>> of push back has been this kind of skepticism from ignorance. And to a +>> certain degree I think we want to give time for understanding to those who +>> have not participated in the first, second, third, etc round of discussion +>> on a proposal. It may not be reasonable to say "you had the last 2 years +>> of +>> time to voice your concern". +>> +>> Now that CTV is being taken seriously as a proposal, we probably should +>> give the community who is finally taking a serious look at it time to +>> understand, get their questions answered, and come to terms with it. This +>> is not to say that CTV as a technology or proposal has been rushed, or has +>> not had enough work put into it, but rather that the community as a whole +>> has not paid enough attention to it for long enough. +>> +>> The wrong approach is: "how do I yell more loudly next time I see +>> something +>> I'm uncomfortable with?" The right approach is to educate those who aren't +>> educated on the proposal and gather consensus on what people think when +>> they understand enough about it to contribute to that consensus. If you +>> care about consensus, you should respect the consensus process and be ok +>> with consensus being not your preferred outcome. If you don't care about +>> consensus, then you're basically attacking the bitcoin community. +>> +>> On Sun, May 1, 2022 at 3:22 AM alicexbt via bitcoin-dev < +>> bitcoin-dev@lists.linuxfoundation.org> wrote: +>> +>> > Hi Michael, +>> > +>> > Maybe the whole thing worked as designed. Some users identified what was +>> > going on, well known Bitcoin educators such as Andreas Antonopoulos, +>> Jimmy +>> > Song etc brought additional attention to the dangers, a URSF movement +>> > started to gain momentum and those attempting a contentious soft fork +>> > activation backed off. (Disappointingly Bitcoin Optech didn't cover my +>> > previous posts to this mailing list 1 +>> > < +>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html +>> >, +>> > 2 +>> > < +>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html +>> >, +>> > 3 +>> > < +>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html +>> > +>> > highlighting the dangers many months ago or recent posts. Normally +>> Optech +>> > is very high signal.) +>> > +>> > +>> > Some users have been misled and there is nothing great being achieved by +>> > doing this on social media. Andreas is clueless about BIP 119 and other +>> > covenant proposals. He is spreading misinformation and some of the URSF +>> > enthusiasts do not understand what are they even opposing or going to +>> run +>> > with risks involved. +>> > +>> > +>> > Answering the subject of this email: "What to do when contentious soft +>> > forks activations are attempted?" +>> > +>> > - Do not consider something contentious because someone said it on +>> mailing +>> > list +>> > - Do not spread misinformation +>> > - Read all posts in detail with different opinions +>> > - Avoid personal attacks +>> > - Look at the technical details, code etc. and comment on things that +>> > could be improved +>> > +>> > +>> > +>> > /dev/fd0 +>> > +>> > Sent with ProtonMail <https://protonmail.com/> secure email. +>> > +>> > ------- Original Message ------- +>> > On Saturday, April 30th, 2022 at 3:23 PM, Michael Folkson via +>> bitcoin-dev +>> > bitcoin-dev@lists.linuxfoundation.org wrote: +>> > +>> > +>> > I?ve been in two minds on whether to completely move on to other topics +>> or +>> > to formulate some thoughts on the recent attempt to activate a +>> contentious +>> > soft fork. In the interests of those of us who have wasted +>> > days/weeks/months of our time on this (with no personal upside) and who +>> > don?t want to repeat this exercise again I thought I should at least +>> raise +>> > the issue for discussion of what should be done differently if this is +>> > tried again in future. +>> > +>> > This could be Jeremy with OP_CTV at a later point (assuming it is still +>> > contentious) or anyone who wants to pick up a single opcode that is not +>> yet +>> > activated on Bitcoin and try to get miners to signal for it bypassing +>> > technical concerns from many developers, bypassing Bitcoin Core and +>> > bypassing users. +>> > +>> > Maybe the whole thing worked as designed. Some users identified what was +>> > going on, well known Bitcoin educators such as Andreas Antonopoulos, +>> Jimmy +>> > Song etc brought additional attention to the dangers, a URSF movement +>> > started to gain momentum and those attempting a contentious soft fork +>> > activation backed off. (Disappointingly Bitcoin Optech didn't cover my +>> > previous posts to this mailing list 1 +>> > < +>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html +>> >, +>> > 2 +>> > < +>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html +>> >, +>> > 3 +>> > < +>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html +>> > +>> > highlighting the dangers many months ago or recent posts. Normally +>> Optech +>> > is very high signal.) +>> > +>> > Alternatively this was the first time a contentious soft fork activation +>> > was attempted, we were all woefully unprepared for it and none of us +>> knew +>> > what we were doing. +>> > +>> > I?m unsure on the above. I?d be interested to hear thoughts. What I am +>> > sure of is that it is totally unacceptable for one individual to bring +>> the +>> > entire Bitcoin network to the brink of a chain split. There has to be a +>> > personal cost to that individual dissuading them from trying it again +>> > otherwise they?re motivated to try it again every week/month. Perhaps +>> the +>> > personal cost that the community is now prepared if that individual +>> tries +>> > it again is sufficient. I?m not sure. Obviously Bitcoin is a +>> permissionless +>> > network, Bitcoin Core and other open source projects are easily forked +>> and +>> > no authority (I?m certainly no authority) can stop things like this +>> > happening again. +>> > +>> > I?ll follow the responses if people have thoughts (I won't be responding +>> > to the instigators of this contentious soft fork activation attempt) but +>> > other than that I?d like to move on to other things than contentious +>> soft +>> > fork activations. Thanks to those who have expressed concerns publicly +>> (too +>> > many to name, Bob McElrath was often wording arguments better than I +>> could) +>> > and who were willing to engage with the URSF conversation. If an +>> individual +>> > can go directly to miners to get soft forks activated bypassing +>> technical +>> > concerns from many developers, bypassing Bitcoin Core and bypassing +>> users +>> > Bitcoin is fundamentally broken. The reason I still have hope that it +>> isn't +>> > is that during a period of general apathy some people were willing to +>> stand +>> > up and actively resist it. +>> > +>> > -- +>> > Michael Folkson +>> > Email: michaelfolkson at protonmail.com +>> > Keybase: michaelfolkson +>> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 +>> > +>> > _______________________________________________ +>> > bitcoin-dev mailing list +>> > bitcoin-dev@lists.linuxfoundation.org +>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> > +>> -------------- next part -------------- +>> An HTML attachment was scrubbed... +>> URL: < +>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220501/7158d8ed/attachment-0001.html +>> > +>> +>> ------------------------------ +>> +>> Message: 2 +>> Date: Sun, 1 May 2022 19:43:29 -0700 +>> From: Jeremy Rubin <jeremy.l.rubin@gmail.com> +>> To: Bitcoin development mailing list +>> <bitcoin-dev@lists.linuxfoundation.org> +>> Subject: [bitcoin-dev] Working Towards Consensus +>> Message-ID: +>> <CAD5xwhhdEgADWwLwbjRKp-UFCw9hHjDsc-L=pkiwW= +>> bmhFqBNw@mail.gmail.com> +>> Content-Type: text/plain; charset="utf-8" +>> +>> Developers, +>> +>> There is much to say about the events of the last two weeks and the +>> response to them. I've been searching for the right words to share here, +>> but I think it best that short of a more thoughtful writeup I start with a +>> timely small step with the below comments. +>> +>> First, let me be clear: I am not advancing a Speedy Trial(ST) activation +>> of +>> Bitcoin Improvement Proposal-119 (BIP-119) CheckTemplateVerify (CTV) at +>> this time. +>> +>> I'm skipping any discussion of the drama here. Most of you are interested +>> in developing Bitcoin, not drama. Let's try to keep this thread focused on +>> the actual work. I'll make some limited comments on the drama in a +>> separate +>> thread, for those who care to hear from me on the subject directly. +>> +>> I believe that the disinformation spread around my post ("7 Theses on a +>> next step for BIP-119"[0]) created three main negative outcomes within the +>> Bitcoin community: +>> +>> 1. Confusion about how Bitcoin's "technical consensus" works and how +>> changes are "approved". +>> 2. Fear about the safety of CTV and covenants more broadly. +>> 3. Misunderstandings around the properties of Speedy Trial, User Activated +>> Soft Fork (UASF), User Resisted Soft Fork (URSF), Soft Forks, Hard Forks, +>> and more. +>> +>> While I cannot take responsibility for the spread of the disinformation, I +>> do apologize to anyone dealing with it for the role my actions have had in +>> leading to the current circumstance. +>> +>> I personally take some solace in knowing that the only way out of this is +>> through it. The conversations happening now seem to have been more or less +>> inevitable, this has brought them to the surface, and as a technical +>> community we are able to address them head on if -- as individuals and +>> collectively -- we choose to. And, viewed through a certain lens, these +>> conversations represent incredibly important opportunities to participate +>> in defining the future of Bitcoin that would not be happening otherwise. +>> Ultimately, I am grateful to live in a time where I am able to play a +>> small +>> role in such an important process. This is the work. +>> +>> In the coming months, I expect the discourse to be messy, but I think the +>> work is clear cut that we should undertake at least the following: +>> +>> 1. Make great efforts to better document how Bitcoin's technical consensus +>> process works today, how it can be improved, and how changes may be +>> formally reviewed while still being unofficially advanced. +>> 2. Work diligently to address the concerns many in the community have +>> around the negative potential of covenants and better explain the +>> trade-offs between levels of functionality. +>> 3. Renew conversations about activation and release mechanisms and +>> re-examine our priors around why Speedy Trial may have been acceptable for +>> Taproot, was not acceptable for BIP-119, but may not be optimal long +>> term[1], and work towards processes that better captures the Bitcoin +>> network's diverse interests and requirements. +>> 4. Work towards thoroughly systematizing knowledge around covenant +>> technologies so that in the coming months we may work towards delivering a +>> coherent pathway for the Bitcoin technical community to evaluate and put +>> up +>> for offer to the broader community an upgrade or set of upgrades to +>> improve +>> Bitcoin's capabilities for self sovereignty, privacy, scalability, and +>> decentralization. +>> +>> This may not be the easiest path to take, but I believe that this work is +>> critical to the future of Bitcoin. I welcome all reading this to share +>> your +>> thoughts with this list on how we might work towards consensus going +>> forward, including any criticisms of my observations and recommendations +>> above. While I would expect nothing less than passionate debate when it +>> comes to Bitcoin, remember that at the end of the day we all largely share +>> a mission to make the world a freer place, even if we disagree about how +>> we +>> get there. +>> +>> Yours truly, +>> +>> Jeremy +>> +>> [0]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/ +>> [1]: http://r6.ca/blog/20210615T191422Z.html I quite enjoyed Roconnor's +>> detailed post on Speedy Trial +>> +>> -- +>> @JeremyRubin <https://twitter.com/JeremyRubin> +>> -------------- next part -------------- +>> An HTML attachment was scrubbed... +>> URL: < +>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220501/9009e65d/attachment.html +>> > +>> +>> ------------------------------ +>> +>> Subject: Digest Footer +>> +>> _______________________________________________ +>> bitcoin-dev mailing list +>> bitcoin-dev@lists.linuxfoundation.org +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> +>> +>> ------------------------------ +>> +>> End of bitcoin-dev Digest, Vol 84, Issue 4 +>> ****************************************** +>> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--000000000000bd004a05de1042b5 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">John,<div><br></div><div>> The path to consensus is to = +propose things that everyone needs.</div><div><br></div><div>If there's= + an insight here, it isn't clear what it is to me. As stated, this is s= +omething I can only 100% disagree with. Its possible that literally nothing= + about bitcoin is something=C2=A0that "everyone needs". Its prett= +y clear that not "everyone needs" taproot. Its even questionable = +whether "everyone needs" bitcoin. Are you really saying that no c= +hange should be added to bitcoin unless it is something literally all bitco= +in users are currently asking for, or maybe just will want to use sometime = +soon? The majority of bitcoin users don't even custody their own funds,= + so practically all features are something those users aren't using. If= + you want to convince people of whatever argument you're making, you= +9;re going to have to get a little more specific and rather less hyperbolic= +.=C2=A0</div><div><br></div><div>> Designers (engineers) solve problems = +with designs, but when they speculate and lead the=C2=A0process, they creat= +e problems instead.=C2=A0</div><div><br></div><div>How do you expect any im= +provement to ever happen to bitcoin if designers can't design things un= +less end-users have asked for it. Every good product designer knows that us= +ers do not know how to design products. Users have problems, designers crea= +te solutions. Companies that have implemented features that users directly = +ask for end up with awful bloated confusing products. Surely this isn't= + what you're suggesting we do in bitcoin, right?</div><div><br></div><d= +iv>> Seek simplicity and efficiency, not complication.</div><div><br></d= +iv><div>This is an extraordinarily ironic thing to say to Jeremy Rubin, who= + designed CTV with exactly that in mind. It is an incredibly simple opcode = +that doesn't allow recursive covenants or various other things that peo= +ple have been worried about in the past about covenants. I'm 99% confid= +ent that there is no simpler, more efficient, and less complicated covenant= + opcode than CTV that=C2=A0can even possibly be designed. The only one on p= +ar is TXHASH+CSFS and that has more complex implications than CTV.</div><di= +v><br></div><div>There are MANY people out there that would like more compl= +ex, more powerful covenants. "The market" is=C2=A0 in fact demand= +ing it. And yet because we must move carefully in Bitcoin, CTV is a comprom= +ise that focuses on simplicity and incremental change rather than radical c= +hange.=C2=A0</div><div><br></div><div>Do you really disagree that CTV was i= +ntended to be as simple as possible and achieves that goal?=C2=A0<br></div>= +<div><br></div><div>> There is simply no urgency or problem that any of = +the proposed soft fork features are trying to address.</div><div><br></div>= +<div>That is pretty subjective, and very debatable. But ignoring the debata= +bleness of it, why is urgency even necessary for an improvement to bitcoin?= + Should we wait until a problem is urgent to fix it? Or should we get ahead= + of it so we don't risk making hasty mistakes?=C2=A0</div><div><br></di= +v><div>> Your aggression to your purpose is the antithesis of consensus,= + as it indicates your incentives are external to it.</div><div><br></div><d= +iv>This is a personal attack John, and there have been too many of those la= +tely. This is a completely unacceptable thing to say on this mailing list. = +I ask that you take your words back and apologize. Please be more objective= + and temper your strong emotions.=C2=A0</div><div><br></div><div>You know w= +hat is antithetical to consensus? People throwing around personal attacks, = +asserting that consensus is something without evidence, and failing to ackn= +owledge the many opinions out there that are different from theirs. You wri= +te your email as if there's only one person in this world who wants CTV= +. You know this isn't the case.=C2=A0<br></div><div><br></div></div><br= +><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, M= +ay 2, 2022 at 3:56 AM John Carvalho via bitcoin-dev <<a href=3D"mailto:b= +itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l= +inuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote= +" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);= +padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">Jeremy,</div><div dir= +=3D"ltr"><br></div><div dir=3D"ltr">The path to consensus is to propose thi= +ngs that everyone needs. Demand comes from the market, not the designers.= +=C2=A0</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Designers (engineer= +s) solve problems with designs, but when they speculate and lead the=C2=A0p= +rocess, they create problems instead. Bitcoin is not a place for speculativ= +e feature additions. Bitcoin cannot afford a culture of additive features n= +o one is asking for. Bitcoin thrives in a culture of "NO." Reject= +ion of change is Bitcoin's primary feature.</div><div dir=3D"ltr"><br><= +/div><div>There is NO HOPE of EVER getting=C2=A0the majority of Bitcoin use= +rs to be able to grasp, audit, and meaningfully consent to complicated new = +features, nor to assess=C2=A0how they may interact with existing features i= +n undesirable ways or affect Bitcoin's incentive structure. To ignore t= +his is a selfish egomania that too many devs succumb to. The public already= + trusts Core devs more than they probably should, and it is unwise to lean = +on that trust.</div><div dir=3D"ltr"><br></div><div>You are of course welco= +me to try and research and document all of the details about how this plays= + out in practice, but you will fail to specify a path to approval or any so= +rt of clear governance structure for ensuring that speculative features get= + into Bitcoin. You will seek and only see a bias that allows you to get wha= +t YOU want. Until you focus=C2=A0on what everyone wants, you will not reach= + consensus on anything.</div><div><br></div><div>Bitcoin changes should=C2= +=A0solve obvious problems=C2=A0and provide easy wins on optimization, secur= +ity, and privacy. Seek simplicity and efficiency, not complication.</div><d= +iv><br></div><div>We have yet to saturate usage of the features we have add= +ed already in the past 5 years. Use those. It is becoming apparent over tim= +e that many features can be accomplished off-chain, or without a blockchain= +, or by merely anchoring into currently available bitcoin transaction types= +.</div><div><br></div><div>There is simply no urgency or problem that any o= +f the proposed soft fork features are trying to address. This includes APO,= + CTV, sidechain proposals, etc, etc.</div><div><br></div><div>Your aggressi= +on to your purpose is the antithesis of consensus, as it indicates your inc= +entives are external to it.</div><div dir=3D"ltr"><br clear=3D"all"><div><d= +iv dir=3D"ltr"><div dir=3D"ltr"><span style=3D"color:rgb(34,34,34)">--</spa= +n><br style=3D"color:rgb(34,34,34)"><div dir=3D"ltr" style=3D"color:rgb(34,= +34,34)"><div dir=3D"ltr">John Carvalho</div><div dir=3D"ltr">CEO,=C2=A0<a h= +ref=3D"http://synonym.to/" style=3D"color:rgb(17,85,204)" target=3D"_blank"= +>Synonym.to</a><br><div><font size=3D"1"><br></font></div></div></div></div= +></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D= +"gmail_attr">On Mon, May 2, 2022 at 3:43 AM <<a href=3D"mailto:bitcoin-d= +ev-request@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev-request= +@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gma= +il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2= +04,204);padding-left:1ex">Send bitcoin-dev mailing list submissions to<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev@lists.linuxfounda= +tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> +<br> +To subscribe or unsubscribe via the World Wide Web, visit<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.linuxfoundation.org/ma= +ilman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://li= +sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br> +or, via email, send a message with subject or body 'help' to<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-request@lists.lin= +uxfoundation.org" target=3D"_blank">bitcoin-dev-request@lists.linuxfoundati= +on.org</a><br> +<br> +You can reach the person managing the list at<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-owner@lists.linux= +foundation.org" target=3D"_blank">bitcoin-dev-owner@lists.linuxfoundation.o= +rg</a><br> +<br> +When replying, please edit your Subject line so it is more specific<br> +than "Re: Contents of bitcoin-dev digest..."<br> +<br> +<br> +Today's Topics:<br> +<br> +=C2=A0 =C2=A01. Re: What to do when contentious soft fork activations are<b= +r> +=C2=A0 =C2=A0 =C2=A0 attempted (Billy Tetrud)<br> +=C2=A0 =C2=A02. Working Towards Consensus (Jeremy Rubin)<br> +<br> +<br> +----------------------------------------------------------------------<br> +<br> +Message: 1<br> +Date: Sun, 1 May 2022 14:14:29 -0500<br> +From: Billy Tetrud <<a href=3D"mailto:billy.tetrud@gmail.com" target=3D"= +_blank">billy.tetrud@gmail.com</a>><br> +To: alicexbt <<a href=3D"mailto:alicexbt@protonmail.com" target=3D"_blan= +k">alicexbt@protonmail.com</a>>,=C2=A0 Bitcoin Protocol Discussion<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:bitcoin-dev@lists.linuxfo= +undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g= +t;<br> +Subject: Re: [bitcoin-dev] What to do when contentious soft fork<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 activations are attempted<br> +Message-ID:<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:CAGpPWDb-T4OB0NKv7O5k9yhD= +QJtmag1QLqM1jJN9fQMoNTPLug@mail.gmail.com" target=3D"_blank">CAGpPWDb-T4OB0= +NKv7O5k9yhDQJtmag1QLqM1jJN9fQMoNTPLug@mail.gmail.com</a>><br> +Content-Type: text/plain; charset=3D"utf-8"<br> +<br> ++1 alicexbt<br> +<br> +We of course want knowledgeable bitcoiners who aren't knowledgeable abo= +ut a<br> +certain proposal to be skeptical. But what we don't want is for that<br= +> +natural skepticism-from-ignorance to be interpreted as opposition, or<br> +really a strong signal of any kind. Any thoughts from ignorance, whether<br= +> +self-aware or not, should be given small weight. It seems the vast majority= +<br> +of push back has been this kind of skepticism from ignorance. And to a<br> +certain degree I think we want to give time for understanding to those who<= +br> +have not participated in the first, second, third, etc round of discussion<= +br> +on a proposal. It may not be reasonable to say "you had the last 2 yea= +rs of<br> +time to voice your concern".<br> +<br> +Now that CTV is being taken seriously as a proposal, we probably should<br> +give the community who is finally taking a serious look at it time to<br> +understand, get their questions answered, and come to terms with it. This<b= +r> +is not to say that CTV as a technology or proposal has been rushed, or has<= +br> +not had enough work put into it, but rather that the community as a whole<b= +r> +has not paid enough attention to it for long enough.<br> +<br> +The wrong approach is: "how do I yell more loudly next time I see some= +thing<br> +I'm uncomfortable with?" The right approach is to educate those wh= +o aren't<br> +educated on the proposal and gather consensus on what people think when<br> +they understand enough about it to contribute to that consensus. If you<br> +care about consensus, you should respect the consensus process and be ok<br= +> +with consensus being not your preferred outcome. If you don't care abou= +t<br> +consensus, then you're basically attacking the bitcoin community.<br> +<br> +On Sun, May 1, 2022 at 3:22 AM alicexbt via bitcoin-dev <<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +<br> +> Hi Michael,<br> +><br> +> Maybe the whole thing worked as designed. Some users identified what w= +as<br> +> going on, well known Bitcoin educators such as Andreas Antonopoulos, J= +immy<br> +> Song etc brought additional attention to the dangers, a URSF movement<= +br> +> started to gain momentum and those attempting a contentious soft fork<= +br> +> activation backed off. (Disappointingly Bitcoin Optech didn't cove= +r my<br> +> previous posts to this mailing list 1<br> +> <<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev= +/2021-October/019535.html" rel=3D"noreferrer" target=3D"_blank">https://lis= +ts.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html</a>&g= +t;,<br> +> 2<br> +> <<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev= +/2022-January/019728.html" rel=3D"noreferrer" target=3D"_blank">https://lis= +ts.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html</a>&g= +t;,<br> +> 3<br> +> <<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev= +/2022-April/020235.html" rel=3D"noreferrer" target=3D"_blank">https://lists= +.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html</a>><b= +r> +> highlighting the dangers many months ago or recent posts. Normally Opt= +ech<br> +> is very high signal.)<br> +><br> +><br> +> Some users have been misled and there is nothing great being achieved = +by<br> +> doing this on social media. Andreas is clueless about BIP 119 and othe= +r<br> +> covenant proposals. He is spreading misinformation and some of the URS= +F<br> +> enthusiasts do not understand what are they even opposing or going to = +run<br> +> with risks involved.<br> +><br> +><br> +> Answering the subject of this email: "What to do when contentious= + soft<br> +> forks activations are attempted?"<br> +><br> +> - Do not consider something contentious because someone said it on mai= +ling<br> +> list<br> +> - Do not spread misinformation<br> +> - Read all posts in detail with different opinions<br> +> - Avoid personal attacks<br> +> - Look at the technical details, code etc. and comment on things that<= +br> +> could be improved<br> +><br> +><br> +><br> +> /dev/fd0<br> +><br> +> Sent with ProtonMail <<a href=3D"https://protonmail.com/" rel=3D"no= +referrer" target=3D"_blank">https://protonmail.com/</a>> secure email.<b= +r> +><br> +> ------- Original Message -------<br> +> On Saturday, April 30th, 2022 at 3:23 PM, Michael Folkson via bitcoin-= +dev<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a> wrote:<br> +><br> +><br> +> I?ve been in two minds on whether to completely move on to other topic= +s or<br> +> to formulate some thoughts on the recent attempt to activate a content= +ious<br> +> soft fork. In the interests of those of us who have wasted<br> +> days/weeks/months of our time on this (with no personal upside) and wh= +o<br> +> don?t want to repeat this exercise again I thought I should at least r= +aise<br> +> the issue for discussion of what should be done differently if this is= +<br> +> tried again in future.<br> +><br> +> This could be Jeremy with OP_CTV at a later point (assuming it is stil= +l<br> +> contentious) or anyone who wants to pick up a single opcode that is no= +t yet<br> +> activated on Bitcoin and try to get miners to signal for it bypassing<= +br> +> technical concerns from many developers, bypassing Bitcoin Core and<br= +> +> bypassing users.<br> +><br> +> Maybe the whole thing worked as designed. Some users identified what w= +as<br> +> going on, well known Bitcoin educators such as Andreas Antonopoulos, J= +immy<br> +> Song etc brought additional attention to the dangers, a URSF movement<= +br> +> started to gain momentum and those attempting a contentious soft fork<= +br> +> activation backed off. (Disappointingly Bitcoin Optech didn't cove= +r my<br> +> previous posts to this mailing list 1<br> +> <<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev= +/2021-October/019535.html" rel=3D"noreferrer" target=3D"_blank">https://lis= +ts.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html</a>&g= +t;,<br> +> 2<br> +> <<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev= +/2022-January/019728.html" rel=3D"noreferrer" target=3D"_blank">https://lis= +ts.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html</a>&g= +t;,<br> +> 3<br> +> <<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev= +/2022-April/020235.html" rel=3D"noreferrer" target=3D"_blank">https://lists= +.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html</a>><b= +r> +> highlighting the dangers many months ago or recent posts. Normally Opt= +ech<br> +> is very high signal.)<br> +><br> +> Alternatively this was the first time a contentious soft fork activati= +on<br> +> was attempted, we were all woefully unprepared for it and none of us k= +new<br> +> what we were doing.<br> +><br> +> I?m unsure on the above. I?d be interested to hear thoughts. What I am= +<br> +> sure of is that it is totally unacceptable for one individual to bring= + the<br> +> entire Bitcoin network to the brink of a chain split. There has to be = +a<br> +> personal cost to that individual dissuading them from trying it again<= +br> +> otherwise they?re motivated to try it again every week/month. Perhaps = +the<br> +> personal cost that the community is now prepared if that individual tr= +ies<br> +> it again is sufficient. I?m not sure. Obviously Bitcoin is a permissio= +nless<br> +> network, Bitcoin Core and other open source projects are easily forked= + and<br> +> no authority (I?m certainly no authority) can stop things like this<br= +> +> happening again.<br> +><br> +> I?ll follow the responses if people have thoughts (I won't be resp= +onding<br> +> to the instigators of this contentious soft fork activation attempt) b= +ut<br> +> other than that I?d like to move on to other things than contentious s= +oft<br> +> fork activations. Thanks to those who have expressed concerns publicly= + (too<br> +> many to name, Bob McElrath was often wording arguments better than I c= +ould)<br> +> and who were willing to engage with the URSF conversation. If an indiv= +idual<br> +> can go directly to miners to get soft forks activated bypassing techni= +cal<br> +> concerns from many developers, bypassing Bitcoin Core and bypassing us= +ers<br> +> Bitcoin is fundamentally broken. The reason I still have hope that it = +isn't<br> +> is that during a period of general apathy some people were willing to = +stand<br> +> up and actively resist it.<br> +><br> +> --<br> +> Michael Folkson<br> +> Email: michaelfolkson at <a href=3D"http://protonmail.com" rel=3D"nore= +ferrer" target=3D"_blank">protonmail.com</a><br> +> Keybase: michaelfolkson<br> +> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3<br> +><br> +> _______________________________________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a><br> +> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= +dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org= +/mailman/listinfo/bitcoin-dev</a><br> +><br> +-------------- next part --------------<br> +An HTML attachment was scrubbed...<br> +URL: <<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/= +attachments/20220501/7158d8ed/attachment-0001.html" rel=3D"noreferrer" targ= +et=3D"_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attach= +ments/20220501/7158d8ed/attachment-0001.html</a>><br> +<br> +------------------------------<br> +<br> +Message: 2<br> +Date: Sun, 1 May 2022 19:43:29 -0700<br> +From: Jeremy Rubin <<a href=3D"mailto:jeremy.l.rubin@gmail.com" target= +=3D"_blank">jeremy.l.rubin@gmail.com</a>><br> +To: Bitcoin development mailing list<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:bitcoin-dev@lists.linuxfo= +undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g= +t;<br> +Subject: [bitcoin-dev] Working Towards Consensus<br> +Message-ID:<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAD5xwhhdEgADWwLwbjRKp-UFCw9hHjDsc-L=3Dpkiw= +W=3D<a href=3D"mailto:bmhFqBNw@mail.gmail.com" target=3D"_blank">bmhFqBNw@m= +ail.gmail.com</a>><br> +Content-Type: text/plain; charset=3D"utf-8"<br> +<br> +Developers,<br> +<br> +There is much to say about the events of the last two weeks and the<br> +response to them. I've been searching for the right words to share here= +,<br> +but I think it best that short of a more thoughtful writeup I start with a<= +br> +timely small step with the below comments.<br> +<br> +First, let me be clear: I am not advancing a Speedy Trial(ST) activation of= +<br> +Bitcoin Improvement Proposal-119 (BIP-119) CheckTemplateVerify (CTV) at<br> +this time.<br> +<br> +I'm skipping any discussion of the drama here. Most of you are interest= +ed<br> +in developing Bitcoin, not drama. Let's try to keep this thread focused= + on<br> +the actual work. I'll make some limited comments on the drama in a sepa= +rate<br> +thread, for those who care to hear from me on the subject directly.<br> +<br> +I believe that the disinformation spread around my post ("7 Theses on = +a<br> +next step for BIP-119"[0]) created three main negative outcomes within= + the<br> +Bitcoin community:<br> +<br> +1. Confusion about how Bitcoin's "technical consensus" works = +and how<br> +changes are "approved".<br> +2. Fear about the safety of CTV and covenants more broadly.<br> +3. Misunderstandings around the properties of Speedy Trial, User Activated<= +br> +Soft Fork (UASF), User Resisted Soft Fork (URSF), Soft Forks, Hard Forks,<b= +r> +and more.<br> +<br> +While I cannot take responsibility for the spread of the disinformation, I<= +br> +do apologize to anyone dealing with it for the role my actions have had in<= +br> +leading to the current circumstance.<br> +<br> +I personally take some solace in knowing that the only way out of this is<b= +r> +through it. The conversations happening now seem to have been more or less<= +br> +inevitable, this has brought them to the surface, and as a technical<br> +community we are able to address them head on if -- as individuals and<br> +collectively -- we choose to. And, viewed through a certain lens, these<br> +conversations represent incredibly important opportunities to participate<b= +r> +in defining the future of Bitcoin that would not be happening otherwise.<br= +> +Ultimately, I am grateful to live in a time where I am able to play a small= +<br> +role in such an important process. This is the work.<br> +<br> +In the coming months, I expect the discourse to be messy, but I think the<b= +r> +work is clear cut that we should undertake at least the following:<br> +<br> +1. Make great efforts to better document how Bitcoin's technical consen= +sus<br> +process works today, how it can be improved, and how changes may be<br> +formally reviewed while still being unofficially advanced.<br> +2. Work diligently to address the concerns many in the community have<br> +around the negative potential of covenants and better explain the<br> +trade-offs between levels of functionality.<br> +3. Renew conversations about activation and release mechanisms and<br> +re-examine our priors around why Speedy Trial may have been acceptable for<= +br> +Taproot, was not acceptable for BIP-119, but may not be optimal long<br> +term[1], and work towards processes that better captures the Bitcoin<br> +network's diverse interests and requirements.<br> +4. Work towards thoroughly systematizing knowledge around covenant<br> +technologies so that in the coming months we may work towards delivering a<= +br> +coherent pathway for the Bitcoin technical community to evaluate and put up= +<br> +for offer to the broader community an upgrade or set of upgrades to improve= +<br> +Bitcoin's capabilities for self sovereignty, privacy, scalability, and<= +br> +decentralization.<br> +<br> +This may not be the easiest path to take, but I believe that this work is<b= +r> +critical to the future of Bitcoin. I welcome all reading this to share your= +<br> +thoughts with this list on how we might work towards consensus going<br> +forward, including any criticisms of my observations and recommendations<br= +> +above. While I would expect nothing less than passionate debate when it<br> +comes to Bitcoin, remember that at the end of the day we all largely share<= +br> +a mission to make the world a freer place, even if we disagree about how we= +<br> +get there.<br> +<br> +Yours truly,<br> +<br> +Jeremy<br> +<br> +[0]: <a href=3D"https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/" rel= +=3D"noreferrer" target=3D"_blank">https://rubin.io/bitcoin/2022/04/17/next-= +steps-bip119/</a><br> +[1]: <a href=3D"http://r6.ca/blog/20210615T191422Z.html" rel=3D"noreferrer"= + target=3D"_blank">http://r6.ca/blog/20210615T191422Z.html</a> I quite enjo= +yed Roconnor's<br> +detailed post on Speedy Trial<br> +<br> +--<br> +@JeremyRubin <<a href=3D"https://twitter.com/JeremyRubin" rel=3D"norefer= +rer" target=3D"_blank">https://twitter.com/JeremyRubin</a>><br> +-------------- next part --------------<br> +An HTML attachment was scrubbed...<br> +URL: <<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/= +attachments/20220501/9009e65d/attachment.html" rel=3D"noreferrer" target=3D= +"_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments= +/20220501/9009e65d/attachment.html</a>><br> +<br> +------------------------------<br> +<br> +Subject: Digest Footer<br> +<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +<br> +<br> +------------------------------<br> +<br> +End of bitcoin-dev Digest, Vol 84, Issue 4<br> +******************************************<br> +</blockquote></div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--000000000000bd004a05de1042b5-- + + |