diff options
| author | Anthony Towns <aj@erisian.com.au> | 2022-02-24 16:53:05 +1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-02-24 06:53:17 +0000 |
| commit | 7545d2f81f20c462b6a393aac886afada463f732 (patch) | |
| tree | bcbd95e392e04b2698a2f50dc16e17e6d9550997 /5a | |
| parent | 93032cf03dfb5aae03e938d1f0bc1257aefb5de0 (diff) | |
| download | pi-bitcoindev-7545d2f81f20c462b6a393aac886afada463f732.tar.gz pi-bitcoindev-7545d2f81f20c462b6a393aac886afada463f732.zip | |
Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
Diffstat (limited to '5a')
| -rw-r--r-- | 5a/92eb7e63cea8c139121c3976effd04531ee051 | 171 |
1 files changed, 171 insertions, 0 deletions
diff --git a/5a/92eb7e63cea8c139121c3976effd04531ee051 b/5a/92eb7e63cea8c139121c3976effd04531ee051 new file mode 100644 index 000000000..2edbe3d87 --- /dev/null +++ b/5a/92eb7e63cea8c139121c3976effd04531ee051 @@ -0,0 +1,171 @@ +Return-Path: <aj@erisian.com.au> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id D8F11C0011 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 24 Feb 2022 06:53:17 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id B9929401DF + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 24 Feb 2022 06:53:17 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.621 +X-Spam-Level: +X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, + SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] + autolearn=no autolearn_force=no +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id yEyyoxhA7ZyP + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 24 Feb 2022 06:53:15 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 96723401DD + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 24 Feb 2022 06:53:15 +0000 (UTC) +Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) + by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) + id 1nN7zy-0003UB-0W; Thu, 24 Feb 2022 16:53:12 +1000 +Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); + Thu, 24 Feb 2022 16:53:05 +1000 +Date: Thu, 24 Feb 2022 16:53:05 +1000 +From: Anthony Towns <aj@erisian.com.au> +To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <20220224065305.GB1965@erisian.com.au> +References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com> + <87leymuiu8.fsf@rustcorp.com.au> + <CAD5xwhgP2_51Dvar0f1tsMrCXZ61W9-HnLgR45D-54Oc7-X1ag@mail.gmail.com> + <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com> + <i710HUIxNHIqCNhkh07dzlShyDp9ZkoEokw9ZBezCFvsk05ZUy5fXK1xx_IQifLh4f3RYb8FJM_MFm7hAaQFaUM3Jy3E8QhfSzkaogAu1Gs=@protonmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <i710HUIxNHIqCNhkh07dzlShyDp9ZkoEokw9ZBezCFvsk05ZUy5fXK1xx_IQifLh4f3RYb8FJM_MFm7hAaQFaUM3Jy3E8QhfSzkaogAu1Gs=@protonmail.com> +User-Agent: Mutt/1.10.1 (2018-07-13) +X-Spam-Score-int: -18 +X-Spam-Bar: - +Subject: Re: [bitcoin-dev] Recursive covenant opposition, + or the absence thereof, + was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT +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, 24 Feb 2022 06:53:17 -0000 + +On Wed, Feb 23, 2022 at 11:28:36AM +0000, ZmnSCPxj via bitcoin-dev wrote: +> Subject: Turing-Completeness, And Its Enablement Of Drivechains + +> And we have already rejected Drivechains, + +That seems overly strong to me. + +> for the following reason: +> 1. Sidechain validators and mainchain miners have a strong incentive to +> merge their businesses. +> 2. Mainchain miners end up validating and commiting to sidechain blocks. +> 3. Ergo, sidechains on Drivechains become a block size increase. + +I think there are two possible claims about drivechains that would make +them unattractive, if true: + + 1) that adding a drivechain is a "block size increase" in the sense + that every full node and every miner need to do more work when + validating a block, in order to be sure whether the majority of hash + rate will consider it valid, or will reject it and refuse to build + on it because it's invalid because of some external drivechain rule + + 2) that funds deposited in drivechains will be stolen because + the majority of hashrate is not enforcing drivechain rules (or that + deposited funds cannot be withdrawn, but will instead be stuck in + the drivechain, rather than having a legitimate two-way peg) + +And you could combine those claims, saying that one or the other will +happen (depending on whether more or less than 50% of hashpower is +enforcing drivechain rules), and either is bad, even though you don't +know which will happen. + +I believe drivechain advocates argue a third outcome is possible where +neither of those claims hold true, where only a minority of hashrates +needs to validate the drivechain rules, but that is still sufficient +to prevent drivechain funds from being stolen. + +One way to "reject" drivechains is simply to embrace the second claim -- +that putting money into drivechains isn't safe, and that miners *should* +claim coins that have been drivehcain encumbered (or that miners +should not assist with withdrawing funds, leaving them trapped in the +drivechain). In some sense this is already the case: bip300 rules aren't +enforced, so funds committed today via bip300 can likely expect to be +stolen, and likely won't receive the correct acks, so won't progress +even if they aren't stolen. + + + +I think a key difference between tx-covenant based drivechains and bip300 +drivechains is hashpower endorsement: if 50% of hashpower acks enforcement +of a new drivechain (as required in bip300 for a new drivechain to exist +at all), there's an implicit threat that any block proposing an incorrect +withdrawal from that blockchain will have their block considered invalid +and get reorged out -- either directly by that hashpower majority, or +indirectly by users conducting a UASF forcing the hashpower majority to +reject those blocks. + +I think removing that implicit threat changes the game theory +substantially: rather than deposited funds being withdrawn due to the +drivechain rules, you'd instead expect them to be withdrawn according to +whoever's willing to offer the miners the most upfront fees to withdraw +the funds. + +That seems to me to mean you'd frequently expect to end up in a scorched +earth scenario, where someone attempts to steal, then they and the +legitimate owner gets into a bidding war, with the result that most +of the funds end up going to miners in fees. Because of the upfront +payment vs delayed collection of withdrawn funds, maybe it could end up +as a dollar auction, with the two parties competing to lose the least, +but still both losing substantial amounts? + +So I think covenant-based drivechains would be roughly the same as bip300 +drivechains, where a majority of hashpower used software implementing +the following rules: + + - always endorse any proposed drivechain + - always accept any payment into a drivechain + - accept bids to ack/nack withdrawals, then ack/nack depending on + whoever pays the most + +You could probably make covenant-based drivechains a closer match to +bip300 drivechains if a script could determine if an input was from a +(100-block prior) coinbase or not. + +> Logically, if the construct is general enough to form Drivechains, and +> we rejected Drivechains, we should also reject the general construct. + +Not providing X because it can only be used for E, may generalise to not +providing Y which can also only be used for E, but it doesn't necessarily +generalise to not providing Z which can be used for both G and E. + +I think it's pretty reasonable to say: + + a) adding dedicated consensus features for drivechains is a bad idea + in the absence of widespread consensus that drivechains are likely + to work as designed and be a benefit to bitcoin overall + + b) if you want to risk your own funds by leaving your coins on an + exchange or using lightning or eltoo or tumbling/coinjoin or payment + pools or drivechains or being #reckless in some other way, and aren't + asking for consensus changes, that's your business + +Cheers, +aj + + |