Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4A55AC000B for ; Fri, 11 Mar 2022 00:12:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 31C2C40556 for ; Fri, 11 Mar 2022 00:12:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=blockstream-com.20210112.gappssmtp.com 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 FrU4F1dKuPsD for ; Fri, 11 Mar 2022 00:12:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) by smtp2.osuosl.org (Postfix) with ESMTPS id D77A04014E for ; Fri, 11 Mar 2022 00:12:31 +0000 (UTC) Received: by mail-qk1-x72e.google.com with SMTP id q4so5814625qki.11 for ; Thu, 10 Mar 2022 16:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=UVCxasCsBI6hwWd7PFfDFdLogCUYpt99zpVPlVzvra4=; b=M30tzsoXz2DdGGXsIiYQreldyyID4GNy9p1MklMD1gVvtfz78SwIKkKHrnV620VZWl auHqrEM1yQR6kGCZgYK6IWuve4pcnZXSr6+etjlWn90hN1OkCEs/+gHylDk0PP3VRkvQ stsxCOT/HiZPUoKagBEF1JiysELyW9jEBjra2WSLLHIWv4WTDsb3VSt6XPTRxJha2BrS 2r4BdVKA0h/XUkW9gudl+tyv+MqE8OUxhPCKVwrWMVTskb+++fzOy5c6IbBzVF3T0eHs j6K1Z9AXlzQDqk6+joiWZS377DRKFwUXneTN7Yx5kDKufgXRc9ov81vYZtjjsQYnriuM V3kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UVCxasCsBI6hwWd7PFfDFdLogCUYpt99zpVPlVzvra4=; b=BDEZaMtnMRSgelmKapX+FsX/oVaDwQSWmrgTsNZIfymDJdYjMeidsTvfCXnlnURzWH renNpI+RLKWDbHqQVu4iK+ilciG1eLhnUOv/SlDBxXgzywiLpUj9Jk8TfA29wohWez5u 5Kqv8fhwqqua6gZ6oUB3Vn+oJSImGBRC+6IsKaCpfYo1Ecm5cZmtJGV2WY4KK1FJTI2f Ea8UC4i4c1u350l8NPdSNLDfSupfbUdFAVvITv0hCgIThMXC/nKrJnyXk5OxJJZoDl8w Z7fMeZPU5QQlTRXfxrpMO2Wv8LmGRPnZK/c8u/6RnwlsDNcfaPCBgzX03tnL5eKHdigx nhug== X-Gm-Message-State: AOAM533I1ZuGxCfn1Smi4Mb7eR2ccm7lZCy3DOWbQda+LZaIBpHpRIkh cbAug46xJ3uJL0XMxqR7vErM5r2eHrxuU86j0K3u85oZSFB6ZQ== X-Google-Smtp-Source: ABdhPJwk4zySLwUxrBEKLX8Z4CdVEvmkbu0l7q7U5+g+2QA4Bi/0a+BGGo/yaMAfCXH5ge2BWh9pCHbJzKti9hzphWQ= X-Received: by 2002:a05:620a:2082:b0:67b:1235:2ff2 with SMTP id e2-20020a05620a208200b0067b12352ff2mr4872990qka.640.1646957550352; Thu, 10 Mar 2022 16:12:30 -0800 (PST) MIME-Version: 1.0 From: "Russell O'Connor" Date: Thu, 10 Mar 2022 19:12:19 -0500 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000bfd17a05d9e62ffc" Subject: [bitcoin-dev] Speedy Trial 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: Fri, 11 Mar 2022 00:12:33 -0000 --000000000000bfd17a05d9e62ffc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu., Mar. 10, 2022, 08:04 Jorge Tim=C3=B3n via bitcoin-dev, < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > You're right, we shouldn't get personal. We shouldn't ignore feedback fro= m > me, mark friedenbach or luke just because of who it comes from. > For goodness sake Jorge, enough with the persecution complex. As the person who initially proposed the Speedy Trial deployment design, I can say it was designed to take in account those concerns raised by luke-jr and the "no-miner-veto" faction. I also listened to the "devs-do-not-decide" faction and the "no-divegent-consensus-rules" faction and their concerns. The "no-miner-veto" concerns are, to an extent, addressed by the short timeline of Speedy Trial. No more waiting 2 years on the miners dragging their feet. If ST fails to active then we are back where we started with at most a few weeks lost. And those weeks aren't really lost if they would have been wasted away anyways trying to find broad consensus on another deployment mechanism. I get that you don't like the design of Speedy Trial. You may even object that it fails to really address your concerns by leaving open how to follow up a failed Speedy Trial deployment. But regardless of how you feel, I believe I did meaningfully address the those miner-veto concerns and other people agree with me. If you are so concerned about listening to legitimate criticism, maybe you can design a new deployment mechanism that addresses the concerns of the "devs-do-not-decide" faction and the "no-divegent-consensus-rules" faction. Or do you feel that their concerns are illegitimate? Maybe, by sheer coincidence, all people you disagree with have illegitimate concerns while only your concerns are legitimate. A major contender to the Speedy Trial design at the time was to mandate eventual forced signalling, championed by luke-jr. It turns out that, at the time of that proposal, a large amount of hash power simply did not have the firmware required to support signalling. That activation proposal never got broad consensus, and rightly so, because in retrospect we see that the design might have risked knocking a significant fraction of mining power offline if it had been deployed. Imagine if the firmware couldn't be quickly updated or imagine if the problem had been hardware related. --000000000000bfd17a05d9e62ffc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu., Mar. 10, 2022, 08:04 Jorge Tim=C3=B3n via= bitcoin-dev, <bitcoin-dev@lists.linuxfoundation.or= g> wrote:
=


