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
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
|
Return-Path: <gubatron@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7AD8BC077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jan 2020 01:22:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 666BF85A37
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jan 2020 01:22:07 +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 xZR7vAxTB68v
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jan 2020 01:22:04 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f42.google.com (mail-io1-f42.google.com
[209.85.166.42])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 8678884B6F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jan 2020 01:22:04 +0000 (UTC)
Received: by mail-io1-f42.google.com with SMTP id k24so19934210ioc.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jan 2020 17:22:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=Tmt/rH2VOVk8lzz3FL1n/HbgtF6EANDwF4P2I9DL8q0=;
b=ACG46r4vlAi0S9gMqEc4NjvrJnWbh+FgMBdC6h9aT60IzU4flZPuW0kkUsfCc7RUK+
Cr1ObZVfsio67uCjLsCFTx///lKJ6KtIpFTukzbFYlxAboSweiFWC4n4eURZYJn5nJgc
96cXQPuoaUvsTbKQRB29OwhhHRFu0LvVwCb5JHkYBJEpzYHKm2WNEQNwGtooXPAc9IfZ
JQm++irz4QJKRDowVxARsY6v9LA9ze4Ad0LmnpASVFdGxuWEllHjaFTbVAjH44mw5y1L
LH0Ef7kReWdobng1CWyUpIfe12AgznEBc1gxjC/ubphGy83mnyvCNi8nvUZhlldPGKrT
cLqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=Tmt/rH2VOVk8lzz3FL1n/HbgtF6EANDwF4P2I9DL8q0=;
b=DSxCNfSy5qvwTsT5DvUOx+EoYgKmdJSItf0YXwT1AEIENjRH6Cy9LxCGQemXHftOxZ
g68lybDGm5Z+UGNn/wLfDtnbN670VbxKoPYAsD0tU63htoGr/mDGMJ9W9YwbMllKKe6S
z9+QoByqAwl46HHoJQBYTBTRDiwAurcS77EXiqjF4Vk8x7tDjb/pyKWjVvofse6I6eIk
USTK+ckxTnjmqNp+es4+ZmwNg1Hs3hrQJnHdzXUVdKCFGquK2PzuNNA/A9T/HzIwzjIB
Z6k+k3P2uFb/JRZYcRtxcOUmzTJxazAL76OTG/bbD+VA94JETnGrEZOvf23TNsWCU6pk
UAVQ==
X-Gm-Message-State: APjAAAVrh+lsYS9E3zWdFM0Ll87DT3U2R6kTYm4GAgcS8/qHaN/aOOfJ
dDtvnBw51g5aez9yy8EjRxAIlrNQ/ZzQ0ygDXr0=
X-Google-Smtp-Source: APXvYqyBEw7urItEV6Aqm63WktFVTykk70CC8+9ckrOsKH8v9nUqBb0VtKRXvQ0oOqvg9O+fHoPa2nuRrW2VynA2eXw=
X-Received: by 2002:a6b:1443:: with SMTP id 64mr23235635iou.116.1579137723691;
Wed, 15 Jan 2020 17:22:03 -0800 (PST)
MIME-Version: 1.0
References: <kAPCabG_c_AiGFYny48dO7ZT-MUgINLLoiKdzElSN8IrRej9szT3t9s0FvAHihraSo0CftPwFjU_pxvKuu9SziIJFt2JZxO3rdpS3-CMKzg=@protonmail.com>
<Qa9HJ5p2bYnXsjvgcTz-J_stEwJ80SU9UTZF5abv96i5eM_6y3pmy9Bu4tEnFXOc_lBs-y2BFoMh4xOGjl2US56hAFPvxDZM2eyhJkEdBLM=@protonmail.com>
<2mw_wd_ocLESpSG9ST3yJBsJriHf1l5LsdQ2jLamTUUKTMmwUpcjEeohClnMHJl4qjXNW9mHQJiK65jmDHfLG3-nVSRse9PdXnXokGZ2_ac=@protonmail.com>
<P-QnOpNsFdehy_F3FJgAr0lSJ2xtmT5cwRsEC8VfnIUrSgfNDkLNizm2L1TG65AhKM430tzJ9p33WBnSmJ92ZTKEoaKXCTQzVKrZkH9vtn4=@protonmail.com>
In-Reply-To: <P-QnOpNsFdehy_F3FJgAr0lSJ2xtmT5cwRsEC8VfnIUrSgfNDkLNizm2L1TG65AhKM430tzJ9p33WBnSmJ92ZTKEoaKXCTQzVKrZkH9vtn4=@protonmail.com>
From: Angel Leon <gubatron@gmail.com>
Date: Wed, 15 Jan 2020 18:21:52 -0700
Message-ID: <CADZB0_ZcJawjSBBE9nHLcFrHoZofDt-8pw4Xx980zp8OCjN6CA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000127a31059c37a79c"
X-Mailman-Approved-At: Thu, 16 Jan 2020 01:28:23 +0000
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: Thu, 16 Jan 2020 01:22:07 -0000
--000000000000127a31059c37a79c
Content-Type: text/plain; charset="UTF-8"
> Instead of using sidechains, just use channel factories.
> You do not need to broadcast the entire internal ledgers of those
services, only their customers need to know those internal ledgers, and
sign off on the updates of those ledgers.
That's right, all you need to broadcast is a small proof, a non-interactive
blockchain suffix proof
https://eprint.iacr.org/2017/963.pdf
On Sun, Jan 12, 2020 at 7:33 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good morning Robin,
>
>
> > Good morning ZmnSCPxj,
> >
> > Thank you for your detailed feedback! Two topics:
> >
> > Lightning vs Sidechains
> >
> > ------------------------
> >
> > Why an either-or-solution, if we can connect sidechains via the LN to
> get the best of both worlds?
> >
> > The LN works exceptionally great under the following conditions:
> >
> > - you're always online
> > - you have BTC to manage your channels' inbound-capacity
> > - you can afford BTC transactions
> > - in your channel is much more than the minimum on-chain TX fees
> >
> > The next Billion users do not fit that category. They are on
> unreliable cell phone connections and do not have any BTC yet.
> > And the more popular Bitcoin becomes, the fewer people can
> afford LN channels. Even Eltoo requires your funds to be significantly
> higher than Bitcoin's TX fees, right?
> >
> > Already today, more and more services like tippin.me,
> BlueWallet, etc, provide custodial solutions.
> > For small amounts, custody is an acceptable workaround. And I
> love their usability. Install it and immediately I can send you $0.01. Yet,
> scaling their approach globally does not lead to desirable outcomes, since
> we'd be back to trusting banks with their Excel sheets.
> >
> > So let's make their internal ledgers public and trustless, via
> independent sidechains. Decentralized Blockchains do scale decently up to a
> couple Million UTXOs. So a couple thousand Sidechains is probably
> sufficient for a global medium of exchange. Cross-chain communication
> without requiring cross-chain validation is possible via atomic swaps and
> through Bitcoin's LN. That scales because it separates chain-validators
> from swap-validators.
> > Bitcoin's LN acts as the central settlement layer for efficient
> cross-chain transactions between all sidechains.
> >
> > So Endusers "living" in sidechains instead of directly in the LN
> has many advantages:
> >
> > - no bitcoin blockspace required for on-boarding new users
> > - no need to lock funds to provide inbound-capacity
> > - no need to stay online or pay watch towers
> > - no need to store channel histories
> > - account balances can be much smaller than BTC TX fees
> >
> > Those are the exact same reasons why BlueWallet built their LndHub.
> But sidechains can be trustless. Also a generic protocol provides
> flexibility for sidechain innovations with arbitrary digital assets and
> consensus rules.
>
>
> Which is why I brought up multiparticipant offchain updateable
> cryptocurrency systems.
> The "channel factories" concepts does what you are looking for, except
> with better trust-minimization than sidechains can achieve.
> Just replace "sidechain" with either Decker-Wattenhofer or
> Decker-Russell-Osuntokun constructions.
> You can even use the Somsen "statechain" mechanism, which rides a
> Decker-Wattenhofer/Decker-Russell-Osuntokun construction, though its
> trust-minimization is only very very slightly better than federated
> sidechains.
>
> It is helpful to remember that Poon-Dryja, Decker-Wattenhofer,
> Decker-Russell-Osuntokun, and all other future such constructions, can host
> any contract that its lower layer can support.
> So if you ride a Poon-Dryja on top of the Bitcoin blockchain, you can host
> HTLCs inside the Poon-Dryja, since the Bitcoin blockchain can host HTLCs.
> Similarly, if you ride a Decker-Wattenhofer on top of the Bitcoin
> blockchain, you can host a Poon-Dryja inside the Decker-Wattenhofer, since
> the Bitcoin blockchain can host Poon-Dryja channels.
> This central insight leads one to conclude that anything you can put
> onchain, you an generally also put offchain, so why use a chain at all
> except as an ultimate anchor to reality?
> Poon-Dryja is strictly two-participant, while Decker-Wattenhofer limits
> the practical number of updates due to its use of decrementing relative
> timelocks: so you put the payment layer in a bunch of Poon-Dryja channels
> which support tons of updates each but only two participants per channel,
> and create a layer that supports changes to the channel topology (where
> changes to the channel connectivity are expected to be much rarer than
> payments) and is multiparticipant so you can *actually* scale.
>
> Instead of using sidechains, just use channel factories.
> You do not need to broadcast the entire internal ledgers of those
> services, only their customers need to know those internal ledgers, and
> sign off on the updates of those ledgers.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000127a31059c37a79c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> Instead of using sidechains, just use channel factori=
es.<br>
> You do not need to broadcast the entire internal ledgers of those=20
services, only their customers need to know those internal ledgers, and=20
sign off on the updates of those ledgers.<div><div dir=3D"ltr" class=3D"gma=
il_signature" data-smartmail=3D"gmail_signature"><br></div><div class=3D"gm=
ail_signature" data-smartmail=3D"gmail_signature">That's right, all you=
need to broadcast is a small proof, a non-interactive blockchain suffix pr=
oof<br><a href=3D"https://eprint.iacr.org/2017/963.pdf">https://eprint.iacr=
.org/2017/963.pdf</a><br><br></div></div><br></div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jan 12, 2020 at 7:33 P=
M ZmnSCPxj via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Robin,<br>
<br>
<br>
> Good morning ZmnSCPxj,<br>
><br>
> Thank you for your detailed feedback! Two topics:<br>
><br>
> Lightning vs Sidechains<br>
><br>
> ------------------------<br>
><br>
> Why an either-or-solution, if we can connect sidechains via the LN to =
get the best of both worlds?<br>
><br>
> The LN works exceptionally great under the following conditions:<br>
><br>
> -=C2=A0 =C2=A0you're always online<br>
> -=C2=A0 =C2=A0you have BTC to manage your channels' inbound-capaci=
ty<br>
> -=C2=A0 =C2=A0you can afford BTC transactions<br>
>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0in your channel is much more than the=
minimum on-chain TX fees<br>
><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The next Billion users do not fit tha=
t category. They are on unreliable cell phone connections and do not have a=
ny BTC yet.<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0And the more popular Bitcoin becomes,=
the fewer people can afford LN channels. Even Eltoo requires your funds to=
be significantly higher than Bitcoin's TX fees, right?<br>
><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Already today, more and more services=
like <a href=3D"http://tippin.me" rel=3D"noreferrer" target=3D"_blank">tip=
pin.me</a>, BlueWallet, etc, provide custodial solutions.<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For small amounts, custody is an acce=
ptable workaround. And I love their usability. Install it and immediately I=
can send you $0.01. Yet, scaling their approach globally does not lead to =
desirable outcomes, since we'd be back to trusting banks with their Exc=
el sheets.<br>
><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So let's make their internal ledg=
ers public and trustless, via independent sidechains. Decentralized Blockch=
ains do scale decently up to a couple Million UTXOs. So a couple thousand S=
idechains is probably sufficient for a global medium of exchange. Cross-cha=
in communication without requiring cross-chain validation is possible via a=
tomic swaps and through Bitcoin's LN. That scales because it separates =
chain-validators from swap-validators.<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bitcoin's LN acts as the central =
settlement layer for efficient cross-chain transactions between all sidecha=
ins.<br>
><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So Endusers "living" in sid=
echains instead of directly in the LN has many advantages:<br>
><br>
> -=C2=A0 =C2=A0no bitcoin blockspace required for on-boarding new users=
<br>
> -=C2=A0 =C2=A0no need to lock funds to provide inbound-capacity<br>
> -=C2=A0 =C2=A0no need to stay online or pay watch towers<br>
> -=C2=A0 =C2=A0no need to store channel histories<br>
> -=C2=A0 =C2=A0account balances can be much smaller than BTC TX fees<br=
>
><br>
>=C2=A0 =C2=A0 =C2=A0Those are the exact same reasons why BlueWallet bui=
lt their LndHub. But sidechains can be trustless. Also a generic protocol p=
rovides flexibility for sidechain innovations with arbitrary digital assets=
and consensus rules.<br>
<br>
<br>
Which is why I brought up multiparticipant offchain updateable cryptocurren=
cy systems.<br>
The "channel factories" concepts does what you are looking for, e=
xcept with better trust-minimization than sidechains can achieve.<br>
Just replace "sidechain" with either Decker-Wattenhofer or Decker=
-Russell-Osuntokun constructions.<br>
You can even use the Somsen "statechain" mechanism, which rides a=
Decker-Wattenhofer/Decker-Russell-Osuntokun construction, though its trust=
-minimization is only very very slightly better than federated sidechains.<=
br>
<br>
It is helpful to remember that Poon-Dryja, Decker-Wattenhofer, Decker-Russe=
ll-Osuntokun, and all other future such constructions, can host any contrac=
t that its lower layer can support.<br>
So if you ride a Poon-Dryja on top of the Bitcoin blockchain, you can host =
HTLCs inside the Poon-Dryja, since the Bitcoin blockchain can host HTLCs.<b=
r>
Similarly, if you ride a Decker-Wattenhofer on top of the Bitcoin blockchai=
n, you can host a Poon-Dryja inside the Decker-Wattenhofer, since the Bitco=
in blockchain can host Poon-Dryja channels.<br>
This central insight leads one to conclude that anything you can put onchai=
n, you an generally also put offchain, so why use a chain at all except as =
an ultimate anchor to reality?<br>
Poon-Dryja is strictly two-participant, while Decker-Wattenhofer limits the=
practical number of updates due to its use of decrementing relative timelo=
cks: so you put the payment layer in a bunch of Poon-Dryja channels which s=
upport tons of updates each but only two participants per channel, and crea=
te a layer that supports changes to the channel topology (where changes to =
the channel connectivity are expected to be much rarer than payments) and i=
s multiparticipant so you can *actually* scale.<br>
<br>
Instead of using sidechains, just use channel factories.<br>
You do not need to broadcast the entire internal ledgers of those services,=
only their customers need to know those internal ledgers, and sign off on =
the updates of those ledgers.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000127a31059c37a79c--
|