|
25 ноября 2010, 7:07:51 AM | # 1 |
Сообщения: 1484
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Оказывается, что blk0001.dat, где Bitcoin хранит блок информации цепи, совместимый по Windows, Linux, 32-разрядные и 64-разрядные. Поэтому, почему бы не сохранить новых пользователей некоторое время, отправляя блоки 1-74000 с каждым выпуском? Предположительно, индексация и проверки локального файла будет быстрее и использовать меньше сетевые ресурсы, чем загружать все эти блоки через P2P. |
25 ноября 2010, 1:37:13 PM | # 2 |
Сообщения: 812
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Получил 1806 Биткоинов
Реальная история. Да, не P2P должен быть быстрее, потому что вы можете скачать из многих пользователей одновременно вместо одного источника?
(Также причина, почему некоторые игровые компании используют битторрент для распространения обновлений) |
25 ноября 2010, 2:25:37 PM | # 3 |
Сообщения: 224
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
У меня смешанные чувства по этому поводу. Часть проблемы заключается в том, что воспринимается как бесплатная хорошим, сеть хостинга в виде Source Forge, что, безусловно, позволит этим исполнительским версии программного обеспечения включают значительно больше данных, чем это делается в настоящее время для Bitcoins. Если каким-то образом мы были платить за эту услугу, как сообщества с точки зрения $$$ на МиБ, я думаю, что это не было бы ежу понятно, что это должно оставаться в стороне от распределения. К сожалению, для этого рассмотрения, это бесплатно хорошо с точки зрения большинства пользователей.
Другой вопрос заключается в том, что пропускная способность сети между узлами также является свободным благо. Я предложил в эта нить что, возможно, презумпция пропускной способности сети также не может рассматриваться как свободное благом либо. На самом деле, я считаю, что это не должно быть так, но это совершенно отдельный вопрос полностью. Пропускная способность сети для загрузки блоков для меня мыть в любом случае, хотя новый клиент приходит "онлайн" пытаясь получить полный блок цепь делает сосут целую кучу блоков через сеть Bitcoin и что последствия любого, кто случается быть связан с этими узлами. Кстати, это одна из причин, почему я думаю, что это было бы невероятно полезно начать "зарядка" для полосы пропускания в качестве средства препятствовать такого поведения ... и, конечно же, чтобы заработать несколько дополнительных Bitcoins на стороне. Если вы можете получить блоки "свободно" из другого источника, некоторые люди могли бы получить более творчески о том, как получить, что решаемые включая загрузку второго пакета на каком-то свободный файл хостинга (возможно, в комплекте с основными распределениями клиента) или придумывая схемы на способ загрузки новых клиентов, что воздействие сеть в менее навязчивой манере. Я думаю, что я хочу сказать, что в то время как это простое решение сложной проблемы, она не решает все проблемы, в том числе, возможно, клиентов, которые могут хранить данные блока в другом формате. Там также не какая-либо очевидная причина обязательно поощрять другие клиент программного обеспечения дистрибутивы включить этот вид данных или по этому вопросу, чтобы положить в более, чем самый минимальном количестве блоков. Тем не менее, поднимая вопрос полезно здесь, и я надеюсь, что он поднимает обсуждение этой проблемы. Да, не P2P должен быть быстрее, потому что вы можете скачать из многих пользователей одновременно вместо одного источника? (Также причина, почему некоторые игровые компании используют битторрент для распространения обновлений) Я согласен, это кажется очень странным, что вы бы что-то, которое по своей природе распространяется через P2P-каналы и вместо того, чтобы поместить его в обычную модель распределения клиент-сервер. Часть того, почему я говорю, что, возможно, больше мыслей должна идти в это, возможно, чтобы поощрить связь распределения торрента какого-то для большой коллекции блоков, если кто-то имели свой клиент от некоторого времени, или какого-то другого вида экспериментирования о том, как чтобы решить эту же проблему. Проблема заключается в том, что новые клиенты требуют всего блок цепи и на самом деле не могут попасть в "добыча" или подтверждение новых сделок, пока они не имеют эту цепь. Давайте решать эту проблему, которая является большим вопросом. Другой вопрос заключается в том, что это кажется пустой тратой пропускной способности, чтобы включить эти блоки в клиенте, если все, что вы делаете, это обновление программного обеспечения. Я бы так же обеспокоен тем, что блок цепь может получить уничтожена программой установки с этим "старшая" версия цепи, заставляя старых клиентов для обновления до текущего блока снова и снова, хотя это, конечно, ошибка установки. Просто потому, что это бесплатно хорошо не означает, нет никаких других последствий для идти по этому пути. |
25 ноября 2010, 2:31:34 PM | # 4 |
Сообщения: 812
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Действительно, доставка данных с клиентом просто ляп.
Если основная причина, что протокол Биткойна P2P является настолько неэффективным при передаче больших объемов блоков, которые должны быть исправлены. Я думаю, что это из-за синхронизации HDD происходит. Может быть, это должно быть сдерживало для начальной загрузки, или протокол должен быть более битторрент, как для блоков [0..last-10000], так как они в основном установлены в камне. |
25 ноября 2010, 5:51:39 PM | # 5 |
Сообщения: 364
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Это не загружающий, что занимает время, это проверка и индексировать его.
Bandwidthwise, это более эффективно, чем если бы вы скачали архив. Bitcoin только загружает данные в blk0001.dat, которая в настоящее время 55MB, и строит blkindex.dat себе, что 47MB. Построение blkindex.dat является то, что вызывает все активности диска. В блоке загрузки, он очищает только базу данных на диск каждые 500 блоков. Вы можете увидеть блок подсчета паузу в ?? 499 и 999 ??. Вот когда это промывка. Делая свои проверочный и индексацию является единственным способом, чтобы быть уверенными, что ваши данные индекса надежности. При копировании blk0001.dat и blkindex.dat из ненадежного источника, нет никакого способа узнать, если вы можете доверять все содержимое в них. Может быть, Berkeley DB имеет несколько настроек, мы можем сделать, чтобы включить или увеличить кэш-память. |
25 ноября 2010, 11:19:55 PM | # 6 |
Сообщений: 25
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Моя первая реакция была "+1 для быстрой установки", Но в большинстве случаев задержки 24hr я страдал был местный диск. Отключение Fsync (?) В базе данных в режиме догоняющего помогло бы больше всего.
Да, не P2P должен быть быстрее, потому что вы можете скачать из многих пользователей одновременно вместо одного источника? (Также причина, почему некоторые игровые компании используют битторрент для распространения обновлений) Хорошая точка зрения. Но так как ша-256 блока подключается к коду, это вполне разумно, чтобы отправить данные тоже. Когда blockchain закончится 500meg, я думаю, что эффективность передачи станет важной. У нас есть варианты,
http://sourceforge.net/apps/trac/sourceforge/wiki/Developer%20web говорит котировка Примечание: Все релизы файл должен быть один файл. Файлы Множественные для одного выпуска должны быть заархивированы вместе (деготь, Деб, молния и т.д.). Мы рекомендуем использовать Rsync для всех загруженных более 20 мегабайтов, а Rsync позволяет возобновить отмененные или прерванные передачи. Хм, доставка blockchain для каждой бинарной арки будет порочным. Тогда, кто предоставляет трекер & семена для данных? Кто-то с стимулом или духом сообщества? Ну, этот форум + вики, кажется, живет на http://www.slicehost.com/ знак равно> мин $ 20 / месяц. Это, вероятно, может делиться без вреда веб-сайт, и (я думаю), семя может быть сильно душил, чтобы другие семена BT тянуть больше веса. |
26 ноября 2010, 1:47:43 AM | # 7 |
Сообщения: 1484
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Это не загружающий, что занимает время, это проверка и индексировать его. Это не относится ко многим начинающим пользователям, которые говорят такие вещи, как "также потребовалось несколько часов, чтобы охватить все 90 000 блоков, но в конце концов он прибыл" (Цитата из одного нового пользователя, на IRC, сегодня). котировка Bandwidthwise, это более эффективно, чем если бы вы скачали архив. Согласовано. Сжатый в архиве, blk0001.dat составляет около 36MB. котировка Bitcoin только загружает данные в blk0001.dat, которая в настоящее время 55MB, и строит blkindex.dat себе, что 47MB. Построение blkindex.dat является то, что вызывает все активности диска. В блоке загрузки, он очищает только базу данных на диск каждые 500 блоков. Вы можете увидеть блок подсчета паузу в ?? 499 и 999 ??. Вот когда это промывка. Осталось загрузить, а не проверка, которая имеет самый высокий Изменчивость опыта, где первое время пользователи видят задержку 30 минут до несколько часов до программного обеспечения фактически используется. Некоторые P2P узлы могут быть очень медленно (я вижу высокую вариабельность латентности и пропускной способности для старых блоков и блоков больше, чем 512 байт). Конец полосы пропускания пользователь может быть низким, пятнистый или дорого. Брандмауэры часто является проблемой. Держу пари, что вышеуказанная жалоба нового пользователя была связана с брандмауэром Microsoft; но дело стоит: большая дисперсия конфигурации сети и возможностей предполагает воздействие P2P скачать может быть гораздо, гораздо больше, чем воздействие проверки на диске 90000 блоков. котировка Делая свои проверочный и индексацию является единственным способом, чтобы быть уверенными, что ваши данные индекса надежности. При копировании blk0001.dat и blkindex.dat из ненадежного источника, нет никакого способа узнать, если вы можете доверять все содержимое в них. Кто сказал, что ненадежные? Предложение заключается в том, что вы распространяете blk0001.dat (и только blk0001.dat) в bitcoin.org официальных загрузок клиента. И, конечно, клиент будет потратить некоторое время на проверку blk0001.dat при первом использовании. Это неизбежно, и никто не предложил изменения или исключения проверки. Просто перевозка груза blk0001.dat с официальным Bitcoin исключит несколько головных болей, что новые Bitcoin пользователи продолжают испытывать. |
26 ноября 2010, 2:07:43 AM | # 8 |
Сообщения: 1484
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Может быть, Berkeley DB имеет несколько настроек, мы можем сделать, чтобы включить или увеличить кэш-память. Какой из ACID свойства вам нужно, во время загрузки? Добавление записей BDB не просто добавление в лог-файл, пока вы выдавать контрольно-пропускной пункт. Затем контрольная точка обновляет основной файл базы данных. При нормальной операции BDB, вы гарантированы, что каждая запись журнала будет синхронизирована на диск тарелочку, до завершения транзакции успешно. Это очень строгое, но требуется для полного ACID. Включение DB_TXN_NOSYNC по-прежнему дает вам много: "целостность базы данных будет сохранена, но если приложение или система выходит из строя, то можно некоторое количество самых последних совершено сделок могут быть отменены во время восстановления" Bitcoin, очевидно, может восстановить, если последние операции отменяются, так, кажется, полезно этот флаг должен быть установлен на 100% от первоначального блока загрузки. Это оставляет контрольные точки, что является балансом между количеством выполненных работ на контрольно-пропускной пункт времени - количество записей, которые должны быть скопированы из журнала в файл база данных - и время настенных часов. Просто нужно попробовать некоторые ценности и посмотреть, что "чувствует" справа - возможно контрольно-пропускной пункт каждые 10000 блоков? |
26 ноября 2010, 5:32:01 PM | # 9 |
Сообщения: 364
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Я испытал это на медленном 7-летний диск, где пропускная способность и CPU явно не была узким местом. Начальная загрузка заняла 1 час 20 минут.
Если это занимает гораздо больше времени, чем это, конечно, 24 часа, то она должна быть загрузка с очень медленным узлом, или подключение гораздо медленнее, чем около 15KB в секунду (120kbps), или что-то еще не так. Было бы хорошо знать, что, как представляется, узкое место, когда это произойдет. Каждые 10 минут или около того, когда последний блок отправляется, он должен иметь возможность изменить к более быстрому узлу. Когда последний блок вещания, он запрашивает следующие 500 блоков от других узлов, и продолжает загрузку с той, которая отправляет его быстро. По крайней мере, как она должна работать. Может быть, Berkeley DB имеет несколько настроек, мы можем сделать, чтобы включить или увеличить кэш-память. Какой из ACID свойства вам нужно, во время загрузки?Кто-то должен поэкспериментировать с различными настройками Berkeley DB и посмотреть, если есть что-то, что делает загрузку значительно быстрее. Если что-то существенное обнаруживается, то мы можем разработать подробные сведения. котировка Добавление записей BDB просто добавление в лог-файл, пока вы не выдавать контрольную точку. Затем контрольная точка обновляет основной файл базы данных. Мы контрольно-пропускной пункт каждые 500 блоков. |
26 ноября 2010, 5:42:17 PM | # 10 |
Сообщения: 224
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Кто сказал, что ненадежные? Предложение заключается в том, что вы распространяете blk0001.dat (и только blk0001.dat) в bitcoin.org официальных загрузок клиента. И, конечно, клиент будет потратить некоторое время на проверку blk0001.dat при первом использовании. Это неизбежно, и никто не предложил изменения или исключения проверки. Просто перевозка груза blk0001.dat с официальным Bitcoin исключит несколько головных болей, что новые Bitcoin пользователи продолжают испытывать. Мое личное предложение должны иметь блок данных в качестве отдельной загрузки, но настоятельно рекомендуется. Если вы хотите, чтобы упростить установку для пользователей Windows, и в противном случае невежественных пользователей компьютеров, которые не могут принимать блок файл этой природы и поставить его в правильный каталог, возможно создание формальной установка файл, чтобы поместить его там, где он должен пойти бы более "удобный", Но все это на самом деле должно содержать только данные блока. Целью этого является, главным образом, так что те, кто обновление до новой версии может сделать это без того, чтобы также поддерживать загрузку и те же данные блока, которые, по определению, будет расти с течением времени. |
26 ноября 2010, 6:08:40 PM | # 11 |
Сообщений: 43
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Целью этого является, главным образом, так что те, кто обновление до новой версии может сделать это без того, чтобы также поддерживать загрузку и те же данные блока, которые, по определению, будет расти с течением времени. Я не знаю, как это для вас, но когда я обновляю Bitcoin не придется повторно загружать любые блоки. Он просто берет там, где она была прервана перед обновлением. |
26 ноября 2010, 7:17:25 PM | # 12 |
Сообщения: 224
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Целью этого является, главным образом, так что те, кто обновление до новой версии может сделать это без того, чтобы также поддерживать загрузку и те же данные блока, которые, по определению, будет расти с течением времени. Я не знаю, как это для вас, но когда я обновляю Bitcoin не придется повторно загружать любые блоки. Он просто берет там, где она была прервана перед обновлением. То есть точка. Если блоки включены в обновлении было бы также по определению включает в себя блоки, которые уже получены через сеть. Вот почему я предлагаю, что он должен быть отдельным, но настоятельно рекомендуется загрузить для новых пользователей, а не что-то объединены в нормальных дистрибутивах. |
28 ноября 2010, 2:33:29 AM | # 13 |
Сообщения: 1484
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Еще один новый пользователь на IRC, Linux на этот раз загружал в размере 1 блок каждые 4 секунд - по оценкам общего времени загрузки около 4 дней.
Другие комментаторы в этой теме правильны, что модернизация пользователям не нужна база данных, блок ... но что нибудь необходимо сделать, чтобы улучшить начальный блок загрузки опыт для новых пользователей. Улучшение базы данных все, что вы хотите .. вы все еще будете иметь коллег, давая вам блоки медленно по целому ряду причин. У нас есть хэш генеза блока через блок 74000 жёстко прописанные (составитель) в Bitcoin, так что нет никаких причин, почему мы не должны быть в состоянии автоматически загружать сжатую ZipFile базы данных блока из в любом месте, распаковать его, проверить его и начать работать. |
28 ноября 2010, 7:23:04 AM | # 14 |
Сообщений: 56
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Другие комментаторы в этой теме правильны, что модернизация пользователям не нужна база данных, блок ... но что нибудь необходимо сделать, чтобы улучшить начальный блок загрузки опыт для новых пользователей. Улучшение базы данных все, что вы хотите .. вы все еще будете иметь коллег, давая вам блоки медленно по целому ряду причин. * Что-то * должно быть сделано, блок цепь будет * огромной * в следующем году или так, правильно? |
28 ноября 2010, 7:33:55 AM | # 15 |
Сообщения: 1484
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Другие комментаторы в этой теме правильны, что модернизация пользователям не нужна база данных, блок ... но что нибудь необходимо сделать, чтобы улучшить начальный блок загрузки опыт для новых пользователей. Улучшение базы данных все, что вы хотите .. вы все еще будете иметь коллег, давая вам блоки медленно по целому ряду причин. * Что-то * должно быть сделано, блок цепь будет * огромной * в следующем году или так, правильно? Да исправить. Предположительно в какой-то момент будет легкий клиент, который только загрузки заголовков блоков, но все еще будет сотни тысяч тех, кто ... |
28 ноября 2010, 8:53:00 AM | # 16 |
Сообщений: 43
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Вот почему я предлагаю, что он должен быть отдельным, но настоятельно рекомендуется загрузить для новых пользователей, а не что-то объединены в нормальных дистрибутивах. К сожалению, я не понял вас. У нас есть хэш генеза блока через блок 74000 жёстко прописанные (составитель) в Bitcoin, так что нет никаких причин, почему мы не должны быть в состоянии автоматически загружать сжатую ZipFile базы данных блока из в любом месте, распаковать его, проверить его и начать работать. Я полагаю, вы имеете в виду контрольно-пропускные пункты? Если это так, как я понимаю, они применяются только при проверке блока, который был загружен. Содержание blk0001.dat и blkindex.dat являются никогда проверяются клиентом, так как клиент предназначен для проверки, что данные до это будет записано в этих файлах. Как Satoshi указано в этой теме, Делая свои проверочный и индексацию является единственным способом, чтобы быть уверенными, что ваши данные индекса надежности. При копировании blk0001.dat и blkindex.dat из ненадежного источника, нет никакого способа узнать, если вы можете доверять все содержимое в них. |
28 ноября 2010, 10:02:22 AM | # 17 |
Сообщения: 1484
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Я полагаю, вы имеете в виду контрольно-пропускные пункты? Если это так, как я понимаю, они применяются только при проверке блока, который был загружен. Содержание blk0001.dat и blkindex.dat являются никогда проверяются клиентом, так как клиент предназначен для проверки, что данные до это будет записано в этих файлах. Не совсем верно. "-checkblocks" (CheckBlock ()) выполняет довольно много проверок на содержание blk0001.dat / blkindex.dat. AcceptBlock () делает немного больше, добавляя контекст, но не намного больше. Но давайте игнорировать, что на данный момент. Я думаю, что более важный момент вам не хватает в том, что никто не предлагает, что проверка будет пропущена. Код Bitcoin вполне способен проверки индексации и ненадежных данных blk0001.dat. Это просто нужно было несколько модификаций вести себя благоразумно, если blkindex.dat отсутствует. Предложение просто: не загружать огромное количество несжатых данных с использованием протокола (Bitcoin P2P), который не был разработан для передачи больших объемов данных. котировка Как Satoshi указано в этой теме, Делая свои проверочный и индексацию является единственным способом, чтобы быть уверенными, что ваши данные индекса надежности. При копировании blk0001.dat и blkindex.dat из ненадежного источника, нет никакого способа узнать, если вы можете доверять все содержимое в них. Клиент явно способен проверка криптографической целостности blk0001.dat из ненадежного источника, так как он делает это для блоков поступают по сети, и blk0001.dat содержит ... сериализованные блоки первоначально получили из ненадежных источников по сети. Это, кажется, не слишком трудно передать в blk0001.dat данных о местоположении файла ProcessBlock (), а просто пропустить WriteToDisk () вызов хранения в вниз по течению вызываемого абонента AcceptBlock (). |
28 ноября 2010, 4:09:46 PM | # 18 |
Сообщения: 224
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Клиент явно способен проверка криптографической целостности blk0001.dat из ненадежного источника, так как он делает это для блоков поступают по сети, и blk0001.dat содержит ... сериализованные блоки первоначально получили из ненадежных источников по сети. Это, кажется, не слишком трудно передать в blk0001.dat данных о местоположении файла в ProcessBlock (), а просто пропустить WriteToDisk () вызов хранения в вниз по течению вызываемого абонента AcceptBlock () Если я не ошибаюсь здесь, что это означает, что в данный момент "официальный" Клиент предполагает, что blk0001.dat содержит проверенные данные, так что если вы загружаете, что данные из другого источника, которые могут быть скомпрометированы, на данный момент нет никакой возможности проверить эту информацию. Это лишь временная опасность быть в курсе, когда программа пытается справиться с этой конкретной проблемой. С другой стороны, кто-то мог бы также поместить в интерфейс или в качестве параметра командной строки на bitcoind какой-то "reverifications" из данных блока, который будет выполняться локально. Я думаю, что есть и другие приложения для этого в том числе, возможно, в качестве меры предосторожности против некоторых вирусов на вашем компьютере манипулирует данные в блок цепи, где это было бы полезно в любом случае, но это, кажется, как вариант, который должен быть добавлен к программному обеспечению. Так как код проверки уже в программном обеспечении, это просто создание алгоритма и спусковой механизм для выполнения этой проверки. Действительно, если есть конкретный блок, который представляет интерес в процессе проверки, попытка "излечивать" цепь на основании блока-запросы одноранговых узлов может быть использована, чтобы исправить возможные ошибки или даже выбросить всю цепь. Я надеюсь, что такая возможность в конце концов добавляется. |
28 ноября 2010, 4:25:15 PM | # 19 |
Сообщения: 1708
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Насколько я понимаю, что клиент уже сделал blockchain перепроверить при запуске, если индекс отсутствует. Я сделал это, когда я первый начал, и он уверен, казалось, что он шел по цепочке. Разве это не требуется индекс функционировать в любом случае? Почему бы это предположить, что blockchain был действительным при запуске? Любой мог редактировать его. Блок генезис кодируется в клиенте, не так ли? Это и blockchain контрольно-пропускные пункты являются единственными частями, которые считаются правильными, или я ошибаюсь? Там нет никаких оснований, чтобы предотвратить blockchain загрузки через другие методы. В будущем с Bitcoin сети работает близко к, это емкость, загрузив весь blockchain по сети P2P будет вредна.
Даже цепь, которая уже подрезала из его Меркла дерева должны быть в состоянии проверить с самого начала, в противном случае, что хорошо использует Merkle дерево на всех? |
28 ноября 2010, 5:13:01 PM | # 20 |
Сообщения: 364
цитировать ответ |
Re: RFC: корабль блок цепь 1-74000 с тарболлами выпуска?
Несмотря на все остальное говорит, текущий следующий шаг:
котировка Кто-то должен поэкспериментировать с различными настройками Berkeley DB и посмотреть, если есть что-то, что делает загрузку значительно быстрее. Если что-то существенное обнаруживается, то мы можем разработать подробные сведения. В частности, я подозреваю, что более кэширование чтения может помочь.Еще один новый пользователь на IRC, Linux на этот раз загружал в размере 1 блок каждые 4 секунд - по оценкам общего времени загрузки около 4 дней. Потом что-то более конкретно было неправильно. Это не из-за нормальное начальное время загрузки. Без получения более подробной информации, она не может быть поставлен диагноз. Если бы это было из-за медленной загрузки, так это ускорить через 10-20 минут, когда следующий блок вещания должен был бы сделать это перейти на более быстрый источник? debug.log может иметь ключи. Как быстро их подключение к Интернету? Это было стабильно медленно, или просто замедлиться в одной точке?котировка У нас есть хэш генеза блока через блок 74000 жёстко прописанные (составитель) в Bitcoin, так что нет никаких причин, почему мы не должны быть в состоянии автоматически загружать сжатую ZipFile базы данных блока из в любом месте, распаковать его, проверить его и начать работать. 74000 контрольно-пропускной пункт не достаточно, чтобы защитить вас, и ничего не делает, если загрузка уже за 74000. -checkblocks делает больше, но по-прежнему легко победил. Вы все еще должны доверять поставщику ZipFile.Если бы не было "проверить его" шаг, который будет принимать до тех пор, как текущую нормальную начальную загрузку, в которой он является индексацией, а не загрузки данных, что является узким местом. Предположительно в какой-то момент будет легкий клиент, который только загрузки заголовков блоков, но все еще будет сотни тысяч тех, кто ... 80 байт в заголовке и не индексирования работы. Может занять 1 минуту.котировка несжатых данных с использованием протокола (Bitcoin P2P), который не был предназначен для передачи больших объемов данных. Данные в основном хэш и ключи и подписи, которые сжаты,.Скорость начальной загрузки не является отражением скорости передачи больших объемов данных протокола. Сдерживающий фактор является индексирование в то время как он загружает. |