Trying to get a deeper understanding of atomic swaps

Question

I'm an IT-student and writing a thesis about atomic swaps on BTC and BTC-like blockchains. For the thesis I decided to use BTC, LTC, BCH and DCR. These chains have a somehow similar codebase and the same scripting language (I'm not a professional, so there might be differences, but they are not that serious). And they all have a high enough marketcap to be relevant for atomic swaps.

So the goal of the thesis is to find hashed timelock contracts (HTLCs) and connect matching HTLCs from different chains to get the atomic swap. Therefore I first searched the web for anything on atomic swaps [1] and analyzed the input script of this transaction [2] to get a basic understanding how atomic swaps work and what they look like.

Then I wrote a go program to search for any script longer than simple P2PKH scripts. This gave me a list of many different scripts which I analyzed by hand to only take the HTLC ones. (Besides many multisig scripts, there is not much to find on BTC^^)

At this point I found multiple different types of HTLCs as listed below. Afterwards I crawled* BTC again saving all transactions with HTLC scripts, storing the interesting data like tx-id, input value, pubKeyHashes, the secrets and their hashes. I found about one hundret HTLCs on BTC so far.

I did the same for LTC and found about 400 HTLCs.

As far as I understood, the secrets of HTLCs have to be the same on both chains. So I wrote another go program to match the found HTLCs from BTC and LTC and got around 30 matches. The next steps would then be to crawl BCH and DCR and also match the HTLCs found there.

*Crawling in this case means that I start to search the blockchain backwards (to get the newest first, the beginning years are not that interesting in this case^^) until the beginning of 2017. So about 18 months. As stated in [1] the first known atomic swap between BTC and LTC was made on 19th April 2017 (or April 19th 2017 or 19.4.2017 or whatever you like). So there is not much sense in crawling any further.

My questions now are the following:

• Why are there so many different types? Is it compatibility with other chains? Or what?
• What are the differences between these types (besides length and hashing algorithm)?
• What are the advantages and disadvantages of these types?
• Why are there so many HTLCs on LTC and so few on BTC?
• Do you know other such HTLC scripts?
• Can you provide interesting resources on this topic?

I'm open to any constructive input and hope you have a few answers for me. Thank you in advance.

Type 1: sha256 secret, length=97byte

63  if
82  size
01  data1
    20
88  equalverify
a8  sha256
20  data32
    <secret_hash 32byte>
88  equalverify
76  dup
a9  hash160
14  data20
    <pubkey_hash1 20byte>
67  else
04  data4
    <timelock 4byte>
b1  checklocktimeverify
75  drop
76  dup
a9  hash160
14  data20
    <pubkey_hash2 20byte>
68  endif
88  equalverify
ac  checksig

Type 2a: sha256 secret, length=94byte

63  if
a8  sha256
20  data32
    <secret_hash 32byte>
76  dup
a9  hash160
14  data20
    <pubkey_hash1 20byte>
88  equalverify
ac  checksig
67  else
04  data4
    <timelock 4byte>
b1  checklocktimeverify
75  drop
76  dup
a9  hash160
14  data20
    <pubkey_hash2 20byte>
88  equalverify
ac  checksig
68  endif

Type 2b: sha256 secret, length=93byte

63  if
a8  sha256
20  data32
    <secret_hash 32byte>
88  equalverify
76  dup
a9  hash160
14  data20
    <pubkey_hash1 20byte>
67  else
04  data4
    <timelock 4byte>
b1  checklocktimeverify
75  drop
76  dup
a9  hash160
14  data20
    <pubkey_hash2 20byte>
68  endif
88  equalverify
ac  checksig

Type 3: ripemd160 secret, length=81byte

63  if
a6  ripemd160
14  data20
    <secret_hash 20byte>
88  equalverify
76  dup
a9  hash160
14  data20
    <pubkey_hash1 20byte>
67  else
04  data4
    <timelock 4byte>
b1  checklocktimeverify
75  drop
76  dup
a9  hash160
14  data20
    <pubkey_hash2 20byte>
68  endif
88  equalverify
ac  checksig

Type 4a: hash160 secret, length=86byte

63  if
03  data3
    <timelock 3byte>
b1  checklocktimeverify
75  drop
76  dup
a9  hash160
14  data20
    <pubkey_hash2 20byte>
88  equalverify
ac  checksig
67  else
76  dup
a9  hash160
14  data20
    <secret_hash 20byte>
88  equalverify
ad  checksigverify
82  size
01  data1
    21 -> 33
88  equalverify
a9  hash160
14  data20
    <pubkey_hash1 20byte>
87  equal
68  endif

Type 4b: hash160 secret, length=82byte

63  if
03  data3
    <timelock 3byte>
b1  checklocktimeverify
75  drop
76  dup
a9  hash160
14  data20
    <pubkey_hash2 20byte>
88  equalverify
ac  checksig
67  else
76  dup
a9  hash160
14  data20
    <secret_hash 20byte>
88  equalverify
ad  checksigverify
a9  hash160
14  data20
    <pubkey_hash1 20byte>
87  equal
68  endif

Type 5a: hash160 secret, length=81byte

63  if
a9  hash160
14  data20
    <secret_hash 20byte>
88  equalverify
76  dup
a9  hash160
14  data20
    <pubkey_hash1 20byte>
67  else
04  data4
    <timelock 4byte>
b2  checksequenceverify
75  drop
76  dup
a9  hash160
14  data20
    <pubkey_hash2 20byte>
68  endif
88  equalverify
ac  checksig

Type 5b: hash160 secret, length=78byte

63  if
a9  hash160
14  data20
    <secret_hash 20byte>
88  equalverify
76  dup
a9  hash160
14  data20
    <pubkey_hash1 20byte>
