Btalk.org

 Забыли пароль?
 Регистрация
Поиск
Просмотры: 4084|Ответы: 0

Новый релиз Bitcoin Core 0.10.0

[Скопировать ссылку]

11

Темы

27

Сообщения

2

Блоги

Продвинутый

Rank: 3Rank: 3

Баланс
262
Опубликовано 27-2-2015 06:15:06 | Показать все сообщения |Режим чтения
bitcoincore.jpg
Недавно вышел Bitcoin Core 0.10.0 -  новый крупный релиз  официального Bitcoin клиента, добавлены новые функции и сделано исправление ошибок.

Если вы используете старую версию, выключите программу. Подождите, пока она полностью не завершится (что может занять несколько минут для более старых версий), а затем запустите установку (на Windows) или просто скопируйте /Applications/Bitcoin-Qt (на Mac) или bitcoind/bitcoin-qt (на Linux).

Потому что релиз 0.10.0 использует заголовки первыми для синхронизации и параллельную загрузку блока (см далее), файлы блока и базы данных не являются обратно совместимыми с более старыми версиями Bitcoin Core или другого программного обеспечения: * Блоки будут храниться на диске не по порядку (в порядке их получения, на самом деле), что делает его несовместимым с некоторыми инструментами или другими программами. Переиндексация с помощью более ранних версий также больше не работает в результате этого. * База данных блок-индекса сейчас содержит заголовки, для которых нет блока сохранненого на диске, что более ранние версии не поддерживают. Если вы хотите, чтобы иметь возможность провести даунгрейд гладко, сделайте резервную копию всей вашей папки Data. Без этого вашу ноду нужно будет начать синхронизировать (или импортировать из bootstrap.dat) заново после. Вполне возможно, что данные из полностью синхронизированной 0.10 ноды могут быть использованы в старых версиях как есть, но это не поддерживается и может сломаться, как только старая версия пытается проиндексировать. Это не влияет на кошелек вперед или назад совместимость.


Что нового:
Быстрая синхронизация
-----------------------------------
Bitcoin Core теперь использует "headers-first" синхронизацию. Это означает, что первыми опрашиваются пиры для заголовков блоков (всего 27 мегабайт, по состоянию на декабрь 2014 г.) и проверяют их. На втором этапе, когда заголовки были проверены, то скачиваются блоки. Однако, так как мы уже знаем заранее о всей цепочке, блоки могут быть загружены параллельно от всех доступных пиров. На практике это означает гораздо более быструю и надежную синхронизацию. На современном компьютере с приличным интернетом, это может занять всего 3 часа до полной синхронизации. Вы можете заметить замедление прогресса в первые несколько минут, когда заголовки еще проверяются, но после этого синхронизация должна набрать скорость.

Несколько RPC были добавлены/обновлены, в результате этого:
- `getblockchaininfo` теперь возвращает количество проверенных заголовков в дополнение к
числу проверенных блоков.
- `getpeerinfo` также списки количества блоков и заголовков мы знаем, что мы имеем общими с каждым пиром. При синхронизации, высота блоков, что мы запросили у пиров (но еще не получили) также входят в список "на борту".
- новый RPC `getchaintips` списки всех известных ветвей цепочки блоков, включая тех где имеются только заголовки.


Изменения комиссии за транзакцию
-----------------------------------------------------
Этот релиз автоматически оценивает, насколько высока комиссия (или метод получить высокий приоритет) за транзакцию, которая требует быстрого подтверждения. Настройки по умолчанию создают транзакции, которые подтверждаются быстро; см. новую настройку 'txconfirmtarget' для контроля компромисса между сборами и временем подтверждения. Комиссия не будет добавлена по умолчанию, если "sendfreetransactions" параметр включен.

Предыдущие релизы использовали жестко заданную комиссию (и приоритеты), и иногда могли создавать транзакции, которые имели очень долгое подтверждение.

Статистика, используемая для начисления комиссии и приоритетов сохраняется в директории Data в `fee_estimates.dat` файле перед выключением программы, а читается при запуске.

Новые параметры командной строки для изменения комиссии:
- `-txconfirmtarget=n` : Создает транзакции, которые имеют достаточную комиссию (или приоритет)
так что они, вероятно, получат подтверждения не позднее n блоков (default: 1). Этот параметр отменяется -paytxfee опцией.
- `-sendfreetransactions` : Отправить транзакцию с нулевой платой, если возможно (default: 0)

