> 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.

Yes, I'm only aiming LN-cooperative cases, as your noticed HTLCs only exist
on commitment txn and masquerading them in some Taptree would come
with its own challenges. Cooperative closings should be the majority of
channels if network is reliable and so would be a set big enough to achieve
the goal
of blurring Coinjoins among LN transactions.

Right now we don't use `nSequence` but the current interactive tx
construction proposal uses it for RBF (weird watermark was an example).

> On mutual closes, we should probably set `nLockTime` to the current
blockheight + 1 as well.
> This has greater benefit later in a Taproot world.

I assume mutual closes would fall under the aforementioned tx construction
proposal, so a closing may be a batch to fund other channels or
splice existent ones.

> 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.

That's a really acute point, utxo age and spending frequency may be obvious
protocol leaks. 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. 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 adoption
of a common format by other onchain transactions than LN ones would help a
lot.

> 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.

Yes but if you do this for Core and given some merchants are refusing RBF
transactions for onchain payments, people are going to complain...
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
broadcast them later to obfuscate mempool analysis).

> However, it seems to me that we need to as well nail down the details of
this format.

Of course, just curious of people opinions right now but if it's a good way
to solve the described problem, will draft a spec.

Le sam. 22 févr. 2020 à 20:29, ZmnSCPxj <ZmnSCPxj@protonmail.com> a écrit :

> 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
>