[Lightning-dev] Make Me An Offer: Next Level Invoicing

Corné Plooy corne at bitonic.nl
Fri Oct 25 09:10:24 UTC 2019


Rusty,


At the recently held Lightning Conference in Berlin you asked for people
to send you use cases / feature requests for the next-generation
Lightning invoicing. I already did some work on this back in 2018; that
work was interrupted when I started working on other ideas. I believe
CDecker is member of some W3C(?) commission on payments, so he may also
have ideas on this.


My earlier work focused on an interactive protocol for direct
communication between payer and payee. This is an old sketch / WIP:

https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md

I know some people don't like such interaction, but it does make many
things easier to accomplish, e.g. rendez-vous routing and stuckless
payments.


For now, without doing an actual technology proposal, I'd like to share
a way of thinking about payer/payee interaction.


In my view, a transaction is not a line, it's a circle. Bitcoins go from
payer to payee over the Lightning network, and whatever
assets/goods/services are paid for go from payee to payer - this closes
the circle. Transactions on all hops of the circle should be atomic.
Between Lightning hops this is realized with HTLCs. For the payer-payee
hop this is generally not possible, as non-cryptographic things
generally don't allow you to construct HTLCs on them. Invoices and
proofs of payment act as cryptographic representatives of
non-cryptographic entities.


In a generalized view, the interaction between payer and payee can be
seen as a virtual payment channel. Full refunds, partial refunds, update
of what goods are to be delivered (which may depend on an additional
payment or a partial refund), sending back delivered goods (with
refund), are all updates to this virtual channel. Desirable properties
of such a channel:

* The channel has a state, and that state can be updated.

* A state update invalidates the previous state.

* By default, a state update requires consent of both parties. We may
include a feature where, in the previous state, one party gives consent
to allow the other party to unilaterally perform certain types of state
updates.

* A state update may require a payment of a certain amount in one
direction or in the opposite direction. The state update only becomes
valid in combination with the corresponding proof of payment.

* The state specifies obligations of parties to each other (e.g. "A
shall return <delivered goods> back to B").

* A state can be "final" in the sense that there should be no more
updates in the future. This may not need to be enforced by software or
by protocol: it can simply be by convention. If the "final" state
requires consent of both parties for an update, any participant can make
it final by never signing an update, or even by throwing away the
private key used for the channel.


The state updating mechanism and its properties require special
attention. I think the purpose of the channel is to aid in conflict
resolution - it should provide evidence of what is agreed between both
parties. There is nothing in an old state that makes it inherently
invalid: in fact, at some point in the past it was valid. The only thing
that makes it invalid is the presence of a later version. To reveal the
truth in conflict resolution, it is necessary that

(1) the latest state is revealed

(2) it is clear that this latest state is more recent than all other
states that are revealed

I hope that (1) is likely incentive-wise: typically, incentives of the
parties are each other's opposite, so either one party has an interest
in revealing an update, or the other party has. I haven't worked out
this thought very rigorously though.

I think a bit of cryptography can help with (2). One idea is to include
sequence numbers in states, another is to include the hash of the
previous state. Either way, the possibility remains (cryptographically,
maybe not incentive-wise) to mess up the evidence by "forking" the
channel: making multiple state updates that have the same parent state.
This may be resolved semantically, with rules like "if A unilaterally
makes a fork, and both sides are revealed, B may choose which side of
the fork is to be considered valid".


Some advanced ideas

* Contracts between three or more parties.

* Merging and joining of contracts in state updates


CJP





More information about the Lightning-dev mailing list