Why Nostr? What is Njump?
2023-08-16 00:49:03
in reply to

Lightning Mailing List on Nostr: 🔖 Title: Resumable channels using OP_CHECKSIGFROMSTACK 🏷️ Categories: ...

🔖 Title: Resumable channels using OP_CHECKSIGFROMSTACK
🏷️ Categories: Lightning-dev

📝 Summary: Thomas Voegtlin proposes the use of OP_CHECKSIGFROMSTACK for resumable Lightning channels, allowing for backup of channel state and fraud proof. Bastien Teinturier argues against the necessity and dangers of fraud proofs, suggesting mobile wallets can check backups. Peter Todd disagrees, suggesting a different approach and discussing Phoenix’s approach. SomberNight suggests implementing a peer backup solution. Bastien argues against reputation loss as a deterrent for cheating. Thomas suggests a more decentralized model and proposes symmetric peer backups with on-chain state commitments.

👥 Authors: • Peter Todd ( Peter Todd [ARCHIVE] (npub1m23…2np2) ) • Bastien TEINTURIER ( Bastien TEINTURIER [ARCHIVE] (npub17fj…tr0s) ) • SomberNight ( SomberNight [ARCHIVE] (npub1r3w…8xs3) ) • Thomas Voegtlin ( Thomas Voegtlin [ARCHIVE] (npub10f9…ej47) )

📅 Messages Date Range: 2023-08-14 to 2023-08-30

✉️ Message Count: 10

📚 Total Characters in Messages: 44764

Messages Summaries

✉️ Message by Thomas Voegtlin on 14/08/2023: Proposal for resumable Lightning channels using OP_CHECKSIGFROMSTACK. Allows for backup of channel state and fraud proof. Suited for private channels with Lightning service providers.

✉️ Message by Bastien TEINTURIER on 16/08/2023: The author argues that fraud proofs for Lightning channels are unnecessary and dangerous, suggesting that mobile wallets can check the state of returned backups to prevent cheating. They also mention a BOLT PR for backups.

✉️ Message by Peter Todd on 16/08/2023: The author disagrees with the necessity and potential dangers of fraud proofs in Lightning Network, suggesting a different approach and highlighting a potential use case for a “latest state backup” oracle scheme. They also discuss the benefits and drawbacks of Phoenix’s approach.

✉️ Message by Bastien TEINTURIER on 17/08/2023: A hard penalty may be appropriate for a paid service, but designing payment for it is not easy and users may not be willing to pay. Phoenix should inform users if something goes wrong.

✉️ Message by Thomas Voegtlin on 17/08/2023: Bastien is not interested in fraud proofs, but Thomas argues they are not dangerous and suggests using existing messages for backup data.

✉️ Message by Bastien TEINTURIER on 17/08/2023: The sender is disappointed that the recipient is not interested in fraud proofs for a mobile wallet. They discuss the dangers and complexities involved in implementing this feature.

✉️ Message by SomberNight on 17/08/2023: Mobile wallet providers are unlikely to cheat because the mobile wallet can check for any attempts and the provider risks reputation loss. A peer backup solution could be implemented by any node, allowing users to store backups with them. The reputation argument may not hold up for random nodes, but for hardcoded nodes like ACINQ, it is sufficient. The idea of symmetric resumable channels is also proposed.

✉️ Message by Bastien TEINTURIER on 18/08/2023: The argument that reputation loss prevents cheating doesn’t hold up if users can connect to arbitrary nodes. A more complex protocol may be needed.

✉️ Message by Thomas Voegtlin on 18/08/2023: The writer argues that the loss of reputation is not a sufficient deterrent for wallet providers to cheat, especially if users can open channels with arbitrary nodes. They suggest considering a more decentralized model.

✉️ Message by Thomas Voegtlin on 30/08/2023: Proposal for symmetric peer backups in resumable channels. Issue: if Alice loses state, Bob may disconnect. Solution: Alice writes Bob’s state commitment on-chain to prevent forgetting.

Follow Lightning Mailing List (npub1j3t…4gll) 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