Topic: La taille des blocks dans le réseau Bitcoin, en route vers les 20Mb ? (Read 13409 times)

Il y a qu'une vitesse celle de celui qui met le plus .

J'en ai mis suffisamment mais pas trop.

C'est l'une des caractéristiques que core devra résoudre à l'avenir car si le rejet des transactions est intentionnel, les utilisateurs risquent de perdre patience, toutes les transactions devraient être inclus dans un Block celon l'ordre d'envoi et non pas par priorité.. Autrement c'est la BC à 2 vitesse.. les dev doivent juste s'assurer que des frais minimum on bien été inclus.

Tout dépend ce que tu as autorisé comme frais.

Les hot wallet (téléphone) sont très conservateurs (mettent trop de frais).

Le Bitcoin Core fait ce que tu veux (il faut donc savoir à combien sont les frais pour ne pas taper trop bas en frais).

ça fait longtemps que j'ai plus fait de transaction sans frais (ça existe encore ?) ... car quand je regarde la mempool, ça fait froid dans le dos (12000-14000 transactions en attente avec 300Mo de mempool).

C'est vraiment rare que ça descend à moins de 4200 maintenant depuis que j'ai enlevé la purge de la Mempool locale.

évidemment, il ne faut pas exagérer le réseau n'est pas congestionné à ce point..aujourd'hui par exemple, on es loin de la saturation du réseau pourtant ma transaction met un certain temps avant d'être confirmé..j'ai déjà remarqué cela lors de transactions simultané (in/out) mes transactions (out) mettaient plus de temps être confirmé par un mineur..alors que les in mettaient moins de temps..dire qu'il y a boycote c'est certain..mais de là à dire que c'est intentionnel..je ne m'y avancerai pas  

Pourquoi la taille de block n'est pas un objectif sérieux ... pour des développeurs.
Faire rentrer plus dans la même chose, c'est un objectif sérieux !

https://fee.org/articles/dont-increase-the-block-size-for-bitcoin-transactions/


Et ce n'est donc pas un hasard de croiser cette constatation : "avant d'être gratuites, les transactions doivent être libres !"

ça sent surtout le pump à plein nez, mais quid de "classic" fork ou pas 

