Вот идея: почему бы не просто изменить OP_CHECKSIG (который в настоящее время проверяет одну сигнатуру), поэтому он сам поддерживал несколько подписей, которые могут быть соединены с логикой?

Сейчас мы берем HASH160 единого Публичных А совпадать с адресом, и OP_CHECKSIG соответствует этому Публичных А для подписи А.

Что делать, если OP_CHECKSIG были расширены таким образом, что мы предлагаем, как А, может быть также двоично-сериализовать выражение? Прямо сейчас, вы вход А и действительная подпись для А, и получить истинные. С усилением, в OP_CHECKSIG вы вводите "(А и В) или С"И три подписи A B C (которые не являются более параметрами, они являются просто более байтами заправленных в одних и те же параметры с помощью двоичной сериализации). Не все три подписи должны быть действительными, достаточно должны быть действительными, чтобы сделать выражение оценки в действительности. Конечно, Публичных "" Сам по себе еще допустимое выражение, один, который проверяет только с действительной подписью для А, и которая является то, что считается стандартной сделкой сегодня.

Поскольку адрес Bitcoin основан на том, что составляет HASH160 (А), с этой модификацией вы могли бы иметь нормальный вид адрес Bitcoin на основе всего выражения, так как это было бы лишь HASH160 бинарной сериализации выражения. Там не было бы никакой необходимости раздувать адреса или ввести новый формат.

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