You're right, we shouldn't get personal. We shou= ldn't ignore feedback from me, mark friedenbach or luke just because of= who it comes from.

For goodness sake Jorge, enough with the persecution c= omplex.

As the person wh= o initially proposed the Speedy Trial deployment design, I can say it was d= esigned to take in account those concerns raised by luke-jr and the "n= o-miner-veto" faction.=C2=A0 I also listened to the "devs-do-not-= decide" faction and the "no-divegent-consensus-rules" factio= n and their concerns.

Th= e "no-miner-veto" concerns are, to an extent, addressed by the sh= ort timeline of Speedy Trial.=C2=A0 No more waiting 2 years on the miners d= ragging their feet.=C2=A0 If ST fails to active then we are back where we s= tarted with at most a few weeks lost.=C2=A0 And those weeks aren't real= ly lost if they would have been wasted away anyways trying to find broad co= nsensus on another deployment mechanism.

<= div dir=3D"auto">I get that you don't like the design of Speedy Trial.= =C2=A0 You may even object that it fails to really address your concerns by= leaving open how to follow up a failed Speedy Trial deployment.=C2=A0 But = regardless of how you feel, I believe I did meaningfully address the those = miner-veto concerns and other people agree with me.
=
If you are so concerned about listening to legi= timate criticism, maybe you can design a new deployment mechanism that addr= esses the concerns of the "devs-do-not-decide" faction and the &q= uot;no-divegent-consensus-rules" faction.=C2=A0 Or do you feel that th= eir concerns are illegitimate?=C2=A0 Maybe, by sheer coincidence, all peopl= e you disagree with have illegitimate concerns while only your concerns are= legitimate.

A major con= tender to the Speedy Trial design at the time was to mandate eventual force= d signalling, championed by luke-jr.=C2=A0 It turns out that, at the time o= f that proposal, a large amount of hash power simply did not have the firmw= are required to support signalling.=C2=A0 That activation proposal never go= t broad consensus, and rightly so, because in retrospect we see that the de= sign might have risked knocking a significant fraction of mining power offl= ine if it had been deployed.=C2=A0 Imagine if the firmware couldn't be = quickly updated or imagine if the problem had been hardware related.
<= div dir=3D"auto">
--000000000000bfd17a05d9e62ffc--