path: root/9d/e5b7b42d5fdead337fe10bae60e8147ba5640e

Return-Path: <eric@voskuil.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 16ECCC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 23:45:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id E849F43094
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 23:45:15 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 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]
 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 lzC8-SGAYxsY
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 23:45:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com
 [IPv6:2607:f8b0:4864:20::429])
 by smtp2.osuosl.org (Postfix) with ESMTPS id E5720400CC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 23:45:13 +0000 (UTC)
Received: by mail-pf1-x429.google.com with SMTP id a188so642771pfb.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 04 Mar 2021 15:45:13 -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=EVLSgZgAUiK9mzfShoQSx2xzfX+EdhWF61LvJCD7dvM=;
 b=F6RqCLlr710HIlxVae5VGIPEnMpCe4HZS2IiLquVGsUP3I0gimhWcQU1CtN7p7e8Hn
 58lNIaKaRwrqY0tmEEgPX//RB60wHZccjGStoi+hxuEI3BUsQx8cHsnE6OWMOqBQ4mIk
 P/9JH9/6t+MfEAihGi7+lfQnZub2sVAVmVryZKWjIX4QwHwo+DyU//4w9OEpURXpavBF
 i9SdXJYJetAC/6VRWsXIj7PHhWGzO322czUYPCi5ZojHaJrtPvvgT0ioW5CuRcra4aF+
 +D4fI7sEYXOhPnOmojfkmbBkAev/uFNCTGqGLqn2YAow2Wk7WJ+MuxHLfBua8Vy7UL1x
 Y4UQ==
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=EVLSgZgAUiK9mzfShoQSx2xzfX+EdhWF61LvJCD7dvM=;
 b=dhvLVaCBgCVyH81VzNlEpMwXQ0atSnYNfyFEXQCs/OA9Bdnxot+hzwebkSZHg0HGHR
 F487dnPUNJzjP3a/kNAZyPmLwCAUrYX49o1DcwmTH6prPoBP5EBLARZ7IVMNtaTYPbas
 jVEAKdayzlPWdBn99qkdhgcMVYmaUmWxF8lh4ZYAhUb2x18iCSDAbNrIbNhQpBK+wWz7
 Vv20GC2cmTzfsVJsyUNhZ1qzlM7aAy4j/C19qLbBzJGkcuHVZw1J93nnoxskE5wyWl4z
 FF5/QZsOZFuog/PgmlYQ5V1NlsC6pILM8U5snTgr/T366plpDLTQCMfivXoL3PMvbmV2
 wllg==
X-Gm-Message-State: AOAM530WQG9OyZdf3EgFQKotbTmPG1dABdbnrB+5PRd0eqcG4OI4YACt
 /cp4D8E04HwgOrzYLlxB3MYBkA==
X-Google-Smtp-Source: ABdhPJwEMxsQYo/vBEo2EEjYwbyFlf/ouOaj+8co0EtwTTo8fVUCOv2/cp9LCGFdxaK5KB/Cfq66OQ==
X-Received: by 2002:a63:5d2:: with SMTP id 201mr780838pgf.12.1614901513302;
 Thu, 04 Mar 2021 15:45:13 -0800 (PST)
Received: from ?IPv6:2600:380:707e:3fea:d1ed:f262:c787:7ca4?
 ([2600:380:707e:3fea:d1ed:f262:c787:7ca4])
 by smtp.gmail.com with ESMTPSA id t23sm425614pgv.34.2021.03.04.15.45.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Mar 2021 15:45:12 -0800 (PST)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-C456C2B2-707D-4C44-A899-22A967BEB649
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Thu, 4 Mar 2021 15:45:11 -0800
Message-Id: <847E2B79-4215-4528-A494-C676457B03F8@voskuil.org>
References: <CACrzPemtN4+fJ7ALAr=BvsMjmE8nXbOY4COyT-XdBMQbBy5r4Q@mail.gmail.com>
In-Reply-To: <CACrzPemtN4+fJ7ALAr=BvsMjmE8nXbOY4COyT-XdBMQbBy5r4Q@mail.gmail.com>
To: Vincent Truong <vincent.truong@procabiak.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (18D52)
Subject: Re: [bitcoin-dev] Making the case for flag day activation of taproot
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: Thu, 04 Mar 2021 23:45:16 -0000


--Apple-Mail-C456C2B2-707D-4C44-A899-22A967BEB649
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Mike was wrong about a number of things, and in the end decided that Bitcoin=
 was pointless, as people could not defend it against the state. He used thi=
s as the basis for his defense of large blocks and centralized mining. When t=
hat didn=E2=80=99t work out he quit, to work on centralized systems.

People can of course do what they want, but unnecessarily splitting from the=
 existing chain reduces utility, which seems counterproductive. BCH is a goo=
d example of this.

Compatibility isn=E2=80=99t =E2=80=9Cdangerous=E2=80=9D. Old nodes don=E2=80=
=99t need to know what new nodes are doing. If the person operating one need=
s to validate a taproot payment to himself, he would have to upgrade. Otherw=
ise it=E2=80=99s of no consequence, his node is economic (relevant) only in r=
elation to the legacy payments he receives, which he can continue to validat=
e.

e

> On Mar 4, 2021, at 15:22, Vincent Truong via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
>=20
> =EF=BB=BF
>=20
> I must remind everyone of Mike Hearn's proposal not many years ago, which o=
ught to be on everyone's mind right now. "Every soft fork should be a hard f=
ork, and that soft forks are inherently dangerous because old nodes are tric=
ked to not know what the new nodes are doing" (paraphrased). Whether taproot=
 is dangerous is not the issue; whether old nodes should or should not ignor=
e new rules, is.
>=20
> Flag day activation of a soft fork is basically proposing a hard fork, but=
 without saying or doing it at full commitment. May as well just do a flag d=
ay hard fork.
>=20
> Bitcoin Cash/Bcash has already tested for you how a market driven hard for=
k should work. Bitcoin didn't die. We should be learning from the mistakes m=
ade in those early hard forks to not repeat them when Bitcoin hard forks - l=
ike having replay protection written before deployment.
>=20
> If it's not evident within the first 6-12 blocks which fork is winning, th=
en the market will trade it out. Just like what happened with Bitcoin Cash/B=
cash.
>=20
> Not only that, it stops the drama of Bitcoin Core devs from "being in cont=
rol" of consensus. The market will choose, you just create the safest way fo=
r users to participate. The market is consensus. Rough consensus is just the=
 conversation starter.
