HTLC Atomic Swap | How the Secret Key Works Across Different Chains?

[Mahiyammahi]

So I was exploring the safest option to trade with some one without being getting scammed. Then learned about HTLC but no matter how hard I'm trying to understand the mechanism behind this it's but It's just messing with my head.  I will try to clearly presents my confusion. 

Let's say Alice will swap her 0.1 BTC with 100 USDT with BOB
Steps that would take in the process,  correct me if I'm wrong.

• Alice Locks her BTC with a secrete key on a hash & Give it to  (The hash)
• Bob Locked the USDT with the same hash Alice provided
• Alice Claimed the USDT with the secrete key (This key has been genertaed by Alice) and the key has been stored on that Blockchain(BSC) permanently
• Bob sees the Secrete key and claimed his BTC,  both trade has done no ome scammed.

So my question is -
1. Since the secrete key has not been shared with Bob , how that hash do knows this is the correct key for the hash Alice provided?
2. Alice could have entered the wrong key for claiming the USDT . Since BTC & BSC both is in the different chain they can't contact each other.
3. Since secrete key is not some numerical value/string how it's findout the correct key ?

[ertil]

how that hash do knows this is the correct key for the hash Alice provided?

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

Code:

SHA-256("Hello World!")=7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069

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.

Alice could have entered the wrong key

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

[Cookdata]

So my question is -
1. Since the secrete key has not been shared with Bob , how that hash do knows this is the correct key for the hash Alice provided?

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.

2. Alice could have entered the wrong key for claiming the USDT . Since BTC & BSC both is in the different chain they can't contact each other.

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.

3. Since secrete key is not some numerical value/string how it's findout the correct key ?

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.

[Mahiyammahi]

@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

Code:

d80a208c6ca4e93a2fdb564624115d41be4ac4cfc2caac903e7874dc920f8824

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?

[Cookdata]

@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

Code:

d80a208c6ca4e93a2fdb564624115d41be4ac4cfc2caac903e7874dc920f8824

By consistent, you mean the same?

Code:

Hibro ==> d80a208c6ca4e93a2fdb564624115d41be4ac4cfc2caac903e7874dc920f8824
Hybro ==> 181b4b1fbef01f14c42bae63ed57f844254cff02ed30601fbfa6ec74b714fd1c

You see the output hash is different when I changed the "i" to "y" and are 32 byte output each.

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?

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.

[Mahiyammahi]

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.

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. .

You can't brute force Sha256 hash function to get a secrete key, they are one way and irreversible.

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²⁵⁶

[ertil]

If hash has been leaked ain't it possible to guessing random secrete key

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.

I was trying to built a marketplace for this types of Deal

Just to be clear: hashed values should be as random, as private keys are.

This is what can be guessed:

Code:

SHA-256("something")=3fc9b689459d738f8c88a3a48aa9e33542016b7a4052e001aaa536fca74813cb

But this one will be hard to guess:

Code:

SHA-256(02601ABB20535BA767E7B045483CEDAA9A638637837BCCC1503CA0896556E97BA7)=6b12a0a4a0d6fb7a1d3a7de3cb6d762f6f6d88401ff8092c68387b2ef2524211

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:

Code:

RIPEMD-160(6b12a0a4a0d6fb7a1d3a7de3cb6d762f6f6d88401ff8092c68387b2ef2524211)=d4f16b29542a9196a2325f9a2ebd34718b98e2cc
p2wpkh(d4f16b29542a9196a2325f9a2ebd34718b98e2cc)=bc1q6nckk22592gedg3jt7dza0f5wx9e3ckvfvaq5r

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.

[NotATether]

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.