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).
Topic: Segregated Witness, l'évolution prochaine du réseau Bitcoin. - page 5. (Read 16480 times)
pointage des blocks créés par un client Bitcoin Core : https://coin.dance/blocks
87,8 % sont issus d'un client Bitcoin Core.
87,8 % sont issus d'un client Bitcoin Core.
c'est le client modifié à la sauce viaBTC si j'ai bien vu.
bah, ça s'éteindra comme une bougie ...
bah, ça s'éteindra comme une bougie ...
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.
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 ?
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.
88% des blocks sont déjà actuellement minés par un Bitcoin Core officiel.
ç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 !..
https://bitcoin.org/fr/telecharger
C'est du long, mais c'est du bon.. Attendons de voir la suite maintenant avec les mineurs !..
Explications sur l'introduction du SegWit dans la v0.13.1 de Bitcoin Core :
Quote
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.
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.
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. 
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.
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.
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...
Apparemment ce n'est pas passé...
espérons que les autres mineurs se coalisent contre viabtc...
On les aura à l'usure.
Comme à chaque fois ...
Comme à chaque fois ...
Qu'en est il de l'approbation des mineurs ?? visiblement il faut atteindre les 95% c'est jouable ??
Projection immédiate de l'amélioration SegWit : https://medium.com/@bergealex4/moving-forward-reflections-on-scaling-bitcoin-retarget-milan-5e70ba88b2ab#.1bazzcarq
Il tournera avant décembre : http://www.newsbtc.com/2016/10/18/bitcoin-core-segwit-ready/
Si j'ai bien compris, en langage imagé ... ça donnerait ceci :
réseau actuel = http://media.drive-fermier.fr/catalog/product/cache/46/image/1000x760/9df78eab33525d08d6e5fb8d27136e95/c/a/cageot_gourmand_-_l_gumes_de_saison_-_15_.jpg
Les transactions sont désorganisées dans le block.
réseau futur = http://perso.numericable.fr/serge.cormier/miniature/vitrines/epicerie_fruits_legumes.jpg
Le block contient une organisation propre structurelle permettant ... de gagner de la place (et donc d'en mettre plus avec la même taille finale).
Je me demande si ce type d'organisation fait du retard de block en fonction des frais (0-fee en fait) ... pour organiser des petites transactions ensembles (faible historiques) et des grosses transactions ensemble dans le prochain block (forte historique de mouvement).
réseau actuel = http://media.drive-fermier.fr/catalog/product/cache/46/image/1000x760/9df78eab33525d08d6e5fb8d27136e95/c/a/cageot_gourmand_-_l_gumes_de_saison_-_15_.jpg
Les transactions sont désorganisées dans le block.
réseau futur = http://perso.numericable.fr/serge.cormier/miniature/vitrines/epicerie_fruits_legumes.jpg
Le block contient une organisation propre structurelle permettant ... de gagner de la place (et donc d'en mettre plus avec la même taille finale).
Je me demande si ce type d'organisation fait du retard de block en fonction des frais (0-fee en fait) ... pour organiser des petites transactions ensembles (faible historiques) et des grosses transactions ensemble dans le prochain block (forte historique de mouvement).
C'est exactement ce que j'ai compris aussi ! Ton résumé est tout simplement parfait
le BIP141 sera une mise en place du SegWit : https://github.com/bitcoin/bitcoin/commit/d12b732ac287a1ed7543481b79801c9afc333b7f
Ils veulent le faire après le halving, c'était déjà présenté comme ça (ne pas brusquer les plannings établis).
Ils ont raison.
J'ai l'impression qu'ils testent beaucoup en amont maintenant en informant un peu mieux (mineurs et exchange) puis quand vient le temps de release au public, ça fonctionne sans faille immédiate (la v0.12 en est un bon exemple d'ailleurs, on va surement aller à v0.13.0 alors que seulement la v0.12.0 et la v0.12.1 sont sorties).
Ils ont raison.
J'ai l'impression qu'ils testent beaucoup en amont maintenant en informant un peu mieux (mineurs et exchange) puis quand vient le temps de release au public, ça fonctionne sans faille immédiate (la v0.12 en est un bon exemple d'ailleurs, on va surement aller à v0.13.0 alors que seulement la v0.12.0 et la v0.12.1 sont sorties).
Bon alors, c'est pour quand? parce qu'on a 3 mois de retard sur le calendrier prévu la.. 
Jump to: