Попытка получить более глубокое понимание атомарных свопов

Я студент ИТ и пишу диссертацию об атомарных свопах на BTC и блокчейнах, подобных BTC. Для дипломной работы я решил использовать BTC, LTC, BCH и DCR. У этих цепочек в чем-то схожая кодовая база и один и тот же скриптовый язык (я не профессионал, поэтому отличия могут быть, но они не такие серьезные). И все они имеют достаточно высокую рыночную капитализацию, чтобы иметь отношение к атомарным свопам.

Таким образом, цель диссертации состоит в том, чтобы найти хэшированные контракты временной блокировки (HTLC) и соединить соответствующие HTLC из разных цепочек, чтобы получить атомарный обмен. Поэтому я сначала поискал в Интернете что-нибудь об атомарных свопах [1] и проанализировал входной сценарий этой транзакции [2], чтобы получить общее представление о том, как работают атомарные свопы и как они выглядят.

Затем я написал программу go для поиска любого скрипта длиннее, чем простые скрипты P2PKH. Это дало мне список множества различных скриптов, которые я проанализировал вручную, чтобы выбрать только HTLC. (Кроме множества мультиподписных скриптов, на BTC нечего найти^^)

На данный момент я нашел несколько различных типов HTLC, перечисленных ниже. После этого я снова просканировал * BTC, сохранив все транзакции с помощью HTLC-скриптов, сохранив интересные данные, такие как tx-id, входное значение, pubKeyHashes, секреты и их хэши. На данный момент я нашел около сотни HTLC на BTC.

Я сделал то же самое для LTC и нашел около 400 HTLC.

Насколько я понял, секреты HTLC должны быть одинаковыми в обеих цепочках. Поэтому я написал еще одну программу для сопоставления найденных HTLC от BTC и LTC и получил около 30 совпадений. Следующими шагами будет сканирование BCH и DCR, а также сопоставление найденных там HTLC.

*Сканирование в данном случае означает, что я начинаю поиск в блокчейне в обратном направлении (чтобы сначала получить самое новое, начальные годы не так интересны в этом случае^^) до начала 2017 года. Итак, около 18 месяцев. Как указано в [1], первый известный атомный своп между BTC и LTC был совершен 19 апреля 2017 года (или 19 апреля 2017 года, или 19 апреля 2017 года, или как вам угодно). Так что смысла дальше лезть нет.

Мои вопросы сейчас следующие:

  • Почему существует так много разных типов? Совместима ли она с другими цепями? Или что?
  • Каковы различия между этими типами (кроме длины и алгоритма хеширования)?
  • Каковы преимущества и недостатки этих типов?
  • Почему так много HTLC на LTC и так мало на BTC?
  • Знаете ли вы другие подобные HTLC-скрипты?
  • Можете ли вы предоставить интересные ресурсы по этой теме?

Я открыт для любого конструктивного вклада и надеюсь, что у вас есть несколько ответов для меня. Заранее спасибо.

Тип 1: секрет sha256, длина = 97 байт.

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

Тип 2a: секрет sha256, длина = 94 байта

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

Тип 2b: секрет sha256, длина = 93 байта

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

Тип 3: секрет ripemd160, длина = 81 байт.

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

Тип 4a: секрет hash160, длина = 86 байт.

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

Тип 4b: секрет hash160, длина = 82 байта.

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

Тип 5a: секрет hash160, длина = 81 байт.

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

Тип 5b: секрет hash160, длина = 78 байт.

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

Тип 6: секрет hash160, длина = 79 байт.

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

Тип 7: несколько секретов ripemd160, длина = 80 + n*23 байта.

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

Тип 8: несколько секретов ripemd160, длина = 81 + n*23 байта.

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

если вам интересно, как атомарные свопы работают в реальных проектах, вы можете проверить эту статью wiki.swap.online/atomic-swap-on-tether . Эти ребята реализовали первый атомарный своп BTC на USDT в своем проекте swap.online wallet. Проверьте это, чтобы лучше понять, как это работает.

Ответы (1)

Мне нравится вопрос, но, возможно, это не тот форум, где можно получить лучшие ответы. Это более или менее область вопросов и ответов, где вы должны задать один вопрос, на который можно легко ответить. Смотрите справку форума. Таким образом, я думаю, что bitcointalk.org может быть лучше для обсуждения этого...

Во всяком случае, мне нравится, как вы показали, что было сделано, и что вы ищете. У меня не будет полных ответов на все 6 пунктов. Кажется, я понимаю, что логика следующего скрипта(ов) является ключом к пониманию того, что происходит, и помогает частично ответить на ваши вопросы.

Почему существует так много разных типов? Совместима ли она с другими цепями? Или что?

Это открытая среда, и каждый может создавать сценарии, которые, по его мнению, удовлетворяют потребности. И есть много путей, ведущих в Рим... Так как операция стека даст true или false, транзакция либо действительна, либо недействительна. Так что нельзя точно сказать, каков был замысел всех сценариев. Методом проб и ошибок? Разные библиотеки? Состав Мануллая?

Каковы различия между этими типами (кроме длины и алгоритма хеширования)?

тьфу, пришлось бы объяснять все скрипты - мне лень. Но ради будущих читателей я рассмотрю один пример ниже...

Каковы преимущества и недостатки этих типов?

Почему так много HTLC на LTC и так мало на BTC?

Знаете ли вы другие подобные HTLC-скрипты?

Я оставляю это аудитории, чтобы (возможно) дать лучшие ответы, чем я мог бы сделать

Можете ли вы предоставить интересные ресурсы по этой теме?

Поиск на этом форуме и в bitcointalk по запросу «HTLC» уже дает необходимую базу информации. В треде всегда есть ссылки на дальнейшее описание, и рано или поздно вы поймете, что молния :-)

Рядом со скриптом вики я пытаюсь дать краткое объяснение того, что происходит в стеке, пока этот скрипт выполняется. Важно знать, что в стеке уже есть некоторые данные, прежде чем показанные скрипты будут выполнены. В выбранном мной примере, скорее всего, есть подпись, некоторые данные и «истина» для утверждений, следующих за разделом «если». Для раздела «другое», вероятно, есть подпись, публичный ключ и «ложь». Обратите внимание, что оператор if «съедает» верхний элемент стека («true» или «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

Пример может быть простым тестом, потому что я не вижу, как раздел «если» с sig, data и «true» в стеке может привести к правильному результату (хотя я могу ошибаться). После записи в стеке у нас будет структура данных, которая sha256. Далее следуют 32 байта, которые затем дублируются. Это три элемента данных в стеке. Верхний элемент удаляется из стека, хешируется, и хэш возвращается в стек. Еще три элемента данных в стеке. Далее следует еще один элемент данных (20 байт), прежде чем функция equalverify (съест и) проверит два верхних элемента. Если это правда, последует контрольный знак, но в стеке все еще есть две структуры данных из предыдущей операции. И я не вижу тут никакой мультиподписи (которая бы проверяла паблики, но не хэши). Так что checksig потерпит неудачу... Следовательно, я предполагаю, что это какой-то тестовый скрипт.

спасибо за развернутый ответ. Я также создал тему на bitcointalk.org.
извините за двойную публикацию, но я не могу редактировать свой комментарий, потому что он старше 5 минут -.- В любом случае: в следующие дни я более подробно рассмотрю атомарные свопы и HTLC. возможно, я был немного недалеким с вопросом о разнообразии скриптов ^^ Одна интересная вещь: я проверил несколько HTLC-транзакций, которые я нашел, с помощью hashmal , который является инструментом для тестирования биткойн-транзакций. И он сказал, что этот сценарий был действительным. Но я также был сбит с толку, когда попытался проверить это вручную.
О, круто, надо взглянуть на этот гашмал. Никогда не перешагивал через это. Спасибо за ссылку.
Попытка получить более глубокое понимание атомарных свопов
СпросиСетьПолитика конфиденциальности1y, 0v