Nadav Kohen [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-19 📝 Original message: Hi all, After having some ...
📅 Original date posted:2019-10-19
📝 Original message:
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 <ZmnSCPxj at protonmail.com> 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 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 attempt.
>
> >
> > 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)".
>
> Stuckless should be able to do this, if we compose it with AMP as I
> described above.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191019/4bb2a626/attachment-0001.html>;
📝 Original message:
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 <ZmnSCPxj at protonmail.com> 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 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 attempt.
>
> >
> > 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)".
>
> Stuckless should be able to do this, if we compose it with AMP as I
> described above.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191019/4bb2a626/attachment-0001.html>;