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
|
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 C5B71C0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Feb 2020 23:36:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id AC89C864F6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Feb 2020 23:36:04 +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 I8faYk3sTd1b
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Feb 2020 23:36:02 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by whitealder.osuosl.org (Postfix) with ESMTPS id 31B6885BCA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Feb 2020 23:36:02 +0000 (UTC)
Date: Mon, 24 Feb 2020 23:35:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1582587359;
bh=ZEFQWpnbhM3Z4pTesudRsrk+1VrLGmc71J6Z/Vd4iz4=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=ZC+2u6ztN7hZpCpD5opC53/SLU91TTEh74PRrEzJ4l223oRDzFDINbOhSlReY1uKG
BfLr97p0Evg+qckXpRye1Ee+L06mtGUH81/5gl9pL33K93qp7/vrU+Ulg/ChWd7uuR
LjWjJbR/pHu/hB+eh+oDhIDGJ0kY/Ob8vCyzQoEY=
To: Antoine Riard <antoine.riard@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <2-MilNWxNU5sCVK81AtIN7LhLButGQNbxgkr50rzsCvd5FqrD3VHBKCWjlxeFXYbKzC1XX5jm8NpzQUR95TGyupYqL6ggL8rPObGYC0AYWE=@protonmail.com>
In-Reply-To: <CALZpt+H6g4ak_kzbNr-QwTd04YwqBqkmHL4ZYPxqxQLgtv9W6Q@mail.gmail.com>
References: <CALZpt+E4Mr=g8zw95tyteGh53DH1mZ2HhNzQdy92+ErTtx3VbQ@mail.gmail.com>
<wUeoSi98_WNKqyiqI0yZ7YKCjsWqBO4lprQkQXbO_VkrALVxaYWsMRvbgnsHMWXA7QsB2gp9N2-a-gLuxY74xQMXwdyYKsKyLbNe1OSUVoQ=@protonmail.com>
<CALZpt+H6g4ak_kzbNr-QwTd04YwqBqkmHL4ZYPxqxQLgtv9W6Q@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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding
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, 24 Feb 2020 23:36:04 -0000
Good morning Antoine,
> > On mutual closes, we should probably set `nLockTime` to the current blo=
ckheight + 1 as well.
> > This has greater benefit later in a Taproot world.
>
> I assume mutual closes would fall under the aforementioned tx constructio=
n proposal, so a closing may be a batch to fund other channels or
> splice existent ones.
Ah, that is indeed of great interest.
I proposed before to consider splicing as a form of merged closing plus fun=
ding, rather than a modification of channel state; in particular we might n=
ote that, for compatibility with our existing system, a spliced channel wou=
ld have to change its short channel ID and channel ID, so it is arguably a =
different channel already.
>
> > A kind of non-equal-value CoinJoin could emulate a Lightning open + clo=
se, but most Lightning channels will have a large number of blocks (thousan=
ds or tens of thousands) between the open and the close; it seems unlikely =
that a short-term channel will exist > that matches the non-equal-value Coi=
nJoin.
>
> That's a really acute point, utxo age and spending frequency may be obvio=
us protocol leaks.
Yes; I am curious how JoinMarket reconciles how makers mix their coins vs. =
how takers do; presumably the tumbler.py emulates the behavior of a maker s=
omehow.
> Splicing may help there because a LN node would do multiple chain writes =
during channel lifecycle for liquidity reasons but it's
> near-impossible to predict its frequency without deployment.
Long ago, I proposed an alternative to splicing, which would today be recog=
nizable as a "submarine swap" or "lightning loop". https://lists.linuxfound=
ation.org/pipermail/lightning-dev/2017-May/000692.html
Perhaps the frequencies of those operations may hint as to how much splicin=
g would occur in practice in the future.
> Even with this, I do fear an analysis gap between Coinjoin spending delta=
and LN ones. A way to circumvent this would be for CoinjoinXT to timelock =
its PTG
> transactions to mimick actively-spliced LN channels. That's where adoptio=
n of a common format by other onchain transactions than LN ones would help =
a lot.
Well, one way to implement splice-in would be to have an output that is fir=
st dedicated to the splice-in, and *then* a separate transaction which actu=
ally does the splice-in.
This has a drawback of requiring an extra transaction, which wins us the fa=
cility to continue operation of the channel even while the splice-in transa=
ctions are being confirmed while retaining only one state.
(the latest proposal, I believe, does *not* use this construction, and inst=
ead requires both sides to maintain two sets of states, with one state bein=
g a fallback in case the splice-in gets double spent; but in times of high =
blockchain load this can lead to the channel having a two sets of states un=
til blockchain load reduces.)
As it happens, my alternate proposal for CoinJoinXT is similar in that ther=
e are "entry transactions" that introduce coins into the PTG, which are nee=
ded to prevent participants from double-spending while the mix is on-going.=
https://zmnscpxj.github.io/bitcoin/coinjoinxt.html
Note the proposal differs from the original by waxwing, which requires back=
outs at each intermediate output, and the entry transactions are potential =
watermarks on the CoinJoinXT protocol as well.
A Chaumian CoinJoinXT cannot use backouts at each intermediate output since=
no participant should have any knowledge of how much each participant has =
contributed to each intermediate output, they only know they put so many fu=
nds in and so should get so many funds out.
Emulating LN splices mildly makes ConJoinXT less desirable, however, as the=
mix takes longer and is more costly.
>
> > Should always be on, even if we do not (yet) have a facility to re-inte=
ract to bump fees higher.
> > While it is true that a surveillor can determine that a transaction has=
in fact been replaced (by observing the mempool) and thus eliminate the se=
t of transactions that arose from protocols that mark RBF but do not (yet) =
have a facility to bump fees higher, this > information is not permanently =
recorded on all fullnodes and at least we force surveillors to record this =
information themselves.
>
> Yes but if you do this for Core and given some merchants are refusing RBF=
transactions for onchain payments, people are going to complain...
Grumble grumble, all unconfirmed transaction are RBF because miners like mo=
ney, grumble grumble, flagged RBF is just a node relay policy, grumble grum=
ble, some humans sometimes, grumble grumble....
Does not Electrum do RBF by default?
Unless I have a lower-level agent that always enables RBF option when I ins=
tall new Electrums, hmmm, maybe I should check first.
> Also see footnote on spurious-RBF about not-having facility to bump fees =
higher (you can sign multiple RBF transactions in 1-RTT and agree to broadc=
ast them later to obfuscate mempool analysis).
1.5RTT with MuSig.
An issue here is that if not all participants contribute to the fees equall=
y, then a participant who is paying lower fee or no fee has a mild incentiv=
e to just broadcast the highest-fee version and be done with it: forget the=
other transactions and just aim for the highest fee immediately, ignore th=
e mempool state so you do not have to do all those calculations or even mai=
ntain a mempool, and so on.
This can be mitigated if all participants contribute equal or nearly-equall=
y to the fees, though that complicates single-funding, and may violate Init=
iator Pays Principle (the initiator of an action should pay all fees relate=
d to the action, as otherwise it may be possible to create a null operation=
that the acceptor of the action ends up paying fees for, which can be used=
as a financial attack to drain acceptors).
> > However, it seems to me that we need to as well nail down the details o=
f this format.
>
> Of course, just curious of people opinions right now but if it's a good w=
ay to solve the described problem, will draft a spec.
There may be other protocols interested in this as well --- for instance "s=
ubmarine swaps" and "lightning loops", which are the same thing.
Regards,
ZmnSCPxj
|
