Каковы пределы m и n в m-of-n многоуровневых адресах?

Этот метод описывает, как создать мультисессию 2-из-3.

Я слышал, что существует число, ограниченное числом мультисигских частей, и ограничение их на 3.

Описан ли стандартный метод, описанный выше для многосигенных адресов генерации и расходов , с более чем тремя частями? Каков предел? Как обойти это и создать /потратить более крупные мультисессии с использованием биткойна (практические «как» будут оценены)

20 голосов | спросил ripper234 23 MarpmSun, 23 Mar 2014 20:51:40 +04002014-03-23T20:51:40+04:0008 2014, 20:51:40

5 ответов


19

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

Кроме того, нам нужно различать raw multisig (простой скрипт на основе OP_CHECKMULTISIG) и P2SH multisig (где скрипт OP_CHECKMULTISIG отображается только при расходах).

Наконец, поскольку скрипты включают открытые ключи, их размеры зависят от их длины. Существуют как сжатые (33 байта), так и несжатые (65 байтов) ключи, в зависимости от того, какая версия кошелька была использована для их создания.

Необработанный multisig

Каждая комбинация m-of-n действительна (до n = 20), но правила стандартности допускают только до n = 3.

Это ограничение применяется при отправке (т. е. отправка в мультисимвол 2 из 4 не считается стандартным).

P2SH multisig

Правила

validity требуют, чтобы сценарий P2SH redeem был не более 520 байт. Поскольку сценарий redeem является [m pubkey1 pubkey2 ... n OP_CHECKMULTISIG], следует, что длина всех открытых ключей вместе плюс количество открытых ключей не должно превышать 517.

  • Для сжатых открытых ключей это означает до n = 15
  • Для несжатых, до n = 7.

Для стандартности это зависит от версии. До v0.9. * Ссылочный клиент требовал, чтобы общий сценарий расходов составлял не более 500 байт.

  • Для сжатых ключей это означает m * 73 + n * 34 <= 496 (до 1 из 12, 2 из 10, 3-из-8 или 4-из-6).
  • Для несжатых клавиш это означает, что m * 73 + n * 66 <= 496 (до 1-of-6, 2-of-5, 3-of-4).

В 0.10 эти правила стандартизации, вероятно, будут ослаблены, что позволит перейти к пределам достоверности (15-из-15 для сжатых ключей, 7-из-7 для несжатых клавиш).

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

ответил Pieter Wuille 23 J0000006Europe/Moscow 2014, 03:43:44
3

от 0 до 0 до 20 из 20

https://blockchain.info/tx/970b435253b69cde8207b3245d7723bb24861fd7ab3cfe361f45ae8de085ac52 является освобождением 0-of-0 p2sh

https://blockchain.info/tx/da738e29f64e90ae46dcc3e6b4154041d6324abbe7919e722d486a4a3148b7dc если 20-из-20 голодных многопользовательских скидок

https://blockchain.info/tx/552026dade1c9385e4693a4e82f07080d8d1950fc822346f95a0dc1e0a833465 является 15-из -15 выкупа p2sh

ответил amaclin 23 J0000006Europe/Moscow 2014, 08:25:00
1

Недавно я внедрил multi-sig выходы для Dartcoin , используя код BitcoinJ в качестве ссылки.

Кажется, что ссылочный клиент имеет максимум 3 ключа для многосегментных транзакций. Тем не менее, фактический предел равен 16. Это ограничение не является произвольным (например, 3 ключевого предела), но связано с жестким пределом предела скрипта.

Использование более 3-х клавиш работает точно так же, как с тремя клавишами. Как вы можете видеть в коде, вывод состоит только из количества ключей, которые вы предоставляете (n), и порога расходов (m).

ответил Steven Roose 24 MarpmMon, 24 Mar 2014 14:30:21 +04002014-03-24T14:30:21+04:0002 2014, 14:30:21
1

Мы тестировали multisigs p2sh до 8-из-15. Выше 15, биткойн вызвал проблемы.

Вы можете просмотреть наш код здесь, чтобы посмотреть, как это делается:

https://github.com/orisi/orisi

Здесь также обсуждается проект с некоторыми интересными лакомыми кусочками:

https://bitcointalk.org/index.php?topic=645589.0

В настоящее время проблема заключается в том, что все, что выше 3 из 3, превышает стандартный размер транзакции, и мы должны проталкивать его через пул Eligius. Но от людей, сказанных в потоке, есть способ сжать ключи и сделать даже 8 из 15-ти

ответил kolinko 23 J0000006Europe/Moscow 2014, 21:20:54
-1

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

http://bitcoinmagazine.com/11108/multisig-future-bitcoin/

ответил Nagaraj Hubli 25 MaramTue, 25 Mar 2014 00:33:00 +04002014-03-25T00:33:00+04:0012 2014, 00:33:00

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132