Bitcoin XT

[glub0x]

Les exchanges ça me parait bien aussi, mais en fait le facteur décisif pour les mineurs c'est les profits.
Pour garder des profits il leur faut des exchanges mais aussi des investisseurs sur ceux-ci, des gens qui vont transformer $ vers BTC ( des acheteurs). Et le moins possible de gens faisant l'inverse BTC->$

La raison pour laquelle les mineurs ne votent pas tout de suite pour des reward a 50 btc ++ et acceptent les halving est qu'ils savent que sinon ils perdraient leur profits.
Qu'est-ce que le profit pour un mineur?
Vaste sujet, instinctivement un mineur ne veut pas d'un btc a 0. Mais cherche-t-il un btc le plus haut possible? Pas certain plus btc est fort plus d'autres mineurs entre en jeux, plus ça devient concurrentiel ... Toujours-est-il que le mineur ferra tout pour éviter un effondrement des cours.

Concernant l'évolution de bitcoin on à déjà une chaine de décision qui suit plus ou moins ces règles
Devs->produit->btc release
Mineurs->censure->Devs
Mineurs-> cherche -> acheteurs (en passant par les exchange)

Qui sont les acheteurs, là c'est vraiment dur de se faire un idée, rare sont ceux qui publient et on ne peut même pas savoir si on à plutôt quelques gros ou beaucoup de petits...
On voit quand même une chaine se former, il existe des liens...
Il y a plein d'autres acteurs qui ont certainement tous uun pouvoir, ou mettre les VC par exemple ( celui qui dit dans la douche! ), ou se pose les start-ups, ont-elle toute le même interêt ect ect...

Donc tout ne repose pas sur les devs et ils ne sont pas les rois du palais bitcoin.
Que se passe-t-il donc dans notre petit scenario si les devs se mettaient tous d'accord pour qu'une de leur addresse recoive 1 000 bitcoins au prochain patch en modifiant le code de btc ( ils ont travaillé dur après tout) ?
Probablement les mineurs censureraient mais comme il faut des devs, un fork, pas si différend de celui-ci se produirait. Dans le cas ci-dessus, la fraude est tellement grosse que le consensus serrait immédiat, mais dans le cas d'une fraude plus discrète?

La methode du fork en elle-même n'est pas a bannir, on ne peut pas dire, ils sont mauvais car ils font un fork. On peut dire qu'ils ont tort, qu'ils sont corrompus eux-même mais ce systeme de fork est le seul moyen d'éjecter des devs corrompus, c'est une arme forte qui protège bitcoin.

[kcud_dab]

https://www.reddit.com/r/bitcoinxt/comments/3i1dra/psa_its_super_easy_to_manipulate_the_node_count_i/

Si on en croit ce topic, 2 personnes sont responsables de 460 nodes XT (dont la majorité avec PseudoNode -> https://github.com/basil00/PseudoNode ).

[btchip]

La methode du fork en elle-même n'est pas a bannir, on ne peut pas dire, ils sont mauvais car ils font un fork. On peut dire qu'ils ont tort, qu'ils sont corrompus eux-même mais ce systeme de fork est le seul moyen d'éjecter des devs corrompus, c'est une arme forte qui protège bitcoin.

euh, c'est très compliqué de déployer le fork, en fait, une fois que le système tourne. Donc à bannir, probablement pas, mais pas à encourager non plus, vu qu'elle est globalement inutilisable.

[Seccour]

https://www.reddit.com/r/bitcoinxt/comments/3i1dra/psa_its_super_easy_to_manipulate_the_node_count_i/

Si on en croit ce topic, 2 personnes sont responsables de 460 nodes XT (dont la majorité avec PseudoNode -> https://github.com/basil00/PseudoNode ).

Qu'ils sont cons. Ils donnent une fausse idée de "l'adoption" d'XT. Alalala...

[Meuh6879]

(dont la majorité avec PseudoNode -> https://github.com/basil00/PseudoNode ).

ça fait longtemps que ça existe ça ?
c'est pas ce que les mineurs chinois utilisaient avant le BIP66 ... ? (client SPV)

je vois bien à quoi peu servir le système ... mais c'est dommage qu'il y ait un mode STEALTH pour ne pas savoir que ce n'est pas un FULL BLOCKCHAIN.

la tentation va être grande pour certains de lacher le client officiel (même si ce pseudo node ne fait qu'encaisser les augmentations de clients voulant utiliser ponctuellement le réseau Bitcoin).

[anemol]

Auparavant, Bitcoin nous a offert "La Guerre des clones" (Litecoin ouvrant les hostilités)

Aujourd'hui, Bitcoin nous offre "La Guerre des nœuds".

Pas de panique, Bitcoin-Core reste pour le moment fièrement en tête: une belle tête de noeud!

Bitcoin était au bord du gouffre. Grâce à Mike et Gavin , Bitcoin fait un grand pas en avant! 

Blague à part et à contre-courant:
Y a t'il une réelle volonté de rendre le réseau Bitcoin plus efficace sans pour autant vouloir augmenter la taille des blocs?
Chercher à minimiser la taille des blocs permettra de mettre en place des mécanismes qui serviront à quantifier et cadrer leur augmentation.
Les blocs sont ils compressés? Si oui, n'est il pas possible de pousser encore plus loin la compression?
Si non, pourquoi ne le sont-ils pas?

[kcud_dab]

je vois bien à quoi peu servir le système ... mais c'est dommage qu'il y ait un mode STEALTH pour ne pas savoir que ce n'est pas un FULL BLOCKCHAIN.

Le problème c'est que les gens pourront mentir, il n'y a pas vraiment de moyen de vérifier qu'une node a bien la blockchain complète derrière...

Y a t'il une réelle volonté de rendre le réseau Bitcoin plus efficace sans pour autant vouloir augmenter la taille des blocs?

Oui, en explorant les solution offchain : lightning, sidechains etc..
Voir cette page -> https://en.bitcoin.it/wiki/Scalability
(il y a sur cette page une proposition de "compression" de la blockchain, mais c'est un peu plus compliqué que de simplement "zipper" la blockchain)

[anemol]

(il y a sur cette page une proposition de "compression" de la blockchain, mais c'est un peu plus compliqué que de simplement "zipper" la blockchain)

La compression/décompression en temps réel (stockage, transport et exploitation) dans nombre de domaines (télécommunication, flux audio et vidéo,etc). Je ne vois pas pourquoi le protocole Bitcoin y échapperait. C'est même primordiale pour le stockage et le trafic (bande passante).
Donc au lieu de querelles sur la taille de blocs, il vaudrait déjà que la priorité des développeurs soient de mettre un maximum d'informations dans la taille des blocs actuels. Après tout, il n'y a peut être pas les bons développeurs pour mener le projet?

[Meuh6879]

Non, le premier argument de la taille ... c'est le pruning mode.
en l'état, il est actuellement bâclé et inutile.

il faut creuser là-bas car le pruning et la blockchain ... ne sont que l'adaptation de freenet pour Bitcoin.

http://www.asksteved.com/stats/

Freenet fait 150 To.

[btchip]

Je ne vois pas pourquoi le protocole Bitcoin y échapperait.

parce qu'un bloc, c'est essentiellement des hashs, et des hashs, c'est essentiellement de l'entropie

[hdbuck]

... Après tout, il n'y a peut être pas les bons développeurs pour mener le projet?

tres profond ca. bravo.

[anemol]

parce qu'un bloc, c'est essentiellement des hashs, et des hashs, c'est essentiellement de l'entropie

Oui bien sûr mais au final il ne s'agit qu'une longue suite d'octets comme  n'importe quelle  information numérique (multimédia, etc). Peut être que les algorithmes actuels ne sont pas performants pour compresser ce type de données mais dans ce cas, la priorité des développeurs devrait être d'en créer des nouveaux (ou du moins chercher dans ce sens): rentabiliser et maximiser les ressources actuelles en innovant.

Le projet XT ne va pas dans ce sens, ne propose qu'une solution de facilité (poussée par des intérêts financiers il semblerait).

[glub0x]

parce qu'un bloc, c'est essentiellement des hashs, et des hashs, c'est essentiellement de l'entropie

Oui bien sûr mais au final il ne s'agit qu'une longue suite d'octets comme  n'importe quelle  information numérique (multimédia, etc). Peut être que les algorithmes actuels ne sont pas performants pour compresser ce type de données mais dans ce cas, la priorité des développeurs devrait être d'en créer des nouveaux (ou du moins chercher dans ce sens): rentabiliser et maximiser les ressources actuelles en innovant.

Le projet XT ne va pas dans ce sens, ne propose qu'une solution de facilité (poussée par des intérêts financiers il semblerait).

Comment sont représenté les transactions dans un block? 
Sut bitcoin wiki on trouve ça https://fr.bitcoin.it/wiki/Blocs.

Champ   Description   Taille
Taille du block   Nombre d'octets jusqu'à la fin du block                                                  4 bytes
En-tête du bloc   (Voir En-tête de bloc pour plus de détails)                                           80 octets
Nombre de transactions   Nombre entier positif (Voir les spécifications du protocole)   1 - 9 octets
transactions   Liste de toutes les transactions incluses dans le bloc                            Variable

La compréssion aurait lieu sur transaction et je pense qu'elle existe déjà. Quelqu'un sait il sous quel format? Un exemple de bloc bitcoin tel qu'il est dans la blockchain aujourd'hui?

[Seldar]

Le projet XT ne va pas dans ce sens, ne propose qu'une solution de facilité (poussée par des intérêts financiers il semblerait).

Tout comme les blockchains sont pourssées par d'autres intérêts financiers.
L'idée d'une compression est très bien pour réduire la taille de la chaine, mais les anti-augmentations ne seraient pas satisfaient pour autant, cela ne changerait pas le problème de l'augmentation du nombre de transactions avec la centralisation accrue qu'ils craignent.

Le stockage de la blockchaine par compression des blocs peut s'implanter sans changer le reste du protocole.

[glub0x]

Je pense qu'il fait allusion a la compréssion des blocks eux même.
Par exemple le niveau 0 de compréssion d'un block serrait

14HGyxrLkFYd61BXWR5wuga57u6UQqzyc9 envoie 2btc a 14KGyxrLkFYd61BXWR5wuga57u6UQqzyc9;
14LGyxrLkFYd61BXWR5wuga57u6UQqzyc9 envoie 0,6btc a 14IGyxrLkFYd61BXWR5wuga57u6UQqzyc9;
[...]
reward 25btc 14HGyxrLkFYd61BXWR5wuga57u6UQqzyc9
Hash : 000001ae ...
précédent hash : 00001bg ...


Mais c'est certainement pas sous cette forme là que sont transmise les transactions.
Changer la représentation de transaction demanderait de changer le protocole puisque les autres clients ne comprendrait pas ces nouveaux blocks
Honnêtement je pense qu'ils sont déjà optimisé a 100% car ça parit tellement basique...


[EDIT ] Après une petite recherche sur https://en.bitcoin.it/wiki/Transaction
La majorité des transactions est composé du hash sha256 de ou provient les bitcoins pour faire cette transaction (32bytes / 49 ) seul le script semble être potentiellement gros...
J'imagine que script est négligeable dans la taille des blocs aujourd'hui (a vérifier)
Donc en gros si on oublie script, et si on part du principe qu'on ne peut pas compresser un hash sha256 (comme dit plus haut c'est juste de l'information) et bien il n'y a pas grd chose a gagner du côté de la compression des blocs

[kcud_dab]

parce qu'un bloc, c'est essentiellement des hashs, et des hashs, c'est essentiellement de l'entropie

Oui bien sûr mais au final il ne s'agit qu'une longue suite d'octets comme  n'importe quelle  information numérique (multimédia, etc). Peut être que les algorithmes actuels ne sont pas performants pour compresser ce type de données mais dans ce cas, la priorité des développeurs devrait être d'en créer des nouveaux (ou du moins chercher dans ce sens): rentabiliser et maximiser les ressources actuelles en innovant.

Comme le fait remarquer btchip, bien que ce soit une suite d'octet c'est surtout des hash (public key, signatures etc..) et ce genre de données n'est pas facilement compressible sans perdre des informations... (ou alors le gain de compression est quasi null) ce qui poserait problème dans la blockchain.


@glub0x :
Voici un exemple de transaction bitcoin :

Code:

0100000001649b5c8d65eede3193283d71989fc3057ed059f6b7e7483cd4a01aaf76f7b83b000000006a473044022019ca1f355e2de9fc1e0cef01ed96bf315f7af96923f071f2334260ade67ebfb8022044e7fee2b321cca8889cdeb58ba488b130ae135ac5fe6eb0ccf049eb2bbae76a012102018a4aa8b98eb7f563246861d097e59f57f670dbf45f591090ffbd59e1c0c273ffffffff02008589dc000000001976a914cb5fa137907dd353aed4c7a880e48a8e14be3ea688ac07df2276040000001976a9143dec5af9b69a74d35112422e87278ebf9833c2a188ac00000000

En décodé, ça donne ça :

Code:

{ 
    "txid" : "6def3c435b4687d36ab8e1999c7a725f09fd190738fd537ca0c6e8b49ff0d7e7",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "3bb8f776af1aa0d43c48e7b7f659d07e05c39f98713d289331deee658d5c9b64",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "3044022019ca1f355e2de9fc1e0cef01ed96bf315f7af96923f071f2334260ade67ebfb8022044e7fee2b321cca8889cdeb58ba488b130ae135ac5fe6eb0ccf049eb2bbae76a01 02018a4aa8b98eb7f563246861d097e59f57f670dbf45f591090ffbd59e1c0c273",
                "hex" : "473044022019ca1f355e2de9fc1e0cef01ed96bf315f7af96923f071f2334260ade67ebfb8022044e7fee2b321cca8889cdeb58ba488b130ae135ac5fe6eb0ccf049eb2bbae76a012102018a4aa8b98eb7f563246861d097e59f57f670dbf45f591090ffbd59e1c0c273"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 37.00000000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 cb5fa137907dd353aed4c7a880e48a8e14be3ea6 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914cb5fa137907dd353aed4c7a880e48a8e14be3ea688ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1KYLjQybTWuikYJARtv8zT5bWnukXDTf1r"
                ]
            }
        },
        {
            "value" : 191.61865991,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 3dec5af9b69a74d35112422e87278ebf9833c2a1 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a9143dec5af9b69a74d35112422e87278ebf9833c2a188ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "16eRMxjLUwEEedwF7DUwkw7z365MRHrzzd"
                ]
            }
        }
    ]
}

[glub0x]

Quel est la fonction qui permet d'encoder ces transactions ?
De toute façon vu la tête de la version codé, il n'y a pas grd chose a chercher en optimisation...

[kcud_dab]

https://en.bitcoin.it/wiki/Transaction

[anemol]

Je pense qu'il fait allusion a la compréssion des blocks eux même.

Je vise bien la chaîne de blocs en elle-même (donc les blocs mais surtout le contenant).

La compression en temps réel (sans perte de données bien entendu) est omniprésente. Votre matériel informatique est déjà équipé pour le faire avec des flux multimédias (lecture DVD Divx,etc)

Rien n'empêche le cas échéant de développer et commercialiser du matériel adapté en créant ainsi un nouveau marché, de nouveaux acteurs.

Changer la représentation de transaction demanderait de changer le protocole puisque les autres clients ne comprendrait pas ces nouveaux blocks

Si l'équipe officielle de développeurs annonçait qu'ils ont fait évoluer le protocole Bitcoin grâce à la création et au déploiement d'un 'codec' qui  permet un gain de 10% et qu'ils ont bon espoir d'améliorer ses performances dans le futur, est ce que cela serait réellement dérangeant de rompre avec "l'ancien format" quitte à mettre à jour son client?

Comme le fait remarquer btchip, bien que ce soit une suite d'octet c'est surtout des hash (public key, signatures etc..) et ce genre de données n'est pas facilement compressible sans perdre des informations... (ou alors le gain de compression est quasi null) ce qui poserait problème dans la blockchain.

J'ai du mal à croire que sur des milliers de transactions à mettre dans un bloc, il n'y ait pas "des motifs" (patterns) qui se répètent et par la même, se compressent.

[mably]

Quand je me demande si une évolution est bonne,  je me demande si elle fonctionnerait en mode dégradé. En transmettant l'info par radio ou d'autres systèmes.

Si bitcoin ne peut plus fonctionner en mode dégradé,  je me dis que c'est trop dangereux.

D'où l'hésitation de certains à augmenter la taille des blocs de manière irréfléchie...