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
|
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 9C80B3EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 19 Sep 2019 07:52:22 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6281A76D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 19 Sep 2019 07:52:21 +0000 (UTC)
Date: Thu, 19 Sep 2019 07:52:11 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1568879535;
bh=WNvRejzvMv0uxJOlNPsOA60GvjbGcHeNPUE8PyPWZcY=;
h=Date:To:From:Reply-To:Subject:Feedback-ID:From;
b=OE8dTaHHIjdN26OXd8y4FEDXj7kEzrXdEFejJTI6MYFe71AhYELJ/fJL+ycUV8Djv
zYpzKdQt12k37bg/5j+Fsn/p4rFOZFyPbuer+aErXh+5/FgPxOOWixjmk4NkyRyZ8P
RtQ8d6OsFpDEilpNO4jdqqvR48z3n4pm9wR+A7yM=
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <7e7SBK5tLdpzTkgh-sNrAZR7qnPfu_i0tHY5ia4pk3Mjdw3dSZx3kcKiIMC9Hmu_lp8Y3mBFqlqsA_iHobJo58MSiW8NW1zKHUQKOWuuw4c=@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
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Timelocks and Lightning on MimbleWimble
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, 19 Sep 2019 07:52:22 -0000
Good morning list,
I was reading transcript of recent talk: https://diyhpl.us/wiki/transcripts=
/scalingbitcoin/tel-aviv-2019/edgedevplusplus/blockchain-design-patterns/
And in section "Taproot: main idea":
> Q: Can you do timelocks iwth adaptor signatures?
>
> ...
>
> A: This is one way it's being proposed by mimblewimble; but this requires=
the ability to aggregate signatures across transactions.
>
> Q: No, there's two transactions already existing. Before locktime, you ca=
n spend wit hthe adaptor signature one like atomic swaps. After locktime, t=
he other one becomes valid and you can spend with that. They just double sp=
end each other.
>
> A: You'd have to diagram that out for me. There's a few ways to do this, =
some that I know, but yours isn't one of them.
I believe what is being referred to here is to simply have an `nLockTime` t=
ransaction that is signed by all participants first, and serves as the "tim=
elock" path.
Then, another transaction is created, for which adaptor signatures are give=
n, before completing the ritual to create a "hashlock" path.
I find it surprising that this is not well-known.
I describe it here tangentially, for instance: https://lists.linuxfoundatio=
n.org/pipermail/bitcoin-dev/2019-April/016888.html
The section "Payjoin2swap Swap Protocol" refers to "pre-swap transaction" a=
nd "pre-swap backout transaction", which are `nLockTime`d transactions.
Later transactions then use a Scriptless Script-like construction to transf=
er information about a secret scalar x.
My understanding of MimbleWimble is that:
* There must exist a proof-of-knowledge of the sum of blinding factors used=
.
This can be trivially had by using a signature of this sum, signing an em=
pty message or "kernel".
* I believe I have seen at least one proposal (I cannot find it again now) =
where the "kernel" is replaced with an `nLockTime`-equivalent.
Basically, the `nLockTime` would have to be explicitly published, and it =
would be rejected for a block if the `nLockTime` was less than the block he=
ight.
* There may or may not exist some kind of proof where the message being s=
igned is an integer that is known to be no greater than a particular value,=
and multiple signatures that signed a lower value can somehow be aggregate=
d to a higher value, which serves this purpose as well, but is compressible=
.
My understanding is thus that the above `nLockTime` technique is what is in=
deed intended for MimbleWimble cross-system atomic swaps.
--------
However, I believe that Lightning and similar offchain protocols are **not =
possible** on MimbleWimble, at least if we want to retain its "magical shri=
nking blockchain" property.
All practical channel constructions with indefinite lifetime require the us=
e of *relative* locktime.
Of note is that `nLockTime` represents an *absolute* lifetime.
The only practical channel constructions I know of that do not require *rel=
ative* locktime (mostly various variants of Spilman channels) have a fixed =
lifetime, i.e. the channel will have to be closed before the lifetime arriv=
es.
This is impractical for a scaling network.
It seems to me that some kind of "timeout" is always necessary, similar to =
the timeout used in SPV-proof sidechains, in order to allow an existing cla=
imed-latest-state to be proven as not-actually-latest.
* In Poon-Dryja, knowledge of the revocation key by the other side proves t=
he published claimed-latest-state is not-actually-latest and awards the ent=
ire amount to the other party.
* This key can only be presented during the timeout, a security parameter=
.
* In Decker-Wattenhofer decrementing-`nSequence` channels, a kickoff starts=
this timeout, and only the smallest-timeout state gets onchain, due to it =
having a time advantage over all other versions.
* In indefinite-lifetime Spilman channels (also described in the Decker-Wat=
tenhofer paper), the absolute-timelock initial backoff transaction is repla=
ced with a kickoff + relative-locktime transaction.
* In Decker-Russell-Osuntokun, each update transaction has an imposed `nSeq=
uence` that forces a state transaction to be delayed compared to the update=
transaction it is paired with.
It seems that all practical offchain updateable cryptocurrency systems, som=
e kind of "timeout" is needed during which participants have an opportunity=
to claim an alternative version of some previous claim of correct state.
This timeout could be implemented as either relative or absolute lock time,=
but obviously an absolute locktime would create a limit on the lifetime of=
the channel.
Thus, if we were to target an indefinite-lifetime channel, we must use rela=
tive lock times, with the timeout starting only when the unilateral close i=
s initiated by one participant.
Now, let us turn back to the MimbleWimble.
As it happens, we do *not* actually need SCRIPT to implement these offchain=
updateable cryptocurrency systems.
2-of-2 is often enough (and with Schnorr and other homomorphic signatures, =
this is possible without explicit script, only pubkeys and signatures, whic=
h MimbleWimble supports).
* Poon-Dryja revocation can be rewritten as an HTLC-like construct (indeed =
this was the original formulation).
* Since we have shown that, by use of two transaction alternatives, one t=
imelocked and the other hashlocked, we can implement an HTLC-like construct=
on MimbleWimble, that is enough.
* Relative locktimes in Decker-Wattenhofer are imposed by simple `nSequence=
`, not by `OP_CSV`.
HTLCs hosted inside such constructions can again use the two-transactions=
construct in MimbleWimble.
* Ditto with indefinite-lifetime Spilman.
* Ditto with Decker-Russell-Osuntokun.
* The paper shows the use of `OP_CSV`, but aj notes it is redundant, and =
I agree: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-Mar=
ch/001933.html
Thus, it is not the "nonexistence of SCRIPT" that prevents Lightning from b=
eing deployed on MimbleWimble.
Instead, it is the "nonexistence of **relative** locktime" that prevents Li=
ghtning over MimbleWimble.
Why would **relative** locktimes not possibly exist?
In order to **validate** a relative locktime, we need to know the blockheig=
ht that the output we are spending was confirmed in.
But the entire point of the "magical shrinking blockchain" is that already-=
spent outputs can be removed completely and all that needs to be validated =
by a new node is:
* The coin-creation events.
* The current UTXO set (plus attached rangeproofs).
* The blinding keys.
* Signatures of the blinding keys, and the kernels they sign (if we use the=
"kernels encode `nLockTime`" technique in some way, they should not exceed=
the current supposed blockheight).
The problem is that an output that exists in the UTXO set might be invalid,=
if it appears "too near" to an `nSequence` minimum spend of a previous out=
put that was spent in its creation.
That is, the above does not allow validation of **relative** locktimes, onl=
y **absolute locktimes**.
(At least as far as I understand: there may be special cryptographic constr=
ucts that allow signatures to reliably commit to some relative locktime).
This means that relative locktimes need to be implemented by showing the tr=
ansactions that spend previous UTXOS and create the current UTXOs, and so n=
o backwards to coin-creation events.
This forces us back to the old "validate all transactions" model of startin=
g a new node (and seriously damaging the entire point of using MimbleWimble=
anyway).
I do not believe it is the lack of SCRIPT that prevents Lightning-over-Mimb=
leWimble, but rather the lack of relative locktime, which seems difficult t=
o validate without knowing the individual transactions and when they were c=
onfirmed.
Regards,
ZmnSCPxj
|
