lightning-dev  

Messages by Thread

• • Re: [Lightning-dev] complementing lightning with with a discreet physical delivery protocol? VzxPLnHqr via Lightning-dev
  • Re: [Lightning-dev] complementing lightning with with a discreet physical delivery protocol? ZmnSCPxj via Lightning-dev
• [Lightning-dev] On the recent softforks survey, forget to fulfill my answer! Antoine Riard
• [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages Antoine Riard
  • Re: [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages Antoine Riard
  • Re: [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages David A. Harding
  • Re: [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages Antoine Riard
  • Re: [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages Michael Folkson
  • Re: [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages Antoine Riard
• [Lightning-dev] Tuesday’s IRC workshop on L2 onchain support Michael Folkson
• [Lightning-dev] Reminder: Transaction relay workshop on IRC Libera - Tuesday 15th June 19:00 UTC Antoine Riard
• [Lightning-dev] BIP118 confusion / SIGHASH_NOINPUT is now SIGHASH_ANYPREVOUT (i think) Ryan Grant
  • Re: [Lightning-dev] BIP118 confusion / SIGHASH_NOINPUT is now SIGHASH_ANYPREVOUT (i think) Ryan Grant
• [Lightning-dev] Dropping Tor v2 onion services from node_announcement darosior via Lightning-dev
  • Re: [Lightning-dev] Dropping Tor v2 onion services from node_announcement Peter Todd
  • Re: [Lightning-dev] Dropping Tor v2 onion services from node_announcement Matt Corallo
  • Re: [Lightning-dev] Dropping Tor v2 onion services from node_announcement Olaoluwa Osuntokun
• [Lightning-dev] YAELBOT Ján Sáreník
• [Lightning-dev] Upgrade on reestablish. Rusty Russell
  • Re: [Lightning-dev] Upgrade on reestablish. Rusty Russell
• [Lightning-dev] On Mempool Funny Games against Multi-Party Funded Transactions Antoine Riard
  • Re: [Lightning-dev] On Mempool Funny Games against Multi-Party Funded Transactions Ján Sáreník
• [Lightning-dev] Making unannounced channels harder to probe Rusty Russell
  • Re: [Lightning-dev] Making unannounced channels harder to probe Joost Jager
  • Re: [Lightning-dev] Making unannounced channels harder to probe Rusty Russell
• [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs Eugene Siegel
  • Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs Bastien TEINTURIER
  • Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs Eugene Siegel
  • Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs Matt Corallo
  • Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs Bastien TEINTURIER
  • Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs Bastien TEINTURIER
  • Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs Eugene Siegel
  • Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs Matt Corallo
• [Lightning-dev] L2s Onchain Support IRC Workshop Antoine Riard
  • Re: [Lightning-dev] L2s Onchain Support IRC Workshop Jeremy
  • Re: [Lightning-dev] L2s Onchain Support IRC Workshop Antoine Riard
  • Re: [Lightning-dev] L2s Onchain Support IRC Workshop Bastien TEINTURIER
• [Lightning-dev] Splicing draft Rusty Russell
• [Lightning-dev] Questions on lightning chan closure privacy Mr. Lee Chiffre
  • Re: [Lightning-dev] Questions on lightning chan closure privacy Mr. Lee Chiffre
  • Re: [Lightning-dev] Questions on lightning chan closure privacy Lloyd Fournier
  • Re: [Lightning-dev] Questions on lightning chan closure privacy ZmnSCPxj via Lightning-dev
• [Lightning-dev] Replacement of invoices to handle stuck payments. Rusty Russell
• [Lightning-dev] Lightning Network Protocol Suite Diagram - Request for feedback René Pickhardt via Lightning-dev
  • Re: [Lightning-dev] Lightning Network Protocol Suite Diagram - Request for feedback Elliot Heitman
• [Lightning-dev] c-lightning release v0.10.0: Neutralizing Fee Therapy Rusty Russell
• [Lightning-dev] Analysis and Probing of Parallel Channels Sergei Tikhomirov
• [Lightning-dev] Towards more reliable payment path finding via probabilistic modeling the uncertainty of channel balance René Pickhardt via Lightning-dev
  • Re: [Lightning-dev] Towards more reliable payment path finding via probabilistic modeling the uncertainty of channel balance Elias Rohrer
  • Re: [Lightning-dev] Towards more reliable payment path finding via probabilistic modeling the uncertainty of channel balance René Pickhardt via Lightning-dev
  • Re: [Lightning-dev] Towards more reliable payment path finding via probabilistic modeling the uncertainty of channel balance Elias Rohrer
• [Lightning-dev] Single Round Trustless Schnorr-based PTLC Idea + Offline LN Payment Demo Matheus Degiovani
• [Lightning-dev] Funding Timeout Recovery proposal Christian Decker
• [Lightning-dev] Rescuing funding mistakes Rusty Russell
• [Lightning-dev] Error Codes for LN Carla Kirk-Cohen
  • Re: [Lightning-dev] Error Codes for LN Rusty Russell
  • Re: [Lightning-dev] Error Codes for LN Carla Kirk-Cohen
• [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming) Joost Jager
  • Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming) ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming) Joost Jager
  • Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming) Antoine Riard
  • Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming) Joost Jager
  • Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming) Joost Jager
  • Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming) Antoine Riard
  • Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming) ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming) Olaoluwa Osuntokun
  • Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming) Joost Jager
  • Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming) Joost Jager
