Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-15 📝 Original message: Hi all, I want to propose ...
📅 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.
📝 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.