Из примечаний к выпуску Bitcoin Core 0.10.0 :
Стандартные правила сценариев ослаблены для адресов P2SH
Правила IsStandard() были почти полностью удалены для сценариев погашения P2SH, что позволяет приложениям использовать любой допустимый тип сценария, такой как «n-of-m OR y», адреса оракула с блокировкой хешем и т. д. В то время как протокол Биткойн всегда поддерживал эти типы скриптов, фактически их использование в основной сети ранее было неудобным, поскольку стандартные узлы Bitcoin Core не передавали их майнерам, и большинство майнеров не включали их в добытые ими блоки.
Таким образом, основное программное обеспечение теперь будет передавать более сложные P2SH-транзакции, которые ранее считались нестандартными транзакциями .
Какие конкретные изменения были внесены (т.е. смягчены стандарты)? Это относится только к P2SH Txns? Наконец, "n-of-m OR y"и hash-locked oracle addressesупоминаются в качестве примеров: к чему именно это относится?
Какие конкретные изменения были внесены (т.е. смягчены стандарты)?
Гэвин Андресен сделал этот запрос на вытягивание , предлагая изменение, а также этот документ с обоснованием , описывающий, почему он поддержал это изменение.
Это относится только к P2SH Txns?
Это применимо только к сценариям выкупа P2SH , то есть сценарию, который запускается, чтобы проверить, есть ли у вас данные, необходимые для траты вывода, отправленного на адрес P2SH.
Наконец, в качестве примеров упоминаются «n-of-m OR y» и адреса оракула с блокировкой хеша: к чему именно это относится?
n-of-m OR yотносится к сценарию, который проверяет несколько подписей из набора ключей ИЛИ одну подпись из другого ключа. Например, если Алиса владеет бизнесом, а Боб и Чарли являются ее сотрудниками, она может разрешить Бобу и Чарли работать вместе, чтобы тратить ее биткойны (2 из 2), или Алиса («y») может тратить свои биткойны самостоятельно. .
hash-locked oracleозначает, как правило, что вы можете создать транзакцию, которая может быть потрачена только тогда, когда предоставлен хэш некоторых данных. Например, в этом PDF -файле (стр. 24) описывается контракт с блокировкой хеша с тремя сторонами: Алисой, Бобом и Чарли.
Алиса хочет заплатить Чарли 1,00 BTC через Боба.
Чарли случайным образом генерирует большое число r , а затем хеширует (HASH160) это число, чтобы получить h . Значение r — это оракул, а значение h — хеш-блокировка.
Чарли дает хэш Алисе .
(Транзакция 1) Алиса получает публичный ключ Боба и платит ему 1,01 BTC в выводе с помощью скрипта вроде:<Bob's pubkey> CHECKSIGVERIFY HASH160 <hash h> EQUAL
(Транзакция 2) Боб не может потратить этот вывод без числа r , которое сгенерировало хэш h , но он знает, что у Чарли есть число r , поэтому Боб получает адрес Чарли и платит ему 1,00 BTC с помощью скрипта вроде:<Charlie's pubkey> CHECKSIGVERIFY HASH160 <hash h> EQUAL
(Транзакция 3) Чарли тратит выходные данные транзакции 2, создавая сценарий подписи: <number r> <Charlie's signature>это означает , что r раскрывается в цепочке блоков.
(Транзакция 4) Боб видит r в цепочке блоков и использует его в какой-то момент, чтобы потратить вывод транзакции 1:<number r> <Bob's signature>
Приведенный выше пример кажется чрезмерно надуманным, но приведенный выше PDF-файл использует его как часть канала микроплатежей, который позволяет проводить транзакции вне цепочки блоков распределенным способом с низким уровнем доверия, что, возможно, позволяет Биткойну масштабироваться намного лучше, чем без такого система.
Ник Оделл
IsStandardкажется, что он совсем не изменился; возможно, разработчики имели в видуIsStandardTx? В любом случае, я не могу найти измененный код.Волшебник Оззи
n-of-m OR yи адреса Oracle