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

2018-06-25 Thread René Pickhardt via Lightning-dev
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] W3C Web Payments Working Group / Payment Request API

2018-08-23 Thread René Pickhardt via Lightning-dev
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] Measuring centrality of nodes in LN graph

2018-08-27 Thread René Pickhardt via Lightning-dev
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

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

2018-07-22 Thread René Pickhardt via Lightning-dev
, 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

2018-07-22 Thread René Pickhardt via Lightning-dev
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

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

2018-03-01 Thread René Pickhardt via Lightning-dev
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

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

2018-03-13 Thread René Pickhardt via Lightning-dev
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] New form of 51% attack via lightning's revocation system possible?

2018-03-13 Thread René Pickhardt via Lightning-dev
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] Fwd: Opening channels with neighbors for cost/connectivity benefit

2018-03-28 Thread René Pickhardt via Lightning-dev
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

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

2018-11-16 Thread René Pickhardt via Lightning-dev
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] Strawman BOLT11 static "offer" format using probes.

2018-11-16 Thread René Pickhardt via Lightning-dev
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

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-10 Thread René Pickhardt via Lightning-dev
Dear Rusty, thanks for the initiative. You suggested in your paragraph "messages changes during splicing" during splicing to duplicate each commitment transaction. One which spends the old funding tx and one which spends the spliced tx. I believe this can be simplified. Though I think my workflow

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

2019-01-21 Thread René Pickhardt via Lightning-dev
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] lightning-c RPC

2019-01-22 Thread René Pickhardt via Lightning-dev
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] Colored coins or non-fungible tokens

2018-12-04 Thread René Pickhardt via Lightning-dev
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

2018-11-29 Thread René Pickhardt via Lightning-dev
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] Penalty tx and RBF

2018-11-23 Thread René Pickhardt via Lightning-dev
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

2018-11-20 Thread René Pickhardt via Lightning-dev
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] [META] Organization of 1.1 Spec Effort

2018-11-26 Thread René Pickhardt via Lightning-dev
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] 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)

2019-03-28 Thread René Pickhardt via Lightning-dev
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

2019-03-28 Thread René Pickhardt via Lightning-dev
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] Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0

2019-03-05 Thread René Pickhardt via Lightning-dev
Hey everyone, In this mail I introduce the Just in Time Routing schema (aka JIT Routing). Its main idea is to mitigate the disadvantages from our current source based routing (i.e.: guessing a route that will work in the sense that it has enough liquidity in each channel) and make the routing

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

2019-03-15 Thread René Pickhardt via Lightning-dev
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

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

2019-03-20 Thread René Pickhardt via Lightning-dev
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

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

2019-01-24 Thread René Pickhardt via Lightning-dev
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 and the semantic web

2019-01-28 Thread René Pickhardt via Lightning-dev
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] [PROPOSAL]: FAST - Forked Away Simultaneous Transactions

2019-06-25 Thread René Pickhardt via Lightning-dev
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

[Lightning-dev] Congestion and Flow control for Multipath Routing

2019-07-15 Thread René Pickhardt via Lightning-dev
Dear fellow BOLT devs, in this mail I want to suggest a congestion and flow control mechanism to improve the speed and reliability of multi path routing schemes. This is the first of a couple of emails that I will write in the following weeks as I have used my break in hospital not only to

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

2019-12-23 Thread René Pickhardt via Lightning-dev
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] Few questions

2020-02-09 Thread René Pickhardt via Lightning-dev
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] Direct Message draft

2020-02-20 Thread René Pickhardt via Lightning-dev
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] Research on proactive fee free channel rebalancing in the friend of a friend network / and roadmap for a protocol extension

2020-01-07 Thread René Pickhardt via Lightning-dev
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

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

2020-05-05 Thread René Pickhardt via Lightning-dev
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] Collaborated stealing. What happens when the final recipient discloses the pre-image

2020-07-17 Thread René Pickhardt via Lightning-dev
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

2020-06-17 Thread René Pickhardt via Lightning-dev
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] bLIPs: A proposal for community-driven app layer and protocol extension standardization

2021-06-30 Thread René Pickhardt via Lightning-dev
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

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

2021-07-10 Thread René Pickhardt via Lightning-dev
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

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

2021-04-06 Thread René Pickhardt via Lightning-dev
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

2021-03-18 Thread René Pickhardt via Lightning-dev
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

2021-03-17 Thread René Pickhardt via Lightning-dev
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