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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id E4C99C016E;
Sat, 20 Jun 2020 16:01:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id D4AF720532;
Sat, 20 Jun 2020 16:01:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 6jHKtZDBPKFk; Sat, 20 Jun 2020 16:01:26 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch
[185.70.40.140])
by silver.osuosl.org (Postfix) with ESMTPS id 5A9222001E;
Sat, 20 Jun 2020 16:01:26 +0000 (UTC)
Date: Sat, 20 Jun 2020 16:01:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1592668883;
bh=sxmsoUy5qN34lSw5S2tuI6xNmBRPaI4a4XPpoMMDVmo=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=uYFH09dgXMoEx/BYy7276ql77kzMjgLhnbSj+8LovCrIusYAciU4mZTVt56Rw/tRg
ouQ9t/MWeQyzJNt5uzzv+G9ZfRObWibSCFt/GWQrnx+xmUVUfIkuJb5o5KkI7GHZtl
9wMU2xkk4gTttp1J9b1E2Cj8PbHgKOir0u9c+qlM=
To: "David A. Harding" <dave@dtrt.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <wRX9uiX_fFrjZvlmgx3Sj64VA3DdXakJZJq2_7DHJWIS7QBlphgpaBDdm4SjdY4aij5pESsumww8iJw8QZe5mO8bPgpYFyp6eImF2xbaXR4=@protonmail.com>
In-Reply-To: <20200620103647.g62srlcxbjqpaqj6@ganymede>
References: <PtYNeePySy_thDHm8FwIIGEk32EjJpSmiwPctyEg0hOrLZEHjO1IBghm4MWY88g51K-XF2pf_JDnW0UdTL6QSbACEj21h9U1s5ITc_N3I6Q=@protonmail.com>
<67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com>
<62P_3wvv8z7AVCdKPfh-bs30-LliHkx9GI9Og3wqIK6hadIG0d6MJJm077zac1erpPUy31FqgZjkAjEl9AQtrOCg4XA5cxozBb7-OIbbgvE=@protonmail.com>
<4c4f3a06-0078-ef6a-7b06-7484f0f9edf1@mattcorallo.com>
<CACdvm3Of_9zhNmzCxeK-z8oz6wU=8RuDjr0R9+yrGeFjLYz9pg@mail.gmail.com>
<20200619195846.fclw4ilngvbbf2kk@ganymede>
<20200619205220.fshbr7pbijaerbf2@ganymede>
<CACdvm3O+A5M17rqejzAMUzE+fxLdzqnDY2m5+rnc5C=nzyPp9g@mail.gmail.com>
<20200620103647.g62srlcxbjqpaqj6@ganymede>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties
and Competing Interest
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: Sat, 20 Jun 2020 16:01:29 -0000
Good morning Dave,
> ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> hoping one of Bitcoin's several inventive cryptographers would come
> along and describe how someone with an adaptor signature could use that
> information to create a pubkey that could be put into a transaction with
> a second output that OP_RETURN included the serialized adaptor
> signature. The pubkey would be designed to be spendable by anyone with
> the final signature in a way that revealed the hidden value to the
> pubkey's creator, allowing them to resolve the PTLC. But if that's
> fundamentally not possible, I think we could advocate for making
> pay-to-revealed-adaptor-signature possible using something like
> OP_CHECKSIGFROMSTACK.[3]
Not a cryptographer, I just play one on the Internet, but maybe the pay-for=
-signature construction could work...?
Assuming a PTLC has a pointlocked branch, which involves signing with MuSig=
(A, B).
A offers to B the amount if B reveals the secret `t` behind `T =3D t * G`; =
A knows `T` but not `t`.
This is done by B handing over `R[B]` and `s'[B]`:
R =3D R[A] + R[B] + T
s'[B] =3D r[B] + h(MuSig(A, B) | R | m) * b
Then A provides its partial signature to B.
s[A] =3D r[A] + h(MuSig(A, B) | R | m) * a
B has to complete the signature by:
s =3D s[A] + s'[B] + t
Since A knows both `s[A]` and `s'[B]`, once it knows `s`, it can compute `t=
`.
Now, we can massage the equation for `s`:
s =3D r[A] + h(MuSig(A, B) | R | m) * a + r[B] + h(MuSig(A, B) | R | m)=
* b + t
; multiply both sides by G
s * G =3D r[A] * G + h(MuSig(A, B) | R | m) * a * G + r[B] * G + h(MuSi=
g(A, B) | R | m) * b * G + t * G
; replace with public points
s * G =3D R[A] + h(MuSig(A, B) | R | m) * A + R[B] + h(MuSig(A, B) | R =
| m) * B + T
Note that A can compute `s * G` above, because it generated `R[A]`, was giv=
en `R[B]` and `T`, and knows who `A` and `B` are.
So what A needs to do is to offer a fund that can only be claimed by leakin=
g knowledge of `s` behind `s * G`.
A can do this by creating a new keypair `A[p4s] =3D a[p4s] * G` and putting=
a fund into it.
Then A generates an `R[A][p4s] =3D r[A][p4s] * G`, and computes:
R[p4s] =3D R[A][p4s] + s * G
s'[A][p4s] =3D r[A][p4s] + h(A | R[p4s] | m) * a[p4s]
The signed message could be a signature to `SIGHASH_NONE`, finally an actua=
l use for that flag.
A reveals publicly (in an `OP_RETURN` as you suggest):
* `R[A][p4s]`
* `s * G`
* `s'[A][p4s]`
* `A[p4s]` - Already the Schnorr output pubkey.
In order to complete the above signature, a third party C has to learn `s` =
from B.
The third party has to scan every onchain 1-of-1 signature for an `s` that =
matches `s * G`, so there is greater processing (point multiplies are more =
expensive than hashes, also there are more 1-of-1s).
But once learned, the third party can complete the signature and claim the =
funds.
And A then learns `s`, from which it can derive `t`.
The third party learns about which channel (i.e. the UTXO that was spent to=
create the PTLC in the first place), but never learns `t` or `T`, which is=
a small but nice privacy bonus.
Regards,
ZmnSCPxj
|
