ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-15 📝 Original message: Good morning Jonas, ...
📅 Original date posted:2019-10-15
📝 Original message:
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
📝 Original message:
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