La taille des blocks dans le réseau Bitcoin, en route vers les 20Mb ?

[Meuh6879]

(backup graphic image : http://imagizer.imageshack.us/a/img537/6123/DjnV42.gif )


https://bitcointalk.org/index.php?topic=946236.msg11338528#msg11338528

Pas mal, je voyais pas que ça se remplissais aussi vite ... malgré le peu de monde dessus.
Vivement que le mode "pruning" suive dans le même temps pour réduire la blockchain ... et bénéficier des blocks à 20Mb.

[1714969338]

1714969338

[1714969338]

1714969338

[1714969338]

1714969338

[1714969338]

1714969338

[Seldoon182]

Le block size 20 mb limit est juste débatut pour l'instant.

Reddit, I think you're jumping the gun based on watching a personal repository. I think this is just some testing code — he hasn't discussed this particular change with the other core developers; I for one would vigorously oppose it."

“For one, it's actually /broken/ because it doesn't change the protocol message size (makes for a nice example of how misleading unit tests often are; in this case they're vacuous as they don't catch that blocks over about 2MB wouldn't actually work). It's also not consistent with the last discussions we had with Gavin over his large block advocacy, where he'd agreed that his 20mb numbers were based on a calculation error.

[TotalPanda]

mmmmmhhh

[Seldoon182]

https://www.youtube.com/watch?v=Td6fwuI7F7U

[Seldoon182]

En tout cas la taille des blocks risque d'évoluer rapidement.

Oui je pense que si Bitcoin va vers l'augmentation de la taille des blocs plutôt que d'emprunter la piste des Sidechains, alors d'ici quelques années on sera à 2giga par bloc pour 14 000 transactions par secondes de quoi rivaliser avec le réseau VISA.

[Seldoon182]

[Meuh6879]

Message de Gavin Andresen, le communiquant (et développeur) de la team de développeurs (oui, il en a un tas derrière Gavin !) sur la façon dont pour être intégré, la limite des 20Mb : http://gavinandresen.ninja/bigger-blocks-another-way

1) Limite dynamique : une des plus populaire idée est de lier la limite de taille d'un block à ce qui s'est passé avant ... cela permet de rendre le réseau malléable ... et de conserver la fonction "antispam" du réseau.

Reste à savoir si la limite de la taille du block (toutes les 10 minutes) doit être basée sur les derniers blocks, l'augmentation de difficulté (il y a 2 semaines) ou d'autres critères comme les frais du réseaux (plus on en met et plus on peut augmenter la taille de bloc).

Gavin préfère intégrer des solutions simples dans ce sens car elles sont visuellement compréhensibles et n'enclenchent donc pas de bug après l'intégration (seulement des résultats que l'on peut étudier par la suite).

2) Pourquoi restreindre à 20Mb ? : certaines n'aiment pas laisser un logiciel libre de ses mouvements.

Ce qui est respectable car (il est) déployé sur bons nombres de machines peu puissantes (portables ou cartes ATOM/Arduino) et certains développeurs n'aiment pas le penchant/écrit de Satoshi qui indiquerait qu'à moyenne échéance, le travail d'un node reviendra aux mineurs ou à des acteurs spécialisés ... le reste des utilisateurs se contentant de programmes SPV (lecteur d'arbres de Merkle).

Une limite permet, aussi, de laisser une marge de manoeuvre pour étudier un problème et protéger le réseau contre un acteur hostile ayant un budget important pour faire perdurer une attaque ciblée.

[Meuh6879]

http://cointelegraph.com/news/114481/chinese-exchanges-reject-gavin-andresens-20-mb-block-size-increase

les mineurs (grosses fermes) commencent à râler sur l'augmentation car ils vont devoir augmenter leur consommation internet ... 

[Seldoon182]

Le Gavincoin est une connerie. Développons les Sidechains ffs !

[Meuh6879]

Les prévisions, c'est bien ... et ça donne ça ... en calculant 
https://bitcointalk.org/index.php?topic=1085852.0

[Meuh6879]

Un autre graphique plus simple ... pour comprendre les implications dans le réseau, de gros blocks (même si on faitu n raccourci important entre penser que tous les blocs seront pleins).

Source : https://i.imgur.com/FnxfFFR.png et https://bitcointalk.org/index.php?topic=1095586.0

[Seldoon182]

L'augmentation de la taille des blocs pose clairement une atteinte à la neutralité de Bitcoin. Un accord semble avoir été trouvé: https://bitcointalk.org/index.php?topic=1095804.0 Pour l'instant on ignore la décision finale mais on peut lire ceci:

Parameters are:

    8MB cap
    Doubling every two years (so 16MB in 2018)
    For twenty years
    Earliest possible chain fork: 11 Jan 2016
    After miner supermajority (code in the next patch)
    And grace period once miner supermajority achieved (code in next patch)

[Meuh6879]

J'ai toujours pas compris pourquoi ils ont pas fait les choses simplement : augmentation de la taille de bloc tous les ans ... durant 3 ans pour voir.

Techniquement, ça veut dire qu'on peut attendre 3 ans avant de refaire un Fork.

Et moi, je veux surtout le "pruning" quand on augmentera la taille de Block ! 

[Meuh6879]

30 000 transactions par secondes ?  
blocks de 8Go ...  

Purée, j'adore ce forum ... tout est calculé et prévisible des années en avance.
Mais qu'est-ce qu'ils attendent, les gens ?!?

Source : https://i.imgur.com/QoTEOO2.gif et https://bitcointalk.org/index.php?topic=1096227.0

[kcud_dab]

Un accord semble avoir été trouvé: https://bitcointalk.org/index.php?topic=1095804.0 Pour l'instant on ignore la décision finale mais on peut lire ceci:

J'aime bien les articles qui disent que le problème est reglé... ça fait des semaines que des gens se prennent la tête pour savoir si il faut ou non modifier la limites des blocks, donc une proposition qui a 24h et qui propose de la doubler tous les 2 ans ne va pas faire de consensius en 48h si rapidement...

[hdbuck]

paymium se mouille: http://www.e-ducat.fr/augmenter-la-taille-des-blocs-oui-mais-comment/

la solution proposée par Gavin Andresen, soutenue par Coinbase, Bitpay et Paymium, reste la plus prometteuse.

si c'est coinbase, bitpay et paymium qui le disent..

Son déploiement permettrait à la fois d’augmenter significativement la capacité du réseau et de tester sa gouvernance informelle par les mineurs à travers la mise à jour d’un paramètre important (la taille maximale d’un bloc).

j'ai hate de les voir tester leur gouvernance informelle () a propos de la limite du nombre de bitcoins.. ^^

[Meuh6879]

Ouais, c'est la prochaine bêtises qu'ils commencent à nous sortir dans la version XT. 

Moi, pour le moment, je suis pas chaud ... s'ils mettaient un noeud P2Pool dans le bitcoin core, ça m'arrangerait mieux et ça aiderait le réseau.

[TotalPanda]

J'ai bien l'envie d'implémenter ce type d'option. Pour voir ...  

[Meuh6879]

Une version de Bitcoin Core nommée "Bitcoin XT" apporte la modification de la taille des blocks à 8Mb pour donner de l'eau au moulin des fermes de minages chinoises qui ont accepté de miner avec la taille de 8Mb "pour voir ce que ça donne ..." : http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010235.html

Cette version XT, si elle est déployée en masse ... peut très bien être la suite de Bitcoin Core.
Il y aura donc séparation de la blockchain si cela arrive (mais on supposera aisément que les développeurs XT et CORE se mettront d'accord pour aligner l'ensemble lors du basculement en introduisant une version commune d'une révision de la version des blocks).

I feel sad that it's come to this, but there is no other way. The Bitcoin
Core project has drifted so far from the principles myself and many others
feel are important, that a fork is the only way to fix things.

Forking is a natural thing in the open source community, Bitcoin is not the
first and won't be the last project to go through this. Often in forks,
people say there was insufficient communication. So to ensure everything is
crystal clear I've written a blog post and a kind of "manifesto" to
describe why this is happening and how XT plans to be different from Core
(assuming adoption, of course).

[Meuh6879]

Pourtant, face à cette "mini" crise de tables de bureaux ... on peut mettre en lumière que le consensus suit son cours au sain des développeurs du Bitcoin Core.

Le consensus de l'augmentation de la taille des blocks est clairement défini dans le BIP100 : http://themerkle.com/news/current-state-of-the-blocksize-debate-bip-100-vs-bip-101/

Certains développeurs pensent comme moi qu'il est préférable de mettre à jour la limite de block progressivement en même temps que la mise à jour du client ... ainsi, on garde le contrôle sur la limite haute de génération des blocks.

C'est ce qu'introduit le BIP102.

Imaginez si plus de la moitié du réseau à une limite haute de 8Mb et qu'un problème arrive ?

Je préfère un doublement de la taille (de 1Mb à 2Mb) des blocks ... déjà pour voir ... puis 2-6 mois plus tard, une nouvelle révision de la taille en fonction des statistiques réelles constatées entre temps.

2 hard fork par an, c'est tout à fait jouable d'après les historiques du réseau Bitcoin (à mes yeux).
Evidemment, ça ne plaît pas à tout le monde de mettre à jour "régulièrement" son client Bitcoin ...  

---

De mon point de vue, je préfère rester sur le Bitcoin Core car je crois dans le travail des BIP du coté des développeurs.

Le BIP66 a dû "tirer" les fermes de minage chinoises ... de leur sommeil du coté des clients complets obsolète pour leur travail de minage.

Ce qui peut être amusant alors que ces derniers déclarent qu'ils soient déjà prêt pour la taille de block de 8Mb (et ses complications en terme de stockage et de bande passante).