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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 72E551045
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Apr 2019 05:33:50 +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 smtp1.linuxfoundation.org (Postfix) with ESMTPS id 30958466
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Apr 2019 05:33:49 +0000 (UTC)
Date: Thu, 18 Apr 2019 05:33:42 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1555565626;
bh=okBidcCJ37mrTiFBoU3OSH1Uhpf3zJhciNV5BE4woA0=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=FsnS28lP3LWMKpeyGV8oBTbRNpHTsEZkwuJ7ceIGvxYW3IHFf7wFrRGStdI+ZZjM3
8akGad2sFY6ae09LUX4ZU0IfaXDscvv4adJn/zuQdaHv78vQiYx8oGPY1xc5UL9N+p
prllc3DCRzGxOdir4ODwu9lgN43fBjJM5iPk3+u4=
To: Nadav Kohen <nadav@suredbits.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <BuPb9X2Va172-mEpWEgdK8rcUEvLKJ4Y_804yfwJLULSa7tkTvpDyZ9GWJD0Q84AtdkzePOU-bTtRjdi5f-tbuJM4src6zaNIy9XM1tGeoQ=@protonmail.com>
In-Reply-To: <CALGTLwPjH8x_6gqRoXnkWKu8ZcJSgWBFV0vWss60MTi4E1MdHQ@mail.gmail.com>
References: <IAFPSZAn6TYt348fmmnPznQ_ApG7pa48eMjzTgrjuVAt6fS1tNieRxlcIXyTATy2vjZCUn4wVQcsyDlyb_3Ip46BstFRikB95-lKewAZBEE=@protonmail.com>
<CALGTLwPjH8x_6gqRoXnkWKu8ZcJSgWBFV0vWss60MTi4E1MdHQ@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW, URI_NOVOWEL autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 18 Apr 2019 13:40:07 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Smart Contracts Unchained
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 18 Apr 2019 05:33:50 -0000
Good morning Nadav,
Yes, transporting contracts over a single direct channel is always possible=
.
When Lightning switches to Decker-Russell-Osuntokun ("eltoo"), do note that=
contracts with an absolute timelock must be forced onchain earlier than th=
e absolute timelock by the CSV requirement of the channel (unilateral close=
time).
With current Poon-Dryja channels, transported contracts must be augmented b=
y a 2-of-2 on all branches, which can be done by adding a 2-of-2 multisig o=
n the escrow branch, using temporary keys.
The purpose of the 2-of-2 is to enforce that the only valid claims to the c=
ontract have an `nSequence` representing the unilateral close time of the c=
hannel.
xref. HTLC-timeout and HTLC-success transactions in BOLT#3.
Transporting over multiple hops requires that compliance to a contract make=
s one side reveal information that the other side does not know, together w=
ith some kind of timeout/backoff.
Practically speaking, only HTLC-type contracts can be transported.
For example, DLCs will have many possible branches where the Oracle provide=
s a signature for one branch, and this signature is what is learned by the =
other party in the contract.
In addition, DLCs for practical use require a timeout (in case the Oracle f=
ails to reveal the signature on the appointed time).
Thus, far fewer contracts can be transported over the network.
(Of note is that a Lightning channel is itself a contract (that is transpor=
table only within a direct channel); this is the basis of channel factories=
, where the factory level is effectively a "channel" with more than two par=
ticipants, and transporting Lightning channels instead of HTLCs)
(You may be interested in looking at the "Fulgurite" effort)
OF note is that DLCs have an Oracle.
I observe that escrow services (which are specializations of the Smart Cont=
racts Unchained technique) are basically oracles also.
If DLCs can transport their oracle signatures over multiple hops, then it s=
hould be possible for Smart Contracts Unchained to transport the federation=
/escrow signatures over multiple hops also.
I do not know the math behind DLCs enough to be certain, however, and leave=
it to better mathematicians than I.
Regards,
ZmnSCPxj
Regards,
ZmnSCPxj
=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 Thursday, April 18, 2019 12:17 AM, Nadav Kohen <nadav@suredbits.com> wro=
te:
> Hi all!
>
> I've been thinking a lot about how to add the benefits that lightning pro=
vides in terms of privacy and speed to the smart contracts unchained setup.=
The high-level idea is to utilize the fact that a lightning channel alread=
y has on-chain funds locked up, and if parties cooperate, some of these fun=
ds can be moved into the 2/3 MultiSig output needed for the escrow scheme b=
y cooperating off-chain (and then moved back to their channel balances off-=
chain as well). The following is an admittedly pretty rough outline of how =
this might be accomplished.
>
> A - B : Smart Contracts in a Lightning Channel
>
> 1) Parties both commit to a 2/3 MultiSig output on their next commitment =
transaction
> 2) Parties then both revoke_and_ack
> 3) When the contract yields a result, the to_local and to_remote balances=
can be updated and the 2/3 MultiSig output can be removed
> 4) If either party is uncooperative, their counter-party can force close =
the channel and funds can be resolved on-chain using the escrow
>
> If either party does not revoke_and_ack well before any potential for the=
m to discover if they have an advantage in the contract (or after some smal=
l but reasonable time), their counter-party should go on chain with the com=
mitment transaction containing the 2/3 MultiSig
>
> A - B - C : Single Hop Smart Contracts (Useful if someone, B in this case=
, wants to provide a hub that matches users wanting to enter smart contract=
s)
>
> 1) A irrevocably commits to a 2/3 MultiSig output on their commitment tra=
nsaction with B (which B also commits to but does not yet revoke their old =
state)
> 2) C irrevocably commits to the same 2/3 MultiSig output on their commitm=
ent transaction with B (which B also commits to)
> 3) B irrevocably commits to both outputs
> 4) When the contract yields a result, say A should win some money from C,=
then A can ask B to remove that output (and update balances) by revealing =
to B how to claim funds from C
> 5) B can then ask C to remove the output and add to B's balance
>
> If B does not revoke_and_ack on either channel, then the affected counter=
-party should close the channel and go on chain with the 2/3 MultiSig trans=
action
> If B refuses to remove the output, A can claim their funds on-chain where=
B can learn how to claim funds from C
> If C refuses to remove the output, B can claim their funds on-chain using=
the information revealed by A
>
> Problems: How do we ensure that only B can claim the 2/3 MultiSig from C,=
and not anyone who sees A's on-chain spend of their 2/3 MultiSig? I'm pret=
ty sure this is possible to do but I don't know Script well enough
>
> A - B - C - D : Fully Routed Smart Contracts
>
> 1) Given the n possible outcomes in which A gets money from the contract =
between A and D, a_1 < a_2 < ... < a_n, and the m possible outcomes in whic=
h D gets money, d_1 < d_2 < ... < d_m, D must send n HTLCs to A with the am=
ounts a_1, a_2 - a_1, a_3 - a_2, ..., a_n - a_(n-1) and A must send m HTLCs=
to D with amounts d_1, d_2 - d_1, d_3 - d_2, ..., d_m - d_(m-1)
> 2) These HTLCs must be special and have two hashes, where either preimage=
unlocks the funds
> 3) In the payments from A to D, A knows one preimage and the smart contra=
cting platform knows the other (and similarly for D to A)
> 4) Should a_i be the outcome of the contract, D should tell A what the pr=
eimages are to payments 1 through i
> 5) D should fail all m payments
> 6) A should fail all payments i+1 through n
> (It is possible and in fact likely that there can be ways to use fewer tr=
ansactions and thus less collateral than this, perhaps by using subtraction=
and not just addition as in a_i - d_j, what I've presented is simply a low=
er bound that works in all cases)
>
> If D does not reveal their preimages, A can get the relevant preimages fr=
om the smart contracting platform
>
> Problems: The smart contracting platform is given more information about =
the contract in the happy path in this scheme. Also, all routers need to su=
pport special double-hash HTLCs
>
> An alternative way to possibly do multi-hop routing that would require le=
ss be told to the escrow service, is to have each routing node add an outpu=
t on either side where it takes one position in one channel and the other p=
osition in the other channel (essentially allowing them to break event when=
the contract is completed). This has the same problems as the Single Hop c=
ase as well as the additional problem (that I couldn't imagine a solution f=
or) of making the commitments to the 2/3 MultiSig output on commitment tran=
sactions atomic; in the single hop case incentives seem to work out but I d=
on't know how "failed routing" would be detected or handled in the multi-ho=
p case.
>
> Feedback welcome!
>
> Best,
> Nadav
>
> On Wed, Apr 3, 2019 at 9:14 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
>
> > https://zmnscpxj.github.io/bitcoin/unchained.html
> >
> > Smart contracts have traditionally been implemented as part of the cons=
ensus rules of some blokchain.=C2=A0 Often this means creating a new blockc=
hain, or at least a sidechain to an existing blockchain.=C2=A0 This writeup=
proposes an alternative method without launching a separate blockchain or =
sidechain, while achieving security similar to federated sidechains and add=
itional benefits to privacy and smart-contract-patching.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
