Re: [Lightning-dev] type,len,value standard

2018-11-14 Thread ZmnSCPxj via Lightning-dev
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

Re: [Lightning-dev] Link-level payment splitting via intermediary rendezvous nodes

2018-11-14 Thread Christian Decker
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

Re: [Lightning-dev] type,len,value standard

2018-11-14 Thread Conner Fromknecht
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

Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.

2018-11-14 Thread ZmnSCPxj via Lightning-dev
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

[Lightning-dev] Strawman BOLT11 static "offer" format using probes.

2018-11-14 Thread Rusty Russell
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

Re: [Lightning-dev] Forwarding hints in channel update messages

2018-11-14 Thread Rusty Russell
Joost Jager writes: > 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. The decision was made to allow

Re: [Lightning-dev] Base AMP

2018-11-14 Thread ZmnSCPxj via Lightning-dev
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.

Re: [Lightning-dev] Summary of the Second Lightning Development Summit (2018 Adelaide)

2018-11-14 Thread ZmnSCPxj via Lightning-dev
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

Re: [Lightning-dev] Summary of the Second Lightning Development Summit (2018 Adelaide)

2018-11-14 Thread Pierre
> I wumbo, you wumbo, he wumbo she wumbo. I would respectfully disagree here: pretty sure that's "he wumboes, she wumboes". ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org

Re: [Lightning-dev] Summary of the Second Lightning Development Summit (2018 Adelaide)

2018-11-14 Thread ZmnSCPxj via Lightning-dev
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.

Re: [Lightning-dev] Link-level payment splitting via intermediary rendezvous nodes

2018-11-14 Thread Christian Decker
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

[Lightning-dev] Forwarding hints in channel update messages

2018-11-14 Thread Joost Jager
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