diff options
| author | Luke Dashjr <luke@dashjr.org> | 2022-04-21 02:05:47 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-04-21 02:05:52 +0000 |
| commit | e2ba68f51fd0f186e32934c8f30e38c2ba0231f5 (patch) | |
| tree | 82425ee052e3ba7b3b37e3f57e4d4062f8c6ebf6 | |
| parent | 0407250ef8a379bdf7454fbcb6ae75d5dfe0c0d3 (diff) | |
| download | pi-bitcoindev-e2ba68f51fd0f186e32934c8f30e38c2ba0231f5.tar.gz pi-bitcoindev-e2ba68f51fd0f186e32934c8f30e38c2ba0231f5.zip | |
Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
| -rw-r--r-- | e9/e66a5ca32409f4734afeecc6362d625372acb0 | 177 |
1 files changed, 177 insertions, 0 deletions
diff --git a/e9/e66a5ca32409f4734afeecc6362d625372acb0 b/e9/e66a5ca32409f4734afeecc6362d625372acb0 new file mode 100644 index 000000000..677d638d7 --- /dev/null +++ b/e9/e66a5ca32409f4734afeecc6362d625372acb0 @@ -0,0 +1,177 @@ +Return-Path: <luke@dashjr.org> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 4F40CC002C + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 21 Apr 2022 02:05:52 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 457E34015A + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 21 Apr 2022 02:05:52 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -4.4 +X-Spam-Level: +X-Spam-Status: No, score=-4.4 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, + SPF_HELO_NONE=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=dashjr.org +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 0KqHgL1ld9C5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 21 Apr 2022 02:05:51 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +Received: from zinan.dashjr.org (zinan.dashjr.org [IPv6:2001:470:88ff:2f::1]) + by smtp2.osuosl.org (Postfix) with ESMTP id D214D4013B + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 21 Apr 2022 02:05:50 +0000 (UTC) +Received: from ishibashi.lan (unknown [12.151.133.18]) + (Authenticated sender: luke-jr) + by zinan.dashjr.org (Postfix) with ESMTPSA id C525538A189E; + Thu, 21 Apr 2022 02:05:48 +0000 (UTC) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan; + t=1650506749; bh=j07vl4mIXnZukqkKv2dVkgJKpXF2dFfvlNOTZv5raM4=; + h=From:To:Subject:Date:References:In-Reply-To; + b=eGFe9xrqC6eN0BmLtqvi/1YLMyNGII2RJ/OWR0RP8GNpA4m7Z4N51DrALxgpSBMZH + Qqs5bWc4REnCViOPMJY0CgprF5PYrXJriEqgyOyZ0Jvv9H1BX0GvSi3oFfALMTbHa+ + D13t4Pgufu+PzXPR4oIE7H1k3KyuYZAIW/ZKKhsw= +From: Luke Dashjr <luke@dashjr.org> +To: bitcoin-dev@lists.linuxfoundation.org, "David A. Harding" <dave@dtrt.org> +Date: Thu, 21 Apr 2022 02:05:47 +0000 +User-Agent: KMail/1.9.10 +References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> +In-Reply-To: <64a34b4d46461da322be51b53ec2eb01@dtrt.org> +X-KMail-QuotePrefix: > +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +Content-Disposition: inline +Message-Id: <202204210205.47678.luke@dashjr.org> +Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, + e.g. for CTV +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, 21 Apr 2022 02:05:52 -0000 + +1-2 can be mitigated to some extent by encoding an expiry height in the +address (and pubkey?), and honouring CTV for UTXOs during the active period. +It might take longer to remove CTV code post-deactivation, but that's simply +a tradeoff to consider. + +The bigger issue with CTV is the miner-decision route. Either CTV has +community support, or it doesn't. If it does, miners shouldn't have the +ability to veto it. If it doesn't, miners shouldn't have the ability to +activate it (making it a 51% attack more than a softfork). + + +On Thursday 21 April 2022 01:04:53 David A. Harding via bitcoin-dev wrote: +> Hi all, +> +> The main criticisms I'm aware of against CTV seem to be along the +> following lines: +> +> 1. Usage, either: +> a. It won't receive significant real-world usage, or +> b. It will be used but we'll end up using something better later +> 2. An unused CTV will need to be supported forever, creating extra +> maintenance +> burden, increasing security surface, and making it harder to evaluate +> later +> consensus change proposals due to their interactions with CTV +> +> Could those concerns be mitigated by making CTV an automatically +> reverting +> consensus change with an option to renew? E.g., redefining OP_NOP4 as +> OP_CTV +> for five years from BIP119's activation date and then reverting to +> OP_NOP4. +> If, prior to the end of those five years, a second soft fork was +> activated, it +> could continue enforcing the CTV rules either for another five years or +> permanently. +> +> This would be similar in nature to the soft fork described in BIP50 +> where the +> maximum block size was temporarily reduced to address the BDB locks +> issue and +> then allowed to return to its original value. In Script terms, any use +> of +> OP_CTV would effectively be: +> +> OP_IF +> <arguments> OP_CTV +> OP_ELSE +> <5 years after activation> OP_CLTV +> OP_ENDIF +> +> As long as we are absolutely convinced CTV will have no negative effects +> on the +> holders or receivers of non-CTV coins, I think an automatically +> reverting soft +> fork gives us some ability to experiment with new features without +> committing +> ourselves to live with them forever. +> +> The main downsides I can see are: +> +> 1. It creates a big footgun. Anyone who uses CTV without adequately +> preparing for +> the reversion could easily lose their money. +> +> 2. Miners would be incentivized to censor spends of the reverting +> opcode near its reversion date. E.g., if Alice receives 100 bitcoins +> to a +> script secured only by OP_CTV and attempts to spend them the day +> before it +> becomes OP_NOP4, miners might prefer to skip confirming that +> transaction even +> if it pays a high feerate in favor of spending her 100 bitcoins to +> themselves +> the next day after reversion. +> +> The degree to which this is an issue will depend on the diversity of +> hashrate and the willingness of any large percentage of hashrate to +> deliberately reorg the chain to remove confirmed transactions. This +> could be +> mitigated by having OP_CTV change to OP_RETURN, destroying any +> unspent CTV-only +> coins so that any censoring miners only benefited from the (hopefully +> slight) +> decrease in bitcoin currency supply. +> +> 3. A bias towards keeping the change. Even if it turned out very few +> people +> really used CTV, I think there would be a bias at the end of five +> years towards +> "why not just keep it". +> +> 4. The drama doesn't end. Activating CTV now, or decisively not +> activating it, +> may bring to an end our frequent discussions about it (though I +> wouldn't +> count on that). An automatically reverting soft fork would probably +> guarantee we'll have further consensus-level discussions about CTV in +> the +> future. +> +> Thanks for reading. I'm curious to hear y'alls thoughts, +> +> -Dave +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + + |