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

perl

legendary

Activity: 1918

Merit: 1190

Quote from: galaxiekyl on August 27, 2016, 09:31:59 AM

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.

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

galaxiekyl

legendary

Activity: 2002

Merit: 1113

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.

Meuh6879

legendary

Activity: 1512

Merit: 1012

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.

galaxiekyl

legendary

Activity: 2002

Merit: 1113

é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 Roll Eyes

Meuh6879

legendary

Activity: 1512

Merit: 1012

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/

Quote

Sex, Drugs, Rock & Roll

In his essay, Roger analogizes Bitcoin to Starbucks. According to him, the 1 MB cap is like limiting a Starbucks to twenty customers in a day. If they did that, there would be no way Starbucks would be successful. But Bitcoin is more like a Starbucks that the government is constantly trying to shut down. It only exists because it can’t be shut down.

Bitcoin is regulatory arbitrage at its finest, the monetary equivalent of what BitTorrent is to the sharing of media content. When users send Bitcoin from one person to another, instead of recording the transaction on a single server, like Paypal or any other bank, miners compete to bundle transactions into blocks. If the government regulates or shuts down any given mining operation, there will be others, somewhere in the world, willing to step up and compete for the block reward. The system thus far has created a perfect balance, with just enough decentralization to keep its independence, but just enough centralization to eliminate redundancies.

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

Quote

Sadly, Bitcoin has been marketed for years as a free/cheap network for transactions, but this is flatly untrue. Bitcoin, as it currently stands, is poorly designed for retail, which is why payment processors like Bitpay are struggling despite millions in venture capital. Supporters of raising the Bitcoin blocksize bought into this narrative so deeply, they believe that Bitcoin must remain cheap to use. But Bitcoin’s users, the underserved, don’t care about free transactions, they care about the transaction freedom.

galaxiekyl

legendary

Activity: 2002

Merit: 1113

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

Meuh6879

legendary

Activity: 1512

Merit: 1012

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

galaxiekyl

legendary

Activity: 2002

Merit: 1113

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.

hdbuck

legendary

Activity: 1260

Merit: 1002

le filtre cest les fees.

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

bitcoin c'est pas les restos du coeur.

Barnabe

hero member

Activity: 616

Merit: 503

★Bitvest.io★ Play Plinko or Invest!

Quote from: galaxiekyl on January 30, 2016, 05:39:20 PM

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.

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.

galaxiekyl

legendary

Activity: 2002

Merit: 1113

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.

Meuh6879

legendary

Activity: 1512

Merit: 1012

ça commence à bouger ...

Meuh6879

legendary

Activity: 1512

Merit: 1012

ça y est ... on y est.

Limite de block du Bitcoin Core 0.11.2 = 750kB

Code:

2016-01-16 13:34:50 CreateNewBlock(): total size 749986

2016-01-16 13:34:52 socket recv error Une connexion existante a dû être fermée par l'hôte distant. (10054)
2016-01-16 13:35:04 socket recv error Une connexion existante a dû être fermée par l'hôte distant. (10054)
2016-01-16 13:35:05 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter

2016-01-16 13:35:08 CreateNewBlock(): total size 749869
2016-01-16 13:35:26 CreateNewBlock(): total size 749984

2016-01-16 13:35:28 socket recv error Une connexion existante a dû être fermée par l'hôte distant. (10054)
2016-01-16 13:35:34 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-16 13:35:35 ERROR: AcceptToMemoryPool: nonstandard transaction: dust

2016-01-16 13:35:43 CreateNewBlock(): total size 749969

2016-01-16 13:35:46 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-16 13:35:52 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-16 13:35:55 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter

2016-01-16 13:36:02 CreateNewBlock(): total size 749918

2016-01-16 13:36:11 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-16 13:36:16 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-16 13:36:17 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-16 13:36:17 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter

2016-01-16 13:36:20 CreateNewBlock(): total size 749974

Meuh6879

legendary

Activity: 1512

Merit: 1012

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

Quote

People often think that Bitcoin is ruled by miners, but this is wrong. Miners are merely employees of the network. Even if every miner decided to make 2 MB blocks right now, everyone running a Bitcoin full node would simply ignore their blocks. Bitcoin is composed of immutable rules (called "consensus rules") that all full nodes enforce no matter what.

Le texte complet est dans le lien.

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

Meuh6879

legendary

Activity: 1512

Merit: 1012

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.

glub0x

legendary

Activity: 892

Merit: 1013

Quote from: drhelmutp on August 19, 2015, 09:04:37 AM

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.

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.

Barnabe

hero member

Activity: 616

Merit: 503

★Bitvest.io★ Play Plinko or Invest!

Quote from: drhelmutp on August 19, 2015, 09:04:37 AM

Quote from: glub0x on August 19, 2015, 08:58:51 AM

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

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

Quote from: glub0x on August 19, 2015, 08:58:51 AM

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.

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.

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

drhelmutp

sr. member

Activity: 440

Merit: 250

Quote from: glub0x on August 19, 2015, 08:58:51 AM

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

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

Quote from: glub0x on August 19, 2015, 08:58:51 AM

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.

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.

glub0x

legendary

Activity: 892

Merit: 1013

Quote from: kcud_dab on August 19, 2015, 07:19:58 AM

Quote from: Barnabe on August 19, 2015, 07:14:18 AM

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.

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.

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

kcud_dab

legendary

Activity: 1652

Merit: 1002

Bitcoin enthusiast!

Quote from: Barnabe on August 19, 2015, 07:14:18 AM

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.

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.

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