From jtimon at jtimon.cc Thu Nov 14 02:43:03 2019 From: jtimon at jtimon.cc (=?UTF-8?B?Sm9yZ2UgVGltw7Nu?=) Date: Thu, 14 Nov 2019 03:43:03 +0100 Subject: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers In-Reply-To: <90ab0a11-e4c1-92ad-e389-18514f67f2d2@slamail.org> References: <87zhhb2bpf.fsf@rustcorp.com.au> <798f31a2-fb53-a7ce-4bd6-ef06102eebba@slamail.org> <877e4bt678.fsf@rustcorp.com.au> <857a3203-6f85-b40a-9d7a-bee320180a32@slamail.org> <87d0dzqch4.fsf@rustcorp.com.au> <87y2wko2x4.fsf@rustcorp.com.au> <90ab0a11-e4c1-92ad-e389-18514f67f2d2@slamail.org> Message-ID: > - if `replacement`: > - MUST fail if `signature` does not sign `offer` with same key as original. > - MUST only fetch once (no double-redirects!) The offer can only ever be replaced once or only once every so often? Perhaps it can only be replaced once per invoice_request? > - if description or amount significantly changes, must re-ask user. Let's say we're talking about a 20 year monthly subscription and the price rises 1% per year. Did the price "significantly changed" because it ends up adding to a lot in the 20 year compared to what the offer said, or it did not because the individual 1% increases are considered small? "significantly changes" sounds handwavy indeed. Regarding slip-0173, I fear this end up becoming used in practice as ids, given that they rely on a centralized manual registry vulnerable to name squatting and all that. It's probably nothing to worry much about, since the software can configure them locally, for example, clightning does it in https://github.com/ElementsProject/lightning/blob/master/bitcoin/chainparams.c And thus if two chains happen to end up using the same string for the bip173 hrp, it is the software maintainer and not who pushed to slip-0173 first what decides. I guess in addition to the hrp in bip173, we can add a chain_id field to the offer and perhaps even repeated hrp for different chains could be reused within the same software. Although it is certainly something chain creators should try to avoid if possible. I guess this applies to bolt11 invoices too, although for the invoices sent through the lightning network it is redundant, since the chain_id is already included in all messages. On another note, perhaps I'm wrong, but I think this lacks a way for people to potentially add their own custom fields, and I foresee people abusing the description field, and ending up putting json, protobuf or, even worse, xml in them. Oh, there's no description field in invoice request, then whatever is big enough and it's not needed for those specific use cases. I was thinking how to abuse it for my own use case as I was reading, and I don't think it's one covered by UBL. Perhaps it's too stupid to ever be covered there, but here we go. I'm just playing with a little protocol in which an http server (bob) accepts requests from users (or alices) and gives an invoice in response. Then after alice pays the invoice, she can submit the payment hash and preimage to bob to prove him that the invoice has indeed been paid so that bob goes ahead and performs some "action", which can actually fail, in which case there should be a refund, which I currently don't handle in any way. But whether it fails in the "action" or not, bob gives some response. So far this seems pretty generic I bet many use cases follow this pattern, with different fields for the "request" which will somehow determine what the "action" will be. Perhaps not all require the extra step of actively proving the payment, since bob could detect the payment on his own. The current bolt12 draft could be used and take care of the refund part. So if we can somehow brainstorm all possible fields in the request that can make sense for all cases, that would be great. The current draft doesn't cover my case though. In my case, the request contains a bolt11 invoice that bob is supposed to pay, that is the "action" here. But after alice pays the invoice to bob. This probably sounds quite stupidly unnecessary (and I actually hope it is), but note that the invoice in the request may be for a different chain. In that case, during "action", bob would need to try to pay that invoice using another node connected to the lightning network of that other chain. But the details of my concrete use case matter much. The point is, should we add a bolt11 field to invoice request only for my use case? I don't think so, if the invoices of the 2 chains can be paid atomically, this use case as it is would become obsolete, and then we would want to remove the field from the spec again. And I bet other people will think of other fields they would like to add to the invoice_request but being something too specific they will also feel it doesn't belong to the specs. So we'll simply put the fields in the description. Is that intended? I'm assuming bob (the offer creator) will be able to use plugins or something to do extra or custom validations on the invoice requests. And perhaps alice could use plugins too to better handle custom errors from particular types of bobs. Perhaps I'm assuming too much? Does that make sense to you? If you're really curious, the code for my use case is in https://github.com/jtimon/multi-ln-demo/tree/master/py-ln-gateway but I already said I don't handle refunds and it doesn't even have a database yet, so anybody using this with production chains is not reckless but simply stupid.