7 февраля 2011, 10:31:27 PM   # 1
 
 
Сообщения: 314
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

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


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
В другом потоке [микрофон] писал:

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

http://portal.acm.org/citation.cfm?id=1514739

http://www.hyperelliptic.org/tanja/KoblitzC.html

Я пытаюсь inplement в secp256k1 ярлык. Если есть результаты в ближайшее время. К сожалению, я только ожидать около 20% ускорения. Посмотрим.

Я также смотрел на проверку подписи пакетного:

http://cseweb.ucsd.edu/~mihir/papers/batch.pdf

http://www.math.snu.ac.kr/~jhcheon/publications/2007/BatchVer_PKC2007_CL.pdf

Это теоретически может ускорить проверку почти в 4 раза (таблица 6 в 2-бумаге), если у вас есть много подписей в пакете. Это требует небольшого изменения в формате ECDSA подписи: (R, S) заменяется на (R, S), где R является точкой ЕС, который г координаты х. Это изменение может быть применено задним числом, так как R вычисляется и отбрасывает каждый раз, когда сиг проверяется.

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

Мне нужно исследовать некоторые аспекты безопасности, а именно: это R необходимо проверить, чтобы увидеть, если он находится на кривой (т.е. у ^ 2 = х ^ 3 + 7)? А что соответствующий параметр безопасности для вероятности партии проверить тест можно обмануть? Документы говорят о 2 ^ 80, но это кажется слишком консервативным.
Hal сейчас офлайн Пожаловаться на Hal   Ответить с цитированием Мультицитирование сообщения от Hal Быстрый ответ на сообщение Hal


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


8 февраля 2011, 7:11:52 AM   # 2
 
 
Сообщения: 314
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

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





Я реализовал оптимизированный ECDSA проверить для secp256k1 кривых, используемого Bitcoin, основанный на страницах 125-129 Руководства по криптографии эллиптических кривых, по Hankerson, Менезес и Ванстоуну. У меня есть книга, но я также нашел PDF на русском сайте, который является более удобным.

secp256k1 использует следующее простое для его координаты х и у:

р = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f

и порядок кривой:

п = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

Первый шаг состоит в вычислении значений беты, лямбда таким образом, что для любой точки кривой Q = (х, у):

лямбда * Q = (бета * х по модулю р, у)

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

Книга рассказывает (ну, подсказки), как вычислить лямбда и бета, а вот значения, которые я нашел:

лямбда = 0x5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72

бета = 0x7ae96a2b657c07106e64479eac3434e99cf0497512f58995c1396c28719501ee


Учитывая, что мы можем умножить лямбда быстро, вот трюк, чтобы вычислить K * Q. Сначала используйте ярлык для вычисления Q»= лямбда * Q. Далее, к должно быть разложен на две части k1 и k2, каждый примерно половину ширины п, таким образом, что:

к = к1 + к2 * лямбда-мод п

затем

к * Q = (k1 + k2 * лямбда) * Q = k1 * Q + к2 * лямбда * Q = k1 * Q + k2 * Q»,

Это последнее выражение можно оценить эффективность с помощью двойного умножения алгоритма, а так как k1 и k2 половины длины, мы получаем ускорение.

Недостающая часть раскалывает к на k1 и k2. Это использует следующие 4 значения:

a1 = 0x3086d221a7d46bcde86c90e49284eb15
b1 = -0xe4437ed6010e88286f547fa90abfe4c3
а2 = 0x114ca50f7a8e2f3f657c1108d9d44cfd8
b2 = 0x3086d221a7d46bcde86c90e49284eb15

(Это нормально, что a1 = b2)

Используйте их, как следует разделить к:

с1 = RoundToNearestInteger (b2 * к / п)
с2 = RoundToNearestInteger (-b1 * к / п)

k1 = к - c1 * a1 - a2 c2 *
k2 = -c1 * b1 - c2 * b2


При всем этом, я измеряю около 25% ускорений на сырье подписи поверок. Для Bitcoin, блок начальной загрузки с WiFi подключенного локального узла уменьшается с:

реальный 36m21.537s
пользователь 24m43.277s
SYS 0m27.950s

чтобы:

реальный 32m59.777s
пользователь 18m21.145s
SYS 0m28.262s

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

8 февраля 2011, 12:28:00 PM   # 3
 
 
Сообщения: 1526
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Качественный товар! A 25% выигрыша довольно существенно, если смотреть на него с точки зрения аппаратных затрат, а не начальной загрузки. Было бы, конечно, падение стоимости запуска масштаба VISA узла.

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

8 февраля 2011, 9:08:58 PM   # 4
 
 
Сообщения: 314
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Я поставил код вверх на GitHub. Я программист на более чем C ++; это показывает.

https://github.com/halfinney/bitcoin/tree/secp256k1

Вот самодостаточная тестовая программа, которая сравнивает скорость. Стройте с -lcrypto.

Код:
#включают
#включают
#включают
#включают
#включают

#define Репс 1000


// Разделить secp256k1 показатель к в два меньших k1 и k2 такие, что для любой точки Y,
// к * Y = k1 * Y + k2 * Y 'где Y' = лямбда * Y очень быстро
статическая ИНТ
splitk (BIGNUM * bnk1, BIGNUM * bnk2, Const BIGNUM * БНК, Const BIGNUM * BNN, BN_CTX * CTX)
{
    BIGNUM * BNC1 = BN_new ();
    BIGNUM * BNC2 = BN_new ();
    BIGNUM * bnt1 = BN_new ();
    BIGNUM * bnt2 = BN_new ();
    BIGNUM * bnn2 = BN_new ();
    статический символ без знака A1B2 [] = {
        0x30, 0x86, 0xd2, 0x21, 0xa7, 0xd4, 0x6b, 0xcd,
        0xE8, 0x6c, 0x90, 0xe4, 0x92, 0x84, 0xeb, 0x15,
    };
    статический символ без знака B1M [] = {
        0xe4, 0x43, 0x7e, 0xd6, 0x01, 0x0E, 0x88, 0x28,
        0x6F, 0x54, 0x7F, 0xa9, 0x0a, 0xBF, 0xe4, 0xC3,
    };
    статический символ без знака а2 [] = {
        0x01, 0x14, 0xca, 0x50, 0xf7, 0xa8, 0xe2, 0xf3,
        0xf6, 0x57, 0xc1, 0x10, 0x8d, 0x9d, 0x44, 0xcf,
        0xd8,
    };
    BIGNUM * bna1b2 = BN_bin2bn (A1B2, SizeOf (A1B2), NULL);
    BIGNUM * bnb1m = BN_bin2bn (B1M, SizeOf (B1M), NULL);
    BIGNUM * bna2 = BN_bin2bn (а2, SizeOf (а2), NULL);

    BN_rshift1 (bnn2, BNN);
    BN_mul (BNC1, БНК, bna1b2, CTX);
    BN_add (BNC1, BNC1, bnn2);
    BN_div (BNC1, NULL, BNC1, BNN, CTX);
    BN_mul (BNC2, БНК, bnb1m, CTX);
    BN_add (BNC2, BNC2, bnn2);
    BN_div (BNC2, NULL, BNC2, BNN, CTX);

    BN_mul (bnt1, BNC1, bna1b2, CTX);
    BN_mul (bnt2, BNC2, bna2, CTX);
    BN_add (bnt1, bnt1, bnt2);
    BN_sub (bnk1, БНК, bnt1);
    BN_mul (bnt1, BNC1, bnb1m, CTX);
    BN_mul (bnt2, BNC2, bna1b2, CTX);
    BN_sub (bnk2, bnt1, bnt2);

    BN_free (BNC1);
    BN_free (BNC2);
    BN_free (bnt1);
    BN_free (bnt2);
    BN_free (bnn2);
    BN_free (bna1b2);
    BN_free (bnb1m);
    BN_free (bna2);
    возвращать 0;
}

статическая ИНТ
secp256k1Verify (Const символ без знака хэш [32], Const символ без знака * dersig, size_t sigsize, Const EC_KEY * PKey)
{
    INT Rslt = 0 ;;
    Const EC_GROUP * Группа = EC_KEY_get0_group (PKey);
    Const EC_POINT * Y = EC_KEY_get0_public_key (PKey);
    Const EC_POINT * G = EC_GROUP_get0_generator (группа);
    EC_POINT * Глэм = EC_POINT_new (группа);
    EC_POINT * Ylam = EC_POINT_new (группа);
    EC_POINT * R = EC_POINT_new (группа);
    Const EC_POINT * Пункты [3];
    Const BIGNUM * bnexps [3];
    BIGNUM * БНП = BN_new ();
    BIGNUM * BNN = BN_new ();
    BIGNUM * BNX = BN_new ();
    BIGNUM * BNY = BN_new ();
    BIGNUM * БНК = BN_new ();
    BIGNUM * bnk1 = BN_new ();
    BIGNUM * bnk2 = BN_new ();
    BIGNUM * bnk1a = BN_new ();
    BIGNUM * bnk2a = BN_new ();
    BIGNUM * bnsinv = BN_new ();
    BIGNUM * BNH = BN_bin2bn (хэш, 32, NULL);
    статический символ без знака беты [] = {
        0x7A, 0xe9, 0x6a, 0x2b, 0x65, 0x7c, 0x07, 0x10,
        0x6e, 0x64, 0x47, 0x9e, 0xac, 0x34, 0x34, 0xe9,
        0x9C, 0xf0, 0x49, 0x75, 0x12, 0xf5, 0x89, 0x95,
        0xc1, 0x39, 0x6c, 0x28, 0x71, 0x95, 0x01, 0xEE,
    };
    BIGNUM * bnbeta = BN_bin2bn (бета, 32, NULL);
    BN_CTX * CTX = BN_CTX_new ();
    ECDSA_SIG * сиг = d2i_ECDSA_SIG (NULL, &dersig, sigsize);

    если (Sig == NULL)
        Гото сделано;

    EC_GROUP_get_curve_GFp (группа, БНП, NULL, NULL, CTX);
    EC_GROUP_get_order (группа, BNN, CTX);

    если (BN_is_zero (SIG->г) || BN_is_negative (SIG->г) || BN_ucmp (SIG->г, BNN) >= 0
        || BN_is_zero (SIG->с) || BN_is_negative (SIG->с) || BN_ucmp (SIG->с, BNN) >= 0)
        Гото сделано;

    EC_POINT_get_affine_coordinates_GFp (группа, G BNX, BNY, CTX);
    BN_mod_mul (BNX, BNX, bnbeta, БНП, CTX);
    EC_POINT_set_affine_coordinates_GFp (группа, Глэм, BNX, BNY, CTX);
    EC_POINT_get_affine_coordinates_GFp (группа, Y, BNX, BNY, CTX);
    BN_mod_mul (BNX, BNX, bnbeta, БНП, CTX);
    EC_POINT_set_affine_coordinates_GFp (группа, Ylam, BNX, BNY, CTX);

    Очки [0] = Глая;
    Очки [1] = Y;
    Очки [2] = Ylam;

    BN_mod_inverse (bnsinv, SIG->с, BNN, CTX);
    BN_mod_mul (БНК, BNH, bnsinv, BNN, CTX);
    splitk (bnk1, bnk2, БНК, BNN, CTX);
    bnexps [0] = bnk2;
    BN_mod_mul (БНК, SIG->г, bnsinv, BNN, CTX);
    splitk (bnk1a, bnk2a, БНК, BNN, CTX);
    bnexps [1] = bnk1a;
    bnexps [2] = bnk2a;

    EC_POINTs_mul (группа, R, bnk1, 3, очки, bnexps, CTX);
    EC_POINT_get_affine_coordinates_GFp (группа, R, BNX, NULL, CTX);
    BN_mod (BNX, BNX, BNN, CTX);
    Rslt = (BN_cmp (BNX, SIG->г) == 0);

    ECDSA_SIG_free (сиг);
сделанный:
    EC_POINT_free (глэм);
    EC_POINT_free (Ylam);
    EC_POINT_free (R);
    BN_free (НПБ);
    BN_free (BNN);
    BN_free (BNX);
    BN_free (BNY);
    BN_free (БНК);
    BN_free (bnk1);
    BN_free (bnk2);
    BN_free (bnk1a);
    BN_free (bnk2a);
    BN_free (bnsinv);
    BN_free (BNH);
    BN_free (bnbeta);
    BN_CTX_free (CTX);
   
    вернуться Rslt;
}



главный()
{
    EC_KEY * PKey;
    EC_GROUP * группа;
    Const EC_POINT * ecpub;
    неподписанный символ сиг [100];
    без знака siglen = SizeOf (Sig);
    символ без знака хэш [32];
    структура формата: первый формат TV1, TV2;
    двойная time1, time2;
    Int я;
    INT Rslt;

    ENGINE_load_builtin_engines ();
    CRYPTO_malloc_init ();

    группа = EC_GROUP_new_by_curve_name (NID_secp256k1);
    PKey = EC_KEY_new ();
    EC_KEY_set_group (PKey, группа);
    EC_KEY_generate_key (PKey);
    ecpub = EC_KEY_get0_public_key (PKey);
    ECDSA_sign (0, хэш, 32, сиг, &siglen, PKey);

    Rslt = ECDSA_verify (0, хэш, 32, сиг, siglen, PKey);
    Е ("Rslt =% d \ п", Rslt);

    Rslt = secp256k1Verify (хэш, сиг, siglen, PKey);
    Е ("Rslt =% d \ п", Rslt);

    хэш [0] ++;

    Rslt = ECDSA_verify (0, хэш, 32, сиг, siglen, PKey);
    Е ("Rslt =% d \ п", Rslt);

    Rslt = secp256k1Verify (хэш, сиг, siglen, PKey);
    Е ("Rslt =% d \ п", Rslt);

    хэш [0] -;

    gettimeofday (&TV1, NULL);
    для (я = 0; я<ПРЕДСТАВИТЕЛИ; я ++) {
        Rslt = ECDSA_verify (0, хэш, 32, сиг, siglen, PKey);
    }
    gettimeofday (&TV2, NULL);
    Е ("Rslt =% d \ п", Rslt);
    time1 = (tv2.tv_sec - tv1.tv_sec + (tv2.tv_usec - tv1.tv_usec) / 1000000.) / REPS;
    Е ("Время:% г \ п", Time1);

    gettimeofday (&TV1, NULL);
    для (я = 0; я<ПРЕДСТАВИТЕЛИ; я ++) {
        Rslt = secp256k1Verify (хэш, сиг, siglen, PKey);
    }
    gettimeofday (&TV2, NULL);
    Е ("Rslt =% d \ п", Rslt);
    time2 = (tv2.tv_sec - tv1.tv_sec + (tv2.tv_usec - tv1.tv_usec) / 1000000.) / REPS;
    Е ("Время:% г \ п", Time2);
    Е ("% Е %% убыстрение \ п", (Time1-time2) / time1);

    Выход (0);
}
Hal сейчас офлайн Пожаловаться на Hal   Ответить с цитированием Мультицитирование сообщения от Hal Быстрый ответ на сообщение Hal

13 января 2013, 2:25:57 PM   # 5
 
 
Сообщений: 70
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Загрузка проверка вещь звучит интересно. Это почти идеально подходит для Bitcoin на самом деле.

Так как почти 2 года ушел, но нет активности для этого "партия проверка"-алгоритм имеет (по-видимому) сделал / опубликован, я хотел бы спросить: почему?

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

13 января 2013, 3:24:21 PM   # 6
 
 
Сообщения: 1106
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Так как почти 2 года ушел, но нет активности для этого "партия проверка"-алгоритм имеет (по-видимому) сделал / опубликован, я хотел бы спросить: почему?

SMTP

Риск против награды. Не в обиде Hal, но 25% не является очень большим шагом вперед, и проверка подписи является то, что абсолютно необходимо работать правильно. Получить это неправильно, и люди могут потерять много денег очень быстро. Почему рисковать?
Peter Todd сейчас офлайн Пожаловаться на Питер Тодд   Ответить с цитированием Мультицитирование сообщения от Peter Todd Быстрый ответ на сообщение Peter Todd

13 января 2013, 3:41:08 PM   # 7
 
 
Сообщения: 1092
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Почему привычка графических процессоров очень помогает? Конечно, проверка подписей параллельно будет улучшение?
MatthewLM сейчас офлайн Пожаловаться на MatthewLM   Ответить с цитированием Мультицитирование сообщения от MatthewLM Быстрый ответ на сообщение MatthewLM

13 января 2013, 4:02:30 PM   # 8
 
 
Сообщения: 1050
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Риск против награды. Не в обиде Hal, но 25% не является очень большим шагом вперед, и проверка подписи является то, что абсолютно необходимо работать правильно. Получить это неправильно, и люди могут потерять много денег очень быстро. Почему рисковать?

Secp256k1 конкретной оптимизация была реализована, и есть запрос тянуть интегрировать его в опорном клиенте. Это действительно добиться некоторого улучшения 20%.

Что было задано SMTP о параллельной пакетной проверке, потенциально намного более высокой speedsup (Hal упоминается x4). Проблема заключается в том, что это гораздо более агрессивны изменения, и риск получения криптографических вещи неправильно чрезвычайно высок. Это также не может определить какую степень ускорения можно, как нам нужно сделать восстановление R перед тем партия проверка возможно (и изменение этого требует жесткой вилки в основном, как и подписи являются частью правил сценариев).

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

13 января 2013, 4:09:38 PM   # 9
 
 
Сообщения: 798
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Почему привычка графических процессоров очень помогает? Конечно, проверка подписей параллельно будет улучшение?

Это не вопрос параллельно VS. не параллельно, это связано с тем, что графические процессоры страшны в точке умножения сложной части проверки подписи. Регулярное CPU намного превосходит их в этом, и гораздо меньше энергии.
Etlase2 сейчас офлайн Пожаловаться на Etlase2   Ответить с цитированием Мультицитирование сообщения от Etlase2 Быстрый ответ на сообщение Etlase2

13 января 2013, 4:15:27 PM   # 10
 
 
Сообщения: 1050
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Это не вопрос параллельно VS. не параллельно, это связано с тем, что графические процессоры страшны в точке умножения сложной части проверки подписи. Регулярное CPU намного превосходит их в этом, и гораздо меньше энергии.

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

Кто-то должен написать его ...
Pieter Wuille сейчас офлайн Пожаловаться на Pieter Wuille   Ответить с цитированием Мультицитирование сообщения от Pieter Wuille Быстрый ответ на сообщение Pieter Wuille

13 января 2013, 4:17:15 PM   # 11
 
 
Сообщений: 70
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Риск против награды. Не в обиде Hal, но 25% не является очень большим шагом вперед, и проверка подписи является то, что абсолютно необходимо работать правильно. Получить это неправильно, и люди могут потерять много денег очень быстро. Почему рисковать?
Да, я согласен inprinciple, 25% не так много (я получил только 22%). Но если secp256k1Verify код Хэла интегрирован в предварительно 0.8.0 итоге он может быть вставлен в следующем 0.8.0 релизе официально. Это значит, другие люди признают это как важное улучшение.
И в свете, что вероятная узкость является (или просто стала) это ECDSA_verify сильно (!), Я могу понять их решение.

Чтобы ответить на ваш вопрос "Почему рисковать?": Для того, чтобы не потерять все больше и больше потенциальные новые пользователей, потому что они раздражают огромное реальное время, необходимым для проверки текущего блока цепи с официальными версиями Bitcoin.
Кажется, что большинство людей не видят эту реальную опасность - это в режиме реального времени поведение может ограничить (или даже убить) Bitcoin использования / распространять серьезно. 🙁

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

13 января 2013, 4:30:17 PM   # 12
 
 
Сообщения: 1106
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Чтобы ответить на ваш вопрос "Почему рисковать?": Для того, чтобы не потерять все больше и больше потенциальные новые пользователей, потому что они раздражают огромное реальное время, необходимым для проверки текущего блока цепи с официальными версиями Bitcoin.
Кажется, что большинство людей не видят эту реальную опасность - это в режиме реального времени поведение может ограничить (или даже убить) Bitcoin использования / распространять серьезно. 🙁

Вы знаете, что превращает новые потенциальные пользователь прочь Bitcoin? Заголовки типа "Bitcoin взломан! Тысячи теряют весь свой Bitcoins!"

Если приходится ждать десять минут до часа, что делает вас не хочешь использовать Bitcoin, как о вас ждать, пока мы не придумали наложенную сеть поверх Bitcoin с моментальными сделками? Это произойдет в конце концов; Я работаю над одной такой концепцией себя.
Peter Todd сейчас офлайн Пожаловаться на Питер Тодд   Ответить с цитированием Мультицитирование сообщения от Peter Todd Быстрый ответ на сообщение Peter Todd

13 января 2013, 4:32:01 PM   # 13
 
 
Сообщений: 70
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Кто-то должен написать его ...
Особое внимание уделяется "просто" ... с февраля 2011 года: ->>

Но что мне не нравится идея ожидать в будущем не только CPU / процессор для Bitcoin-клиента, но и (высокого класса?) GPU для клиента, чтобы получить разумное поведение в реальном времени своего Bitcoin-клиента. Это я называю мисс зачатия в будущем.

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

13 января 2013, 4:37:32 PM   # 14
 
 
Сообщений: 70
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Если приходится ждать десять минут до часа, что делает вас не хочешь использовать Bitcoin, как о вас ждать, пока мы не придумали наложенную сеть поверх Bitcoin с моментальными сделками? Это произойдет в конце концов; Я работаю над одной такой концепцией себя.
Я думаю, жду > 24 ч для всей цепи блока больше истина (не 10 минут до часа) это раздражает. 🙁
По крайней мере 0.8.0 будут иметь возможность не проверять bootstrap.dat, я думаю.

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

13 января 2013, 4:50:07 PM   # 15
 
 
Сообщения: 1050
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Но что мне не нравится идея ожидать в будущем не только CPU / процессор для Bitcoin-клиента, но и (высокого класса?) GPU для клиента, чтобы получить разумное поведение в реальном времени своего Bitcoin-клиента. Это я называю мисс зачатия в будущем.

В дальнейшем - в какой-то момент (ближнее или дальнее) - это не разумно ожидать, что каждый конечный пользователь будет работать полностью подтверждающую Bitcoin узел. Если они используют настольный клиент на всех (я предполагаю, что гораздо больше будет происходить на мобильных устройствах, например), то, вероятно, будет с SPV клиентом или даже легче. На данный момент в будущем, "разумное поведение в режиме реального времени для Bitcoin-клиента" будет применяться только к тем, которые должны (шахтеры, платежные системы, продавцов) или добровольцем. Я ожидаю, что такие люди, чтобы запустить узел 24/7, и время, чтобы сделать синхронизации будет применяться только один раз.

Это вовсе не означает, что мы должны сказать всем сейчас уйти (хотя многие люди, к сожалению, но по понятным причинам) для полной проверки клиентов. В то время как экономика растет, нам нужна сеть, чтобы поддерживать его. В связи с этим, вы правы, и мы должны делать усилие, чтобы сохранить производительность как можно (и я полагаю, что я делать то, что я могу для этого). Но, как говорит Retep, корректность гораздо более высокого значения - если есть проблема с кодом, это может быть катастрофа (потерянные монеты, раздвоенная сеть, ...).

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

GPU-код, чтобы сделать проверку ECDSA бы в первую очередь будет эксперимент, на мой взгляд. Если это действительно помогает значительно ускорить процедуру, некоторые из них могут рассмотреть. Но как это происходит сейчас, я не думаю, что есть фактическая потребность.
Pieter Wuille сейчас офлайн Пожаловаться на Pieter Wuille   Ответить с цитированием Мультицитирование сообщения от Pieter Wuille Быстрый ответ на сообщение Pieter Wuille

13 января 2013, 4:57:10 PM   # 16
 
 
Сообщения: 1050
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

По крайней мере 0.8.0 будут иметь возможность не проверять bootstrap.dat, я думаю.

Вы не можете создать набор UTXO (необходимый для проверки), не делая большую часть проверки в любом случае (все, кроме проверки подписи, в основном). Если вы имеете в виду кого-то доверяя построить предварительно индексированный blockchain для вас, вы гораздо лучше работает узел SPV - это быстрее, требует меньше диск, нужно меньше пропускной способности для технического обслуживания, и не требует доверия централизованного источника ваши данные блока.

Код действующего глава мерзавца (до 0. До сих пор есть некоторые проблемы, которые вызывают начальное SyncUP быть медленным (в частности, блок выборки алгоритма дерьмовый, и становится очень легко спутать с тем моментом, когда она перестает делать что-либо в течение нескольких минут). Из отчетов, также кажется, что это значительно медленнее при проверке на системах Windows. Тем не менее, если в сочетании с параллельным + оптимизировано подписи кода проверки (которая может или не может сделать это в 0,8 выпуска), и системный блок выборка будет исправлена, я надеюсь, что мы может приблизиться к синхронизации времени 1 час на достаточно новых системах.
Pieter Wuille сейчас офлайн Пожаловаться на Pieter Wuille   Ответить с цитированием Мультицитирование сообщения от Pieter Wuille Быстрый ответ на сообщение Pieter Wuille

13 января 2013, 5:11:38 PM   # 17
 
 
Сообщения: 1106
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Если приходится ждать десять минут до часа, что делает вас не хочешь использовать Bitcoin, как о вас ждать, пока мы не придумали наложенную сеть поверх Bitcoin с моментальными сделками? Это произойдет в конце концов; Я работаю над одной такой концепцией себя.
Я думаю, жду > 24 ч для всей цепи блока больше истина (не 10 минут до часа) это раздражает. 🙁

Это заняло у меня неделю, чтобы подать заявку на мой счет PayPal обратно в тот же день.
Peter Todd сейчас офлайн Пожаловаться на Питер Тодд   Ответить с цитированием Мультицитирование сообщения от Peter Todd Быстрый ответ на сообщение Peter Todd

13 января 2013, 5:42:17 PM   # 18
 
 
Сообщений: 70
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Вы не можете создать набор UTXO (необходимый для проверки), не делая большую часть проверки в любом случае (все, кроме проверки подписи, в основном).
"большая часть проверки в любом случае" ... Я хотел бы нагрузить этот "большинство" на реальное время не по размеру коды или "логический" проверочные-классы, а затем выясняется, что проверка подписи нуждается 99% или более от него (зависит от скорости диска).

Или поставить его в реальных цифрах: Мне нужно, чтобы заблокировать высоту 216283: 112,7 сек CPU-время, чтобы поместить все данные в место для каждой возможной (в том числе проверки сценария) проверки. Ну, в режиме реального времени в 2-3 раза больше, в зависимости от того, как быстро диск (мне нужно было например 260 сек), из которого я прочитал блок цепь.
И делать полную проверку (с скрипт-поверок) нуждается в 22419827/940 сек > 6,5 часов (я этого не делал, только оценив его из образца около 890000 OP_CHECKSIG) в самых последних искупительных сценариев.

И я не считаю, что это огромный сейф в режиме реального времени, потому что я использую хэш-таблицы, а не уровень БДА структуры. 🙂 Поэтому я ожидаю при загрузке нового bootstrap.dat (говорят blockheight 216283) с диска в клиенте с предварительной 0.8.0 мне нужно всего лишь около 5 минут.

КСТАТИ: B-деревья могут теперь гораздо лучше рассуждали, потому что вам сейчас нужно гораздо больше делеции в ваших структурах данных из-за выкупленные сценариев.

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

13 января 2013, 5:52:01 PM   # 19
 
 
Сообщения: 1050
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Вы не можете создать набор UTXO (необходимый для проверки), не делая большую часть проверки в любом случае (все, кроме проверки подписи, в основном).
"большая часть проверки в любом случае" ... Я хотел бы нагрузить этот "большинство" на реальное время не по размеру коды или "логический" проверочные-классы, а затем выясняется, что проверка подписи нуждается 99% или более от него (зависит от скорости диска).

Я уверен, я полностью согласен. С точки зрения использования процессора, подписи проверки перевешивает все. Но до последней контрольной точки (= именно то, что хранится в bootstrap.dat), проверка подписи отключена в любом случае (и это не изменилось в 0 ..

Кроме того, я полагаю, что импорт bootstrap.dat на вашем оборудовании потребуется более 5 минут. Совершено полностью в оперативной памяти, вероятно, это возможно, но клиент также поддерживает базу данных на диске, и делает синхронную запись, время от времени, чтобы убедиться, что блок данных и индекс / монеты остаются в соответствии с Афоризмом.
Pieter Wuille сейчас офлайн Пожаловаться на Pieter Wuille   Ответить с цитированием Мультицитирование сообщения от Pieter Wuille Быстрый ответ на сообщение Pieter Wuille

13 января 2013, 6:22:40 PM   # 20
 
 
Сообщений: 70
Цитировать по имени
цитировать ответ
по умолчанию Re: Ускорение проверки подписи

Но до последней контрольной точки (= именно то, что хранится в bootstrap.dat), проверка подписи отключена в любом случае (и это не изменилось в 0 ..
Чувствую ли я жертвой недоразумения или вы просто сказали мне трюк?

Я просто должен сцепить мой текущий блок цепи (3 файлов) в 1 огромный файл (почти 4,9 Гб), назовите этот "bootstrap.dat" и 0,7. * загрузит это без подписи проверки в Bitcoin-клиент, если я начну его (и, конечно, построить новый blkindex.dat)?

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



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

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

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

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW