I was looking for a secure way to trade with someone without getting scammed and stumbled upon HTLC. But man, it’s so confusing! Let me break down what’s tripping me up.
Imagine Alice wants to swap her 0.1 BTC for 100 USDT with Bob. Here’s what I think the steps are, but feel free to correct me if I’m off:
1. Alice locks her BTC using a secret key tied to a hash and gives that hash to Bob.
2. Bob locks the USDT with the same hash Alice shared.
3. Alice then claims the USDT using the secret key she generated, which gets permanently recorded on that Blockchain (BSC).
4. Bob sees that secret key and claims his BTC. Trade done, no scams!
So, I’ve got some questions:
1. Since Bob never got the secret key, how does the hash recognize this key as the right one for the hash Alice provided?
2. What if Alice enters an incorrect key to claim the USDT? Since BTC and BSC operate on different chains, they can’t communicate, right?
3. How does the system determine if the secret key is correct if it isn’t just a simple numerical value or string?
Hashing goes in one direction. You can take some data, and calculate a hash of it. But you cannot take a hash, and find a matching data easily. If you can, then a given hash function is broken.
Some example: https://emn178.github.io/online-tools/sha256.html
And then, by requiring a message, which will hash exactly to 0x7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069, you can be quite sure, that it will be "Hello World!". If you could go in an opposite direction, and find a different message, which would hash to this value, or have any software, which will find you a valid message for any hash, then this hash function would be broken.
If you use a wrong key, or a wrong hash, then coins will be unspendable. Sending coins to random public keys or hashes is possible. And then, if nobody knows the key, and the message, then they will stay on a given address, potentially forever, or until someone will break a given public key or hash. Also, there are invalid public keys and hashes, and then coins are just provably unspendable.
More technical details: https://en.bitcoin.it/wiki/Atomic_swap
A hash is a fingerprint to a text or some characters and you can verify the hash if you know the the text. Any characters that is hashed, you can verify if it's real or it has been tempered.
In your example, Alice provide the hash when btc was locked and only provide the secret key to the hash only if Bob lock his equivalent USDT and can be claim by Alice if she provide the secret key to that hash.
https://learnmeabitcoin.com/technical/cryptography/hash-function/
You can play around with some data to understand fingerprints with this hash function.
You can't cheat the smart contract, Alice key must be verified if it match the hash before the USDT can be claimed by Alice so that Bob can be safe in the transaction.
Check the link I provided above to understand hash function, any character or text you hash gives an equivalent 32 bytes and it's unique to that data. If you change the data, the hash changes.
@Ertil & @Cookdata I was able to understand how that secrete key works. But I saw that for my Text the Hash is consistent. Like I entered "Hibro" it was
It's rare to two person in the world choosing same secrete key , also some person can be brute force the string/secrete key to findout. Even though only the receiver can claim the fund. So is it possible that one hash can be used by diff person at diff times if the secret key somehow matched?
By consistent, you mean the same?
You see the output hash is different when I changed the "i" to "y" and are 32 byte output each.
You may understand hash but I'm not sure about Atomic swap. Two people cannot choose the same secret key because it's not manual, they are randomly generated. The chance of two people generating the same key is zero in a real transaction.
You can't brute force Sha256 hash function to get a secrete key, they are one way and irreversible.
Actually the concept is clear rn, thanks for it. I was trying to built a marketplace for this types of Deal, where these two separate person will meet on the platform and will finish the deal. So before starting I was learning the mechanism. Let's see how things works around. Hope I can share the update soon of my prototype. .
If hash has been leaked ain't it possible to guessing random secrete key, although the chances are on in a trillion. Ig it's 2²⁵⁶
If you have so much power, to break SHA-256, then you can also break secp256k1, and access the funds of someone else's directly.
Just to be clear: hashed values should be as random, as private keys are.
This is what can be guessed:
But this one will be hard to guess:
And then, of course you can try to go from 0x6b12a0a4a0d6fb7a1d3a7de3cb6d762f6f6d88401ff8092c68387b2ef2524211 into 02601ABB20535BA767E7B045483CEDAA9A638637837BCCC1503CA0896556E97BA7. However, in that case, you could just instead find the private key to 02601ABB20535BA767E7B045483CEDAA9A638637837BCCC1503CA0896556E97BA7, and sweep someone's coins directly.
Then, if the message used for hashing is generated in a similar way, as private keys are, and is never revealed anywhere, then it can be safely used.
And also, revealing the hashed message can be used, to trigger a different transaction. For example:
Then, if anyone will move coins from bc1q6nckk22592gedg3jt7dza0f5wx9e3ckvfvaq5r, it will reveal 02601ABB20535BA767E7B045483CEDAA9A638637837BCCC1503CA0896556E97BA7, which means it will be possible to get 0x6b12a0a4a0d6fb7a1d3a7de3cb6d762f6f6d88401ff8092c68387b2ef2524211 from there, and unlock some HTLC somewhere else.
You cannot atomically exchange BTC and USDT like that. The secret will have to be revealed at some point, that's why Lightning Network has things like penalty transactions to try and stop that.
The proper way to make an atomic swap without revealing the secret would be to use a zk-SNARK proving that Bob does in fact hold the secret, then you have to change the hash function to be zkp-friendly, and finally both Alice and Bob would need to send their coins to intermediary addresses, generated by keys sourced from entropy made using ECDH between both of them.
In this setup, there is still intermediate data that must be deleted (and thus only created in a controlled environment), but they are no longer directly sharing the secret key.