>=20
>=20
>> On Thu, 4 Mar 2021, 1:39 am Chris Belcher via bitcoin-dev, <bitcoin-dev@l=
ists.linuxfoundation.org> wrote:
>> The bitcoin world is close to total gridlock on the question of how to
>> activate taproot. There's no agreement on activation[1][2], and if an
>> agreement isn't reached then nothing happens. That would be really
>> terrible because we'd miss out on the benefits of taproot and
>> potentially other future soft forks.
>>=20
>> A major problem with BIP8 is that it would result to a situation where
>> different parts of the bitcoin ecosystem run different consensus rules.
>> Some people will run LOT=3Dtrue and others LOT=3Dfalse. Worst of all, it
>> becomes vulnerable to a twitter/reddit/social media blitz which could
>> attempt to move the date of miner activation around.
>>=20
>> Twitter and reddit drama provide a perfect cover for social attacks on
>> bitcoin.
>>=20
>> Forced signalling leads to brinksmanship. Where two or more sides
>> (backed up by social media drama) enter into a game of chicken with
>> deployed nodes. If one of them doesn't concede then we get a damaging
>> chain split. And the $1 trillion in value that the bitcoin network
>> protects is put at risk. =46rom the point of view of a miner or big
>> exchange stuck in the middle, if they look at the ecosystem of twitter
>> and reddit (especially if you think about all the problems with bots and
>> sockpuppets) they have no idea which consensus rules they should
>> actually follow and exactly what date they take effect. Miners,
>> exchanges, merchants and the rest of the ecosystem exist to serve their
>> customers and users, and trouble happens when they don't know what their
>> customers really want. Social media attacks are not just a theoretical
>> concern; back during the block size drama, the bitcoin reddits were
>> targetted by bots, sockpuppets and brigading[3].
>>=20
>> Enter flag day activation. With a flag day there can be no
>> brinksmanship. A social media blitz cant do anything except have its own
>> followers fork away. Crucially, miner signalling cant be used to change
>> the activation date for nodes that didn't choose to and just passively
>> follow signalling. Changing the activation date requires all those users
>> to actually run different node software.
>>=20
>> Flag day activation works simply: we choose a block height and after
>> that block height the new taproot rules become enforced.
>>=20
>>=20
>> Supporters of the permissionless, "users rule" approach of LOT=3Dtrue
>> should be happy because it completely takes miners out of activation.
>>=20
>> Supporters of the safe, conservative approach of LOT=3Dfalse can be made
>> happy with a few ways of derisking:
>>=20
>> * Getting mining pools, businesses and users to look at the code and ask
>> if they (a) think its either neutral or good for their business or use
>> case and (b) they believe others view it similarly and that the
>> consensus changes proposed have a good social consensus around them.
>>=20
>> * Setting the flag day far in the future (18 months or 2 years in the
>> original proposal[3]).
>>=20
>>=20
>> =3D=3D What if flag day activation is used maliciously? =3D=3D
>>=20
>> What if one day the Core developer team is co-opted and uses the flag
>> day method to do something bad? For example, a soft fork where sending
>> to certain blacklisted addresses is not allowed. The bitcoin user
>> community who wants to resist this can create their own
>> counter-soft-fork full node, where the first block after the flag day
>> MUST pay to one of those addresses on the blacklist. This forces a chain
>> split between the censorship rules and the no-censorship rules, and its
>> pretty obvious that the real bitcoin which most people follow will be
>> the chain without censorship.
>>=20
>> For example, if a group of users didn't agree with taproot then they
>> could create their own counter-flag-day-activation which requires that a
>> transaction is included that does an invalid-spend from a taproot output
>> in the first block after the flag day height.
>>=20
>> This is always possible with any user activated soft fork. In BIP8
>> LOT=3Dtrue it could be done by rejecting block headers with certain
>> version bits signalled.
>>=20
>>=20
>> =3D=3D But it will take so long! =3D=3D
>>=20
>> We seem to be at a deadlock now. This will take less time than any other
>> method, because other methods might never happen. BIP8 is dead and from
>> what I see there's no other credible plan.
>>=20
>> We've already waited years for taproot. I remember listening to talks
>> about bitcoin from 2015 of people discussing Schnorr signatures. And
>> given how slow segwit and p2sh adoption were its pretty likely that
>> we'll waiting a while for taproot to be actually adopted.
>>=20
>>=20
>> =3D=3D A social media blitz could still try to activate it early =3D=3D
>>=20
>> The brinksmanship only works because miner signalling can make many
>> other nodes activate early, even if those other nodes didn't do
>> anything. There can't be a game of chicken that puts the bitcoin network
>> at risk.
>>=20
>> If a group of people did adopt alternative node software which has a
>> shorter flag day, they actually have a risk of slow blocks. Because they
>> cant trick or force any other nodes to come along with them, they are
>> likely to only have a small economy and therefore would lose a lot of
>> hashrate. Imagine trading bitcoins for cash in person and instead of
>> waiting 10 minutes for a confirmation you have to wait 3 hours because
>> the blocks are slow.
>>=20
>> Also, the argument for downloading and running a different software only
>> to speed up activation is pretty weak. Taproot would activate in ~18
>> months, so why are you so impatient that you need it in 6 months? And
>> risk slow blocks for you while doing so? The big difference with BIP148
>> the segwit UASF, is that people *had to* run some other software
>> otherwise they would get *no soft fork at all*.
>>=20
>>=20
>> =3D=3D Without miner signalling how do we know the new rules are even
>> activated? =3D=3D
>>=20
>> When did you see miners signalling their support for the inflation schedu=
le?
>>=20
>> Bitcoin's rules are enforced by wallets backed by full nodes. You'll
>> always know if your own full node is enforcing the new rules. The thing
>> that matters isnt miner signalling but your own full node, and the nodes
>> of those you trade with.
>>=20
>> Flag day activation is quite similar to the way block reward halvenings
>> work. At and after block height 630000 miners are only allowed to create
>> 6.25 BTC rather than 12.5 BTC. Everyone knows that if miners continued
>> to create 12.5 BTC or more they would be unable to sell or spend those
>> coins anywhere.
>>=20
>> In 2017 when segwit was being activated people created a huge list of
>> various bitcoin companies, merchants and wallets:
>> https://web.archive.org/web/20171228111943/https://bitcoincore.org/en/seg=
wit_adoption/
>> Looking at that list, you would know that if someone stole coins from a
>> segwit address they would be unable to deposit them in many exchanges
>> and merchants: Bitrefill, Bitstamp, Kraken, Localbitcoins, Paxful,
>> Vaultoro, HitBTC, etc.
>>=20
>> Then what happened is only a month after S2X was beaten this guy moved
>> 40000 BTC to a segwit address, confident about the power of the network
>> to protect his coins.
>> https://old.reddit.com/r/Bitcoin/comments/7tcmi4/bitcointalks_famous_user=
_loaded_moved_his_40k_btc/
>>=20
>> If there's ever any doubt about flag day activation we can always draw
>> up a similar list, although if there's broad consensus about it then
>> there's no reason why bitcoin businesses wouldn't upgrade to the latest
>> Core, like they did with every other previous soft fork.
>>=20
>>=20
>> =3D=3D This gives the impression that Core developers control the protoco=
l =3D=3D
>>=20
>> This objection has a mirror image argument: BIP8 with LOT=3Dfalse gives
>> the impression that miners control the protocol(!)
>>=20
>> Eventually some group has to make a decision. We will ask the bitcoin
>> economy and users what they think of flag day activation. It's pretty
>> clear that nobody seriously objects to taproot, and as described above
>> if Core developers did something evil the community could resist it with
>> a counter-flag-day-activation.
>>=20
>>=20
>>=20
>> =3D=3D TL;DR =3D=3D
>>=20
>> I believe flag day activation is the way forward. It should answer all
>> the objections and risks which make other methods too controversial.
>> Let's go ahead and bring taproot to bitcoin!
>>=20
>>=20
>>=20
>> =3D=3D References =3D=3D
>>=20
>> [1] -
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018=
498.html
>>       luke-jr posts saying LOT=3Dfalse in his view reintroduces a bug, he=

>> compares it to introducing an inflation bug and just hoping that miners
>> will not exploit it.
>>=20
>> [2] -
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018=
425.html
>>       This whole thread has many people disagreeing with LOT=3Dtrue
>>=20
>> [3] -
>> https://old.reddit.com/r/Bitcoin/comments/4biob5/research_into_instantane=
ous_vote_behavior_in/
>>=20
>> https://old.reddit.com/r/Bitcoin/comments/3v04pd/can_we_please_have_a_civ=
il_discussion_about/cxjnz1d/?context=3D1
>>=20
>> https://old.reddit.com/r/Bitcoin/comments/41ykkt/members_trying_to_destro=
y_bitcoin_on_this_thread/cz6ccka/?context=3D3
>>=20
>> [4] -
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018=
495.html
>>       Matt Corallo's flag day activation proposal
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-C456C2B2-707D-4C44-A899-22A967BEB649
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr">Mike was wrong about a num=
ber of things, and in the end decided that Bitcoin was pointless, as people c=
ould not defend it against the state. He used this as the basis for his defe=
nse of large blocks and centralized mining. When that didn=E2=80=99t work ou=
t he quit, to work on centralized systems.</div><div dir=3D"ltr"><br></div><=
div dir=3D"ltr">People can of course do what they want, but unnecessarily sp=
litting from the existing chain reduces utility, which seems counterproducti=
ve. BCH is a good example of this.</div><div dir=3D"ltr"><br></div><div dir=3D=
"ltr">Compatibility isn=E2=80=99t =E2=80=9Cdangerous=E2=80=9D. Old nodes don=
=E2=80=99t need to know what new nodes are doing. If the person operating on=
e needs to validate a taproot payment to himself, he would have to upgrade. O=
therwise it=E2=80=99s of no consequence, his node is economic (relevant) onl=
y in relation to the legacy payments he receives, which he can continue to v=
alidate.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">e</div><div dir=3D=
"ltr"><br><blockquote type=3D"cite">On Mar 4, 2021, at 15:22, Vincent Truong=
 via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt; wrote:<br><br=
></blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div=
 dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">I must remind ev=
eryone of Mike Hearn's proposal not many years ago, which ought to be on eve=
ryone's mind right now. "Every soft fork should be a hard fork, and that sof=
t forks are inherently dangerous because old nodes are tricked to not know w=
hat the new nodes are doing" (paraphrased). Whether taproot is dangerous is n=
ot the issue; whether old nodes should or should not ignore new rules, is.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">Flag day activation of a s=
oft fork is basically proposing a hard fork, but without saying or doing it a=
t full commitment. May as well just do a flag day hard fork.<div dir=3D"auto=
"><div dir=3D"auto"><br></div><div dir=3D"auto">Bitcoin Cash/Bcash has alrea=
dy tested for you how a market driven hard fork should work. Bitcoin didn't d=
ie. We should be learning from the mistakes made in those early hard forks t=
o not repeat them when Bitcoin hard forks - like having replay protection wr=
itten before deployment.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
<span style=3D"font-family:sans-serif">If it's not evident within the first 6=
-12 blocks which fork is winning, then the market will trade it out. Just li=
ke what happened with Bitcoin Cash/Bcash.</span><br></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Not only that, it stops the drama of Bitcoin Cor=
e devs from "being in control" of consensus. The market will choose, you jus=
t create the safest way for users to participate. The market is consensus. R=
ough consensus is just the conversation starter.</div><div dir=3D"auto"><br>=
</div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Thu, 4 Mar 2021, 1:39 am Chris Belcher via bitcoin-dev, &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">The bitcoin world is close to total gri=
dlock on the question of how to<br>
activate taproot. There's no agreement on activation[1][2], and if an<br>
agreement isn't reached then nothing happens. That would be really<br>
terrible because we'd miss out on the benefits of taproot and<br>
potentially other future soft forks.<br>
<br>
A major problem with BIP8 is that it would result to a situation where<br>
different parts of the bitcoin ecosystem run different consensus rules.<br>
Some people will run LOT=3Dtrue and others LOT=3Dfalse. Worst of all, it<br>=

becomes vulnerable to a twitter/reddit/social media blitz which could<br>
attempt to move the date of miner activation around.<br>
<br>
Twitter and reddit drama provide a perfect cover for social attacks on<br>
bitcoin.<br>
<br>
Forced signalling leads to brinksmanship. Where two or more sides<br>
(backed up by social media drama) enter into a game of chicken with<br>
deployed nodes. If one of them doesn't concede then we get a damaging<br>
chain split. And the $1 trillion in value that the bitcoin network<br>
protects is put at risk. =46rom the point of view of a miner or big<br>
exchange stuck in the middle, if they look at the ecosystem of twitter<br>
and reddit (especially if you think about all the problems with bots and<br>=

sockpuppets) they have no idea which consensus rules they should<br>
actually follow and exactly what date they take effect. Miners,<br>
exchanges, merchants and the rest of the ecosystem exist to serve their<br>
customers and users, and trouble happens when they don't know what their<br>=

customers really want. Social media attacks are not just a theoretical<br>
concern; back during the block size drama, the bitcoin reddits were<br>
targetted by bots, sockpuppets and brigading[3].<br>
<br>
Enter flag day activation. With a flag day there can be no<br>
brinksmanship. A social media blitz cant do anything except have its own<br>=

followers fork away. Crucially, miner signalling cant be used to change<br>
the activation date for nodes that didn't choose to and just passively<br>
follow signalling. Changing the activation date requires all those users<br>=

to actually run different node software.<br>
<br>
Flag day activation works simply: we choose a block height and after<br>
that block height the new taproot rules become enforced.<br>
<br>
<br>
Supporters of the permissionless, "users rule" approach of LOT=3Dtrue<br>
should be happy because it completely takes miners out of activation.<br>
<br>
Supporters of the safe, conservative approach of LOT=3Dfalse can be made<br>=

happy with a few ways of derisking:<br>
<br>
* Getting mining pools, businesses and users to look at the code and ask<br>=

if they (a) think its either neutral or good for their business or use<br>
case and (b) they believe others view it similarly and that the<br>
consensus changes proposed have a good social consensus around them.<br>
<br>
* Setting the flag day far in the future (18 months or 2 years in the<br>
original proposal[3]).<br>
<br>
<br>
=3D=3D What if flag day activation is used maliciously? =3D=3D<br>
<br>
What if one day the Core developer team is co-opted and uses the flag<br>
day method to do something bad? For example, a soft fork where sending<br>
to certain blacklisted addresses is not allowed. The bitcoin user<br>
community who wants to resist this can create their own<br>
counter-soft-fork full node, where the first block after the flag day<br>
MUST pay to one of those addresses on the blacklist. This forces a chain<br>=

split between the censorship rules and the no-censorship rules, and its<br>
pretty obvious that the real bitcoin which most people follow will be<br>
the chain without censorship.<br>
<br>
For example, if a group of users didn't agree with taproot then they<br>
could create their own counter-flag-day-activation which requires that a<br>=

transaction is included that does an invalid-spend from a taproot output<br>=

in the first block after the flag day height.<br>
<br>
This is always possible with any user activated soft fork. In BIP8<br>
LOT=3Dtrue it could be done by rejecting block headers with certain<br>
version bits signalled.<br>
<br>
<br>
=3D=3D But it will take so long! =3D=3D<br>
<br>
We seem to be at a deadlock now. This will take less time than any other<br>=

method, because other methods might never happen. BIP8 is dead and from<br>
what I see there's no other credible plan.<br>
<br>
We've already waited years for taproot. I remember listening to talks<br>
about bitcoin from 2015 of people discussing Schnorr signatures. And<br>
given how slow segwit and p2sh adoption were its pretty likely that<br>
we'll waiting a while for taproot to be actually adopted.<br>
<br>
<br>
=3D=3D A social media blitz could still try to activate it early =3D=3D<br>
<br>
The brinksmanship only works because miner signalling can make many<br>
other nodes activate early, even if those other nodes didn't do<br>
anything. There can't be a game of chicken that puts the bitcoin network<br>=

at risk.<br>
<br>
If a group of people did adopt alternative node software which has a<br>
shorter flag day, they actually have a risk of slow blocks. Because they<br>=

cant trick or force any other nodes to come along with them, they are<br>
likely to only have a small economy and therefore would lose a lot of<br>
hashrate. Imagine trading bitcoins for cash in person and instead of<br>
waiting 10 minutes for a confirmation you have to wait 3 hours because<br>
the blocks are slow.<br>
<br>
Also, the argument for downloading and running a different software only<br>=

to speed up activation is pretty weak. Taproot would activate in ~18<br>
months, so why are you so impatient that you need it in 6 months? And<br>
risk slow blocks for you while doing so? The big difference with BIP148<br>
the segwit UASF, is that people *had to* run some other software<br>
otherwise they would get *no soft fork at all*.<br>
<br>
<br>
=3D=3D Without miner signalling how do we know the new rules are even<br>
activated? =3D=3D<br>
<br>
When did you see miners signalling their support for the inflation schedule?=
<br>
<br>
Bitcoin's rules are enforced by wallets backed by full nodes. You'll<br>
always know if your own full node is enforcing the new rules. The thing<br>
that matters isnt miner signalling but your own full node, and the nodes<br>=

of those you trade with.<br>
<br>
Flag day activation is quite similar to the way block reward halvenings<br>
work. At and after block height 630000 miners are only allowed to create<br>=

6.25 BTC rather than 12.5 BTC. Everyone knows that if miners continued<br>
to create 12.5 BTC or more they would be unable to sell or spend those<br>
coins anywhere.<br>
<br>
In 2017 when segwit was being activated people created a huge list of<br>
various bitcoin companies, merchants and wallets:<br>
<a href=3D"https://web.archive.org/web/20171228111943/https://bitcoincore.or=
g/en/segwit_adoption/" rel=3D"noreferrer noreferrer noreferrer" target=3D"_b=
lank">https://web.archive.org/web/20171228111943/https://bitcoincore.org/en/=
segwit_adoption/</a><br>
Looking at that list, you would know that if someone stole coins from a<br>
segwit address they would be unable to deposit them in many exchanges<br>
and merchants: Bitrefill, Bitstamp, Kraken, Localbitcoins, Paxful,<br>
Vaultoro, HitBTC, etc.<br>
<br>
Then what happened is only a month after S2X was beaten this guy moved<br>
40000 BTC to a segwit address, confident about the power of the network<br>
to protect his coins.<br>
<a href=3D"https://old.reddit.com/r/Bitcoin/comments/7tcmi4/bitcointalks_fam=
ous_user_loaded_moved_his_40k_btc/" rel=3D"noreferrer noreferrer noreferrer"=
 target=3D"_blank">https://old.reddit.com/r/Bitcoin/comments/7tcmi4/bitcoint=
