Good morning Conner,
> > For a sequence of `type,len,value`, the `type`s must be in ascending order
> > -- not explicitly accepted or rejected. It would be easier to check
> > uniqueness > (the previous rule we accepted) here for a naive parser (keep
> > track of some "minimum allowed type" that
ZmnSCPxj writes:
> The construction we came up with allows multiple rendezvous nodes,
> unlike the HORNET construction that is inherently only a single
> rendezvous node. Perhaps the extra flexibility comes with some
> security degradation?
I don't think this is the case. If I remember
Hi ZmnSCPxj,
Thanks for writing this up! I had started an email, but you beat me to it :)
> 1. For a sequence of `type,len,value`, each `type` must be unique. --
> accepted.
To add to this, it seemed that there was some agreement that repeated fields
should be serialized under a single root
Good morning Rusty,
No particular comment on static offer invoices, but instead various
bikeshedding.
>
> The format of the final-hop lightning onion would contain:
>
> [whatever-marker-we-need?][128-bit-`p`-field][[type,len,data]+]
I think a separate BOLT for the type,len,data would be
Hi all,
I want to propose a method of having reusable BOLT11 "offers" which
provide almost-spontaneous payments as well as not requiring generating
a BOLT11 invoice for each potential sale.
An "offer" has a `p` field of 26 bytes (128 bits assuming top two are 0)
(which is ignored by existing
Good morning list,
In case it was not noticed, I made a pull request for Base AMP:
https://github.com/lightningnetwork/lightning-rfc/pull/511
This is primarily based on what Rusty suggested on-list, with sufficient MUST
and SHOULD.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
While consistency with typical grammar might be desirable, as a made-up word,
wumbo has the opportunity to define its own grammar.
Do we really want to impose normal grammar on wumbo?
We do not want to paint ourselves in a corner if in the future we find we need
the ability to define novel
The link in the original post contains actual descriptions of "wumbo" and
"hidden destinations".
Admittedly, the linked wiki page is not necessarily clear, so I shall describe
them here anyway.
Wumbo is the study of all things wumbological.
I wumbo, you wumbo, he wumbo she wumbo.
Wumboing.
Hi Conner,
thanks for the pointers, looking forward to reading up on the
wrap resistance. I don't quite follow if you're against the
re-wrapping for spontaneous re-routing, or the entire rendez-vous
construction we came up with in Australia. If it's the latter, do
you have an alternative
Hello all,
I'd like to bring up an idea that builds on top of "non-strict" forwarding.
I commented about this on conner's non-strict forwarding lightning-rfc pr,
but it is probably better to discuss it on its own in this list.
A node that forwards non-strictly, is using any of its channels to
10 matches
Mail list logo
