Еще в 2013 году анонимным автором написал краткий документ об использовании подписей BLS для достижения своего рода неинтерактивного coinjoin. Я прыгнул на него сразу же, указывая на то, что он также может иметь полезные свойства анти-цензуры. (Edit: ссылка бумаги вниз, копия доступен от Andrew Poelstra.)

Сердечник зависит от того, является тем фактом, что для подписи БСТА можно взять набор {сообщений, Публичный, подпись} кортежей и объединить свои подписи: {[message1, message2, ...], [pubkey1, pubkey2,. ..], подпись}, таким образом, является неосуществимо разъединить их, не зная компоненты, и все еще быть в состоянии проверить результат. Через умного трюк, который включает в себя подписание на вход и на выход, авторство входов и выходов может быть несвязанным. У меня есть реализация боковой цепи этого, что я работаю on-- как coinjoin вообще хорошо сочиняет с КТ, но я не уверен, что делать о производительности (подробнее ниже).

Другое применение этих агрегируемых подписей, которое пришло время от времени в # Bitcoin-волшебниках используют их, чтобы уменьшить размер блока ("2013-09-13 21:38 < gmaxwell> сипа: Я слегка взволнован этим спаривание крипто агрегатной идея подписи. Не из-за анонимности вещей, а потому, что она делает масштабируемые платы реле жизнеспособной. а также может уменьшить размеры транзакций в неанонимном случае"), Так как вы бы сохранить размеры стоящих подписей. Совокупные подписи BLS может даже быть совместимы с «эффективными» мошенничества доказательств, хотя стоимость делает, вероятно, делает это не победа. (Вы бы дерево Merkel суммы по внутренним вычислениям, которая агрегирует частные подписи как продукты в поле 3kbit, что сделало бы возможным, чтобы показать блок имел недопустимую совокупную подпись с компактным доказательством).

Основной недостаток этого являются два fold-- подписей BLS включает Сопряжение Cryptography-- менее зрелые предположения безопасности, чем простые сигнатуры ECC, и что более важно, они медленно, чтобы проверить: На оборудовании, может проверить 70000 secp256k1 подписей в секунду (или 140 000 / с с дозируемой Шнорра) они могут обрабатывать только около 8000 BLS подпись в секунду, с состоянием выбора параметров искусства и программного обеспечения. Таким образом, в то время как пропускная способность будет снижена, емкость большинство узлов не будет увеличена много, потому что они будут упираются на подписи. (И, прямо сейчас, проверка подписи широко кэшируются в Bitcoin-- и агрегация будет двигаться проверку назад на критическом пути).

[У меня были разговоры о том, Дэн Боне об использовании мульти-возведение в степень, как оптимизация при расчете требуемого продукта спариваниях here--, но вполне вероятно, что повышение производительности, что это будет получить бы только порядка 2х.]

Адам Бэк спрашивал меня об этом снова сегодня, и я указал ему на предыдущие дискуссии относительно пределов производительности. Затем он предложил просто использовать Шнорра мульти-подпись вместо подписи БСТ. Идея заключается в том, что если у вас есть входы с pubkeys P и P2 вы можете комбинировать их и сформировать Публичные P + P2 и подписать с тем, чтобы доказать авторизацию с двумя ключами. При этом ранее говорилось о том, что кто-то злонамеренный мог установить их P2 в P3-P, а затем подписать агрегат с только P3, казалось, чтобы убить его.

Но на самом деле несколько месяцев назад Питер Wuille решил это как побочный эффект его ключевой работы дерево мульти-подписи, он предложил вместо этого объединить P и P2, вы используете P * H (P) + P2 * H (P2); это не препятствует подписанию, но это делает невозможным создание Публичных в виде линейной комбинации других ранее существовавших pubkeys. Питер имеет реализацию этого в рамках многоступенчатой ​​подписи работы Libsecp256k1: https://github.com/bitcoin/secp256k1/pull/322

Таким образом, способ, которым мы могли бы использовать это, чтобы улучшить масштабируемость в Bitcoin бы добавить OP_GROUPCHECKSIGVERIFY (и, возможно, многоверсионный его) как часть нового TypeCode segwit сценария, который принимает в качестве входных sighash флагов и Публичного. Операция сценария будет толкать в Публичной на сделку «стек области видимости подписи» и sighash слепой транзакции хэша на открывает транзакции хэша стека.

После того, как все входы обрабатываются в pubkeys в стеке будут объединены в новую Публичных, как Р = Р1 * Н (Н (all_Pn) || Р1) + Р2 * Н (Н (all_Pn) || Р2) + ..., и корневое сообщение хэш computed-- то дополнительный свидетель группы подписи в конце транзакции будет содержать подпись корня с P.

Скорость проверки будет похожа на отдельные входы с пакетной Шноррой (умножение с H () можно сложить в мульти-ехр в проверке), так что это в большей степени экономии пространства, чем ускорение; но размер сделки будет снижена на 41% asymptotically-- без каких-либо новых предположений безопасности или производительности попаданием. Основное ограничение в том, что транзакция должна иметь много входов, чтобы в полной мере осознать, что выгоды.

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

Критически, несколько различных пользователи могут взаимодействовать безопасно производить одну большую сделку с двумя круглыми протоколом, который может сделать это разумно, чтобы получить _many_ входы в одном transaction--, но в отличие от подписей БСТ они должны взаимодействовать, чтобы объединить свои подписи. Фактически это было бы CoinJoin, с большим пространством (и, таким образом, платой) экономией для пользователей CoinJoin.

Даже без объединения нескольких пользователей такой подход делает его гораздо более экономичными для одного пользователя, чтобы подмести txout пыль, которая станет важным усовершенствованием своей собственной. Для блока 400083, если все операции использовали это (но без увеличения CoinJoin, или даже поведенческих изменений предпочитать sendmany над цепочками сделок, которые можно было бы ожидать, если это на самом деле существовал, а также игнорирование multisig использования, что будет способствовать дальнейшему улучшению этого показателя) I вычислить это уменьшит размер блока по 172050 байтам, выполненных из 897956 или уменьшения на 19%, что является значительной частью асимптотического результата. [Редактировать: Развертка 2016 последних блоков с точным подсчетом для multisig, показывает фактическое уменьшение для существующих моделей использования будет составлять 30%]

В действительности это может достичь, по крайней мере половины асимптотического выигрыша, не имея никакого негативного влияния на производительности (10x-17x более высокую производительности, чем BLS) и отсутствие новых сильных криптографических предположений безопасности. Мне кажется, что улучшение ежу понятно, что Bitcoin почти уверен, что в конечном итоге принять после внедрения.