📅 Original date posted:2019-05-19
📝 Original message:
Hi ZmnSCPxj,
Sorry for the late reply I only recently had time to review your comments.
I didn't really get your motivation for multiple secrets. In my mind,
having the last hop put collateral into the HTLC to make a *Collateralized
HTLC* solves the problem without any extra complexity (your original
example captures this perfectly). You wrote:
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).
I think this unnecessary. The "free option" time isn't limited by a
timelock (if it was, we wouldn't have solved the problem). The option is
limited by the exchange's willingness to wait for the other party to sign
the state update (assuming the exchange signs first). The minor point I was
trying to make was that normally when routing payments etc you can be
willing to wait for minutes or hours for the other party to come back
online if they went offline during a state update. But if you are doing a
swap and your partner is meant to be signing a collateralized HTLC you
shouldn't wait; you should force settlement to the blockchain within a few
seconds. As soon as the state gets onto the blockchain the other party has
lost any chance of getting an option.
At a glance, the simplest way to enable this functionality is to add a new
field to the "update_add_htlc" BOLT message [1] like
"collateral_amount_sat". The receiver of "collateral_amount_sat" would have
to contribute that amount to the HTLC (if they are willing to go through
with the update). Obviously you should only ever agree to do this if you
are last hop or are willing to risk your collateral on the honest behaviour
of nodes further down.
I was actually wondering if this could be a useful feature outside of
swaps. e.g. if there is a new node without much reputation who you are
routing a payment to, you could demand that they put up collateral into the
HLTC to receive the payment. This might help prevent attacks where people
try and tie up funds by receiving large payments they never release the
secrets for.
WRT to your final comments, it sounds a bit like [2] which also mentions
that their protocol can make atomic swaps fungible.
1.
https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc
2. Anonymous Multi-Hop Locks for Blockchain Scalability and
Interoperability: https://eprint.iacr.org/2018/472.pdf
Cheers,
Lloyd
On Mon, May 6, 2019 at 2:51 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190519/b8ffbfb6/attachment-0001.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 12:54:57
in reply to nevent1q…xl65
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 12:54:57Event JSON
{
"id": "43566a11d52600d161d68bd268a6c6ce7bbdd478dc2fcb5f84c562d07e4ebe67",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315297,
"kind": 1,
"tags": [
[
"e",
"e949cd5071c2265b93a06e878cb0573f324d4a16f94106fbf2cf90e9320dd73f",
"",
"root"
],
[
"e",
"0aefa7445556c3240349b23f3c08a2cd49a978fd6e279e5d800d3131dc9bfa17",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2019-05-19\n📝 Original message:\nHi ZmnSCPxj,\n\nSorry for the late reply I only recently had time to review your comments.\nI didn't really get your motivation for multiple secrets. In my mind,\nhaving the last hop put collateral into the HTLC to make a *Collateralized\nHTLC* solves the problem without any extra complexity (your original\nexample captures this perfectly). You wrote:\n\nThe exchange can insist on getting a short timelock for receiving the\n\u003e collateral (i.e. limit the time horizon that the exchange hash is valid),\n\u003e to reduce the time horizon in which the payee can pay or not pay the\n\u003e collateral for the exchange (as before the payee releases the collateral,\n\u003e it still has the option of doing or not doing the swap, i.e. American\n\u003e Option).\n\n\nI think this unnecessary. The \"free option\" time isn't limited by a\ntimelock (if it was, we wouldn't have solved the problem). The option is\nlimited by the exchange's willingness to wait for the other party to sign\nthe state update (assuming the exchange signs first). The minor point I was\ntrying to make was that normally when routing payments etc you can be\nwilling to wait for minutes or hours for the other party to come back\nonline if they went offline during a state update. But if you are doing a\nswap and your partner is meant to be signing a collateralized HTLC you\nshouldn't wait; you should force settlement to the blockchain within a few\nseconds. As soon as the state gets onto the blockchain the other party has\nlost any chance of getting an option.\n\nAt a glance, the simplest way to enable this functionality is to add a new\nfield to the \"update_add_htlc\" BOLT message [1] like\n\"collateral_amount_sat\". The receiver of \"collateral_amount_sat\" would have\nto contribute that amount to the HTLC (if they are willing to go through\nwith the update). Obviously you should only ever agree to do this if you\nare last hop or are willing to risk your collateral on the honest behaviour\nof nodes further down.\n\nI was actually wondering if this could be a useful feature outside of\nswaps. e.g. if there is a new node without much reputation who you are\nrouting a payment to, you could demand that they put up collateral into the\nHLTC to receive the payment. This might help prevent attacks where people\ntry and tie up funds by receiving large payments they never release the\nsecrets for.\n\nWRT to your final comments, it sounds a bit like [2] which also mentions\nthat their protocol can make atomic swaps fungible.\n\n1.\nhttps://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc\n2. Anonymous Multi-Hop Locks for Blockchain Scalability and\nInteroperability: https://eprint.iacr.org/2018/472.pdf\n\nCheers,\n\nLloyd\n\nOn Mon, May 6, 2019 at 2:51 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning Lloyd,\n\u003e\n\u003e I think the most generic solution is to require multiple hashlocks.\n\u003e One hashlock for the payee, the other for the exchange.\n\u003e\n\u003e Payer acquires an exchange hash from the exchange, plus specs of the\n\u003e collateral.\n\u003e Then payer routes to the payee via the exchange using two hashlocks\n\u003e (hashlock for the payment hash, hashlock for the exchange hash) and from\n\u003e the payee to the exchange.\n\u003e The exchange onion hop includes the information that the cross-currency\n\u003e swap is allowed by pointing at the hashlock that the exchange hash is on.\n\u003e The exchange verifies that it is one of the exchange hashes it has issued\n\u003e and it releases the agreed amount to the next hop, plus the collateral\n\u003e agreed upon.\n\u003e\n\u003e The payee onion hop includes the information that it should proceed to\n\u003e give a single hashlock to succeeding hops, as well as the agreed-upon\n\u003e collateral to the exchange.\n\u003e The exchange receives the payment with a single hashlock containing the\n\u003e value of the collateral.\n\u003e It verifies that the collateral value is equal to the agreed collateral\n\u003e for that payment, then releases the exchange preimage.\n\u003e The payee can then release its preimage once it has acquired the exchange\n\u003e preimage.\n\u003e\n\u003e The above is similar to your solution, as it effectively means the payee\n\u003e offers collateral to the exchange, which it can only reclaim by properly\n\u003e completing the payment protocol.\n\u003e The exchange can insist on getting a short timelock for receiving the\n\u003e collateral (i.e. limit the time horizon that the exchange hash is valid),\n\u003e to reduce the time horizon in which the payee can pay or not pay the\n\u003e collateral for the exchange (as before the payee releases the collateral,\n\u003e it still has the option of doing or not doing the swap, i.e. American\n\u003e Option).\n\u003e The advantage is that it can go over multiple hops, and the exchange and\n\u003e payee do not know each other (but the payer does).\n\u003e Disadvantage is that it requires two hashlocks, which is rather obvious on\n\u003e the protocol and signals \"this payment is a cross-currency exchange\n\u003e payment!\" to all intermediate nodes; also, it still allows a short time\n\u003e duration for American Option shenanigans.\n\u003e\n\u003e The Route Maker solution by CJP is plausible, to me, only if the exchange\n\u003e and the Route Maker are the same, which is effectively what is done here,\n\u003e but now requires multiple secrets to be revealed.\n\u003e\n\u003e I was thinking it might be possible, to use point/scalar and require the\n\u003e sum of the payment scalar and the exchange scalar, and thereby hide from\n\u003e intermediate nodes that multiple secrets are needed, but now the payer\n\u003e receives the sum of scalars instead of two separate preimages; this can\n\u003e make it difficult for protocols requiring proof-of-payment secrets (such as\n\u003e the offline vending machine discussed before) from working correctly.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e Sent with ProtonMail Secure Email.\n\u003e\n\u003e ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\n\u003e On Saturday, May 4, 2019 4:28 AM, Lloyd Fournier \u003clloyd.fourn at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e \u003e Hi ZmnSCPxj,\n\u003e \u003e\n\u003e \u003e I'm glad you pointed this out. I think this protocol is practical. That\n\u003e talk was actually given by my colleague :).\n\u003e \u003e My post in the December thread was trying to explain the same idea but\n\u003e as a [A -\u003e Exchange -\u003e A] on-chain trade (rather than a [A -\u003e Exchange -\u003e\n\u003e B] cross chain L2 payment). For reference:\n\u003e https://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def.\n\u003e \u003e\n\u003e \u003e I mentioned it was possible to do it in a channel. Although looking back\n\u003e at it now it seems I was somewhat confused at the time. I said:\n\u003e \u003e\n\u003e \u003e \u003e As ZmnSCPxj demonstrated, the idea of sending a payment in asset A and\n\u003e the other party receiving it as asset B with some exchange node in the\n\u003e middle doing a conversion is unsound given what we are able to construct in\n\u003e Lightning.\n\u003e \u003e\n\u003e \u003e As you just showed, this is wrong. [A -\u003e Exchange -\u003e B] with the\n\u003e collateral on the last hop works fine. After all, [A -\u003e Exchange -\u003e A] is\n\u003e just a special case of [A -\u003e Exchange -\u003e B]. I agree that extending this\n\u003e idea across multiple hops after the exchange securely looks impossible.\n\u003e \u003e\n\u003e \u003e Note, the Exchange should watch carefully for their counter-party\n\u003e delaying in signing the channel update on the final hop (to gain value from\n\u003e the option this gives them). If they notice this they should close the\n\u003e channel and avoid doing business with this party.\n\u003e \u003e Despite this, it's still a far better protocol than the vanilla atomic\n\u003e swap because the delaying party has a far less time to realise any gains\n\u003e from the option. The exchange can put an end to it by closing the channel\n\u003e within 1 on chain tx.\n\u003e \u003e\n\u003e \u003e On naming. I think it's better to call it *collateral* rather than an\n\u003e *option premium* because it is only paid on a failure to execute the trade.\n\u003e \u003e I was thinking we can call them collateralized HTLCs.\n\u003e \u003e\n\u003e \u003e It's possible to modify the protocol slightly so that the party\n\u003e receiving the option pays the *premium* regardless of whether they release\n\u003e x or not. This makes it a proper cross chain option with guaranteed premium.\n\u003e \u003e We made a poster describing this idea here:\n\u003e https://coblox.tech/docs/financial_crypto19.pdf.\n\u003e \u003e\n\u003e \u003e Cheers,\n\u003e \u003e\n\u003e \u003e Lloyd\n\u003e \u003e On Tue, Apr 23, 2019 at 1:52 PM ZmnSCPxj via Lightning-dev \u003c\n\u003e lightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e Good morning list,\n\u003e \u003e \u003e\n\u003e \u003e \u003e Reviving an old thread, but I saw this just recently:\n\u003e http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/\n\u003e \u003e \u003e\n\u003e \u003e \u003e Suppose you are a BTC to WJT exchange.\n\u003e \u003e \u003e I want to pay 1 BTC to send 1000000000 WJT to YAIjbOJA.\n\u003e \u003e \u003e I have a BTC channel to you.\n\u003e \u003e \u003e You have a WJT channel to YAIjbOJA.\n\u003e \u003e \u003e\n\u003e \u003e \u003e In order to create a properly-incentivized American Call Option with a\n\u003e premium, you insist that 10% of the WJT value be the premium that is paid\n\u003e if the exchange does not pull through.\n\u003e \u003e \u003e\n\u003e \u003e \u003e We perform this ritual:\n\u003e \u003e \u003e\n\u003e \u003e \u003e 1. YAIjbOJA generates a secret x and gives h(x) to me.\n\u003e \u003e \u003e 2. On my channel to you, I get 1 BTC from my side and create an HTLC.\n\u003e \u003e \u003e Hash is h(x) payable to you, timelock is 2 days payable to me.\n\u003e \u003e \u003e 3. On your channel to YAIjbOJA, you get 1000000000 WJT from you, and\n\u003e 100000000 WJT (10%, the premium) from YAIjbOJA and create an HTLC.\n\u003e \u003e \u003e Hash is h(x) payable to YAIjbOJA, timelock is 1 days payable to\n\u003e you.\n\u003e \u003e \u003e\n\u003e \u003e \u003e The above also forms an American Call Option, but with a premium if\n\u003e the payment does not push through.\n\u003e \u003e \u003e\n\u003e \u003e \u003e However, extending this to beyond one hop after the exchange node is\n\u003e difficult.\n\u003e \u003e \u003e Problems in communicating with the next hop may cause the current hop\n\u003e after the exchange node to become liable for the premium without being able\n\u003e to forward the liability to the final payee, which is an avenue for attack.\n\u003e \u003e \u003e And if the payee must be the hop after the exchange node, the exchange\n\u003e node now knows exactly how much and when that node receives payment, and\n\u003e can sell this information and/or selectively disrupt/censor some payments.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Putting the premium before the exchange node is possible with an\n\u003e additional transaction spending the HTLC (the timelock branch is payable to\n\u003e a 2-of-2 with a pre-signed transaction that sends the premium to the\n\u003e exchange and returns the rest of the value to the payer).\n\u003e \u003e \u003e But this is unsafe, since the exchange (and any node between the payer\n\u003e and the exchange) can stall the protocol deliberately and refuse to\n\u003e forward, extracting the premium via the timelock branch.\n\u003e \u003e \u003e This is effectively forcing fees even in a route failure, which does\n\u003e not incentivize intermediate nodes to actually forward when they can do\n\u003e nothing and receive fees anyway for not routing.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Regards,\n\u003e \u003e \u003e ZmnSCPxj\n\u003e \u003e \u003e _______________________________________________\n\u003e \u003e \u003e Lightning-dev mailing list\n\u003e \u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190519/b8ffbfb6/attachment-0001.html\u003e",
"sig": "bf4bbf67f15be62aead2fba4fd1693006cd025102dcae5975e9ceab7163e84326d4795e372593c35e3b0b2aa252b331e79cd73cc6e5fb03ac5c47c45322df259"
}