Skip to content

Latest commit

 

History

History
87 lines (62 loc) · 7.51 KB

bip-0011.mediawiki

File metadata and controls

87 lines (62 loc) · 7.51 KB

  BIP: 11
  Layer: Applications
  Title: M-of-N Standard Transactions
  Author: Gavin Andresen <[email protected]>
  Translate: Karpov Aleksey <[email protected]>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0011
  Status: Final
  Type: Standards Track
  Created: 2011-10-18
  Post-History: 2011-10-02

Table of Contents

Аннотация

Этот BIP предлагает, принять транзакции с подписями M-из-N как новый тип стандартных транзакций.

Мотивация

Создание защищенных кошельков, escrow транзакции и другие варианты использования, когда для получения средств требуется более одной подписи. Несколько вариантов использования:

  • Кошелек, защищенный «wallet protection service» (WPS). Потребуются транзакции использующие подписи 2-из-2, в которых
одна подпись поступает с(возможно, скомпрометированного) компьютера с кошельком а вторая подпись от WPS. При отправке защищенных биткоинов, клиент пользователя, свяжется с WPS и предоставит предлагаемую транзакцией. WPS свяжется с пользователем для подтверждения того, что он инициировали транзакцию и что данные транзакции верны. Подробная информация о том, как связываются клиенты и WPS, выходит за рамки этого BIP. Примечание: клиенты должны настаивать на том, чтобы их служба защиты кошельков предоставляла им копии закрытого ключа(ей), используемых для защиты своих кошельков, которые они могут автономно и безопасно хранить, чтобы их средства можно было потратить, даже если WPS уйдет с рынка.

  • Трехстороннее депонирование (покупатель, продавец и доверенный агент). Используется транзакция с 2-of-3 подписями.
Покупатель, продавец и агент предоставляют открытые ключи, затем покупатель отправляет средства в транзакцию CHECKMULTISIG 2-of- 3 и отправляет продавцу и агенту идентификатор транзакции. Продавец выполняет свое обязательство, а затем попросит покупателя подписать транзакцию (уже подписанную продавцом), которая отправляет ему заблокированные средства. Если покупатель и продавец не могут договориться, тогда агент в сотрудничестве с покупателем или продавцом решает, что произойдет с заблокированными монетами. Информация о том, как покупатель, продавец и агент связывается для сбора подписей или открытых ключей, выходит за рамки этого BIP.

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

Новый типа стандартной транзакции (scriptPubKey), который ретранслируется клиентами и включается в создоваемые новые блоки: 

    m {pubkey}...{pubkey} n OP_CHECKMULTISIG

Но только для значения n, которое меньше или равно 3.

Операции OP_CHECKMULTISIG выполняется с использованием стандартного scriptSig: 

    OP_0 ...signatures...

(OP_0 требуется из-за ошибки в OP_CHECKMULTISIG; потребляется слишком много элементов из стека, поэтому в стек должно быть помещено фиктивное значение).

Текущий клиент Satoshi не ретранслирует или не обрабатывает транзакции с scriptSigs размером более 200 байт; для размещения транзакций с 3 подписями, он будет увеличен до 500 байт.

Обоснование

OP_CHECKMULTISIG - уже активированный opcode, и это самый простой способ поддержки нескольких важных вариантов использования. Один аргумент против использования OP_CHECKMULTISIG заключается в том, что старые клиенты и майнеры считают его «20 sigops» для вычисления количества операций подписи в блоке, и существует жесткий предел в 20 000 sigops на блок - это означает не более 1000 транзакций c мульти-подписями могут поместится в блоке. Создание транзакций с несколькими подписями с использованием нескольких операций OP_CHECKSIG позволяет увеличить их количество на каждый блок.

Контр-аргумент состоит в том, что новые транзакции с мульти-подписями будут использоваться в сочетании с OP_EVAL (см. OP_EVAL BIP) и будут подсчитываться точно. В любом случае, по мере увеличения объема транзакции, необходимо будет устранить жестко запрограммированный максимальный размер блока, и в это время могут быть решены правила подсчета количества операций подписи операций в блоке.

Более слабый аргумент - OP_CHECKMULTISIG не следует использовать, потому что во время проверки потребляет слишком много элементов из стека. Добавление дополнительного поля OP_0 к scriptSig добавляет только 1 байт к транзакции, и любая альтернатива, которая позволяет избежать OP_CHECKMULTISIG, добавляет по крайней мере несколько байтов кода операций. OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases.

Реализация

OP_CHECKMULTISIG уже поддерживается старыми клиентами и майнерами как нестандартный тип транзакции.

https://github.com/gavinandresen/bitcoin-git/tree/op_eval

Post History