Why Nostr? What is Njump?
2023-06-19 19:42:17
in reply to

Lightning Mailing List on Nostr: 🔖 Title: Liquidity griefing for 0-conf dual-funded txs 🏷️ Categories: ...

🔖 Title: Liquidity griefing for 0-conf dual-funded txs
🏷️ Categories: Lightning-dev

📝 Summary: The Lightning Network's dual funded transactions face challenges in protecting against liquidity griefing attacks. One solution is to never lock UTXOs used in the transactions, but this falls short when using 0-conf. A proposed solution is to lock UTXOs after transaction completion if the channel has only one contributor. Another proposal suggests using swap-in-potentiam addresses for immediate transfer to a 0-conf Lightning channel. However, locking UTXOs after completion may not work for splicing.

👥 Authors: • Matt Morehouse ( <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1zgyy2j829vn4zuvhkgza7qe37knzdls4kuwt2k8cehwpjxn9duwqv5j4mf" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Matt Morehouse [ARCHIVE]</span> (<span class="italic">npub1zgy…j4mf</span>)</a></span> ) • ZmnSCPxj ( <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>ZmnSCPxj [ARCHIVE]</span> (<span class="italic">npub1g5z…ms3l</span>)</a></span> ) • Bastien TEINTURIER ( <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Bastien TEINTURIER [ARCHIVE]</span> (<span class="italic">npub17fj…tr0s</span>)</a></span> )

📅 Messages Date Range: 2023-05-05 to 2023-05-10

✉️ Message Count: 5

📚 Total Characters in Messages: 26852

Messages Summaries

✉️ Message by Bastien TEINTURIER on 05/05/2023: The introduction of dual funded transactions in lightning has created challenges in protecting against liquidity griefing attacks from malicious peers. An elegant solution is to never lock utxos used in dual funded transactions, but this falls short when using 0-conf. Nodes offering 0-conf services expose themselves to liquidity griefing. Another related issue is that nodes that want to offer 0-conf channels must ensure that the utxos they use for 0-conf are isolated from the utxos they use for non 0-conf.

✉️ Message by ZmnSCPxj on 07/05/2023: Dual-funded 0-conf can be made safe if the initiator uses swap-in-potentiam addresses, allowing for immediate transfer to a 0-conf Lightning channel.

✉️ Message by Matt Morehouse on 09/05/2023: A proposed solution to protect against liquidity griefing attacks in Lightning Network's dual funded transactions is to never lock UTXOs used in the transactions. Instead, a proposal suggests locking UTXOs after transaction completion if the channel has only one contributor. This enables the common use case for 0-conf channels.

✉️ Message by ZmnSCPxj on 10/05/2023: A proposal to address liquidity griefing attacks in dual funded transactions by not locking UTXOs and using 0-conf channels with certain conditions.

✉️ Message by Bastien TEINTURIER on 10/05/2023: A proposal to lock UTXOs after tx_completes have been exchanged to prevent double-spending in 0-conf channels, but it may not work for splicing.

Follow <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1j3t00t9hv042ktszhk8xpnchma60x5kz4etemnslrhf9e9wavywqf94gll" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Lightning Mailing List</span> (<span class="italic">npub1j3t…4gll</span>)</a></span> for full threads


⚠️ Heads up! We've now started linking to replaceable long-form events (NIP-23), which allow for dynamic display of thread details like summaries, authors, and more. If you're unable to see this, your client may not support this feature yet.
Author Public Key
npub1j3t00t9hv042ktszhk8xpnchma60x5kz4etemnslrhf9e9wavywqf94gll