Bitcoin Core : : Bitcoin Core 0.16.0 est sorti


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.

Bitcoin Core : : Bitcoin Core 0.16.0 est sorti

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é.

  • 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,
  • 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.

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)

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. 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é.

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,
  • 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,: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 `( ! = nullptr) == (pindex->nChainTx == 0)’ a échoué

Hachages pour vérification

Bitcoin-0.16.0-aarch64-linux-gnu.tar.gz Bitcoin-0.16.0-bras-linux-gnueabihf.tar.gz Bitcoin-0.16.0-i686-pc-linux-gnu.tar.gz Bitcoin-0.16.0-osx64.tar.gz Bitcoin-0.16.0-OSX.dmg Bitcoin-0.16.0.tar.gz Bitcoin-0.16.0-win32-setup.exe Bitcoin-0.16.0 -win32.zip Bitcoin-0.16.0-win64-setup.exe bitcoin-0.16.0-win64.zip 3eeb8fef65fc5f6a66477 bitcoin-0.16.tar.gz