Good morning Rene,
Thank you for continuing to think about Lightning even while in hospital.
Please take care your health.
As the usual list spammer, I will of course respond pointlessly.
> Protocol idea (base version)
> =====================
> Disclaimer: This base version has obvious drawbacks but I decided to include
> it as it transports the idea.
>
> A regular payment on the Lightning Network for amount `x` has a Payment Hash
> `H` and a preimage `r`. If a recipient would now accept that this payment
> could be split over up to `n` paths the recipient would create a sha-chain of
> preimages and payment hashes with `n` elements
>
> ```
> r_0 = rand()
> H_0 = H(r_0)
> r_{i+1} = H_i
> H_{i+1} = H(r_{i+1})
> ```
>
> The payment process is initiated by the recipient providing H_{n-1} and
> signaling (in the invoice) that up to `n` preimages are available to complete
> this payment.
>
> A sender can now decide to split the payment amount `x` into `n` seperate
> payments for example of the amounts `x/n` though different splits should be
> possible. Once the preimage of the first partial payment is returned the
> payer learns the payment hash wich can be used for the next partial payment.
> (One issue is that while we have a proof of payment we do not necessarily
> have a proof of amount - which is true for the regular lightning case though
> with a single atomic payment this is not an issue as the preimage will not be
> relased if the amount is too low. We could avoid this issue by demanding that
> mulipath payments have to be at least of size `x/n`)
Assuming we accept `r_0` as proof-of-complete-payment, this does not leave the
payer with many options.
For example, suppose the payee has given `H_1 n=2` for `x = 2.0`.
Suppose the payer can find a route that can transport 2.0 in a single attempt.
The payer cannot take this route, since it can only ask for `r_1`, which is the
hash of `r_0`, and thus even if it could pay the entire 2.0 it is unable to
acquire a proof-of-complete-payment.
This could be fixed by extending HTLC offers with the number of hash operations
to perform in sequence, so that if the payer can pay the entire payment in a
single routing attempt it can request for payment in exchange of a preimage of
a hash of a hash (etc.).
But this would require an update in the peer protocol BOLT #2, not just a
payer-payee interaction change in BOLT #11.
The lack of an atomic proof-of-payment is extremely disturbing and requires
that payer and payee trust one another.
I see later that you still are unable to fix this.
> (which is a local problem of routing nodes)
As it solves a problem of the forwarding nodes, maybe forwarding nodes should
offer a fee discount if this protocol is used?
> Protocol Overview (suggested version)
> ==============================
> Let us assume the receiving node supports a window size of `s` concurrent
> payments. Now the payee will not only create one sha-chain of `n` payment
> hashes as in the base version but `s` sha-chains of `n` payment hashes.
It seems to me that `s` would have to be a global consensus parameter: hop
nodes would want to restrict it, payer and payee nodes would want `s` to be
infinite.
> * Nodes already agree to do some overpayments to obfuscate the payment amount.
*grumble* Only C-lightning ever implemented this *grumble*.
*grumble* Worse, when we reorganized the `pay` implementation we inadvertently
removed the feature and nobody cared enough to file an issue about its
disappearance *grumble*.
>
> Potential Improvements (for better privacy)
> ================================
> * Instead of using a sha-chain we could xor every preimage with a sequence
> number making it harder for an attacker to correlate two consecutive payments
> in the stream of payments via
> ```
> r_0=rand()
> H_0(r_0)
> r_{i+1} = H_0 ^ (i+1)
> H_{i+1} = H(r_{i+1})
> ```
> Instead of a sequence number we could also do something like `(i+1)*x` (as
> attackers should not be aware of the overall payment amount it will be hard
> to guess that number). I guess you folks are aware of much better
> cryptographic tricks to achieve what I suggest here. So please take this just
> as an idea from a beginner in cryptography.
It would be trivial to grind `i`, especially since we expect `n` to be small,
e.g. `n < 100` would be reasonable assumption.
The traditional solution for obfuscating easily-ground things is to add a salt
and hash it.
So:
r_{i + 1} = H_i ^ h(salt | i)
The `salt` could be included in the invoice, but that would add even more data
to invoices.
(consider that a C-lightning-generated invoice with a routing hint would no
longer fit in a tweet).
It would be nice to reuse some data in the invoice for the salt, but the payee
node id is easily ground (a forwarding node could grind nearby nodes to see if
the salt matches) and the other random data in the invoice is dependent on the
hash you put in the invoice (which is what you need to compute *with* the
salt...).
> * The proposed mechanism is not atomic. It is possible that a payee receives
> only a fraction of all payments and stops collaborating
I believe this to be a major problem.
Under current system, an expert testimony can show that revelation of the
preimage of a payment hash implies payment has been done.
An invoice would have to commit (in its description) what should be done in
exchange for payment (e.g. `d` should be "delivery of 100 USA Federal Reserve
Commemorative Papers to ZmnSCPxj", not just "100 USA Federal Reserve
Commemorative Papers").
An invoice is signed cryptographically, attesting that the node with the
specified public key has promised to deliver on the described service, if
payment is done.
Payment can only be done by exchange of the proof-of-payment preimage, thus if
anybody other than the payee is able to show the preimage, the payee has indeed
been paid and it is now held liable to its promise.
In particular, experts can show that node software will not release the
preimage if less than the agreed invoice amount is paid, and that this node
software would be under the control of the payee.
Similarly, under bass amplifier ("multipart payment"), experts can show that
node software will not release the preimage if less than the agreed amount in
total has reached the payee in all paths, thus preserving the important
atomicity of proof-of-payment.
Without this atomicity Lightning cannot operate as a trustless payment system.
> * As I used the term `stream of payments` in the text this mechanism could
> also be extended for a streaming payments protocol.
It may be better to extend this proposed protocol in this direction.
For example, if a shachain is used, we can use the recent "pay-for-data"
protocol (preimage is encryption key of data) for streaming live data.
As each payment pays for e.g. one time unit of video data, and noncooperation
of the payer or payee is equivalent to simply cancelling the stream of live
data.
There is still the issue of the payee having to be trusted to deliver the
correct data, but if the payments per unit time is small enough this may be an
acceptable risk.
Such streaming of pay-for-data would be expected to cause significant
congestion on the LN due to the high rate of payments, so it would be more
appropriate for congestion and flow control protocols here.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
