Вернуться   Биткоин Форум > Разработка и Техническое Обсуждение
25 августа 2012, 1:23:43 PM   # 1
 
 
Сообщения: 1526
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome"
Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE
Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e
подробнее...


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
Много хорошей работы по масштабируемости было сделано в последнее время, albiet еще не объединены. Так что скоро это будет время, чтобы обновить масштабируемость вики записей страница / FAQ.

Для полных узлов LevelDB и, что гораздо важнее, sipas ultraprune работы на более эффективные рабочие наборах поставить нас обратно в точку, где проверка ECDSA является узким местом, а не IO.

Я хочу сделать примерно упорядоченный список известных методик можно использовать для повышения пропускной способности проверки подписи. Как это выглядит:

  • Устранение избыточных проверок подписи (DONE)
  • Многопоточная проверка подписи. Это легче после Sipa рефакторинга. Для большинства машин, на которых Bitcoin бежит это даст как минимум в ое ускорение (я сомневаюсь, что кто-то использует одноядерные машины больше) и для серверов, больше похож на 4-8x ускорения предполагающего это нормально, чтобы насытить все ядра.
  • Реализовать Коблиц-кривой конкретных оптимизация, это метод Г и Hal объяснил, как это сделать некоторое время назад. По-видимому, это что-то вроде 20% ускорения в но может пойти выше.
  • Разрешить мульти-машина sharded проверки, так что вы можете иметь несколько машин параллельно. Конечно, это приводит нас больше к "supernode" дизайн, который некоторые считают спорным.

Там также могут быть способы использования экзотических инструкций процессора, как те, в SSE3 или AES-NI. Там какая-то его обсуждение Вот, но это, кажется, относится только к бинарным кривым, а не кривым простого порядка, которые мы используем.

Много исследований было сделано в последние годы на пути сделать ECDSA быстрее, но, к сожалению, почти все они несовместимы с secp256k1 кривой Bitcoin использует. Пакетная проверка, в частности, как представляется, требует внесения изменений в подписи (по крайней мере, что я был в состоянии найти). Получение доступа к этим ускорениям будет означать глобальное обновление и жесткую вилку. Но то, что убыстрение может привести!

DJB и друзья утверждают, что с их ed25519 кривых ( "издание" для Эдвардса) и осторожное осуществление они могут сделать пакетную проверку 70,000+ подписей в секунду на дешевом четырёхъядерный Intel Westmere чип, который в настоящее время несколько поколений назад. С учетом достижений в области процессоров с течением времени, вполне вероятно, что в ближайшем будущем цитируемого программное обеспечение будет возможностью проверить многие сотни тысяч подписей в секунду, даже если держать ядро ​​рассчитывать константу. Но основные отсчеты не являются постоянными - вполне вероятно, что в течение 10 лет или около 24-32 чипов будут стандартными даже на потребительских настольных компьютерах. В этот момент миллион подписей в секунду или больше не звучит неразумно.

Если мы успешно управлять первый жесткий вилочный процесс, кажется поэтому, что даже обычные компьютеры вы можете иметь в вашем доме (при достаточно оперативной памяти и пропускной способности) будут способны идти в ногу с движением грузов далеко сверх того, что как VISA и MasterCard ручка в сочетании ,
Майк Хирн сейчас офлайн Пожаловаться на Mike Хирн   Ответить с цитированием Мультицитирование сообщения от Mike Хирн Быстрый ответ на сообщение Mike Хирн


Как заработать Биткоины?
Без вложений. Не майнинг.


25 августа 2012, 2:04:04 PM   # 2
 
 
Сообщения: 1050
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

Получил 1806 Биткоинов
Реальная история.





Есть больше потенциальных оптимизации:
  • Пакетная проверка: теоретически, должна быть возможность проверить различные подписи в одной транзакции или одного блока на один раз, так как мы не заботимся, чтобы знать, какая подпись не удается. Это кажется очень экспериментальным, но я читал вещи о ускорении до 4x
  • Специализированная / реализация сборки: для кривой NIST-P256 (ака secp256r1), Google реализовала оптимизированную версию, которая 3-4е разы быстрее на x86-64. Их методы могут быть переносимыми на secp256k1?

