From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 50D87C002D for ; Tue, 26 Apr 2022 13:06:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 4B3EF41803 for ; Tue, 26 Apr 2022 13:06:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=q32-com.20210112.gappssmtp.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 ahQqLUS-tj46 for ; Tue, 26 Apr 2022 13:06:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by smtp4.osuosl.org (Postfix) with ESMTPS id BDF3D417D2 for ; Tue, 26 Apr 2022 13:06:11 +0000 (UTC) Received: by mail-lf1-x129.google.com with SMTP id p12so26282980lfs.5 for ; Tue, 26 Apr 2022 06:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r1/gJBauazLET1FLLQL0VIbzsWBXQ96QVhsBV9T+LkA=; b=S2AN9+JGSMN05zoGyK4EAyATj60uVm8dUfooa+fR6xtRTY7SAPAHZOnFrXMZzn+2DH 6blyeWcpzvt6OqxYuFb8c7rdIdgnwSmSTm6unYPThBVzNInBK5R6h/nX+Pm9ZghM874F 7tEri28jEyDteo+U3R5V+8sA/8nXnq3KvhdVATSalllEwZgMwIMN5FQYCsTmyyeVLAmX wnDWdsEqQuDAZgyuwLPWCE89VRFY6IUso1ZhrEtLKUtpBL55Yb2dpl9+JDwOxih8CdJT u4XYxKPgmt5sMu6y1gbYJxRWdoCEBDdt3Y9h5Pk1JexzPgShhlaXXBr39+iPUzh5x0pz 4aWQ== 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:cc; bh=r1/gJBauazLET1FLLQL0VIbzsWBXQ96QVhsBV9T+LkA=; b=CQNVK7zeYylpxqL/8CGnPcu5KqXse025An2fXIL4XaQvRtZtwvo+/YDc7OJ3/poXYj WV8U9dTxmn27p7F2R7Azb1pRR7LfHctqFDTTrCpl027PWWXdoKz9CiOODGMqc5YxyCAM yvkhNvX+YLwuZc68d6Muth82gbQTSZUKFGu0icQ9AGuXln+Td9pRs0WP3YxGpf123Z// 5s81I/yB1bdrHlUXfKNbmIsEiKPJyCrj9lQx2i5ERMeYWM8rXzpIhZqN4JV9aLDmcUyA IiGZerzfFmuH6xX1m1Ndl4AikSLzbZfWKitib/y+vO7XSDcLYFRx0FlzLntyXhK9pUnU qGZg== X-Gm-Message-State: AOAM532T0gsoE2O/rnWbVNuKLco/WXt+MIGXUrl3G4o0B6GESza8Ti9p dZ64nJA8Xv6XZI+y4rN2Pj9k2cxNrbLuGAezpelS5/I= X-Google-Smtp-Source: ABdhPJzJo4XC2uLnb29XvDUpb9xNFU6Orf66L7q7+M1YFKhO+n3iEYFQFVXNInARkJau3aFL57BSWAsyrNrP/s0gfsE= X-Received: by 2002:a19:ad46:0:b0:46b:b1a4:ffd5 with SMTP id s6-20020a19ad46000000b0046bb1a4ffd5mr16469656lfd.103.1650978367983; Tue, 26 Apr 2022 06:06:07 -0700 (PDT) MIME-Version: 1.0 References: <20220330042106.GA13161@erisian.com.au> <20220411130522.GA3633@erisian.com.au> <20220424121429.GA7363@erisian.com.au> <20220425170012.GA7453@erisian.com.au> <20220426054214.GA7933@erisian.com.au> In-Reply-To: <20220426054214.GA7933@erisian.com.au> From: Erik Aronesty Date: Tue, 26 Apr 2022 09:05:56 -0400 Message-ID: To: Anthony Towns , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000027d59405dd8e5b91" X-Mailman-Approved-At: Tue, 26 Apr 2022 16:32:07 +0000 Subject: Re: [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: Tue, 26 Apr 2022 13:06:13 -0000 --00000000000027d59405dd8e5b91 Content-Type: text/plain; charset="UTF-8" - it occurs to me that the real problem we have isn't whether miners lead or users lead. we know that users lead, we just need miners to be "ready" and have time to upgrade their software - in the case of "evil" forks, i also don't need or want miners to "defend" bitcoin... (if bitcoin is so broken that a bad fork gets past all of the users, the miners have lost their purpose, so that is a fallacy of reification and should be ignored) - we cannot measure user consensus in any systematic way, or else we resort to gaming the system or centralization - wallet votes (sign a message signalling... ), can cause centralization pressures - node signals (node published signal) will be sybil attacked - eyeballs... (lol) - can we all agree that this verbal and social wrangling and chest pounding seems, right now, to remain the best system of achieving consensus? or can we do better? On Tue, Apr 26, 2022 at 1:42 AM Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, Apr 25, 2022 at 11:26:09AM -0600, Keagan McClelland via > bitcoin-dev wrote: > > > Semi-mandatory in that only "threshold" blocks must signal, so if > > only 4% or 9% of miners aren't signalling and the threshold is set > > at 95% or 90%, no blocks will be orphaned. > > How do nodes decide on which blocks are orphaned if only some of them > have > > to signal, and others don't? Is it just any block that would cause the > > whole threshold period to fail? > > Yes, exactly those. See [0] or [1]. > > [0] > https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Mandatory_signalling > > [1] https://github.com/bitcoin/bips/pull/1021 > (err, you apparently acked that PR) > > Cheers, > aj > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000027d59405dd8e5b91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
- it occurs to me that the real problem we have isn't = whether miners lead or users lead.=C2=A0 =C2=A0we know that users lead, we = just need miners to be "ready" and have time to upgrade their sof= tware

=C2=A0- in the case of "evil" forks, i a= lso don't need or want miners to "defend" bitcoin... (if bitc= oin is so broken that a bad fork gets past all of the users, the miners hav= e lost their purpose, so that is a fallacy of reification and should be ign= ored)

=C2=A0- we cannot measure user consensus in any systematic way= , or else we resort to gaming the system or centralization=C2=A0
=
=C2=A0 =C2=A0 - wallet votes (sign a message signalling... )= , can cause centralization pressures
=C2=A0 =C2=A0 - node signals= (node published signal) will be sybil attacked
=C2=A0 =C2=A0 - e= yeballs... (lol)

=C2=A0- can we all agree that thi= s verbal and social wrangling and chest pounding seems, right now, to remai= n the best system of achieving consensus?=C2=A0 or can we do better?
<= div>








<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 26, 2022 at 1:42 AM Anthon= y Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Mon, Apr 25, 2022 at 11:2= 6:09AM -0600, Keagan McClelland via bitcoin-dev wrote:
> > Semi-mandatory in that only "threshold" blocks must sig= nal, so if
>=C2=A0 =C2=A0 =C2=A0only 4% or 9% of miners aren't signalling and t= he threshold is set
>=C2=A0 =C2=A0 =C2=A0at 95% or 90%, no blocks will be orphaned.
> How do nodes decide on which blocks are orphaned if only some of them = have
> to signal, and others don't? Is it just any block that would cause= the
> whole threshold period to fail?

Yes, exactly those. See [0] or [1].

[0] https://githu= b.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Mandatory_signalling<= br>
[1] https://github.com/bitcoin/bips/pull/1021
=C2=A0 =C2=A0 (err, you apparently acked that PR)

Cheers,
aj

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000027d59405dd8e5b91--