Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
Good morning list, and all,
Rene Pickhardt mentioned strongly about the new Boomerang paper:
https://arxiv.org/pdf/1910.01834.pdf
I would like to compare it with my own proposal which combines High AMP
("Discrete Log AMP" or "DAMP" or "DLAMP") with Stuckless to provide a similar
facility:
*
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002225.html
*
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002232.html
So let me describe Boomerang mildly:
* Boomerang requires payment points and scalars.
It uses the term "HTLC" still, but means "pointlocked" for the "H" here.
* Boomerang uses a pay-for-contract construction involving two PTLC layers.
The first layer has a pointlocked branch involving the signatures of *both*
channel endpoints, rather than the receiver.
The pointlocked branch is spent by the second-layer PTLC; thus both endpoints
need to sign off on this in order to enforce that the second-layer PTLC is used.
* I describe "pay for contract" here:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001795.html
Of note is that the "direction" of the second layer is different in the
Boomerang paper, whereas my above description has the same direction for the
second-layer PTLC.
But I consider "pay for contract" a way to set up multiple transactions
with specific outputs, and the "second layer" can be anything; the example I
gave in my original treatment, to me, is simply one possibility among many
possibilities.
Indeed, I also gave another example of pay-for-contract (though did not use
the term):
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002055.html
* The first layer sets up the second layer atomically.
The second layer lets the payer reclaim its funds in case the payee
attempts to claim more than the allowed number of incoming payments.
If the payee is honest, however, inevitably the second layer times out and
returns the funds to the payee, letting the payee use its newly-accepted funds.
* In a normal Boomerang payment where everyone acts honestly:
1. The first-layer PTLC is claimed by the payee, instantiating the
second-layer PTLC.
2. The payer fails the second-layer PTLC, putting the money to the payee.
I would like to raise the following points against Boomerang:
* It requires more layers of PTLCs than my High AMP + Stuckless proposal.
While this "should" be negligible given that we are running offchain, it does
increase onchain footprint if the channel is unilaterally dropped onchain while
a Boomerang payment is ongoing.
* Either we have a separate Boomerang style of forwarding (which all
forwarding nodes have to support in addition to "normal" PTLC forwards), or we
enforce that all payment-point forwards use Boomerang at all times.
The former has the drawback that forwarding nodes might specifically
monitor Boomerang (i.e. it is distinguishable from other formats), the latter
has the drawback that small payments that would succeed on a single path would
have the same overhead in case they get dropped onchain.
* As I pointed out before:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002030.html
If the "return path" for "ACK" in Stuckless is the same as the normal payment
path, then it becomes possible for forwarding nodes to guess the
distance-to-payer, information it cannot determine currently.
* The "ACK" in Stuckless is equivalent to the first-layer PTLCs in Boomerang
being claimed (and instantiating the second-layer PTLCs).
This lets forwarding nodes guess the distance-to-payer (by measuring the
time between the first-layer PTLC is claimed and the second-layer PTLC is
failed).
Stuckless has the possibility of sending the "ACK" via another means
(hopefully not leaking timing information to forwarding nodes), but Boomerang,
due to using pay-for-contract, cannot do so at all.
* There is no incentive for the payer to actually fail the second-layer PTLC
and thus release the payment immediately.
* In particular, the first-layer PTLC being claimed is sufficient to provide
proof-of-payment to the payer.
The payer having acquired what it wanted (proof-of-payment), it can then
refuse to cancel the second-layer PTLC until its timelock expires, on the
off-chance the payee is hacked and leaks the secret that would let the payer
claim the second-layer PTLC.
* In the High AMP + Stuckless proposal, the payee will not release the
proof-of-payment until the payer provides the required secret to claim the
money after the ACK.
Release of proof-of-payment is incentivized by being paid using an incoming
PTLC.
* Boomerang does not enable those cool hacks like Barrier Escrows.
One can argue that pay-for-contract implements the same behavior as barrier
escrows.
But barrier escrows allow *any* contract arrangement to be made
permissionlessly, without forwarding nodes becoming involve
Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
Hi all, After having some more thinking I think I have another cool thing that can be done with barrier escrows. We already have established that pay-for-atomic-multi-payment-setup can be provided by using a High AMP to a node that is trusted not to collude with the parties involved (along with payment point addition). Before moving on to my idea I'd also like to note that a sub-case of this is pay-for-payment-setup where two parties pay an AMP to a barrier through each other where one way is a payment being setup (which likely has some complicated payment point) while the other direction is a simple payment that requires only a secret known to the receiving node as well as the barrier escrow secret. In this way, when the barrier subsides, one party gets paid and the other party has a payment setup to it. This can be used for such things as option-like DLCs. Anyway, aside from very general multi-payment setup, I've realized that we can likely use barrier escrows to re-negotiate payments/contracts. I'll start with what I think is the most simple example: Bob has a payment setup to Sally with payment point (S + X) where Sally knows S and X enforces some contract. The goal here is for Carol to set up a payment to Sally for the point S' + X' (X' could be X), atomic with having Bob leave his contract (note that Bob and Carol could be the same entity in the case where payment amount is being re-negotiated). In order to make this possible, instead of using (S + X) Bob and Sally instead use (S + KE(X, E)) where KE is the key exchange function and E is a point known to a barrier escrow. Carol can now set up her payment to sally by adding E to that payment. Sally sets up a payment to Bob for the amount of his original payment (perhaps minus some fee) with the point B + E (where Bob knows B). And lastly, Sally and Bob create an AMP to the barrier escrow in return for the scalar to E. Upon receiving this secret, Bob and Sally can exit their contract by claiming (near) equal amounts, and Sally know has Carol as her new contract participant. This is the description of the simplest pay-for-payment-re-negotiation I could think of but this scheme is fully extensible to re-negotiating multiple set up payments. For example, say that Alice and Bob have set up a DLC over lightning as described earlier in this thread. Bob can sell his position to Carol by atomically closing his position while Carol opens hers by using a barrier escrow. This is done by essentially reusing the escrow that is baked in to Alice and Bob's contract for payment re-negotiation as the barrier escrow used for atomic multi-payment setup between Alice and Carol. To recap the many nuggets I can remember from this thread (so far) Payment Points allow for: 0) Everything listed in the first post in this thread 1) Payments conditional on some discrete logarithm-based access structures (think a bunch of ANDs and ORs) 1a) Multisig-like access structures 1b) Oracle-dependent "option" 2) Atomic multi-payment setup using barrier escrows 2a) Atomic payment for return payment setup 2b) Premium to cross-currency lightning nodes for use to avoid Free Option Problem 2c) Lightning DLCs 2d) Lightning DLC "option"s or one-way DLCs with a premium 3) Multi-payment re-negotiation using barrier escrows 3a) Selling DLC positions 4) Also, High AMP is interoperable with "Stuckless" payments 5) It would be nice to have a language like miniscript (perhaps call it "Improv" because scriptless --due to LLoyd) that compiled to "Layer 3" protocol specifications 6) We should start writing these things up and adding them to: https://github.com/ElementsProject/scriptless-scripts This stuff is super fun, I can't wait for there to be payment points on LN :) Best, Nadav On Tue, Oct 15, 2019 at 12:01 AM ZmnSCPxj wrote: > Good morning Jonas, Orfeas, and all, > > > > hashing out old ideas in public like an out-of-the-loop person > > > > Being fully in-the-loop literally seems undesirable anyway. As the > scriptless > > scripts space gets bigger, I invite everyone to consider contributing to > the > > scriptless scripts repo at > > https://github.com/ElementsProject/scriptless-scripts. This allows to > have the > > ideas at one place, improve them over time and standardize on > terminology and > > notation. In particular, the escrow idea seems quite established and > would be a > > nice to have written down comprehensively along with it's shortcomings. > > Thank you, this seems of interest. > > > > > > OR is harder > > > > Unless you have additional requirements OR is simpler because it just > means > > creating and revealing the key to the other party. In your exmple "(A > AND B) OR > > (B AND C) OR (C AND A)", A and B can generate each generate their key > and add > > it. Then they each split their key into two shares, one is created by > adding a > > random scalar, the other by subtracting the same random scalar. They each > > encrypt their first share t
Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
Good morning Jonas, Orfeas, and all, > > hashing out old ideas in public like an out-of-the-loop person > > Being fully in-the-loop literally seems undesirable anyway. As the scriptless > scripts space gets bigger, I invite everyone to consider contributing to the > scriptless scripts repo at > https://github.com/ElementsProject/scriptless-scripts. This allows to have the > ideas at one place, improve them over time and standardize on terminology and > notation. In particular, the escrow idea seems quite established and would be > a > nice to have written down comprehensively along with it's shortcomings. Thank you, this seems of interest. > > > OR is harder > > Unless you have additional requirements OR is simpler because it just means > creating and revealing the key to the other party. In your exmple "(A AND B) > OR > (B AND C) OR (C AND A)", A and B can generate each generate their key and add > it. Then they each split their key into two shares, one is created by adding a > random scalar, the other by subtracting the same random scalar. They each > encrypt their first share to B and the second share to C. They do the same for > C and A. The receivers must check that they've received valid shares, i.e. > their shares sum up to the secret to the A + B key. That's not very efficient > because it requires a lot of communication, but I don't know of a better > scheme > for general disjunctive normal forms like that and this helps as a mental > model. Any policy consisting of ANDs and ORs policy can be written in > disjunctive normal form and can therefore be constructed similar to above > example. I believe we do have additional requirements in some cases. For example, consider the case of a DLC oracle which, at some future point, will be constrained to reveal the scalar behind one of the points `A`, `B`, `C`, or `D`. Then I make a bet with Nadav that the oracle will reveal the scalar behind either point A or point B, and that he should pay me if the oracle publishes either point. What can the oracle safely reveal beforehand, that would let Nadav and I arrange so that I am paid if I learn the secret behind point `A` or point `B`? In particular, it should not be possible to, for example, learn `c` after learning only `a`, or learn `b` after learning only `a`, etc. I suppose for this part we could just have a separate "aggregating oracle' which itself would be tr\*sted to report the result of the first oracle accurately, adding more "he said she said" layers and reducing reliability and increasing the tr\*sted set. I suppose a "compiler" for a language that implements arbitrary ANDs / ORs policy would then output some protocol specification about how the participants set things up. > > - 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? Engineering-wise, it seems better to group individual parallel attempts into a group that transfers a share of the total value. I imagine that grouping shares of the total value into a group that can be attempted in parallel with others, would require more funds to potentially be locked up. That is, the payer needs to lock up units of the payment amount in order to run in parallel. In the scheme as proposed, for example: * I decide to pay a 10 mBTC invoice by splitting it up to 5 mBTC and 5 mBTC sub-payments. * The first sub-payment reaches the destination immediately. * The second sub-payment takes a long time to reach the destination and I worry it is stuck. * Fortunately, I have some spare 5mBTC in another channel and I make a new stuckless attempt with that instead. In sum total, I have put three different 5mBTC attempts to make a single 10mBTC payment, and I can control (because of the stuckless ACK) exactly how much the receiver can claim of those attempts. If we were to group them differently, then it seems to me that I would have to speculatively allocate entire units of 10mBTC in order to create a new stuckless attem
Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
> hashing out old ideas in public like an out-of-the-loop person Being fully in-the-loop literally seems undesirable anyway. As the scriptless scripts space gets bigger, I invite everyone to consider contributing to the scriptless scripts repo at https://github.com/ElementsProject/scriptless-scripts. This allows to have the ideas at one place, improve them over time and standardize on terminology and notation. In particular, the escrow idea seems quite established and would be a nice to have written down comprehensively along with it's shortcomings. > OR is harder Unless you have additional requirements OR is simpler because it just means creating and revealing the key to the other party. In your exmple "(A AND B) OR (B AND C) OR (C AND A)", A and B can generate each generate their key and add it. Then they each split their key into two shares, one is created by adding a random scalar, the other by subtracting the same random scalar. They each encrypt their first share to B and the second share to C. They do the same for C and A. The receivers must check that they've received valid shares, i.e. their shares sum up to the secret to the A + B key. That's not very efficient because it requires a lot of communication, but I don't know of a better scheme for general disjunctive normal forms like that and this helps as a mental model. Any policy consisting of ANDs and ORs policy can be written in disjunctive normal form and can therefore be constructed similar to above example. On 10/9/19 11:42 PM, Nadav Kohen wrote: > Hi list, > > I'm back again with another idea about Payment Points and fun things to do > with them! Hopefully this time I'm not entirely just hashing out old ideas > in public like an out-of-the-loop person :) > > *TLDR: Adding and ECDH-ing points gives us AND and OR functionality which > we can compose to make cool lightning contracts like Multisig, Escrow, and > DLCs* > > So when looking at the following (likely incomplete) list of things you can > do with payment points: > > 1) Payment De-correlation > 2) "Stuckless" Payments > 3) High AMP > 4) Selling Signatures > 5) Selling Pedersen De-commitment > 6) Escrow Contracts > > I started of trying to classify what kind of thing these new features are > in hopes of coming across new ones. The first three I clumped into a group > I called "Payment point addition allows us to do cool things while > maintaining the Proof of Payment (PoP) property". The next two (4 and 5) I > called "Commitment applications where point is public". But ZmnSCPxj's > proposal for lightning escrow contracts ( > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002028.html) > struck me as something different that might somehow be made more general. > > Essentially the idea is to use the point S + ECDH(B, E) where S is the > seller's point, B is the buyer's point and E is the escrow's point. This > means that the scalar can be discovered by the seller in collaboration with > the buyer or the escrow, that is, S AND (B OR E). I propose that under > certain circumstances (such as the parties involved being able to > interact), this can be generalized to have payments conditioned on > arbitrary AND/OR circuits. > > I believe that AND is very straightforward as you simply take two > conditions A and B and add them together to get a point that requires both > of their scalars are discoverable (except maybe under certain bad > circumstances that can be avoided where like B = C - A, this must be > guarded against). > > OR is harder but I think that it can be achieved in the two party case by > ECDH and in the n-party case by multi-party key exchanges (which I know > pretty much nothing about other than that they exist). Given some key > exchange protocol (preferably non-interactive), KE, KE(A_1, ..., A_n) > should result in a number known only to those who know any scalar a_1, ..., > a_n and no one else. Assuming this exists and we can manage to trustlessly > (in some possibly stretched sense of the word) compute shared keys > (including such things as KE(A+B, C)), then KE(A, B) acts as A OR B in our > payment condition contract. > > To restate the escrow contract idea in this setting, the payment is > conditioned on S + KE(B, E). Important to note is that not all parties must > know about the details of the payment itself: the Escrow in this example > knows nothing about this payment (other than that some payment exists) > unless there is a dispute. > > Lastly, note that contracts following this scheme look indistinguishable to > normal payments on the network, and are fully compatible with High AMPs > since we can simply take the payment point specified by our contract and > add that point to each partial payment point. > > Well this is all nice in theory, but is there anything that will actually > come out of this thinking? I'll detail the two things I've thought of so > far for which I'd love critique! I'd also love to hear if anyone else > th
Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
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
Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
Good morning Nadav and Lloyd,
> I really like the Premium-free American Call Option mitigation you've
> described here! I totally agree that it is probably best to move to
> computational security rather than rational security. I hadn't thought about
> how well High AMP inter-operates with the AND/OR scheme to make things like
> barrier escrows :) I wonder if there is some nice generalization of this kind
> of setup so that being a Barrier Escrow as a Service can be another way to
> make money by participating in the Lightning ecosystem. Maybe this modified
> High AMP is all there is to it and all we need is some standard communication
> interface for these Barrier Escrows?
Indeed, from my current thinking, only the computationally-intractable-security
High AMP is needed.
Note that the secret `z` behind `Z` can itself also serve as:
* The blinding scalar in route decorrelation.
* The ACK response scalar in Stuckless.
This discussion is valuable in fact because ***I would have been perfectly and
totally fine with economically-rational High AMP***.
But being able to ab^H^Hreuse the High AMP mechanism to implement barrier
escrow means we might very well do better to design a unified package of
features that implement decorrelation, High AMP, Stuckless, barrier escrow,
etc. using the same mechanism, while providing a proof-of-payment
("pay-for-scalar") on top of which we can hook things like pay-for-signature
and pay-for-Pedersen-decommitment.
So let us define some terms.
* Attempt - a single sequence of pointlocked timelocked contracts that
terminate at some payee.
It either fails or succeeds atomically.
* Sub-payment - one or more attempts, each of which semantically pay for "the
same thing" for "the same value", set up in parallel.
Pre-Stuckless, each sub-payment only has a single attempt at a time.
After Stuckless, 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.
Pre-AMP, a payment contains only a single sub-payment.
After AMP, a payment may have multiple sub-payments, and all sub-payments
will be claimed atomically.
So let me propose the below, when we switch to payment points:
* The payee receives a PTLC offer:
* It pays in exchange for the secret behind `S + Z`.
* The peyee knows the secret behind `S`, and the packet includes a TLV
identifying *which* `S` exactly is being used.
* I believe the `S + Z` and `S` should be enough for the payee to determine
`Z`.
* The offer also includes an onion-encrypted packet that tells the payee
where to get the secret `z` behind `Z`.
* On contacting the payer, the payee gets:
* `z_route` a blinding factor for this route (cross-route decorrelation /
Stuckless ACK)
* This uniquely identifies a single attempt of a sub-payment.
* `z_all` a blinding factor (High AMP computational-intractability).
* This uniquely identifies a single sub-payment.
* To claim *this* attempt the payee computes the sum of all `z_all` for
all routes, plus the `z_route` for this particular incoming payment.
* If a different attempt of the same sub-payment is already requested by
the payee, then the payer will send only `z_all` (which the payee then matches
with the `z_all` of a different attempt) but not `z_route`, indicating to the
payee that the two attempts are parallel attempts of the same sub-payment.
* Having separate blinding factors lets payers do Stuckless and multipath
simultaneously, i.e. split the payment in paths, then make more than one
parallel attempt for each split-out path.
* A forwarding node receives a PTLC offer that it should forward:
* It pays in exchange for the secret behind `F`.
* It includes a secret `y`.
* The forwarding node should unwrap the onion packet by one layer and send to
the next node a PTLC offer in exchange for the secret behind `F + Y`, where `Y
= y * G`.
Forwarding nodes thus learn almost nothing, and the use of higher constructions
like barrier escrows etc. are not known to forwarding nodes (and thus cannot be
censored by them).
Then:
* Suppose a payer wants to make a single payment.
* It selects random `z_all`.
* It generates a route.
* It selects random `z_blind` for each forwarding node and the payee in the
route and computes `z_route` as the sum of all `z_blind`.
* It computes `Z` for this route as `(z_route + z_all) * G`.
* It offers a PTLC to the first forwarding node for `S + z_blind[0] * G +
z_all * G`.
* In the packet, the first hop node gets `y = z_blind[1]`, next gets `y =
z_blind[2]`, the final payee has no `y`.
* The payee then receives a payment for `S + Z`, where `Z` is the sum of all
`z_blind` times `G`, plus `z_all * G`.
* The payee then contacts the payer via an anonymous contact point and
learns `z_all` and `z
Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
Hi ZmnSCPxj, > I think, it is possible to make, a miniscript-like language for such things. > Indeed, the only material difference, between SCRIPT-based `OP_CHECKSIG`s and Lightning, would be the requirement to reveal scalars rather than prove your knowledge of them. I've thought about this too. I've been pitching the language name as "Improv" (since it's scriptless!). I think it would allow you to specify the rules by which each output on each transaction can be spent and would compile those rules into a protocol that does the secure key and signature exchange for all the transactions in the scaffold. In other words, a protocol compiler. I think this could be really useful for formal specification of layer-2 protocols. LL On Thu, Oct 10, 2019 at 3:31 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Nadav, > > Thank you very much for this framework! > It seems very good idea, kudos to making this framework. > > I think, it is possible to make, a miniscript-like language for such > things. > Indeed, the only material difference, between SCRIPT-based `OP_CHECKSIG`s > and Lightning, would be the requirement to reveal scalars rather than prove > your knowledge of them. > > > > Idea 2: DLCs Routed over Lightning > > Say that some DLC oracle will either broadcast s_A or s_B whose public > points are S_A and S_B (which can be computed from public information as > per the DLC scheme). Then say that Alice and Bob enter into a contract > under which Alice wins some amount if s_A is broadcasted and Bob if s_B is > broadcasted. Say Alice has a point A and Bob has a point B. They each send > the other a payment with the amount that party must receive if they win > with the payment point A + S_A for Bob's payment to Alice and B + S_B for > Alice's payment to Bob. And this is it! If s_A is broadcasted then Alice > gets paid (and Bob gets proof of payment a, which is the scalar to A), > otherwise s_B is broadcasted and Bob gets paid (with Alice receiving b as > PoP). An interesting note is that under this scheme neither party is forced > to pay extra on-chain fees in the case of a counter-party who doesn't > cooperate whilst in the wrong. > > One wrinkle with this scheme is that setup isn't trustless. Although it > is generally true that one party must sign the funding transaction for a > DLC before the other party for on-chain DLCs, at least there is the > mitigation that when your counter-party goes silent, you can move your > input funds invalidating the funding transaction you signed (at a cost > because fees). So what can we do here to ensure that both payments are > setup at the same time in the case that Alice and Bob don't trust each > other? > > Say that although they don't trust each other, they're both willing to > trust some escrow entity who generates some point E for their payment. > Alice's payment point to Bob becomes B + S_B + E and Bob's to Alice becomes > A + S_A + E. The escrow now waits to hear from Alice and Bob that they have > incoming payments setup and only once both of them attest to this (using > signatures, for example) does the escrow release the scalar to E to them > both. The escrow can also have a timeout at which it will never reveal the > scalar to E: forcing both parties to commit to the contract well before the > DLC event. In this way, trust has been moved from counter-party to > trustworthy (hopefully) escrow in such a way that the Escrow learns nothing > about the contract itself (other than that there is one of some kind). > > I think we can call this a "barrier escrow". > > * It is similar to the concept of synchronization barriers for multithread > coordination: https://en.wikipedia.org/wiki/Barrier_(computer_science) > * In effect, each sub-transaction of the entire arrangement is a "thread" > of operation, and the "barrier escrow" ensures that all the threads have > reached it before letting them continue to claim the payments. > > > I seem, this is applicable to *not only* DLC, but others as well. > Instead, it seems to me to also provide an alternate solution to the > Premium-free American Call Option Problem. > > Let us introduce our characters: > > * B, a supposed buyer, holding some Bitcoin. > * S, a supposed seller, who wishes to be paid in another asset. > * X, a cross-currency exchange Lightning node. > * E, a tr\*sted escrow. > > X would like to facilitate exchanges across different assets, but wants to > be paid a premium in order to prevent the Premium-free American Call Option > Problem. > B would like to swap its Bitcoin for another asset to pay S, and would be > willing to pay the above premium, but only conditional on S actually > getting the asset it wants to be paid in. > X and B are non-trusting to each other, but are willing to tr\*st escrow E. > > This again is another "two transactions" setup, where we move tr\*st from > X and B and transfer it to E. > > * B forwards the payment to be exchanged through X an
Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
Hi Nadav, I've thought about similar problems before. Essentially you are trying to create an "access structure" on discrete logarithm (the completion of the adaptor signature in "pay-to-point"). I think the term for arbitrary combinations of AND and ORs and even N-of-M is called a *monotone access structure*. > Essentially the idea is to use the point S + ECDH(B, E) where S is the seller's point, B is the buyer's point and E is the escrow's point I can't see how you can create an access structure like this with ECDH. Neither B nor E know the discrete log of ECDH(B,E). I can see that you can hash it and use it as a scalar but then you have to make a heavy zkp to prove the validity (or interact with the escrow which violates the premise). Fortunately, I think it is possible to create any monotone access structure on a discrete logarithm using *verifiable encryption*. Applying this to the Escrow payment problem, the buyer decides on the payment point B and verifiably encrypts the discrete logarithm of B under the Escrow's public key E and sends the encryption to the seller. If there's a dispute, the seller sends the encryption to the Escrow. If the Escrow resolve the dispute in favour of the seller they just decrypt the ciphertext and send the discrete log of B to the seller. The seller can now redeem the payment. 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. So how do we do this verifiable encryption/secret sharing? Well it's not really straight forward. In the case of Escrow, Camenisch-Shoup [1] verifiable encryption might be attractive since the Escrow can be trusted to produce the Paillier modulus properly. Otherwise there's Camenisch-Damgaard [2] which is much less efficient but only relies on CDH assumption. As far as I know there are no usable implementations of either of these schemes but Camenisch-Damgaard is relatively straightforward and I think it's practical. [1] https://www.shoup.net/papers/verenc.pdf [2] https://eprint.iacr.org/1999/008 LL On Thu, Oct 10, 2019 at 10:43 AM Nadav Kohen wrote: > Hi list, > > I'm back again with another idea about Payment Points and fun things to do > with them! Hopefully this time I'm not entirely just hashing out old ideas > in public like an out-of-the-loop person :) > > *TLDR: Adding and ECDH-ing points gives us AND and OR functionality which > we can compose to make cool lightning contracts like Multisig, Escrow, and > DLCs* > > So when looking at the following (likely incomplete) list of things you > can do with payment points: > > 1) Payment De-correlation > 2) "Stuckless" Payments > 3) High AMP > 4) Selling Signatures > 5) Selling Pedersen De-commitment > 6) Escrow Contracts > > I started of trying to classify what kind of thing these new features are > in hopes of coming across new ones. The first three I clumped into a group > I called "Payment point addition allows us to do cool things while > maintaining the Proof of Payment (PoP) property". The next two (4 and 5) I > called "Commitment applications where point is public". But ZmnSCPxj's > proposal for lightning escrow contracts ( > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002028.html) > struck me as something different that might somehow be made more general. > > Essentially the idea is to use the point S + ECDH(B, E) where S is the > seller's point, B is the buyer's point and E is the escrow's point. This > means that the scalar can be discovered by the seller in collaboration with > the buyer or the escrow, that is, S AND (B OR E). I propose that under > certain circumstances (such as the parties involved being able to > interact), this can be generalized to have payments conditioned on > arbitrary AND/OR circuits. > > I believe that AND is very straightforward as you simply take two > conditions A and B and add them together to get a point that requires both > of their scalars are discoverable (except maybe under certain bad > circumstances that can be avoided where like B = C - A, this must be > guarded against). > > OR is harder but I think that it can be achieved in the two party case by > ECDH and in the n-party case by multi-party key exchanges (which I know > pretty much nothing about other than that they exist). Given some key > exchange protocol (preferably non-interactive), KE, KE(A_1, ..., A_n) > should result in a number known only to those who know any scalar a_1, ..., > a_n and no one else. Assuming this exists and we can manage to trustlessly > (in some possibly stretched sense of the word) compute shared keys > (including such things as KE(A+B, C)), then KE(A, B) acts as A OR B in our > payment condition contract. > > To restate the escrow contract idea in this setting, the payment is > conditioned on S + KE(B, E). Important to note is that not all parties must > know about the details of the paym
Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
Hi list and ZmnSCPxj,
Glad this has been helpful and I'm not just stating obvious things :)
always hard to tell once the idea has been had.
> I think, it is possible to make, a miniscript-like language for such
things.
> Indeed, the only material difference, between SCRIPT-based
`OP_CHECKSIG`s and Lightning, would be the requirement to reveal scalars
rather than prove your knowledge of them.
Totally agree, and furthermore, another idea I had is that if we want to
adjust any of this to a scheme where you reveal proof of knowledge rather
than the scalars themselves, then rather than just a point, the parties can
agree on a point, a nonce point, and a message and then essentially use
pay-for-signature to have Schnorr signatures revealed rather than the
scalars themselves. This scheme even lets participants use partial
signatures that they can add (though there is potentially some nonce
nastiness involved). It certainly would add complexity but is an option
should it ever be useful. I think. Another thought is that maybe users can
have one key be static (like the node id?) and have the nonce be the
"Payment Point" in my scheme so that the signature is proof that this set
of node ids has collective access to the nonce point?
I really like the Premium-free American Call Option mitigation you've
described here! I totally agree that it is probably best to move to
computational security rather than rational security. I hadn't thought
about how well High AMP inter-operates with the AND/OR scheme to make
things like barrier escrows :) I wonder if there is some nice
generalization of this kind of setup so that being a Barrier Escrow as a
Service can be another way to make money by participating in the Lightning
ecosystem. Maybe this modified High AMP is all there is to it and all we
need is some standard communication interface for these Barrier Escrows?
Best,
Nadav
On Thu, Oct 10, 2019 at 10:15 AM ZmnSCPxj wrote:
> Good morning list, and Nadav,
>
>
> > I would also like to point out the below assumption, which underlies
> Bass Amplifier ("multipath payments", "base AMP") and its claim to
> atomicity:
> >
> > - If we agree that my secret `s` is worth `m` millisatoshi, then I (as
> a perfectly rational economic agent) will not claim any payments
> conditional on my revelation of `s` that sum up to less than `m`
> millisatoshi: I will only claim all of them when I can get multiple
> payments conditional on my revelation of `s` that sum up to `m`
> millisatoshi or more.
> > - I now call this "economically-rational atomicity", and describe
> also them mildly here:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001109.html
> >
> > The above is exactly the behavior we want E to perform: only if
> it receives both requests to reveal its secret `e` behind `E`, will it
> actually reveal the secret.
> > In our case, we turn the requests to E into partial payments of
> a single invoice (though of course, the payment from S to E would be in the
> asset that S wants rather than in Bitcoin).
> > E would not like to "sell short" its secret `e` for less than
> the price of its service, thus if E is economically rational, it would only
> claim payments (and reveal `e`) once all incoming payments sum up to the
> price of its service.
>
> Right right, except an economically-rational actor will also accept a
> *single* payment that exceeds the price `m` miilisatoshi.
> Meaning anyone can then subvert the behavior of the barrier escrow E.
> For example, as soon as the exchange X is able to get the incoming premium
> payment conditional on release of the secret behind `X + E`, the exchange
> can simply directly send the entire payment asked by the escrow E for the
> secret behind `e` and claim the premium without actually performing the
> swap and forwarding to `S`.
>
> Fortunately,
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001109.html
> also notes that it is possible to upgrade the High AMP with
> economically-rational security to a High AMP with
> computationally-intractable security.
> The sketch given in that link is different, but we can use a conversion
> that utilizes points and scalars in much the same way as Nadav suggests as
> part of the framework.
>
> That is, we can create a High AMP with the following rules for the
> receiver:
>
> * If the receiver knows a secret `e` behind a point `E`, payment is
> demanded in exchange for the secret `e + z` behind a point `E + Z` instead.
> * The receiver is informed what `E` is being talked about, in some TLV
> to the receiver, as well as the point `Z`.
> * Every branch of the multipath also includes, in some TLV, a secret
> `z[i]`.
> * `sum[i=1..n](z[i]) == z`, i.e. the sum of all the branch secrets is
> the secret `z` behind the point `Z`.
> * Thus, only once the receiver acquires all branches as incoming payments,
> will it be able to reconstruct the secret `z` and thereby claim its pa
Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
Good morning list, and Nadav,
> I would also like to point out the below assumption, which underlies Bass
> Amplifier ("multipath payments", "base AMP") and its claim to atomicity:
>
> - If we agree that my secret `s` is worth `m` millisatoshi, then I (as a
> perfectly rational economic agent) will not claim any payments conditional on
> my revelation of `s` that sum up to less than `m` millisatoshi: I will only
> claim all of them when I can get multiple payments conditional on my
> revelation of `s` that sum up to `m` millisatoshi or more.
> - I now call this "economically-rational atomicity", and describe also
> them mildly here:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001109.html
>
> The above is exactly the behavior we want E to perform: only if it
> receives both requests to reveal its secret `e` behind `E`, will it actually
> reveal the secret.
> In our case, we turn the requests to E into partial payments of a
> single invoice (though of course, the payment from S to E would be in the
> asset that S wants rather than in Bitcoin).
> E would not like to "sell short" its secret `e` for less than the
> price of its service, thus if E is economically rational, it would only claim
> payments (and reveal `e`) once all incoming payments sum up to the price of
> its service.
Right right, except an economically-rational actor will also accept a *single*
payment that exceeds the price `m` miilisatoshi.
Meaning anyone can then subvert the behavior of the barrier escrow E.
For example, as soon as the exchange X is able to get the incoming premium
payment conditional on release of the secret behind `X + E`, the exchange can
simply directly send the entire payment asked by the escrow E for the secret
behind `e` and claim the premium without actually performing the swap and
forwarding to `S`.
Fortunately,
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001109.html
also notes that it is possible to upgrade the High AMP with
economically-rational security to a High AMP with computationally-intractable
security.
The sketch given in that link is different, but we can use a conversion that
utilizes points and scalars in much the same way as Nadav suggests as part of
the framework.
That is, we can create a High AMP with the following rules for the receiver:
* If the receiver knows a secret `e` behind a point `E`, payment is demanded in
exchange for the secret `e + z` behind a point `E + Z` instead.
* The receiver is informed what `E` is being talked about, in some TLV to the
receiver, as well as the point `Z`.
* Every branch of the multipath also includes, in some TLV, a secret `z[i]`.
* `sum[i=1..n](z[i]) == z`, i.e. the sum of all the branch secrets is the
secret `z` behind the point `Z`.
* Thus, only once the receiver acquires all branches as incoming payments, will
it be able to reconstruct the secret `z` and thereby claim its payment (and
incidentally reveal `e + z`; if the ultimate payer then knows `z` it is able to
acquire `e` as proof-of-payment).
So let us reconsider the protocol:
* B, S, and X generate additional keypairs `b2, B2`, `s2, S2`, and `x2, X2`
respectively and give the public keys to buyer B.
* B generates `Z` from `B2 + S2 + X2`.
* B sends the premium payment to X, in exchange for revelation of the secret
behind `X + E + Z`.
* X sends the request to the barrier escrow E to reveal the secret behind `E +
Z`, also providing its share of the secret behind `Z`, `x2`.
* B sends the payment to be swapped to the other asset to X, in exchange for
revelation of the secret behind `S + E + Z`.
* X swaps the asset and forwards to S, in exchange for the revelation of the
secret behind `S + E + Z`.
* S sends the request to the barrier escrow E to reveal the secret behind `E +
Z`, also providing its share of the secret behind `Z`, `s2`.
* B sends the request to the barrier escrow E to reveal the secret behind `E +
Z`, also providing its share of the secret behind `Z`, `b2`.
* E reconstructs `z` from `b2 + s2 + x2`, then reveals `e + z` to claim all the
escrow service sub-payments.
* X learns `e + z` and is able to reveal `x + e + z` to claim the premium.
* S learns `e + z` and is able to reveal `s + e + z` to claim the premium.
* B learns `e + z`, `x + e + z`, and `s + e + z`, and is able to recover
proof-of-payment for the premium as `(x + e + z) - (e + z)`, and
proof-of-payment for the actual service or product as `(s + e + z) - (e + z)`.
Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
Good morning Nadav,
Thank you very much for this framework!
It seems very good idea, kudos to making this framework.
I think, it is possible to make, a miniscript-like language for such things.
Indeed, the only material difference, between SCRIPT-based `OP_CHECKSIG`s and
Lightning, would be the requirement to reveal scalars rather than prove your
knowledge of them.
> Idea 2: DLCs Routed over Lightning
> Say that some DLC oracle will either broadcast s_A or s_B whose public points
> are S_A and S_B (which can be computed from public information as per the DLC
> scheme). Then say that Alice and Bob enter into a contract under which Alice
> wins some amount if s_A is broadcasted and Bob if s_B is broadcasted. Say
> Alice has a point A and Bob has a point B. They each send the other a payment
> with the amount that party must receive if they win with the payment point A
> + S_A for Bob's payment to Alice and B + S_B for Alice's payment to Bob. And
> this is it! If s_A is broadcasted then Alice gets paid (and Bob gets proof of
> payment a, which is the scalar to A), otherwise s_B is broadcasted and Bob
> gets paid (with Alice receiving b as PoP). An interesting note is that under
> this scheme neither party is forced to pay extra on-chain fees in the case of
> a counter-party who doesn't cooperate whilst in the wrong.
> One wrinkle with this scheme is that setup isn't trustless. Although it is
> generally true that one party must sign the funding transaction for a DLC
> before the other party for on-chain DLCs, at least there is the mitigation
> that when your counter-party goes silent, you can move your input funds
> invalidating the funding transaction you signed (at a cost because fees). So
> what can we do here to ensure that both payments are setup at the same time
> in the case that Alice and Bob don't trust each other?
> Say that although they don't trust each other, they're both willing to trust
> some escrow entity who generates some point E for their payment. Alice's
> payment point to Bob becomes B + S_B + E and Bob's to Alice becomes A + S_A +
> E. The escrow now waits to hear from Alice and Bob that they have incoming
> payments setup and only once both of them attest to this (using signatures,
> for example) does the escrow release the scalar to E to them both. The escrow
> can also have a timeout at which it will never reveal the scalar to E:
> forcing both parties to commit to the contract well before the DLC event. In
> this way, trust has been moved from counter-party to trustworthy (hopefully)
> escrow in such a way that the Escrow learns nothing about the contract itself
> (other than that there is one of some kind).
I think we can call this a "barrier escrow".
* It is similar to the concept of synchronization barriers for multithread
coordination: https://en.wikipedia.org/wiki/Barrier_(computer_science)
* In effect, each sub-transaction of the entire arrangement is a "thread" of
operation, and the "barrier escrow" ensures that all the threads have reached
it before letting them continue to claim the payments.
I seem, this is applicable to *not only* DLC, but others as well.
Instead, it seems to me to also provide an alternate solution to the
Premium-free American Call Option Problem.
Let us introduce our characters:
* B, a supposed buyer, holding some Bitcoin.
* S, a supposed seller, who wishes to be paid in another asset.
* X, a cross-currency exchange Lightning node.
* E, a tr\*sted escrow.
X would like to facilitate exchanges across different assets, but wants to be
paid a premium in order to prevent the Premium-free American Call Option
Problem.
B would like to swap its Bitcoin for another asset to pay S, and would be
willing to pay the above premium, but only conditional on S actually getting
the asset it wants to be paid in.
X and B are non-trusting to each other, but are willing to tr\*st escrow E.
This again is another "two transactions" setup, where we move tr\*st from X and
B and transfer it to E.
* B forwards the payment to be exchanged through X and onward to S, conditional
on receiving the scalar behind `S + E`.
* B gives a payment to X conditional on receiving the scalar behind `X + E`.
* X continues to forward the payment, in the target asset, to S.
* X contacts E and requests for the secret behind `E`.
* S, on receiving the incoming payment, contacts E and requests for the secret
behind `E`.
* As E has now received both requests, it releases the secret simultaneously to
both branches.
* S and X can now claim their payments.
Now, I would also like to observe the below fact:
* Proof-of-payment can be reconsidered, under payment point + scalar scheme, to
be "pay-for-scalar" scheme.
I would also like to point out the below assumption, which underlies Bass
Amplifier ("multipath payments", "base AMP") and its claim to atomicity:
* If we agree that my secret `s` is worth `m` millisatoshi, then I (as a
perfectly rational e
[Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
Hi list, I'm back again with another idea about Payment Points and fun things to do with them! Hopefully this time I'm not entirely just hashing out old ideas in public like an out-of-the-loop person :) *TLDR: Adding and ECDH-ing points gives us AND and OR functionality which we can compose to make cool lightning contracts like Multisig, Escrow, and DLCs* So when looking at the following (likely incomplete) list of things you can do with payment points: 1) Payment De-correlation 2) "Stuckless" Payments 3) High AMP 4) Selling Signatures 5) Selling Pedersen De-commitment 6) Escrow Contracts I started of trying to classify what kind of thing these new features are in hopes of coming across new ones. The first three I clumped into a group I called "Payment point addition allows us to do cool things while maintaining the Proof of Payment (PoP) property". The next two (4 and 5) I called "Commitment applications where point is public". But ZmnSCPxj's proposal for lightning escrow contracts ( https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002028.html) struck me as something different that might somehow be made more general. Essentially the idea is to use the point S + ECDH(B, E) where S is the seller's point, B is the buyer's point and E is the escrow's point. This means that the scalar can be discovered by the seller in collaboration with the buyer or the escrow, that is, S AND (B OR E). I propose that under certain circumstances (such as the parties involved being able to interact), this can be generalized to have payments conditioned on arbitrary AND/OR circuits. I believe that AND is very straightforward as you simply take two conditions A and B and add them together to get a point that requires both of their scalars are discoverable (except maybe under certain bad circumstances that can be avoided where like B = C - A, this must be guarded against). OR is harder but I think that it can be achieved in the two party case by ECDH and in the n-party case by multi-party key exchanges (which I know pretty much nothing about other than that they exist). Given some key exchange protocol (preferably non-interactive), KE, KE(A_1, ..., A_n) should result in a number known only to those who know any scalar a_1, ..., a_n and no one else. Assuming this exists and we can manage to trustlessly (in some possibly stretched sense of the word) compute shared keys (including such things as KE(A+B, C)), then KE(A, B) acts as A OR B in our payment condition contract. To restate the escrow contract idea in this setting, the payment is conditioned on S + KE(B, E). Important to note is that not all parties must know about the details of the payment itself: the Escrow in this example knows nothing about this payment (other than that some payment exists) unless there is a dispute. Lastly, note that contracts following this scheme look indistinguishable to normal payments on the network, and are fully compatible with High AMPs since we can simply take the payment point specified by our contract and add that point to each partial payment point. Well this is all nice in theory, but is there anything that will actually come out of this thinking? I'll detail the two things I've thought of so far for which I'd love critique! I'd also love to hear if anyone else things of any cool application using this line of thought (or really anything cool with payment points :P). Idea 1: "MultiSignature" Lightning Contracts I mean "MultiSignature" here only in the sense that m-of-n parties must agree to the payment in order for it to happen, no actual signatures are used. A "MultiSignature" contract is simply a bunch of ANDs and ORs! For example a 2-of-3 multisig between parties A, B, and C can be represented as (A AND B) OR (B AND C) OR (C AND A). As such, if some seller has a point S and three parties have points A, B, and C where a certain payment must go through if any two of them think it should, then the payment point used for the payment should be S + KE(A + B, B + C, C + A). We add S to this point so that the scalar, s, can act as proof of payment. And that's it! I haven't thought long enough to come up with any situation where this might be useful but hoping someone who reads this will! Idea 2: DLCs Routed over Lightning Say that some DLC oracle will either broadcast s_A or s_B whose public points are S_A and S_B (which can be computed from public information as per the DLC scheme). Then say that Alice and Bob enter into a contract under which Alice wins some amount if s_A is broadcasted and Bob if s_B is broadcasted. Say Alice has a point A and Bob has a point B. They each send the other a payment with the amount that party must receive if they win with the payment point A + S_A for Bob's payment to Alice and B + S_B for Alice's payment to Bob. And this is it! If s_A is broadcasted then Alice gets paid (and Bob gets proof of payment a, which is the scalar to A), otherwise s_B is broadcasted and Bob gets paid (
