Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года | Биткоин форум

		Биткоин Форум > Разработка и Техническое Обсуждение
Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года

19 мая 2015, 3:57:52 PM	# 1
davec Сообщений: 39 Цитировать по имени цитировать ответ	Re: Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Во-первых, я хочу отметить, что я только сообщать об этом здесь, потому что она не может быть использована для вилочного mainnet или testnet. Тем не менее, это является проблемой для регрессионного тестирования сети, если какие-либо из тестов на самом деле было больше, чем в 2016 году блоков для проверки коды перенастроить. Делая некоторые тесты с использованием нашего моделирования тестовой сети в btcd, Джош Rickmar, и я заметил, что Bitcoin ядро неправильно вычисляет сложность перенастройки из-за переполнения, который происходит на regtest сети. Это другое поведение из всех версий Bitcoin Ядра до совершения https://github.com/bitcoin/bitcoin/commit/df9eb5e14fa8072bc8a82b59e712c2ba36f13f4c. Вопрос заключается в том, что ранее расчеты использовали класс CBigNum, который, в свою очередь, используется произвольное точность OpenSSL bignums, теперь ограничены 256-битовых целых числа. Для справки, вот расчеты трудности корректив в pow.cpp: Код: Const arith_uint256 bnPowLimit = UintToArith256 (params.powLimit); arith_uint256 bnNew; arith_uint256 bnOld; bnNew.SetCompact (pindexLast->Nbits); bnOld = bnNew; bnNew * = nActualTimespan; bnNew / = params.nPowTargetTimespan; если (bnNew > bnPowLimit) bnNew = bnPowLimit; Обратите внимание, что корректировка вычисляется путем умножения старого трудности (в пересчете от его компактного представления к uint256) на промежуток времени, скорректированного (которая ограничена макс целевой промежуток времени * 4 и мин целевого промежутка времени / 4). Результат затем делится на промежуток времени цели и преобразован обратно в компактную форму. К сожалению, это означает, что с помощью новых uint256s, введенных с вышеупомянутой фиксации вызывает результат `bnNew * = nActualTimespan;` линия переполнения, тогда как ранее это было с произвольной точностью и не будет. Используя реальные цифры для regtest, то разветвление состояние становится ясно. Во-первых, давайте делать математику, используя старую арифметику на основе произвольной точности. Для простоты и иллюстрирующая проблемы, мы будем считать, что первые блоки 2016 найдены достаточно быстро, так что минимальный возможный случай умножения получает удар. Код: Компактные Насадки для regtest блока генеза: 0x207fffff Конвертируется в uint256: 0x7fffff0000000000000000000000000000000000000000000000000000000000 nTargetTimespan: 14 * 24 * 60 * 60 = 1209600 = 0x127500 nActualTimespan = nTargetTimespan / 4 = 302400 = 0x49d40 (минимально возможный множитель для простоты) Код: bnNew.SetCompact (pindexLast->Nbits) -> 0x7fffff0000000000000000000000000000000000000000000000000000000000 bnNew * = nActualTimespan -> 0x7fffff0000000000000000000000000000000000000000000000000000000000 * 0x49d40 = 0x24e9ffb62c00000000000000000000000000000000000000000000000000000000000 * Обратите внимание на то, как предыдущая строка переполняет макс uint256, но это хорошо, потому что в произвольной точности арифметики OpenSSL * . BnNew / = Params () TargetTimespan () -> 0x24e9ffb62c00000000000000000000000000000000000000000000000000000000000 / 0x127500 = 0x1fffffc000000000000000000000000000000000000000000000000000000000 Старые Ожидаемые сложности бит: 0x201fffff Теперь, давайте повторим математику с помощью текущий код в Bitcoin Ядра: Код: bnNew.SetCompact (pindexLast->Nbits) -> 0x7fffff0000000000000000000000000000000000000000000000000000000000 bnNew * = nActualTimespan -> 0x7fffff0000000000000000000000000000000000000000000000000000000000 * 0x49d40 = 0xfb62c00000000000000000000000000000000000000000000000000000000000 * Обратите внимание на то, как предыдущая строка переполняет макс uint256, но теперь 2s дополнение завернуто и, таким образом, не то же самое, что и выше * . BnNew / = Params () TargetTimespan () -> 0x7fffff0000000000000000000000000000000000000000000000000000000000 / 0x127500 = 0xd9ebbc99a778556334111eefccdaab889667445223000ddebbc99a77855 Новые Ожидаемые сложности биты: 0x1e0d9ebb Обратите внимание на то, как расчетная величина значительно ниже, чем она должна быть, по сравнению с предыдущим поведением и, следовательно, приводит к требуемому доказательству работы будучи ~ 154000 раз сложнее, чем это должно быть. Чуть больше математики показывает, что, так как максимальный множитель nTargetTimespan * 4 = 4838400 = 0x49d400, это условие переполнения может произойти до тех пор, трудность >= 0x377aef2669de1558cd0447bbf336aae22599d11488c00377aef2669de15 (компактные биты: 0x1e0377ae). Простое исправление с помощью более высокой точности арифметических операций для промежуточных результатов. Джош Rickmar работает над патчем, который делает это.

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

