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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id A0ACDC077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 02:33:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 96666847AB
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 02:33:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id eYW5-ST1hMDU
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 02:33:30 +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 whitealder.osuosl.org (Postfix) with ESMTPS id 562AC83DC2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 02:33:30 +0000 (UTC)
Date: Mon, 13 Jan 2020 02:33:21 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1578882807;
bh=Pj+xVJqGZzG1Cur6S6Qg0eXFBFxzo5Xu+aR09yrM+Yc=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=UVy0gGRyfDOTTWhNkr8XzRlZZCYniq+F9FiE2r189XB4CnORx0KU/Z0X347/fDsYq
qluJlfQK4ihojAiCxag4Ihbw/9JYvMo1yDZb4SniaVXgACgqCWg+O6BTGTasqYgO/E
F5/B0vOXWsjCK4x5sobzdNXsKwvt4/xsF/m3ihtE=
To: Robin Linus <robinlinus@protonmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <P-QnOpNsFdehy_F3FJgAr0lSJ2xtmT5cwRsEC8VfnIUrSgfNDkLNizm2L1TG65AhKM430tzJ9p33WBnSmJ92ZTKEoaKXCTQzVKrZkH9vtn4=@protonmail.com>
In-Reply-To: <2mw_wd_ocLESpSG9ST3yJBsJriHf1l5LsdQ2jLamTUUKTMmwUpcjEeohClnMHJl4qjXNW9mHQJiK65jmDHfLG3-nVSRse9PdXnXokGZ2_ac=@protonmail.com>
References: <kAPCabG_c_AiGFYny48dO7ZT-MUgINLLoiKdzElSN8IrRej9szT3t9s0FvAHihraSo0CftPwFjU_pxvKuu9SziIJFt2JZxO3rdpS3-CMKzg=@protonmail.com>
<Qa9HJ5p2bYnXsjvgcTz-J_stEwJ80SU9UTZF5abv96i5eM_6y3pmy9Bu4tEnFXOc_lBs-y2BFoMh4xOGjl2US56hAFPvxDZM2eyhJkEdBLM=@protonmail.com>
<2mw_wd_ocLESpSG9ST3yJBsJriHf1l5LsdQ2jLamTUUKTMmwUpcjEeohClnMHJl4qjXNW9mHQJiK65jmDHfLG3-nVSRse9PdXnXokGZ2_ac=@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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 02:33:32 -0000
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 unre=
liable 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 tha=
n 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 lov=
e their usability. Install it and immediately I can send you $0.01. Yet, sc=
aling 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 in=
dependent sidechains. Decentralized Blockchains do scale decently up to a c=
ouple Million UTXOs. So a couple thousand Sidechains is probably sufficient=
for a global medium of exchange. Cross-chain communication without requiri=
ng cross-chain validation is possible via atomic swaps and through Bitcoin'=
s LN. That scales because it separates chain-validators from swap-validator=
s.
> Bitcoin's LN acts as the central settlement layer for efficient c=
ross-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. B=
ut sidechains can be trustless. Also a generic protocol provides flexibilit=
y for sidechain innovations with arbitrary digital assets and consensus rul=
es.
Which is why I brought up multiparticipant offchain updateable cryptocurren=
cy 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-O=
suntokun constructions.
You can even use the Somsen "statechain" mechanism, which rides a Decker-Wa=
ttenhofer/Decker-Russell-Osuntokun construction, though its trust-minimizat=
ion is only very very slightly better than federated sidechains.
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.
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 blockchai=
n, you can host a Poon-Dryja inside the Decker-Wattenhofer, since the Bitco=
in blockchain can host Poon-Dryja channels.
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?
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.
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
|
