Date: Sun, 23 Feb 2020 01:29:09 +0000
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
Precedence: list

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