[bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding

[bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 3365 bytes --]

Coinjoins interceptions seem to raise at an increasing pace. Their onchain
fingerprint (high-number of inputs/outputs, lack of anti-fee snipping,
script
type, ...) makes their detection quite easy for a chain observer. A ban of
coinjoin'ed coins or any other coins linked through a common ownwer would
undermine the long-term fungibility of the whole ecosystem.

Of course, they do provide privacy for the participating coins but at the
tradeoffs of creating two observable sets: coinjoin'ed vs non-coinjoin'ed.
Ideally, all onchain transactions should conform to a common transaction
pattern that provides unobservability -- i.e a specific transaction would
be indistinguishable from any other transaction at all. For LN or Coinjoin
it means an external observer, not-involved in the protocol, should be
unable to tell which protocol is being used, or if _any_ specific protocol
is being used.

How can a Bitcoin tranaction leak protocol usage ?
* the output type (p2sh, p2wsh, ...)
* the spending policy (2-of-3 multisig, timelock, hashlock,...)
* outputs ordering (BIP69)
* nLocktime/nSequence
* RBF-signaling
* Equal-value outputs
* weird watermark (LN commitment tx obfuscated commitment number)
* fees strategy like CPFP
* in-protocol announcements [0]

A solution could be to blur multiple protocol onchain transactions into
one common transaction format [1]. For example, if one of them uses
nSequence
for some protocol semantic all the other ones should do it too. Any
deviation
would be enough to be leverage as a watermark and blow up all other tweaks.
If Schnorr-Taproot gets adopted and deployed by the community and LN
specifies
an interactive tx construction protocol [2], the timing would be pretty good
to adopt such format IMO.

Coinjoin:
* nSequence can be set, it's still secure if party don't resign [3]
* nLocktime can be set for anti-fee snipping
* Taproot spending

LN (cooperative case):
* splicing may blur funding/closing as the same thing, closing
address can be a funding output
* splice-in would allow equal value outputs
* nSequence likely to be set for multi-party tx construction
* nLocktime can be set for anti-fee snipping

Adopting a common transaction format isn't a cure-all solution
on the long-term privacy road but if it circumvent ban of some class
of transactions that would be already a nice win and a worthy effort
to do so.

Questions:
* Are there any protocol-specific semantic wrt to onchain transactions
incompatibility
between Coinjoin and cooperative LN txn ?
* What about RBF-by-default ?
* Core wallet or any other protocol or even batching algorithms could adopt
to this format ?
* Is artificially increasing the number of outputs to mimic Coinjoins txn
acceptable wrt to utxo bloat/fees ?

Cheers,

Antoine

[0] Like LN announcing public channels with signatures committing both
to onchain utxos and nodes static pubkeys. And them being display on LN
search engines with full owner info...

[1] By format, I don't mean a *binary* format a la PSBT but mere something
like BOLT3, a *logical* format.

[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002500.html

[3] But "blank" RBF would be a privacy leak if Coinjoin are never bumped,
because if you see both a low-fees and high-fees transaction you now know
they are a LN one, so Coinjoins implems should do some time spurious RBFs

[-- Attachment #2: Type: text/html, Size: 3749 bytes --]

Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding

[AdamISZ]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, 21 February 2020 22:17, Antoine Riard via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> How can a Bitcoin tranaction leak protocol usage ?
> * the output type (p2sh, p2wsh, ...)
> * the spending policy (2-of-3 multisig, timelock, hashlock,...)
> * outputs ordering (BIP69)
> * nLocktime/nSequence
> * RBF-signaling
> * Equal-value outputs
> * weird watermark (LN commitment tx obfuscated commitment number)
> * fees strategy like CPFP
> * in-protocol announcements [0]
>
Good list.
Another one, usually wouldn't be *protocol* as much as wallet leakage, but could be: utxo selection algorithm (which of course may be difficult to deduce, but often, far from impossible).
(Also trivial and increasingly irrelevant, but nVersion).

With regards to coinjoin in this context (I know your points are much broader), my comment is:
For existing protocols (joinmarket's, wasabi's, samourai's), in the equal-outs paradigm, I don't see much that can be done in this area.
But I would ask people to consider CoinJoinXT[1] more seriously in a taproot/schnorr world, since it addresses this exact point. With a short (not cross-block like swaps or LN setup) interaction, participants can arrange the effect of coinjoin without the on-chain watermark of coinjoin (so, steganographic). The taproot/schnorr part is needed there because multisig is required from transaction to transaction in that protocol, so doing it today is less interesting (albeit still interesting).

waxwing

[1] https://joinmarket.me/blog/blog/coinjoinxt/

Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding

[ZmnSCPxj]

Good morning waxwing,

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, 21 February 2020 22:17, Antoine Riard via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > How can a Bitcoin tranaction leak protocol usage ?
> >
> > -   the output type (p2sh, p2wsh, ...)
> > -   the spending policy (2-of-3 multisig, timelock, hashlock,...)
> > -   outputs ordering (BIP69)
> > -   nLocktime/nSequence
> > -   RBF-signaling
> > -   Equal-value outputs
> > -   weird watermark (LN commitment tx obfuscated commitment number)
> > -   fees strategy like CPFP
> > -   in-protocol announcements [0]
>
> Good list.
> Another one, usually wouldn't be protocol as much as wallet leakage, but could be: utxo selection algorithm (which of course may be difficult to deduce, but often, far from impossible).
> (Also trivial and increasingly irrelevant, but nVersion).
>
> With regards to coinjoin in this context (I know your points are much broader), my comment is:
> For existing protocols (joinmarket's, wasabi's, samourai's), in the equal-outs paradigm, I don't see much that can be done in this area.
> But I would ask people to consider CoinJoinXT[1] more seriously in a taproot/schnorr world, since it addresses this exact point. With a short (not cross-block like swaps or LN setup) interaction, participants can arrange the effect of coinjoin without the on-chain watermark of coinjoin (so, steganographic). The taproot/schnorr part is needed there because multisig is required from transaction to transaction in that protocol, so doing it today is less interesting (albeit still interesting).

CoinJoinXT is indeed something I am interested in at some point: https://zmnscpxj.github.io/bitcoin/coinjoinxt.html
The above writeup is a client-server model, with multiple clients mixing.
If none of the participants reveal that a CoinJoinXT was done, then the graph is difficult to detect as such.
However, if any participants reveal that a CoinJoinXT was done, it has a fallback such that it is almost as good as an equal-value CoinJoin (but takes up more block space).
At least it is not immediately obvious that it is in fact a CoinJoinXT from *just* a simple transaction analysis, which we hope is enough to deter simple policies like "check N transactions back for a transaction with more than one equal-valued output".

Regards,
ZmnSCPxj

Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 3147 bytes --]

> Another one, usually wouldn't be *protocol* as much as wallet leakage,
but could be: utxo selection algorithm (which of course may be difficult to
deduce, but often, far from impossible).

Yes sure that's a good point, it may affect protocol too if your LN
implementation has its own onchain wallet. If not, and it reuses a non-LN
wallet you just carry on its fingerprint.
An extension in the future could be for closing/splicing transaction, your
liquidity algorithm may select in a really specific fashion which channels
must be closed or increased...

> But I would ask people to consider CoinJoinXT[1] more seriously in a
taproot/schnorr world, since it addresses this exact point.

The equal value paradigm is such a watermark and I assume it leans to
increase the number of outputs so I don't see it followed by any other
protocol. But yes CoinjoinXT, if you can come up with a easy interactive
multi-tx construction protocol that would be interesting (and could be
reused by any cut-through implementation I guess).

Overall, my thinking was to start specifying this now because such thing
would take a fair amount of time/coordination to get adopted. This way if
and when Taproot/Schnorr happen we don't
have to wait another period to start enjoying the privacy enhancement
(worst-case we can fallback on 2p-ecdsa).



Le sam. 22 févr. 2020 à 07:10, AdamISZ <AdamISZ@protonmail.com> a écrit :

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, 21 February 2020 22:17, Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > How can a Bitcoin tranaction leak protocol usage ?
> > * the output type (p2sh, p2wsh, ...)
> > * the spending policy (2-of-3 multisig, timelock, hashlock,...)
> > * outputs ordering (BIP69)
> > * nLocktime/nSequence
> > * RBF-signaling
> > * Equal-value outputs
> > * weird watermark (LN commitment tx obfuscated commitment number)
> > * fees strategy like CPFP
> > * in-protocol announcements [0]
> >
> Good list.
> Another one, usually wouldn't be *protocol* as much as wallet leakage, but
> could be: utxo selection algorithm (which of course may be difficult to
> deduce, but often, far from impossible).
> (Also trivial and increasingly irrelevant, but nVersion).
>
> With regards to coinjoin in this context (I know your points are much
> broader), my comment is:
> For existing protocols (joinmarket's, wasabi's, samourai's), in the
> equal-outs paradigm, I don't see much that can be done in this area.
> But I would ask people to consider CoinJoinXT[1] more seriously in a
> taproot/schnorr world, since it addresses this exact point. With a short
> (not cross-block like swaps or LN setup) interaction, participants can
> arrange the effect of coinjoin without the on-chain watermark of coinjoin
> (so, steganographic). The taproot/schnorr part is needed there because
> multisig is required from transaction to transaction in that protocol, so
> doing it today is less interesting (albeit still interesting).
>
> waxwing
>
> [1] https://joinmarket.me/blog/blog/coinjoinxt/
>

[-- Attachment #2: Type: text/html, Size: 3824 bytes --]

Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding

[ZmnSCPxj]

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

Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 6296 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 7363 bytes --]

Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding

[ZmnSCPxj]

Good morning Antoine,


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

Ah, that is indeed of great interest.
I proposed before to consider splicing as a form of merged closing plus funding, rather than a modification of channel state; in particular we might note that, for compatibility with our existing system, a spliced channel would 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 + 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.

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

> 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 recognizable as a "submarine swap" or "lightning loop". https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/000692.html
Perhaps the frequencies of those operations may hint as to how much splicing 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 adoption 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 first dedicated to the splice-in, and *then* a separate transaction which actually does the splice-in.
This has a drawback of requiring an extra transaction, which wins us the facility to continue operation of the channel even while the splice-in transactions are being confirmed while retaining only one state.
(the latest proposal, I believe, does *not* use this construction, and instead requires both sides to maintain two sets of states, with one state being 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 until blockchain load reduces.)

As it happens, my alternate proposal for CoinJoinXT is similar in that there are "entry transactions" that introduce coins into the PTG, which are needed 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 backouts 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 funds 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-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...

Grumble grumble, all unconfirmed transaction are RBF because miners like money, grumble grumble, flagged RBF is just a node relay policy, grumble grumble, 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 install 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 broadcast them later to obfuscate mempool analysis).

1.5RTT with MuSig.

An issue here is that if not all participants contribute to the fees equally, then a participant who is paying lower fee or no fee has a mild incentive 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 the mempool state so you do not have to do all those calculations or even maintain a mempool, and so on.
This can be mitigated if all participants contribute equal or nearly-equally to the fees, though that complicates single-funding, and may violate Initiator Pays Principle (the initiator of an action should pay all fees related 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 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.

There may be other protocols interested in this as well --- for instance "submarine swaps" and "lightning loops", which are the same thing.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 8832 bytes --]

Morning Zeeman,

> I proposed before to consider splicing as a form of merged closing plus
funding, rather than a modification of channel state; in particular we
might note that, for compatibility with our existing system, a spliced
channel would have to change its short channel ID > and channel ID, so it
is arguably a different channel already.

Yes but you may want alias to keep your channel routing-score across
splicing, though how to do this is more LN-dev specific.

> Emulating LN splices mildly makes ConJoinXT less desirable, however, as
the mix takes longer and is more costly.

Intuitively, a lot of Coinjoin traffic may be redirected in the future
through LN when protocol matures, privacy properties may be better (though
need careful analysis).
Coinjoins would be only for high-amounts for which security/liquidity isn't
offered by LN, and in this case time for increasing privacy is IMO an
acceptable tradeoff.

> Does not Electrum do RBF by default?

Dunno, for more context on RBF and its controversies see
https://bitcoincore.org/en/faq/optin_rbf/ (or Optech resources)

> 1.5RTT with MuSig

Yes right I meaned you don't need to assume latter interactivity if it's a
multi-party tx construction you sign multiple RBF versions at same time.
Still need to think about privacy-preserving fee bumping wrt to mempool
observer

> This can be mitigated if all participants contribute equal or
nearly-equally to the fees, though that complicates single-funding, and may
violate Initiator Pays Principle (the initiator of an action should pay all
fees related 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).

Yes, but also you want the acceptor to pay for its inputs announced to
avoid pouring the spending burden on the initiator only, or doing any
free-ride aggregation .

> There may be other protocols interested in this as well --- for instance
"submarine swaps" and "lightning loops", which are the same thing.

Yes good point, specially batched submarine swaps are good candidates, also
DLCs (will enquiry on tx pattern of more bitcoin protocol)


Le lun. 24 févr. 2020 à 18:36, ZmnSCPxj <ZmnSCPxj@protonmail.com> a écrit :

> Good morning Antoine,
>
>
> > > 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.
>
> Ah, that is indeed of great interest.
> I proposed before to consider splicing as a form of merged closing plus
> funding, rather than a modification of channel state; in particular we
> might note that, for compatibility with our existing system, a spliced
> channel would 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 +
> 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.
>
> 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
> somehow.
>
> > 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
> recognizable as a "submarine swap" or "lightning loop".
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/000692.html
> Perhaps the frequencies of those operations may hint as to how much
> splicing 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
> adoption 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
> first dedicated to the splice-in, and *then* a separate transaction which
> actually does the splice-in.
> This has a drawback of requiring an extra transaction, which wins us the
> facility to continue operation of the channel even while the splice-in
> transactions are being confirmed while retaining only one state.
> (the latest proposal, I believe, does *not* use this construction, and
> instead requires both sides to maintain two sets of states, with one state
> being 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 until blockchain load reduces.)
>
> As it happens, my alternate proposal for CoinJoinXT is similar in that
> there are "entry transactions" that introduce coins into the PTG, which are
> needed 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
> backouts 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 funds 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-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...
>
> Grumble grumble, all unconfirmed transaction are RBF because miners like
> money, grumble grumble, flagged RBF is just a node relay policy, grumble
> grumble, 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
> install 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
> broadcast them later to obfuscate mempool analysis).
>
> 1.5RTT with MuSig.
>
> An issue here is that if not all participants contribute to the fees
> equally, then a participant who is paying lower fee or no fee has a mild
> incentive 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 the mempool state so you do not have to do all those calculations or
> even maintain a mempool, and so on.
> This can be mitigated if all participants contribute equal or
> nearly-equally to the fees, though that complicates single-funding, and may
> violate Initiator Pays Principle (the initiator of an action should pay all
> fees related 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
> 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.
>
> There may be other protocols interested in this as well --- for instance
> "submarine swaps" and "lightning loops", which are the same thing.
>
> Regards,
> ZmnSCPxj
>
>

[-- Attachment #2: Type: text/html, Size: 9918 bytes --]