Add specs for offline payments

[q-src]

Back in August, we have published a demo video on twitter showing our LN beer tap selling water (sadly no beer...) while being offline. In order to generate an invoice and verify its settlement completely offline, we introduced deputy payment processing, a slightliy different way of payment processing relying on a deterministic preimage generation process. However, in order for this to work, both parties of a payment need to support it. This is why a public specification is necessary.

This pull request contains a first draft of such a specifcation. However, it does not only describe the specification required for offline point of sales but also the one for the opposite scenario: offline payment devices (e.g. an offline phone but also some sort of NFC card).

The specification is divided in the following parts:

• Offline Data Transmission: This specification describes how terminal devices of both parties can mitigate on a commonly supported way to transmit data required for an offline payment to succeed (e.g. a preimage or an authorization token). It is the basis for the following two specs. For further details on why we separated ths part, a blogpost on puzzle.ch will follow.

• Deputy Payment Processing: This specification describes how a payment must be processed, so that an offline point of sale is able to verify that the corresponding invoice is settled. For the proof of payment exchange, offline data transmission is used. For further details on how we implemented deputy payment processing, ~a blogpost on puzzle.ch will follow~ please have a look at our blogpost.

• Authorized Payment Initiation: This specification describes how a payment can be requested from a node directly using an authorization token. For the token exchange between sender and receiver, offline data transmission is used. For further details on how we implemented authorized payment initiation, a blogpost on puzzle.ch will follow.

The PR currently adds a dedicated BOLT for each of those parts as we were not sure where to put them otherwise. As mentioned, we will soon publish additional blogposts explaining the idea behind and how we implemented those specifications. Of course, we are also happy to join one of your IRC meetings in order to further discuss this matter.

[t-bast]

Thanks for sharing this! It would be useful to add ASCII diagrams of the different flows and data exchanged. That would help review the protocols themselves before we consider any kind of spec inclusion.

[q-src]

I finally found the time to add the requested diagrams - hopefully they help. If you have any questions, I will be glad to answer them.