📅 Original date posted:2019-01-05
📝 Original message:
Hi David and ZmnSCPxj,
ZmnSCPxj,
Thanks for your response. I messed something up with my response so my
original post didn't get into the archive. I put it in a gist:
https://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def for
reference.
> I agree.
> When I was developing American Call Options on top of onchain HTLCs, I
came up with a similar construction for ensuring that the premium is paid
before the HTLCs setting up the option appear onchain.
I would be interested to see how your construction worked. You can actually
modify the construction I gave before (in the gist) to create a fair option
too. You just change it so the asset `C` is paid on both branches of the
HTLC. This changes `C` from collateral to a premium. This sounds a bit
different to what you describe as the premium isn't paid before the HTLCs
go onto the chain.
The only other proposal for options I've seen is:
https://www.ics.uci.edu/~jamesal1/Swaptions.pdf. I could be missing
something, but this seems to give Alice a free option on an option in this
one. The premium payment has the option problem: Bob cannot cancel his
offer of an option but Alice can take her time to accept it.
> However, can such a scheme scale on-Lightning?
The scalability issue with the scheme in payment channels is the lack of
objective ordering of events in layer 2. If Alice and Bob disagree on
whether "Take Offer" or "Cancel Offer" happened first, they will have to
close their channel and resolve their dispute on the blockchain. This means
that channels may have to go to the blockchain much more often than if you
were just doing payments. In practice, this problem might not be so severe.
Parties that have frequent disputes will just tend to stop opening channels
with each other. It still guarantees that in the worst case there are no
long options for either party.
---
David,
> Instead of Alice's node just locally constructing this path and trying
> to pay it like normal, she first sends a special probe to Charlie
> requesting a new hash for which only he knows the preimage. With this
> hash plus the hash Alice received from Eliza, Alice sends a payment that
> requires both hashlocks be unlocked before anyone can claim the payment.
Moving the option from the random anonymous person (Alice) to the exchange
node is a good improvement. If participants become good at identifying
exchange nodes that delay in revealing the secret that might be enough to
make the cross asset payment idea practical.
As you hinted at, I think there is a simpler construction that is more
compatible with today's lightning:
1. Alice given `A` wants to send `B` to Bob with Charlie doing the exchange.
2. Charlie generates a secret `s` and makes a payment of `B` to Bob locked
under H(s)
3. Once Bob has the locked payment of `B` he sends H(s) to Alice
4. Alice then makes the payment of `A` under H(s) to Charlie.
5. Charlie now unlocks Alice's payment with `s` and receives `A`
6. Alice then learns `s` and sends it to Bob
7. Bob unlocks Charlie's payment with `s` and receives `B`
> In ZmnSCPxj's terminology, the option is now no longer
> free because Charlie must decide between potential routing income and
> potential option income
I didn't really get why the exchange would get any routing income from
this? The exchange is the receiver of a payment of BTC on one leg and the
sender of WJT on another. I'd expect the exchange would gain profit from
spreads rather than fees in these protocols.
Lloyd
\n
On Sat, Jan 5, 2019 at 6:01 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning David,
>
> What happens if the exchange node only sends its preimage towards the
> payer and not towards the payee?
>
> If the payer and payee do not coordinate, then it becomes possible for the
> exchange node to take the funds without the payee gaining the ability to
> claim the payment.
> This might be used by a node to take proofs of payment without paying, by
> simulating the payer and exchange nodes.
> This may be important if the proof of payment is valuable, such as, the
> mentioned offline Lightning vending machines, or if the preimage is the
> decryption key for valuable data (e.g. ransomware; now the ransomware
> author may find it is scammed off their potential earnings).
>
> Regards,
> ZmnSCPxj
>
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, January 5, 2019 5:05 AM, David A. Harding <dave at dtrt.org>
> wrote:
>
> > On Thu, Dec 27, 2018 at 05:43:51AM +0000, ZmnSCPxj via Lightning-dev
> wrote:
> >
> > > We can try to mitigate this, but the solutions below all have
> significant drawbacks.
> >
> > An alternative is to give the person making the exchange the ability to
> > cancel the payment if they think the exchange rate has changed
> > unfavorably for them. I think you could do that by adding an extra
> > hashlock to the HTLC that's controlled by the exchanger. For example,
> > here's what we'd expect a cross-asset path to look like:
> >
> > Alice Bob Charlie Dan Eliza
> > 1.3 mBTC -> 1.3 mBTC -> 1.2 mBTC
> >
> > 1.2 mWJT -> 1.1 mWJT -> 1.0 mWJT
> >
> >
> > Instead of Alice's node just locally constructing this path and trying
> > to pay it like normal, she first sends a special probe to Charlie
> > requesting a new hash for which only he knows the preimage. With this
> > hash plus the hash Alice received from Eliza, Alice sends a payment that
> > requires both hashlocks be unlocked before anyone can claim the payment.
> >
> > 1. When this payment reaches the exchanger, Charlie, he checks that the
> > payment includes a hashlock he controls before routing the payment
> on to
> > a different asset.
> >
> > 2. When the payment reaches receiver Eliza's node, she releases her
> > PreImage (PI0) back along the path.
> >
> > 3. When Eliza's preimage reaches exchanger Charlie's node, he releases
> > his preimage (PI1) in both directions along the path and continues
> > forwarding PI0 backwards. Eventually everyone receives both preimages
> > through the usual offchain or onchain mechanisms.
> >
> > Alice Bob Charlie Dan Eliza
> > PI0 <- PI0 <- PI0 <- PI0 <- PI0 (start here)
> > PI1 <- PI1 <- PI1 -> PI1 -> PI1
> >
> >
> > However, if the exchange rate changes too much for Charlie's comfort
> > before both preimages have been released, Charlie can unilaterally
> > decide to cancel the payment by simply not releasing his preimage.
> >
> > Note that by making the payment contingent on the approval of the
> > exchanger, the ability to create an underhanded call option is
> > transferred to the exchanger. However, this may be less concerning
> > because the exchanger can only keep this option open by refusing to
> > immediately claim the routing fees.
> >
> > For example, our exchanger Charlie is being offered 0.1 mBTC to route
> > the payment (a made up number). If he can route 100 such payments in a
> > day (another made up number), he can earn 10.0 mBTC from routing. By
> > comparison, if he delays a payment of 1.2 mBTC, he'd need to expect the
> > exchange rate to change by an order of magnitude within a day to earn
> > the same amount. In ZmnSCPxj's terminology, the option is now no longer
> > free because Charlie must decide between potential routing income and
> > potential option income. Whether or not exchangers play the option game
> > will therefore likely be based on the amount of honest routing income
> > they can earn relative to the exchange rate volatility (and also on how
> > good nodes get at tracking reliable routes).
> >
> > This idea certainly complicates the current protocol (both routing and
> > transaction construction), but maybe there are simplifications
> > available.
> >
> > -Dave
>
>
> _______________________________________________
> 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/20190105/3dc2a953/attachment-0001.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 12:53:45
in reply to nevent1q…n9mg
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 12:53:45Event JSON
{
"id": "871e1ac9c214a7862e3f5d2ed07eeda0c91ff60fb36e5e733af7607f362b0471",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315225,
"kind": 1,
"tags": [
[
"e",
"ca4ba408a7f58042d7f13af4ffdac9ce35c46314a12c4b25cf60835498578c43",
"",
"root"
],
[
"e",
"6fc044d59650297ba21d3fb03ee3ef69345f58dbe2cb50dc9b129e57fc91ad09",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2019-01-05\n📝 Original message:\nHi David and ZmnSCPxj,\n\nZmnSCPxj,\n\nThanks for your response. I messed something up with my response so my\noriginal post didn't get into the archive. I put it in a gist:\nhttps://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def for\nreference.\n\n\u003e I agree.\n\u003e When I was developing American Call Options on top of onchain HTLCs, I\ncame up with a similar construction for ensuring that the premium is paid\nbefore the HTLCs setting up the option appear onchain.\n\nI would be interested to see how your construction worked. You can actually\nmodify the construction I gave before (in the gist) to create a fair option\ntoo. You just change it so the asset `C` is paid on both branches of the\nHTLC. This changes `C` from collateral to a premium. This sounds a bit\ndifferent to what you describe as the premium isn't paid before the HTLCs\ngo onto the chain.\n\nThe only other proposal for options I've seen is:\nhttps://www.ics.uci.edu/~jamesal1/Swaptions.pdf. I could be missing\nsomething, but this seems to give Alice a free option on an option in this\none. The premium payment has the option problem: Bob cannot cancel his\noffer of an option but Alice can take her time to accept it.\n\n\u003e However, can such a scheme scale on-Lightning?\n\nThe scalability issue with the scheme in payment channels is the lack of\nobjective ordering of events in layer 2. If Alice and Bob disagree on\nwhether \"Take Offer\" or \"Cancel Offer\" happened first, they will have to\nclose their channel and resolve their dispute on the blockchain. This means\nthat channels may have to go to the blockchain much more often than if you\nwere just doing payments. In practice, this problem might not be so severe.\nParties that have frequent disputes will just tend to stop opening channels\nwith each other. It still guarantees that in the worst case there are no\nlong options for either party.\n\n---\nDavid,\n\n\u003e Instead of Alice's node just locally constructing this path and trying\n\u003e to pay it like normal, she first sends a special probe to Charlie\n\u003e requesting a new hash for which only he knows the preimage. With this\n\u003e hash plus the hash Alice received from Eliza, Alice sends a payment that\n\u003e requires both hashlocks be unlocked before anyone can claim the payment.\n\nMoving the option from the random anonymous person (Alice) to the exchange\nnode is a good improvement. If participants become good at identifying\nexchange nodes that delay in revealing the secret that might be enough to\nmake the cross asset payment idea practical.\n\nAs you hinted at, I think there is a simpler construction that is more\ncompatible with today's lightning:\n1. Alice given `A` wants to send `B` to Bob with Charlie doing the exchange.\n2. Charlie generates a secret `s` and makes a payment of `B` to Bob locked\nunder H(s)\n3. Once Bob has the locked payment of `B` he sends H(s) to Alice\n4. Alice then makes the payment of `A` under H(s) to Charlie.\n5. Charlie now unlocks Alice's payment with `s` and receives `A`\n6. Alice then learns `s` and sends it to Bob\n7. Bob unlocks Charlie's payment with `s` and receives `B`\n\n\u003e In ZmnSCPxj's terminology, the option is now no longer\n\u003e free because Charlie must decide between potential routing income and\n\u003e potential option income\n\nI didn't really get why the exchange would get any routing income from\nthis? The exchange is the receiver of a payment of BTC on one leg and the\nsender of WJT on another. I'd expect the exchange would gain profit from\nspreads rather than fees in these protocols.\n\nLloyd\n\n\\n\n\nOn Sat, Jan 5, 2019 at 6:01 PM ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning David,\n\u003e\n\u003e What happens if the exchange node only sends its preimage towards the\n\u003e payer and not towards the payee?\n\u003e\n\u003e If the payer and payee do not coordinate, then it becomes possible for the\n\u003e exchange node to take the funds without the payee gaining the ability to\n\u003e claim the payment.\n\u003e This might be used by a node to take proofs of payment without paying, by\n\u003e simulating the payer and exchange nodes.\n\u003e This may be important if the proof of payment is valuable, such as, the\n\u003e mentioned offline Lightning vending machines, or if the preimage is the\n\u003e decryption key for valuable data (e.g. ransomware; now the ransomware\n\u003e author may find it is scammed off their potential earnings).\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e\n\u003e Sent with ProtonMail Secure Email.\n\u003e\n\u003e ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\n\u003e On Saturday, January 5, 2019 5:05 AM, David A. Harding \u003cdave at dtrt.org\u003e\n\u003e wrote:\n\u003e\n\u003e \u003e On Thu, Dec 27, 2018 at 05:43:51AM +0000, ZmnSCPxj via Lightning-dev\n\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e We can try to mitigate this, but the solutions below all have\n\u003e significant drawbacks.\n\u003e \u003e\n\u003e \u003e An alternative is to give the person making the exchange the ability to\n\u003e \u003e cancel the payment if they think the exchange rate has changed\n\u003e \u003e unfavorably for them. I think you could do that by adding an extra\n\u003e \u003e hashlock to the HTLC that's controlled by the exchanger. For example,\n\u003e \u003e here's what we'd expect a cross-asset path to look like:\n\u003e \u003e\n\u003e \u003e Alice Bob Charlie Dan Eliza\n\u003e \u003e 1.3 mBTC -\u003e 1.3 mBTC -\u003e 1.2 mBTC\n\u003e \u003e\n\u003e \u003e 1.2 mWJT -\u003e 1.1 mWJT -\u003e 1.0 mWJT\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Instead of Alice's node just locally constructing this path and trying\n\u003e \u003e to pay it like normal, she first sends a special probe to Charlie\n\u003e \u003e requesting a new hash for which only he knows the preimage. With this\n\u003e \u003e hash plus the hash Alice received from Eliza, Alice sends a payment that\n\u003e \u003e requires both hashlocks be unlocked before anyone can claim the payment.\n\u003e \u003e\n\u003e \u003e 1. When this payment reaches the exchanger, Charlie, he checks that the\n\u003e \u003e payment includes a hashlock he controls before routing the payment\n\u003e on to\n\u003e \u003e a different asset.\n\u003e \u003e\n\u003e \u003e 2. When the payment reaches receiver Eliza's node, she releases her\n\u003e \u003e PreImage (PI0) back along the path.\n\u003e \u003e\n\u003e \u003e 3. When Eliza's preimage reaches exchanger Charlie's node, he releases\n\u003e \u003e his preimage (PI1) in both directions along the path and continues\n\u003e \u003e forwarding PI0 backwards. Eventually everyone receives both preimages\n\u003e \u003e through the usual offchain or onchain mechanisms.\n\u003e \u003e\n\u003e \u003e Alice Bob Charlie Dan Eliza\n\u003e \u003e PI0 \u003c- PI0 \u003c- PI0 \u003c- PI0 \u003c- PI0 (start here)\n\u003e \u003e PI1 \u003c- PI1 \u003c- PI1 -\u003e PI1 -\u003e PI1\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e However, if the exchange rate changes too much for Charlie's comfort\n\u003e \u003e before both preimages have been released, Charlie can unilaterally\n\u003e \u003e decide to cancel the payment by simply not releasing his preimage.\n\u003e \u003e\n\u003e \u003e Note that by making the payment contingent on the approval of the\n\u003e \u003e exchanger, the ability to create an underhanded call option is\n\u003e \u003e transferred to the exchanger. However, this may be less concerning\n\u003e \u003e because the exchanger can only keep this option open by refusing to\n\u003e \u003e immediately claim the routing fees.\n\u003e \u003e\n\u003e \u003e For example, our exchanger Charlie is being offered 0.1 mBTC to route\n\u003e \u003e the payment (a made up number). If he can route 100 such payments in a\n\u003e \u003e day (another made up number), he can earn 10.0 mBTC from routing. By\n\u003e \u003e comparison, if he delays a payment of 1.2 mBTC, he'd need to expect the\n\u003e \u003e exchange rate to change by an order of magnitude within a day to earn\n\u003e \u003e the same amount. In ZmnSCPxj's terminology, the option is now no longer\n\u003e \u003e free because Charlie must decide between potential routing income and\n\u003e \u003e potential option income. Whether or not exchangers play the option game\n\u003e \u003e will therefore likely be based on the amount of honest routing income\n\u003e \u003e they can earn relative to the exchange rate volatility (and also on how\n\u003e \u003e good nodes get at tracking reliable routes).\n\u003e \u003e\n\u003e \u003e This idea certainly complicates the current protocol (both routing and\n\u003e \u003e transaction construction), but maybe there are simplifications\n\u003e \u003e available.\n\u003e \u003e\n\u003e \u003e -Dave\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190105/3dc2a953/attachment-0001.html\u003e",
"sig": "4fa5b6f2738abb8f4ed5dbea20f833e7c57a4454595d733fd01de45738c900b9393041f18b7bd16947ad98c29c9f29e2c776a75abe11bf30d532f67bd47fc2b6"
}