Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Using 0x0000...00 as a secret works in the client but not in the smart contracts #3091
Currently, the SecretRegistry contract refuses 0x00...00 as the secret. If I create a hash lock with keccack(0x0000..00), send the secret, but never send a balance proof, what happens?
If the recipient believes it has received an offchain payment, but cannot really claim the payment online, the experience is unpleasant.
(How I found it: I started reading Solidy code with #3070 in mind.)
Seems like yes. message_handler.py: def handle_message_lockedtransfer() has a similar check against already-registered secrets, but not against
referenced this issue
Nov 29, 2018
My reasoning for not allowing registration for a secret of the form
Indeed, I should have checked the client implementation more closely.
Yes indeed after an offline discussion with @pirapira this seems like a potential critical issue in misalignment between client and contracts which can lead to loss of funds when a user needs to go on-chain.
The suggested solution would be to do the following three things.
How does that sound @pirapira?