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 <bitcoin-dev@lists.linuxfoundation.org> 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>> 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> 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> 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> 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--