rich1.0Rusty Russell [ARCHIVE] (npub1zw…hkhpx)https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://yabu.me📅 Original date posted:2018-11-15 📝 Original message: 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 nodes). The payer uses a new lightning probe message using the current onion format we use for HTLCs to retreive the complete invoice. The format of the final-hop lightning onion would contain: [whatever-marker-we-need?][128-bit-`p`-field][[type,len,data]+] We would probably define a few optional types to start: 1. quantity: for ordering multiple of an item, default 1. 2. delivery-address: steal from https://www.w3.org/TR/vcard-rdf/#Delivery_Addressing_Properties ? 3. signature: basically a blob so payer can prove it was them. The return lightning message would contain a new bolt11 invoice (perhaps we optimize some fields by copying from the bolt11 offer if they don't appear?), and an additional field: `m` (27) `data_length` 52. Merkle hash of fields payer provided in onion msg above, and the offer `p` value. The payer checks the signature is correct, `m` is correct, and uses the invoice to pay as normal. The bolt11 offer + fields-from-onion + bolt11 invoice + preimage is the complete proof of payment. Refinements ----------- We can generate alternate leaves for the merkle tree (using SHA256(shared-secret | leafnum)) so revealing the `m` value doesn't risk revealing your delivery-address for example. The return needs to list the fields it *didn't* include in the merkle because it didn't accept them (the merchant doesn't want to be bound to conditions it doesn't understand!). We could add a `k` field to the bolt11 offer to allow the final invoice to delegated to a separate key. The default `x` (expiry) field for an offer which does not have an old-style 53-byte `p` field (ie. a "pure" offer) could be infinite. We could merkelize the delivery-address too :) I've handwaved a bit over the detailed format, because there are other things we want to put in the onion padding, and because the return is similar to the "soft-error"/"partial payment ack" proposals. Results ------- This gives us static invoicing, and a single static invoice (without an amount field) can thus be used to approximate "spontaneous" donations, while still providing proof of payment; indeed, providing non-transferrable proof-of-payment since the invoice now commits to the payer-provided signature. It also provides a platform for recurring payments: while we can do this with preimage-is-next-payment_hash, that requires pre-generation and isn't compatible with static invoices. I apologize that this wasn't fleshed out before the summit, but I overestimated the power of Scriptless Scripts so had mentally deferred this. Thanks! Rusty.