[Lightning-dev] Possible Attack IF we add BOTH upfront AND negative routing fees to the Lightning Network

Happy new year dear fellow Lightning Network Developers, last month I have made a small observation why we probably should at most progress EITHER with `negative fees` [1] OR `upfront fees` [2] but not with BOTH as adding both features to the protocol would result in a potentially lucrative

Re: [Lightning-dev] Fee Ratecards (your gateway to negativity)

Dear Lisa and lightning developers, thank you for your contribution and ideas to the problem of increasing reliability to the payment deliver process by having balanced channels and providing liquidity where necessary. This is at least how I understand your intentions of the proposal. I will just

Re: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

%20pairs.ipynb > > Thanks, > Matt > > On 9/22/22 2:40 AM, René Pickhardt via Lightning-dev wrote: > > Good morning fellow Lightning Developers, > > > > I am pleased to share my most recent research results [1] with you. They > may (if at all) only have a > > sm

[Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

Good morning fellow Lightning Developers, I am pleased to share my most recent research results [1] with you. They may (if at all) only have a small impact on protocol development / specification but are actually mainly of concern to node operators and LSPs. I still thought they may be relevant

[Lightning-dev] Supporting a custodial user who wishes to withdraw all sats from the account...

Dear fellow Lightning Developers, I was recently on an event where the visitors have been gifted 10k sats on a custodial wallet. They could spend those sats via some web interface and an NFC card. During the event I was contacted by several plebs who were confused about one particular thing: It

Re: [Lightning-dev] Preliminary Hidden Lightning Network Analysis

Dear Tony, Thank you for putting emphasis on this. I was actually waiting for someone to publicly exploit this. > The reason this is possible is because [...] currently channel IDs are > based on UTXO's. Scid aliases may be the biggest benefit here, but the use > of `unknown_next_peer` ,

[Lightning-dev] Principle Limitations to the reliability of the Lightning Network Protocol

Dear fellow lightning developers, please note my recent blog article titled "Price of Anarchy from selfish routing strategies on the Lightning Network" [1] where we investigate how the selfish behavior of nodes sending Bitcoin over the Lightning Network may lead to higher drain on channels which

[Lightning-dev] Invitation to test our research on probabilistic and optimal payment flows. I made it quick & easy for you (:

Dear fellow lightning developers, last week I have started a new repository [0] where I maintain a python package that can be used to test (and more importantly simulate) the improvements to payment delivery that we have suggested over the last years (c.f. [1][2][3]). I kindly invite you to check

Re: [Lightning-dev] Code for sub second runtime of piecewise linarization to quickly approximate the minimum convex cost flow problem (makes fast multi part payments with large amounts possible)

Dear Carsten and fellow lightning developers, thanks for going into such detail and discovering some of the minor inaccuracies of my very rough piecewise linearization! On Mon, Mar 14, 2022 at 1:53 PM Carsten Otto wrote: > 1.2) The Mission Control information provided by lnd [...] > > I think

Re: [Lightning-dev] Code for sub second runtime of piecewise linarization to quickly approximate the minimum convex cost flow problem (makes fast multi part payments with large amounts possible)

Dear Carsten, Martin and fellow lightning developers, first of all thank you very much for independently verifying and acknowledging my recent findings about the runtime of finding a pieceweise linearized approximation to the min cost flow problem, for working on integrating them into lnd-manageJ

[Lightning-dev] Code for sub second runtime of piecewise linarization to quickly approximate the minimum convex cost flow problem (makes fast multi part payments with large amounts possible)

Dear fellow Lightning Developers, I am pleased (and a bit proud) to be able to inform you that I finally found a quick way to approximate the slow minimum convex cost flow computation. This is necessary for optimally reliable and cheap payment flows [0] to deliver large multi part payments over

Re: [Lightning-dev] Route reliability<->fee trade-off control parameter

Dear Joost, First I am happy that you also agree that reliability can and should be expressed as a probability as discussed in [0]. The problem that you address is that of feature engineering[1]. Which consists of two (or even more) steps: 1.) Feature selection: That means in payment delivery

