Nadav Kohen [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-10 📝 Original message: Hi list and ZmnSCPxj, ...
📅 Original date posted:2019-10-10
📝 Original message:
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 <ZmnSCPxj at protonmail.com> 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191010/7b38f17c/attachment.html>;
📝 Original message:
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 <ZmnSCPxj at protonmail.com> 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191010/7b38f17c/attachment.html>;