alks_famous_user_loaded_moved_his_40k_btc/</a><br>
<br>
If there's ever any doubt about flag day activation we can always draw<br>
up a similar list, although if there's broad consensus about it then<br>
there's no reason why bitcoin businesses wouldn't upgrade to the latest<br>
Core, like they did with every other previous soft fork.<br>
<br>
<br>
=3D=3D This gives the impression that Core developers control the protocol =3D=
=3D<br>
<br>
This objection has a mirror image argument: BIP8 with LOT=3Dfalse gives<br>
the impression that miners control the protocol(!)<br>
<br>
Eventually some group has to make a decision. We will ask the bitcoin<br>
economy and users what they think of flag day activation. It's pretty<br>
clear that nobody seriously objects to taproot, and as described above<br>
if Core developers did something evil the community could resist it with<br>=

a counter-flag-day-activation.<br>
<br>
<br>
<br>
=3D=3D TL;DR =3D=3D<br>
<br>
I believe flag day activation is the way forward. It should answer all<br>
the objections and risks which make other methods too controversial.<br>
Let's go ahead and bring taproot to bitcoin!<br>
<br>
<br>
<br>
=3D=3D References =3D=3D<br>
<br>
[1] -<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febr=
uary/018498.html" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank"=
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/01849=
8.html</a><br>
&nbsp; &nbsp; &nbsp; luke-jr posts saying LOT=3Dfalse in his view reintroduc=
es a bug, he<br>
compares it to introducing an inflation bug and just hoping that miners<br>
will not exploit it.<br>
<br>
[2] -<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febr=
uary/018425.html" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank"=
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/01842=
5.html</a><br>
&nbsp; &nbsp; &nbsp; This whole thread has many people disagreeing with LOT=3D=
true<br>
<br>
[3] -<br>
<a href=3D"https://old.reddit.com/r/Bitcoin/comments/4biob5/research_into_in=
stantaneous_vote_behavior_in/" rel=3D"noreferrer noreferrer noreferrer" targ=
et=3D"_blank">https://old.reddit.com/r/Bitcoin/comments/4biob5/research_into=
_instantaneous_vote_behavior_in/</a><br>
<br>
<a href=3D"https://old.reddit.com/r/Bitcoin/comments/3v04pd/can_we_please_ha=
ve_a_civil_discussion_about/cxjnz1d/?context=3D1" rel=3D"noreferrer noreferr=
er noreferrer" target=3D"_blank">https://old.reddit.com/r/Bitcoin/comments/3=
v04pd/can_we_please_have_a_civil_discussion_about/cxjnz1d/?context=3D1</a><b=
r>
<br>
<a href=3D"https://old.reddit.com/r/Bitcoin/comments/41ykkt/members_trying_t=
o_destroy_bitcoin_on_this_thread/cz6ccka/?context=3D3" rel=3D"noreferrer nor=
eferrer noreferrer" target=3D"_blank">https://old.reddit.com/r/Bitcoin/comme=
nts/41ykkt/members_trying_to_destroy_bitcoin_on_this_thread/cz6ccka/?context=
=3D3</a><br>
<br>
[4] -<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Febr=
uary/018495.html" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank"=
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/01849=
5.html</a><br>
&nbsp; &nbsp; &nbsp; Matt Corallo's flag day activation proposal<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer n=
oreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundation.org</sp=
an><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/span><br></div></blockquote></body></html>=

--Apple-Mail-C456C2B2-707D-4C44-A899-22A967BEB649--