Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 941EAC0001 for ; Sun, 28 Feb 2021 20:44:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 6E4754300A for ; Sun, 28 Feb 2021 20:44:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20150623.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 xyrfG52hK8fq for ; Sun, 28 Feb 2021 20:44:12 +0000 (UTC) X-Greylist: delayed 00:16:08 by SQLgrey-1.8.0 Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by smtp2.osuosl.org (Postfix) with ESMTPS id 760EA43006 for ; Sun, 28 Feb 2021 20:44:12 +0000 (UTC) Received: by mail-oi1-f180.google.com with SMTP id f3so15973662oiw.13 for ; Sun, 28 Feb 2021 12:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=tUzE2MjNEIPcbV/5LlGboThXKlcrhGIgXjHfmn+t+UU=; b=1dR+IeRfmR4FxGXZqpqpsKEYBYz4lWlOX95tNtFYezmtfaG6ij9E1IZAMwV9thu57a wm3fZTLo7D/A1hJjRBNGdosa2RX03Ucb1evuv4v0DPDouSV0yN7v6ibteb+do3kjpp4i O+7c8Q2ZmM7LIt3zxpK6qDiv4xF0WFMUd3+w0I+k/RuliUjPumqFbfyxOydVpbQg2Y4o wukX3fOuO2NPVJcwt1hpMtgk3X6q4rGPHw+98XU1WqH8zDUA/BmaIaMquCp6oBEs6VfE yuxCMotuurYhKGwVQmBBGS2CHMiGINyTsew37DmH6PBzwSxo6HLDvYSWN0hPUK3IorYS /6tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=tUzE2MjNEIPcbV/5LlGboThXKlcrhGIgXjHfmn+t+UU=; b=oe8LPeLffKnsuL9rxqmOzJObNhhRYkMDykxGyjSeahI5+kTy3rOcyuMREiySW4JWh8 mVHgAQGLBPnn5+4lW/OoSBoEtY7j9Gh/1u1j1/bjMAOc2dTZ4kaQv7cwKlaWwjBK/T/e WrU+twOsz+FGNakKNXrdD1zccnGPz4J5HynqYZfudJZt/3RlyomoybufOv2DgvBGjyCG /2Hfv8CmB+FclfPblB/cxd6ALtjU+t2j2X0JgLsPdwFirjOmFjvNyY+TXDOy7abZTaKF 1IPTlpbqN5c2C3Fz0gJ1ETxXHQkKAqilyM+OqhpcU9S6Dh0YZlcudmfyCW+rsjuCdGWC ypqw== X-Gm-Message-State: AOAM530B03R98gPGfQ/JI/PlUJHITmTYU0Df37zJHut2OEk8I1ZamRSO THKgeXs8pf0Davc573rpE6jFAG6zH6QND6ya X-Google-Smtp-Source: ABdhPJw6pIHVeKN53dLF+17CFTMUuH/v3BDqaOdWHz2wxtAK7Auw4INx6p4P5EuNUtI4G/xHmtKGDQ== X-Received: by 2002:a17:90a:7061:: with SMTP id f88mr7881039pjk.56.1614543601057; Sun, 28 Feb 2021 12:20:01 -0800 (PST) Received: from ?IPv6:2601:600:9c00:1d0::250e? ([2601:600:9c00:1d0::250e]) by smtp.gmail.com with ESMTPSA id g8sm16361189pfu.13.2021.02.28.12.20.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Feb 2021 12:20:00 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-87B2DF72-54E0-4890-B2C0-831DB3F95904 Content-Transfer-Encoding: 7bit From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Sun, 28 Feb 2021 12:19:59 -0800 Message-Id: References: In-Reply-To: To: Jeremy , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (18D52) X-Mailman-Approved-At: Sun, 28 Feb 2021 21:15:45 +0000 Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation 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: Sun, 28 Feb 2021 20:44:14 -0000 --Apple-Mail-87B2DF72-54E0-4890-B2C0-831DB3F95904 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In the attempt to change consensus rules there is a simple set of choices: 1) hard fork: creates a chain split 2) soft fork: creates a chain split 3) 51% attack: does not create a chain split The presumption being that one can never assume 100% explicit adoption of an= y rule change. A 51% attack can of course fail. It is also possible that signaling can be u= ntruthful. But miner signaling provides some level of assurance that it will= be successful. This level of assurance is increased by adoption of a higher= than majority threshold, as has been done in the past. Most of the discussion I=E2=80=99ve seen has been focused on who is in charg= e. Bitcoin requires no identity; anyone can mine and/or accept bitcoin - nob= ody is in charge. The majority of those who mine can choose to enforce censorship any time the= y want. They don=E2=80=99t need anyone=E2=80=99s permission. No power is giv= en to them by developers or anyone else. They have that power based on their= own capital invested. Similarly, the economy (those who accept bitcoin) can enforce any rule chang= e it wants to. And it can do so at any level of participation that wants to g= o along. Anyone can do this, it requires nobody=E2=80=99s permission. Furthe= rmore, it is possible for the economy to signal its level of agreement in ev= ery transaction, as miners have done in blocks previously. But if the objective is to produce a rule change while avoiding a chain spli= t, 50% is a much lower bar than 100%. If there is some other objective, it=E2= =80=99s not clear to me what it is. e > On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev wrote: >=20 > =EF=BB=BF > Miners still can generate invalid blocks as a result of SPV mining, and it= could be profitable to do "bad block enhanced selfish mining" to take advan= tage of it. >=20 >=20 > Hard to analyze exactly what that looks like, but... >=20 > E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate t= o mine bad blocks would mean 1/4th of the time you could make 20% of the has= hrate mine bad blocks, overall a > 5% (series expansion) benefit. One could a= nalyze out that the lost hash rate for bad blocks only matters for the first= difficulty adjustment period you're doing this for too, as the hashrate dro= p will be accounted for -- but then a miner can switch back to mining valid c= hain, giving themselves a larger % of hashrate. >=20 > So it is still possible that an un-upgraded miner will fail part 3, and at= tempting to accommodate un-upgraded miners leads to some nasty oscillating h= ashrate being optimal. >=20 >=20 > -- > @JeremyRubin >=20 >=20 >> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo w= rote: >> Note further that mandatory signaling isn't "just" a flag day - unlike a T= aproot flag day (where miners running Bitcoin=20 >> Core unmodified today will not generate invalid blocks), a mandatory sign= aling flag day blatantly ignores goal (3) from=20 >> my original post - it results in any miner who has not taken active actio= n (and ensured every part of their often-large=20 >> infrastructure has been correctly reconfigured) generating invalid blocks= . >>=20 >> As for "Taproot" took too long, hey, at least if its locked in people can= just build things assuming it exists. Some=20 >> already are, but once its clearly locked in, there's no reason to not con= tinue other work at the same time. >>=20 >> Matt >>=20 >> On 2/28/21 14:43, Jeremy via bitcoin-dev wrote: >> > I agree with much of the logic presented by Matt here. >> >=20 >> > BIP8 was intended to be simpler to agree on to maintain consensus, yet w= e find ourselves in a situation where a "tiny"=20 >> > parameter has the potential to cause great network disruption and confu= sion (rationality is not too useful a concept=20 >> > here given differing levels of sophistication and information). It is t= herefore much simpler and more likely to be=20 >> > universally understood by all network participants to just have a flag d= ay. It is easier to communicate what users=20 >> > should do and when. >> >=20 >> > This is ultimately not coercive to users because the upgrade for Taproo= t itself is provable and analyzable on its own,=20 >> > but activation parameters based on what % of economically relevant node= s are running an upgrade by a certain date are=20 >> > not. Selecting these sorts of complicated consensus parameters may ulti= mately present more opportunity for a cooptable=20 >> > consensus process than something more straightforward. >> >=20 >> >=20 >> > That said, a few points strike me as worth delving into. >> >=20 >> >=20 >> > 1) Con: Mandatory signalling is no different than a flag day. Mandatory= signaling is effectively 2 flag days -- one for=20 >> > the signaling rule, 1 for the taproot type. The reason for the 2 week g= ap between flag day for signaling and flag day=20 >> > for taproot rules is, more or less, so that nodes who aren't taproot re= ady at the 1st flag day do not end up SPV mining=20 >> > (using standardness rules in mempool prevents them from mining an inval= id block on top of a valid tip, but does not=20 >> > ensure the tip is valid). >> > 2) Con: Releasing a flag day without releasing the LOT=3Dtrue code lead= ing up to that flag day means that clients would=20 >> > not be fully compatible with an early activation that could be proposed= before the flag day is reached. E.g., LOT=3Dtrue=20 >> > is a flag day that retains the possibility of being compatible with oth= er BIP8 releases without changing software. >> > 3) Pro: BIP-8 is partially in service of "early activation" and . I'm p= ersonally skeptical that early activation is/was=20 >> > ever a good idea. A fixed activation date may be largely superior for b= usiness purposes, software engineering schedules,=20 >> > etc. I think even with signaling BIP8, it would be possibly superior to= activate rules at a fixed date (or a quantized=20 >> > set of fixed dates, e.g. guaranteeing at least 3 months but maybe more)= . >> > 4) Pro: part of the argument for BIP-8=3Dfalse is that it is possible t= hat the rule could not activate, if signaling does=20 >> > not occur, providing additional stopgap against dev collusion and bugs.= But BIP-8 can activate immediately (with start=20 >> > times being proposed 1 month after release?) so we don't have certainty= around how much time there is for that secondary=20 >> > review process (read -- I think it isn't that valuable) and if there *i= s* a deadly bug discovered, we might want to=20 >> > hard-fork to fix it even if it isn't yet signaled for (e.g., if the rul= e activates it enables more mining reward). So I=20 >> > think that it's a healthier mindset to release a with definite deadline= and not rule out having to do a hard fork if=20 >> > there is a grave issue (we shouldn't ever release a SF if we think this= is at all likely, mind you). >> > 5) Con: It's already taken so long for taproot, the schedule around tap= root was based on the idea it could early=20 >> > activate, 2022 is now too far away. I don't know how to defray this oth= er than, if your preferred idea is 1 year flag=20 >> > day, to do that via LOT=3Dtrue so that taproot can still have early act= ivation if desired. >> >=20 >> > Overall I agree with the point that all the contention around LOT, make= s a flag day look not so bad. And something=20 >> > closer to a flag day might not be so bad either for future forks as wel= l. >> >=20 >> > However, I think given the appetite for early activation, if a flag day= is desired I think LOT=3Dtrue is the best option=20 >> > at this time as it allows our flag day to remain compatible with such a= n early activation. >> >=20 >> > I think we can also clearly communicate that LOT=3Dtrue for Taproot is n= ot a precedent setting occurence for any future=20 >> > forks (hold me accountable to not using this as precedent this should I= ever advocate for a SF with similar release=20 >> > parameters). >> >=20 >> >=20 >> > _______________________________________________ >> > bitcoin-dev mailing list >> > bitcoin-dev@lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-87B2DF72-54E0-4890-B2C0-831DB3F95904 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
In the attempt to change consensus rul= es there is a simple set of choices:

