From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 76473C0001 for ; Wed, 3 Mar 2021 14:39:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 66146400ED for ; Wed, 3 Mar 2021 14:39:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net 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 Lax865GLPzE8 for ; Wed, 3 Mar 2021 14:39:31 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by smtp2.osuosl.org (Postfix) with ESMTPS id 35E02400E9 for ; Wed, 3 Mar 2021 14:39:31 +0000 (UTC) Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4DrGq65G32zDv2F for ; Wed, 3 Mar 2021 06:39:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1614782370; bh=YTC8TfZC2d6CPEAAnGOyBkDWnNoC0HIYlacfNTnz3co=; h=From:Subject:To:Date:From; b=mM2PrPQLBWswzgu4Ayd2FQiruyLGagqZTrqLbq5gSUDJJAcgKAxgEHMm0F6aUlRn3 /j1at3/Fwq1BEFm176/4mF5qbyL+QGZyxEdNYc9H3YAu2ZBpB7ubYoc9ABkRc+fqgW xpTcUn0RivicfX7jOy8TA+jvl4SA5kZnRKf7fIFs= X-Riseup-User-ID: 38B586D61AB4BF4880748795E511933C5C07D1C012B4FE18A40EFD7F4CB0AD62 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4DrGq46LlQz5vNX for ; Wed, 3 Mar 2021 06:39:28 -0800 (PST) From: Chris Belcher Autocrypt: addr=belcher@riseup.net; prefer-encrypt=mutual; keydata= xsFNBFPk74oBEACzBLjd+Z5z7eimqPuObFTaJCTXP7fgZjgVwt+q94VQ2wM0ctk/Ft9w2A92 f14T7PiHaVDjHxrcW+6sw2VI2f60T8Tjf+b4701hIybluWL8DntG9BW19bZLmjAj7zkgektl YNDUrlYcQq2OEHm/MGk6Ajt2RA56aRKqoz22e+4ZA89gDgamxUAadul7AETSsgqOEUDI0FKR FODzoH65w1ien/DLkG1f76jd0XA6AxrESJVO0JzvkTnJGElBcA37rYaMmDi4DhG2MY4u63VE 8h6DyUXcRhmTZIAj+r+Ht+KMDiuiyQcKywCzzF/7Ui7YxqeAgjm5aPDU2E8X9Qd7cqHQzFM7 ZCqc9P6ENAk5a0JjHw0d0knApboSvkIJUB0j1xDIS0HaRlfHM4TPdOoDgnaXb7BvDfE+0zSz WkvAns9oJV6uWdnz5kllVCjgB/FXO4plyFCHhXikXjm1XuQyL8xV88OqgDFXwVhKrDL9Pknu sTchYm3BS2b5Xq1HQqToT3I2gRGTtDzZVZV0izCefJaDp1mf49k2cokDEfw9MroEj4A0Wfht 0J64pzlBYn/9zor5cZp/EAblLRDK6HKhSZArIiDR1RC7a6s7oTzmfn0suhKDdTzkbTAnDsPi Dokl58xoxz+JdYKjzVh98lpcvMPlbZ+LwIsgbdH4KZj7mVOsJwARAQABzR9DaHJpcyBCZWxj aGVyIDxmYWxzZUBlbWFpbC5jb20+wsF+BBMBAgAoBQJT5O+KAhsDBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAAKCRDvc06md/MRKS8jD/9P9fSYSIVjltL9brAMfIu7wJn0H0lX TbcuCM2uQitJ3BNxI3c7aq5dEby27u5Ud54otncDJuRPQVDKs6H7t1rInitgJ1MTQ9/aQGFA btKcgtVIMFbeClzTTfWr4W7fE45NI7E9EANgk5JfmWh3U+KINYLF5RtqynYocrsP6zOV+G9A HCpBemd9TN60CoMLMyMzTHEW1oQffaVAXY8DgthEYO/odWYIod7VTmEm0zU1aSysPqMwPWNm 8XIl0f8SfKQyZlAU8e1eCFVCenkE44FKC5qQNYc2UxexEYtfCWChTGc4oHKxIyYmTCCefsQF LvgwtvlNHRXHSDKSPSNcRcpl8DFpNEKrmMlkJ8Mx+YR05CydlTQ0bI3FBohJC+UHrjD5I3hA wJUC1o+yVSOEd+zN3cG1EECIwkEQSmBgG5t/le2RdzfXOdpf9ku2/zoBpq00R54JxUKlfRM7 OPTv7X+1AKHkxOySdCZwGgvdh2Whuqs4kTvtco00gCFM9fBd5oi1RJuHtxHsj8+/XU15UItb jeo96CIlM5YUeoRLPT5mxZYWgYAARFeSFReNq/Tuwq9d8EokUrtAyrPayznliy53UJfWDVzl 925c0Cz0HWaP2fWj+uFcj/8K0bhptuWJQy0Poht1z3aJC1UjEgr1Xz8I7jeSJmIlA9plcJw2 k4dhWc7BTQRT5O+KARAAyFxAM28EQwLctr0CrQhYWZfMKzAhCw+EyrUJ+/e4uiAQ4OyXifRr ZV6kLRul3WbTB1kpA6wgCShO0N3vw8fFG2Cs6QphVagEH8yfQUroaVxgADYOTLHMOb7INS8r KI/uRNmE6bXTX27oaqCEXLMycqYlufad7hr42S/T8zNh5m2vl6T/1Poj2/ormViKwAxM+8qf xd8FNI4UKmq2zZE9mZ5PiSIX0qRgM0yCvxV39ex/nhxzouTBvv4Lb1ntplR/bMLrHxsCzhyM KDgcX7ApGm+y6YEsOvzw9rRCRuJpE4lth8ShgjTtNTHfklBD6Ztymc7q7bdPWpKOEvO5lDQ6 q8+KfENv862cOLlWLk7YR2+mHZ1PXGhWC7ggwEkfGJoXo0x8X+zgUKe2+9Jj4yEhfL0IbFYC z2J5d+cWVIBktI3xqkwLUZWuAbE3vgYA4h8ztR6l18NTPkiAvpNQEaL4ZRnAx22WdsQ8GlEW dyKZBWbLUdNcMmPfGi5FCw2nNvCyN6ktv5mTZE12EqgvpzYcuUGQPIMV9KTlSPum3NLDq8QI 6grbG8iNNpEBxmCQOKz2/BuYApU2hwt2E44fL8e6CRK3ridcRdqpueg75my6KkOqm8nSiMEc /pVIHwdJ9/quiuRaeC/tZWlYPIwDWgb8ZE/g66z35WAguMQ+EwfvgAUAEQEAAcLBZQQYAQIA DwUCU+TvigIbDAUJEswDAAAKCRDvc06md/MRKaZwD/9OI3o3gVmst/mGx6hVQry++ht8dFWN IiASPBvD3E5EWbqWi6mmqSIOS6CxjU0PncxTBPCXtzxo/WzuHGQg/xtNeQ0T8b2lBScZAw93 qm1IcHXLUe5w/Tap6YaDmSYCIZAdtbHzYfPW4JK7cmvcjvF8jhTFOBEOFVQkTi19G7caVot0 +wL1e2DRHDXAe5CinEpaLBlwHeEu/5j6wc3erohUZlK9IbAclj4iZTQbaq3EyqUXl59dBOON xmL5edJxzVishIYQGIyA9WP1SylXt+kO82NEqZG2OxdXAlzjuJ8C2pAG+nbLtDo4hcsiN/MA aX9/JB7MXclT5ioerF4yNgKEdfq7LmynsTUd8w/Ilyp7AD+BWoujyO94i8h9eKvjf9PvSwxQ uAjRpxne7ZJD8vCsMNXBHSbeEK2LiwStHL/w473viXpDD53J6OLxX6a5RummR+rixbMH7dgK MJQ7FlyDphm3or6CSkGEir1KA0y1vqQNFtHhguFapAWMDKaJjQQNgvZUmOo6hbZqmvUF1OWc d6GA6j3WOUe3fDJXfbq6P9Jmxq64op887dYKsg7xjQq/7KM7wyRcqXXcbBdgvNtVDP+EnzBN HyYY/3ms4YIHE5JHxQ9LV4yPcWkYTvb1XpNIFVbrSXAeyGHVNT+SO6olFovbWIC3Az9yesaM 1aSoTg== To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net> Date: Wed, 3 Mar 2021 14:39:23 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2021 14:39:32 -0000 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