19 мая 2015, 4:59:03 PM	# 2
Voisine Сообщения: 119 Цитировать по имени цитировать ответ	Re: Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года Получил 1806 Биткоинов Реальная история. Таким образом, переход на 256bit Интс считается безопасным, предположительно потому, что 0x1e0377ae выше MAX_PROOF_OF_WORK (0x1d00ffff), но это не безопасное предположение для regtest

19 мая 2015, 5:36:14 PM	# 3
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года Это было на самом деле указали, в то время было сделано изменение; но это, казалось, глупо менять минимум regtest просто, чтобы сделать его пригодным (или еще хуже, чтобы добавить много дополнительной сложности и другой тип номера только для обработки значений, которые происходят в _cannot_ Bitcoin). Несколько подобно тому, как testnet 20-минутное правило подвергает странное поведение, где, если предпоследний блок в окне перенацеливания является Diff-1 трудность просто от того, что обратно ~ 1: Тесты намеренно сломать систему для того, чтобы сделать его проще тест, что иногда имеет побочный ущерб; Излишне общность подвергает свой собственный risks-- например, код bignum OpenSSL был неправ в платформе зависимого пути до недавнего времени (и раздражающе, мы потратили месяцы с этим открытием, подпадающим под эмбарго) - любое использование этого несет свои собственные риски.

19 мая 2015, 8:07:55 PM	# 4
davec Сообщений: 39 Цитировать по имени цитировать ответ	Re: Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года Цитата: gmaxwell от 19 мая 2015 года, 5:36:14 PM ... но это, казалось, глупо менять минимум regtest просто, чтобы сделать его пригодным (или еще хуже, чтобы добавить много дополнительной сложности и другой тип номера только для обработки значений, которые происходят в _cannot_ Bitcoin). Спасибо за ответ. К сожалению, сеть regtest в настоящее время в основном непригодная для использования в предполагаемом пути, как только вы сгенерировали достаточно блоки, чтобы достичь первого интервала перенастроить. Я полагаю, что это большая сделка для нас в btcd, потому что у нас есть тесты, которые осуществляют эти типы вещей и сделать много испытаний моделирования с использованием СИМнет (что эффективно как regtest сети без некоторых вещей, характерных для инструмента блока тестера и некоторая дополнительная логика для предотвращения распространения адресов и обнаружения). Это большая причина, почему мы обнаружили этот вопрос, так как мы сравнивали поведение во время некоторого моделирования и заметили, что Bitcoin ядро ошибочно отвергая блоки из-за наличия слишком низкую трудность, когда на самом деле трудность была правильной. Я должен признать, что я разочарован тем, что ответ в основном, что Bitcoin ядро не чувствует, как регрессионный и моделирования тестирования является достаточно важным, чтобы гарантировать надлежащее поведение перенастроить для него, но я ценю ответ, тем не менее.

