1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id D9D69C077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 00:21:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id CFA3A8526D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 00:21:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fKq8awGeubkR
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 00:21:50 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
by fraxinus.osuosl.org (Postfix) with ESMTPS id F006B85264
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 00:21:49 +0000 (UTC)
Date: Mon, 13 Jan 2020 00:21:42 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1578874907;
bh=zR5HA4uPXMxQtoCfAS1nvn+MktxOECgMRy2iQvONuXw=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=E0uPD60AKjHXBtDshKre23IR5ELZhdHuUFeBAzZg/vlcxlKGNGKyDSmrFK5EN2xmi
/5uUHJzDgIIn3/Lh6ak7B5sYlnksWw/oAzb1hqLNG5g9DPzCti1mniRXxf3H7+y8Jd
RDsJIu3Vb3j0GuCfAvbX+FDZvhSQsSc8hcHvVKoA=
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jan 2020 00:21:52 -0000
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
|
