path: root/9b/83eb7746cfcf64de7841ffebf6a1009c59cf8a

Return-Path: <roconnor@blockstream.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A5DBAC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 22:01:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 8B8D78427E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 22:01:18 +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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20150623.gappssmtp.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id WRoPSIaLe3xE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 22:01:16 +0000 (UTC)
X-Greylist: delayed 02:46:36 by SQLgrey-1.8.0
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com
 [IPv6:2607:f8b0:4864:20::835])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 3A6C08418A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 22:01:16 +0000 (UTC)
Received: by mail-qt1-x835.google.com with SMTP id v64so18870472qtd.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 03 Mar 2021 14:01:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=3f7/nyrh/SlnshLGZWCHnUJNjXKl3Rb/ipIrUT25qwE=;
 b=B63lR7CIeC4QdGeeiPjBsJU8JSGfdgRi/V9N/nbVKVMP0c8oCiV58jR6SvDKnZ6ECK
 2JYjk7pJv2TP2sguO5zK3mQNpOJIG/DjtPUYGvD8C3S/2qAMfH0DziVHHN9N8sztOB/r
 pgn6t1AveNZCZLDWBciDuVOc+2gEUZJTuKvYolWqsWtiCuzwOLYUoLdLq6DHvHXDmaQs
 N5TTGSUx+WSIxEhHdtBQaTVzSGh/2h8/83pqB4x6vBCEOAqlS4AJn3wFuQZd4Oax58n6
 /3QFmSPcdXFMNuAEyKoM2pkRq7e+mSGjmhmEWW4xMk4oTn6GvjphR4y9w2urhfYuvsYp
 uoaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=3f7/nyrh/SlnshLGZWCHnUJNjXKl3Rb/ipIrUT25qwE=;
 b=H1veXr9Aq9WBLFmQf/cYLyBS0+krZnP8Phm0aWMVwBzWolmr7r2NWXy/C9N5ZQYIBC
 /CR2zw1O1TomFn29BLZFdJkz5diTJl5MT+TFemwzvlyywufw7gWxY/LQhx9Radpp48ar
 BTbOrBDNdHJcvMg32u4jvOfg6rCNqstZ5GNlbl/7bWgFS+AMEfspGPUHKsGMVFiPDFeF
 3vxx8RtW45uoZOVqHVIupZQZXmrSFXehukxlkrTQpZ6BgVf+oT6K6VckJDgLJHMbUlhf
 HeLV12tt/wR5IIPsL4F76gWy51oNEGWis0FUbV8L3dFuvtAE0z8h0vi9/sfrppeOJSy0
 SeBg==
X-Gm-Message-State: AOAM532kHMzZ6Te41Tmuc2XUr/JwibmR/DZELuna8lNbdTvkrildAEw5
 jTh01ZsQkZzvqYqfO/s8HBY1CvzHM8kS7zAesyqm91Ik38c6/AFy
X-Google-Smtp-Source: ABdhPJz0SBicxWLdv975qhOvBtz0F0gd0/lceVBIXsh2puOqxUqplfAJK4Tf6y1BpuCJRE+jIRLlzXk0J/7dZ2qGmSY=
X-Received: by 2002:a05:622a:315:: with SMTP id
 q21mr658930qtw.324.1614798512333; 
 Wed, 03 Mar 2021 11:08:32 -0800 (PST)
MIME-Version: 1.0
References: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net>
In-Reply-To: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Wed, 3 Mar 2021 14:08:21 -0500
Message-ID: <CAMZUoKkWmdwi-VH3WUvFfG+5MDK3xhvZUac3eBQbxXX_b_btWw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b646f805bca69385"
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: Wed, 03 Mar 2021 22:01:18 -0000

--000000000000b646f805bca69385
Content-Type: text/plain; charset="UTF-8"

While I support essentially any proposed taproot activation method,
including a flag day activation, I think it is premature to call BIP8 dead.

Even today, I still think that starting with BIP8 LOT=false is, generally
speaking, considered a reasonably safe activation method in the sense that
I think it will be widely considered as a "not wholly unacceptable"
approach to activation.

