Hey Antoine,
Sure, I agree with you, the usual mempool pinning issues still apply
regardless of whether we use 0-conf or not. And we must solve them
all at some point!
I think a reasonable mid-term solution is to use v3 transactions for
channel funding and splicing, with the obvious caveat that
Hi Bastien,
> This can be fixed by using a "soft lock" when selecting utxos for a non
> 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
> utxos while non 0-conf funding attempts can (should) reuse soft locked
> utxos.
If my understanding of the "soft lock" strategy is
Hey Matt, Zman,
> I propose that we DO lock our UTXOs after tx_completes have been
> exchanged IF we are the only contributor. We don't have to worry
> about liquidity griefing in this case, since the peer has no
> tx_signatures to withhold from us.
While this is true for dual funding, this
Good morning Matt, and t-bast,
Your proposal basically means "do not dual-fund 0-conf".
You might as well use the much simpler openv1 flow in that case, just because
it is simpler.
Regards,
ZmnSCPxj
Sent with Proton Mail secure email.
--- Original Message ---
On Tuesday, May 9th,
Hi Bastien,
In general, 0-conf is only safe when WE are the only contributor to
the channel, otherwise the peer could double spend us.
The problem you seem to be describing is that we might double-spend
ourselves if we don't lock our 0-conf UTXOs at some point. I propose
that we DO lock our
Good morning t-bast, and list,
Dual-funded 0-conf can be made safe in the following case:
* If the initiator uses swap-in-potentiam addresses (with initiator as Alice,
acceptor as Bob).
If the initiator stalls, then the acceptor can retaliate by refusing to sign
the swap-in-potentiam UTXOs
Good morning list,
One of the challenges created by the introduction of dual funded
transactions [1] in lightning is how to protect against liquidity
griefing attacks from malicious peers [2].
Let's start by reviewing this liquidity griefing issue. The dual funding
protocol starts by exchanging
