{"type":"rich","version":"1.0","title":"Rusty Russell [ARCHIVE] wrote","author_name":"Rusty Russell [ARCHIVE] (npub1zw…hkhpx)","author_url":"https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-11-15\n📝 Original message:\nHi all,\n\n    I want to propose a method of having reusable BOLT11 \"offers\" which\nprovide almost-spontaneous payments as well as not requiring generating\na BOLT11 invoice for each potential sale.\n\nAn \"offer\" has a `p` field of 26 bytes (128 bits assuming top two are 0)\n(which is ignored by existing nodes).  The payer uses a new lightning\nprobe message using the current onion format we use for HTLCs to\nretreive the complete invoice.\n\nThe format of the final-hop lightning onion would contain:\n\n        [whatever-marker-we-need?][128-bit-`p`-field][[type,len,data]+]\n\nWe would probably define a few optional types to start:\n\n1. quantity: for ordering multiple of an item, default 1.\n2. delivery-address: steal from https://www.w3.org/TR/vcard-rdf/#Delivery_Addressing_Properties ?\n3. signature: basically a blob so payer can prove it was them.\n\nThe return lightning message would contain a new bolt11 invoice (perhaps\nwe optimize some fields by copying from the bolt11 offer if they don't\nappear?), and an additional field:\n\n        `m` (27) `data_length` 52.  Merkle hash of fields payer provided\n        in onion msg above, and the offer `p` value.\n\nThe payer checks the signature is correct, `m` is correct, and uses the\ninvoice to pay as normal.  The bolt11 offer + fields-from-onion + bolt11\ninvoice + preimage is the complete proof of payment.\n\nRefinements\n-----------\n\nWe can generate alternate leaves for the merkle tree (using\nSHA256(shared-secret | leafnum)) so revealing the `m` value doesn't risk\nrevealing your delivery-address for example.\n\nThe return needs to list the fields it *didn't* include in the merkle\nbecause it didn't accept them (the merchant doesn't want to be bound to\nconditions it doesn't understand!).\n\nWe could add a `k` field to the bolt11 offer to allow the final invoice\nto delegated to a separate key.\n\nThe default `x` (expiry) field for an offer which does not have an\nold-style 53-byte `p` field (ie. a \"pure\" offer) could be infinite.\n\nWe could merkelize the delivery-address too :)\n\nI've handwaved a bit over the detailed format, because there are other\nthings we want to put in the onion padding, and because the return is\nsimilar to the \"soft-error\"/\"partial payment ack\" proposals.\n\nResults\n-------\n\nThis gives us static invoicing, and a single static invoice (without an\namount field) can thus be used to approximate \"spontaneous\" donations,\nwhile still providing proof of payment; indeed, providing\nnon-transferrable proof-of-payment since the invoice now commits to the\npayer-provided signature.\n\nIt also provides a platform for recurring payments: while we can do this\nwith preimage-is-next-payment_hash, that requires pre-generation and\nisn't compatible with static invoices.\n\nI apologize that this wasn't fleshed out before the summit, but I\noverestimated the power of Scriptless Scripts so had mentally deferred\nthis.\n\nThanks!\nRusty."}