Le bulletin de cette semaine comprend le tableau de bord habituel et les actions à entreprendre, un article de fond du développeur Anthony Towns sur la consolidation de quatre millions d’UTXO chez Xapo, des nouvelles à propos de possibles mises à niveau du système de script de Bitcoin, des liens vers quelques questions et réponses très plébiscitées sur Bitcoin Stack Exchange, ainsi que quelques commits notables dans les branches de développement des projets Bitcoin Core, Lightning Network Daemon (LND) et C-lightning.

Action items

  • ● Bitcoin Core 0.16.2 released: une version mineure qui apporte des corrections de bugs et de petites améliorations. Si vous utilisez les RPC abandontransaction ou verifytxoutproof, vous devriez tout particulièrement envisager une mise à niveau. Sinon, nous vous recommandons d’examiner les notes de version pour les autres changements qui pourraient affecter votre activité et de mettre à niveau lorsque cela vous convient.

Dashboard items

  • ● Frais toujours bas : le taux de hachage a augmenté la difficulté de plus de 14 % durant la période de réajustement de 2 016 blocs qui s’est terminée dimanche, donnant un temps moyen entre les blocs de 8 minutes et 41 secondes. Cela a aidé à absorber la charge transactionnelle accrue due à la spéculation sur les prix de la semaine passée. Immédiatement après un réajustement de difficulté, le temps moyen entre les blocs est rétabli à 10 minutes.

    Alors que nous passons du calme habituel des transactions du week-end à la nouvelle semaine, il existe une possibilité d’augmentation rapide des estimations de frais de transaction. Nous recommandons de faire preuve de prudence lors de l’envoi de grosses transactions à faibles frais telles que les consolidations jusqu’à se rapprocher du week-end, quand le volume de transactions commence à nouveau à diminuer.

Rapport de terrain : Consolidation de 4 millions d’UTXO chez Xapo

par Anthony Towns, développeur sur Bitcoin Core chez Xapo

As mentioned in newsletter #3, the past few months of low transaction fees makes it a great time to do UTXO consolidation! Consolidation has been one of a variety of activities Xapo has been undertaking to be prepared for the next time fees spike like they did in the last few months of 2017.

Plot of total Bitcoin UXTOs, January - July 2018
Plot of total Bitcoin UXTOs, January - July 2018, source: Statoshi

The idea behind UTXO consolidation is essentially this: when your average outgoing payment is larger than your average incoming payment (or when they’re the same, but you’re batching outgoing payments), you’ll often have to combine many UTXOs in order to fund an outgoing transaction, which increases the size of your transactions and hence the fees you pay. By consolidating UTXOs in advance, you can combine inputs ahead of time, giving you more control over when most of those costs are incurred. If you can do it when fees are low, that lets you reduce those costs pretty substantially.

For example, if you would have spent a dozen 2-of-3 multisig inputs at 100 s/B (satoshis per byte), that would cost around 360,000 satoshis; while if you consolidated those inputs beforehand at 2 s/B, and then spent the single consolidated input later at 100 s/B, your total cost for the two transactions is only about 41,000 satoshis: i.e. 87% less paid in fees. And if fees don’t rise the risk isn’t huge: if fees just sat at 2 s/B, you’d be spending 7,900 satoshis across two transactions if you consolidated, rather than spending 7,200 satoshis in a single transaction if you did nothing.

Consolidation also gives an opportunity to update the addresses you use for your UTXOs, for example to roll keys over, switch to multisig, or switch to segwit or bech32 addresses. And reducing the number of UTXOs makes it easier to run a full node too, marginally improving Bitcoin’s decentralisation and overall security, which is always nice.

Of course, one thing you really don’t want to have happen is for your consolidation transactions to somehow fill up the blockchain and cause fees to immediately start rising! There are two metrics to watch to avoid this risk: one is whether the mempool is full (which causes the minimum acceptable fee to rise), and the other is how much empty space there has been in recent blocks (which gives an indication of whether miners will accept more transactions at the minimum fee). Both these metrics have been very promising most of the time over the past few months: the mempool has regularly been close to empty, meaning the transactions paying as little as 1 s/B have been propagated to miners; and many blocks have not been full, meaning cheap consolidation transactions will get mined reasonably quickly rather than creating a backlog that will cause fees to rise.

The approach we took to actually doing the consolidation was to have a script that would select groups of small UTXOs and create a consolidation transaction spending them to a single pool address at a fee rate of 1.01 satoshis per byte. The script gradually feeds consolidation transactions into the network, so it doesn’t cause too large a spike in the mempool, and perhaps more importantly so we don’t risk having our transactions get dropped because they have low fees and the mempool has filled up. We triggered this manually when we were comfortable it wouldn’t interfere with our operations, and when there didn’t seem to be much load on the Bitcoin network in general.

All in all, this has worked out pretty well; we’ve reduced our UTXO count by something like 4 million UTXOs this year, and aside from some concerned redditors, the cost to the network as a whole has been minimal, as has the cost to us.

Additional resources

Nouvelles

  • ● “Improvements in the Bitcoin Scripting Language” par Pieter Wuille : une présentation la semaine dernière donnant une vue d’ensemble de haut niveau de plusieurs améliorations possibles à court terme pour Bitcoin. Nous recommandons fortement de regarder la vidéo, de consulter les diapositives, ou de lire la transcription (avec références) par Bryan Bishop—mais si vous êtes trop occupé, voici la conclusion de Wuille : “mon objectif initial ici est les signatures Schnorr et taproot. La raison de cette focalisation est que la capacité à faire apparaître n’importe quelle entrée et sortie dans le cas coopératif comme identiques est un gain énorme pour le fonctionnement de l’exécution des scripts.

    “Schnorr est nécessaire pour cela car sans lui nous ne pouvons pas encoder plusieurs parties dans une seule clé. Le fait d’avoir plusieurs branches là-dedans est un changement relativement simple.

    “Si vous regardez les modifications du consensus nécessaires pour ces choses, c’est en réalité remarquablement faible, quelques dizaines de lignes de code. On dirait que la majeure partie de la complexité réside dans l’explication de l’utilité de ces choses et de la manière de les utiliser, et non pas tant dans leur impact sur les règles de consensus.

    “Des choses comme l’agrégation, je pense, sont quelque chose qui pourra être fait après que nous aurons exploré diverses options pour des améliorations structurelles du langage de script, une fois qu’il sera clair comment la structuration devrait être faite, parce que nous apprendrons probablement des déploiements comment ces choses sont utilisées en pratique. C’est ce sur quoi je travaille avec un certain nombre de collaborateurs et nous proposerons espérons-le quelque chose bientôt, et c’est la fin de ma présentation.”

Questions et réponses sélectionnées de Bitcoin Stack Exchange

Bitcoin Stack Exchange est l’un des premiers endroits où les contributeurs d’Optech cherchent des réponses à leurs questions—ou quand nous avons quelques moments libres pour aider à répondre aux questions d’autres personnes. Dans cette nouvelle rubrique mensuelle, nous mettons en lumière certaines des questions et réponses les mieux votées publiées au cours du mois écoulé.

  • ● Schnorr versus ECDSA : dans cette réponse, le développeur du protocole Bitcoin Pieter Wuille explique certains des principaux avantages du schéma de signature Schnorr par rapport au schéma actuel de signature ECDSA de Bitcoin.

  • ● Why does HD key derivation stop working after a certain index in BIP44 wallets? : un développeur testant son portefeuille constate qu’un paiement envoyé à des indices de clé peu élevés fonctionne comme prévu, mais que les paiements envoyés à des indices plus élevés n’apparaissent jamais dans ses portefeuilles. Une réponse de Viktor T. révèle pourquoi.

  • ● The maximum size of a Bitcoin DER-encoded signature is… : dans cette réponse, Pieter Wuille fournit les calculs pour déterminer la taille d’une signature Bitcoin. Comme mentionné dans le Bulletin #3, la taille maximale avec un portefeuille ordinaire est de 72 octets—mais Wuille explique comment vous pouvez créer une transaction non standard avec une signature de 73 octets et pourquoi vous pourriez penser avoir vu une signature de 74 voire 75 octets.

  • ● If you can use almost any opcode in P2SH, why can’t you use them in scriptPubKeys? : dans cette réponse, le rédacteur technique Bitcoin David A. Harding explique pourquoi les premières versions de Bitcoin restreignaient les types de transactions pouvant être envoyées aux “transactions standards” et pourquoi la plupart de ces restrictions sont toujours en place même si presque tous les opcodes sont désormais disponibles pour un usage standard via P2SH et segwit P2WSH.

Changements notables dans le code et la documentation

Un bref aperçu des fusions et commits récents réalisés dans divers projets Bitcoin open source.

  • ● Bitcoin Core #12257 : si vous démarrez Bitcoin Core avec l’option -avoidpartialspends, le portefeuille dépensera par défaut toutes les sorties reçues à la même adresse dès que l’une d’entre elles devrait être dépensée. Cela empêche que deux sorties vers la même adresse soient dépensées dans des transactions distinctes, ce qui est une manière courante par laquelle la réutilisation d’adresse réduit la confidentialité. L’inconvénient est que cela peut rendre les transactions plus grandes que leur taille minimale nécessaire. Les entreprises Bitcoin utilisant le portefeuille intégré de Bitcoin Core et n’ayant pas besoin de cette confidentialité supplémentaire peuvent tout de même vouloir activer cette option lorsque les frais sont faibles afin de consolider automatiquement les entrées liées.

  • ● LND #1617 : met à jour les estimations de la taille des transactions on-chain afin d’empêcher que des transactions paient accidentellement des frais trop faibles et restent bloquées. Ce commit peut être intéressant pour quiconque s’interroge sur la taille des transactions (et des parties de transactions) produites dans le protocole actuel.

  • ● LND #1531 : le daemon ne recherche plus les dépenses dans la mempool—il attend d’abord qu’elles fassent partie confirmée d’un bloc. Cela permet au même code de fonctionner sur des nœuds complets comme Bitcoin Core et btcd ainsi que sur des clients légers basés sur BIP157 qui n’ont pas accès aux transactions non confirmées. Cela fait partie de l’effort continu visant à aider les personnes sans nœud complet à utiliser LN.

  • ● Dans plusieurs commits, les développeurs de C-lightning ont pour l’essentiel achevé la transition consistant à gérer les fonctions liées aux pairs dans gossipd vers leur gestion dans channeld ou connectd selon le cas.

  • C-lightning a amélioré sa gestion des secrets afin que les secrets et signatures soient toujours générés et stockés par un daemon séparé des parties du système directement connectées au réseau.