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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id B032FC013E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Feb 2020 01:29:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id A65F085507
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Feb 2020 01:29:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id BUM0MNao0NM5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Feb 2020 01:29:23 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by fraxinus.osuosl.org (Postfix) with ESMTPS id CBC37852D5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Feb 2020 01:29:22 +0000 (UTC)
Date: Sun, 23 Feb 2020 01:29:09 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1582421360;
bh=O+FZwC2eb+eq8rLjq7g54DgUw9xpX+bHxOtl2rk3WUo=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=N974NoEOUXoeGwcgIcwy5edYwLOKc9UwkSEHhLFQ12xTKVZGfbg9MdoSObJOjnBQt
7BHe5a4voFzUX0LsPCPiRuubHZYh6ZkJMh7Q6hJw9HdfafHIV+sVqikb9Zt93PbV+9
F3n8t9Ecd82FHGPatmvZjSkZmxsKALAkdmqkzHIw=
To: Antoine Riard <antoine.riard@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <wUeoSi98_WNKqyiqI0yZ7YKCjsWqBO4lprQkQXbO_VkrALVxaYWsMRvbgnsHMWXA7QsB2gp9N2-a-gLuxY74xQMXwdyYKsKyLbNe1OSUVoQ=@protonmail.com>
In-Reply-To: <CALZpt+E4Mr=g8zw95tyteGh53DH1mZ2HhNzQdy92+ErTtx3VbQ@mail.gmail.com>
References: <CALZpt+E4Mr=g8zw95tyteGh53DH1mZ2HhNzQdy92+ErTtx3VbQ@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
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: Sun, 23 Feb 2020 01:29:24 -0000
Ggood morning Antoine, and list,
> * nLocktime/nSequence
> ...
> * weird watermark (LN commitment tx obfuscated commitment number)
> ...
> LN (cooperative case):
I notice your post puts little spotlight on unilateral cases.
A thing to note, is that we only use `nSequence` and the weird watermark on=
unilateral closes.
Even HTLCs only exist on unilateral closes --- on mutual closes we wait for=
HTLCs to settle one way or the other before doing the mutual close.
If we assume that unilateral closes are rare, then it might be an acceptabl=
e risk to lose privacy in that case.
Of course, it takes two to tango, and it takes two to make a Lightning chan=
nel, so ---
In any case, I explored some of the difficulties with unilateral closes as =
well:
* https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/00=
2421.html
* https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/00=
2415.html
On mutual closes, we should probably set `nLockTime` to the current blockhe=
ight + 1 as well.
This has greater benefit later in a Taproot world.
> Questions:
> * Are there any protocol-specific semantic wrt to onchain transactions in=
compatibility
> between Coinjoin and cooperative LN txn ?
A kind of non-equal-value CoinJoin could emulate a Lightning open + close, =
but most Lightning channels will have a large number of blocks (thousands o=
r 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 CoinJoin.
In particular, a LN cooperative close will, in general, have only one input=
.
A new form of CoinJoin could, instead of using a single transaction, use tw=
o, with an entry transaction that spends into an n-of-n of the participants=
, and the n-of-n being spent to split the coin back to their owners.
But again: a Lightning network channel would have much time with the funds =
in a single UTXO before later splitting the funds,
This also starts edging closer to CoinJoinXT territory.
> * What about RBF-by-default ?
Should always be on, even if we do not (yet) have a facility to re-interact=
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 set 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 record=
ed on all fullnodes and at least we force surveillors to record this inform=
ation themselves.
> * Core wallet or any other protocol or even batching algorithms could ado=
pt
> to this format ?
It seems likely.
However, it seems to me that we need to as well nail down the details of th=
is format.
> * Is artificially increasing the number of outputs to mimic Coinjoins txn
> acceptable wrt to utxo bloat/fees ?
That is indeed an issue.
Regards,
ZmnSCPxj
|
