Public redemption with known secret

[birnbuazn]

Open/unresolved questions

• In the current design of your HTLCs, anybody who knows the secret, can redeem the asset. The redeem_identity is baked into the contract, so nobody but the intended recipient can get the money, but it still feels wrong that anybody could trigger the process. What if the secret has been leaked and the recipient doesn’t want to redeem?

[D4nte]

Thank you for your question/feedback!
Let's have a look in more details:

Bitcoin

In the Bitcoin HTLC we can see that a OP_CHECKSIG op is used for both the redeem and refund path.

Which means that to create a transaction valid to spend the HTLC output, a valid signature of the inputs/outputs needs to be provided.
Only the holder of the private key matching the pubkey hash present in the script is able to provide such signature, hence, only the receiver of Bitcoin funds can trigger the redeem. Check out our Bitcoin blog post for more details.

Ethereum

Yes, it is absolutely true. Anyone can trigger the redeem path of the Ether HTLC given that they know the secret.
The Ether (or ERC20 token) will be sent to the pre-defined address in the HTLC.
This means that the participant receiving Ether could get his HTLC redeemed by a 3rd party.

Please note that we already working towards a new HTLC that would remove this possibility when trying to not embed the redeem/refund address in the HTLC. See comit-network/spikes#4 for more details.

For the sake of completeness, let's review the scenario you are suggesting:

Alice redeems on Ethereum

In the case where Alice is the one who redeems Ether.
Alice holds the secret.
Bob locked Ether using the secret hash.

If the secret has been leaked than what it means is:

1. Bob could redeem his asset without Alice redeeming it
2. Someone could redeem Alice's Ether without her wanting it

In this specific scenario, 1. is a more serious concern than 2.
The knowledge of the secret is the primary security parameter to atomic swaps.
If Alice's secret leaked then she has more urgent concerns than someone redeeming her Ether.

Bob redeems on Ethereum

In the case where Bob is the one who redeems Ether.
Alice holds the secret.
Alice locked Ether using the secret hash.

Two sub-scenarios:

1. Alice has already redeemed her asset
2. Alice does not yet have redeemed her asset

(1) If Alice has already redeemed her asset, Bob needs to proceed with redeeming.
If someone else redeems for him it is not great due to the lack of control but yet, not really a security issue as, if Bob were to decide not to redeem then he would lose both assets (the one he locked and the Ether).

(2) If Alice has not yet redeemed her asset and someone decides to trigger Bob's Ether then indeed we remove the control of redeeming from Bob. However, Bob has little choice in this scenario as Alice is the one to redeem the asset first to reveal the secret.

Conclusion

In conclusion, the fact that anyone could redeem the Ether HTLC (to the initial recipient's address) is not great however it is not a security issue per se.
If Alice is redeeming on Ethereum then the fact that the secret was leaked is a greater security concern.
If Bob is redeeming on Ethereum then in any case, Bob has little choice on whether to redeem or not as Alice drives this part of the protocol. For someone to redeem for Bob changes very little in the whole execution.

One could even see a service that redeems for Bob as soon as Alice redeems, allowing Bob not be permanently online when proceed with an atomic swap.

In any case, we have already taken step towards a design that does not allow this exact thing.

I hope this helps!

[thomaseizinger]

@birnbuazn feel free to close this issue if @D4nte comment explains our standpoint well enough :)

[D4nte]

Please re-open if the question/feedback has not been fully answered.