Good morning, > * Sub-payment - one or more attempts, each of which semantically pay for "the same thing" for "the same value", set up in parallel. > a sub-payment may have multiple attempts running in parallel, but only one attempt will be claimable. > * Payment - one or more sub-payments, each of which semantically pay for "different parts of an entire thing", set up in parallel. > a payment may have multiple sub-payments, and all sub-payments will be claimed atomically.
This can be also thought of as: Payment = ONE-OF(attempt_11, ..., attempt_m1) AND ... AND ONE-OF(attempt_n1, ..., attempt_m'n) Its dual also deserves some thought: Payment = ONE-OF(attempt_11 AND ... AND attempt_m1), ..., (attempt_n1 AND ... AND attempt_m'n)) or in words, "A payment is an atomic value transfer through many paths, each of which carry a part of the entire value -- many alternative groups of paths are available to be used, but only one of the groups eventually goes through." Is there a reason to design in preference of one of the two? Speaking of generalization, it would be nice to have arbitrary AND-OR combinations, but this needs further exploration: > If we want to create more complex access structures then we use verifiable secret sharing where the discrete log of B is split up into shares and distributed according the the desired structure. One possible milestone of this generalisation would be to enable atomic payments where the paying wallet says "there are all these known paths, each with such and such capacity; I want some to go through such that the desired value is transferred in aggregate, no more, no less (possibly within a margin of error)". Kindly ignore me if I'm regurgitating already discussed stuff. Best, Orfeas -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
