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
|
Return-Path: <joachimstr@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id A8425C077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 17:34:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 9F28783DA4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 17:34:25 +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 lYzXhGRNxzSo
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 17:34:23 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by whitealder.osuosl.org (Postfix) with ESMTPS id EFD38815EA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jan 2020 17:34:22 +0000 (UTC)
Date: Mon, 13 Jan 2020 17:34:17 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1578936860;
bh=DMcDEIqm3ndHgFIKrVF6KNOtl8CaYU4FkFAR/TNwVh4=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=wdjejkfduoGVPg559KnHIWoD646D/e5of5Dd3Kn5fc4sv/Wq77iUhcc9FyUPuXxbR
uw9g7HLfsSNXPCLx0M4UJW+fnqmD03Y1rCEmqaA1UI+zD96ruHh1B1eXe4a/JjI4DX
o03RAtRWGnrZvzzsZCVroykOx1ca2feGvfCa1PLA=
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= <joachimstr@protonmail.com>
Reply-To: =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= <joachimstr@protonmail.com>
Message-ID: <-8y3dnfO2vpyLPeOF5scfp0c5AZd9FF-_xkr1jL2iT1j02fSMJHix2YQupuOeBRF9v5icwGQbriKFXqd5B1AusZp0X7ENOvQ_q4OGCazueU=@protonmail.com>
In-Reply-To: <P-QnOpNsFdehy_F3FJgAr0lSJ2xtmT5cwRsEC8VfnIUrSgfNDkLNizm2L1TG65AhKM430tzJ9p33WBnSmJ92ZTKEoaKXCTQzVKrZkH9vtn4=@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>
<P-QnOpNsFdehy_F3FJgAr0lSJ2xtmT5cwRsEC8VfnIUrSgfNDkLNizm2L1TG65AhKM430tzJ9p33WBnSmJ92ZTKEoaKXCTQzVKrZkH9vtn4=@protonmail.com>
Feedback-ID: rtGq1wInl4cYyZOA2iZwaHP-4FBFY67Qt3DcVBMZh8YR1tV-3hijnv7SxpdDwGlNdSPgHEykKLn6PcHDKa0D8A==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 13 Jan 2020 17:40:51 +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: Mon, 13 Jan 2020 17:34:25 -0000
> Instead of using sidechains, just use channel factories.
I am not familiar enough with the latest advancements in this field. Is it =
possible using LN/channel factories to achieve off-line-like participation =
user experience without previous registration with any kind of gateway prov=
ider? For example, can you go online, join the network [somehow instantly],=
generate address/invoice and then put it somewhere for others to later use=
it when you are off-line? Can you also participate while being off-line fo=
r very long periods of time without relying on third party providers to sec=
ure your channels? If not, is using sidechains really equally replaceable w=
ith LN/CF constructions?
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Monday, January 13, 2020 2:33 AM, 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 g=
et 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 un=
reliable cell phone connections and do not have any BTC yet.
> > And the more popular Bitcoin becomes, the fewer people can affo=
rd LN channels. Even Eltoo requires your funds to be significantly higher t=
han Bitcoin's TX fees, right?
> > Already today, more and more services like tippin.me, BlueWalle=
t, etc, provide custodial solutions.
> > For small amounts, custody is an acceptable workaround. And I l=
ove 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 sufficie=
nt for a global medium of exchange. Cross-chain communication without requi=
ring cross-chain validation is possible via atomic swaps and through Bitcoi=
n's LN. That scales because it separates chain-validators from swap-validat=
ors.
> > 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 L=
N 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 flexibil=
ity for sidechain innovations with arbitrary digital assets and consensus r=
ules.
> >
>
> Which is why I brought up multiparticipant offchain updateable cryptocurr=
ency systems.
> The "channel factories" concepts does what you are looking for, except wi=
th 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-minimiz=
ation is only very very slightly better than federated sidechains.
>
> It is helpful to remember that Poon-Dryja, Decker-Wattenhofer, Decker-Rus=
sell-Osuntokun, and all other future such constructions, can host any contr=
act that its lower layer can support.
> So if you ride a Poon-Dryja on top of the Bitcoin blockchain, you can hos=
t HTLCs inside the Poon-Dryja, since the Bitcoin blockchain can host HTLCs.
> Similarly, if you ride a Decker-Wattenhofer on top of the Bitcoin blockch=
ain, you can host a Poon-Dryja inside the Decker-Wattenhofer, since the Bit=
coin blockchain can host Poon-Dryja channels.
> This central insight leads one to conclude that anything you can put onch=
ain, you an generally also put offchain, so why use a chain at all except a=
s an ultimate anchor to reality?
> Poon-Dryja is strictly two-participant, while Decker-Wattenhofer limits t=
he practical number of updates due to its use of decrementing relative time=
locks: 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 cr=
eate a layer that supports changes to the channel topology (where changes t=
o 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 service=
s, only their customers need to know those internal ledgers, and sign off o=
n the updates of those ledgers.
>
> Regards,
> ZmnSCPxj
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