Re: [Lightning-dev] Handling nonzerobasefee when using Pickhard-Richter algo variants

Dear ZmnSCPxj, thank you very much for this mail and in particular the openess to tinker about a protocol change with respect to the transport layer of HTLCs / PTLCs! I fully agree that we should think about adopting our onion transport layer in a way that supports local payment splits and merges

[Lightning-dev] Do we really want users to solve an NP-hard problem when they wish to find a cheap way of paying each other on the Lightning Network?

Dear fellow lightning developers, with a mixture of shock and disbelief I have been following the (semi) public discussions for the last 6 weeks and the reaction of some companies / people that reached out to me. I have to say I am really surprised by the amount of hesitation that - despite

Re: [Lightning-dev] Proposal for an invoice pattern with an embedded Bitcoin onchain address

Hi, I am sorry to hear you had trouble with payment pathfinding. However if I understand your suggestion correctly I think the proposed functionality already exists in a very similar way in today's invoices with a mechanism called fallback address. The main difference seems to be that the

Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

Hey everyone, just for reference when I was new here (and did not understand the processes well enough) I proposed a similar idea (called LIP) in 2018 c.f.: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001367.html I wonder what exactly has changed in the reasoning by

[Lightning-dev] Lightning Network Protocol Suite Diagram - Request for feedback

Dear fellow Lightning Developers, as you all probably know Andreas, Roasbeef and I are working on writing the book "Mastering the Lightning Network" and I am happy to say that there has been quite some progress over the last 18 months. In Particular it lead to a diagram of the Lightning Network

Re: [Lightning-dev] Towards more reliable payment path finding via probabilistic modeling the uncertainty of channel balance

aths are pre-filtered based on the probability of payment success, > and then the final path is selected along the lines of the currently > deployed fee rate/CLTV risk assessment? > > Kind Regards, > > Elias > > On 17 Mar 2021, at 13:50, René Pickhardt via Lightning-dev wrote: > >

[Lightning-dev] Towards more reliable payment path finding via probabilistic modeling the uncertainty of channel balance

Dear fellow Lightning Network developers, I am very pleased to share with you some research progress [0] with respect to achieving better payment path finding and a better reliability of the payment process. TL;DR summary: In payment (multi)path finding use the (multi)paths with the highest

Re: [Lightning-dev] Collaborated stealing. What happens when the final recipient discloses the pre-image

Hey Ankit, The lightning network sees the possession of a preimage as a proof of payment. And I believe everyone agrees that a court should rule in favor of A forcing E to deliver the good or reimburse A. The reason is that possession of the preimage matching the signed payment hash from E is a

[Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

Hey everyone and of course good morning ZmnSCPxj (: about 11 months ago I discovered a potential blackmail attack with HTLCs after answering this question on stack exchange (c.f https://bitcoin.stackexchange.com/questions/89232/why-is-my-spendable-msat-much-lower-than-msatoshi-to-us/89235#89235).

Re: [Lightning-dev] Force close of channel with unresolved htlc

Dear Subhra, as discussed bilaterally and after clarification of your question the situation is as follows: Let us assume A and B have a channel in which A has 4 tokens and B has 6 tokens Now A offers an HTLC with the amount of 2 tokens and B accepts (receives) the offer then A and B both have

Re: [Lightning-dev] Direct Message draft

Hey Rusty, I was very delighted to read your proposal. But I don't see how you prevent message spam. If I understand you correctly you suggest that I can communicate to any node along a path of peer connections (not necessarily backed by payment channels but kind of only known through channel

Re: [Lightning-dev] Few questions

Good Morning Cezary, you might want to direct questions about understanding the lightning network protocol like yours to https://bitcoin.stackexchanage.com as this mailinglist is more devoted towards driving the development of the protocol. Anyway here are the answers to your questions 2 and 3

Re: [Lightning-dev] Research on proactive fee free channel rebalancing in the friend of a friend network / and roadmap for a protocol extension

Good morning ZmnSCPxj, and list, the answer to your question is absolutely yes and we can can achieve this actually in a very simple and elegant way. Please find attached a clear and simple adaption of the algorithm described from the paper for a general multipath payment and a small python code

[Lightning-dev] Research on proactive fee free channel rebalancing in the friend of a friend network / and roadmap for a protocol extension

Dear fellow Lightning Developers, today my research paper (together with Mariusz Nowostawski) "*Imbalance measure and proactive channel rebalancing algorithm for the Lightning Network*" was published on arxiv: https://arxiv.org/abs/1912.09555 The LaTeX project as well as the code for the

Re: [Lightning-dev] [PROPOSAL]: FAST - Forked Away Simultaneous Transactions

Hey Ugam, I like the very clearly communicated idea and the fact that we can do crazy stuff with the filler of the onions. I have two concerns / questions: 1.) In pathfinding we actually try to make payments smaller (like moving to AMP) instead of combining payments. I think it was shown several

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

Dear ZmnSCPxj and fellow lightning developers, I want to point out two things and make a suggestion for a new gossip message. A good pruning heuristic is "channel capacity", which can be checked > onchain (the value of the UTXO backing the channel is the channel capacity). > It is good to keep

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

Dear Pierre-Marie and fellow lightning developers, I really like that suggestion. In the context of JIT routing I was tinkering about the same idea (is it possible for sending nodes to only know a small part of the network - for example the friend of a friend network - to save Hardware / gossip

[Lightning-dev] I just released more than 200 slides trying to give an Overview of BOLT 1.0 for beginners. Feedback welcome!

Hey everyone, as you know I am just a mathematician and not a cryptographer by training who is interested and amazed by the Lightning Network Protocol. I joined this open source effort pretty late (in the beginning of 2018) and tried to catch up ever since. At that time reading the BOLTs (despite

[Lightning-dev] Potential Privacy issue with dual funded channels

Hey everyone, during the spec meeting we have discussed intensively about dual funded channels and potential game theory with the fees however I now believe that we missed out another important crucial part which is the privacy of the node providing liquidity. While I have not seen a concrete

Re: [Lightning-dev] Lightning and the semantic web

Dear Melvin, I believe the scheme lightning: should only apply * for payments in the form of bolt11 strings * to identifiy nodes like lightning:node_id@ipaddr:port * maybe to identify channels (look up the short_channel_id of the form of a triple separated by the letterx.

Re: [Lightning-dev] Lightning and the semantic web

Dear Melvin, I believe the vocabulary is not consistent across implementations. For example if you look at c lightning there is no such command `describegraph` but there are the two commands `listnodes` and `listchannels` which should give the same information. For both I have attached a sample

Re: [Lightning-dev] lightning-c RPC

Hey Alex, I think this is currently not being implemented. Also there is a mailinglist particularly for issues related to c-lightning at: https://lists.ozlabs.org/listinfo/c-lightning and of course issues like this could also be asked in the bug tracker at:

Re: [Lightning-dev] Lightning and the semantic web

Dear Melvin, have you looked into the W3C Payment Group? https://www.w3.org/TR/payment-request/ The entire field of semantic web kind of originated from W3C and they are working on a recommendation for browser vendors to enable a low level payment API. Also there is LightningJoule that builds on

Re: [Lightning-dev] Colored coins or non-fungible tokens

Dear Joao, there are the people from BHB Networks (in Itally) working on colored coins for Bitcoin and Lightning. The main contributor seems to be Alekos Filini. As far as I understand there is quite some progress. You can find more information in their spec repo at:

Re: [Lightning-dev] Reason for having HMACs in Sphinx

Hey CJP, I am still not 100% through the SPHINX paper so it would be great if at least another pair of eyes could lookt at this. However from the original SPHINX paper I quote: "Besides extracting the shared key, each mix has to be provided with authentic and confidential routing information to

Re: [Lightning-dev] [META] Organization of 1.1 Spec Effort

Hey Rusty, No matter how we agree for the process I suggest to create a wiki page on which we make it transparent and link to it from README.md. The current process was new to me and I think one cannot expect newcomers to read through the entire Mailinglist. As soon as we have an agreement I

Re: [Lightning-dev] Penalty tx and RBF

Hey Cezary, sorry I misread your initial question. I thought you where referring to the (probably bigger problem) of getting the commitment transaction to be mined because RBF does not work. But if we assume that your channel partner published an outdated commitment transaction which got mined

Re: [Lightning-dev] Base AMP

Hey List, as this base AMP proposal seems pretty small I just started to write this up to make a PR for BOLT04 and BOLT11. While doing my write up I realize that there are smaller things that I would want to verify / double check and propose with you. ## Verifying: 1.) I understand the receiving

Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.

Dear Rusty, I am not getting this proposal (maybe I am lacking some technical basic understandings) however I decided to ask more questions in order to complete my onboarding process faster and hope this is fine. My problem starts with the fact that I can't find the term "lightning probe

[Lightning-dev] Proposal to include some form of best effort routing, fragmentation and local AMP

Good morning list, in Adelaide I had a long conversation with another participant who complained that slow payments and failing payments are still a major UX issue for people that try to use the lightning network. While I believe this is a very valid point and we might want to think heavily about

Re: [Lightning-dev] Measuring centrality of nodes in LN graph

Hey Kulpreet, thanks for this nice overview article! I have just today implemented a first draft for the c-lightning autopilot [0]. I have implemented 4 heuristics to select nodes to which one could connect. On of those [1] samples from the nodes that contribute to the high diameter. This

[Lightning-dev] W3C Web Payments Working Group / Payment Request API

Hey lightning devs, I was wondering if any of the companies here are members of W3C and if anyone here could be member of the W3C Web Payments Working Group (c.f.: https://www.w3.org/Payments/WG/ )? According to this mail https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March.txt

Re: [Lightning-dev] proposal for Lightning Network improvement proposals

, 2018, 6:45 AM René Pickhardt via Lightning-dev < > lightning-dev@lists.linuxfoundation.org> wrote: > >> Hey everyone, >> >> in the grand tradition of BIPs I propose that we also start to have our >> own LIPs (Lightning Network Improvement proposals) >> >

[Lightning-dev] proposal for Lightning Network improvement proposals

Hey everyone, in the grand tradition of BIPs I propose that we also start to have our own LIPs (Lightning Network Improvement proposals) I think they should be placed on the github.com/lightning account in a repo called lips (or within the lightning rfc repo) until that will happen I created a

[Lightning-dev] Including a Protocol for splicing to BOLT

Hey everyone, I found a mail from 6 month ago on this list ( c.f.: https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-December/000865.html ) in which it was stated that there was a plan to include a splicing protocol as BOLT 1.1 (On a side node I wonder weather it would make more

[Lightning-dev] Fwd: Opening channels with neighbors for cost/connectivity benefit

Sorry I sent this mail by accident only to Karan. -- Forwarded message - From: René Pickhardt Date: Di., 27. März 2018 11:10 Subject: Re: [Lightning-dev] Opening channels with neighbors for cost/connectivity benefit To: Karan Verma

Re: [Lightning-dev] New form of 51% attack via lightning's revocation system possible?

sical doublespend > attack in which invalidated spends have to happen after the fork > started, and the attacker just filters them from its fork. > > But as I said before, if we can't count on there not being a 51% > attacker, then things are pretty much broken anyway :-) > > Ch

[Lightning-dev] New form of 51% attack via lightning's revocation system possible?

Hey everyone, disclaimer: as mentioned in my other mail ( https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001065.html ) I am currently studying the revocation system of duplex micropayment channels in detail but I am also pretty new to the topic. So I hope the attack I am

Re: [Lightning-dev] Pinging a route for capacity

Hey everyone, disclaimer I am new here and have not a full understanding of the complete specs yet - however since I decided to participate in lighting dev I will just be brave and try to add my ideas on the problem jimpo posed. So even in case by ideas are complete bs please just tell me in a