1) h= ard fork: creates a chain split
2) soft fork: creates a chain split
3) 51% attack: does not create a chain split

The presumption being that one can never a= ssume 100% explicit adoption of any rule change.

A 51% attack can of course fail. It is also possible that signaling= can be untruthful. But miner signaling provides some level of assurance tha= t it will be successful. This level of assurance is increased by adoption of= a higher than majority threshold, as has been done in the past.

Most of the discussion I=E2=80=99ve seen has been f= ocused on who is in charge. Bitcoin requires no identity; anyone can mine an= d/or accept bitcoin - nobody is in charge.

The majority of those who mine can choose to enforce censorship any time= they want. They don=E2=80=99t need anyone=E2=80=99s permission. No power is= given to them by developers or anyone else. They have that power based on t= heir own capital invested.

= Similarly, t= he economy (those who accept bitcoin) can enforce any rule change it wants t= o. And it can do so at any level of participation that wants to go along. An= yone can do this, it requires nobody=E2=80=99s permission. Furthermore, it i= s possible for the economy to signal its level of agreement in every transac= tion, as miners have done in blocks previously.

But if the objective is to produce a rule change while avoiding a c= hain split, 50% is a much lower bar than 100%. If there is some other object= ive, it=E2=80=99s not clear to me what it is.
<= br style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">e

