From: Anthony Towns <aj@erisian•com.au>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
Date: Thu, 24 Feb 2022 16:53:05 +1000 [thread overview]
Message-ID: <20220224065305.GB1965@erisian.com.au> (raw)
In-Reply-To: <i710HUIxNHIqCNhkh07dzlShyDp9ZkoEokw9ZBezCFvsk05ZUy5fXK1xx_IQifLh4f3RYb8FJM_MFm7hAaQFaUM3Jy3E8QhfSzkaogAu1Gs=@protonmail.com>
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
next prev parent reply other threads:[~2022-02-24 6:53 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 17:20 [bitcoin-dev] " Russell O'Connor
2022-01-26 22:16 ` Jeremy
2022-01-27 4:20 ` James Lu
2022-01-27 19:16 ` Russell O'Connor
2022-01-28 0:18 ` James O'Beirne
2022-01-28 13:14 ` Michael Folkson
2022-01-28 14:17 ` Anthony Towns
2022-01-28 16:38 ` Jeremy
2022-01-28 14:13 ` Russell O'Connor
2022-01-28 15:14 ` James O'Beirne
2022-01-29 15:43 ` Russell O'Connor
2022-01-29 17:02 ` Jeremy Rubin
[not found] ` <CAD5xwhjHv2EGYb33p2MRS=VSz=ciGwAsiafX1yRHjxQEXfykSA@mail.gmail.com>
2022-01-29 17:14 ` Russell O'Connor
2022-01-31 2:18 ` Anthony Towns
2022-01-28 1:34 ` Anthony Towns
2022-01-28 13:56 ` Russell O'Connor
2022-02-01 1:16 ` Anthony Towns
2022-02-08 2:16 ` Russell O'Connor
2022-02-17 14:27 ` Anthony Towns
2022-02-17 14:50 ` Russell O'Connor
2022-02-08 3:40 ` Rusty Russell
2022-02-08 4:34 ` Jeremy Rubin
2022-02-11 0:55 ` [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " David A. Harding
2022-02-11 3:42 ` Jeremy Rubin
2022-02-11 17:42 ` James O'Beirne
2022-02-11 18:12 ` digital vagabond
2022-02-12 10:54 ` darosior
2022-02-12 15:59 ` Billy Tetrud
2022-02-17 15:15 ` Anthony Towns
2022-02-18 7:34 ` ZmnSCPxj
2022-02-23 11:28 ` ZmnSCPxj
2022-02-23 18:14 ` Paul Sztorc
2022-02-24 2:20 ` ZmnSCPxj
2022-02-24 6:53 ` Anthony Towns [this message]
2022-02-24 12:03 ` ZmnSCPxj
2022-02-26 5:38 ` Billy Tetrud
2022-02-26 6:43 ` ZmnSCPxj
2022-02-27 0:58 ` Paul Sztorc
2022-02-27 2:00 ` ZmnSCPxj
2022-02-27 7:25 ` ZmnSCPxj
2022-02-27 16:59 ` Billy Tetrud
2022-02-27 23:50 ` Paul Sztorc
2022-02-28 0:20 ` Paul Sztorc
2022-02-28 6:49 ` ZmnSCPxj
2022-02-28 7:55 ` vjudeu
2022-03-04 8:42 ` ZmnSCPxj
2022-03-04 13:43 ` vjudeu
2022-02-28 22:54 ` Paul Sztorc
2022-03-01 5:39 ` Billy Tetrud
2022-03-02 0:00 ` Paul Sztorc
2022-03-04 12:35 ` Billy Tetrud
2022-03-04 20:06 ` Paul Sztorc
2022-02-26 6:00 ` Anthony Towns
2022-02-15 8:45 ` [bitcoin-dev] " Rusty Russell
2022-02-15 18:57 ` Jeremy Rubin
2022-02-15 19:12 ` Russell O'Connor
2022-02-16 2:26 ` Rusty Russell
2022-02-16 4:10 ` Russell O'Connor
2022-02-14 2:40 [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " Lucky Star
2022-02-26 7:47 Prayank
2022-02-26 16:18 ` Billy Tetrud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220224065305.GB1965@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox