Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Sun, 28 Feb 2021 12:38:13 -0800
Message-Id: <DB47E953-AAEF-4550-B60E-8530F3477A39@voskuil.org>
References: <0adb87b0-0e05-2ccc-77e1-1de689b45739@mattcorallo.com>
In-Reply-To: <0adb87b0-0e05-2ccc-77e1-1de689b45739@mattcorallo.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
Precedence: list

I think it has been shown that an understanding of reasonableness is not uni=
versal, making any assertion about it as a collective goal kind of self-defe=
ating. The question is what is achievable, not what is reasonable. I=E2=80=99=
m not making any value judgements here. Simply pointing out that anything ot=
her than a successful 51% attack will create a split.

e

> On Feb 28, 2021, at 12:25, Matt Corallo <lf-lists@mattcorallo.com> wrote:
>=20
> =EF=BB=BFGlad you asked! Yes, your goal here is #4 on the list of goals I l=
aid out at [1], which I referenced and specifically addressed each of in the=
 OP of this thread.
>=20
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/0=
17547.html
>=20
>> On 2/28/21 15:19, Eric Voskuil wrote:
>> 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=
 any rule change.
>> A 51% attack can of course fail. It is also possible that signaling can b=
e untruthful. But miner signaling provides some level of assurance that it w=
ill be successful. This level of assurance is increased by adoption of a hig=
her 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 ch=
arge. Bitcoin requires no identity; anyone can mine and/or accept bitcoin - n=
obody is in charge.
>> The majority of those who mine can choose to enforce censorship any time t=
hey want. They don=E2=80=99t need anyone=E2=80=99s permission. No power is g=
iven to them by developers or anyone else. They have that power based on the=
ir own capital invested.
>> Similarly, the economy (those who accept bitcoin) can enforce any rule ch=
ange it wants to. And it can do so at any level of participation that wants t=
o go along. Anyone can do this, it requires nobody=E2=80=99s permission. Fur=
thermore, it is possible for the economy to signal its level of agreement in=
 every transaction, as miners have done in blocks previously.
>> But if the objective is to produce a rule change while avoiding a chain s=
plit, 50% is a much lower bar than 100%. If there is some other objective, i=
t=E2=80=99s not clear to me what it is.
>> e
>>>> On Feb 28, 2021, at 12:02, Jeremy via bitcoin-dev <bitcoin-dev@lists.li=
nuxfoundation.org> wrote:
>>>=20
>>> =EF=BB=BF
>>> Miners still can generate invalid blocks as a result of SPV mining, and i=
t could be profitable to do "bad block enhanced selfish mining" to take adva=
ntage 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% hashrat=
e to mine bad blocks would mean 1/4th of the time you could make 20% of the h=
ashrate mine bad blocks, overall a > 5% (series expansion) benefit. One coul=
d analyze out that the lost hash rate for bad blocks only matters for the fi=
rst difficulty adjustment period you're doing this for too, as the hashrate d=
rop will be accounted for -- but then a miner can switch back to mining vali=
d chain, giving themselves a larger % of hashrate.
>>>=20
>>> So it is still possible that an un-upgraded miner will fail part 3, and a=
ttempting to accommodate un-upgraded miners leads to some nasty oscillating h=
ashrate being optimal.
>>>=20
>>>=20
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/Jerem=
yRubin>
>>>=20
>>>=20
>>>> On Sun, Feb 28, 2021 at 11:52 AM Matt Corallo <lf-lists@mattcorallo.com=
 <mailto:lf-lists@mattcorallo.com>> wrote:
>>>=20
>>>    Note further that mandatory signaling isn't "just" a flag day - unlik=
e a Taproot flag day (where miners running
>>>    Bitcoin
>>>    Core unmodified today will not generate invalid blocks), a mandatory s=
ignaling flag day blatantly ignores goal (3)
>>>    from
>>>    my original post - it results in any miner who has not taken active a=
ction (and ensured every part of their
>>>    often-large
>>>    infrastructure has been correctly reconfigured) generating invalid bl=
ocks.
>>>=20
>>>    As for "Taproot" took too long, hey, at least if its locked in people=
 can just build things assuming it exists. Some
>>>    already are, but once its clearly locked in, there's no reason to not=
 continue 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.
>>>    >
>>>    > BIP8 was intended to be simpler to agree on to maintain consensus, y=
et we find ourselves in a situation where a
>>>    "tiny"
>>>    > parameter has the potential to cause great network disruption and c=
onfusion (rationality is not too useful a
>>>    concept
>>>    > here given differing levels of sophistication and information). It i=
s therefore much simpler and more likely to be
>>>    > universally understood by all network participants to just have a f=
lag day. It is easier to communicate what users
>>>    > should do and when.
>>>    >
>>>    > This is ultimately not coercive to users because the upgrade for Ta=
proot itself is provable and analyzable on
>>>    its own,
>>>    > but activation parameters based on what % of economically relevant n=
odes are running an upgrade by a certain
>>>    date are
>>>    > not. Selecting these sorts of complicated consensus parameters may u=
ltimately 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. Manda=
tory signaling is effectively 2 flag days --
>>>    one for
>>>    > the signaling rule, 1 for the taproot type. The reason for the 2 we=
ek gap between flag day for signaling and
>>>    flag day
>>>    > for taproot rules is, more or less, so that nodes who aren't taproo=
t ready at the 1st flag day do not end up SPV
>>>    mining
>>>    > (using standardness rules in mempool prevents them from mining an i=
nvalid 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 l=
eading up to that flag day means that clients
>>>    would
>>>    > not be fully compatible with an early activation that could be prop=
osed before the flag day is reached. E.g.,
>>>    LOT=3Dtrue
>>>    > is a flag day that retains the possibility of being compatible with=
 other BIP8 releases without changing software.
>>>    > 3) Pro: BIP-8 is partially in service of "early activation" and . I=
'm personally skeptical that early activation
>>>    is/was
>>>    > ever a good idea. A fixed activation date may be largely superior f=
or business purposes, software engineering
>>>    schedules,
>>>    > etc. I think even with signaling BIP8, it would be possibly superio=
r to activate rules at a fixed date (or a
>>>    quantized
>>>    > set of fixed dates, e.g. guaranteeing at least 3 months but maybe m=
ore).
>>>    > 4) Pro: part of the argument for BIP-8=3Dfalse is that it is possib=
le that the rule could not activate, if
>>>    signaling does
>>>    > not occur, providing additional stopgap against dev collusion and b=
ugs. But BIP-8 can activate immediately (with
>>>    start
>>>    > times being proposed 1 month after release?) so we don't have certa=
inty around how much time there is for that
>>>    secondary
>>>    > review process (read -- I think it isn't that valuable) and if ther=
e *is* 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=
 rule activates it enables more mining
>>>    reward). So I
>>>    > think that it's a healthier mindset to release a with definite dead=
line 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 t=
his is at all likely, mind you).
>>>    > 5) Con: It's already taken so long for taproot, the schedule around=
 taproot was based on the idea it could early
>>>    > activate, 2022 is now too far away. I don't know how to defray this=
 other than, if your preferred idea is 1 year
>>>    flag
>>>    > day, to do that via LOT=3Dtrue so that taproot can still have early=
 activation if desired.
>>>    >
>>>    > Overall I agree with the point that all the contention around LOT, m=
akes a flag day look not so bad. And something
>>>    > closer to a flag day might not be so bad either for future forks as=
 well.
>>>    >
>>>    > 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 su=
ch an early activation.
>>>    >
>>>    > I think we can also clearly communicate that LOT=3Dtrue for Taproot=
 is not a precedent setting occurence for any
>>>    future
>>>    > forks (hold me accountable to not using this as precedent this shou=
ld I ever advocate for a SF with similar release
>>>    > parameters).
>>>    >
>>>    >
>>>    > _______________________________________________
>>>    > bitcoin-dev mailing list
>>>    > bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.lin=
uxfoundation.org>
>>>    > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>    <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