Author

Topic: [2016-08-22] Bitcoin Core v0.13.0 (Read 2075 times)

legendary
Activity: 1512
Merit: 1011
August 24, 2016, 02:01:15 PM
#9
Comme ça pousse la nouvelle méthode de réindexation ...
(en moins de 24h, il ne me reste que 29 semaines à récupérer depuis un dossier vide).
legendary
Activity: 1512
Merit: 1011
August 23, 2016, 05:25:52 PM
#8
Ma traduction s'arrête là car les autres changements expliqués requièrent un niveau de développeur et donc ... une connaissance accrue de l'anglais associé.
legendary
Activity: 1512
Merit: 1011
August 23, 2016, 05:21:30 PM
#7
Code:

+Changement sur la réindexation
+------------------
+
+Dans les versions anciennes, la réindexation faisait la validation en lisant dans les blocks présents
+dans les fichiers sur le disque dur. Ces 2 procédures ont été séparées, comme cela, tous les blocks sont connus
+avant de démarrer la validation. Cela était nécessaire pour faire certaines optimisations qui
+étaient disponibles durant les synchronisations normales et le sont maintenant durant la réindexation.
+
+Les 2 phases sont séparées dans l'affichage du logiciel Bitcoin Core. Durant la première,
+"Réindexation des blocks sur le disque" est présenté. Durant la deuxième (plus lente) phase,
+"Préparation des blocks sur le disque" est affiché.
+
+Il est possible de, seulement, refaire la validation maintenant, sans devoir refaire l'index des blocks,
+en utilisation ligne de commande `-reindex-chainstate` (qui peut être ajouté à
+`-reindex` qui fait les 2 procédures). Cette nouvelle option est pratique quand les blocks sont déjà sur le disque
+et qu'on assume qu'ils sont valables, mais que le statut de la chaine des block est corrompue. C'est aussi intéressant
+pour faire des tests de performance.

legendary
Activity: 1512
Merit: 1011
August 23, 2016, 05:08:22 PM
#6
Code:

+Segregated Witness = Séparation et regroupement
+------------------
+
+Les préparations pour le pas de programme du procédé de séparation et de regroupement ("segwit"), comme
+il est décrit dans [BIP141], [BIP143], [BIP144], et [BIP145] sont
+finalisées et incluses dans cette version.  Cependant, le BIP 141 ne donne pas encore un critère
+d'activation dans le réseau actuel, et donc cette version ne supporte pas le segwit
+utilisé sur le réseau actuel.  L'utilisation sur le réseau de test est supporté, et après que le BIP 141 ait été mise à jour
+pour ce critère, une future version de Bitcoin Core est attendue permettant
+l'introduction de ce critère pour le réseau actuel.
+
+Plus tard, parce que le critère segwit d'activation n'est pas spécifié dans le réseau actuel,
+la version 0.13.0 se comportera comme toutes les versions précédentes prévues avant le segwit
+même après l'activation du BIP 141 sur le réseau actuel. La mise à jour vers une meilleure version sera
+requise pour utiliser les fonctions segwit disponibles sur le réseau actuel (comme le signal
+d'activation du BIP 141, le minage de blocks segwit, la validation totale des blocks segwit, le relayage
+des blocks segwit aux autres noeuds segwit, et l'utilisation de transactions segwit dans les
+porte-monnaies, etc).

legendary
Activity: 1512
Merit: 1011
August 23, 2016, 04:54:25 PM
#5
Code:

+Générateur de clé à détermination hiérarchique
+-----------------------------------------
+Les nouveaux portes-monnaies utiliseront le générateur de clé à détermination hiérarchique nommé "HD"
+d'après la méthode décrite dans le BIP32 (chemin m/0'/0'/k').
+Les portes-monnaies existants utiliseront toujours la méthode traditionnelle de génération de clé.
+
+Les sauvegardes des portes-monnaies HD, peu importe quand elles ont été créées, peuvent
+être utilisées, maintenant, pour recréer toutes les clés privées, même si
+l'une d'entre elles n'a pas été faite durant la date de la sauvegarde.
+**Attention:** Le cryptage d'un porte-monnaie créera une nouvelle graine ce qui demande
+de faire une nouvelle sauvegarde !
+
+La descente d'un porte-monnaie (en utilisant la commande RPC `dumpwallet`) contiendra la graine
+de détermination hiérarchique. Cela est prévu pour permettre, dans les futures versions, d'importer la graine et tous les fonds
+associés, mais cela n'est pas encore possible.
+
+La création de clés HD dans les nouveaux porte-monnaies peut être désactivée avec `-usehd=0`. gardez à
+l'esprit que ce paramètre affectera uniquement les nouveaux porte-monnaies créés.
+Vous ne pouvez pas désactiver le générateur de clé HD une fois le porte-monnaie HD créé.
+
+Il n'y a pas de visibilité différente entre une clé HD et une clé traditionnelle.
+
+Les porte-monnaies HD sont incompatibles avec les anciennes versions de Bitcoin Core.
+
+[Pull request], [BIP 32]
+

legendary
Activity: 1512
Merit: 1011
August 23, 2016, 04:27:22 PM
#4
Code:

+Support du "Compact Block" (BIP 152)
+-------------------------------
+
+Le support dans le relayage des blocks utilisant le protocole "Compact Block" a été intégré
+dans le PR 8068.
+
+le premier but est de réduire les pics de bande passante permettant un meilleur temps de relayage, et dans beaucoup de
+situations, cela réduit le temps de propagation. Ceci est automatiquement activé
+si les autres noeuds le supportent.
+[BIP 152]
+
+Comme effet secondaire, les noeuds ordinaires qui ne minent pas, téléchargeront et enverront ces blocks
+plus vite si ces blocks sont produits par des mineurs utilisant la même politique
+de diffusion filtrante. Cela veut dire qu'un mineur qui produit un block avec beaucoup de
+transactions produites à partir de son propre noeud sera relayé plus lentement que le block conçu
+uniquement avec des transactions de la mémoire du réseau. L'effet général voulu,
+dans cette différence de relayage sur le réseau, est de largement décourager la fabrication
+de transactions et donc en résultera une perte de block trouvé par les mineurs en question, et c'est pour cela que les mineurs sont
+invités à configurer leur noeud pour prendre en compte cette nouvelle politique de relayage.

legendary
Activity: 1512
Merit: 1011
August 23, 2016, 04:04:26 PM
#3
Code:

+Augmentation de la taille de cache de la base de donnée
+--------------------------------
+
+En conséquence de la croissance de l'UTXO, la performance avec le rêglage habituel
+de la cache de la base de donnée fixé à 100 MiB a souffert.
+Pour cette raison, le réglage a été changé pour 300 MiB dans cette version du programme.
+
+Pour les noeuds qui ont des systèmes peu puissants, le réglage de la cache de la base de donnée peut être remis à
+100 MiB (ou une autre valeur) comme suit :
+
+- ajoutez `dbcache=100` dans le fichier bitcoin.conf
+- ou changez le réglage dans le logiciel situé dans `Options → Taille de cache de la base de donnée`
+
+Notez que le réglage de la cache de la base de donnée est le plus visible en performance
+lors de la première synchro. du noeud et quand il est redémarré après un arrêt.

legendary
Activity: 1512
Merit: 1011
August 23, 2016, 03:54:12 PM
#2
Code:

+Compatibilité
+==============
+
+Microsoft a arrêté la maintenance de Windows XP le 08-04-2014,
+Un système d'exploitation créé en 2001. Cela veut dire la fin des correctifs de sécurité.
+Sans ces mises à jours de sécurité, utiliser un porte-monnaie Bitcoin
+est irresponsable au mieux.
+
+De plus, depuis la version 0.12.x il y a eux de nombreux retours comme quoi Bitcoin Core
+plantait aléatoirement sur Windows XP. Il n'a pas été possible
+de trouver la source de ces crashs, mais on peut suspecter une corrélation
+avec le fait que les bibliothèques de programmation Qt ne supportent plus non-plus WinXP.
+
+Nous n'avons pas le temps ni les ressources pour fournir un support à un système d'exploitation
+en fin de vie. Et donc, depuis la 0.13.0, Windows XP n'est plus supporté. Les utilisateurs sont
+invités à migrer vers une nouvelle version de Windows, ou à installer un autre
+système d'exploitation alternatif qui est supporté.
+
+Aucune action ne sera prise pour empêcher l'installation ou le fonctionnement du logiciel sur Windows XP,
+vous pouvez toujours le faire à vos risques et périls, mais n’espérez pas qu'il fonctionne : ne rapportez
+pas les erreurs rencontrées sur Windows XP dans le sujet de suivi des problèmes.
legendary
Activity: 1512
Merit: 1011
August 23, 2016, 12:27:41 PM
#1
https://github.com/bitcoin/bitcoin/releases/tag/v0.13.0
Téléchargements : https://bitcoin.org/bin/bitcoin-core-0.13.0/

Changelog : https://github.com/bitcoin/bitcoin/compare/v0.13.0...master