19 мая 2015, 10:45:34 PM	# 5
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года Цитата: davec от 19 мая 2015 года, 8:07:55 PM Я должен признать, что я разочарован тем, что ответ в основном, что Bitcoin ядро не чувствует, как регрессионный и моделирования тестирования является достаточно важным, чтобы гарантировать надлежащее поведение перенастроить для него, но я ценю ответ, тем не менее. Тестирование является очень важным, но добавление дополнительного кода для размещения делает моделирование даже _less_ верны, и более вероятно, чтобы пропустить реальные проблемы (или потенциально даже представить реальные проблемы). Я делаю регрессионное тестирование с ASIC шахтером и основным кодом сети (с контрольными точками = 0, конечно). Тестирование с реальным поведением производства времени является золотым стандартом и не может быть заменено shortcutted версии без компромиссов. (FWIW, testnet, который, несмотря на свои собственные глупые ярлыки, несколько ближе к Bitcoin имеет тестовые случаи в цепи для экстремальных регулировки). Единственная причина, вы были в состоянии сделать этот комментарий на все, потому что regtest существует, и единственная причина, regtest режим существует потому, что он был специально создан для жгута блока тестера, который работает на внешних сервера установки CI, например, его предполагаемое использование. Долгое время Жгут применили патч, чтобы изменить поведение, чтобы сделать его вычислительно дешевле test-- за счет делает их менее точными и faithful--, но сохраняя патч внешне взяла работу. Использование этого расширилось по сравнению с then-- я думаю, что сегодня несколько иной подход будет иметь больше смысла для regtest shortcutting и приведет к меньшему отклонению от нормального поведения сети. (Например, когда в тестовом режиме, маска из самых высоких бит блока хешей до целевой проверки). Так совсем наоборот, тестирование является достаточно важным, что нужно на самом деле испытывать фактический код Bitcoin сети и не altcoinified макета, что делает тестирование легче, или в ту меру, модифицированная версия для контролируемости используются большое внимание должно быть принято, чтобы свести к минимуму числа различий (и не добавлять риск для производства кода). Как вы могли бы извлечь "тестирование не важно" от моих комментариев по поводу целого режима альтернативной сети, созданного специально для тестирования за me-- специально, учитывая количество усилий, я помещал в ранее убедить вас, что тестирование соглашения имеет важное значение.

20 мая 2015, 7:20:53 AM	# 6
jl2012 Сообщения: 1750 Цитировать по имени цитировать ответ	Re: Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года Извините, если это глупый вопрос. Зачем вам нужно проверить с низкой сложностью, как это, в то время как вы могли бы иметь трудности с 46 теперь бесполезным 330MH / с USB Block Erupter?

20 мая 2015, 8:19:17 AM	# 7
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года Цитата: jl2012 от 20 мая 2015 года, 7:20:53 AM Извините, если это глупый вопрос. Зачем вам нужно проверить с низкой сложностью, как это, в то время как вы могли бы иметь трудности с 46 теперь бесполезным 330MH / с USB Block Erupter? Чтобы проверить на каком-то сервере «облако», которое не имеет бесполезных USB блок erupter. Кроме того, потому что вы хотите, чтобы провернуть через тысячи имитационных блоков в течение нескольких минут. Я лично думаю, что его из довольно маргинальное значение (таким образом, упоминание о тестировании с mainnet), но не стоит. Может быть, я должен начать усилие сбора для старых Основныеопераций шахтеров для Bitcoin разработчиков программного обеспечения? Есть на самом деле USB шахтеры с намного больше, чем 330MH / с, который должен быть бесполезным иш прямо сейчас.

