Re: [bitcoin-dev] Coins: A trustless sidechain protocol

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Robin,

The reason why I stopped considering sidechains for scaling and have since moved to Lightning Network development was that, on reflection, I realized sidechains *still* do not scale, even with stakes anchored on the mainchain.
The issue is that sidechains, like any blockchain, still require that everyone interested in it to propagate all their transaction to everyone else interested in it.
Contrast this with Lightning Network, where you select only a tiny handful of nodes to inform about your payment, even if you have a gigantic Lightning Network.

Or, more blithely: Let me get this straight, you already know blockchains cannot scale, so your scaling proposal involves making ***more*** blockchains?

You might point to the use of large numbers of sidechains with limited userbase, and the use of cross-chain atomic swaps to convert between sidecoins.
I would then point out that Lightning Network channel are cryptocurrency systems with two users (with significantly better security than a 2-user sidechain would have), and that Lightning Network payment routing is just the use of cross-channel atomic swaps to convert between channelcoins.
Indeed, with a multiparticipant offchain updateable cryptocurrency system mechanism, like Decker-Wattenhofer or Decker-Russell-Osuntokun ("eltoo"), you could entirely replace sidechains with a mechanism that does not give custody to your funds to anyone else, since you can always insist on using n-of-n signing with you included in the signer set to prevent state changes that do not have your approval.

---

You could implement the collateral contract with a simple `<one year> OP_CHECKSEQUENCEVERIFY OP_DROP <A> OP_CHECKSIG`, with a single-sign signature used at the consensus layer for your sidechain.
`OP_CHECKSEQUENCEVERIFY` ensures, as a side effect, that the spending transaction opts in to RBF.
Thus, if the pubkey `<A>` is used in a single-sign signature scheme (which reveals the privkey if double-signed), then at the end of the period, anyone who saw the double-signing can claim that fund and thus act as "Bob".
Indeed, many "Bob"s will act and claim this fund, increasing the fee each time to try to get their version onchain.
Eventually, some "Bob" will just put the entire fund as fee and put a measly `OP_RETURN` as single output.
This "burns" the funds by donating it to miners.

From the point of view of Alice this is hardly distinguishable from losing the fund right now, since Alice will have a vanishingly low chance of spending it after the collateral period ends, and Alice still cannot touch the funds now anyway.
Alice also cannot plausibly bribe a miner, since the miner could always get more funds by replacing the transaction internally with a spend-everything-on-fees `OP_RETURN` output transaction, and can only persuade the miner not to engage in this behavior by offering more than the collateral is worth (which is always worse than just losing the collateral).

A `OP_CHECKTEMPLATEVERIFY` would work better for this use-case, but even without it you do not need a *single* *tr\*sted* Bob to implement the collateral contract.

Regards,
ZmnSCPxj