Bitcoin Core : : Bitcoin Core 0.16.0 est sorti

Nous sommes heureux d’annoncer la sortie de Bitcoin Core 0.16.0, la première version de Bitcoin Core à inclure la prise en charge du portefeuille par défaut pour les témoins séparés (segwit). La version contient également plusieurs autres améliorations et corrections de bogues, comme décrit ci-dessous.

La dernière version est disponible en téléchargement à partir de la page de téléchargement

Les sections suivantes décrivent les modifications les plus importantes de cette version. Pour plus de détails, veuillez consulter les notes de version.

Portefeuille Segwit

Bitcoin Core 0.16.0 introduit une prise en charge complète de segwit dans le portefeuille et les interfaces utilisateur. Un nouvel argument -addresstype a été ajouté, qui prend en charge les adresses héritées, p2sh-segwit (par défaut) et bech32. Il contrôle le type d’adresses produites par getnewaddress, getaccountaddress et createmultisigaddress. Un argument -changetype a également été ajouté, avec les mêmes options, et par défaut égal à -addresstype, pour contrôler le type de changement utilisé.

Un nouveau paramètre address_type a été ajouté aux RPC getnewaddress et addmultisigaddress pour spécifier le type d’adresse à générer. Un argument change_type a été ajouté au RPC fundrawtransaction pour remplacer l’argument -changetype pour des transactions spécifiques.

Toutes les adresses segwit créées via getnewaddress ou *multisig RPC obtiennent explicitement leurs scripts de rachat ajoutés au fichier de portefeuille. Cela signifie que la rétrogradation après la création d’une adresse segwit fonctionnera, tant que le fichier du portefeuille est à jour
Toutes les clés segwit du portefeuille se voient ajouter un script de rachat implicite, sans qu’il soit écrit dans le fichier. Cela signifie que la récupération d’une ancienne sauvegarde fonctionnera, tant que vous utilisez un nouveau logiciel
Toutes les clés de pool de clés utilisées dans les transactions obtiennent explicitement leurs scripts de rachat ajoutés aux fichiers du portefeuille. Cela signifie que la rétrogradation après la récupération à partir d’une sauvegarde qui inclut une adresse segwit fonctionnera

Notez que certains RPC ne prennent pas encore en charge les adresses segwit. Notamment, signmessage/verifymessage ne prend pas en charge les adresses segwit, pas plus que importmulti pour le moment. La prise en charge de segwit dans ces RPC continuera d’être ajoutée dans les futures versions.

Les sorties de modification P2WPKH sont désormais utilisées par défaut si une destination dans la transaction est une sortie P2WPKH ou P2WSH. Ceci est fait pour s’assurer que la sortie de changement est aussi impossible à distinguer des autres sorties que possible dans les deux cas.

Prise en charge des adresses BIP173 (Bech32) (adresses « bc1… »)

La prise en charge complète des adresses segwit natives (BIP173 / Bech32) a maintenant été ajoutée. Cela inclut la possibilité d’envoyer vers des adresses BIP173 (y compris celles qui ne sont pas v0) et de générer ces adresses (y compris comme nouvelles adresses par défaut, voir ci-dessus).

Une case à cocher a été ajoutée à l’interface graphique pour sélectionner si une adresse Bech32 ou une adresse enveloppée P2SH doit être générée lors de l’utilisation d’adresses segwit. Lorsqu’il est lancé avec -addresstype=bech32, il est coché par défaut. Lorsqu’il est lancé avec -addresstype=legacy, il est décoché et désactivé.

Portefeuilles HD par défaut

En raison d’un changement rétro-incompatible dans la base de données du portefeuille, les portefeuilles créés avec la version 0.16.0 seront rejetés par les versions précédentes. De plus, la version 0.16.0 ne créera que des portefeuilles déterministes hiérarchiques (HD). Notez que cela ne s’applique qu’aux nouveaux portefeuilles ; les portefeuilles créés avec les versions précédentes ne seront pas mis à niveau vers la HD.

Remplacer par frais par défaut dans l’interface graphique

L’écran d’envoi utilise désormais BIP125 RBF par défaut, indépendamment de -walletrbf. Il y a une case à cocher pour marquer la transaction comme finale.

Le RPC par défaut reste inchangé : pour utiliser RBF, lancez avec -walletrbf=1 ou utilisez l’argument remplaçable pour les transactions individuelles.

Configuration du répertoire des portefeuilles

Bitcoin Core a désormais plus de flexibilité quant à l’emplacement du répertoire des portefeuilles. Auparavant, les fichiers de base de données de portefeuille étaient stockés au niveau supérieur du répertoire de données bitcoin. Le comportement est maintenant :

Pour les nouvelles installations (où le répertoire de données n’existe pas déjà), les portefeuilles seront désormais stockés dans un nouveau sous-répertoire wallets/ à l’intérieur du répertoire de données par défaut
Pour les nœuds existants (où le répertoire de données existe déjà), les portefeuilles seront stockés à la racine du répertoire de données par défaut. Si un sous-répertoire wallets/ existe déjà à la racine du répertoire data, alors les wallets seront stockés dans le sous-répertoire wallets/ par défaut
L’emplacement du répertoire des portefeuilles peut être remplacé en spécifiant une option -walletdir= où peut être un chemin absolu vers un répertoire ou un lien symbolique vers un répertoire

Des précautions doivent être prises lors du choix de l’emplacement du répertoire des portefeuilles, car s’il devient indisponible pendant le fonctionnement, des fonds peuvent être perdus.

Prise en charge de la signalisation des nœuds élagués (BIP159)

Les nœuds élagués peuvent désormais signaler NODE_NETWORK_LIMITED de BIP159 à l’aide de bits de service, en préparation de la prise en charge complète de BIP159 dans les versions ultérieures. Cela permettrait aux nœuds élagués de desservir les blocs les plus récents. Cependant, la modification actuelle n’inclut pas encore la prise en charge de la connexion à ces pairs élagués.

Performances : assemblage SHA256 activé par défaut

Les optimisations de hachage SHA256 pour les architectures prenant en charge SSE4, qui entraînent des accélérations d’environ 50 % dans SHA256 sur le matériel pris en charge (synchronisation et validation des blocs ~ 5 % plus rapides), sont désormais activées par défaut. Dans les versions précédentes, ils étaient activés à l’aide de l’indicateur –enable-experimental-asm lors de la construction, mais sont désormais la valeur par défaut et ne sont plus considérés comme expérimentaux.

Modifications de l’interface graphique

Les utilisations de « µBTC » dans l’interface graphique affichent désormais également le terme plus familier « bits », spécifié dans BIP176
L’option de réutilisation d’une adresse précédente a maintenant été supprimée. Cela était justifié par la nécessité de « renvoyer » une facture, mais maintenant que nous avons l’historique des demandes, ce besoin devrait disparaître
La prise en charge de la recherche par TXID a été ajoutée, plutôt que simplement par adresse et étiquette
Une option « Utiliser le solde disponible » a été ajoutée à la boîte de dialogue d’envoi de pièces, pour ajouter le solde restant du portefeuille disponible à une sortie de transaction
Une bascule pour dévoiler les champs de mot de passe dans la boîte de dialogue de mot de passe a été ajoutée

Nouveau RPC rescanblockchain

Une nouvelle chaîne de blocs de rescan RPC a été ajoutée pour invoquer manuellement un rescan de blockchain. Le RPC prend en charge les arguments de hauteur de début et de fin pour la réanalyse et peut être utilisé dans un environnement multiportefeuille pour réanalyser la blockchain au moment de l’exécution.

Nouveau RPC savemempool

Un nouveau RPC savemempool a été ajouté, ce qui permet d’enregistrer le mempool actuel sur le disque à tout moment pour éviter qu’il ne soit perdu en raison de pannes ou de coupures de courant.