Для справки, проверка сценария достигает скорости 1735 сиг поверок в секунду, на одном ядре моего ядра i7-2670QM (2.2 ГГц) процессор. Предполагая, что по крайней мере, оптимизация и parallellisation Хэла возможны без дополнительных накладных расходов, 8000 sigops / с должно быть выполним на этом процессоре, что означает проверяющий текущий блок наихудшего (из-20К sigops предела) в 2.4S.
Pieter Wuille сейчас офлайн Пожаловаться на Pieter Wuille   Ответить с цитированием Мультицитирование сообщения от Pieter Wuille Быстрый ответ на сообщение Pieter Wuille

25 августа 2012, 2:27:58 PM   # 3
kjj
 
 
Сообщения: 1302
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

Что касается кривой, я действительно предпочитаю двигаться к кривой, которая лучше, чем доверенный тот, который быстрее. Secp256k1 не используется широко, и некоторые люди считают его небезопасным. Ну, не небезопасные точно, может быть, нервный; они не имеют уверенности в нем, что они имеют в некоторых других кривых.

Если есть оптимизации известна популярными, широко доверенные кривые, что было бы лучше.

Один небольшой недостаток в росте FPGA / ASIC добычи полезных ископаемых является то, что шахтеры не будут автоматически груды почти-простоя процессоров, сидя вокруг управления их графических процессоров, которые могли бы участвовать в объединенных схем проверки. (Я что-то вроде DistCC думать) я стрелять в BFL парень по электронной почте, они будут скоро груда АСВА сидит вокруг, как они покупают их от людей, переходящих на СБИС, возможно, они были бы заинтересованы в перепрофилирования их верификации подписи устройства.
kjj сейчас офлайн Пожаловаться на kjj   Ответить с цитированием Мультицитирование сообщения от kjj Быстрый ответ на сообщение kjj

25 августа 2012, 3:35:41 PM   # 4
 
 
Сообщения: 1526
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

Есть больше потенциальных оптимизации:

Да, вы будете видеть, что я упомянул оба этих уже:

котировка
DJB и друзья утверждают, что с их кривыми ed25519 ( "издание" для Эдвардса) и осторожное осуществление они могут сделать пакетную проверку 70,000+ подписей в секунду на дешевые четырёхъядерный чип Intel Westmere

Это реализация ed25519 написана на ассемблере и изготовлена ​​специально для использования как много ILP, насколько это возможно, наряду с тем, что инструкции процессора доступны (у них есть реализация, которая требует поддержки amd64).

Насколько я знаю, последние результаты для GPU / FPGA ускорения ECDSA показывают либо нет ускорений на все или только тривиальные ускорения. Это не то, что по своей природе превосходит с выделенными аппаратными средствами, по-видимому.

Во всяком случае, учитывая потенциал для почти 100k (партии) верификации в секунду только с помощью программного обеспечения, кажется, лучше проводить эти подходы скорее. Ваш пункт о безопасности выбранных кривых хорошо сделан, но я не знаю, как вы получите больше уверенности в безопасности нового кривой или версии ECDSA, не пытаясь его в дикой природе.
Майк Хирн сейчас офлайн Пожаловаться на Mike Хирн   Ответить с цитированием Мультицитирование сообщения от Mike Хирн Быстрый ответ на сообщение Mike Хирн

25 августа 2012, 4:05:18 PM   # 5
 
 
Сообщения: 1652
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

Если мы успешно управлять первым жестким вилочным процессом ...

Я не думаю, что новый алгоритм подписи не требует жесткой вилки; переопределить OP_NOP как OP_CHECKSIGVERIFY2, который использует ed25519, создать новый «стандартный» тип транзакции, использующие этот новый код операции, а также новый тип адреса Bitcoin, который соответствует его, а затем начать развертывание поддержки шахтер, и т.д., как схематически изображено Вот.

Это, вероятно, будет лучше, чем жесткая вилка; Я не уверен, что план перехода будет выглядеть для старых сделок, если OP_CHECKSIG была пересмотрена, чтобы использовать кривую ed25519.

Если новый тип сделки была значительно дешевле, то дешевле операционные издержки могли бы стимулировать людей к модернизации своих клиентов / бумажники.

Я не думаю, что сейчас самое подходящее время, чтобы сделать какой-либо из этого, в основном потому, что я не удивлюсь, если какое-то решение для мгновенного "с цепи" выплаты принимаются вместо этого, в этом случае, возможно, sep256k1 стоимость сделки будет незначительная.
Гэвин Андресен сейчас офлайн Пожаловаться на Гэвин Андресен   Ответить с цитированием Мультицитирование сообщения от Gavin Andresen Быстрый ответ на сообщение Гэвин Андресен

25 августа 2012, 4:16:04 PM   # 6
kjj
 
 
Сообщения: 1302
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

Насколько я знаю, последние результаты для GPU / FPGA ускорения ECDSA показывают либо нет ускорений на все или только тривиальные ускорения. Это не то, что по своей природе превосходит с выделенными аппаратными средствами, по-видимому.

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

Это не просто сырой скорость, это скорость за доллар, или скорость в расчете на ватт. Если вы можете подключить устройство питания USB низки, проверяющий Sigs, а также ваш процессор, это сервер вам не нужно покупать, власть и прохладно. Может быть стоит посмотреть в, я не говорю, что это ответ.

Ну, мы в инновационном криптографическом бизнесе, или инновационные деньги бизнес? Я знаю, что есть некоторые совпадения, но я бы предпочел, чтобы мы были столь же консервативны, как мы можем быть и позволить другим людям взять на себя риски, которые мы делаем не совсем иметь к. Не то, что я думаю, что там будет нулевой день выпущен для Secp256k1 нибудь ...
kjj сейчас офлайн Пожаловаться на kjj   Ответить с цитированием Мультицитирование сообщения от kjj Быстрый ответ на сообщение kjj

25 августа 2012, 4:24:32 PM   # 7
 
 
Сообщения: 1526
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

Это, вероятно, будет лучше, чем жесткая вилка; Я не уверен, что план перехода будет выглядеть для старых сделок, если OP_CHECKSIG была пересмотрена, чтобы использовать кривую ed25519.

Конечно, я больше думал, что бы просто новый флаг sighash, указывающий, что подпись нового типа.

Переосмысление NOP, означает, что торговцы, которые не модернизируют получить эффективно понижены до SPV безопасности уровня (доверие прочности цепи), а не полной проверки, потому что я мог бы послать им сделку, которая тратит деньги никому ELSES и они принимают его. Или это не так? И нулевое подтверждение сделка фактически негодна, конечно.

Я думаю, что если бы я был с помощью веб-сайта Bitcoin, что я не платил много внимания я бы скорее он просто перестал работать, чем прошел через немое понижение безопасности. Когда люди жалуются мне сайт не замечая новые платежи, это просто обновление программного обеспечения, чтобы исправить сбой. Но если кто-то платит мне с кем-то ELSES монет и умудряется кормить меня такой блок, что может привести к серьезным потерям.

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

Что бы такое решение выглядит?
Майк Хирн сейчас офлайн Пожаловаться на Mike Хирн   Ответить с цитированием Мультицитирование сообщения от Mike Хирн Быстрый ответ на сообщение Mike Хирн

25 августа 2012, 6:14:38 PM   # 8
 
 
Сообщения: 1652
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

Переосмысление NOP, означает, что торговцы, которые не модернизируют получить эффективно понижены до SPV безопасности уровня (доверие прочности цепи), а не полной проверки, потому что я мог бы послать им сделку, которая тратит деньги никому ELSES и они принимают его. Или это не так?
Это неверно; Вы не могли бы послать транзакцию нового стиля торговца, если они бы уже модернизированы и издавали адреса нового стиля.

... которая на самом деле просто BIP16 адреса, с сценарий выкупа быть что-то вроде  OP_NOP1
(Я неправ о необходимости нового Bitcoin типа адреса).

Очевидно торговцы не начать делать это до тех пор, большинство шахтеров не интерпретировали OP_NOP1 в OP_ED25519_VERIFY.

котировка
котировка
Я не думаю, что сейчас самое подходящее время, чтобы сделать какой-либо из этого, в основном потому, что я не удивлюсь, если какое-то решение для мгновенного "с цепи" выплаты принимаются вместо этого, в этом случае, возможно, sep256k1 стоимость сделки будет незначительная.
Что бы такое решение выглядит?
http://gavintech.blogspot.com/2012/07/off-chain-transactions.html
Гэвин Андресен сейчас офлайн Пожаловаться на Гэвин Андресен   Ответить с цитированием Мультицитирование сообщения от Gavin Andresen Быстрый ответ на сообщение Гэвин Андресен

25 августа 2012, 6:36:08 PM   # 9
 
 
Сообщения: 144
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

... новый тип Bitcoin адрес ...

Почему бы потребовался новый тип адреса? Я думал, что точка P2SH в том, что это последний раз, когда новый тип адреса всегда необходим. Любой, кто может отправить P2SH адреса должны автоматически иметь возможность отправлять по адресам, используя новые правила проверки.
twobitcoins сейчас офлайн Пожаловаться на twobitcoins   Ответить с цитированием Мультицитирование сообщения от twobitcoins Быстрый ответ на сообщение twobitcoins

25 августа 2012, 7:58:28 PM   # 10
 
 
Сообщений: 19
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

Если мы успешно управлять первым жестким вилочным процессом ...

Я не думаю, что новый алгоритм подписи не требует жесткой вилки; переопределить OP_NOP как OP_CHECKSIGVERIFY2, который использует ed25519, создать новый «стандартный» тип транзакции, использующие этот новый опкодом и новый тип адреса Bitcoin, соответствующий ему
При добавлении инструкции, пожалуйста, разделить его на инструкцию, которая выталкивает сериализированную транзакцию, и тот, который проверяет подпись данных в стеке. Наличие общего назначения подписи инструкции проверки было бы хорошо. В частности, это позволило бы интересный вариант вне-цепи сделок.

А почему новый тип адреса? Не являются скрипт хэш-адреса достаточно?

----

В качестве побочного сведению: Ed25519 не только ECDSA на другой кривой. Это другой алгоритм подписи на основе сигнатур Шнорры. Не уверен, насколько велики последствия этого есть, но я подозреваю, что восстановление открытого ключа не представляется возможным с ним.
CodesInChaos сейчас офлайн Пожаловаться на CodesInChaos   Ответить с цитированием Мультицитирование сообщения от CodesInChaos Быстрый ответ на сообщение CodesInChaos

26 августа 2012, 3:23:57 AM   # 11
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

В качестве побочного сведению: Ed25519 не только ECDSA на другой кривой. Это другой алгоритм подписи на основе сигнатур Шнорры. Не уверен, насколько велики последствия этого есть, но я подозреваю, что восстановление открытого ключа не представляется возможным с ним.

восстановление открытого ключа можно с ним, если тривиальные модификациями. (IIRC алгоритм, для главным образом пояса-и-подтяжки причин смешивает хэш ожидаемых Публичной в значение подписания, так что необходимо будет изменить на хэш-адрес, а)
gmaxwell сейчас офлайн Пожаловаться на gmaxwell   Ответить с цитированием Мультицитирование сообщения от gmaxwell Быстрый ответ на сообщение gmaxwell

26 августа 2012, 1:38:41 PM   # 12
 
 
Сообщения: 1526
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

Это неверно; Вы не могли бы послать транзакцию нового стиля торговца, если они бы уже модернизированы и издавали адреса нового стиля.

То, что я имел в виду, я иду и найти выход на цепи, что не-модернизирована торговец будет видеть, как NOP / всегда-действительным. Тогда я послал ему сделку, которая подключается к нему, а затем регулярному выходу в старом стиле, который использует адрес купец дал мне. Я считаю купцам IP-адрес (возможно, узел работает на веб-сервере) и отправить их сделку. Oни "проверить" это и открыть входной скрипт удовлетворяет вывод, что заставляет их думать, что они получили деньги.

Конечно, если продавец ждет N подтверждений становится все труднее и труднее, но по сути это SPV модель безопасности. Торговец был понижен до него, не понимая.

Майк Хирн сейчас офлайн Пожаловаться на Mike Хирн   Ответить с цитированием Мультицитирование сообщения от Mike Хирн Быстрый ответ на сообщение Mike Хирн

26 августа 2012, 7:05:40 PM   # 13
 
 
Сообщения: 1652
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

То, что я имел в виду, я иду и найти выход на цепи, что не-модернизирована торговец будет видеть, как NOP / всегда-действительным. Тогда я послал ему сделку, которая подключается к нему, а затем регулярному выходу в старом стиле, который использует адрес купец дал мне. Я считаю купцам IP-адрес (возможно, узел работает на веб-сервере) и отправить их сделку. Oни "проверить" это и открыть входной скрипт удовлетворяет вывод, что заставляет их думать, что они получили деньги.
Да, это был один из уроков, извлеченных из BIP16-- операций искупительная нестандартным входы должны быть нечто пролеченных в нестандартности. И они, как о v0.6 (я думаю, я очень хорошо забыть, когда были введены изменения).

