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,
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
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
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
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
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
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
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
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
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
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
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)),
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
Hi Joost,
On Mon, Dec 20, 2021 at 5:02 AM Joost Jager wrote:
> Hi fiatjaf and peter,
>
> On Sat, Dec 18, 2021 at 2:08 PM fiatjaf wrote:
>
>> As a temporary solution, I suggest taking a look at
>> https://github.com/fiatjaf/lnurl-rfc/blob/luds/18.md. The idea is that
&
Good morning, Joost.
As a temporary solution, I suggest taking a look at
https://github.com/fiatjaf/lnurl-rfc/blob/luds/18.md. The idea is that you
can either provide
- a lone pubkey (to be used for manually identifying the payer later if
necessary);
- a domain-specific pubkey along
15 matches
Mail list logo
