path: root/5a/d2c66280238dc586af1267212b884b8557892e

Return-Path: <vincent.truong@procabiak.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B0D90C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 21:03:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 9CC7A605AE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 21:03:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.142
X-Spam-Level: *
X-Spam-Status: No, score=1.142 tagged_above=-999 required=5
 tests=[BAYES_40=-0.001, DATE_IN_PAST_24_48=1.34, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=procabiak.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id MuX9P6ZNkzhh
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 21:03:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com
 [IPv6:2a00:1450:4864:20::22f])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 3F42C605A8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Mar 2021 21:03:08 +0000 (UTC)
Received: by mail-lj1-x22f.google.com with SMTP id e2so27931355ljo.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 04 Mar 2021 13:03:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=procabiak.com; s=procabiakindustries;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=HRSuFgAoIR3/9AN7uCiVTEsvJmDLhOSGgl/sYsXpPd8=;
 b=DZnEuTtWWDjfjJ03n5K0Yo0lump28ZUWYQsaFAUBahQNnnazYcqV57ezS4A9da5huv
 imZb451ypxeDZYKqNXM3iwTq8qnyxd8PzD0DSVm6MrpvKTU/DGWQOcoqUULh6WIFLA/C
 7bKBYD65BZg59MOZxyn9eXmJAO4oQTmUpilag=
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=HRSuFgAoIR3/9AN7uCiVTEsvJmDLhOSGgl/sYsXpPd8=;
 b=Mjt5Nb6S/5jTd2RHN53+GL8oP3eCEtQBp+QSSjMmXRVEV4unJn6Epx1AlLQ4ZB5SAI
 aGDpue27zHd/IEGF2iUooVi6yYZWjS/c/p0GmVdjiD9cDBt5oMSHPHORGgWRou1To2zU
 CrCNQ3H+Uan0+Amt2X7ESIYFg1c6YjES3Y01YsI+9TzbKF4vthOTa1SxFSbolYoCSiMP
 mz12rLMDWr3t3p2v/oeslnKa/JDdl32xOR3c0cYjiyaIveo7dmN7MdH0cT19WhQ1ATAX
 kSYKMyBLAMip//+AzFghWuMIuIMNXWeItdrowEj74QO1FIaOaD9Hes88uYKZM0Q/6gbO
 ebMg==
X-Gm-Message-State: AOAM530QaYHNbCoutctyRuhzRm/IGQb8fo4h8ezXayl9Km9Ko+QVWltt
 bYTwf0SqdjcL/hXXA471zQModb2+QegB2RTdK23YQ2o4bk+cbUj/
X-Google-Smtp-Source: ABdhPJzfTHYK+MlHCU6/KqSOUYaWjMoLa921zT3yooG0ClMGtad9VEmT5uMINAdL2QOMDINlAXDiKxW3hkz0q+rd/Dw=
X-Received: by 2002:a17:906:5a8f:: with SMTP id
 l15mr7050661ejq.462.1614788394434; 
 Wed, 03 Mar 2021 08:19:54 -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: Vincent Truong <vincent.truong@procabiak.com>
Date: Thu, 4 Mar 2021 03:19:42 +1100
Message-ID: <CACrzPemtN4+fJ7ALAr=BvsMjmE8nXbOY4COyT-XdBMQbBy5r4Q@mail.gmail.com>
To: Chris Belcher <belcher@riseup.net>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a3542305bca4387b"
X-Mailman-Approved-At: Thu, 04 Mar 2021 23:22:18 +0000
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 21:03:10 -0000

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

I must remind everyone of Mike Hearn's proposal not many years ago, which
ought to be on everyone's mind right now. "Every soft fork should be a hard
fork, and that soft forks are inherently dangerous because old nodes are
tricked 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 ignore new rules, is.

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
day hard fork.

Bitcoin Cash/Bcash has already tested for you how a market driven hard fork
should work. Bitcoin didn't die. We should be learning from the mistakes
made in those early hard forks to not repeat them when Bitcoin hard forks -
like having replay protection written before deployment.

If it's not evident within the first 6-12 blocks which fork is winning,
then the market will trade it out. Just like what happened with Bitcoin
Cash/Bcash.

Not only that, it stops the drama of Bitcoin Core devs from "being in
control" of consensus. The market will choose, you just create the safest
way for users to participate. The market is consensus. Rough consensus is
just the conversation starter.


On Thu, 4 Mar 2021, 1: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
>

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

<div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">I must remi=
nd everyone of Mike Hearn&#39;s proposal not many years ago, which ought to=
 be on everyone&#39;s mind right now. &quot;Every soft fork should be a har=
d fork, and that soft forks are inherently dangerous because old nodes are =
tricked to not know what the new nodes are doing&quot; (paraphrased). Wheth=
er taproot is dangerous is not the issue; whether old nodes should or shoul=
d not ignore new rules, is.</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">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 fl=
ag day hard fork.<div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"=
auto">Bitcoin Cash/Bcash has already tested for you how a market driven har=
d fork should work. Bitcoin didn&#39;t die. We should be learning from the =
mistakes made in those early hard forks to not repeat them when Bitcoin har=
d forks - like having replay protection written before deployment.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto"><span style=3D"font-family:sans-=
serif">If it&#39;s not evident within the first 6-12 blocks which fork is w=
inning, then the market will trade it out. Just like what happened with Bit=
coin Cash/Bcash.</span><br></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">Not only that, it stops the drama of Bitcoin Core devs from &quot;being=
 in control&quot; of consensus. The market will choose, you just create the=
 safest way for users to participate. The market is consensus. Rough consen=
sus is just the conversation starter.</div><div dir=3D"auto"><br></div></di=
v></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Thu, 4 Mar 2021, 1:39 am Chris Belcher via bitcoin-dev, &lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=
=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">The bitcoin world is close to total gridl=
ock on the question of 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 noreferrer noreferrer" target=3D"=
_blank">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_fa=
mous_user_loaded_moved_his_40k_btc/" rel=3D"noreferrer noreferrer noreferre=
r" target=3D"_blank">https://old.reddit.com/r/Bitcoin/comments/7tcmi4/bitco=
intalks_famous_user_loaded_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 noreferrer noreferrer" target=3D"_blan=
k">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/01=
8498.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 noreferrer noreferrer" target=3D"_blan=
k">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/01=
8425.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 noreferrer noreferrer" ta=
rget=3D"_blank">https://old.reddit.com/r/Bitcoin/comments/4biob5/research_i=
nto_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 norefe=
rrer noreferrer" target=3D"_blank">https://old.reddit.com/r/Bitcoin/comment=
s/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 n=
oreferrer noreferrer" target=3D"_blank">https://old.reddit.com/r/Bitcoin/co=
mments/41ykkt/members_trying_to_destroy_bitcoin_on_this_thread/cz6ccka/?con=
text=3D3</a><br>
<br>
[4] -<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Feb=
ruary/018495.html" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blan=
k">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/01=
8495.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" rel=3D"noreferrer =
noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000a3542305bca4387b--