Mode sans échec désactivé par défaut

Le mode sans échec est maintenant désactivé par défaut et doit être activé manuellement (avec -disablesafemode=0) si vous souhaitez l’utiliser. Le mode sans échec est une fonctionnalité qui désactive automatiquement un sous-ensemble d’appels RPC – principalement liés au portefeuille et à l’envoi – en cas de détection de certaines conditions problématiques avec le réseau. Cependant, les développeurs en sont venus à considérer ces vérifications comme n’étant pas suffisamment fiables pour agir automatiquement. Même avec le mode sans échec désactivé, ils provoqueront toujours des avertissements dans le champ des avertissements du RPC getneworkinfo et lanceront la commande -alertnotify.

Script renommé pour la création d’identifiants JSON-RPC

Le script share/rpcuser/rpcuser.py a été renommé en share/rpcauth/rpcauth.py. Ce script peut être utilisé pour créer des informations d’identification rpcauth pour un utilisateur JSON-RPC.

Valider les améliorations d’adresse

La sortie RPC validateaddress a été étendue avec quelques nouveaux champs et la prise en charge des adresses segwit (à la fois P2SH et Bech32). Spécifiquement:

Un nouveau champ iswitness est True pour les adresses P2WPKH et P2WSH (adresses « bc1… »), mais pas pour les adresses segwit encapsulées dans P2SH (voir ci-dessous)
Le champ existant isscript indiquera désormais également True pour les adresses P2WSH
Un nouveau champ intégré est présent pour toutes les adresses de script où le script est connu et correspond à quelque chose qui peut être interprété comme une adresse connue. Cela est particulièrement vrai pour les adresses P2SH-P2WPKH et P2SH-P2WSH. La valeur pour Embedded comprend une grande partie des informations que validateaddress rapporterait si elle était invoquée directement sur l’adresse Embedded
Pour les scripts multisig, un nouveau champ pubkeys a été ajouté qui signale les clés publiques complètes impliquées dans le script (si elles sont connues). Il s’agit d’un remplacement du champ d’adresses existant (qui rapporte les mêmes informations mais codées comme adresses P2PKH), représenté d’une manière plus utile et moins déroutante. Le champ des adresses reste présent pour les adresses non-segwit pour une compatibilité descendante
Pour toutes les adresses à clé unique avec une clé connue (même lorsqu’elles sont enveloppées dans P2SH ou P2WSH), le champ pubkey sera présent. En particulier, cela signifie que l’appel de validateaddress sur la sortie de getnewaddress signalera toujours la clé publique, même lorsque le type d’adresse est P2SH-P2WPKH

Changements de bas niveau

Le getinfo RPC obsolète a été supprimé. Il est recommandé d’utiliser les RPC les plus spécifiques :
- obtenir des informations sur la chaîne de blocs
- obtenir des informations sur le réseau
- obtenir des informations sur le portefeuille
- obtenir des informations sur l’exploitation minière
Le portefeuille RPC getreceivedbyaddress renverra une erreur s’il est appelé avec une adresse qui n’est pas dans le portefeuille
Le portefeuille RPC addwitnessaddress est obsolète et sera supprimé dans la version 0.17, définissez l’argument address_type de getnewaddress ou l’option -addresstype=[bech32|p2sh-segwit] Au lieu
dumpwallet inclut désormais des scripts encodés en hexadécimal du portefeuille dans le fichier de vidage, et importwallet importe désormais ces scripts, mais les adresses correspondantes peuvent ne pas être ajoutées correctement ou une nouvelle analyse manuelle peut être nécessaire pour trouver les transactions pertinentes
Le RPC getblockchaininfo inclut désormais un champ d’erreurs
Un nouveau paramètre blockhash a été ajouté au RPC getrawtransaction qui permet de récupérer une transaction brute à partir d’un bloc spécifique si elle est connue, même sans -txindex activé
Les RPC decoderawtransaction et fundrawtransaction ont désormais des paramètres iswitness facultatifs pour remplacer les vérifications heuristiques des témoins si nécessaire
Le délai d’expiration de la phrase de passe du portefeuille est désormais limité à 2 ^ 30 secondes
L’utilisation d’adresses avec le RPC createmultisig est désormais obsolète et sera supprimée dans une version ultérieure. Les clés publiques doivent être utilisées à la place
Les réanalyses de la blockchain ne verrouillent plus le portefeuille pour l’ensemble du processus de réanalyse, de sorte que d’autres RPC peuvent désormais être utilisés en même temps (bien que les résultats des soldes/transactions puissent être incorrects ou incomplets jusqu’à ce que la réanalyse soit terminée)
Le RPC de journalisation est maintenant rendu public plutôt que caché
Un booléen initialblockdownload a été ajouté au RPC getblockchaininfo pour indiquer si le nœud est actuellement dans IBD ou non
minrelaytxfee est maintenant inclus dans la sortie de getmempoolinfo

