From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Robin Linus <robinlinus@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Coins: A trustless sidechain protocol
Date: Mon, 13 Jan 2020 00:21:42 +0000 [thread overview]
Message-ID: <Qa9HJ5p2bYnXsjvgcTz-J_stEwJ80SU9UTZF5abv96i5eM_6y3pmy9Bu4tEnFXOc_lBs-y2BFoMh4xOGjl2US56hAFPvxDZM2eyhJkEdBLM=@protonmail.com> (raw)
In-Reply-To: <kAPCabG_c_AiGFYny48dO7ZT-MUgINLLoiKdzElSN8IrRej9szT3t9s0FvAHihraSo0CftPwFjU_pxvKuu9SziIJFt2JZxO3rdpS3-CMKzg=@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
next prev parent reply other threads:[~2020-01-13 0:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-12 18:54 Robin Linus
2020-01-13 0:21 ` ZmnSCPxj [this message]
2020-01-13 2:02 ` Robin Linus
2020-01-13 2:33 ` ZmnSCPxj
2020-01-13 17:34 ` Joachim Strömbergson
2020-01-13 22:05 ` Jeremy
2020-01-16 1:21 ` Angel Leon
2020-01-13 18:06 ` Joachim Strömbergson
2020-01-13 19:47 ` Robin Linus
2020-01-13 20:49 ` Joachim Strömbergson
2020-01-13 22:22 ` Robin Linus
2020-01-14 0:53 ` ZmnSCPxj
2020-01-14 2:19 ` Robin Linus
2020-01-14 2:59 ` ZmnSCPxj
2020-01-14 4:12 ` Robin Linus
2020-01-14 15:06 ` Joachim Strömbergson
2020-01-14 15:26 ` ZmnSCPxj
2020-01-15 1:43 ` Robin Linus
2020-01-15 5:46 ` ZmnSCPxj
2020-01-17 4:17 ` Robin Linus
2020-01-17 13:54 ` ZmnSCPxj
2020-01-18 8:21 ` Robin Linus
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='Qa9HJ5p2bYnXsjvgcTz-J_stEwJ80SU9UTZF5abv96i5eM_6y3pmy9Bu4tEnFXOc_lBs-y2BFoMh4xOGjl2US56hAFPvxDZM2eyhJkEdBLM=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=robinlinus@protonmail$(echo .)com \
/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