From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Antoine Riard <antoine.riard@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding
Date: Sun, 23 Feb 2020 01:29:09 +0000 [thread overview]
Message-ID: <wUeoSi98_WNKqyiqI0yZ7YKCjsWqBO4lprQkQXbO_VkrALVxaYWsMRvbgnsHMWXA7QsB2gp9N2-a-gLuxY74xQMXwdyYKsKyLbNe1OSUVoQ=@protonmail.com> (raw)
In-Reply-To: <CALZpt+E4Mr=g8zw95tyteGh53DH1mZ2HhNzQdy92+ErTtx3VbQ@mail.gmail.com>
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 acceptable risk to lose privacy in that case.
Of course, it takes two to tango, and it takes two to make a Lightning channel, so ---
In any case, I explored some of the difficulties with unilateral closes as well:
* https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002421.html
* https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002415.html
On mutual closes, we should probably set `nLockTime` to the current blockheight + 1 as well.
This has greater benefit later in a Taproot world.
> Questions:
> * Are there any protocol-specific semantic wrt to onchain transactions incompatibility
> 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 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 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 two, 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 recorded on all fullnodes and at least we force surveillors to record this information themselves.
> * Core wallet or any other protocol or even batching algorithms could adopt
> to this format ?
It seems likely.
However, it seems to me that we need to as well nail down the details of this 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
next prev parent reply other threads:[~2020-02-23 1:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-21 22:17 Antoine Riard
2020-02-22 12:10 ` AdamISZ
2020-02-23 0:59 ` ZmnSCPxj
2020-02-24 17:58 ` Antoine Riard
2020-02-23 1:29 ` ZmnSCPxj [this message]
2020-02-24 18:26 ` Antoine Riard
2020-02-24 23:35 ` ZmnSCPxj
2020-02-25 19:16 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='wUeoSi98_WNKqyiqI0yZ7YKCjsWqBO4lprQkQXbO_VkrALVxaYWsMRvbgnsHMWXA7QsB2gp9N2-a-gLuxY74xQMXwdyYKsKyLbNe1OSUVoQ=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox