lightning-dev  

Messages by Thread

• [Lightning-dev] lnurl to enable payer/payee interactions Anton Kumaigorodskiy
  • Re: [Lightning-dev] lnurl to enable payer/payee interactions ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] lnurl to enable payer/payee interactions Anton Kumaigorodskiy
  • Re: [Lightning-dev] lnurl to enable payer/payee interactions ZmnSCPxj via Lightning-dev
• [Lightning-dev] Routing fees under custodial conditions (was: Mandatory "d" or "h" UX issues) ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Routing fees under custodial conditions (was: Mandatory "d" or "h" UX issues) Félix-Antoine Paradis
• [Lightning-dev] Mandatory "d" or "h" UX issues Francis Pouliot
  • Re: [Lightning-dev] Mandatory "d" or "h" UX issues Olaoluwa Osuntokun
  • Re: [Lightning-dev] Mandatory "d" or "h" UX issues Félix-Antoine Paradis
  • Re: [Lightning-dev] Mandatory "d" or "h" UX issues Rusty Russell
  • Re: [Lightning-dev] Mandatory "d" or "h" UX issues Giovanni P
• [Lightning-dev] LightningWiki.net - community effort to collect information, input greatly appreciated Abel Lykens via Lightning-dev
• [Lightning-dev] Need Updates on Lightning Network Van Ezquer via Lightning-dev
• [Lightning-dev] Lite client considerations for Lightning Implementations Chris Stewart
  • Re: [Lightning-dev] Lite client considerations for Lightning Implementations Fabrice Drouin
• [Lightning-dev] Reuse of payment_hash in lightning invoices Andrea RASPITZU
  • Re: [Lightning-dev] Reuse of payment_hash in lightning invoices ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Reuse of payment_hash in lightning invoices Andrea RASPITZU
  • Re: [Lightning-dev] Reuse of payment_hash in lightning invoices Jose Manuel Arenillas
• [Lightning-dev] Quick analysis of channel_update data Fabrice Drouin
  • Re: [Lightning-dev] Quick analysis of channel_update data Christian Decker
  • Re: [Lightning-dev] Quick analysis of channel_update data Fabrice Drouin
  • Re: [Lightning-dev] Quick analysis of channel_update data Fabrice Drouin
  • Re: [Lightning-dev] Quick analysis of channel_update data ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Quick analysis of channel_update data Fabrice Drouin
  • Re: [Lightning-dev] Quick analysis of channel_update data Rusty Russell
  • Re: [Lightning-dev] Quick analysis of channel_update data Christian Decker
  • Re: [Lightning-dev] Quick analysis of channel_update data Fabrice Drouin
  • Re: [Lightning-dev] Quick analysis of channel_update data Christian Decker
  • Re: [Lightning-dev] Quick analysis of channel_update data Matt Corallo
  • Re: [Lightning-dev] Quick analysis of channel_update data Rusty Russell
  • Re: [Lightning-dev] Quick analysis of channel_update data Fabrice Drouin
  • Re: [Lightning-dev] Quick analysis of channel_update data Rusty Russell
  • Re: [Lightning-dev] Quick analysis of channel_update data Fabrice Drouin
  • Re: [Lightning-dev] Quick analysis of channel_update data Rusty Russell
• [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Will Yager
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Alexander Leishman
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Alexander Leishman
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Tamas Blummer
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network James Asefa
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Tamas Blummer
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Tamas Blummer
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network CJP
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network CJP
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network CJP
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network CJP
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network David A. Harding
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Lloyd Fournier
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network David A. Harding
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Corné Plooy via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Rusty Russell
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Corné Plooy via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Lloyd Fournier
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Lloyd Fournier
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • [Lightning-dev] An Argument For Single-Asset Lightning Network Lawrence Deacon
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Lawrence Deacon
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Lawrence Deacon
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network Lloyd Fournier
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network kostadin rangelov
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network kostadin rangelov
  • Re: [Lightning-dev] An Argument For Single-Asset Lightning Network kostadin rangelov
• [Lightning-dev] visual identification of payee node id Pavol Rusnak via Lightning-dev
  • Re: [Lightning-dev] visual identification of payee node id William Casarin
  • Re: [Lightning-dev] visual identification of payee node id Maximillian George
  • Re: [Lightning-dev] visual identification of payee node id Eugene via Lightning-dev
  • Re: [Lightning-dev] visual identification of payee node id ZmnSCPxj via Lightning-dev
• Re: [Lightning-dev] Data piggybacking within the payment_preimage for offline payments in wallets ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Data piggybacking within the payment_preimage for offline payments in wallets Jose Femenias
  • Re: [Lightning-dev] Data piggybacking within the payment_preimage for offline payments in wallets ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Data piggybacking within the payment_preimage for offline payments in wallets ZmnSCPxj via Lightning-dev
• [Lightning-dev] Proposal: Unspecified BOLT Protocol Extensions ZmnSCPxj via Lightning-dev
• [Lightning-dev] Data piggybacking within the payment_preimage for offline payments in wallets JOSE FEMENIAS CAÑUELO
  • [Lightning-dev] Data piggybacking within the payment_preimage for offline payments in wallets Jose Femenías Cañuelo
  • Re: [Lightning-dev] Data piggybacking within the payment_preimage for offline payments in wallets ZmnSCPxj via Lightning-dev
• [Lightning-dev] Minisketch and lightning gossip Rusty Russell
  • Re: [Lightning-dev] Minisketch and lightning gossip Pieter Wuille
• [Lightning-dev] Spec Meeting: Tuesday, January 8, 2019 at 19:00:00 UTC (~1hr) Rusty Russell
• [Lightning-dev] OpenCAP alias integrations with invoices/destination Lane Wagner
  • Re: [Lightning-dev] OpenCAP alias integrations with invoices/destination ZmnSCPxj via Lightning-dev
• Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol Trey Del Bonis
  • Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol Trey Del Bonis
  • Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol Trey Del Bonis
  • Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol Trey Del Bonis
  • [Lightning-dev] Fwd: Fulgurite: ideas for making a more flexible Lightning Network protocol Trey Del Bonis
• [Lightning-dev] Colored coins or non-fungible tokens Joao Joyce
  • Re: [Lightning-dev] Colored coins or non-fungible tokens René Pickhardt via Lightning-dev
• [Lightning-dev] Funds locked in channel and MAX_HTLC Cezary Dziemian
  • Re: [Lightning-dev] Funds locked in channel and MAX_HTLC Rusty Russell
• [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Matt Corallo
  • Re: [Lightning-dev] [bitcoin-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Bob McElrath
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Rusty Russell
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Matt Corallo
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Rusty Russell
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Matt Corallo
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Rusty Russell
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Johan Torås Halseth
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Matt Corallo
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Johan Torås Halseth
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Matt Corallo
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Jeremy
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Johan Torås Halseth
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) David A. Harding
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Johan Torås Halseth
  • Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) David A. Harding
• [Lightning-dev] Reason for having HMACs in Sphinx Corné Plooy via Lightning-dev
  • Re: [Lightning-dev] Reason for having HMACs in Sphinx René Pickhardt via Lightning-dev
  • Re: [Lightning-dev] Reason for having HMACs in Sphinx Christian Decker
  • Re: [Lightning-dev] Reason for having HMACs in Sphinx Corné Plooy via Lightning-dev
  • Re: [Lightning-dev] Reason for having HMACs in Sphinx ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Reason for having HMACs in Sphinx Corné Plooy via Lightning-dev
  • Re: [Lightning-dev] Reason for having HMACs in Sphinx ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Reason for having HMACs in Sphinx Corné Plooy via Lightning-dev
  • Re: [Lightning-dev] Reason for having HMACs in Sphinx Christian Decker
  • Re: [Lightning-dev] Reason for having HMACs in Sphinx Rusty Russell
  • Re: [Lightning-dev] Reason for having HMACs in Sphinx Christian Decker
  • Re: [Lightning-dev] Reason for having HMACs in Sphinx Rusty Russell
• [Lightning-dev] Dual Funding Proposal lisa neigut
  • Re: [Lightning-dev] Dual Funding Proposal ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Dual Funding Proposal lisa neigut
  • Re: [Lightning-dev] Dual Funding Proposal Rusty Russell
  • Re: [Lightning-dev] Dual Funding Proposal Rusty Russell
  • Re: [Lightning-dev] Dual Funding Proposal ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] Dual Funding Proposal Rusty Russell
  • Re: [Lightning-dev] Dual Funding Proposal lisa neigut
  • Re: [Lightning-dev] Dual Funding Proposal Rusty Russell
• [Lightning-dev] [DRAFT] Multi-cell-hop onion with TLV (and example for multi-part-payment) Rusty Russell
  • Re: [Lightning-dev] [DRAFT] Multi-cell-hop onion with TLV (and example for multi-part-payment) ZmnSCPxj via Lightning-dev
  • Re: [Lightning-dev] [DRAFT] Multi-cell-hop onion with TLV (and example for multi-part-payment) Rusty Russell
  • Re: [Lightning-dev] [DRAFT] Multi-cell-hop onion with TLV (and example for multi-part-payment) ZmnSCPxj via Lightning-dev
• [Lightning-dev] [META] Organization of 1.1 Spec Effort Rusty Russell
  • Re: [Lightning-dev] [META] Organization of 1.1 Spec Effort Matt Corallo
  • Re: [Lightning-dev] [META] Organization of 1.1 Spec Effort René Pickhardt via Lightning-dev
  • Re: [Lightning-dev] [META] Organization of 1.1 Spec Effort Peter Todd
  • Re: [Lightning-dev] [META] Organization of 1.1 Spec Effort Matt Corallo
  • Re: [Lightning-dev] [META] Organization of 1.1 Spec Effort Rusty Russell
• [Lightning-dev] Penalty tx and RBF Cezary Dziemian
  • Re: [Lightning-dev] Penalty tx and RBF René Pickhardt via Lightning-dev
  • Re: [Lightning-dev] Penalty tx and RBF Cezary Dziemian
  • Re: [Lightning-dev] Penalty tx and RBF René Pickhardt via Lightning-dev
  • Re: [Lightning-dev] Penalty tx and RBF Cezary Dziemian
  • Re: [Lightning-dev] Penalty tx and RBF ZmnSCPxj via Lightning-dev
• [Lightning-dev] lookupinvoice Sarat G
  • Re: [Lightning-dev] lookupinvoice Rusty Russell
  • Re: [Lightning-dev] lookupinvoice Sarat G
• [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Rusty Russell
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Matt Corallo
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Matt Corallo
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Rusty Russell
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Matt Corallo
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Rusty Russell
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Matt Corallo
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Rusty Russell
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Matt Corallo
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment David A. Harding
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Matt Corallo
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Joost Jager
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Joost Jager
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Rusty Russell
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Joost Jager
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Rusty Russell
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Joost Jager
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Rusty Russell
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Joost Jager
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment David A. Harding
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Joost Jager
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Matt Corallo
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Joost Jager
  • Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment Matt Corallo
• [Lightning-dev] Invoice Address Format Varunram Ganesh
  • Re: [Lightning-dev] Invoice Address Format Rusty Russell
• [Lightning-dev] Rendez-vous proposal with ephemeral key switch Christian Decker
• [Lightning-dev] Açai: a backup protocol for Lightning Network wallets Margherita Favaretto
• [Lightning-dev] RBF and dual-fund interactions ZmnSCPxj via Lightning-dev

• Earlier messages
• Later messages