ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-06 📝 Original message: Good morning Lloyd, I ...
📅 Original date posted:2019-05-06
📝 Original message:
Good morning Lloyd,
I think the most generic solution is to require multiple hashlocks.
One hashlock for the payee, the other for the exchange.
Payer acquires an exchange hash from the exchange, plus specs of the collateral.
Then payer routes to the payee via the exchange using two hashlocks (hashlock for the payment hash, hashlock for the exchange hash) and from the payee to the exchange.
The exchange onion hop includes the information that the cross-currency swap is allowed by pointing at the hashlock that the exchange hash is on.
The exchange verifies that it is one of the exchange hashes it has issued and it releases the agreed amount to the next hop, plus the collateral agreed upon.
The payee onion hop includes the information that it should proceed to give a single hashlock to succeeding hops, as well as the agreed-upon collateral to the exchange.
The exchange receives the payment with a single hashlock containing the value of the collateral.
It verifies that the collateral value is equal to the agreed collateral for that payment, then releases the exchange preimage.
The payee can then release its preimage once it has acquired the exchange preimage.
The above is similar to your solution, as it effectively means the payee offers collateral to the exchange, which it can only reclaim by properly completing the payment protocol.
The exchange can insist on getting a short timelock for receiving the collateral (i.e. limit the time horizon that the exchange hash is valid), to reduce the time horizon in which the payee can pay or not pay the collateral for the exchange (as before the payee releases the collateral, it still has the option of doing or not doing the swap, i.e. American Option).
The advantage is that it can go over multiple hops, and the exchange and payee do not know each other (but the payer does).
Disadvantage is that it requires two hashlocks, which is rather obvious on the protocol and signals "this payment is a cross-currency exchange payment!" to all intermediate nodes; also, it still allows a short time duration for American Option shenanigans.
The Route Maker solution by CJP is plausible, to me, only if the exchange and the Route Maker are the same, which is effectively what is done here, but now requires multiple secrets to be revealed.
I was thinking it might be possible, to use point/scalar and require the sum of the payment scalar and the exchange scalar, and thereby hide from intermediate nodes that multiple secrets are needed, but now the payer receives the sum of scalars instead of two separate preimages; this can make it difficult for protocols requiring proof-of-payment secrets (such as the offline vending machine discussed before) from working correctly.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, May 4, 2019 4:28 AM, Lloyd Fournier <lloyd.fourn at gmail.com> wrote:
> Hi ZmnSCPxj,
>
> I'm glad you pointed this out. I think this protocol is practical. That talk was actually given by my colleague :).
> My post in the December thread was trying to explain the same idea but as a [A -> Exchange -> A] on-chain trade (rather than a [A -> Exchange -> B] cross chain L2 payment). For reference: https://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def.
>
> I mentioned it was possible to do it in a channel. Although looking back at it now it seems I was somewhat confused at the time. I said:
>
> > As ZmnSCPxj demonstrated, the idea of sending a payment in asset A and the other party receiving it as asset B with some exchange node in the middle doing a conversion is unsound given what we are able to construct in Lightning.
>
> As you just showed, this is wrong. [A -> Exchange -> B] with the collateral on the last hop works fine. After all, [A -> Exchange -> A] is just a special case of [A -> Exchange -> B]. I agree that extending this idea across multiple hops after the exchange securely looks impossible.
>
> Note, the Exchange should watch carefully for their counter-party delaying in signing the channel update on the final hop (to gain value from the option this gives them). If they notice this they should close the channel and avoid doing business with this party.
> Despite this, it's still a far better protocol than the vanilla atomic swap because the delaying party has a far less time to realise any gains from the option. The exchange can put an end to it by closing the channel within 1 on chain tx.
>
> On naming. I think it's better to call it *collateral* rather than an *option premium* because it is only paid on a failure to execute the trade.
> I was thinking we can call them collateralized HTLCs.
>
> It's possible to modify the protocol slightly so that the party receiving the option pays the *premium* regardless of whether they release x or not. This makes it a proper cross chain option with guaranteed premium.
> We made a poster describing this idea here: https://coblox.tech/docs/financial_crypto19.pdf.
>
> Cheers,
>
> Lloyd
> On Tue, Apr 23, 2019 at 1:52 PM ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
> > Good morning list,
> >
> > Reviving an old thread, but I saw this just recently: http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/
> >
> > Suppose you are a BTC to WJT exchange.
> > I want to pay 1 BTC to send 1000000000 WJT to YAIjbOJA.
> > I have a BTC channel to you.
> > You have a WJT channel to YAIjbOJA.
> >
> > In order to create a properly-incentivized American Call Option with a premium, you insist that 10% of the WJT value be the premium that is paid if the exchange does not pull through.
> >
> > We perform this ritual:
> >
> > 1. YAIjbOJA generates a secret x and gives h(x) to me.
> > 2. On my channel to you, I get 1 BTC from my side and create an HTLC.
> > Hash is h(x) payable to you, timelock is 2 days payable to me.
> > 3. On your channel to YAIjbOJA, you get 1000000000 WJT from you, and 100000000 WJT (10%, the premium) from YAIjbOJA and create an HTLC.
> > Hash is h(x) payable to YAIjbOJA, timelock is 1 days payable to you.
> >
> > The above also forms an American Call Option, but with a premium if the payment does not push through.
> >
> > However, extending this to beyond one hop after the exchange node is difficult.
> > Problems in communicating with the next hop may cause the current hop after the exchange node to become liable for the premium without being able to forward the liability to the final payee, which is an avenue for attack.
> > And if the payee must be the hop after the exchange node, the exchange node now knows exactly how much and when that node receives payment, and can sell this information and/or selectively disrupt/censor some payments.
> >
> > Putting the premium before the exchange node is possible with an additional transaction spending the HTLC (the timelock branch is payable to a 2-of-2 with a pre-signed transaction that sends the premium to the exchange and returns the rest of the value to the payer).
> > But this is unsafe, since the exchange (and any node between the payer and the exchange) can stall the protocol deliberately and refuse to forward, extracting the premium via the timelock branch.
> > This is effectively forcing fees even in a route failure, which does not incentivize intermediate nodes to actually forward when they can do nothing and receive fees anyway for not routing.
> >
> > Regards,
> > ZmnSCPxj
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
Good morning Lloyd,
I think the most generic solution is to require multiple hashlocks.
One hashlock for the payee, the other for the exchange.
Payer acquires an exchange hash from the exchange, plus specs of the collateral.
Then payer routes to the payee via the exchange using two hashlocks (hashlock for the payment hash, hashlock for the exchange hash) and from the payee to the exchange.
The exchange onion hop includes the information that the cross-currency swap is allowed by pointing at the hashlock that the exchange hash is on.
The exchange verifies that it is one of the exchange hashes it has issued and it releases the agreed amount to the next hop, plus the collateral agreed upon.
The payee onion hop includes the information that it should proceed to give a single hashlock to succeeding hops, as well as the agreed-upon collateral to the exchange.
The exchange receives the payment with a single hashlock containing the value of the collateral.
It verifies that the collateral value is equal to the agreed collateral for that payment, then releases the exchange preimage.
The payee can then release its preimage once it has acquired the exchange preimage.
The above is similar to your solution, as it effectively means the payee offers collateral to the exchange, which it can only reclaim by properly completing the payment protocol.
The exchange can insist on getting a short timelock for receiving the collateral (i.e. limit the time horizon that the exchange hash is valid), to reduce the time horizon in which the payee can pay or not pay the collateral for the exchange (as before the payee releases the collateral, it still has the option of doing or not doing the swap, i.e. American Option).
The advantage is that it can go over multiple hops, and the exchange and payee do not know each other (but the payer does).
Disadvantage is that it requires two hashlocks, which is rather obvious on the protocol and signals "this payment is a cross-currency exchange payment!" to all intermediate nodes; also, it still allows a short time duration for American Option shenanigans.
The Route Maker solution by CJP is plausible, to me, only if the exchange and the Route Maker are the same, which is effectively what is done here, but now requires multiple secrets to be revealed.
I was thinking it might be possible, to use point/scalar and require the sum of the payment scalar and the exchange scalar, and thereby hide from intermediate nodes that multiple secrets are needed, but now the payer receives the sum of scalars instead of two separate preimages; this can make it difficult for protocols requiring proof-of-payment secrets (such as the offline vending machine discussed before) from working correctly.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, May 4, 2019 4:28 AM, Lloyd Fournier <lloyd.fourn at gmail.com> wrote:
> Hi ZmnSCPxj,
>
> I'm glad you pointed this out. I think this protocol is practical. That talk was actually given by my colleague :).
> My post in the December thread was trying to explain the same idea but as a [A -> Exchange -> A] on-chain trade (rather than a [A -> Exchange -> B] cross chain L2 payment). For reference: https://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def.
>
> I mentioned it was possible to do it in a channel. Although looking back at it now it seems I was somewhat confused at the time. I said:
>
> > As ZmnSCPxj demonstrated, the idea of sending a payment in asset A and the other party receiving it as asset B with some exchange node in the middle doing a conversion is unsound given what we are able to construct in Lightning.
>
> As you just showed, this is wrong. [A -> Exchange -> B] with the collateral on the last hop works fine. After all, [A -> Exchange -> A] is just a special case of [A -> Exchange -> B]. I agree that extending this idea across multiple hops after the exchange securely looks impossible.
>
> Note, the Exchange should watch carefully for their counter-party delaying in signing the channel update on the final hop (to gain value from the option this gives them). If they notice this they should close the channel and avoid doing business with this party.
> Despite this, it's still a far better protocol than the vanilla atomic swap because the delaying party has a far less time to realise any gains from the option. The exchange can put an end to it by closing the channel within 1 on chain tx.
>
> On naming. I think it's better to call it *collateral* rather than an *option premium* because it is only paid on a failure to execute the trade.
> I was thinking we can call them collateralized HTLCs.
>
> It's possible to modify the protocol slightly so that the party receiving the option pays the *premium* regardless of whether they release x or not. This makes it a proper cross chain option with guaranteed premium.
> We made a poster describing this idea here: https://coblox.tech/docs/financial_crypto19.pdf.
>
> Cheers,
>
> Lloyd
> On Tue, Apr 23, 2019 at 1:52 PM ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
> > Good morning list,
> >
> > Reviving an old thread, but I saw this just recently: http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/
> >
> > Suppose you are a BTC to WJT exchange.
> > I want to pay 1 BTC to send 1000000000 WJT to YAIjbOJA.
> > I have a BTC channel to you.
> > You have a WJT channel to YAIjbOJA.
> >
> > In order to create a properly-incentivized American Call Option with a premium, you insist that 10% of the WJT value be the premium that is paid if the exchange does not pull through.
> >
> > We perform this ritual:
> >
> > 1. YAIjbOJA generates a secret x and gives h(x) to me.
> > 2. On my channel to you, I get 1 BTC from my side and create an HTLC.
> > Hash is h(x) payable to you, timelock is 2 days payable to me.
> > 3. On your channel to YAIjbOJA, you get 1000000000 WJT from you, and 100000000 WJT (10%, the premium) from YAIjbOJA and create an HTLC.
> > Hash is h(x) payable to YAIjbOJA, timelock is 1 days payable to you.
> >
> > The above also forms an American Call Option, but with a premium if the payment does not push through.
> >
> > However, extending this to beyond one hop after the exchange node is difficult.
> > Problems in communicating with the next hop may cause the current hop after the exchange node to become liable for the premium without being able to forward the liability to the final payee, which is an avenue for attack.
> > And if the payee must be the hop after the exchange node, the exchange node now knows exactly how much and when that node receives payment, and can sell this information and/or selectively disrupt/censor some payments.
> >
> > Putting the premium before the exchange node is possible with an additional transaction spending the HTLC (the timelock branch is payable to a 2-of-2 with a pre-signed transaction that sends the premium to the exchange and returns the rest of the value to the payer).
> > But this is unsafe, since the exchange (and any node between the payer and the exchange) can stall the protocol deliberately and refuse to forward, extracting the premium via the timelock branch.
> > This is effectively forcing fees even in a route failure, which does not incentivize intermediate nodes to actually forward when they can do nothing and receive fees anyway for not routing.
> >
> > Regards,
> > ZmnSCPxj
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev