В этой теме () Я показал странную особенность проверки Bitcoin подписи. Эта "особенность" может быть использован для сжатия транзакций, передаваемых (более чем на 95% в некоторых крайних случаях)

Идея заключается в том, чтобы создать новый псевдо опкод OP_COPY_SCRIPTSIG. OP_COPY_SCRIPTSIG имеет единственный аргумент, который является показателем ввода подписи которого скрипт должен быть скопирован.
OP_COPY_SCRIPTSIG должны быть интерпретированы клиентом Satoshi и должны быть заменены точной подписью, когда Тй принимаются. так это прозрачно для процедуры проверки сценария. Когда сделка должна быть направлена, он снова сжимается. Использование этого псевдо-опкод не изменяет правила проверки транзакции, ни она подразумевает жесткую вилку.

Как это работает?

Предположим, что Алиса сжать ее операции. Она просит пользователей, которые присылают свои биткойны, чтобы отправить ее деньги с завершающим OP_CODESEPARATOR в выходных сценариев. Клиент Satoshi модифицируется рассмотреть этот сценарий в качестве стандарта.

Теперь, если она хочет, чтобы собрать сто неизрасходованные выходов, она просто подписать первый входной scriptSig и заполнить оставшиеся scriptSigs с {OP_COPY_SCRIPTSIG, 0}. Та же подпись может быть использована в каждом входе, до тех пор, как все они были отправлены в тот же адрес и имеет косую OP_CODESEPARATOR в своих выходные сценариев.

Поскольку каждый scriptSig использует обычно около 100 байт, она использует два байта, а не для почти всех из них, экономя 98% пространства scriptSig.

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

Например: Сделка с двумя входами и двумя выходами (один возвращается к отправителю, как изменение) выглядит следующим образом:

Input 0: Предыдущие ТЕ: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6, индекс: 0,  
  scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d1
  90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Input 1: Предыдущий ТЙ: e2ac980643b0b82c0e88ffdfec6b64e2ac980643b0b82c0e88ffdfec6b649f2dc, индекс: 0,  
  scriptSig: {OP_COPY_SCRIPTSIG, 0}.

Выход 0:
  Значение: 5000000000
  scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG

Выход 1:
  Значение: 134
  scriptPubKey: {OP_COPY_SCRIPTPUB, 0}.


С наилучшими пожеланиями, Серхио.