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
|
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 2CCD5C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 5 Sep 2020 02:45:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 1AB6086AD8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 5 Sep 2020 02:45:12 +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 WXTcD8GLshcz
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 5 Sep 2020 02:45:10 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch
[185.70.40.137])
by whitealder.osuosl.org (Postfix) with ESMTPS id E1B1286A6D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 5 Sep 2020 02:45:09 +0000 (UTC)
Date: Sat, 05 Sep 2020 02:45:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1599273907;
bh=YfWogWmoGurn7bAc/ltsD29rdIWVxzE4O2yJoUQ2sbc=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=TgQJuUsQLQ3YkJbBrdaWQ4QjsUcPPKzmDA+QgFdUPJmM/jv/SZE1uW9J3Y79RQoy1
g94E5lFnknXGKc6YNgZZlqYyZgU3Waerttr8qVRHc7bd0e0pwQ8NPr6ozLT0WY7TlW
iWDNctlWJFSzAOGIgSJPbaXBI+mZrRz+wTyTIcwQ=
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <w4WQcFmuXVY25fP69czESim9yHGOIB8v5G7jRnSiV5cqhpDXD9tG0AzFqWPUIxbFKfP1Kr-0mOuGocUVpBacFCTOAvRnO1MxBOcxB-w1KjM=@protonmail.com>
In-Reply-To: <Vf-RtORZUR0QYHZiYeyfVyJEIQbh0RYnPpZEeeDiIwaiGvu-R9wxhHm6D4b_Nwd8Ia2n6u2OL4u48Ra6t8BGWOCgGXJpFkFWQeAX2S4ijiI=@protonmail.com>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
<CALZpt+GxKDEDAGUH3Jb3rcZdh_jy_depLRE5KzGTpkZOLVH+QA@mail.gmail.com>
<VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com>
<0ac3fecb-012b-e210-55bb-36809682634a@riseup.net>
<bqFuDDJpKgkg1DaEQ9p14lxD__yLcJmklNqSK3jhmHxjxmhRYgHGJnUDDWMKfkZTJu-VqhFkVX4P2w6ipYuHpJ6umPmwe44PQs3HoNELEg4=@protonmail.com>
<8f387b40-8212-9807-70cc-b527902609c2@riseup.net>
<Vf-RtORZUR0QYHZiYeyfVyJEIQbh0RYnPpZEeeDiIwaiGvu-R9wxhHm6D4b_Nwd8Ia2n6u2OL4u48Ra6t8BGWOCgGXJpFkFWQeAX2S4ijiI=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Detailed protocol design for routed
multi-transaction CoinSwap
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, 05 Sep 2020 02:45:12 -0000
Good morning Chris, and probably also Lightningers,
> However, it might be possible to prevent the maker from learning the coll=
ateral input at all.
>
> If my understanding of BIP-143 is correct, inputs are hashed separately (=
`hashPrevouts`) from outputs (`hashOutputs`).
> Bob can provide the `hashPrevouts` as an opaque hash, while providing a d=
ecommitment of `hashOutputs` to show that the outputs of the collateralized=
contract transaction are correct, which is all that Charlie really needs t=
o know.
>
> Bob is incentivized to provide the correct `hashPrevouts`, because if it =
provides an incorrect `hashPrevouts` it cannot get a signature for a transa=
ction it can use in case of a protocol abort, thus potentially losing its m=
oney in case of a protocol abort.
> Conversely, Charlie does not care where Bob gets the funds that goes into=
its contract output come from, it only cares that the Bob collateralized c=
ontract output is I+K.
> It loses nothing to sign that transaction, and it would prefer that trans=
action since its own contract output is only I.
>
> This solution is mildly "unclean" as it depends on the details of the sig=
hash algorithm, though, and is not proposed seriously.
> Hopefully nobody will change the sighash algorithm anytime soon.........
>
> In addition, it complicates reusing Lightning watchtowers.
> Lightning watchtowers currently trigger on txid (i.e. it would have trigg=
ered on the txid of the B collateralized contract tx), but watching this ne=
eds to trigger on the spend of a txo, since it is not possible to prove tha=
t a specific `hashPrevouts` etc. goes with a specific txid without revealin=
g the whole tx (which is precisely what we are trying to avoid), as both ar=
e hashes.
> Watchtowers may need to be entrusted with privkeys, or need to wait for `=
SIGHASH_ANYPREVOUT` so that the exact txid of the B collateralized contract=
tx does not need to be fixed at signing time, thus this solution is undesi=
rable as well.
On the other hand, when considering Decker-Russell-Osuntokun, the `(halftxi=
d, encrypted_blob)` approach to watchtowers simply does not work.
Watchtowers are simpler in Decker-Russell-Osuntoku if and only if the watch=
tower knows the funding outpoint, therefore knows which channel it is watch=
ing *before* an attack on the channel occurs, and is less private.
I have argued before that we should instead use `(sighash[0:15], encrypted_=
blob)` rather than `(txid[0:15], encrypted_blob)`.
This makes Decker-Russell-Osuntokun blobs indistinguishable from Poon-Dryja=
blobs, and the watchtower is not even made aware what the commitment type =
of the channel is until an actual attack occurs.
If watchtowers use `(sighash[0:15], encrypted_blob)` instead, the proposal =
to hide the collateral input behind `hashPrevouts` would be workable, as Ch=
arlie knows the entire sighash of the B collateralized contract transaction=
even if it does not know the txid.
This also does not reveal the funding outpoint, or whether it is watching a=
Poon-Dryja channel, a Decker-Russell-Osuntokun channel, or a CoinSwap.
--
Even if we propose that CoinSwap makers should run their own watchtowers ra=
ther than hire a public watchtower, it's safer for a CoinSwap maker to have=
watchtowers that are unaware of exactly *what* they are watching.
If the watchtowers are aware of the funding outputs they are watching, then=
every additional watchtower a maker creates increases the attack surface o=
n the privacy of the maker, as the funding outputs becoming known allows th=
e maker hodlings to be derived.
If watchtowers only get a partial sighash, then the information that they c=
ontain are not sufficient by themselves to determine what coins are owned b=
y the maker, thus every additional watchtower is no longer a potential atta=
ck vector on the privacy of the maker.
So this is off-topic, but anyway, we should probably move to using `sighash=
[0:15]` instead of `txid[0:15]` for watchtowers.
Regards,
ZmnSCPxj
|