After a normal and successful Core update with LOT=false, we will have more
data showing broad community support for the taproot upgrade in hand.  In
the next release, 6 months later or so, Core could then confidently deploy
a BIP8 LOT=true client, should it prove to be necessary.  A second Core
deployment of LOT=true would mitigate some of the concerns with LOT=false,
but still provide a period beforehand to objective actions taken by the
community in support of taproot.  We don't even have to have agreement
today on a second deployment of LOT=true after 6 months to start the
process of a LOT=false deployment. The later deployment will almost
certainly be moot, and we will have 6 months to spend debating the LOT=true
deployment versus doing a flag day activation or something else.

I don't think we need to start self-sabotaging our efforts to get taproot
activated this year just yet.  Let's cherry-pick the commits of PR #19573
to split it up into non-MUST_SIGNAL and MUST_SIGNAL components, and get
some reviews on that first.  Then afterwards we can decide if BIP8 is dead
or not.

On Wed, Mar 3, 2021 at 9:39 AM Chris Belcher via bitcoin-dev <
bitcoin-dev@lists.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.
>
> 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=true and others LOT=false. Worst of all, it
> becomes vulnerable to a twitter/reddit/social media blitz which could
> attempt to move the date of miner activation around.
>
> Twitter and reddit drama provide a perfect cover for social attacks on
> bitcoin.
>
> 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. From 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].
>
> 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.
>
> Flag day activation works simply: we choose a block height and after
> that block height the new taproot rules become enforced.
>
>
> Supporters of the permissionless, "users rule" approach of LOT=true
> should be happy because it completely takes miners out of activation.
>
> Supporters of the safe, conservative approach of LOT=false can be made
> happy with a few ways of derisking:
>
> * 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.
>
> * Setting the flag day far in the future (18 months or 2 years in the
> original proposal[3]).
>
>
> == What if flag day activation is used maliciously? ==
>
> 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.
>
> 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.
>
> This is always possible with any user activated soft fork. In BIP8
> LOT=true it could be done by rejecting block headers with certain
> version bits signalled.
>
>
> == But it will take so long! ==
>
> 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.
>
> 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.
>
>
> == A social media blitz could still try to activate it early ==
>
> 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.
>
> 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.
>
> 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*.
>
>
> == Without miner signalling how do we know the new rules are even
> activated? ==
>
> When did you see miners signalling their support for the inflation
> schedule?
>
> 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.
>
> 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.
>
> 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/segwit_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.
>
> 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/
>
> 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.
>
>
> == This gives the impression that Core developers control the protocol ==
>
> This objection has a mirror image argument: BIP8 with LOT=false gives
> the impression that miners control the protocol(!)
>
> 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.
>
>
>
> == TL;DR ==
>
> 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!
>
>
>
> == References ==
>
> [1] -
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html
>       luke-jr posts saying LOT=false in his view reintroduces a bug, he
> compares it to introducing an inflation bug and just hoping that miners
> will not exploit it.
>
> [2] -
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018425.html
>       This whole thread has many people disagreeing with LOT=true
>
> [3] -
>
> https://old.reddit.com/r/Bitcoin/comments/4biob5/research_into_instantaneous_vote_behavior_in/
>
>
> https://old.reddit.com/r/Bitcoin/comments/3v04pd/can_we_please_have_a_civil_discussion_about/cxjnz1d/?context=1
>
>
> https://old.reddit.com/r/Bitcoin/comments/41ykkt/members_trying_to_destroy_bitcoin_on_this_thread/cz6ccka/?context=3
>
> [4] -
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018495.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
>

--000000000000b646f805bca69385
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>While I support essentially any proposed taproot acti=
vation method, including a flag day activation, I think it is premature to =
call BIP8 dead.</div><div><br></div><div>Even today, I still think that sta=
rting with BIP8 LOT=3Dfalse is, generally speaking, considered a reasonably=
 safe activation method in the sense that I think it will be widely conside=
red as a &quot;not wholly unacceptable&quot; approach to activation.</div><=
div><br></div><div>After a normal and successful Core update with LOT=3Dfal=
se, we will have more data showing broad community support for the taproot =
upgrade in hand.=C2=A0 In the next release, 6 months later or so, Core coul=
d then confidently deploy a BIP8 LOT=3Dtrue client, should it prove to be n=
ecessary.=C2=A0 A second Core deployment of LOT=3Dtrue would mitigate some =
of the concerns with LOT=3Dfalse, but still provide a period beforehand to =
objective actions taken by the community in support of taproot.=C2=A0 We do=
n&#39;t even have to have agreement today on a second deployment of LOT=3Dt=
rue after 6 months to start the process of a LOT=3Dfalse deployment. The la=
ter deployment will almost certainly be moot, and we will have 6 months to =
spend debating the LOT=3Dtrue deployment versus doing a flag day activation=
 or something else.<br></div><div><br></div><div>I don&#39;t think we need =
to start self-sabotaging our efforts to get taproot activated this year jus=
t yet.=C2=A0 Let&#39;s cherry-pick the commits of PR #19573 to split it up =
into non-MUST_SIGNAL and MUST_SIGNAL components, and get some reviews on th=
at first.=C2=A0 Then afterwards we can decide if BIP8 is dead or not.<br></=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Wed, Mar 3, 2021 at 9:39 AM Chris Belcher via bitcoin-dev &lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxf=
oundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">The bitcoin world is close to total gridlock on the question o=
f how to<br>
activate taproot. There&#39;s no agreement on activation[1][2], and if an<b=
r>
agreement isn&#39;t reached then nothing happens. That would be really<br>
terrible because we&#39;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&#39;t concede then we get a damaging<b=
r>
chain split. And the $1 trillion in value that the bitcoin network<br>
protects is put at risk. From 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&#39;t know what thei=
r<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&#39;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, &quot;users rule&quot; approach of LOT=3D=
true<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&#39;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&#39;s no other credible plan.<br>
<br>
We&#39;ve already waited years for taproot. I remember listening to talks<b=
r>
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&#39;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&#39;t do<br>
anything. There can&#39;t be a game of chicken that puts the bitcoin networ=
k<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&#39;s rules are enforced by wallets backed by full nodes. You&#39;l=
l<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.o=
rg/en/segwit_adoption/" rel=3D"noreferrer" target=3D"_blank">https://web.ar=
chive.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_fa=
mous_user_loaded_moved_his_40k_btc/" rel=3D"noreferrer" target=3D"_blank">h=
ttps://old.reddit.com/r/Bitcoin/comments/7tcmi4/bitcointalks_famous_user_lo=
aded_moved_his_40k_btc/</a><br>
<br>
If there&#39;s ever any doubt about flag day activation we can always draw<=
br>
up a similar list, although if there&#39;s broad consensus about it then<br=
>
there&#39;s no reason why bitcoin businesses wouldn&#39;t upgrade to the la=
test<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&#39;s pretty<b=
r>
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&#39;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-Feb=
ruary/018498.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2021-February/018498.html</a><br>
=C2=A0 =C2=A0 =C2=A0 luke-jr posts saying LOT=3Dfalse in his view reintrodu=
ces 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-Feb=
ruary/018425.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2021-February/018425.html</a><br>
=C2=A0 =C2=A0 =C2=A0 This whole thread has many people disagreeing with LOT=
=3Dtrue<br>
<br>
[3] -<br>
<a href=3D"https://old.reddit.com/r/Bitcoin/comments/4biob5/research_into_i=
nstantaneous_vote_behavior_in/" rel=3D"noreferrer" target=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_h=
ave_a_civil_discussion_about/cxjnz1d/?context=3D1" rel=3D"noreferrer" targe=
t=3D"_blank">https://old.reddit.com/r/Bitcoin/comments/3v04pd/can_we_please=
_have_a_civil_discussion_about/cxjnz1d/?context=3D1</a><br>
<br>
<a href=3D"https://old.reddit.com/r/Bitcoin/comments/41ykkt/members_trying_=
to_destroy_bitcoin_on_this_thread/cz6ccka/?context=3D3" rel=3D"noreferrer" =
target=3D"_blank">https://old.reddit.com/r/Bitcoin/comments/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-Feb=
ruary/018495.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2021-February/018495.html</a><br>
=C2=A0 =C2=A0 =C2=A0 Matt Corallo&#39;s flag day activation proposal<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000b646f805bca69385--