|
Meuh6879 (OP)
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
October 25, 2016, 11:18:10 AM |
|
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
|
|
October 27, 2016, 06:50:02 PM |
|
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 (OP)
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
October 27, 2016, 10:49:39 PM |
|
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
|
|
October 28, 2016, 08:40:51 AM |
|
ça y est enfin ! la dernière version 0.13.1 enfin en ligne ! https://bitcoin.org/fr/telechargerC'est du long, mais c'est du bon.. Attendons de voir la suite maintenant avec les mineurs !..
|
|
|
|
Meuh6879 (OP)
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
October 28, 2016, 12:53:09 PM |
|
Et on peut suivre le support du SegWit chez les mineurs ici : https://coin.dance/blocks88% des blocks sont déjà actuellement minés par un Bitcoin Core officiel.
|
|
|
|
Looarn
|
|
November 03, 2016, 06:50:26 PM |
|
Et on peut suivre le support du SegWit chez les mineurs ici : https://coin.dance/blocks88% 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 ?
|
If my post help you, you can tip me in FeatherCoin here: 6wgNso1AWVuGy5P5Rpc2bBoVaNaKzbxmyi
|
|
|
Meuh6879 (OP)
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
November 04, 2016, 01:00:01 AM |
|
c'est le client modifié à la sauce viaBTC si j'ai bien vu. bah, ça s'éteindra comme une bougie ...
|
|
|
|
Meuh6879 (OP)
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
November 19, 2016, 02:00:26 PM |
|
pointage des blocks créés par un client Bitcoin Core : https://coin.dance/blocks87,8 % sont issus d'un client Bitcoin Core.
|
|
|
|
|
Meuh6879 (OP)
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
November 26, 2016, 01:16:32 AM |
|
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 (OP)
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
November 26, 2016, 04:36:25 PM |
|
|
|
|
|
oscar2000
Legendary
Offline
Activity: 2706
Merit: 1201
עם ישראל
|
|
November 30, 2016, 08:26:29 PM |
|
https://blockchain.info/fr/charts/bip-9-segwitdé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é.
|
הִנֵּה לֹא יָנוּם וְלֹא יִישָׁן שׁוֹמֵר יִשְׂרָאֵל jamais il ne dort ni ne sommeille, le gardien d'israël
|
|
|
Meuh6879 (OP)
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
December 01, 2016, 04:39:02 PM |
|
c'est un peu lent ... mais les 3 mois seront là (comme d'habitude pour un changement des versions).
|
|
|
|
perl
Legendary
Offline
Activity: 1918
Merit: 1190
|
|
December 04, 2016, 07:35:55 PM |
|
Il y a un beau plateau a 25%
|
|
|
|
|
Meuh6879 (OP)
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
December 18, 2016, 10:34:59 PM |
|
Après 1 mois :
|
|
|
|
perl
Legendary
Offline
Activity: 1918
Merit: 1190
|
|
December 19, 2016, 07:55:54 AM |
|
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 (OP)
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
January 12, 2017, 07:14:15 PM |
|
Point sur les noeuds faisant fonctionner une version de Bitcoin Core activée avec SegWit : 55.3 %
|
|
|
|
Meuh6879 (OP)
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
March 01, 2017, 09:49:04 PM |
|
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.
|
|
|
|
|