version raccourcie :

Quote
+Bitcoin Core version 0.13.0 is now available from:
+
+  
+
+This is a new major version release, including new features, various bugfixes
+and performance improvements, as well as updated translations.
+
+Please report bugs using the issue tracker at github:
+
+  
+
+To receive security and update notifications, please subscribe to:
+
+  
+
+Compatibility
+==============
+
+Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
+an OS initially released in 2001. This means that not even critical security
+updates will be released anymore. Without security updates, using a bitcoin
+wallet on a XP machine is irresponsible at least.
+
+In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
+randomly crashing on Windows XP. It is [not clear](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891)
+what the source of these crashes is, but it is likely that upstream
+libraries such as Qt are no longer being tested on XP.
+
+We do not have time nor resources to provide support for an OS that is
+end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
+suggested to upgrade to a newer verion of Windows, or install an alternative OS
+that is supported.
+
+No attempt is made to prevent installing or running the software on Windows XP,
+you can still do so at your own risk, but do not expect it to work: do not
+report issues about Windows XP to the issue tracker.
+
+Notable changes
+===============
+
+Database cache memory increased
+--------------------------------
+
+As a result of growth of the UTXO set, performance with the prior default
+database cache of 100 MiB has suffered.
+For this reason the default was changed to 300 MiB in this release.
+
+For nodes on low-memory systems, the database cache can be changed back to
+100 MiB (or to another value) by either:
+
+- Adding `dbcache=100` in bitcoin.conf
+- Changing it in the GUI under `Options → Size of database cache`
+
+Note that the database cache setting has the most performance impact
+during initial sync of a node, and when catching up after downtime.
+
+
+bitcoin-cli: arguments privacy
+------------------------------
+
+The RPC command line client gained a new argument, `-stdin`
+to read extra arguments from standard input, one per line until EOF/Ctrl-D.
+For example:
+
+    $ src/bitcoin-cli -stdin walletpassphrase
+    mysecretcode
+    120
+    ..... press Ctrl-D here to end input
+    $
+
+It is recommended to use this for sensitive information such as wallet
+passphrases, as command-line arguments can usually be read from the process
+table by any user on the system.
+
+
+C++11 and Python 3
+------------------
+
+Various code modernizations have been done. The Bitcoin Core code base has
+started using C++11. This means that a C++11-capable compiler is now needed for
+building. Effectively this means GCC 4.7 or higher, or Clang 3.3 or higher.
+
+When cross-compiling for a target that doesn't have C++11 libraries, configure with
+`./configure --enable-glibc-back-compat ... LDFLAGS=-static-libstdc++`.
+
+For running the functional tests in `qa/rpc-tests`, Python3.4 or higher is now
+required.
+
+
+Linux ARM builds
+----------------
+
+Due to popular request, Linux ARM builds have been added to the uploaded
+executables.
+
+The following extra files can be found in the download directory or torrent:
+
+- `bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz`: Linux binaries for the most
+  common 32-bit ARM architecture.
+- `bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz`: Linux binaries for the most
+  common 64-bit ARM architecture.
+
+ARM builds are still experimental. If you have problems on a certain device or
+Linux distribution combination please report them on the bug tracker, it may be
+possible to resolve them.
+
+Note that Android is not considered ARM Linux in this context. The executables
+are not expected to work out of the box on Android.
+
+
+Compact Block support (BIP 152)
+-------------------------------
+
+Support for block relay using the Compact Blocks protocol has been implemented
+in PR 8068.
+
+The primary goal is reducing the bandwidth spikes at relay time, though in many
+cases it also reduces propagation delay. It is automatically enabled between
+compatible peers.
+[BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki)
+
+As a side-effect, ordinary non-mining nodes will download and upload blocks
+faster if those blocks were produced by miners using similar transaction
+filtering policies. This means that a miner who produces a block with many
+transactions discouraged by your node will be relayed slower than one with
+only transactions already in your memory pool. The overall effect of such
+relay differences on the network may result in blocks which include widely-
+discouraged transactions losing a stale block race, and therefore miners may
+wish to configure their node to take common relay policies into consideration.
+
+
+Hierarchical Deterministic Key Generation
+-----------------------------------------
+Newly created wallets will use hierarchical deterministic key generation
+according to BIP32 (keypath m/0'/0'/k').
+Existing wallets will still use traditional key generation.
+
+Backups of HD wallets, regardless of when they have been created, can
+therefore be used to re-generate all possible private keys, even the
+ones which haven't already been generated during the time of the backup.
+**Attention:** Encrypting the wallet will create a new seed which requires
+a new backup!
+
+Wallet dumps (created using the `dumpwallet` RPC) will contain the deterministic
+seed. This is expected to allow future versions to import the seed and all
+associated funds, but this is not yet implemented.
+
+HD key generation for new wallets can be disabled by `-usehd=0`. Keep in
+mind that this flag only has affect on newly created wallets.
+You can't disable HD key generation once you have created a HD wallet.
+
+There is no distinction between internal (change) and external keys.
+
+HD wallets are incompatible with older versions of Bitcoin Core.
+
+[Pull request](https://github.com/bitcoin/bitcoin/pull/8035/files), [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)
+
+
+Segregated Witness
+------------------
+
+The code preparations for Segregated Witness ("segwit"), as described in [BIP
+141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki), [BIP
+143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki), [BIP
+144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki), and [BIP
+145](https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki) are
+finished and included in this release.  However, BIP 141 does not yet specify
+activation parameters on mainnet, and so this release does not support segwit
+use on mainnet.  Testnet use is supported, and after BIP 141 is updated with
+proposed parameters, a future release of Bitcoin Core is expected that
+implements those parameters for mainnet.
+
+Furthermore, because segwit activation is not yet specified for mainnet,
+version 0.13.0 will behave similarly as other pre-segwit releases even after a
+future activation of BIP 141 on the network.  Upgrading from 0.13.0 will be
+required in order to utilize segwit-related features on mainnet (such as signal
+BIP 141 activation, mine segwit blocks, fully validate segwit blocks, relay
+segwit blocks to other segwit nodes, and use segwit transactions in the
+wallet, etc).
+
+
+Mining transaction selection ("Child Pays For Parent")
+------------------------------------------------------
+
+The mining transaction selection algorithm has been replaced with an algorithm
+that selects transactions based on their feerate inclusive of unconfirmed
+ancestor transactions.  This means that a low-fee transaction can become more
+likely to be selected if a high-fee transaction that spends its outputs is
+relayed.
+
+With this change, the `-blockminsize` command line option has been removed.
+
+The command line option `-blockmaxsize` remains an option to specify the
+maximum number of serialized bytes in a generated block.  In addition, the new
+command line option `-blockmaxweight` has been added, which specifies the
+maximum "block weight" of a generated block, as defined by [BIP 141 (Segregated
+Witness)] (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki).
+
+In preparation for Segregated Witness, the mining algorithm has been modified
+to optimize transaction selection for a given block weight, rather than a given
+number of serialized bytes in a block.  In this release, transaction selection
+is unaffected by this distinction (as BIP 141 activation is not supported on
+mainnet in this release, see above), but in future releases and after BIP 141
+activation, these calculations would be expected to differ.
+
+For optimal runtime performance, miners using this release should specify
+`-blockmaxweight` on the command line, and not specify `-blockmaxsize`.
+Additionally (or only) specifying `-blockmaxsize`, or relying on default
+settings for both, may result in performance degradation, as the logic to
+support `-blockmaxsize` performs additional computation to ensure that
+constraint is met.  (Note that for mainnet, in this release, the equivalent
+parameter for `-blockmaxweight` would be four times the desired
+`-blockmaxsize`.  See [BIP 141]
+(https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) for additional
+details.)
+
+In the future, the `-blockmaxsize` option may be removed, as block creation is
+no longer optimized for this metric.  Feedback is requested on whether to
+deprecate or keep this command line option in future releases.
+
+
+Reindexing changes
+------------------
+
+In earlier versions, reindexing did validation while reading through the block
+files on disk. These two have now been split up, so that all blocks are known
+before validation starts. This was necessary to make certain optimizations that
+are available during normal synchronizations also available during reindexing.
+
+The two phases are distinct in the Bitcoin-Qt GUI. During the first one,
+"Reindexing blocks on disk" is shown. During the second (slower) one,
+"Processing blocks on disk" is shown.
+
+It is possible to only redo validation now, without rebuilding the block index,
+using the command line option `-reindex-chainstate` (in addition to
+`-reindex` which does both). This new option is useful when the blocks on disk
+are assumed to be fine, but the chainstate is still corrupted. It is also
+useful for benchmarks.
+
+
+Removal of internal miner
+--------------------------
+
+As CPU mining has been useless for a long time, the internal miner has been
+removed in this release, and replaced with a simpler implementation for the
+test framework.
+
+The overall result of this is that `setgenerate` RPC call has been removed, as
+well as the `-gen` and `-genproclimit` command-line options.
+
+For testing, the `generate` call can still be used to mine a block, and a new
+RPC call `generatetoaddress` has been added to mine to a specific address. This
+works with wallet disabled.
+
+
+New bytespersigop implementation
+--------------------------------
+
+The former implementation of the bytespersigop filter accidentally broke bare
+multisig (which is meant to be controlled by the `permitbaremultisig` option),
+since the consensus protocol always counts these older transaction forms as 20
+sigops for backwards compatibility. Simply fixing this bug by counting more
+accurately would have reintroduced a vulnerability. It has therefore been
+replaced with a new implementation that rather than filter such transactions,
+instead treats them (for fee purposes only) as if they were in fact the size
+of a transaction actually using all 20 sigops.
+
+
+Low-level P2P changes
+----------------------
+
+- The optional new p2p message "feefilter" is implemented and the protocol
+  version is bumped to 70013. Upon receiving a feefilter message from a peer,
+  a node will not send invs for any transactions which do not meet the filter
+  feerate. [BIP 133](https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki)
+
+- The P2P alert system has been removed in PR #7692 and the `alert` P2P message
+  is no longer supported.
+
+- The transaction relay mechanism used to relay one quarter of all transactions
+  instantly, while queueing up the rest and sending them out in batch. As
+  this resulted in chains of dependent transactions being reordered, it
+  systematically hurt transaction relay. The relay code was redesigned in PRs
+  \#7840 and #8082, and now always batches transactions announcements while also
+  sorting them according to dependency order. This significantly reduces orphan
+  transactions. To compensate for the removal of instant relay, the frequency of
+  batch sending was doubled for outgoing peers.
+
+- Since PR #7840 the BIP35 `mempool` command is also subject to batch processing.
+  Also the `mempool` message is no longer handled for non-whitelisted peers when
+  `NODE_BLOOM` is disabled through `-peerbloomfilters=0`.
+
+- The maximum size of orphan transactions that are kept in memory until their
+  ancestors arrive has been raised in PR #8179 from 5000 to 99999 bytes. They
+  are now also removed from memory when they are included in a block, conflict
+  with a block, and time out after 20 minutes.
+
+- We respond at most once to a getaddr request during the lifetime of a
+  connection since PR #7856.
+
+- Connections to peers who have recently been the first one to give us a valid
+  new block or transaction are protected from disconnections since PR #8084.
+
+
+Low-level RPC changes
+----------------------
+
+- RPC calls have been added to output detailed statistics for individual mempool
+  entries, as well as to calculate the in-mempool ancestors or descendants of a
+  transaction: see `getmempoolentry`, `getmempoolancestors`, `getmempooldescendants`.
+
+- `gettxoutsetinfo` UTXO hash (`hash_serialized`) has changed. There was a divergence between
+  32-bit and 64-bit platforms, and the txids were missing in the hashed data. This has been
+  fixed, but this means that the output will be different than from previous versions.
+
+- Full UTF-8 support in the RPC API. Non-ASCII characters in, for example,
+  wallet labels have always been malformed because they weren't taken into account
+  properly in JSON RPC processing. This is no longer the case. This also affects
+  the GUI debug console.
+
+- Asm script outputs replacements for OP_NOP2 and OP_NOP3
+
+  - OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP
+65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki)
+
+  - OP_NOP3 has been renamed to OP_CHECKSEQUENCEVERIFY by [BIP
+112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki)
+
+  - The following outputs are affected by this change:
+
+    - RPC `getrawtransaction` (in verbose mode)
+    - RPC `decoderawtransaction`
+    - RPC `decodescript`
+    - REST `/rest/tx/` (JSON format)
+    - REST `/rest/block/` (JSON format when including extended tx details)
+    - `bitcoin-tx -json`
+
+- The sorting of the output of the `getrawmempool` output has changed.
+
+- New RPC commands: `generatetoaddress`, `importprunedfunds`, `removeprunedfunds`, `signmessagewithprivkey`,
+  `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry`,
+  `createwitnessaddress`, `addwitnessaddress`.
+
+- Removed RPC commands: `setgenerate`, `getgenerate`.
+
+- New options were added to `fundrawtransaction`: `includeWatching`, `changeAddress`, `changePosition` and `feeRate`.
+
+
+Low-level ZMQ changes
+----------------------
+
+- Each ZMQ notification now contains an up-counting sequence number that allows
+  listeners to detect lost notifications.
+  The sequence number is always the last element in a multi-part ZMQ notification and
+  therefore backward compatible. Each message type has its own counter.
+  PR [#7762](https://github.com/bitcoin/bitcoin/pull/7762).
+
+

Jump to: