Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-14 📝 Original message: > - if `replacement`: > - ...

📅 Original date posted:2019-11-14
📝 Original message:
> - 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.