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
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
