Ich bin Informatik-Student und schreibe eine Diplomarbeit über Atomic Swaps auf BTC und BTC-ähnlichen Blockchains. Für die Diplomarbeit habe ich mich für BTC, LTC, BCH und DCR entschieden. Diese Ketten haben eine irgendwie ähnliche Codebasis und die gleiche Skriptsprache (ich bin kein Profi, daher kann es Unterschiede geben, aber sie sind nicht so gravierend). Und sie alle haben eine ausreichend hohe Marktkapitalisierung, um für Atomic Swaps relevant zu sein.
Das Ziel der Arbeit ist es also, gehashte Timelock-Kontrakte (HTLCs) zu finden und passende HTLCs aus verschiedenen Ketten zu verbinden, um den atomaren Swap zu erhalten. Deshalb habe ich zuerst im Web nach Atomic Swaps [1] gesucht und das Eingabeskript dieser Transaktion analysiert [2], um ein grundlegendes Verständnis dafür zu bekommen, wie Atomic Swaps funktionieren und wie sie aussehen.
Dann habe ich ein Go-Programm geschrieben, um nach jedem Skript zu suchen, das länger als einfache P2PKH-Skripte ist. Dies gab mir eine Liste mit vielen verschiedenen Skripten, die ich von Hand analysierte, um nur die HTLC-Skripte zu nehmen. (Außer vielen Multisig-Skripten gibt es auf BTC nicht viel zu finden^^)
An diesem Punkt habe ich mehrere verschiedene Arten von HTLCs gefunden, wie unten aufgeführt. Danach habe ich BTC erneut gecrawlt* und alle Transaktionen mit HTLC-Skripten gespeichert, wobei die interessanten Daten wie tx-id, Eingabewert, pubKeyHashes, die Geheimnisse und ihre Hashes gespeichert wurden. Ich habe bisher ungefähr einhundert HTLCs auf BTC gefunden.
Ich habe das gleiche für LTC gemacht und ungefähr 400 HTLCs gefunden.
Soweit ich verstanden habe, müssen die Geheimnisse von HTLCs in beiden Ketten gleich sein. Also schrieb ich ein weiteres Go-Programm, um die gefundenen HTLCs von BTC und LTC abzugleichen, und bekam ungefähr 30 Übereinstimmungen. Die nächsten Schritte wären dann, BCH und DCR zu crawlen und auch die dort gefundenen HTLCs zu matchen.
*Crawling bedeutet in diesem Fall, dass ich bis Anfang 2017 beginne, die Blockchain rückwärts zu durchsuchen (um das Neueste zuerst zu bekommen, die Anfangsjahre sind in diesem Fall nicht so interessant^^). Also ungefähr 18 Monate. Wie in [1] angegeben, wurde der erste bekannte Atomaustausch zwischen BTC und LTC am 19. April 2017 (oder 19. April 2017 oder 19.4.2017 oder wie auch immer Sie möchten) durchgeführt. Es macht also nicht viel Sinn, weiter zu kriechen.
Meine Fragen sind nun folgende:
Ich bin offen für jeden konstruktiven Input und hoffe ihr habt ein paar Antworten für mich. Vielen Dank im Voraus.
Typ 1: sha256-Geheimnis, Länge = 97 Byte
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
Typ 2a: sha256-Geheimnis, Länge = 94 Byte
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
Typ 2b: sha256-Geheimnis, Länge = 93 Byte
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
Typ 3: reifmd160-Geheimnis, Länge = 81 Byte
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
Typ 4a: Hash160-Geheimnis, Länge = 86 Byte
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
Typ 4b: Hash160-Geheimnis, Länge = 82 Byte
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
Typ 5a: Hash160-Geheimnis, Länge = 81 Byte
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
Typ 5b: Hash160-Geheimnis, Länge = 78 Byte
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
Typ 6: Hash160-Geheimnis, Länge = 79 Byte
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
Typ 7: mehrere reifmd160-Geheimnisse, Länge=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
Typ 8: mehrere reifmd160-Geheimnisse, Länge=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
[2] https://insight.bitpay.com/tx/0bb5a53a9c7e84e2c45d6a46a7b72afc2feffb8826b9aeb3848699c6fd856480
Ich mag die Frage, aber dies ist vielleicht nicht das richtige Forum, um die besten Antworten zu bekommen. Es ist mehr oder weniger ein Bereich im Stil von Fragen und Antworten, in dem Sie eine einzelne Frage stellen sollten, die leicht beantwortet werden kann. Siehe die Hilfe des Forums. Daher denke ich, dass bitcointalk.org besser sein könnte, um dies zu diskutieren ...
Wie auch immer, ich mag die Art und Weise, wie Sie gezeigt haben, was getan wurde und wonach Sie suchen. Ich werde keine vollständigen Antworten auf alle 6 Aufzählungspunkte haben. Ich scheine zu verstehen, dass die Logik der folgenden Skripte der Schlüssel zum Verständnis der Vorgänge ist und hilft, Ihre Fragen teilweise zu beantworten.
Warum gibt es so viele verschiedene Arten? Ist es mit anderen Ketten kompatibel? Oder was?
Es ist eine offene Umgebung, und jeder kann die Art von Skripten erstellen, von denen er oder sie glaubt, dass sie die Anforderungen erfüllen. Und es gibt viele Wege, die nach Rom führen ... Da die Stack-Operation wahr oder falsch liefert, ist die Transaktion entweder gültig oder ungültig. Man kann also nicht mit Sicherheit sagen, was die Intention für all die Skripte war. Versuch und Irrtum? Verschiedene Bibliotheken? Manullay-Zusammensetzung?
Was sind die Unterschiede zwischen diesen Typen (neben Länge und Hash-Algorithmus)?
Uh, ich müsste alle Skripte erklären - ich bin zu faul. Aber für zukünftige Leser werde ich unten ein Beispiel durchgehen ...
Welche Vor- und Nachteile haben diese Typen?
Warum gibt es bei LTC so viele HTLCs und bei BTC so wenige?
Kennen Sie andere solche HTLC-Skripte?
Ich überlasse es dem Publikum, (vielleicht) bessere Antworten zu geben, als ich es könnte
Können Sie interessante Ressourcen zu diesem Thema bereitstellen?
Die Suche in diesem Forum und Bitcointalk nach „HTLC“ bietet bereits die notwendige Informationsbasis. Innerhalb der Threads gibt es immer Links zu weiteren Beschreibungen, und früher oder später werden Sie den Blitz verstehen :-)
Neben dem Skript-Wiki versuche ich kurz zu erklären, was auf dem Stack passiert, während dieses Skript ausgeführt wird. Es ist wichtig zu wissen, dass sich bereits einige Daten auf dem Stack befinden, bevor die angezeigten Skripte ausgeführt werden. In meinem gewählten Beispiel gibt es höchstwahrscheinlich eine Signatur, einige Daten und ein „true“ für die Anweisungen, die dem „if“-Abschnitt folgen. Für den "else"-Abschnitt gibt es wahrscheinlich eine Signatur, einen Pubkey und ein "false". Beachten Sie, dass die if-Anweisung das oberste Stack-Element „frisst“ („true“ oder „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
Das Beispiel ist vielleicht ein einfacher Test, weil ich nicht sehe, wie der "if"-Abschnitt mit sig, data und "true" auf dem Stack zu einem gültigen Ergebnis kommen könnte (ich kann mich aber irren). Nach dem Sign-On-Stack hätten wir eine Datenstruktur, die sha256 ist. Darauf folgen 32Byte, die dann dupliziert werden. Dies sind drei Datenelemente auf dem Stack. Das oberste Element wird aus dem Stack entfernt, gehasht und der Hash geht zurück auf den Stack. Immer noch drei Datenelemente auf dem Stack. Ein weiteres Datenelement (20 Bytes) folgt, bevor equalverify (frisst und) die beiden obersten Elemente überprüft. Wenn wahr, würde ein Prüfsignal folgen, aber es gibt immer noch zwei Datenstrukturen aus der vorherigen Operation auf dem Stapel. Und ich sehe hier keine Multisig (die Pubkeys prüfen würde, aber keine Hashes). Checksig würde also fehlschlagen ... Daher nehme ich an, dass dies ein Testskript ist.
Atomaustausch