Autres options de ligne de commande modifiées

-debuglogfile= peut être utilisé pour spécifier un autre fichier de journalisation de débogage
bitcoin-cli a maintenant une option -stdinrpcpass pour permettre la lecture du mot de passe RPC à partir de l’entrée standard
L’option -usehd a été supprimée
bitcoin-cli prend désormais en charge un nouvel indicateur -getinfo qui renvoie une sortie similaire à celle du RPC getinfo désormais supprimé

Tester les modifications

Le port JSON-RPC regtest par défaut a été changé en 18443 pour éviter tout conflit avec la valeur par défaut de testnet de 18332
Segwit est maintenant toujours actif en mode regtest par défaut. Ainsi, si vous mettez à niveau un nœud regtest, vous devrez soit -réindexer, soit utiliser les anciennes règles en ajoutant vbparams=segwit:0:999999999999 à votre regtest bitcoin.conf. Si vous ne le faites pas, cela entraînera un échec de l’assertion CheckBlockIndex() qui ressemblera à : L’assertion `(pindexFirstNeverProcessed ! = nullptr) == (pindex->nChainTx == 0)’ a échoué

Hachages pour vérification

f51392e0cbf7940627944602a64890ed65cf44838fc4795d493cf12aafe37012 Bitcoin-0.16.0-aarch64-linux-gnu.tar.gz 59f95da96f40b3a9acfeda9085e6389f2075ee40ef1fe7f023031f86c946c3ea Bitcoin-0.16.0-bras-linux-gnueabihf.tar.gz d7c173e2921e39df3631b7cd652ae7330c2735b0b221f9dc8f7c899887b4fb59 Bitcoin-0.16.0-i686-pc-linux-gnu.tar.gz ade85a8e39de8c36a134721c3da9853a80f29a8625048e0c2a5295ca8b23a88c Bitcoin-0.16.0-osx64.tar.gz df0036bae9f40536095908c9944ed66c0946f178ae8ef07639caf25a390b2ee7 Bitcoin-0.16.0-OSX.dmg 8cbec0397d932cab7297a8c23c918392f6eebd410646b4b954787de9f4a3ee40 Bitcoin-0.16.0.tar.gz 7558249b04527d7d0bf2663f9cfe76d6c5f83ae90e513241f94fda6151396a29 Bitcoin-0.16.0-win32-setup.exe 60d65d6e57f42164e1c04bb5bb65156d87f0433825a1c1f1f5f6aebf5c8df424 Bitcoin-0.16.0 -win32.zip 6d93ba3b9c3e34f74ccfaeacc79f968755ba0da1e2d75ce654cf276feb2aa16d Bitcoin-0.16.0-win64-setup.exe 42706da1a95b2db8c5808529f73c2063a0dd770f71e0c8506bfa86dc0f3403ef bitcoin-0.16.0-win64.zip e6322c69bcc974a29e6a715e0ecb8799d2d21691d68 3eeb8fef65fc5f6a66477 bitcoin-0.16.0-x86_64-linux-gnu.tar.gz