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
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)),
I think this is a good idea. A very simple change that can improve
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 just so everybody does it in the
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.
Lightning-dev mailing list
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
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
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
>  bLIP = Bitcoin Lightning Improvement Proposal and SPARK = Stand
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.
2021-06-30 16:35 (GMT+02:00), "René Pickhardt via Lightning-dev"
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
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
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
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
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
Mail list logo