Bitcoin признаки каждого из входов для ОГО с отдельной подписью. Это добавляет значительный размер, чтобы общий размер сделки. Размер наиболее распространенных Bitcoin ТХ может быть вычислена как:
Размер (в байтах) = 10 + 147 * NumIn + 34 * NumOut
Это относится и к ОМУ со стандартными выходами, сценариями менее 256 байт каждых, и все входы используют сжатые открытые ключи. Если открытый ключ для ввода несжатых размеров 32 байт больше.
Наибольшая часть сбалансированного (число входов и выходов равна) поступает из входной части и самый большой компонентом ввода является подписью, которая составляет 72 байт с кодированием. Если мы предполагаем, что среднее значение ТХ состоит из двух входов и двух выходов, что делает средний размер ТХ 368 байт. Примерно 39% от этого или 144 байт из двух подписей для двух входов. Однако ТЙ действуют только тогда, когда все подписи являются действительными.
Нужно ли хранить каждую подпись отдельно?
Есть ли какая-либо операция ECDSA, которые могли бы позволить проверку того, что данные были подписаны несколькими секретными ключами с одной подписи и нескольких открытых ключей?
Данный:
закрытые ключи & б
Открытые ключи & В
Данные должны быть подписаны д
Можно ли создать подпись S таким образом, что она может быть уточнена с учетом только A, B, и d?
|
|
||||||
18 июля 2013, 2:21:46 AM
|
# 1 |
Сообщения: 1218
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru |
|
|
|
Как заработать Биткоины?
Без вложений. Не майнинг.
|
18 июля 2013, 4:20:28 AM
|
# 2 |
|
Сообщения: 1428
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Получил 1806 Биткоинов
Реальная история. Даже если есть, другая часть данных подписываются для каждого входного / ключа. то есть "Данные, которые должны быть подписаны, д" в вашем вопросе выше, не является последовательным. Посмотрите OP_CHECKSIG для деталей.
|
|
|
|
|
18 июля 2013, 5:53:10 AM
|
# 3 |
|
Сообщения: 1218
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Даже если есть, другая часть данных подписываются для каждого входного / ключа. то есть "Данные, которые должны быть подписаны, д" в вашем вопросе выше, не является последовательным. Посмотрите OP_CHECKSIG для деталей. Это было бы несовместимый перерыв, и я не питаю никаких иллюзий, что когда-либо будет использоваться для Bitcoin. Давайте рассмотрим это в основном теоретический, возможно, для некоторых будущих altcoin. Структура сделки не обязательно должна или быть одинаковыми. Можно предполагать d является одинаковым для всех входов. Один из методов будет то, что весь ТХ подписан (все входы, все выходы), но точная структура не так важно. Делая немного больше исследований, я считаю, что можно использовать эллиптические кривую арифметику, чтобы добавить секретные ключи вместе, чтобы создать "мастер" Секретный ключ для подписания и этого мастера закрытого ключа можно проверить путем добавления открытых ключей вместе, чтобы сформировать открытый ключ мастер. Я собирался сделать некоторые тесты с OpenSSL, но мне нужно немного поспать. |
|
|
|
|
18 июля 2013, 6:01:08 AM
|
# 4 |
|
Сообщения: 2366
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Некоторые системы подписывания ECC может сделать группировку операций, где вы можете создавать все ключи и все данные, подписанные и подтвердить все это с пренебрежимо малой вероятностью принятия если были признаны недействительными и нулевой возможности отказа, если все были признаны действительными. Но AFAIK ECDSA не такая схема, и те, которых я знаю, имеют большие подписи. (Ну, хотя, если вы должны были использовать его, чтобы всегда объединить все подписи в виде блок-, которые могут быть интересны).
Может быть, вы уже рекомендуемом но его, конечно, можно в to-одном transaction- выставить кучу открытых ключей, компоновать их и подписать с составом. Это то, что вы получаете с 2-го типа детерминированных кошельков или vanitypooling, эффективно. Но сокращение пространства уменьшается необходимость разоблачить ключи ... и было бы порча анализ более мощным, потому что вы несколько сторон не может безопасно входить в этой модели. Это также несовместимо с sighash синглом. Если вы хотите, несовместимый ECC конкретных change- вы могли бы вместо того, чтобы добавить восстановление открытого ключа. Это получить аналогичные экономии пространства, но и сэкономить на операции с одним входом, а не нарушая способность запутать анализ заражать с совместными сделками, или нарушения альтернативных sighashes. Более философски, отдавая особое асимметричной криптосистемы в Bitcoin, вероятно, не великая идея. Мы имеем эту фантастическую гибкую систему подписи, где критерии подписывания программы не только фиксированный асимметричный оператор. Это стоит того, некоторые дополнительные расходы, чтобы сохранить эту гибкость на равных. Он также вполне может быть так, что мы стали обеспокоены безопасностью ECDSA в будущем (например, практические очень большие Q сделать ECDSA неприемлемо слабым). Очевидные альтернативы не очевидно, поддерживают такую mathmatical удовольствия. Одна вещь, которую я иногда хочу, что сделки были сами хэш-деревья внутри. Было бы очень хорошо, чтобы быть в состоянии дать кому-то все данные, необходимые для создания тока UTXO надежно (и, таким образом, также убедитесь, что нет допускается инфляция в цепочке), не посылая им кучу глубоко заусениц данных подписи, которые ISN «т лично им интересно, и которые они считают, имеет достаточную безопасность hashpower только сделать рандомизированные выборочные проверки. |
|
|
|
|
18 июля 2013, 7:20:24 AM
|
# 5 |
|
Сообщения: 798
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Совокупный и проверяемые Зашифрованные Подписи от Билинейного Maps - Бона и др
Агрегатная схема подписи представляет собой цифровую подпись, которая поддерживает агрегирование: Учитывая п подписи на п различных сообщений из п различных пользователей, можно объединить все эти подписей в одной короткой подписи. Эта единственная подпись (и п исходные сообщения) убедите верификатор, что русские пользователи действительно подписывать п исходные сообщения (то есть, пользователь я подписанное сообщение Mi для я = 1; :::; п). Не знаю, о ECDSA, но билинейная карта на основе схема подписи все бушуют в эти дни ... |
|
|
|
|
18 июля 2013, 3:58:02 PM
|
# 6 |
|
Сообщений: 29
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Билинейные карты на основе схемы подписи все бушуют в эти дни ... Только в научных работах |
|
|
|
|
18 июля 2013, 4:54:36 PM
|
# 7 |
|
Сообщения: 700
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Билинейные карты на основе схемы подписи все бушуют в эти дни ... Только в научных работахДовольно много. Дайте им примерно десять лет для доверенный реализации появляться. |
|
|
|
|
18 июля 2013, 8:48:24 PM
|
# 8 |
|
Сообщения: 1218
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Некоторые системы подписывания ECC может сделать группировку операций, где вы можете создавать все ключи и все данные, подписанные и подтвердить все это с пренебрежимо малой вероятностью принятия если были признаны недействительными и нулевой возможности отказа, если все были признаны действительными. Но AFAIK ECDSA не такая схема, и те, которых я знаю, имеют большие подписи. (Ну, хотя, если вы должны были использовать его, чтобы всегда объединить все подписи в виде блок-, которые могут быть интересны). Может быть, мы говорим о разных вещах, но не ECDSA позволит создать составной ключ, просто добавив две закрытые ключи вместе. Подпись (которая будет иметь тот же размер, как отдельные клавиши) можно проверить, выполнив ту же ECC арифметики на открытых ключах. Например сказать, гипотетические транзакции (не в сети Bitcoin и не обязательно в том же формате) имеют следующую информацию в сделке. На данный момент формат / структура не очень важно. Сделка на теле: Версия NumInputs ArrayOfInputs [] NumOutputs ArrayOfOutputs [] Каждый вход в следующем формате: PrevTxHash PrevTxIndex Публичных До сих пор это очень похоже на Bitcoin однако нет никаких сценариев в входах TX. Каждый вход просто состоит из информации, необходимой для идентификации и аутентификации его (ОГО идентификатора, индекса, и открытого ключа). На этом этапе позволяет игнорировать формат выходов, как это не особенно важно для обсуждения этого вопроса. Теперь в отличие от Bitcoin, где каждый вход имеет подпись (упрощенный ТХ подписан ж / закрытый ключ, соответствующий Публичную перечисленные для входа) мы могли бы вместо того, чтобы иметь одну подписи для всей сделки. Также позволяет игнорировать ТЕ coinbase / поколения на данный момент. Так что для сделки с более чем одним открытым ключом входов мы сначала создать составной ключ, выполняя ECC арифметики. Назовое составной ключ ключа ОГО. Мы бы список входов, удаление дубликатов закрытых ключей и создать ключ ОГО, добавив частные ключи вместе. tx.privkey = privkey [0] + privkey [1] + ... privkey [2] Тогда мы подпишем весь ТХ раз с ключом ОГО. Сингл АЯ подпись будет добавлена к ОМУ. Версия NumInputs ArrayOfInputs [] NumOutputs ArrayOfOutputs [] Подпись Для проверки мы бы список входов, удалить дубликаты pubkeys и создать композитный материал таким же образом, как и privkeys. tx.pubkey = Публичные [0] + Публичный [1] + ... Публичных [2] ТЙ (композитный) Публичный будет проверять подпись, созданную ОЕ (композитным) privkey. Этот метод будет более ограничивающим, чем система Bitcoin сценария, однако это будет (с некоторыми другими изменениями) приводит к до 50% экономии с точки зрения требований к пропускной способности и хранения. Требования к мощности вычислительных должны быть примерно одинаковыми. Учитывая, что более 99% + сделок на сегодняшний день в сети Bitcoin являются "стандарт" платить pubkeyhash мы значительные сбережения. При использовании версий других более продвинутых ТХ будет по-прежнему возможно, и было бы возможным альтернативным крипто-валюты, чтобы иметь лучшее из обоих миров. Для "просто" Операции значительного сокращения потребностей в ресурсах, при этом имея возможность создавать более сложные операции. Есть ли риск для безопасности в формате, как это? Любое сокращение ключевой силы? Я не могу найти ничего, что указывало бы на это дело, но это на самом деле не моя область знаний. котировка ... его, конечно, можно в to-одном transaction- выставить кучу открытых ключей, компоновать их и подписать с составом. Но сокращение пространства уменьшается необходимость разоблачить ключи ... и было бы сделать анализ порча более мощным, потому что вы несколько сторон не может безопасно входить в этой модели. Это также несовместимо с sighash синглом. Если вы хотите, несовместимый ECC конкретных change- вы могли бы вместо того, чтобы добавить восстановление открытого ключа. Это получить аналогичные экономии пространства, но и сэкономить на операции с одним входом, а не нарушая способность запутать анализ заражать с совместными сделками, или нарушения альтернативных sighashes. Я предполагаю, что по "составить" вы имеете в виду ECC добавление закрытых ключей (а также отдельный ECC сложение pubkeys). Правильно? Я согласен есть необходимость открытого ключа для каждого входа для проверки подписи, однако подпись значительно больше. Для Bitcoin Публичный составляет 34 байт для сжатого Публичных (66 байт для несжатой pubkeys). Альтернатива CC может просто санкционировать использование сжатых открытых ключей в протоколе. Подпись 72 байта. Bitcoin Tx Входной формат TxOutHash - 32 байта TxOutIndex - 4 байта ScriptLength - переменная (1-9 байт, 1 наиболее распространенные) Подпись - 72 байта (в том числе кодирование) Публичный - 34 байт (сжатые ключи) Последовательность - 4 байта Всего: 147 байт (Подпись составляет 48% от размера входного) котировка и было бы сделать анализ порчи более мощным, потому что вы несколько сторон не могут безопасно входить в этой модели. Это также несовместимо с sighash синглом. Согласовано. котировка Если вы хотите, несовместимый ECC конкретных change- вы могли бы вместо того, чтобы добавить восстановление открытого ключа. Это получить аналогичные экономии пространства, но и сэкономить на операции с одним входом ... Интересно. Можете ли вы предоставить информацию или ссылки на восстановление открытого ключа? котировка Одна вещь, которую я иногда хочу, что сделки были сами хэш-деревья внутри. Было бы очень хорошо, чтобы быть в состоянии дать кому-то все данные, необходимые для создания тока UTXO надежно (и, таким образом, также убедитесь, что нет допускается инфляция в цепочке), не посылая им кучу глубоко заусениц данных подписи, которые ISN «т лично им интересно, и которые они считают, имеет достаточную безопасность hashpower только сделать рандомизированные выборочные проверки. Я прочитал это несколько раз и до сих пор не может осмыслять как хэш дерева в транзакции добавит безопасности. Я закладка его, хотя. |
|
|
|
|
18 июля 2013, 9:14:02 PM
|
# 9 |
|
Сообщений: 17
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Данный: закрытые ключи & б Открытые ключи & В Данные должны быть подписаны д Можно ли создать подпись S таким образом, что она может быть уточнена с учетом только A, B, и d? Почему бы не подписывать данные д с частным ключом, а затем подписать результат с закрытым ключом б, чтобы дать вам S. Используйте ключ B общественности затем открытого ключа А на S, чтобы привести данные г. Будет ли это решить исходную задачу? Хотя, как отмечалось, существуют различные элементы данных, поэтому он не будет работать на практике в любом случае. |
|
|
|
|
18 июля 2013, 9:20:28 PM
|
# 10 |
|
Сообщения: 1218
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Данный: закрытые ключи & б Открытые ключи & В Данные должны быть подписаны д Можно ли создать подпись S таким образом, что она может быть уточнена с учетом только A, B, и d? Почему бы не подписывать данные д с частным ключом, а затем подписать результат с закрытым ключом б, чтобы дать вам S. Используйте ключ B общественности затем открытого ключа А на S, чтобы привести данные г. Будет ли это решить исходную задачу? Хотя, как отмечалось, существуют различные элементы данных, поэтому он не будет работать на практике в любом случае. Это было бы для нового (несовместимого) формата сделки. Там не было бы различных предметов. Сделки будут просто быть подписаны на уровне ОГО. На данный момент это всего лишь академический, я просто хочу знать, если это может быть сделано, и, если это приводит к снижению безопасности. Может быть, я неправильно на этом. |
|
|
|
|
18 июля 2013, 10:43:06 PM
|
# 11 |
|
Сообщений: 17
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Данный: закрытые ключи & б Открытые ключи & В Данные должны быть подписаны д Можно ли создать подпись S таким образом, что она может быть уточнена с учетом только A, B, и d? Почему бы не подписывать данные д с частным ключом, а затем подписать результат с закрытым ключом б, чтобы дать вам S. Используйте ключ B общественности затем открытого ключа А на S, чтобы привести данные г. Будет ли это решить исходную задачу? Хотя, как отмечалось, существуют различные элементы данных, поэтому он не будет работать на практике в любом случае. Это было бы для нового (несовместимого) формата сделки. Там не было бы различных предметов. Сделки просто только будут подписаны на уровне ОГО. Я не считаю, что можно проверить двойную подпись, как вы описали. Помните, это проверка сущность с помощью открытого ключа не воссоздавать подпись и сравнивая его с оригиналом (если они могли бы сделать, чтобы они могли подделать подпись на любые данные). Они организация делает проверку можно проверить только если подпись действительна или нет (то есть истина или ложь). Я уверен, что это будет работать, чтобы делать то, что вы изначально описаны. В основном частный ключ используется со случайным числом для шифрования (знак) некоторые данные и открытый ключ используется для расшифровки (проверить подпись). Все, что я предлагал был знаком (шифровать) данные с закрытым ключом А затем подписать (шифровать) результат с закрытым ключом B. Чтобы проверить, просто расшифровать с помощью клавиши B публичного дешифровать с ключом А. общественности Они действительно только один способ функции. Я не уверен, что вы можете делать то, что вы описали выше. то есть вы не можете просто добавить много частных ключей, подписать сообщение, а затем просуммировать соответствующие открытые ключи и использовать это, чтобы проверить подпись (если это то, что вы имели в виду), даже если вы используете точку добавления EC. Я должен иметь вид, когда я больше бодрствует (трезвый) |
|
|
|
|
18 июля 2013, 11:21:32 PM
|
# 12 |
|
Сообщения: 1218
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Я не уверен, что вы можете делать то, что вы описали выше. то есть вы не можете просто добавить много частных ключей, подписать сообщение, а затем просуммировать соответствующие открытые ключи и использовать это, чтобы проверить подпись (если это то, что вы имели в виду), даже если вы используете точку добавления EC. Я должен иметь вид, когда я больше бодрствует (трезвый) Нет проблем. Я уверен, что это может быть сделано. Он используется для детерминированных кошельков, например, и для его проверяемого безопасного поколения тщеславия адреса. Это интересное свойство ключей ЕСС. Я просто хотел бы знать, если какие-либо криптографические эксперты увидели любое потенциальное снижение безопасности, как я ограниченные знания в области ECC. Если я не был пьян, я не помню, даже прикрываясь в колледже. Вы можете быть правы о подписании и проверки в методе вы описали. Я попробую поэксперементировать с OpenSSL. Мое предположение было бы, что если оба возможно, что при п ключи, п ключевых дополнений плюс одна подписи (или проверка) будет быстрее, чем п автографов (или проверка). |
|
|
|
|
18 июля 2013, 11:39:59 PM
|
# 13 |
|
Сообщения: 225
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Одна вещь, которую я иногда хочу, что сделки были сами хэш-деревья внутри. Было бы очень хорошо, чтобы быть в состоянии дать кому-то все данные, необходимые для создания тока UTXO надежно (и, таким образом, также убедитесь, что нет допускается инфляция в цепочке), не посылая им кучу глубоко заусениц данных подписи, которые ISN «т лично им интересно, и которые они считают, имеет достаточную безопасность hashpower только сделать рандомизированные выборочные проверки. Я прочитал это несколько раз и до сих пор не может осмыслять как хэш дерева в транзакции добавит безопасности. Я закладка его, хотя. Я желающие это сам; это позволило бы использовать конкретный случай, в котором я заинтересован: установка контракта. В качестве примера, в платежных каналах BitcoinJ, метод установки не предусматривает депозит риска от отправителя. При существующем способе формирования TXID, одна из сторон должна иметь всю транзакцию настройки для того, чтобы сгенерировать TXID для того, чтобы ссылаться на него в сделке возврата. Это означает, что если сервер поставить депозит риска, было бы в опасности потерять деньги постоянно (за счет клиента, чтобы быть уверенными, но это позволит DDoS к серверу, с помощью нескольких партий, пытающихся поставить его бизнеса по коллективно выбрасывая свои собственные деньги). С входных сценариев подписания хэш-дерево, обе стороны могут иметь хэш, используемый для TXID до подписания сделки настройки, чтобы они могли совместно подписать сделку возврата еще до подписания, гораздо меньше, разделяя подписи, операции установки. Это позволило бы также облегчить проблему с TXID пластичностью, где узлы или шахтеры могут добавлять вещи входных сценариев и изменить TXID без изменения действительности сделки. Кроме того, это позволило бы замену SIGHASH флагов с массивом хэшей, который должен быть в транзакции хэш дерева. Это позволило бы входы подписывать какие-либо части сделки, которые важны для них, и игнорировать остальные. Например, предположим, что существуют два хеш-деревьев, которые являются поддеревьев - хешей входов в одном хэш-поддерева и хэши выходов в другой хэш-поддерево. SIGHASH_ALL = корень хэш полного хэш-дерева SIGHASH_ALL | SIGHASH_ANYONECANPAY = хеш собственного входа, корень хэш-выходов поддерева SIGHASH_SINGLE | SIGHASH_ANYONECANPAY = хэш собственного ввода хэш-вывода вы заботитесь о (но более гибкий, потому что вы можете гарантировать, что все выходы, вы заботитесь о в там) SIGHASH_NONE = корень хэш входов поддерева SIGHASH_NONE | SIGHASH_ANYONECANPAY = пустой список Плохая часть нет прямого аналога SIGHASH_SINGLE (EDIT: в связи с запиранием порядковых номеров в входах), но я полагаю, для большинства (EDIT: или, по крайней мере, некоторые) случаев использования, это не какие-нибудь более полезным без SIGHASH_ANYONECANPAY, чем это есть с этим флагом. Лучше часть, замена для SIGHASH_SINGLE | SIGHASH_ANYONECANPAY позволяет вам подписать контракт выход и выход изменения в то же время от всех входов. Это позволяет использовать в ситуации, когда у вас есть разное количество входов от вашего количества выходов, или вы хотите, чтобы избежать некоторых из ваших выходов украденных при использовании SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. Это, безусловно, сделать вещи проще для микроплатеж контрактов каналов с более чем двух сторон. EDIT: Отсутствие чистой поддержки SIGHASH_SINGLE может быть облегчено путем окрошки каждого входной фактически хэш дерева своего собственным: хэш ввода эксклюзивного номера последовательности, а сам порядковый номер. Таким образом, вы могли бы перечислить хэш входа включительно или исключительного порядкового номера в зависимости от того, что вы заботитесь о. |
|
|
|
|
19 июля 2013, 1:06:18 AM
|
# 14 |
Сообщений: 17
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Нет проблем. Я уверен, что это может быть сделано. Он используется для детерминированных кошельков, например, и для его проверяемого безопасного поколения тщеславия адреса. Это интересное свойство ключей ЕСС. Я просто хотел бы знать, если какие-либо криптографические эксперты увидели любое потенциальное снижение безопасности, как я ограниченные знания в области ECC. Если я не был пьян, я не помню, даже прикрываясь в колледже. Да ты прав. Но частные ключи являются скалярными величинами, так что вы просто использовать добавить их с помощью нормального сложения и технически следует уменьшить по модулю п, где п есть порядок. Открытые ключи являются точками ЕС, так что вы добавить их с помощью добавления точки. Я думаю, что программы тщеславия адреса часто делают такие же вещи, но умножать все частные адреса, которые в данном случае являются частичными ключами (так что тщеславие адрес калькулятор не заканчивается, зная закрытый ключ). Это вычислительно более эффективным. Результат столь же безопасным. |
|
|
|
|
19 июля 2013, 3:14:25 AM
|
# 15 |
|
Сообщения: 2366
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Может быть, мы говорим о разных вещах, но не ECDSA позволит создать составной ключ, просто добавив две закрытые ключи вместе. Да, я говорил о чем-то другом там. Пакетная проверка. Я продолжал говорить о создании третьего ключа от двух других, хотя, что может быть сделано, но страдает некоторые ограничения, которые я упомянул.котировка Есть ли риск для безопасности в формате, как это? Любое сокращение ключевой силы? Я не могу найти ничего, что указывало бы на это дело, но это на самом деле не моя область знаний. Я не знаю ни вреда безопасности от делать это.котировка Интересно. Можете ли вы предоставить информацию или ссылки на восстановление открытого ключа? Если у вас есть подпись и сообщение его подпись и две многозначных, бит, вы можете восстановить открытый ключ, используемый. Это избавляет от необходимости передавать открытые ключи. Мы используем сегодня для Bitcoin signmessage.котировка Я прочитал это несколько раз и до сих пор не может осмыслять как хэш дерева в транзакции добавит безопасности. Я закладка его, хотя. Это не _add_ безопасности, что позволило бы более гибким компромиссы безопасности / вычисления / пропускной способности без ущерба для безопасности.Простой пример: Допустим, вы являетесь SPV узел. Полный узел сообщает вам о сделке платит вам, который находится в блоке. Вы действительно не дают @ # $ @@ о сделке _whole_, что вы действительно хотите является доказательством того, что конкретный txout в этом блоке. Сегодня полный узел должен послать вам полную transaction- вместе со всеми его потенциально раздутыми scriptsigs, которые вы не можете проверить (не хватают входов) и не заботитесь о том, и всех других результатах, которые не платят вам. Если сделка была внутренне структурирован дерево можно запросить только данные, представляющие интерес и до сих пор получить доказательства того, что эти данные были совершены в блоке в вопросе. |
|
|
|
|
19 июля 2013, 3:30:42 AM
|
# 16 |
|
Сообщения: 1218
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
котировка Есть ли риск для безопасности в формате, как это? Любое сокращение ключевой силы? Я не могу найти ничего, что указывало бы на это дело, но это на самом деле не моя область знаний. Я не знаю ни вреда безопасности от делать это.Спасибо. котировка котировка Интересно. Можете ли вы предоставить информацию или ссылки на восстановление открытого ключа? Если у вас есть подпись и сообщение его подпись и две многозначных, бит, вы можете восстановить открытый ключ, используемый. Это избавляет от необходимости передавать открытые ключи. Мы используем сегодня для Bitcoin signmessage.Интересно. Мне нужно, чтобы смотреть на это. Поэтому, когда исходное сообщение & подпись известны сразу может восстановить открытый ключ. Так почему же Bitcoin включает открытый ключ вход TX? Есть хорошая причина, или это просто из-за отсутствия понимания о том, как восстановление ключа может быть использован. Если я вас правильно понимаю, как в текущей Bitcoin ТХ каждый вход должен был бы быть подписан открытый ключ может быть извлечена. Это означало бы, один и тот же 72 байта на вход, но исключить из 34 Публичных байт на вход. Делает меньше 1 входы TX, но больше с множеством входов TX по сравнению с составным ключом, но по-прежнему всегда меньше "Bitcoin сегодня", Код: Сравнение размера требуемого pubkeys & подпись (ы) в байтах, где п = число входов. Сегодня Биткойн = (72 + 34) * п Tx Key = 34 * п + 72 Публичные Recovery (байты) = 72 * п Один вопрос: Что вы имеете в виду, "два бита неоднозначности"? котировка Это не _add_ безопасности, что позволило бы более гибким компромиссы безопасности / вычисления / пропускной способности без ущерба для безопасности. Простой пример: Допустим, вы являетесь SPV узел. ... Если сделка была внутренне структурирован дерево можно запросить только данные, представляющие интерес и до сих пор получить доказательства того, что эти данные были совершены в блоке в вопросе. Интересно. еще раз спасибо за развернутое знание. Получил я думал много альтернатив. |
|
|
|
|
19 июля 2013, 3:54:22 AM
|
# 17 |
|
Сообщения: 2366
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Интересно. Мне нужно, чтобы смотреть на это. Поэтому, когда исходное сообщение & подпись известны сразу может восстановить открытый ключ. Так почему же Bitcoin включает открытый ключ вход TX? Потому что, когда Bitcoin была написана Satoshi не знал этого. Это также несколько медленнее, чтобы сделать это таким образом, хотя экономия пространства достаточно велика, что я считаю, что это очень чистая победа. Кроме того, ваш ключ состоит материал требует накопления точек КИО, так что это не совсем бесплатно либо.котировка Делает меньше 1 входы TX, но больше с множеством входов TX по сравнению с составным ключом, но по-прежнему всегда меньше "Bitcoin сегодня", В буквальном смысле: два бита на неоднозначность несколько возможных открытых ключей. Валидатор может выполнить восстановление несколько раз, но это будет довольно медленным. Это необходимо по той же причине, сжатый открытый ключ необходим дополнительный бит для кодирования «знак» у-координат.Один вопрос: Что вы имеете в виду, "два бита неоднозначности"? Право, это не будет столь же мало, как сложенные ключи, но он также не будет иметь другие недостатки: ECDSA отдавая, делая общую собственность атаку deanonymization более мощной, лентяйничать до sighash одного, разрывая независимость входов. Если бы вы были готовы сделать составленный ключ signing- вы могли бы вместо этого просто использовали один адрес, или некоторый тип адреса, который используется общий ECDSA открытого ключа плюс порядковый номер (например, для устранения неоднозначности платежей). Тогда вы просто оптимизация, которая может агрегировать несколько автографов под тем же ключом в транзакции в один. ... хотя я и не любитель повторного использования адресов отдавая. |
|
|
|
|
21 июля 2013, 2:03:29 PM
|
# 18 |
|
Сообщений: 75
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Таким образом, вопрос ... Можно ли иметь единую подпись, которая требует два открытых ключей для его создания?
ECDSA основан на подписи ElGamal. Есть несколько вариантов, но давайте рассмотрим основные схемы подписи: Данный: Генератор г Секретный ключ х у открытого ключа = г ^ х Сообщение м Подпись (R, S) на сообщение м справедливо, если г ^ т = у ^ г * г ^ ы Как gmaxwell указывает, можно вычислить у (открытый ключ) от подписи и сообщения, как у = (г ^ м / г ^ S) ^ (1 / г). Для проверки подписи, вы, конечно, должны проверить, что этот открытый ключ, который вы ожидали. Представляется возможным сделать подпись из двух открытых ключей А и В такие, что г ^ т = (А * В) ^ г * г ^ з Очевидно, что это было бы несовместимо с текущим протоколом Bitcoin, но это не представляется возможным в теории. Я не совсем уверен, связанные с безопасностью таких подписей. Я должен думать об этом еще. |
|
|
|
|
22 июля 2013, 4:14:27 AM
|
# 19 |
|
Сообщений: 75
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Так на самом деле это не будет работать. Злоумышленник может просто добавить ввод с помощью открытого ключа, который является мультипликативной инверсией вашего открытого ключа.
Таким образом, если А = у и В = (1 / у) подпись проверяется как: г ^ т = (А * В) ^ г * г ^ ы г ^ т = (г / г) ^ г * г ^ ы г ^ т = 1 ^ г * г ^ ы г ^ т = г ^ ы который тривиальный подделан. Делая немного больше исследований, я считаю, что можно использовать эллиптические кривую арифметику, чтобы добавить секретные ключи вместе, чтобы создать "мастер" Секретный ключ для подписания и этого мастера закрытого ключа можно проверить путем добавления открытых ключей вместе, чтобы сформировать открытый ключ мастер. И в эллиптической кривой арифметике, добавьте обратное, получая единичный элемент. Злоумышленник может добавить свой собственный открытый ключ, чтобы избежать точек на бесконечности. Комбинированное "мастер" Открытый ключ является небезопасным. Так что это не работает. |
|
|
|
|
22 июля 2013, 1:59:47 PM
|
# 20 |
|
Сообщения: 539
цитировать ответ |
Re: Вопрос о ECDSA подписания (более эффективное ОЕ подписание)?
Если бы вы были готовы сделать составленный ключ signing- вы могли бы вместо этого просто использовали один адрес, или некоторый тип адреса, который используется общий ECDSA открытого ключа плюс порядковый номер (например, для устранения неоднозначности платежей). Тогда вы просто оптимизация, которая может агрегировать несколько автографов под тем же ключом в транзакции в один. ... хотя я и не любитель повторного использования адресов отдавая. Для того, чтобы заставить его работать в стандартном клиенте у вас есть два варианта: 1. Отправитель добавляет косую OP_CODESEPARATOR к сценарию (это нестандартное TX) и должно быть направлено непосредственно на комбайн. 2. Вы создаете P2SH адрес скрипта, содержащего замыкающую OP_CODESEPARATOR. Для того, чтобы погасить денежные средства вам потребуется, чтобы отправить сделки непосредственно шахтера, так как это будет нестандартным. Это, очевидно, непреднамеренное использование OP_CODESEPARATOR, и я обескуражить использовать этот метод, но я думаю, что это работает. |
|
|
|
Как заработать Биткоины?
Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包
bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru
3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW
Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包
bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru
3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW
Регистрация для новых участников, на данный момент не доступна. Просим извинения за временные неудобства.