Новые RPC команды для начисления комиссии:
- `estimatefee nblocks` : Возвращает приближенно плата-за-1,000-байтов необходимых для транзакции, чтобы начать подтверждение в течение n блоков. Возвращает -1 если не хватает транзакций которые были просчитаны.
- `estimatepriority nblocks` : Возвращает приблизительный приоритет необходимый для нулевой платы за транзакцию чтобы начать подтверждение в течение n блоков. Возвращает -1 если не достаточно бесплатных транзакций которые были просчитаны.


Изменения контроля доступа RPC
-------------------------------------------------
Соответствие подсети для целей контроля доступа это делается сейчас, сопоставляя двоичный сетевой адрес, а не для работы со строками подстановочных знаков. Для пользователя это означает, что `-rpcallowip` принимает спецификацию подсети, который может быть
- a single IP address (e.g. `1.2.3.4` or `fe80::0012:3456:789a:bcde`)
- a network/CIDR (e.g. `1.2.3.0/24` or `fe80::0000/64`)
- a network/netmask (e.g. `1.2.3.4/255.255.255.0` or `fe80::0012:3456:789a:bcde/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff`)
Произвольное число `-rpcallow` аргументов может быть предоставлена. Входящее соединение будет принято, если его адрес происхождения
совпадает с одним из них.

Например:
| 0.9.x and before                     | 0.10.x                                                 |
|---------------------------------------|-----------------------------------------------    |
| `-rpcallowip=192.168.1.1`      | `-rpcallowip=192.168.1.1` (unchanged) |
| `-rpcallowip=192.168.1.*`      | `-rpcallowip=192.168.1.0/24`               |
| `-rpcallowip=192.168.*`         | `-rpcallowip=192.168.0.0/16`               |
| `-rpcallowip=*` (dangerous!)  | `-rpcallowip=::/0` (still dangerous!)       |

Использование специальных символов приведет к правилу быть отвергнутым из-за ошибки в debug.log:
Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24).


REST интерфейс
------------------------
Новый HTTP API открывает при работе с `-rest` флагом, который позволяет свободный доступ к данным публичных нод.
Он соединяется на тот же порт как RPC, но не нужен пароль и используется простой HTTP вместо JSON-RPC.

Если предположить, что локальный RPC сервер работает на порту 8332, то возможен запрос:
- Blocks: http://localhost:8332/rest/block/*HASH*.*EXT*
- Blocks without transactions: http://localhost:8332/rest/block/notxdetails/*HASH*.*EXT*
- Transactions (requires `-txindex`): http://localhost:8332/rest/tx/*HASH*.*EXT*
В любом случае, * EXT * может быть `bin` (для необработанных двоичных данных),` hex` (для hex-кодировки) или `json`.
Для более подробной информации см `doc/REST-interface.md` в репозитории.


RPC сервер "Warm-Up" режим
--------------------------------------------
Сервер RPC запускается сейчас раньше, прежде чем большинство дорогостоящих инициализаций любящих грузить блокиндекс. Он доступен в настоящее время почти сразу же после начала процесса. Тем не менее, до готовности всех инициализаций, он всегда возвращает немедленно ошибку с кодом -28 для всех вызовов. Этот новый режим может быть полезным для клиентов, чтобы знать, что сервер уже запущен и будет доступен в ближайшее время (например, так, чтобы они не должны стартовать его сами).


Улучшенная безопасность подписания
--------------------------------------------------------
Для 0.10 безопасность подписания против необычных атак была улучшена путем внесения в подпись константы времени и детерминирования. Это изменение является результатом перехода подписания использовать libsecp256k1 вместо OpenSSL. Libsecp256k1 является криптографической библиотекой оптимизированой для используемой Bitcoin curve, которая была создана Bitcoin-разработчиком Pieter Wuille.

Там существуют атаки [1] против большинства реализаций ECC где атакующий на общей виртуальной машине мог бы извлечь приватный ключ, если они могут привести к цели подписать с использованием тех же ключей сотни раз. При совместном пользовании ресурсов повторное использование ключей нецелесообразно по другим причинам, это лучшая практика, чтобы избежать незащищенности.

OpenSSL имеет код в их репозитории исходников для дерандомизации и сокращение времени утечки, которые мы с нетерпением хотели использовать надолго, но эта функциональность до сих пор не сделана в выпущенной версии OpenSSL. Libsecp256k1 достигает значительно более сильной защиты: Насколько мы знаем, это только развернутая реализация константы времени подписания для Bitcoin curve используется и у нас есть основания полагать, что libsecp256k1 лучше протестирована и более тщательно рассмотрена, чем реализация в OpenSSL.
[1] https://eprint.iacr.org/2014/161.pdf


Поддержка в бумажнике watch-only
----------------------------------------------------
Поддержка режима "только наблюдать". Теперь бумажник может отслеживать операции и из кошельков, на которые вы знаете все адреса (или скрипты) даже без приватных ключей.
Это может быть использовано для отслеживания платежей без необходимости иметь приватные ключи в режиме онлайн на возможно уязвимой системе. Кроме того, это может помочь для (ручного) составления multisig транзакций, где вы только один из подписантов.

Один новый RPC, `importaddress`, добавляет функции аналогично `importprivkey`, но вместо этого берет адрес или скрипт (в шестнадцатеричном формате)  как аргумент. После использования его, выходы зачисляются на этот адрес или скрипт, которые считается полученным, и транзакции потребившие эти выходы считаются отправленными.

Следующие RPC имеют опциональную поддержку watch-only:
`getbalance`, `listreceivedbyaddress`, `listreceivedbyaccount`,
`listtransactions`, `listaccounts`, `listsinceblock`, `gettransaction`. См. RPC документацию для получения дополнительной информации.

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


Consensus библиотека
---------------------------------
Начиная с 0.10.0, разработка Bitcoin Core  включает в себя consensus библиотеку.

Цель этой библиотеки, чтобы сделать проверки функциональных возможностей, которое критичны для Bitcoin консенсуса, доступными для других приложений, например, к языковым конструкциям, таким как
[python-bitcoinlib] (https://pypi.python.org/pypi/python-bitcoinlib)  или альтернативные реализации ноды.

Эта библиотека называется `libbitcoinconsensus.so` (или `.dll` для Windows).
Интерфейс определен в заголовке C [bitcoinconsensus.h](https://github.com/bitcoin/bitco ... /bitcoinconsensus.h).

В своей первоначальной версии API включает в себя две функции:
- `bitcoinconsensus_verify_script` проверяет скрипт. Это возвращает который указанный вход предоставленной серийную транзакцию правильно тратит пройденный scriptPubKey при дополнительных ограничениях указанными флагами.
- `bitcoinconsensus_version` возвращает версию API, в настоящее время экспериментально '0'

Функциональность планируется распространить на, например, UTXO управление в будущих релизах, но интерфейс существующих методов должен оставаться стабильным.


Правила стандартного скрипта смягчены для P2SH адресов
---------------------------------------------------------------------------------------
В правилах IsStandard() были практически полностью удалены для P2SH освобождения скриптов, что позволяет приложениям использовать любой допустимый тип скрипта, такие как "n-of-m OR y", хэш-закрытые oracle-адреса, и т.д. В то время как протокол Bitcoin всегда поддерживал эти типы скриптов, фактическое использование их в основной сети ранее было неудобно, как стандарт Bitcoin Core  ноды не ретранслируют их майнерам, и не будет больше майнеров включающих их в блоки, которые они добывают.


bitcoin-tx
--------------
Было отмечено, что многие из RPC функций, предоставляемых bitcoind являются "чистые функции", и работают независимо от bitcoind бумажника. Это включает много RPC "raw transaction" API функций, такие как createrawtransaction.

bitcoin-tx это новая, включающая командную строку, утилита предназначена для того, чтобы легко манипулировать Bitcoin транзакциями. Краткий отчет о своей работе может быть получен с помощью "bitcoin-tx --help". Транзакции могут быть созданы или подписаны аналогично RPC raw tx API. Транзакции могут быть обновлены, удалены входы и выходы, или добавлены новые входы и выходы. Пользовательские скрипты могут быть легко скомпонованы с использованием простого текстового обозначения, заимствованные из bitcoin test комплекта.

Этот инструмент может быть использован для экспериментов с новыми типами транзакций, подписания multi-party транзакций, и много других применений. В долгосрочной перспективе, целью является осуждение и удаление "чистые функции" RPC API вызовы, а те не требуют сервер в обе стороны для исполнения.

Другие утилиты "bitcoin-key" и "bitcoin-script" были предложены, что-бы делать ключ и скрипт операции легко доступными с помощью командной строки.


Улучшения майнинг и релейной политики
-------------------------------------------------------------
Шаблоны блоков Bitcoin Core в настоящее время для версии 3 блоков только, и любой майнинг софт опираясь на `getblocktemplate` должны быть обновлены параллельно использовать libblkmaker либо версии 0.4.2 или любая версия от 0.5.1 и далее. Если вы майните соло, это будет влиять на вас момент, когда вы обновите Bitcoin Core, которое должно быть сделано до BIP66 достижения своих 951/1001 статуса. Если вы майните с протоколом stratum это не повлияет на вас. Если вы майните с протоколом getblocktemplate на пулле, это повлияет, на усмотрение оператора пулла, который должен быть не позднее, чем за BIP66 достижения своих 951/1001 статуса.

`prioritisetransaction` RPC метод был добавлен, чтобы разрешить майнерам манипулировать приоритетом операций на индивидуальной основе.

Bitcoin Core теперь поддерживает BIP 22 длинный опрос, так майнинг софт может быть немедленно уведомлен о новых шаблонах вместо того, чтобы периодически опрашивать.

Поддержка BIP 23 блоков предложений теперь доступен в Bitcoin Core `getblocktemplate` метод. Это позволяет манерам проверить основную годность их следующий блок перед затраты работы на нем, уменьшая риск случайного хардфорка или майнинга недействительных блоков.

Две новых опции чтобы контролировать политику майнинга:
- `-datacarrier=0/1` : Relay and mine "data carrier" (OP_RETURN) транзакции, если это 1.
- `-datacarriersize=n` : Максимальный размер, в байтах, рассмотрим приемлемым для "data carrier" выходов.

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


BIP 66: строгая DER кодировка подписей
------------------------------------------------------------
Bitcoin Core 0.10 реализует BIP 66, который вводит версии блока 3, и новое consensus правило, которое запрещает не DER подписи. Такие сделки были нестандартными с Bitcoin v0.8.0 (выпущен в феврале 2013 года), но были технически все еще разрешаемы внутри блоков.

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

Тот же механизм майнинг-голосования, как и в БИП 34 используется: при 751 из последовательности 1001 блоков имеют номер версии 3 или выше, новый consensus правило становится активным для этих блоков. Когда 951 из последовательности 1001 блоков имеют номер версии 3 или выше, это становится обязательным для всех блоков.

Обратная совместимость с текущей версией майнинг софта НЕ предусмотрена, следовательно майнерам следует читать первый абзац "Улучшения майнинг и релейной политики" выше.


Подробнее читайте оригинал на английском, этот перевод может содержать неточности.

Итак:
Благодаря быстрой синхронизации, теперь можно забыть про скачивание bootstrap.dat через торрент (файл, содержащий данные цепочки блоков, от генезис блока до текущего чекпоинта внутри референсного клиента, версии от  0.7.1 и выше умеют импортировать оттуда данные), стороннее предварительное скачивание цепочки блоков становится бессмысленным, теперь скорость скачивания в Bitcoin Core, должна быть, по идее, никак не медленнее, чем через торрент. На данный момент папка с программой занимает 34,3 ГБ, так что ускорение скорости скачивания, весьма кстати. Немаловажны улучшения по комиссии и добавление режима "только наблюдать".

Новичкам:
Bitcoin Core - это полный клиент, он весьма тяжеловесен, для начала удобнее использовать "легкий" клиент, описание и ссылки на все клиенты доступны на официальном сайте bitcoin.org
Чтобы ответить, вам надо авторизироваться в системе Вход | Регистрация

Правила начислений

Архив|Мобильная версия|Btalk.org

GMT+3, 13-12-2017 12:06 , Processed in 0.102414 second(s), 24 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

Быстрый ответ Вернуться к началу Назад к списку