Comments (3)
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:
- Bob could redeem his asset without Alice redeeming it
- 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:
- Alice has already redeemed her asset
- 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!
from rfcs.
@birnbuazn feel free to close this issue if @D4nte comment explains our standpoint well enough :)
from rfcs.
Please re-open if the question/feedback has not been fully answered.
from rfcs.
Related Issues (20)
- Clarify use of headers vs body HOT 2
- Bitcoin ledger definition should use "magic bytes" to identify the network HOT 2
- Add a `role` header to the SWAP REQUEST HOT 2
- Name of SWAP message HOT 1
- Lack of symmetry when processing declined responses HOT 1
- BAM message response type HOT 2
- Data type for timestamps in HTLCs HOT 4
- Documentation notes HOT 5
- Introduce CLOSE frame to RFC-001 HOT 1
- Remove Error Frame from RFC-001
- Embrace libp2p and replace the frame concept with protocols HOT 5
- Establish a shared identifier for a swap as part of a swap request HOT 4
- Change the Bitcoin RFC to use miniscript
- Hackathon requirements for December HOT 2
- COMIT application expiry constraints HOT 2
- Have a concise name for the cryptographic protocol described in RFC003 HOT 11
- Design protocol for integrating LND into cnd HOT 2
- Update Ether/Erc20 HTLC HOT 1
- Update README to include `COMIT spec` header
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rfcs.