Skip to content

Latest commit

 

History

History
105 lines (88 loc) · 14 KB

bip-0010.mediawiki

File metadata and controls

105 lines (88 loc) · 14 KB

  BIP: 10
  Layer: Applications
  Title: Multi-Sig Transaction Distribution
  Author: Alan Reiner <[email protected]>
  Translate: Karpov Aleksey <[email protected]>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0010
  Status: Withdrawn
  Type: Informational
  Created: 2011-10-28

Транзакция с мульти-подписью - это транзакция, где определенное количество Bitcoin «заблокированно» более чем одним адресом получателя. Последующая транзакция, тратящая эти монеты, потребует от каждой стороны (или некоторого подмножества, в зависимости от сценария) подписать ее своим личным ключом. Этот процес требует сотрудничества между всеми участниками - решение по распределению «заблокированных» средств, собор подписей от всех необходимых участников, а также трансляция завершенной транзакции.

Этот BIP описывает способ стандартизации кодирования подписываемой транзакции, чтобы помочь в сборе и передаче подписей (включая регулярные транзакции 1-of-1, требующие подписи с автономного компьютера). Целью является принятие стандарта, который гарантирует совместимость всех программ, которые его реализуют.

Мотивация

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

Помимо предоставления общей схемы кодирования для подписания/сбора транзакций, она не требует, чтобы подписывающее устройство сохраняло информацию о блокчейне (вся информация, необходимая для проверки и подписания, является частью предлагаемой системы кодирования). Это позволяет использовать очень легкие устройства, которые можно использовать для подписи, поскольку они не нуждаются в информации о блокчейне - только минимальный набор инструментов утилит и модуль ECDSA.

Спецификация

Этот BIP предлагает следующий процесс, с условиями (в кавычках), относящихся к рекомендуемой терминологии, которые следует применять во всех реализациях.

  1. Одна сторона инициирует этот процесс, создав «Предложение о распределении», которое может быть обозначенно абревиатурой как DP или TxDP
  2. Пользователь, создающий TxDP (составитель), создает транзакцию, поскольку они хотели бы ее потратить, но с пустыми сценариями TxIn (куда будут записсаны скрипты подписи в конечном итоге).
  3. В предлагаемой транзакции используеться набор неизрасходованных TxOuts, доступных в блокчейне. Транзакции создающие эти TxOuts, также будут включены в качестве дополнительных данных. Соответственно значения TxIns для создаваемой транзакции могут быть проверены перед подписанием (prev-tx-hash является частью данных, которые подписываются, но значения суммы входа не является частью подписываемой инофрмации). Включив полный сведения о транзакциях выходы которых тратяться, участник подписи может убедиться, что транзакция соответсвет хэшу OutPoint, а затем проверяет входные значения, все без доступа к блокчейн.
  4. TxDP будет иметь «DP ID» или «Unsigned ID», который является хешем предлагаемой транзакции с пустыми скриптами, в Base58. Это конкретное соглашение об именах, для того чтобы убедиться, что он не путается с фактическим идентификатором транзакции, который он будет иметь после его трансляции (идентификатор транзакции не может быть определен до тех пор, пока не будут собраны все подписи). Окончательный идентификатор Tx ID можно назвать "Broadcast ID", чтобы отличить его от предварительно подписанного идентификатора.
5. TxDP будет иметь потенциально неупорядоченный список пар sig-pubkey, которые представляют собой собранные подписи. Если вы получаете TxDP, у которого отсутствует только ваша подпись, вы можете транслировать его сразу после его подписания. 6. Идентичные объекты TxDP с различными подписями могут быть легко объединены. Это позволяет одной стороне одновременно отправлять все запросы на подписи и объединять их во время их получения (вместо того, чтобы «пропускать их»). 7. В случаях, когда TxDP может быть помещен в файл или отправлен по электронной почте, он должен использовать суффикс .txdp или .btcdp

Любой, кто принимает BIP 0010 для транзакций multi-sig, будет использовать следующий формат (без отступов): 

 '-----BEGIN-TRANSACTION-TXDPID-------'
 ("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
    (serializedTxListInHex_Line1)
    (serializedTxListInHex_Line2)
    (serializedTxListInHex_Line3)
    ...
 ("_TXINPUT_") (00) (InputValue)
    ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
    (SigHexRemainingLines)
    ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
    (SigHexRemainingLines)
 ("_TXINPUT_") (01) (InputValue)
    ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
    (SigHexRemainingLines)
 ("_TXINPUT_") (02) (InputValue)
 '-------END-TRANSACTION-TXDPID-------'

Ниже приведен пример TxDP от Armory, созданный во время работы в тестовой сети. Его DPID - 3fX59xPj: 

 -----BEGIN-TRANSACTION-3fX59xPj-------------------------------------------------
 _TXDIST_fabfb5da_3fX59xPj_00a0
 010000000292807c8e70a28c687daea2998d6273d074e56fa8a55a0b10556974cf2b526e61000000
 0000ffffffffe3c1ee0711611b01af3dee55b1484f0d6b65d17dce4eff0e6e06242e6cf457e10000
 000000ffffffff02b0feea0b000000001976a91457996661391fa4e95bed27d7e8fe47f47cb8e428
 88ac00a0acb9030000001976a914dc504e07b1107110f601fb679dd3f56cee9ff71e88ac00000000
 0100000001eb626e4f73d88f415a8e8cb32b8d73eed47aa1039d0ed2f013abdc741ce6828c010000
 008c493046022100b0da540e4924518f8989a9da798ca2d9e761b69a173b8cc41a3e3e3c6d77cd50
 022100ecfa61730e58005338420516744ef680428dcfc05022dec70a851365c8575b190141042dc5
 be3afa5887aee4a377032ed014361b0b9b61eb3ea6b8a8821bfe13ee4b65cd25d9630e4f227a53e8
 bf637f85452c9981bcbd64ef77e22ce97b0f547c783effffffff0200d6117e030000001976a914cf
 f580fd243f64f0ad7bf69faf41c0bf42d86d8988ac00205fa0120000001976a9148d573ef6984fd9
 f8847d420001f7ac49b222a24988ac000000000100000001f2782db40ae147398a31cff9c7cc3423
 014a073a92e463741244330cc304168f000000008c493046022100c9311b9eef0cc69219cb96838f
 dd621530a80c46269a00dccc66498bc03ccf7a0221003742ee652a0a76fd28ad81aa73bb7f7a0a6a
 81850af58f62d9a184d10e5eec30014104f815e8ef4cad584e04974889d7636e8933803d2e72991d
 b5288c9e953c2465533905f98b7b688898c7c1f0708f2e49f0dd0abc06859ffed5144e8a1018a4e8
 63ffffffff02008c8647000000001976a914d4e211215967f8e3744693bf85f47eb4ee9567fc88ac
 603d4e95010000001976a914e9a6b50901c1969d2b0fd43a3ccfa3fef3291efe88ac00000000
 _TXINPUT_00_150.00000000
 _SIG_mzUYGfqGpyXmppYpmWJ31Y4zTxR4ZCod22_00_008c
 4930460221007699967c3ec09d072599558d2e7082fae0820206b63aa66afea124634ed11a080221
 0003346f7e963e645ecae2855026dc7332eb7237012539b34cd441c3cef97fbd4d01410497d5e1a0
 0e1db90e893d1f2e547e2ee83b5d6bf4ddaa3d514e6dc2d94b6bcb5a72be1fcec766b8c382502caa
 9ec09fe478bad07d3f38ff47b2eb42e681c384cc
 _TXINPUT_01_12.00000000
 _SIG_mzvaN8JUhHLz3Gdec1zBRxs5rNaYLQnbD1_01_008c
 49304602210081554f8b08a1ad8caa69e34f4794d54952dac7c5efcf2afe080985d6bd5b00770221
 00dea20ca3dbae1d15ec61bec57b4b8062e7d7c47614aba032c5a32f651f471cfd014104c30936d2
 456298a566aa76fefeab8a7cb7a91e8a936a11757c911b4c669f0434d12ab0936fc13986b156156f
 9b389ed244bbb580112be07dbe23949a4764dffb
 -------END-TRANSACTION-3fX59xPj-------------------------------------------------

В этой транзакции есть два входа: один 150 BTC и другой 12 BTC. Эта транзакция объединяет 162 BTC, чтобы создать два выхода: один из 160 BTC, один 1.9995 BTC и плату комиссии 0.0005 BTC. В этом TxDP оба входа были подписаны и, таким образом, могут немедленно транслироваться.

Стиль коммуникаций береться непосредственно из PGP/GPG, который использует блоки ASCII, подобные этому, для передачи зашифрованных сообщений и подписей. Эта сериализация компактна и будет интерпретироваться одинаково во всех кодировках символов. Ее можно скопировать в электронном письме или сохранить в текстовом файле. Преимущество по сравнению с аналогичным кодированием PGP заключается в том, что для него есть некоторые человекочитаемы элементы, для пользователей, которые хотят вручную изучить пакет TxDP, вместо того, чтобы требовать от программы синтаксического анализа основных элементов TxDP.

Сторона, получающая этот TxDP, может просто добавить свою подпись в соответствующую строку _TXINPUT_. Если это последняя требуемая подпись, они могут транслировать ее самостоятельно. Любое программное обеспечение, которое реализует этот стандарт, должно иметь возможность комбинировать несколько TxDP в одном TxDP. Однако даже без поддержки программ пользователь может вручную объединить их, скопировав соответствующие строки _TXSIGS_ между упорядочиваниями, хотя это не рекомендуемый метод объединения TxDP.

Стандартная реализация

Это предложение было реализовано и протестировано в старых версиях программного обеспечения Armory Bitcoin для использования при подписании транзакции в автономном режиме (как транзакция 1 из 1). Реализацию можно найти по ссылке https://github.com/etotheipi/BitcoinArmory/blob/v0.91-beta/armoryengine/Transaction.py под классом PyTxDistProposal. Однако с версии 0.92, выпущенной в июле 2014 года, Armory больше не использует это предложение для подписания оффлайн-кошелька и перешел в новый формат.