Date: Mon, 13 Jan 2020 00:21:42 +0000
To: Robin Linus <robinlinus@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Qa9HJ5p2bYnXsjvgcTz-J_stEwJ80SU9UTZF5abv96i5eM_6y3pmy9Bu4tEnFXOc_lBs-y2BFoMh4xOGjl2US56hAFPvxDZM2eyhJkEdBLM=@protonmail.com>
In-Reply-To: <kAPCabG_c_AiGFYny48dO7ZT-MUgINLLoiKdzElSN8IrRej9szT3t9s0FvAHihraSo0CftPwFjU_pxvKuu9SziIJFt2JZxO3rdpS3-CMKzg=@protonmail.com>
References: <kAPCabG_c_AiGFYny48dO7ZT-MUgINLLoiKdzElSN8IrRej9szT3t9s0FvAHihraSo0CftPwFjU_pxvKuu9SziIJFt2JZxO3rdpS3-CMKzg=@protonmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Coins: A trustless sidechain protocol
Precedence: list

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 every=
one interested in it to propagate all their transaction to everyone else in=
terested 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 Lightnin=
g Network.

Or, more blithely: Let me get this straight, you already know blockchains c=
annot scale, so your scaling proposal involves making ***more*** blockchain=
s?

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

---

You could implement the collateral contract with a simple `<one year> OP_CH=
ECKSEQUENCEVERIFY OP_DROP <A> OP_CHECKSIG`, with a single-sign signature us=
ed at the consensus layer for your sidechain.
`OP_CHECKSEQUENCEVERIFY` ensures, as a side effect, that the spending trans=
action 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, anyon=
e 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 t=
ime to try to get their version onchain.
Eventually, some "Bob" will just put the entire fund as fee and put a measl=
y `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 spend=
ing it after the collateral period ends, and Alice still cannot touch the f=
unds 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 no=
t 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 wi=
thout it you do not need a *single* *tr\*sted* Bob to implement the collate=
ral contract.

Regards,
ZmnSCPxj