ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-02 📝 Original message: Good morning Lloyd, > ...
📅 Original date posted:2019-01-02
📝 Original message:
Good morning Lloyd,
> Therefore, the ideal abstract functionality we want is:
>
> 1. *Make Offer* Alice makes an offer to Bob to trade `A` for `B`
> 2. *Take Offer* Bob can take the offer (if Alice hasn't already cancelled it) and get `A` in exchange for `B`.
> 3. *Cancel Offer* If Bob hasn't taken the offer, Alice may get back `A` by cancelling the offer
>
> I developed the protocol below which comes pretty close to realising this.
> Let
> - α and β and be two bitcoin-like blockchains
> - Alice own asset `A` on the α blockchain and `C` on the β blockchain
> - Bob own asset `B` on the β blockchain
>
> 1. Alice puts the HTLC for `A` on α and waits for it to confirm (as per usual)
> 2. Alice creates a partial β blockchain transaction by signing one input and one output (using SIGHASH_SINGLE for example):
> - The input is the asset `C`
> - The output is a HTLC which gives `B` and `C` to herself with the secret or gives them both to Bob on timeout
> She sends this partial transaction to Bob. (This gives us the "Make Offer" functionality)
> 3. If Bob wants to accept the offer, he adds asset `B` to another input of the transaction and posts it to β. (This gives us "Take Offer" functionality)
> 4. If Alice wishes to cancel the trade before Bob has confirmed this transaction she double spends the `C` output and then reclaims `A` on α after the timeout. (This gives us the "Cancel Offer" functionality)
> 5. If the "Take Offer" transaction is confirmed on β, Alice must unlock the HTLC before the timeout or Bob will gain `C` AND get back `B`.
> 6. Once she reveals the secret, she both gets back `C` and gains `B` on β.
> 7. Bob can now take `A` on α in the usual manner now that he has learned the secret.
>
> Bob is not guaranteed to get `A` after he "takes" the offer but he is guaranteed to get `A` (in exchange for `B`) or `C` (for free). Obviously, `C` is Alice's collateral for the trade. Bob should only take the offer if he wants `A` more than `B` and if he is sure that the value of gaining `C` will be greater than any loss he could experience from `B` depreciating relative to `A` during the execution of the protocol.
>
> I believe this shows that HTLCs do not in cause options but rather uncancelable offers + uncollateralized HTLCs cause the option problem.
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.
However, can such a scheme scale on-Lightning?
>
> I think this protocol works in payment channels in the case that Alice and Bob have direct channels to each other. The issue is that if Alice decides she wants to cancel at the same time Bob decides he wants to take it you have to go to the blockchain to resolve the issue (which will be rather arbitrary). CJP's idea of having a 3rd party who is trusted simply to compute the outcome of a offer (cancelled or taken) in layer 2 networks seems like a promising direction because this would avoid on-chain resolution in this case.
>
> Cross Asset Payments Don't Make Sense
> ====================================
>
> 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.
>
> But this doesn't necessarily mean that Lightning has to be single asset. Theoretically, a single two-party channel could record multiple asset types with a state transaction that has distinct outputs for different asset-type/party combinations. This would allow you to buy an amount of the desired asset in one of your channels by simply doing a state update where you lose `A` in exchange for `B` with your direct peer (no HTLCs needed). You can then just send `B` normally to the receiver. This is not quite as good as a cross asset payment but it could still be useful*.
It may be possible with RGB. However, you still need some kind of route from yourself to the payee, and the entire route from payer to payee needs to be liquid for the target asset. If there is no viable route where all channels have the asset, then the payment cannot push through.
In addition, this cannot be a cross-blockchain asset, since channels can exist on exactly one blockchain or other cryptocurrency system.
Regards,
ZmnSCPxj
📝 Original message:
Good morning Lloyd,
> Therefore, the ideal abstract functionality we want is:
>
> 1. *Make Offer* Alice makes an offer to Bob to trade `A` for `B`
> 2. *Take Offer* Bob can take the offer (if Alice hasn't already cancelled it) and get `A` in exchange for `B`.
> 3. *Cancel Offer* If Bob hasn't taken the offer, Alice may get back `A` by cancelling the offer
>
> I developed the protocol below which comes pretty close to realising this.
> Let
> - α and β and be two bitcoin-like blockchains
> - Alice own asset `A` on the α blockchain and `C` on the β blockchain
> - Bob own asset `B` on the β blockchain
>
> 1. Alice puts the HTLC for `A` on α and waits for it to confirm (as per usual)
> 2. Alice creates a partial β blockchain transaction by signing one input and one output (using SIGHASH_SINGLE for example):
> - The input is the asset `C`
> - The output is a HTLC which gives `B` and `C` to herself with the secret or gives them both to Bob on timeout
> She sends this partial transaction to Bob. (This gives us the "Make Offer" functionality)
> 3. If Bob wants to accept the offer, he adds asset `B` to another input of the transaction and posts it to β. (This gives us "Take Offer" functionality)
> 4. If Alice wishes to cancel the trade before Bob has confirmed this transaction she double spends the `C` output and then reclaims `A` on α after the timeout. (This gives us the "Cancel Offer" functionality)
> 5. If the "Take Offer" transaction is confirmed on β, Alice must unlock the HTLC before the timeout or Bob will gain `C` AND get back `B`.
> 6. Once she reveals the secret, she both gets back `C` and gains `B` on β.
> 7. Bob can now take `A` on α in the usual manner now that he has learned the secret.
>
> Bob is not guaranteed to get `A` after he "takes" the offer but he is guaranteed to get `A` (in exchange for `B`) or `C` (for free). Obviously, `C` is Alice's collateral for the trade. Bob should only take the offer if he wants `A` more than `B` and if he is sure that the value of gaining `C` will be greater than any loss he could experience from `B` depreciating relative to `A` during the execution of the protocol.
>
> I believe this shows that HTLCs do not in cause options but rather uncancelable offers + uncollateralized HTLCs cause the option problem.
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.
However, can such a scheme scale on-Lightning?
>
> I think this protocol works in payment channels in the case that Alice and Bob have direct channels to each other. The issue is that if Alice decides she wants to cancel at the same time Bob decides he wants to take it you have to go to the blockchain to resolve the issue (which will be rather arbitrary). CJP's idea of having a 3rd party who is trusted simply to compute the outcome of a offer (cancelled or taken) in layer 2 networks seems like a promising direction because this would avoid on-chain resolution in this case.
>
> Cross Asset Payments Don't Make Sense
> ====================================
>
> 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.
>
> But this doesn't necessarily mean that Lightning has to be single asset. Theoretically, a single two-party channel could record multiple asset types with a state transaction that has distinct outputs for different asset-type/party combinations. This would allow you to buy an amount of the desired asset in one of your channels by simply doing a state update where you lose `A` in exchange for `B` with your direct peer (no HTLCs needed). You can then just send `B` normally to the receiver. This is not quite as good as a cross asset payment but it could still be useful*.
It may be possible with RGB. However, you still need some kind of route from yourself to the payee, and the entire route from payer to payee needs to be liquid for the target asset. If there is no viable route where all channels have the asset, then the payment cannot push through.
In addition, this cannot be a cross-blockchain asset, since channels can exist on exactly one blockchain or other cryptocurrency system.
Regards,
ZmnSCPxj