David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-04 📝 Original message: On Thu, Dec 27, 2018 at ...
📅 Original date posted:2019-01-04
📝 Original message:
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190104/09413fd9/attachment.sig>;
📝 Original message:
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190104/09413fd9/attachment.sig>;