Если продавец использует акцию bitcoind, то нестандартная сделка не будет отображаться в кошельке до тех пор, пока не появится в блоке с 1 подтверждением, что делает понижение рейтинга безопасности не существует (она становится вариацией атаки Финня).
Гэвин Андресен сейчас офлайн Пожаловаться на Гэвин Андресен   Ответить с цитированием Мультицитирование сообщения от Gavin Andresen Быстрый ответ на сообщение Гэвин Андресен

27 августа 2012, 10:06:49 AM   # 14
 
 
Сообщения: 1526
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

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

Во-первых, мы должны читать и понимать эту статью:

    http://www.mathnet.or.kr/mathnet/preprint_file/cacr/2005/cacr2005-28.pdf

Основная методика, изложенная в ней не применяется к Bitcoin, потому что, как они говорят:

котировка
Из анализа случая в предыдущем параграфе, то отсюда следует, что преобразование сигнатуры Верьте фи уравнение катиона значимо уменьшает размер скалярных кратные, участвующие в этом уравнении (если можно хранить одну предварительно вычисленное кратное генератора G). В результате, мы могли бы ожидать значительное ускорение подписных VERI катионов Ф.И., так как это исключает большое количество операций точек удвоения, общий элемент в нескольких точечных умножениях. Мы ожидаем, означающим улучшения фи наклоняет, как для простых кривых, так и для случайных бинарных кривых. Для кривых Köblitz, мы можем ожидать лишь незначительное улучшение, так как для этих кривых отображение Фробениуса (который берет на себя роль точки удвоения) идет почти бесплатно.

Тем не менее, модифицированный алгоритм ECDSA * является обязательным требованием, чтобы использовать технику пакетной проверки от Cheon и Yi.

ECDSA * представляет собой простое преобразование ECDSA, что дает большие подписи, но которые могут быть (партия) проверено более быстро. Подписи могут быть преобразованы между формами и имеют одинаковую безопасность. Основное отличие состоит в том, что вместо подписи является (R, S) где г Й Координата точки в аффинном пространстве по модулю N, то подпись становится (R, S), где R представляет полную точку, включая Y со -ordinate. Конечно "р" по-прежнему необходимо на этапе проверки, но это быстро трансформировать и дополнительные данные полезны позже.

Техника, которая имеет значение для нас является тем, что описан в разделе 4.2 настоящего документа:

    http://www.iacr.org/archive/pkc2007/44500442/44500442.pdf

Они утверждают, 4x, когда ускорение дозирования проверку вместе для случая множественного подписчика, больше 7x для случая одиночных подписывающих (получаемого путем группировки сигнатур по адресу) и ое ускорение для отдельных подписчиков на кривых Köblitz. По крайней мере, я думаю, что это ое. Мое понимание раздела-немного Каболки - я ценю кого-то с более сильной хваткой эллиптической кривой математики читать его и проверяя, что это действительно ое, так как сравнения они дают в конце немного сбивают с толком.

Чтобы модифицировать Bitcoin для этого без необходимости переопределить любые опкоды или сделать что-нибудь еще, что изменяет основные сообщения, мы можем определить CTransaction2 сообщения, которое оборачивает в CTransaction. Вне сообщения CTransaction обеспечивает значения R для каждой подписи отдельно. Узлы хранения сообщений CTransaction2. Они направляются только к узлам, которые поддерживают достаточно высокую версию протокола, в противном случае, завернутое CTransaction отправляется, а и старые узлы не воспринимают никакой разницы. Очевидно блок хэширования и так далее все делается на обернутых сообщений. Когда (г, з) подпись получена от старшего узла, то новый узел вычисляет R от него, чтобы он мог сохранить новее Узлы дополнительной работу делать сами преобразования.

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

По очевидным причинам пакетная проверка применяется в основном при скорости транзакций очень высока. В противном случае это просто способ сделать хвост-конец начального блока загрузки быстрее, что в долгосрочной перспективе будет становиться все менее и менее интересно, как узлы становятся более стабильными и долговечны.
Майк Хирн сейчас офлайн Пожаловаться на Mike Хирн   Ответить с цитированием Мультицитирование сообщения от Mike Хирн Быстрый ответ на сообщение Mike Хирн

28 августа 2012, 2:47:40 AM   # 15
 
 
Сообщения: 314
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

Привет Майк. Я до сих пор жив жив, но сильно ограничены.

Я посмотрел на первую работу, которая, как вы знаете, не о пакетной проверке. Это дает скорость, если вы знаете, R, что мы уже должны получить только с г, с нашей псевдо Köblitz кривой. Но я обнаружил, что я пропустил существенную оптимизацию в моей реализации Köblitz, что расколоть G умножение на два, с показателями половины размера. Это должно повысить ускорение от 20% до более похожего на 40% они утверждают. Так что спасибо! (Не то, что я могу сделать что-нибудь об этом. Надеюсь, это намек будет достаточно.)

На пакетной проверки, я думал о много kludgier подхода. Имейте в виду, что в текущей подписи (г, s), г только х-координата R. Таким образом, мы должны поставить у-координату. (На самом деле, это не важно, но это экономит много места.) Таким образом, в настоящее время scriptSig выталкивает ключ и подпись на стеке. Моя идея состояла в том, чтобы первый толчок магическое число и координаты у Р. Будем надеяться, что унаследованный код будет игнорировать эти две глубокие значения стека, и просто проверить подпись традиционно. Но новый код может проверить магическое число, реконструировать R и сделать пакетную проверку. Этот способ операции могут транслироваться которые были обратно совместимы.

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

Я стараюсь смотреть на вторую линии завтра и посмотреть, если такие драматические ускорения возможны. Я попробовать эксперимент, в котором я заплатки из проверки подписи полностью, только что она возвращает истину. Я не получил все я ускорение желавшему для на начальной blockchain загрузки. Интересно повторить, что теперь он занимает так много больше.
Hal сейчас офлайн Пожаловаться на Hal   Ответить с цитированием Мультицитирование сообщения от Hal Быстрый ответ на сообщение Hal

28 августа 2012, 10:24:54 AM   # 16
 
 
Сообщения: 1526
Цитировать по имени
цитировать ответ
по умолчанию Re: Теоретическая скорость макс для проверки ECDSA

Спасибо за входной Hal, это чрезвычайно полезно, как всегда, чтобы иметь профессиональный взгляд криптограф над этими вещами. Мы знаем, что это требует усилий, чтобы отправить эти дни, и оценить это много.

40% скорость из вашего кода, безусловно, один из следующих низких висят фруктов после многопоточной проверки. Я подозреваю, что интеллектуальный микро-оптимизации (с использованием SSE3 и т.д.) может получить нам немного больше скорости тоже.

Причина вы не видели много ускорения от выключения проверки подписи является то, что код базы данных очень неэффективно. Вы можете попробовать слияние sipas ultraprune ветви. Вы также можете попробовать свои LevelDB ветвь. Я не думаю, что они объединяемы вместе, к сожалению, пока по крайней мере (один должен быть перебазировались на другой). LevelDB использует более эффективный формат на диске и перемещает диск IO в отдельный поток, ultraprune резко сокращает размер базы данных (только удерживать неизрасходованные выходы), который уменьшает рабочий набор и делает его также намного более эффективным. С этими изменениями мы уже видели блок цепь раз индексации, измеренные в течение нескольких минут, когда отключена проверка подписи.

После того, как все работы базы данных объединены в, Bitcoin будет упираются на CPU в обозримом будущем, что является правильным и как это должно быть. Вот почему я сейчас расследую, как далеко мы можем нажать проверку ECDSA - Я хочу, чтобы повторно вычислить число масштабируемости. Там часто говорят о Bitcoin быть просто позвоночником платежей или протокол расчетов между "bitbanks" но я надеюсь, что мы можем избежать этого и остаться как можно ближе к Satoshis зрения, насколько это возможно.

С последними результатами научного сообщества, это выглядит более целесообразным, что один мощный компьютер (по сегодняшним меркам) может обрабатывать в основном все сделки, которые кредитная карточка компании / PayPal обработки и многое другое. Конечно, как мы используем Bitcoin в будущем будет отличаться, и я думаю, что дешевые сделки будут открывать новые прецеденты, которые не были ранее возможностями, так что в конце концов, чтобы справиться с таким же количеством людей, как ЦК инфраструктура потребует больше ТХ пропускного чем они делают. Но даже в этом случае, потребность в мульти-машины "суперузлов" кажется, отступает.
Майк Хирн сейчас офлайн Пожаловаться на Mike Хирн   Ответить с цитированием Мультицитирование сообщения от Mike Хирн Быстрый ответ на сообщение Mike Хирн



Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW