[Новое обсуждение особенность] -fastboot

Эй, ребята,

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

Что ты об этом думаешь?

Плюсы:
+ синхронизации вам свежий клиент в течение нескольких минут

Минусы:
- сервера с файлами централизованы, поэтому в случае, если они не работают, вариант не ускорит

Благодаря!

----
EDIT: Я запустить небольшой тест.

Я использовал blockchain Мэтты (спасибо Matt для обмена этого !!) на свежем клиенте.
(http://bitcoin.bluematt.me/bitcoin-nightly/blockchain-nightly/)

время загрузки: 7 минут
bunzip2 и деготь - ~ 2 минуты
./ Bitcoin -rescan: 1 минута

Всего: 10 минут
Результат: 140600 блоков сделано
-------

Любая конструктивная критика со стороны людей, которые голосовали нет? Благодаря!

как о загрузке блоков в обратном направлении?

что вы имеете в виду? взять только последние N блоков? но тогда мы не имеем всю историю

Было бы хорошо, но я не уверен, что вы знаете, что вы говорите.
1. Вы не можете обновить код каждые несколько недель (как?)
2. Вам не нужно, поскольку blockchain является Allready "защищенный" против изменений блока.

Отличная идея! Это будет очень необходимым для Bitcoin, чтобы стать полезными для среднего человека.
При этом, я думаю, вы должны добавить -slowboot опции и иметь быструю загрузку как поведение по умолчанию.

Может быть, вы могли бы объединить идею из Rattus с загрузкой: есть один поток нагрузить блок в обратном направлении от сети p2p, в то время как другой поток загружает файлы кэша из центральных серверов. Теперь те работать, пока они не встретятся друг с другом. Это может даже решить валидацию централизованно хранящиеся зеркальные файлы, потому что, если таковые являются поддельными две цепь никогда не совпадает.

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

@ sirk390

1. вы можете - мерзавец толчок, конечно, я говорил только об обновлении md5 строки в коде. (Так, старые клиенты будут по-прежнему работать, но придется загружать несколько блоков из p2p, чем новые клиенты [равное количеству блоков между выпусками])

2. Вам не нужно, поскольку blockchain является Allready "защищенный" против изменений блока.

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

Цитата: JoelKatz от 18 августа 2011, 10:39:26 AM

Это верно и для новых блоков? Я знаю, что это довольно быстро, чтобы загрузить первый 60-70k, но позже она становится все медленнее и медленнее ....

КСТАТИ. возможно, мы можем хранить уже обработанные блоки? (Как блоб), конечно, с проверкой md5? то мы получаем все так быстро, как скачать

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

Разве это не то, что -rescan вариант для? Повторная проверка блок-цепи? Или я ошибаюсь?

@zellfaze гм ... но нам не нужно запускать -rescan? Если загрузить 140K блоков, что о моих сделках, которые были включены в этих блоках? Будут ли они показать, или мне нужно отсканировать?
Во всяком случае, я считаю, что все-таки скачать + Пересканировать быстрее, чем p2p.

ОК, я сделал домашнее задание.

Я использовал blockchain Мэтты (спасибо Matt для обмена этого !!) на свежем клиенте.
(http://bitcoin.bluematt.me/bitcoin-nightly/blockchain-nightly/)

время загрузки: 7 минут
bunzip2 и деготь - ~ 2 минуты
./ Bitcoin -rescan: 1 минута

Всего: 10 минут
Результат: 140600 блоков сделано

-повторное сканирование не перепроверить блок цепи. Это только синхронизирует блок цепь с бумажником, добавляя недостающие операции к нему.

И в самом деле, большая часть времени проводят проверки блока цепи, не скачивая. До 0.3.24, более крупные блоки часто возникают разрывы соединения при передаче из-за анти-спам меры. То есть / была также причиной задержки при запуске, но постепенно улучшается, так как большее количество узлов (и, таким образом, потенциальные партнеры скачать) перейти на 0.3.24.

Тем не менее, в -fastboot аргумент, который принимает URL или имя файла для импорта blockchain из может быть полезно в некоторых ситуациях.

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

Любой входной сигнал?

Цитата: Pieter Wuille 19 августа 2011 года, 2:21:24 PM

И в самом деле, большая часть времени проводят проверки блока цепи, не скачивая. До 0.3.24, более крупные блоки часто возникают разрывы соединения при передаче из-за анти-спам меры. То есть / была также причиной задержки при запуске, но постепенно улучшается, так как большее количество узлов (и, таким образом, потенциальные партнеры скачать) перейти на 0.3.24.

Но здесь мы не проверки blockchain блок за блоком (который занимает много CPU). Я просто проверить md5um файла, который содержит 140000 блоки. Это гораздо быстрее.

Цитата: Pieter Wuille 19 августа 2011 года, 2:21:24 PM

Тем не менее, в -fastboot аргумент, который принимает URL или имя файла для импорта blockchain из может быть полезно в некоторых ситуациях.

он может принимать аргумент, но я думаю, что он должен также иметь несколько зеркал по умолчанию жёстко прописанных (пользователь, как правило, просто скачать и запустить программу, и не заботится о чтении документации и ищет URL-адреса, и т.д. ...). У меня уже есть 3-х человек, которые добровольно предоставить зеркала, которые могут быть достаточно для бета-версии.

Цитата: ArtForz от 19 августа 2011 года, 2:39:39 PM

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

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

И последнее, но не в последнюю очередь, мы получаем другую (возможно, избыточную) защиту с этим md5sum.

Я думал об этом ... в моем идеальном мире, это то, как он будет реализован.

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

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

Когда клиент видит такую контрольную точку, то можно считать, что все, прежде чем он безопасен. С КППАМИ в блоке цепи, нет необходимости держать жесткое кодирование контрольных точек в программном обеспечении (или, по крайней мере, количество жестко закодированный пропускных пунктов может быть значительно уменьшено для того же эффект.)

Наконец .... (отдельная особенность) .... программное обеспечение должно поддерживать свой род "плоский файл импорт" который содержит последнюю копию blockchain в "капля" формат, подписанный таким же образом. Если хорошо сформированные и правомочно подпись "распределение блоб" доступен, клиент должен принять во всем, от сгустка и не попросить одного блока от партнера, пока весь блоб не было "загруженный" (Читай: копируется в предпочтительный формат по выбору клиента, и индексируются путь клиент любит его ... как "капля" не должны иметь никаких индексов). Учитывая, что блоб должен быть оптимизирован для пространства как можно больше (например, дедупликации открытых ключей, а не тратить байт, где это возможно, и т.д.)

Blobs, когда полученный от доверенной стороны, может также привести к обрезке blockchains для экономии места. При приеме отсеченной цепочки, нужно верить, что цепь не пропустить какие-либо сделок, которые могли бы привести клиент полагать, что потраченные монеты фактически неизрасходованные. Доверенная сторона (разработчик которой открытого ключ harcoded) может быть людьми, чтобы подписать доверенную отсеченную blockchain и утилита третьей стороны с открытым исходным кодом может позволить параноидальной среди нас, чтобы сравнить подписанную отсеченную версию с полной версией для подтверждения для всех остальных что она действительно не искажая неизрасходованный статуса любых монет.

Цитата: casascius от 20 августа 2011 года, 3:48:44 AM

Эй casascius, я думаю, что это отличная идея. Возможно (для первой версии), я могу только жёстко подписи некоторых людей (ответственных за GitHub / Bitcoin), а затем - в клиенте - просто проверять подписи загруженных файлов. Это позволит обновлять Файл с блоками каждый день (и из-за этой функции должна обеспечить еще более быструю загрузку), без изменения исходного кода клиента.

Что вы, ребята, думаете о подписи жестко прописывать вместо md5sum первых N блоков?

бета-версия для Linux:

https://github.com/kkurach/bitcoin/tree/fastboot

любые комментарии? (Файлов: SRC / fastboot.h SRC / fastboot.cpp)

Цитата: Regis 19 августа 2011, 11:52:51 PM

Цитата: Pieter Wuille 19 августа 2011 года, 2:21:24 PM

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

18 августа 2011, 3:54:19 AM	# 1
Regis Сообщений: 16 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Эй, ребята, Я нахожусь в середине реализации новой опции для официального клиента Bitcoin: -fastboot. Как известно, в настоящее время синхронизируется "свежий" клиент занимает очень много времени - даже несколько часов. Эта опция позволит пользователю загружать все блоки в очень короткое время, загружая почти все блоки (как сжатый файл) из одного из зеркал (зеркала будут выбраны случайным образом с помощью клиента). MDhash из загруженного файла будет зашит в клиенте, чтобы предотвратить изменение блоков. Это также означает, что этот код должен обновляться каждые несколько недель (как в настоящее время с количеством блоков), но я думаю, что это стоит. Что ты об этом думаешь? Плюсы: + синхронизации вам свежий клиент в течение нескольких минут Минусы: - сервера с файлами централизованы, поэтому в случае, если они не работают, вариант не ускорит Благодаря! ---- EDIT: Я запустить небольшой тест. Я использовал blockchain Мэтты (спасибо Matt для обмена этого !!) на свежем клиенте. (http://bitcoin.bluematt.me/bitcoin-nightly/blockchain-nightly/) время загрузки: 7 минут bunzip2 и деготь - ~ 2 минуты ./ Bitcoin -rescan: 1 минута Всего: 10 минут Результат: 140600 блоков сделано -------

18 августа 2011, 8:42:15 AM	# 2
Regis Сообщений: 16 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot Получил 1806 Биткоинов Реальная история. Любая конструктивная критика со стороны людей, которые голосовали нет? Благодаря!

18 августа 2011, 8:57:40 AM	# 3
Rattus Сообщения: 781 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot как о загрузке блоков в обратном направлении?

18 августа 2011, 9:00:25 AM	# 4
Regis Сообщений: 16 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot что вы имеете в виду? взять только последние N блоков? но тогда мы не имеем всю историю

18 августа 2011, 10:19:41 AM	# 5
sirk390 Сообщения: 153 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot Было бы хорошо, но я не уверен, что вы знаете, что вы говорите. 1. Вы не можете обновить код каждые несколько недель (как?) 2. Вам не нужно, поскольку blockchain является Allready "защищенный" против изменений блока.

18 августа 2011, 10:27:29 AM	# 6
водн Сообщения: 238 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot Отличная идея! Это будет очень необходимым для Bitcoin, чтобы стать полезными для среднего человека. При этом, я думаю, вы должны добавить -slowboot опции и иметь быструю загрузку как поведение по умолчанию. Может быть, вы могли бы объединить идею из Rattus с загрузкой: есть один поток нагрузить блок в обратном направлении от сети p2p, в то время как другой поток загружает файлы кэша из центральных серверов. Теперь те работать, пока они не встретятся друг с другом. Это может даже решить валидацию централизованно хранящиеся зеркальные файлы, потому что, если таковые являются поддельными две цепь никогда не совпадает.

18 августа 2011, 10:39:26 AM	# 7
JoelKatz Сообщения: 1582 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot Я думаю, что вы решаете неправильную проблему. Большая часть времени не проводят загрузку блока цепи, но ее обработка. Посмотрите на использование процессора.

18 августа 2011, 10:42:50 AM	# 8
Regis Сообщений: 16 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot @ sirk390 1. вы можете - мерзавец толчок, конечно, я говорил только об обновлении md5 строки в коде. (Так, старые клиенты будут по-прежнему работать, но придется загружать несколько блоков из p2p, чем новые клиенты [равное количеству блоков между выпусками]) 2. Вам не нужно, поскольку blockchain является Allready "защищенный" против изменений блока. Это просто еще одна защита. Вычисление хэша не имеет большое значение, и я не знаю, как именно blockchain защита работает, когда злоумышленник может изменить почти все блоки.

18 августа 2011, 10:46:50 AM	# 9
Regis Сообщений: 16 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot Цитата: JoelKatz от 18 августа 2011, 10:39:26 AM Я думаю, что вы решаете неправильную проблему. Большая часть времени не проводят загрузку блока цепи, но ее обработка. Посмотрите на использование процессора. Это верно и для новых блоков? Я знаю, что это довольно быстро, чтобы загрузить первый 60-70k, но позже она становится все медленнее и медленнее .... КСТАТИ. возможно, мы можем хранить уже обработанные блоки? (Как блоб), конечно, с проверкой md5? то мы получаем все так быстро, как скачать

18 августа 2011, 3:40:13 PM	# 10
zellfaze Сообщения: 142 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot Я думаю, что если вы просто загрузите блок цепь и вставить его в каталоге Bitcoin, то клиент Bitcoin не проверяет, если они действительны. Он просто предполагает, что они есть. Разве это не то, что -rescan вариант для? Повторная проверка блок-цепи? Или я ошибаюсь?

18 августа 2011, 5:49:33 PM	# 11
Regis Сообщений: 16 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot @zellfaze гм ... но нам не нужно запускать -rescan? Если загрузить 140K блоков, что о моих сделках, которые были включены в этих блоках? Будут ли они показать, или мне нужно отсканировать? Во всяком случае, я считаю, что все-таки скачать + Пересканировать быстрее, чем p2p.

18 августа 2011, 6:08:12 PM	# 12
Regis Сообщений: 16 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot ОК, я сделал домашнее задание. Я использовал blockchain Мэтты (спасибо Matt для обмена этого !!) на свежем клиенте. (http://bitcoin.bluematt.me/bitcoin-nightly/blockchain-nightly/) время загрузки: 7 минут bunzip2 и деготь - ~ 2 минуты ./ Bitcoin -rescan: 1 минута Всего: 10 минут Результат: 140600 блоков сделано

19 августа 2011, 2:21:24 PM	# 13
Pieter Wuille Сообщения: 1050 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot -повторное сканирование не перепроверить блок цепи. Это только синхронизирует блок цепь с бумажником, добавляя недостающие операции к нему. И в самом деле, большая часть времени проводят проверки блока цепи, не скачивая. До 0.3.24, более крупные блоки часто возникают разрывы соединения при передаче из-за анти-спам меры. То есть / была также причиной задержки при запуске, но постепенно улучшается, так как большее количество узлов (и, таким образом, потенциальные партнеры скачать) перейти на 0.3.24. Тем не менее, в -fastboot аргумент, который принимает URL или имя файла для импорта blockchain из может быть полезно в некоторых ситуациях.

19 августа 2011, 2:39:39 PM	# 14
ArtForz Сообщения: 406 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot Мысли вслух... У нас даже не нужно проверять подписи ECDSA в блоках старше последней контрольной точки? Предполагая, что контрольная точка Хеш хорошо, вы не можете изменить какие-либо операции в блоках перед ним без разрыва цепи. Предполагая, что контрольно-пропускной пункт хэш был заменен (накануне взломан ящик УБС или что-то) ... мы довольно много трахал в любом случае, как клиент отклонит законным цепь и остаться на цепи атакующих. Любой входной сигнал?

19 августа 2011, 11:52:51 PM	# 15
Regis Сообщений: 16 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot Цитата: Pieter Wuille 19 августа 2011 года, 2:21:24 PM И в самом деле, большая часть времени проводят проверки блока цепи, не скачивая. До 0.3.24, более крупные блоки часто возникают разрывы соединения при передаче из-за анти-спам меры. То есть / была также причиной задержки при запуске, но постепенно улучшается, так как большее количество узлов (и, таким образом, потенциальные партнеры скачать) перейти на 0.3.24. Но здесь мы не проверки blockchain блок за блоком (который занимает много CPU). Я просто проверить md5um файла, который содержит 140000 блоки. Это гораздо быстрее. Цитата: Pieter Wuille 19 августа 2011 года, 2:21:24 PM Тем не менее, в -fastboot аргумент, который принимает URL или имя файла для импорта blockchain из может быть полезно в некоторых ситуациях. он может принимать аргумент, но я думаю, что он должен также иметь несколько зеркал по умолчанию жёстко прописанных (пользователь, как правило, просто скачать и запустить программу, и не заботится о чтении документации и ищет URL-адреса, и т.д. ...). У меня уже есть 3-х человек, которые добровольно предоставить зеркала, которые могут быть достаточно для бета-версии.

20 августа 2011, 3:41:15 AM	# 16
Regis Сообщений: 16 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot Цитата: ArtForz от 19 августа 2011 года, 2:39:39 PM Мысли вслух... У нас даже не нужно проверять подписи ECDSA в блоках старше последней контрольной точки? Предполагая, что контрольная точка Хеш хорошо, вы не можете изменить какие-либо операции в блоках перед ним без разрыва цепи. Предполагая, что контрольно-пропускной пункт хэш был заменен (накануне взломан ящик УБС или что-то) ... мы довольно много трахал в любом случае, как клиент отклонит законным цепь и остаться на цепи атакующих. Любой входной сигнал? Эй ArtForz, я думаю, что ты прав. Во всяком случае, я думаю, что это безопаснее, чище и проще реализовать это с помощью закодированных контрольных сумм. Во-первых, мы открываем очень рано, что скачано блоки являются недействительными (потому что кто-то изменил их или были проблемы с загрузкой). Это позволяет повторить загрузку с другого зеркала, как только md5hash рассчитывается. Во-вторых, я не уверен, как именно работает логика внутри клиента (транспортная обработка сломанные цепи), и я бы предпочел, чтобы не прикоснуться к ней, просто чтобы быть на безопасной стороне. С контрольной подход я просто написать класс с одним методом, который загружает и проверяет файлы. Этот метод может быть запущен из любой точки клиента, а остальная часть клиента нетронутая. И последнее, но не в последнюю очередь, мы получаем другую (возможно, избыточную) защиту с этим md5sum.

20 августа 2011, 3:48:44 AM	# 17
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot Я думал об этом ... в моем идеальном мире, это то, как он будет реализован. Клиент имеет несколько открытых ключей, которые она доверяет (разработчик поддерживается), или имеет экран, где доверенные ключи можно манипулировать пользователем (разработчик поддерживает значения по умолчанию, но пользователь в конечном счете отвечает). В каком-то момент, блоки сами по себе могут содержать контрольные точки транзакций, которые поручиться за все до конца и в том числе блоков, которые их содержат. Они не должны быть чем-то особенным, они не могли быть не более, чем стандартные сделки Bitcoin с участием подписи из закодированного ключа. Когда клиент видит такую контрольную точку, то можно считать, что все, прежде чем он безопасен. С КППАМИ в блоке цепи, нет необходимости держать жесткое кодирование контрольных точек в программном обеспечении (или, по крайней мере, количество жестко закодированный пропускных пунктов может быть значительно уменьшено для того же эффект.) Наконец .... (отдельная особенность) .... программное обеспечение должно поддерживать свой род "плоский файл импорт" который содержит последнюю копию blockchain в "капля" формат, подписанный таким же образом. Если хорошо сформированные и правомочно подпись "распределение блоб" доступен, клиент должен принять во всем, от сгустка и не попросить одного блока от партнера, пока весь блоб не было "загруженный" (Читай: копируется в предпочтительный формат по выбору клиента, и индексируются путь клиент любит его ... как "капля" не должны иметь никаких индексов). Учитывая, что блоб должен быть оптимизирован для пространства как можно больше (например, дедупликации открытых ключей, а не тратить байт, где это возможно, и т.д.) Blobs, когда полученный от доверенной стороны, может также привести к обрезке blockchains для экономии места. При приеме отсеченной цепочки, нужно верить, что цепь не пропустить какие-либо сделок, которые могли бы привести клиент полагать, что потраченные монеты фактически неизрасходованные. Доверенная сторона (разработчик которой открытого ключ harcoded) может быть людьми, чтобы подписать доверенную отсеченную blockchain и утилита третьей стороны с открытым исходным кодом может позволить параноидальной среди нас, чтобы сравнить подписанную отсеченную версию с полной версией для подтверждения для всех остальных что она действительно не искажая неизрасходованный статуса любых монет.

20 августа 2011, 7:13:31 AM	# 18
Regis Сообщений: 16 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot Цитата: casascius от 20 августа 2011 года, 3:48:44 AM Я думал об этом ... в моем идеальном мире, это то, как он будет реализован. Клиент имеет несколько открытых ключей, которые она доверяет (разработчик поддерживается), или имеет экран, где доверенные ключи можно манипулировать пользователем (разработчик поддерживает значения по умолчанию, но пользователь в конечном счете отвечает). Эй casascius, я думаю, что это отличная идея. Возможно (для первой версии), я могу только жёстко подписи некоторых людей (ответственных за GitHub / Bitcoin), а затем - в клиенте - просто проверять подписи загруженных файлов. Это позволит обновлять Файл с блоками каждый день (и из-за этой функции должна обеспечить еще более быструю загрузку), без изменения исходного кода клиента. Что вы, ребята, думаете о подписи жестко прописывать вместо md5sum первых N блоков?

25 августа 2011, 9:17:55 AM	# 19
Regis Сообщений: 16 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot бета-версия для Linux: https://github.com/kkurach/bitcoin/tree/fastboot любые комментарии? (Файлов: SRC / fastboot.h SRC / fastboot.cpp)

25 августа 2011, 10:23:32 AM	# 20
Pieter Wuille Сообщения: 1050 Цитировать по имени цитировать ответ	Re: [Новая функция обсуждение] -fastboot Цитата: Regis 19 августа 2011, 11:52:51 PM Цитата: Pieter Wuille 19 августа 2011 года, 2:21:24 PM И в самом деле, большая часть времени проводят проверки блока цепи, не скачивая. До 0.3.24, более крупные блоки часто возникают разрывы соединения при передаче из-за анти-спам меры. То есть / была также причиной задержки при запуске, но постепенно улучшается, так как большее количество узлов (и, таким образом, потенциальные партнеры скачать) перейти на 0.3.24. Но здесь мы не проверки blockchain блок за блоком (который занимает много CPU). Я просто проверить md5um файла, который содержит 140000 блоки. Это гораздо быстрее. Конечно, это является. Это не то, что я имел ввиду. То, что вы делаете, это полезно, но это не имеет те же гарантии безопасности. Сейчас, через HARDCODED блок хэшей в клиенте, сопровождающий имеет возможность заставить определенную цепь на вас, но эта цепь должна еще существовать и быть действительным. Если хэш всего блок файл зашит в клиенте, сопровождающий могут эффективно сделать вас получить неверную базу данных блока.

Заголовок