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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