ça sent à plein nez le serveur VPS loué pour 30j. ce truc-là de classic à block de 2Mb (ils ont fait pareil avec le XT de 20Mb à l'époque).

surtout qu'une transac à 50ct avec frais c'est c'est plus un repas à 50ct.

il y a des alt pour ça, surtout quand les mineur demanderont plus de frais pour couvrir les perte du halving.

le filtre cest les fees.

bitcoin cest pas fait pour te payer un repas 50cts.

bitcoin c'est pas les restos du coeur.

Filtrer les transaction c'est dire que certaines transactions ne sont pas importantes et peuvent être négligées.
Si le bitcoin était utilisé dans un système uniforme (tous les utilisateurs sont semblables) cela ne poserait pas de problème, (en Europe on pourrait dire que les transactions de moins de 50 cts ne sont pas prioritaires).
Le problème c'est que dans d'autres pays on peut payer un repas avec ces 50 cts. Le filtrage ne serait donc pas efficace, car il empêcherait une grande partie des gens d'utiliser la monnaie normalement.

Qui plus est, pourquoi mettre en place un système de filtrage alors que même les mineurs sont d'accord pour agrandir les blocs ? Ce serait utiliser une solution temporaire alors qu'on a la capacité de résoudre le problème plus durablement et sans contraintes.

mieux vaut prévenir que guérir,  ce n'est pas en laissant passé plus d'impuretés dans un volume qu'on le rend plus fluide, il faut d'abord contrôlé les filtres, les changé s'il ne sont pas ou plus adapté et ensuite vérifié le débit et agir en fonction.

traduction: un contrôle des transactions parasite (par ex service de mixing) est peut être analysé par les dev, une solution de filtrage est peut être à implémenté avant l'augmentation de volume, la sécurité avant tout.

ça commence à bouger ...

  ça y est ... on y est.



Limite de block du Bitcoin Core 0.11.2 = 750kB

Une petite explication sur la limitation à 1Mb tant que ça ne sera pas "nécessaire" de l'augmenter : https://bitcointalksearch.org/topic/m.13420219


Le texte complet est dans le lien.

Autre lien lié : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

le soucis est toujours qu'il est difficile "de vendre" un correctif de fond tout-de-suite ... plutôt de le "proposer" quand il n'y a plus le choix.

moi, je suis plutôt du coté du dernier choix ... même si le premier choix à l'avantage de préparer le terrain et de voir un peu un début de fonctionnement avant un problème que l'on peut rêgler au fur-et-à-mesure sans que cela impact les performances.

c'est pour ça qu'on a l'impression que le développement de Bitcoin Core n'avance pas.
c'est pas qu'il n'avance pas, c'est qu'il avance avec prudence ... voilà tout.

ca me fait penser à un "proverbe" de bigard ( vive la référence )
"C'est au pied du mur qu'on voit le mieux le mur"
Pour le moment il n'y a aucun problème effectivement, il n'y avait aucun problème en 2012,2013,2014, je me demande pourquoi les gens en parlait ...
En 2015, le seul problème c'est XT simplement car ils mettent les pieds dans le plat? toujours pour parler en image, a mon avis il ne faut pas blâmer le messager.

Ces rigolos mettent quand même un gros problème.
Le bitcoin a toujours eu des problèmes de crédibilité. Par le passé, on parlait beaucoup des attaques 51% et c'était légitime. Un gouvernement pouvait relativemment facilement torpiller le bitcoin sans grand problème. Vu la puissance de calcul dans le reseau de nos jours, on peut penser à raison que ce n'est plus une aussi grande menace.
Aujourd'hui ce qui empêche le bitcoin de pouvoir grandir et d'être pris au serieux par le grand public et/ou ce qui pourrait être exploité par un tiers mal intentionné c'est la taille des blocs.

Au bout d'un moment il faut agir, une grande partie des mineurs chinois s'est déjà prononcé pour 20MO et pas mal d'entreprises ont publiquement pris position pour la solution qu'ils préfèrent ce qui est deja un bon début. Mais il aurait fallu que ce genre d'accord soit déjà en place et la migration déjà prévue, en étant aussi peu réatif le bitcoin perd de la crédibilité.

Le problème c'est qu'a y sauter pied joints, c'est un coup a y rester coincé.

En théorie, la limite des blocs est très bien comme elle est actuellement, les transactions passent bien, les blocs sont loin d'être plein. Le seul problème c'est quand on a des rigolos qui poussent vers une augmentation en saturant le reseau.

Quelque soit nos actions, le soleil va exploser et le monde va griller donc?
Je comprend pas trop l'intérêt de cette réponse.

Je pense aussi que ce problème aurait du être traité depuis longtemps, Xt à permis de taper dans la fourmilière et j'aime bien quand on saute à pied joint dans le tas de merde plutôt que de tourner autour pendant des années en attendant qu'il s'envole (qd je suis arrivé sur bitcoin on en parlait déjà des 1mb -- 2012!).

Si tout le monde est d'accord pour augmenter mais ne fait jamais rien on peut rester encore 4 ans avec la limite a 1mo et après? Mike hearn le dit bien dans son post, dire qu'on est pour une augmentation c'est bien mais a un moment il faut décider de QUAND on décide et quelle méthode on choisit pour mettre en place ce changement qui serra forcement un fork.

Toute les solutions posent des limites arbitraires selon moi sans réelle fondement, mais je ne suis pas  certain qu'il y ait de solution optimale, souvent les choix les plus dure sont ceux ou on a plein de solutions équivalentes ...

Quelque soit la limite de la taille des blocs (tant qu'il y en a une) on l'approchera et on arrivera un jour à la saturation.

Je comprends la polémique, ce que je ne comprends pas c'est que ce problème a été laissé de coté pendant des mois/années et qu'il ne surgit maintenant qu'on est à la limite de la capacité des blocs.

C'est quelque chose qui aurait déjà du être en place il y a au moins 6 mois.

À priori, au delà d'une certaine taille de bloc, la décentralisation du réseau serait menacée.

Comment déterminer cette taille critique ? Peut-elle être fixe ?  Calculée dynamiquement ?

Bitcoin tel que nous le connaissons a-t-il atteint ses limites de developpement/expansion ?

Beaucoup de questions pour lesquels nous devrions commencer à obtenir des réponses dans les mois qui viennent.

Et c''est quoi la bonne taille ? 2 Mo ? 4 Mo ? 7 Mo ? 21 Mo ? Pas de limite ?
C'est plus ça le fond du problème : combien et pourquoi ?

Je comprends pas pourquoi il y a une telle polémique pour un changement qui aurait du être anticipé (et qui était prévisible) depuis longtemps.
La taille des blocs doit être augmentée, c'est un fait.
Même s'il n'y a qu'une mise à jour qu'une fois par an ce ne devrait pas être un problème ni pour les utilisateurs ni pour les fermes.

c'est toujours une discussion, ce n'est pas mergé

J'ai bien vu, ils acceptent l'augmentation de la taille de block à 2mb pour novembre 2015 ?
https://github.com/bitcoin/bitcoin/pull/6451

  OK, bien compris, je vais rester dans le suivi des BIP puisqu'ils sont affiliés à Bitcoin Core.
Que les autres membres ne parlent du XT que sur le lien que kcud_dab a indiqué !

À propos de XT
-> https://bitcointalksearch.org/topic/bitcoin-xt-1153821

Le déploiement de la version XT peut être suivi officiellement sur l'adresse habituelle qui montre l'activité du réseau Bitcoin : https://getaddr.bitnodes.io/dashboard/

Dommage qu'on est rien entre l’échelle 24h et celle de ... 90 jours. 

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).

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).

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

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.

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


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



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

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...

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://bitcointalksearch.org/topic/bitcoin-xt-or-bitcoin-qt-on-rpi-2-1096227

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 ! 

L'augmentation de la taille des blocs pose clairement une atteinte à la neutralité de Bitcoin. Un accord semble avoir été trouvé: https://bitcointalksearch.org/topic/bitcoin-block-size-conflict-ends-with-latest-update-1095804 Pour l'instant on ignore la décision finale mais on peut lire ceci:

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://bitcointalksearch.org/topic/infographic-that-details-both-sides-of-the-blocksize-issue-1095586

Les prévisions, c'est bien ... et ça donne ça ... en calculant 
https://bitcointalksearch.org/topic/blocksize-growth-extrapolation-attempts-1-linear-2-polynomial-fits-1085852

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

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 ... 

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.

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.

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

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

mmmmmhhh

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

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


https://bitcointalksearch.org/topic/m.11338528

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.