Segregated Witness, l'évolution prochaine du réseau Bitcoin.

[ymig1]

https://www.linkedin.com/pulse/la-tyrannie-des-mineurs-cyril-grunspan

Apparemment ce n'est pas passé...

espérons que les autres mineurs se coalisent contre viabtc...

[1715241563]

1715241563

[1715241563]

1715241563

[Meuh6879]

Le passé a montré que quand des mineurs n'acceptent pas (en tout cas, l'opérateur du pool) la tendance de la plupart ... ça se finit par un desert (coté opérateur).

De plus, je ne fais pas confiance aux statistiques de la piscine minière montrées par Blockchain.info car elles ne font jamais apparaître les blocks de la P2Pool (alors qu'il y a 1 an, si).

C'est pour ça que j'indiquais qu'on les aurait à l'usure.
Quand un potentiel est en attente, la plupart ne veulent pas attendre (surtout si cela a été testé bien en amont et correctement).

L'introduction de la 0.13.1RC2 est un bon exemple de la prudence qu'ils utilisent.
les statistiques des 0.13.1 n'apparaissent toujours pas sur bitnodes ... 2ème point problématique pour se faire une idée ... alors que de mon coté, c'est full slots sur du 0.13-0.13.1

---

On a donc des outils statistiques qui ne donnent pas la vrai réalité du réseau.
Et c'est (très) étrange pour des outils sensés être neutres ... justement.

[ungaro59]

Je suis pret a miner du bitcoin le temps qu'on passe a segwit s'il le faut. On est trop prêt du but pour s'arrêter la maintenant ! Fuck ViaBTC.

[Meuh6879]

Explications sur l'introduction du SegWit dans la v0.13.1 de Bitcoin Core :

Segregated witness soft fork

Segregated witness (segwit) is a soft fork that, if activated, will
allow transaction-producing software to separate (segregate) transaction
signatures (witnesses) from the part of the data in a transaction that is
covered by the txid. This provides several immediate benefits:

    Elimination of unwanted transaction malleability: Segregating the witness
      allows both existing and upgraded software to calculate the transaction
      identifier (txid) of transactions without referencing the witness, which can
      sometimes be changed by third-parties (such as miners) or by co-signers in a
      multisig spend. This solves all known cases of unwanted transaction
      malleability, which is a problem that makes programming Bitcoin wallet
      software more difficult and which seriously complicates the design of smart
      contracts for Bitcoin.

    Capacity increase: Segwit transactions contain new fields that are not
      part of the data currently used to calculate the size of a block, which
      allows a block containing segwit transactions to hold more data than allowed
      by the current maximum block size. Estimates based on the transactions
      currently found in blocks indicate that if all wallets switch to using
      segwit, the network will be able to support about 70% more transactions. The
      network will also be able to support more of the advanced-style payments
      (such as multisig) than it can support now because of the different weighting
      given to different parts of a transaction after segwit activates (see the
      following section for details).

    Weighting data based on how it affects node performance: Some parts of
      each Bitcoin block need to be stored by nodes in order to validate future
      blocks; other parts of a block can be immediately forgotten (pruned) or used
      only for helping other nodes sync their copy of the block chain.  One large
      part of the immediately prunable data are transaction signatures (witnesses),
      and segwit makes it possible to give a different "weight" to segregated
      witnesses to correspond with the lower demands they place on node resources.
      Specifically, each byte of a segregated witness is given a weight of 1, each
      other byte in a block is given a weight of 4, and the maximum allowed weight
      of a block is 4 million.  Weighting the data this way better aligns the most
      profitable strategy for creating blocks with the long-term costs of block
      validation.

    Signature covers value: A simple improvement in the way signatures are
      generated in segwit simplifies the design of secure signature generators
      (such as hardware wallets), reduces the amount of data the signature
      generator needs to download, and allows the signature generator to operate
      more quickly.  This is made possible by having the generator sign the amount
      of bitcoins they think they are spending, and by having full nodes refuse to
      accept those signatures unless the amount of bitcoins being spent is exactly
      the same as was signed.  For non-segwit transactions, wallets instead had to
      download the complete previous transactions being spent for every payment
      they made, which could be a slow operation on hardware wallets and in other
      situations where bandwidth or computation speed was constrained.

    Linear scaling of sighash operations: In 2015 a block was produced that
      required about 25 seconds to validate on modern hardware because of the way
      transaction signature hashes are performed.  Other similar blocks, or blocks
      that could take even longer to validate, can still be produced today.  The
      problem that caused this can't be fixed in a soft fork without unwanted
      side-effects, but transactions that opt-in to using segwit will now use a
      different signature method that doesn't suffer from this problem and doesn't
      have any unwanted side-effects.

    Increased security for multisig: Bitcoin addresses (both P2PKH addresses
      that start with a '1' and P2SH addresses that start with a '3') use a hash
      function known as RIPEMD-160.  For P2PKH addresses, this provides about 160
      bits of security---which is beyond what cryptographers believe can be broken
      today.  But because P2SH is more flexible, only about 80 bits of security is
      provided per address. Although 80 bits is very strong security, it is within
      the realm of possibility that it can be broken by a powerful adversary.
      Segwit allows advanced transactions to use the SHA256 hash function instead,
      which provides about 128 bits of security  (that is 281 trillion times as
      much security as 80 bits and is equivalent to the maximum bits of security
      believed to be provided by Bitcoin's choice of parameters for its Elliptic
      Curve Digital Security Algorithm [ECDSA].)

    More efficient almost-full-node security Satoshi Nakamoto's original
      Bitcoin paper describes a method for allowing newly-started full nodes to
      skip downloading and validating some data from historic blocks that are
      protected by large amounts of proof of work.  Unfortunately, Nakamoto's
      method can't guarantee that a newly-started node using this method will
      produce an accurate copy of Bitcoin's current ledger (called the UTXO set),
      making the node vulnerable to falling out of consensus with other nodes.
      Although the problems with Nakamoto's method can't be fixed in a soft fork,
      Segwit accomplishes something similar to his original proposal: it makes it
      possible for a node to optionally skip downloading some blockchain data
      (specifically, the segregated witnesses) while still ensuring that the node
      can build an accurate copy of the UTXO set for the block chain with the most
      proof of work.  Segwit enables this capability at the consensus layer, but
      note that Bitcoin Core does not provide an option to use this capability as
      of this 0.13.1 release.

    Script versioning: Segwit makes it easy for future soft forks to allow
      Bitcoin users to individually opt-in to almost any change in the Bitcoin
      Script language when those users receive new transactions.  Features
      currently being researched by Bitcoin Core contributors that may use this
      capability include support for Schnorr signatures, which can improve the
      privacy and efficiency of multisig transactions (or transactions with
      multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can
      improve the privacy and efficiency of scripts with two or more conditions.
      Other Bitcoin community members are studying several other improvements
      that can be made using script versioning.

[ungaro59]

ça y est enfin ! la dernière version 0.13.1 enfin en ligne !

https://bitcoin.org/fr/telecharger

C'est du long, mais c'est du bon.. Attendons de voir la suite maintenant avec les mineurs !..

[Meuh6879]

Et on peut suivre le support du SegWit chez les mineurs ici : https://coin.dance/blocks

88% des blocks sont déjà actuellement minés par un Bitcoin Core officiel.

[Looarn]

Et on peut suivre le support du SegWit chez les mineurs ici : https://coin.dance/blocks

88% des blocks sont déjà actuellement minés par un Bitcoin Core officiel.

Toujours des super info Meuh. Merci pour le partage.

Par contre j'ai pas compris ce qu'était le unlimited, on le voit progresser, c'est un node aussi avec d'autre évolution ?

Pour les mineurs, pas sûr qu'il y gagne avec le SegWit car certe on traite plus de blocs, par contre plus de soucis au niveau de la mempool donc plus d'extra fees, tout le monde passe. En gros il gagneront moins au debut, puis de plus en plus en fonction du nombre de transaction.

J'ai bon ?

[Meuh6879]

c'est le client modifié à la sauce viaBTC si j'ai bien vu.
bah, ça s'éteindra comme une bougie ... 

[Meuh6879]

pointage des blocks créés par un client Bitcoin Core : https://coin.dance/blocks

87,8 % sont issus d'un client Bitcoin Core.

[Meuh6879]

Carte plus précise sur le vote en cours.
http://bitcoin.sipa.be/versions.html



(source bitcoin.fr ).

[Meuh6879]

Une question revient souvent sur la partie anglaise du forum : ViaBTC est-il est un problème ?
Non, il n'en est pas un.

---

La première explication la plus simpliste (car en ligne droite) est que la puissance du réseau évolue et que c'est rarement les mineurs privés qui évoluent aussi rapidement (question de rentabilité des achats de matériels tout simplement).

Ainsi, si ViaBTC représente un % actuellement ... bloquant, on sait très bien que dans 2-3 mois, il en sera tout autrement.

---

La deuxième explication est plus conceptuelle et humaine, s'appuyant sur ce qu'il s'est déjà passé lorsque les mineurs devaient tous migrer sur le BIP66.
Les mineurs restant ont commencé à perdre l'ensemble de leur revenu car les mineurs qui utilisaient la team ont compris qu'elle était un frein "à quelque chose".
La deuxième chose est qu'une fois un palier passé, les noeuds qui sont les plus proches des révisions sont plus enclin à dialoguer rapidement avec les versions identiques (récentes donc).

Hors, sur le réseau, il n'y a rien de plus vrai qu'un décalage sensible des versions entre elles ... avec toutes les améliorations à chaque version qui manque.

Le simple fait qu'un client mineur ... n'ait pas les compact block par exemple (BIP152) va lui faire perdre des secondes dans lequel il ne sera pas informé qu'un nouveau block a été créé sur le réseau.

Mis bout-à-bout, la team de minage n'obtient plus les blocks qu'elle obtenait jadis.
C'est là toute la beauté d'un soft-fork ... pouvoir servir toutes les anciennes versions mais en introduisant une course au plus efficace.

Un noeud n'a pas d'intérêt à aller le plus vite, il aime avoir une blockchain correcte et pouvoir y piocher les bitcoins qu'il a acquis.

Un noeud-mineur, en revanche, est très à cheval sur le ping et encore plus quand l'ensemble de ses proches noeuds introduisent des fonctions de rapidité alors que lui ne peut pas les voir et les utiliser (car il est sur une version différente ou modifiée pour sa team de minage, ce qui arrive souvent ... justement).

[Meuh6879]

Point sur les fermes de minages qui supportent ou pas ... le SegWit : https://bitcoinmagazine.com/articles/where-bitcoin-mining-pools-stand-on-segregated-witness-1480086424

[oscar2000]

https://blockchain.info/fr/charts/bip-9-segwit
déjà à 20 % aujourd'hui (en moyenne sur 2016 blocs), et ça monte de manière linéaire. ça veut dire que environ 40 à 45 % y sont déjà passés en instantané.

[Meuh6879]

c'est un peu lent ... mais les 3 mois seront là (comme d'habitude pour un changement des versions).

[perl]

Il y a un beau plateau a 25%

[Meuh6879]

Je pense que les mineurs attendent que les wallet soient tous compatibles : https://bitcoin.fr/segwit-encore-un-effort/

C'est, effectivement, très logique.

[Meuh6879]

Après 1 mois :

[perl]

Je pense que les mineurs attendent que les wallet soient tous compatibles : https://bitcoin.fr/segwit-encore-un-effort/

C'est, effectivement, très logique.

Les mineur en ont rien à faire du wallet. Rendre leur infra compatible à un coût que pour le moment il veulent pas porter. Et on peut être peur d une réduction des fee

[Meuh6879]

Point sur les noeuds faisant fonctionner une version de Bitcoin Core activée avec SegWit :

55.3 %

[Meuh6879]

La troisième version de la révision de Bitcoin Core va sortir ... et les mineurs qui sont restés muets devraient donc pouvoir switcher définitivement avec un basculement sans retour en arrière probable des noeuds.

Il y aura donc 3 versions de Bitcoin Core sur le réseau Bitcoin supportant d'emblée le SegWit :

0.13.1
0.13.2
et
0.14.0

Mais d'après cette mesure, il est plus probable que les mineurs attendront 4 à 5 versions de Bitcoin Core d'emblées supportant SegWit pour y aller.