Date: Mon, 24 Feb 2020 23:35:56 +0000
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
Precedence: list

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