Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-24 📝 Original message:On Wed, Feb 23, 2022 at ...

📅 Original date posted:2022-02-24
📝 Original message: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