Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-02-07 📝 Original message: Olaoluwa Osuntokun ...
📅 Original date posted:2018-02-07
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Protocol Overview
> ==================
> This design can be seen as a generalization of the single, non-interactive
> payment scheme, that uses decoding of extra onion blobs (EOBs?) to encode
> extra data for the receiver. In that design, the extra data includes a
> payment preimage that the receiver can use to settle back the payment. EOBs
> and some method of parsing them are really the only requirement for this
> protocol to work. Thus, only the sender and receiver need to implement this
> feature in order for it to function, which can be announced using a feature
> bit.
OK, so this proposal conflates two things:
1. split payments.
2. expansion of onion space.
We've got a wiki page for #2 which could probably use some love:
https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#using-multiple-hops_data-cells-in-the-onion
For the final hop this may not be necessary, as we have 8 unused bytes
in `next addr`, giving us 20 free bytes.
But why not simplify the proposal: the payment preimage is the XOR of
those 20 bytes (with 12 zero bytes prepended)? And the receiver gives
up to 30 seconds(?) to receive all the parts after the first one.
That means the sender gets dynamic resizing (if they want to split a
payment further, set one to randomness, and XOR that into the other),
the receive has only to remember the combination-so-far.
Cheers,
Rusty.
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Protocol Overview
> ==================
> This design can be seen as a generalization of the single, non-interactive
> payment scheme, that uses decoding of extra onion blobs (EOBs?) to encode
> extra data for the receiver. In that design, the extra data includes a
> payment preimage that the receiver can use to settle back the payment. EOBs
> and some method of parsing them are really the only requirement for this
> protocol to work. Thus, only the sender and receiver need to implement this
> feature in order for it to function, which can be announced using a feature
> bit.
OK, so this proposal conflates two things:
1. split payments.
2. expansion of onion space.
We've got a wiki page for #2 which could probably use some love:
https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#using-multiple-hops_data-cells-in-the-onion
For the final hop this may not be necessary, as we have 8 unused bytes
in `next addr`, giving us 20 free bytes.
But why not simplify the proposal: the payment preimage is the XOR of
those 20 bytes (with 12 zero bytes prepended)? And the receiver gives
up to 30 seconds(?) to receive all the parts after the first one.
That means the sender gets dynamic resizing (if they want to split a
payment further, set one to randomness, and XOR that into the other),
the receive has only to remember the combination-so-far.
Cheers,
Rusty.