• Re: [Lightning-dev] Pay-for-Elgamal-decryption-key and its application to Anonymous Credentials Joe Miyamoto Philips
  • Re: [Lightning-dev] Pay-for-Elgamal-decryption-key and its application to Anonymous Credentials Joe Miyamoto Philips
• Re: [Lightning-dev] Lightning-dev Digest, Vol 66, Issue 4 Joe Miyamoto Philips
• [Lightning-dev] Pay-for-Elgamal-decryption-key and its application to Anonymous Credentials Joe Miyamoto Philips
  • [Lightning-dev] Pay-for-Elgamal-decryption-key and its application to Anonymous Credentials 宮本丈 via Lightning-dev
  • Re: [Lightning-dev] Pay-for-Elgamal-decryption-key and its application to Anonymous Credentials Lloyd Fournier
• [Lightning-dev] Lightning dice Anthony Towns
  • Re: [Lightning-dev] Lightning dice ZmnSCPxj via Lightning-dev
• [Lightning-dev] PoDLEs revisited Lloyd Fournier
  • Re: [Lightning-dev] PoDLEs revisited ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] PoDLEs revisited Rusty Russell
  • Re: [Lightning-dev] PoDLEs revisited Lloyd Fournier
  • Re: [Lightning-dev] PoDLEs revisited Rusty Russell
  • Re: [Lightning-dev] PoDLEs revisited Lloyd Fournier
  • Re: [Lightning-dev] PoDLEs revisited Rusty Russell
  • Re: [Lightning-dev] PoDLEs revisited Lloyd Fournier
  • Re: [Lightning-dev] PoDLEs revisited Rusty Russell
  • Re: [Lightning-dev] PoDLEs revisited Lloyd Fournier
• [Lightning-dev] Trampoline routing improvements and updates Bastien TEINTURIER
• [Lightning-dev] Battlement: A Quorum Based Design for Lightning Network Key Management Omer Shlomovits
  • Re: [Lightning-dev] Battlement: A Quorum Based Design for Lightning Network Key Management Devrandom
• [Lightning-dev] Covert channel recovery with Oblivious Signatures Lloyd Fournier
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures David A. Harding
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures Lloyd Fournier
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures David A. Harding
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures Lloyd Fournier
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures Lloyd Fournier
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures Ariel Lorenzo-Luaces
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures Lloyd Fournier
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures Lloyd Fournier
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures Lloyd Fournier
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures Lloyd Fournier
  • Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures ZmnSCPxj via Lightning-dev
• [Lightning-dev] Recovery of Lightning channels without backups Lloyd Fournier
  • Re: [Lightning-dev] Recovery of Lightning channels without backups Gijs van Dam
  • Re: [Lightning-dev] Recovery of Lightning channels without backups Lloyd Fournier
  • Re: [Lightning-dev] Recovery of Lightning channels without backups Rusty Russell
  • Re: [Lightning-dev] Recovery of Lightning channels without backups Lloyd Fournier
  • Re: [Lightning-dev] Recovery of Lightning channels without backups Rusty Russell
  • Re: [Lightning-dev] Recovery of Lightning channels without backups Lloyd Fournier
  • Re: [Lightning-dev] Recovery of Lightning channels without backups Rusty Russell
  • Re: [Lightning-dev] Recovery of Lightning channels without backups Rusty Russell
  • Re: [Lightning-dev] Recovery of Lightning channels without backups Lloyd Fournier
  • Re: [Lightning-dev] Recovery of Lightning channels without backups Lloyd Fournier
  • Re: [Lightning-dev] Recovery of Lightning channels without backups Rusty Russell
  • Re: [Lightning-dev] Recovery of Lightning channels without backups David A. Harding
  • Re: [Lightning-dev] Recovery of Lightning channels without backups Lloyd Fournier
  • Re: [Lightning-dev] Recovery of Lightning channels without backups David A. Harding
  • Re: [Lightning-dev] Recovery of Lightning channels without backups Lloyd Fournier
• [Lightning-dev] Lightning Distributed Routing João Valente
  • Re: [Lightning-dev] Lightning Distributed Routing Bastien TEINTURIER
  • Re: [Lightning-dev] Lightning Distributed Routing João Valente
  • Re: [Lightning-dev] Lightning Distributed Routing ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Lightning Distributed Routing João Valente
  • Re: [Lightning-dev] Lightning Distributed Routing ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Lightning Distributed Routing João Valente
• [Lightning-dev] Mitigating Channel Jamming with Stake Certificates Gleb Naumenko
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates Gleb Naumenko
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates Bastien TEINTURIER
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates Andrés G . Aragoneses
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates David A. Harding
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates Lloyd Fournier
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates Gleb Naumenko
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates Lloyd Fournier
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates Antoine Riard
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates Lloyd Fournier
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates Gleb Naumenko
• [Lightning-dev] [c-lightning] v0.9.2 "Now with 0-of-N Multisig" Released lisa neigut
• [Lightning-dev] Minor tweaks to blinded path proposal Rusty Russell
  • Re: [Lightning-dev] Minor tweaks to blinded path proposal Bastien TEINTURIER
  • Re: [Lightning-dev] Minor tweaks to blinded path proposal Rusty Russell
• [Lightning-dev] Lightning Pool: A Non-Custodial Channel Lease Marketplace Olaoluwa Osuntokun
  • Re: [Lightning-dev] Lightning Pool: A Non-Custodial Channel Lease Marketplace ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Lightning Pool: A Non-Custodial Channel Lease Marketplace Olaoluwa Osuntokun
  • Re: [Lightning-dev] Lightning Pool: A Non-Custodial Channel Lease Marketplace ZmnSCPxj via Lightning-dev
• [Lightning-dev] Full Disclosure: CVE-2020-26895 LND "Hodl my Shitsig" Antoine Riard
  • [Lightning-dev] Full Disclosure: CVE-2020-26895 LND "Hodl my Shitsig" Antoine Riard
• [Lightning-dev] CVE-2020-26895: LND Low-S Tx-Relay Standardness Conner Fromknecht
• [Lightning-dev] CVE-2020-26896: LND Invoice Preimage Extraction Conner Fromknecht
• [Lightning-dev] Full Disclosure: CVE-2020-26896 LND "The (un)covert channel" Antoine Riard
• [Lightning-dev] Watchtowers cannot sweep HTLCs if option_anchor_outputs is enabled (regression) SomberNight via Lightning-dev
• Re: [Lightning-dev] Lightning-dev Digest, Vol 62, Issue 14 Bitcoin Error Log
• [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Rusty Russell
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Christian Decker
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Bastien TEINTURIER via Lightning-dev
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Rusty Russell
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Rusty Russell
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Christian Decker
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Rusty Russell
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Christian Decker
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Rusty Russell
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Matt Corallo
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Rusty Russell
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Matt Corallo
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Rusty Russell
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Rusty Russell
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Matt Corallo
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Rusty Russell
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Matt Corallo
  • Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation Rusty Russell
• [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Joost Jager
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Joost Jager
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Joost Jager
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Rusty Russell
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Joost Jager
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Christian Decker
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Joost Jager
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Christian Decker
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Rusty Russell
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Antoine Riard
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Joost Jager
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Bastien TEINTURIER via Lightning-dev
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Joost Jager
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Bastien TEINTURIER via Lightning-dev
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Joost Jager
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Bastien TEINTURIER via Lightning-dev
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Joost Jager
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself Bastien TEINTURIER via Lightning-dev

• Earlier messages
• Later messages