Re: [Lightning-dev] Payee pay fee
ZmnSCPxj writes: > Good morning Rusty, > >> So we need a web way of asking a client to send an invoice or offer over >> HTTPS. Is this a new URI scheme? How would this work? > > I thought that offers would work over LN alone? > > When you first proposed the offers, I thought it was this way: > > 1. Payee gives BOLT12 offer to Payer. > 2. Payer generates a completely new random preimage and computes its hash. > 3. Payer issues a payment along an LN route from Payer to Payee using its > random hash. > 4. At the payee hop, the onion packet contains some identifying information > from the BOLT12 offer. > 5. Payee generates a BOLT11 invoice. > 6. Payee sends back an error packet, which includes the BOLT11 invoice. > 7. Payer receives the error packet that includes the BOLT11 invoice. > 8. Payer pays using the BOLT11 invoice. Yes. But how does the payee know to give the bolt12 offer to the payer? That's the piece that's missing here, which is actually independent. > Intermediate nodes remain unaware of this new feature and do not require > upgrades. That works if we use a fake "payment" like this to get the real invoice. Be nicer to use a real message format though, as it's less overhead for everyone and faster. > A node issuing a BOLT12 offer would implicitly signal its support for this > feature by the simple fact of being able to issue the BOLT12 offer. > A node that can understand a BOLT12 offer implicitly means it supports this > feature. Yes; I think it's early enough that we don't need to cram offers into bolt11 in some backwards compat way, they can be a new thing. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Multi-frame sphinx onion format
ZmnSCPxj writes: > Good morning Christian, Rusty, and list, > You can take this a step further and make the realm 0 byte into a > special type "0" which has a fixed length of 1299 bytes, with the > length never encoded for this special type. It would then define the > next 1299 bytes as the "V", having the format of 64 bytes of the > current hop format (short channel ID, amount, CLTV, 12-byte padding, > HMAC), plus 19*65 bytes as the encrypted form of the next hop data. > This lets us reclaim even the realm byte, removing its overhead by > re-encoding it as the type in a TLV system, and with the special > exception of dropping the "L" for the type 0 (== current realm 0) > case. I disagree that this would be any clearer than the current proposal since we completely lose the separation of payload encoding vs. onion encoding. Let's not mix the concepts of payload and transport onion, please. > In short, drop the concept of 65-byte "frames". > > We could have another special length-not-encoded type 255, which > declares the next 32 bytes as HMAC and the rest of the onion packet as > the data for the next hop. > > The above is not a particularly serious proposal. You had me worried for a second there :-) ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