On Feb 28, 2021, at 12:02, Jeremy via bitc= oin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

=EF=BB=BF
Miners still can generate invalid blocks= as a result of SPV mining, and it could be profitable to do "bad block enha= nced selfish mining" to take advantage of it.


Hard to analyze exactly what that looks like, but...

E.g.,= suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to mine= bad blocks would mean 1/4th of the time you could make 20% of the hashrate m= ine bad blocks, overall a > 5% (series expansion) benefit. One could anal= yze out that the lost hash rate for bad blocks only matters for the first di= fficulty adjustment period you're doing this for too, as the hashrate drop w= ill be accounted for -- but then a miner can switch back to mining valid cha= in, giving themselves a larger % of hashrate.

So it is still possible tha= t an un-upgraded miner will fail part 3, and attempting to accommodate un-up= graded miners leads to some nasty oscillating hashrate being optimal.



<= br>
On Sun, = Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists@mattcorallo.com> wrote:
Note further that mandatory signaling isn't "= just" a flag day - unlike a Taproot flag day (where miners running Bitcoin <= br> Core unmodified today will not generate invalid blocks), a mandatory signali= ng flag day blatantly ignores goal (3) from
my original post - it results in any miner who has not taken active action (= and ensured every part of their often-large
infrastructure has been correctly reconfigured) generating invalid blocks.
As for "Taproot" took too long, hey, at least if its locked in people can ju= st build things assuming it exists. Some
already are, but once its clearly locked in, there's no reason to not contin= ue other work at the same time.

Matt

On 2/28/21 14:43, Jeremy via bitcoin-dev wrote:
> I agree with much of the logic presented by Matt here.
>
> BIP8 was intended to be simpler to agree on to maintain consensus, yet w= e find ourselves in a situation where a "tiny"
> parameter has the potential to cause great network disruption and confu= sion (rationality is not too useful a concept
> here given differing levels of sophistication and information). It is t= herefore much simpler and more likely to be
> universally understood by all network participants to just have a flag d= ay. It is easier to communicate what users
> should do and when.
>
> This is ultimately not coercive to users because the upgrade for Taproo= t itself is provable and analyzable on its own,
> but activation parameters based on what % of economically relevant node= s are running an upgrade by a certain date are
> not. Selecting these sorts of complicated consensus parameters may ulti= mately present more opportunity for a cooptable
> consensus process than something more straightforward.
>
>
> That said, a few points strike me as worth delving into.
>
>
> 1) Con: Mandatory signalling is no different than a flag day. Mandatory= signaling is effectively 2 flag days -- one for
> the signaling rule, 1 for the taproot type. The reason for the 2 week g= ap between flag day for signaling and flag day
> for taproot rules is, more or less, so that nodes who aren't taproot re= ady at the 1st flag day do not end up SPV mining
> (using standardness rules in mempool prevents them from mining an inval= id block on top of a valid tip, but does not
> ensure the tip is valid).
> 2) Con: Releasing a flag day without releasing the LOT=3Dtrue code lead= ing up to that flag day means that clients would
> not be fully compatible with an early activation that could be proposed= before the flag day is reached. E.g., LOT=3Dtrue
> is a flag day that retains the possibility of being compatible with oth= er BIP8 releases without changing software.
> 3) Pro: BIP-8 is partially in service of "early activation" and . I'm p= ersonally skeptical that early activation is/was
> ever a good idea. A fixed activation date may be largely superior for b= usiness purposes, software engineering schedules,
> etc. I think even with signaling BIP8, it would be possibly superior to= activate rules at a fixed date (or a quantized
> set of fixed dates, e.g. guaranteeing at least 3 months but maybe more)= .
> 4) Pro: part of the argument for BIP-8=3Dfalse is that it is possible t= hat the rule could not activate, if signaling does
> not occur, providing additional stopgap against dev collusion and bugs.= But BIP-8 can activate immediately (with start
> times being proposed 1 month after release?) so we don't have certainty= around how much time there is for that secondary
> review process (read -- I think it isn't that valuable) and if there *i= s* a deadly bug discovered, we might want to
> hard-fork to fix it even if it isn't yet signaled for (e.g., if the rul= e activates it enables more mining reward). So I
> think that it's a healthier mindset to release a with definite deadline= and not rule out having to do a hard fork if
> there is a grave issue (we shouldn't ever release a SF if we think this= is at all likely, mind you).
> 5) Con: It's already taken so long for taproot, the schedule around tap= root was based on the idea it could early
> activate, 2022 is now too far away. I don't know how to defray this oth= er than, if your preferred idea is 1 year flag
> day, to do that via LOT=3Dtrue so that taproot can still have early act= ivation if desired.
>
> Overall I agree with the point that all the contention around LOT, make= s a flag day look not so bad. And something
> closer to a flag day might not be so bad either for future forks as wel= l.
>
> However, I think given the appetite for early activation, if a flag day= is desired I think LOT=3Dtrue is the best option
> at this time as it allows our flag day to remain compatible with such a= n early activation.
>
> I think we can also clearly communicate that LOT=3Dtrue for Taproot is n= ot a precedent setting occurence for any future
> forks (hold me accountable to not using this as precedent this should I= ever advocate for a SF with similar release
> parameters).
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev
>
_______________________________________________
bitcoi= n-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /span>
= --Apple-Mail-87B2DF72-54E0-4890-B2C0-831DB3F95904--