20 мая 2015, 8:52:58 AM	# 8
jl2012 Сообщения: 1750 Цитировать по имени цитировать ответ	Re: Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года Цитата: gmaxwell от 20 мая 2015 года, 8:19:17 AM Цитата: jl2012 от 20 мая 2015 года, 7:20:53 AM Извините, если это глупый вопрос. Зачем вам нужно проверить с низкой сложностью, как это, в то время как вы могли бы иметь трудности с 46 теперь бесполезным 330MH / с USB Block Erupter? Чтобы проверить на каком-то сервере «облако», которое не имеет бесполезных USB блок erupter. Кроме того, потому что вы хотите, чтобы провернуть через тысячи имитационных блоков в течение нескольких минут. Я думаю, что это относится только если тест предполагает изменение сложности? В противном случае, используя фиксированные трудности (увеличение Retarget интервала с 2016 по астрономическому числу) должно быть в порядке.

20 мая 2015, 8:57:37 AM	# 9
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года Цитата: davec от 19 мая 2015 года, 8:07:55 PM Спасибо за ответ. К сожалению, сеть regtest в настоящее время в основном непригодная для использования в предполагаемом пути, как только вы сгенерировали достаточно блоки, чтобы достичь первого интервала перенастроить. Есть проблема, "nActualTimespan" это большой, верно? Заявление: Код: bnNew * = nActualTimespan; означает умножить старую цель по nActualTimespan и переливается. PowLimit является 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff, что означает 2 хешей на блок. Безопасное состояние является то, что nActualTimespan * powLimit < (2 ^ 256) -1. Если вы можете контролировать временные метки на блоках, то вы можете для nActualTimestamp ни к чему. Компромиссное решение было бы разрешить nPowTargetTimespan и powLimit быть модифицированы для тестирования. Это сохраняет код одинаков для обоих, не увеличивая блок трудности для всех других тестов. Метка время должна увеличиваться каждые 5 блоков из-за срединное правило. Это означает, что 2016 блоки должны принять по меньшей мере, 2016/5 = 404 секунд. Там могут быть RetargetRegtest цепи с powLimit к 0x003fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (так 4096 хэш на блок) и nPowTargetTimespan до 1024, то вы получите один блок каждые 1024 секунд. Это будет медленнее, чтобы построить цепочку, но, по крайней мере, это будет работать, если < 4096 секунд между повторным ориентируетесь. Это может быть включено с "-regtest2" флаг или может быть, 2 параметры могут быть независимо друг от друга установлены. "-regtest -powlimit = 4096 = 1024 -targettimespan", Это также означает, что для главной цепи, когда метка времени обертывания, код должен будет иметь правило макс 2 ^ 32 секунд на каждый блок. [Редактировать] котировка Я думаю, что сегодня несколько иной подход будет иметь больше смысла для regtest shortcutting и приведет к меньшему отклонению от нормального поведения сети. (Например, когда в тестовом режиме, маска из самых высоких бит блока хешей до целевой проверки). Это лучшая идея. Он эмулирует работает много хэшей запуске только один. [Править 2] Это может быть даже постоянная вещь, просто изменить CheckProofOfWork () метод и использовать маску по умолчанию всех из них.

20 мая 2015, 3:16:14 PM	# 10
davec Сообщений: 39 Цитировать по имени цитировать ответ	Re: Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года Цитата: gmaxwell 19 мая 2015, 10:45:34 PM Тестирование является очень важным, но добавление дополнительного кода для размещения делает моделирование даже _less_ верны, и более вероятно, чтобы пропустить реальные проблемы (или потенциально даже представить реальные проблемы). Я делаю регрессионное тестирование с ASIC шахтером и основным кодом сети (с контрольными точками = 0, конечно). Тестирование с реальным поведением производства времени является золотым стандартом и не может быть заменено shortcutted версии без компромиссов. (FWIW, testnet, который, несмотря на свои собственные глупые ярлыки, несколько ближе к Bitcoin имеет тестовые случаи в цепи для экстремальных регулировки). Вы делаете предположение, что здесь код содержит специальный кожух для regtest сети. Я согласен с вами, если код Retarget имел дополнительное условие ветвления, который выполняется только на regtest сети, то вы будете испытывать только ту ветвь, которая не является той же отрасли, как тот, что mainnet / testnet будет использовать. Однако, это не тот случай, так как он спараметрирован. Я лично думаю, что подход testnet о имеющих специальных обсаженных ветвях относительно сложности более опасен с точки зрения тестирования, чем спараметрированный код в вопросе. Цитата: gmaxwell 19 мая 2015, 10:45:34 PM Единственная причина, вы были в состоянии сделать этот комментарий на все, потому что regtest существует, и единственная причина, regtest режим существует потому, что он был специально создан для жгута блока тестера, который работает на внешних сервера установки CI, например, его предполагаемое использование. ... Использование этого расширилось по сравнению с then-- я думаю, что сегодня несколько иной подход будет иметь больше смысла для regtest shortcutting и приведет к меньшему отклонению от нормального поведения сети. (Например, когда в тестовом режиме, маска из самых высоких бит блока хешей до целевой проверки). Так совсем наоборот, тестирование является достаточно важным, что нужно на самом деле испытывать фактический код Bitcoin сети и не altcoinified макета, что делает тестирование легче, или в ту меру, модифицированная версия для контролируемости используются большое внимание должно быть принято, чтобы свести к минимуму числа различий (и не добавлять риск для производства кода). Я согласен, что regtest специально была создана для блока тестера, а позже расширена. Именно поэтому мы создали отдельные СИМнут в btcd для фактического тестирования моделирования, так как режим regtest имеет поведение, определенное в жгут блока тестера, и мы не хотим, чтобы приравнивать их. К сожалению, когда мы обсуждали СИМнем в # Bitcoin-разработчике, более чем один Bitcoin ядро DEV предложила использовать только regtest для этой цели. Таким образом, основываясь на ваши комментарии, я думаю, что есть какая-то путаница в сообществе BC в целом о том, как regtest предполагается использовать. Мы, конечно, можем обсудить другие подходы к будущему, но и весь текущий Жгут тест RPC основан на нем, так что лучше или хуже, это способ, которым вещи в настоящее время работают. Цитата: gmaxwell 19 мая 2015, 10:45:34 PM Как вы могли бы извлечь "тестирование не важно" от моих комментариев по поводу целого режима альтернативной сети, созданного специально для тестирования за me-- специально, учитывая количество усилий, я помещал в ранее убедить вас, что тестирование соглашения имеет важное значение. Я не уверен, как резкий парень, как ты бы ожидать какое-либо другое заключение. Вы заявили, что поведение было известно в то время патча и объединены в любом случае. Поэтому было принято сознательное решение совершить изменения, которые сознательно нарушили retargetting на regtest сети. Единственный логический вывод из этой информации является то, что собственно retargetting на regtest сети не считается достаточно важным, чтобы избежать слияния изменений. Очевидно, были причины для этого решения (некоторые из которых вы выяснены), но каковы бы ни были обстоятельства, приведшие к решению, вывод тот же.

20 мая 2015, 3:50:37 PM	# 11
davec Сообщений: 39 Цитировать по имени цитировать ответ	Re: Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года Цитата: TierNolan от 20 мая 2015 года, 8:57:37 AM Есть проблема, "nActualTimespan" это большой, верно? Это действительно результат умножения в отличие от просто "nActualTimespan" слишком большой. Существует проверка, чтобы обеспечить минимально возможное значение "nActualTimespan" это nTargetTimespan / 4 = 302400 = 0x49d40. Таким образом, когда вы берете regtest powLimit из 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff и умножить его на минимально возможное "nActualTimespan", Результат > (2 ^ 256) - 1. Цитата: TierNolan от 20 мая 2015 года, 8:57:37 AM Если вы можете контролировать временные метки на блоках, то вы можете для nActualTimestamp ни к чему. Не совсем. Он ограничивается минимальным и максимальным значением. Минимальное значение, как указано выше, 0x49d40. Максимальное значение nTargetTimespan * 4 = 4838400 = 0x49d400. Это эффективно ограничивает, сколько один шаг трудности переналадки может быть. Таким образом, в то время как у вас есть какой-то степени контроля, нет никакого способа, чтобы сделать его ниже минимально допустимого значения и regtest powLimit, умноженной на что минимальное допустимое значение перетоков. Легко исправить, как это предусмотрено в jrick PR 6162 заключается в использовании 512-битовой арифметики, поэтому он не может переполнения. Цитата: TierNolan от 20 мая 2015 года, 8:57:37 AM котировка Я думаю, что сегодня несколько иной подход будет иметь больше смысла для regtest shortcutting и приведет к меньшему отклонению от нормального поведения сети. (Например, когда в тестовом режиме, маска из самых высоких бит блока хешей до целевой проверки). Это лучшая идея. Он эмулирует работает много хэшей запуске только один. Это может быть даже постоянная вещь, просто изменить CheckProofOfWork () метод и использовать маску по умолчанию всех из них. Я согласен, это не плохая идея, однако это не означает, что все, что создает блок также должен быть изменен, так как они, скорее всего, добыча блоков с использованием либо встроенного в CPU шахтера, или на основе деталей из getblocktemplate (который включает в себя целевые биты). Они, следовательно, по умолчанию, стремиться создавать блоки с помощью более высокой сложности.

20 мая 2015, 4:28:47 PM	# 12
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года Цитата: davec от 20 мая 2015 года, 3:50:37 PM Я согласен, это не плохая идея, однако это не означает, что все, что создает блок также должен быть изменен, так как они, скорее всего, добыча блоков с использованием либо Bult в CPU шахтера, или на основе деталей из getblocktemplate (которые включают в себя целевые биты). Они, следовательно, по умолчанию, стремиться создавать блоки с помощью более высокой сложности. Шахтер CPU в основных шахтах в 2 этапа. Она сканирует до тех пор, пока не найдет блок с верхними 8 битами, равными нулю (ScanHash), а затем делает более сложную проверку. Он не использует CheckProofOfWork непосредственно, хотя. Если это так, то внутренняя шахтер может быть использована, так как маска будет приниматься во внимание. Это, вероятно, следует изменить. Если цель дает меньше 256 хэш на блок, то первый чек будет игнорировать некоторые заголовки блоков, которые соответствуют полной военнопленным. Блок хешей с менее чем 8 ведущих нулевых битов будет отклонен фильтром предварительной очистки. Я думаю, что внешние тестовые программы должны быть в состоянии обрабатывать нестандартное поведение?

20 мая 2015, 8:28:53 PM	# 13
jtimon Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Regtest Консенсус Разветвление Поведение Введенный в Bitcoin Ядра в мае 2014 года Цитата: davec от 19 мая 2015 года, 8:07:55 PM К сожалению, сеть regtest в настоящее время в основном непригодная для использования в предполагаемом пути, как только вы сгенерировали достаточно блоки, чтобы достичь первого интервала перенастроить. Если это действительно проблема, мы можем просто изменить nTargetTimespan или nTargetSpacing для regtest. Цитата: TierNolan от 20 мая 2015 года, 4:28:47 PM Шахтер CPU в основных шахтах в 2 этапа. Она сканирует до тех пор, пока не найдет блок с верхними 8 битами, равными нулю (ScanHash), а затем делает более сложную проверку. Он не использует CheckProofOfWork непосредственно, хотя. Если это так, то внутренняя шахтер может быть использована, так как маска будет приниматься во внимание. Это, вероятно, следует изменить. Видеть https://github.com/bitcoin/bitcoin/pull/4793

« Предыдущая тема | Следующая тема »

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

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

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

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW