Re: [Lightning-dev] Stateless invoices with proof-of-payment

2021-09-21 Thread fiatjaf
g lnurlpay to reduce the delay between invoice issuance and user confirmation to zero, and so on). On Tue, Sep 21, 2021 at 9:41 AM Joost Jager wrote: > On Tue, Sep 21, 2021 at 2:05 PM fiatjaf wrote: > >> What if instead of the payer generating the preimage the payee could >> gene

Re: [Lightning-dev] Stateless invoices with proof-of-payment

2021-09-21 Thread fiatjaf
What if instead of the payer generating the preimage the payee could generate stateless invoices? Basically just use some secret to compute the preimage upon receiving the HTLC, for example: 1. Payer requests an invoice. 2. Payee computes hash = sha256(hmac(local_secret, arbitrary_invoice_id)),

Re: [Lightning-dev] DNS records for LN nodes

2021-09-12 Thread fiatjaf
I think this is a good idea. A very simple change that can improve usability. Anyone can already do this today if they want, by just shoving data into DNS records and telling people to confirm from there, but it would be nice if it was standardized in a bLIP[0] just so everybody does it in the

[Lightning-dev] No more closed channels because of fake HTLCs

2021-08-28 Thread fiatjaf
silly to you, but anything is better than what we have now. In all the suggestions above, the fallback, worst case scenario, is closing the channel. Today we live in the worst case scenario.) Thank you for reading. --- fiatjaf ___ Lightning-dev mailing list

Re: [Lightning-dev] Removing the Dust Limit

2021-08-08 Thread fiatjaf
For the Lightning point, even if the dust limit was removed Lightning would still be trimming any HTLCs below the amount they cost to redeem in fees, so that wouldn't make any difference. Nonetheless I think reason 1 should be enough. 2021-08-08 11:52 (GMT-07:00), Jeremy said: > We should

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

2021-07-02 Thread fiatjaf
If the BIPs can allow very small standards related to a small niche of Lightning usage, then I think they are the place for everything indeed. I'm convinced. Thinking about proposing the LNURL specs as BIPs now, but then I don't know if it will be weird for them to exist alone there, without the

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

2021-07-01 Thread fiatjaf
2021-June/003074.html > [2] > https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster > [3] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html > [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK = Stand

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

2021-06-30 Thread fiatjaf
by immortan 13. lnurl-withdraw 14. lnurl-pay 15. lnurl-channel 16. bitcoin-liquid lightning bridge 17. I thought I had more but apparently I forgot So we have to hunt these people down and make them submit specs. --- fiatjaf 2021-06-30 16:35 (GMT+02:00), "René Pickhardt via Lightning-dev" s

Re: [Lightning-dev] Doubt regarding payment channel capacity

2019-11-14 Thread fiatjaf
Hello, What happens between two peers is no business of others. They can do what you said if they're cooperating, and many other dirty tricks. And that's not a problem at all for other nodes. The only thing they can't do for not is advertise a channel without telling others where it was funded

Re: [Lightning-dev] Trampoline Routing

2019-08-08 Thread fiatjaf
Ok, here's another question/probably-bad-idea: how feasible is it for these trampoline nodes to return the route they've calculated somehow to the original caller so it can cache the route and use it without trampolines the next time? I don't know if caching routes is a good way improve routing

Re: [Lightning-dev] Trampoline Routing

2019-08-05 Thread fiatjaf
Thank you very much. These were very clarifying answers and ramblings. On Monday, August 5, 2019, ZmnSCPxj wrote: > Good morning fiatjaf, > >> No. My question was more like why does Alice decide to build a route that for through T1 and RT2 and not only through one trampoline rout

[Lightning-dev] Fwd: Trampoline Routing

2019-08-05 Thread fiatjaf
we're going to need some hierarchy, but what it's that? Is it required? Anyway, I'm probably missing something, but another way of putting my question would be: why does your example use 2 trampolines instead of 1? On Monday, August 5, 2019, Bastien TEINTURIER wrote: > Good morning fiat

Re: [Lightning-dev] Trampoline Routing

2019-08-02 Thread fiatjaf
Ok, since you seem to imply each question is valuable, here's mine: how does Alice know RT2 has a route to Bob? If she knows that, can she also know T1 has a route to Bob? In any case, why can't she just build her small onion with Alice -> T1 -> Bob? I would expect that to be the most common case,