Bitcoin XT

[Meuh6879]

Mise en place de la purge et de la restriction du mempool grace à la dernière version 0.11B : https://medium.com/@octskyward/mempool-size-limiting-a3f604b72a4a

Q: What is mempool size limiting?

The mempool is the network’s holding area for transactions that have been made but not put into a block yet. Every Bitcoin node on the network holds unconfirmed transactions in RAM and removes them once they are confirmed. From then on they’re held only on disk.

Bitcoin Core and releases of Bitcoin XT prior to 0.11B have no limit on the number of unconfirmed transactions they will try to hold. If a transaction is valid it will stay in RAM forever until it’s mined. This means DoS attackers can flood the network with transactions until nodes start to run out of physical memory and fall over. I wrote about what can happen then in my article, Crash Landing.

  comment on peut construire des logiciels qui ne purgent rien et stockent tout en RAM jusqu'à planter ?
je pensais que le DBCache (ligne de commande) restreignait cela dans Bitcoin Core !

Il n'en est rien.
Pourtant y'a bien le marqueur UTXO dans le "sommaire" du rêglage du DBCache justement ... 

[Meuh6879]

  Mouais, ça marche bien ... la RAM, effectivement, n'est plus siphonnée avec un plantage à la fin proche de 46Mo de RAM restante (libre).

Par contre, y'a rien à faire ... ça bouffe vraiment trop de CPU pour faire les recherches entre les blocks, l'UTXO et le SPAM réseau.

là, la restriction par frais de réseau (relay) fonctionne (pour limiter l'usage au CPU). 

[Meuh6879]

Bon, on va essayer cela :

Code:

maxmempooltx=100000      #restriction RAM du mempool (noeud simple)
minrelaytxfee=0.00002    #restriction CPU (traitement mining P2Pool)

le 0.00002 , je l'ai sorti de mon android wallet en période de SPAM avec un rêglage des frais en "économique".
j'ai passé une transaction avec ces frais-là pour être sûr que ça passe "normalement" dans le block suivant.

[Meuh6879]

Pour ceux qui veulent, un peu, tester la limite de leur matériel ... utilisez ces rêglages-là :

Code:

maxmempooltx=1000
minrelaytxfee=0.00000001

puis faites des getinfo dans la CONSOLE déjà pour voir s'il a compris (faute dans la ligne de commande par exemple).

ensuite, utilisez à intervals réguliers, le getmempoolinfo pour regarder comment se rempli et surtout comme "purge" le Bitcoin XT, sa mémoire RAM des transactions.

augmentez le maxmempooltx suivant la puissance de votre CPU ...

si on augmente les minrelaytxfee, le CPU est encore plus déchargé de son travail.

---

Tout ceci n'est valable que quand le Bitcoin XT est en mode noeud ET server (P2Pool).
Attention, les transactions intégrées dans un blocks dépassent actuellement les 1 800 en moyenne ... c'est pour ça que l'auteur de cette option indique de "commencer" à 50 000.

Mettre à 1000 ne permet que de voir comme la "purge" Bitcoin XT a lieu ...

[Meuh6879]

Bon, c'est bien ... le dernier rêglage présenté à un gros avantage :

-il relaie toutes les transactions (mêmes les satoshis !)
-il purge après 1000 quelque chose ... qui, en période de SPAM, tourne à 7-8Mo de blocks créés

Mon CPU suit plus quand ça approche 1700 quelque chose ... donc, ça me va aussi tend que j'ai au moins 3 blocks possible en mempool.

[Meuh6879]

La révision C est sortie : https://github.com/bitcoinxt/bitcoinxt/releases/tag/v0.11C

Code:

This release fixes a buffer overflow in the integrated UPNP support.

  c'est un peu léger comme explications ...

[btchip]

C'est normal, ils étaient trop occupés à relinker avec une librairie tierce le plus vite possible pour prouver qu'ils sont plus réactifs que Core, pas le temps de préparer un texte de release (ou une politique de release) (ou une politique)  

[hdbuck]

ils espèrent peut etre que plus ils font de release, plus de gens vont suivre?

dans le meme genre de big blocks -> mass adoption, certainement.

[Meuh6879]

de toutes les façons, même s'ils ont 10% des noeuds actuellement ... faudrait encore qu'ils minent quelques choses : http://xtnodes.com/

[hdbuck]

Mince

Reddit ne trouve pas de blocks ?

Bwahaha ! (Rire sardo(ka)nique)

Peut être qu'avec une blockchain privée ?

TSIM POUM !

attend y'en a quand meme que ca a l'air de tenter:

Dude has completely it  Does he even realize what he is saying 

As if that's not what they were doing all along 

la sidechain liquid de Blockstream est en train de les tondre comme les moutons qu'ils sont.

http://www.coindesk.com/blockstream-commercial-sidechain-bitcoin-exchanges/

[Meuh6879]

Discussion autour du prochain 0.11D : https://github.com/bitcoinxt/bitcoinxt/commit/43b24545b3adcd348adfbdb0054f59b34e30c425

MikeHearn est dans la même ligne de ce que je pense aussi :

The min relay fee change breaks existing wallets, is unnecessary with a proper mempool limiter and IMHO should not have been done.
Again, we'll have to adopt it at some point for mempool consistency as otherwise version skew can assist people with double spending attacks. Being consistent ends up being more important than being correct But it's not urgent.

l'augmentation de la taxe sur le relayage des transactions à "faible coût" ... ne rêgle pas le problème de fond d'une accumulation du mempool dans le coeur du programme original.

[Meuh6879]

Petit discours d'un des développeurs de XT sur la position des développeurs du CORE.
https://medium.com/@octskyward/on-block-sizes-e047bc9f830

So in case you are waiting for Core to make a move, remember this: there cannot be any code added to a Core release without Wladimir being satisfied with it. And he believes that any change to the block size at all simply can’t happen “any time soon”.

What does Maxwell think about a block size increase? He contradicts himself regularly; claiming he wants an increase but simultaneously stating he thinks it shouldn’t happen. So far, Maxwell has clearly stated support for zero block size proposals. Judge people by their actions rather than their words: when Gavin and I asked him to put a specific counterproposal on the table he answered with the Lightning Network (and 1mb blocks forever).

[hdbuck]

Petit discours d'un des développeurs de XT sur la position des développeurs du CORE.
https://medium.com/@octskyward/on-block-sizes-e047bc9f830

So in case you are waiting for Core to make a move, remember this: there cannot be any code added to a Core release without Wladimir being satisfied with it. And he believes that any change to the block size at all simply can’t happen “any time soon”.

What does Maxwell think about a block size increase? He contradicts himself regularly; claiming he wants an increase but simultaneously stating he thinks it shouldn’t happen. So far, Maxwell has clearly stated support for zero block size proposals. Judge people by their actions rather than their words: when Gavin and I asked him to put a specific counterproposal on the table he answered with the Lightning Network (and 1mb blocks forever).

cretin.

[Meuh6879]

  mais non ... juste un peu "orienté", c'est tout (il vend sa vision, donc faut le comprendre aussi dans ce sens-là).

[hdbuck]

Sa vision, il peut se la mettre bien bien profond.

[Seldar]

Petit discours d'un des développeurs de XT sur la position des développeurs du CORE.
https://medium.com/@octskyward/on-block-sizes-e047bc9f830

So in case you are waiting for Core to make a move, remember this: there cannot be any code added to a Core release without Wladimir being satisfied with it. And he believes that any change to the block size at all simply can’t happen “any time soon”.

What does Maxwell think about a block size increase? He contradicts himself regularly; claiming he wants an increase but simultaneously stating he thinks it shouldn’t happen. So far, Maxwell has clearly stated support for zero block size proposals. Judge people by their actions rather than their words: when Gavin and I asked him to put a specific counterproposal on the table he answered with the Lightning Network (and 1mb blocks forever).

cretin.

Il fait seulement une constatation... Rien de rien n'a bouger depuis ces derniers temps...

[hdbuck]

Petit discours d'un des développeurs de XT sur la position des développeurs du CORE.
https://medium.com/@octskyward/on-block-sizes-e047bc9f830

So in case you are waiting for Core to make a move, remember this: there cannot be any code added to a Core release without Wladimir being satisfied with it. And he believes that any change to the block size at all simply can’t happen “any time soon”.

What does Maxwell think about a block size increase? He contradicts himself regularly; claiming he wants an increase but simultaneously stating he thinks it shouldn’t happen. So far, Maxwell has clearly stated support for zero block size proposals. Judge people by their actions rather than their words: when Gavin and I asked him to put a specific counterproposal on the table he answered with the Lightning Network (and 1mb blocks forever).

cretin.

Il fait seulement une constatation... Rien de rien n'a bouger depuis ces derniers temps...

idem au niveau de la taille moyenne des blocs..
pas d'augmentation, pas de masse adoption, et pas de consensus, si ce n'est celui du status quo.

et encore une fois.. ses constatations.. ou est-ce qu'il pourrait les mettre deja?

[Meuh6879]

Il souligne quand même que l'industrie du minage a suivi le chemin de voter par un procédé de génération des blocks en faveur du BIP100.

Et que l'équipe CORE, même si elle a "mise cette idée" dans la trajectoire ... n'est pas super chaude pour la mettre en oeuvre (ou la proposer).

On peut quand même saluer la constatation que le contrôle du CORE n'est pas en plus de main que le dévelopement du XT.

Ce qui pourra justement en surprendre plus d'un.

Alors, bon ... on peut aussi constater que la communauté des développeurs Bitcoin n'est pas très "à l'écoutes" des utilisateurs (ayant moi-même émis plusieurs suggestions quand à rendre Bitcoin XT plus ne adéquation avec un logiciel de P2P en terme de consommation de RAM et d'utilisation de DOWNLOAD et d'UPLOAD).

Mais je pense que comme c'est écrit, ça tournera dans la tête des développeurs assez tôt pour en tenir compte (la limitation du mempool est déjà une "très grande" avancée ... pour les full node privés).

[hdbuck]

la réponse de btcdrak: https://medium.com/@btcdrak/full-of-lies-and-desperation-of-someone-who-risked-his-entire-reputation-on-something-and-lost-and-6c206e68d0cf#.qiiljl3pa



Full of lies and desperation of someone who risked his entire reputation on something and lost; and now strops around like a petulant child.

Bitcoin Core has absolutely every intention of addressing block size in a way which will not compromise the security properties of Bitcoin. The issue is far more complex an nuances than Mike likes to present and scalability is a very complex issue for Bitcoin with block size being the least interesting property, but one which has the potential to change the security model and properties of what Bitcoin stands for.


A Short List of Lies:

1/ Having a set flag day does not take away miner voting, miners vote by upgrading. Additionally, having an expiry mechanism is as simple as, if by flag day we don’t have 95% adoption of the hardfork, abort. It’s a line of code.

2/ Mike claims miners will switch to BIP101 in December if Core doesn’t release a block size increase, this is a complete lie. Truth is miners have outright rejected any controversial change that does not include Bitcoin 3/ Core where the vast majority of technical experts reside. Huge exchanges have also stated they will not accept BIP101 outright. Clearly Mike is trying a game of poker here to frighten people.

3/ The Scaling Bitcoins conferences are not specifically about blocksize, but about how to scale bitcoin efficiently and without risk. Blocksize proposals were off the table at the first meeting in order to bring decorum to the debate and explain the many other aspects of scalability. The second meeting is all about specific scalability proposals which block size is a part of, but it is not the exclusive remit of the conference.

4/ The Liquid sidechain is not a competitor to Bitcoin, it will liquidity between exchanges and thus increase arbitrage. That in turn will help reduce price volatility since huge spreads wont be able to form exchanges (like right now there’s a 5–10% spread between Chinese and Western exchanges).

5/ Mike’s presentation of how things get merged in Bitcoin Core is completely wrong. Read https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md

6/ Bitcoin Core is not under the control of two people, but Wladamir does have the final say on what gets merged or not and has quite rightly said he wont merge controversial changes to consensus related code. That means, consensus changes, like CHECKLOCKTIMEVERIFY or blocksize must have wide technical consensus.


It’s clear Mike does not like the simple fact that the vast majority of technical experts in the Bitcoin field, contribute to Bitcoin Core and not other projects. Not only that, downstream users, rely on Bitcoin Core because they know it has the expertise and stability. XT has nothing, in the short time of it’s existence, hardly any changes have been merged, and what has been has deep technical flaws. Meanwhile Bitcoin Core has made literally hundreds of improvements.

Companies are not going to follow a renegade fork and in the end, they are going to trust the technical expertise of those who can provide long term support and have a proven track record in the field.


Mike, for the love of God, just stop with this nonsense. Stop being divisive and if you can’t, go do something constructive elsewhere. At least, stop telling lies.





donc comme je le disais, en plus detre un cretin, cest un cretin finis.


bon voyage 

[Meuh6879]

XT has nothing, in the short time of it’s existence, hardly any changes have been merged, and what has been has deep technical flaws. Meanwhile Bitcoin Core has made literally hundreds of improvements.

  il est marrant ... XT ne rajoute que 4-6 lignes en plus (qui sont hautement documentées alors que le CORE est une ruine à lire pour un profane) et à la même source que le CORE.

mais bon, je pense qu'il voulait descendre au même niveau que le développeur XT pour la réponse.