67  else
01  data1
    <timelock 1byte>
b2  checksequenceverify
75  drop
76  dup
a9  hash160
14  data20
    <pubkey_hash2 20byte>
68  endif
88  equalverify
ac  checksig

Type 6: hash160 secret, length=79byte

63  if
54  <timelock op>
b1  checklocktimeverify
75  drop
76  dup
a9  hash160
14  data20
    <pubkey_hash2 20byte>
88  equalverify
ac  checksig
67  else
76  dup
a9  hash160
14  data20
    <secret_hash 20byte>
88  equalverify
ad  checksigverify
a9  hash160
14  data20
    <pubkey_hash1 20byte>
87  equal
68  endif

Type 7: multiple ripemd160 secrets, length=80 + n*23byte

63  if
a6  ripemd160
14  data20
    <secret_hash1 20byte>
88  equalverify
a6  ripemd160
14  data20
    <secret_hash2 20byte>
...
88  equalverify
a6  ripemd160
14  data20
    <secret_hash_n 20byte>
88  equalverify
21  data33
    <signature1 33byte>
ac  checksig
67  else
04  data4
    <timelock 4byte>
b1  checklocktimeverify
75  drop
21  data33
    <signature2 33byte>
ac  checksig
68  endif

Type 8: multiple ripemd160 secrets, length=81 + n*23byte

74  depth
60  16
87  equal
63  if
a6  ripemd160
14  data20
    <secret_hash1 20byte>
88  equalverify
a6  ripemd160
14  data20
    <secret_hash2 20byte>
...
88  equalverify
a6  ripemd160
14  data20
    <secret_hash15 20byte>
88  equalverify
21  data33
    <signature1>
67  else
03  data3
    <timelock 3byte>
b1  checklocktimeverify
75  drop
21  data33
    <signature2>
68  endif
ac  checksig

[1] http://www.cryptovibes.com/crypto-news/charlie-lees-atomic-swap-between-litecoin-and-bitcoin-was-a-success/

[2] https://insight.bitpay.com/tx/0bb5a53a9c7e84e2c45d6a46a7b72afc2feffb8826b9aeb3848699c6fd856480

Answer 1

I like the question, but this is maybe not the right forum to get the best answers. It is more or less a Q&A style area, where you should raise a single question, which can easily be answered. See the forum's help. As such I think bitcointalk.org might be better to discuss this...

Anyhow, I like the way how you showed what was done, and what you are looking for. I will not have full answers to all 6 bullet points. I seem to understand, that the logic of the following script(s) is key to understand whats going on, and helps to partially answer your questions.

Why are there so many different types? Is it compatibility with other chains? Or what?

It is an open environment, and anyone can create the type of scripts, that he or she or it believes fullfill the needs. And there are many ways leading to Rome... As the stack operation will provide true or false, the transaction is either valid or invalid. So one cannot say for sure, what the intention was for all the scripts. Trial and error? Different libraries? Manullay composition?

What are the differences between these types (besides length and hashing algorithm)?

ugh, I would have togo through explanation of all scripts - I am too lazy. But for the sake of future readers, I'll go through one example below ...

What are the advantages and disadvantages of these types?

Why are there so many HTLCs on LTC and so few on BTC?

Do you know other such HTLC scripts?

I leave it to the audience, to (maybe) provide better answers, than I could do

Can you provide interesting resources on this topic?

Searching this forum and bitcointalk for "HTLC", provides already the necessary base of information. Within the threads, there are always links to further description, and sooner or later you'll end up understanding lightning :-)

Next to the script wiki I try to give a short explanation what happens on the stack, while this script is executed. It is important to know, that there is already some data on the stack, before the shown scripts are executed. In my chosen example, there is most probably a signature, some data and a "true" for the statements following the "if" section. For the "else" section, there is probably a signature, a pubkey and a "false". Note the if statement "eats" the top stack item ("true" or "false").

63  if                    if previous element on stack=1, then run the code here (if 0, then go to the else section)
a8  sha256                do a sha256 on the last element on the stack
20  data32                push the next 32 bytes on stack
    <secret_hash 32byte>
76  dup                   duplicate the last item on the stack (so you have twice the secret hash on stack)
a9  hash160               hash the last value from stack with sha256 and ripemd160
14  data20                push the next 20 bytes on stack
    <pubkey_hash1 20byte>
88  equalverify           see if top stack items are the same, if not stop execution (tx = invalid)
ac  checksig              check the remaining signature on the stack
67  else
04  data4                 push 4 bytes on stack
    <timelock 4byte>
b1  checklocktimeverify   tx is invalid if timelock is greater than nLocktime field ...
75  drop                  remove top stack item (whatever CLTV left on the stack)
76  dup                   duplicate the
a9  hash160               sha256 and ripemed (probably the pubkey, leaving a pubkey hash on the stack)
14  data20                push next 20 bytes on stack
    <pubkey_hash2 20byte>
88  equalverify           verify top two stack elements (both hashes), if not equal, tx = invalid)
ac  checksig              check the remaining signature on the stack
68  endif

The example is maybe a simple test, cause I can't see, how the "if" section with sig, data and "true" on the stack could come to a valid result (I may be wrong though). After the sig on stack we'd have a data structure, which is sha256'd. 32bytes follow on top of it, and they are then duplicated. This is three data items on stack. The top item is removed from stack, hashed, and the hash goes back on stack. Still three data items on stack. Another data item (20 bytes) follows, before equalverify (eats and) checks the top two items. If true, a checksig would follow, but still there are two data structures from previous operation on stack. And I don't see any multisig here (which would check pubkeys, but not hashes). So checksig would fail... Hence I assume this is some testing script. HTLC script experts may extend, confirm or even prove me wrong.