Bitcoin XT - page 7. | Bitcointalksearch.org

btchip

hero member

Activity: 623

Merit: 500

CTO, Ledger

Quote from: glub0x

On est donc d'accord, si tu ressentais l'urgence que je ressens, peut être adopterai tu ma posture et défendrai cette méthode certe violente mais nécessaire.

ah ben si il y avait une raison, oui.

Quote from: glub0x

A mon sens la corruption des devs core est évidente et le projet lui même se retrouve entaché.

corrompus comment ?

Quote from: glub0x

Je comprends que d'autres pour diverses raison ne sentent pas cette urgence mais aucun de leurs arguments ne m'a pour l'instant fait bouger.

dans ce cas je vais changer la question. Pourquoi y a t'il une urgence ?

Des transactions telles que décrites dans le whitepaper sont toujours tout à fait possible. Meme à 0 fees. Où est le problème ?

Quote from: glub0x

Et l'argument de "la methode utilisé n'est pas la bonne" me fait doucement rire car si il y en a un que je n'accepte pas, c'est celui là.

Pourquoi ? Si il n'y a pas d'urgence, c'est pourtant assez cohérent comme argument.

glub0x

legendary

Activity: 892

Merit: 1013

Quote from: btchip on August 24, 2015, 02:40:53 PM

dans le cas présent il n'y a strictement aucune raison de faire appel à ça - il n'y a pas d'urgence, et les dèvs actuels ont démontré leur maitrise du système en évitant tous les écueils.

On est donc d'accord, si tu ressentais l'urgence que je ressens, peut être adopterai tu ma posture et défendrai cette méthode certe violente mais nécessaire.

Pour moi il y a urgence a remettre bitcoin sur les rails qui m'ont fait l'adopter il y a 3 ans. Ce débat j'ai l'impréssion de l'avoir lu régulierement depuis au moins 2 ans sans changement...
Pour citer l'introduction de satoshi qui fait maintenant ma signature

Quote

1. Introduction
Commerce on the Internet has come to rely almost exclusively on financial institutions serving as
trusted third parties to process electronic payments. While the system works well enough for
most transactions, it still suffers from the inherent weaknesses of the trust based model.
Completely non-reversible transactions are not really possible, since financial institutions cannot
avoid mediating disputes. The cost of mediation increases transaction costs, limiting the
minimum practical transaction size and cutting off the possibility for small casual transactions,
and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible
services. With the possibility of reversal, the need for trust spreads. Merchants must
be wary of their customers, hassling them for more information than they would otherwise need.
A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties
can be avoided in person by using physical currency, but no mechanism exists to make payments
over a communications channel without a trusted party

https://bitcoin.org/bitcoin.pdf

A mon sens la corruption des devs core est évidente et le projet lui même se retrouve entaché. Je comprends que d'autres pour diverses raison ne sentent pas cette urgence mais aucun de leurs arguments ne m'a pour l'instant fait bouger.
Et l'argument de "la methode utilisé n'est pas la bonne" me fait doucement rire car si il y en a un que je n'accepte pas, c'est celui là.

Au passage je me fiche pas mal du prix du bitcoin, c'est certainement pas ça qui va le faire descendre à long terme au contraire l'issue de ce fork va clarifier les choses ce qui serra tres bon pour Btc

hdbuck

legendary

Activity: 1260

Merit: 1002

Quote from: btchip on August 24, 2015, 02:40:53 PM

Quote from: glub0x on August 24, 2015, 12:09:03 PM

Comme je l'ai montré plus haut, si dev Core était complètement corrompus ( genre au prochain patch ils s'octroient 10000btc) la manœuvre employé pour les virer aurait été la même que celle employé par gavin, dans ce cas le même art et les mêmes manières serrait louées.
Empêcher les fork par principe, c'est donner tous les pouvoirs aux devs...

pour moi, ils ne doivent etre utilisés qu'en cas d'extreme urgence, et quand aucune autre solution n'a fonctionné, comme tu le dis. Un fork affaiblit considérablement l'ecosystème, un peu avant le fork (incertitude des acteurs économiques et des observateurs) et énormément pendant le fork (le temps que le système se stabilise).

dans le cas présent il n'y a strictement aucune raison de faire appel à ça - il n'y a pas d'urgence, et les dèvs actuels ont démontré leur maitrise du système en évitant tous les écueils.

pour que meme le dev ~~d'un~~ *du* wallet nous dise ca.. ils sont vraiment tombé sur la tete. ^^

bitcoin est quand meme en train de prendre bien cher la. Sad

j'espere qu'il en sortira renforcé.

btchip

hero member

Activity: 623

Merit: 500

CTO, Ledger

Quote from: glub0x on August 24, 2015, 12:09:03 PM

Comme je l'ai montré plus haut, si dev Core était complètement corrompus ( genre au prochain patch ils s'octroient 10000btc) la manœuvre employé pour les virer aurait été la même que celle employé par gavin, dans ce cas le même art et les mêmes manières serrait louées.
Empêcher les fork par principe, c'est donner tous les pouvoirs aux devs...

pour moi, ils ne doivent etre utilisés qu'en cas d'extreme urgence, et quand aucune autre solution n'a fonctionné, comme tu le dis. Un fork affaiblit considérablement l'ecosystème, un peu avant le fork (incertitude des acteurs économiques et des observateurs) et énormément pendant le fork (le temps que le système se stabilise).

dans le cas présent il n'y a strictement aucune raison de faire appel à ça - il n'y a pas d'urgence, et les dèvs actuels ont démontré leur maitrise du système en évitant tous les écueils.

glub0x

legendary

Activity: 892

Merit: 1013

Quote from: anemol on August 24, 2015, 09:12:43 AM

Le projet Xt ressemble à un projet dissident à Bitcoin et qui tente de passer en coup de force (déploiement des nœuds, etc) Forcement, c'est plutôt contraire à l'idée du logiciel qui repose plutôt sur le concept du consensus. Même si les utilisateurs actuels au fond ne sont pas opposés à des modifications même majeures, c'est l'art et la manière qui ne passent pas.

La limite entre un un projet dissident et un projet salvateur est floue dépend du point de vue et surtout du vainqueur. Si Xt avait remporter une forme de super majorité (et pas de consensus, ce terme est utilisé a tort et a travers), on aurait dit a l'inverse que Core est dissident.

Comme je l'ai montré plus haut, si dev Core était complètement corrompus ( genre au prochain patch ils s'octroient 10000btc) la manœuvre employé pour les virer aurait été la même que celle employé par gavin, dans ce cas le même art et les mêmes manières serrait louées.
Empêcher les fork par principe, c'est donner tous les pouvoirs aux devs...

sangoku

hero member

Activity: 616

Merit: 501

Si tu as pigé le principe ;-)

https://www.youtube.com/watch?v=4U6H96VU-Vg

kcud_dab

legendary

Activity: 1652

Merit: 1002

Bitcoin enthusiast!

Quote from: superresistant on August 24, 2015, 10:38:43 AM

Quote from: kcud_dab on August 24, 2015, 09:33:54 AM

Quote from: anemol on August 24, 2015, 04:56:58 AM

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.

Ce serait négligeable car les données de la blockchain sont difficilement compressibles encor une fois : c'est pratiquement que des empreintes / signatures..
Ou alors faudrait une blockchain basée sur πfs -> https://github.com/philipl/pifs :p

Tu nous explique le principe ?
Je connais pas.

De πfs ? C'est plus une blague qu'autre chose même si mathématiquement ça fonctionne.

Le principe est simple, le chiffre π a une infinité de décimales et toute suite de chiffre existe dans les décimales de π (à confition d'aller assez loin).
À partir de là, il suffit de représenter des données sous forme de chiffres et de trouver à quel index cette suite commence dans les décimales de Pi.

Ex, je veux t'envoyer la séquence : "265359"
Soit je t'envoie les données, soit je te dis que c'est "5,6" dans le chiffre π (en gros : 6 caractères à partir à la 5ime position dans les décimale de pi).

Si tu connais le chiffre π -> 3,141 592 653 589 793 , tu peux retrouver la séquence à partir de 2 informations : la position dans les décimales et la taille de la séquence , et tu peux stocker n'importe quelle information avec 2 paramètres (index et taille de la séquence)

UnderZob

newbie

Activity: 39

Merit: 0

http://blog.blockchain.com/2015/08/24/industry-endorses-bigger-blocks-and-bip101/

BitPay.com, Blockchain.info, Circle.com, Kncminer.com, Bitnet.io, Xapo.com, Bitgo.com

yassin54

legendary

Activity: 1540

Merit: 1000

http://www.newsbtc.com/2015/08/23/bitpay-supports-increase-in-bitcoin-block-size-limit/

superresistant

legendary

Activity: 2156

Merit: 1131

Quote from: kcud_dab on August 24, 2015, 09:33:54 AM

Quote from: anemol on August 24, 2015, 04:56:58 AM

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.

Ce serait négligeable car les données de la blockchain sont difficilement compressibles encor une fois : c'est pratiquement que des empreintes / signatures..
Ou alors faudrait une blockchain basée sur πfs -> https://github.com/philipl/pifs :p

Tu nous explique le principe ?
Je connais pas.

kcud_dab

legendary

Activity: 1652

Merit: 1002

Bitcoin enthusiast!

Quote from: anemol on August 24, 2015, 04:56:58 AM

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.

Ce serait négligeable car les données de la blockchain sont difficilement compressibles encor une fois : c'est pratiquement que des empreintes / signatures..
Ou alors faudrait une blockchain basée sur πfs -> https://github.com/philipl/pifs :p

anemol

hero member

Activity: 800

Merit: 500

Quote from: glub0x on August 24, 2015, 06:38:14 AM

Compresser la blockchain ne relève pas vraiment du problème soulevé par xt.
Même si on divisait par 1000 la taille de la blockchain grâce a une super compression, 98% des gens contre XT le seront toujours.

Au moins il y aurait une intention, une volonté de ne pas gaspiller la bande passante, une "gestion intelligente" des ressources, quitte à augmenter effectivement la taille des blocs graduellement, chiffres et études à l'appui (ce qui manque cruellement aujourd'hui). Mais de toutes manières, mes propos étaient à contre-courant comme je le disais en entrée.

Il existe d'autres possibilités pour libérer et désengorger le réseau, l'augmentation systématique de la taille des blocs n'en est qu'une parmi d'autres.

Quote from: glub0x on August 24, 2015, 06:38:14 AM

Les craintes des anti xt sont plus sur la bande passante, la façon dont à été publié XT, la centralisation ect

Le projet Xt ressemble à un projet dissident à Bitcoin et qui tente de passer en coup de force (déploiement des nœuds, etc) Forcement, c'est plutôt contraire à l'idée du logiciel qui repose plutôt sur le concept du consensus. Même si les utilisateurs actuels au fond ne sont pas opposés à des modifications même majeures, c'est l'art et la manière qui ne passent pas.

Au delà d'effaroucher les nouveaux arrivants; de nourrir la presse; de donner des munitions inespérées aux détracteurs du Bitcoin, c'est surtout le trouble occasionné chez les utilisateurs (ceux qui utilisent déjà Bitcoin à petite ou grande échelle) qui pourrait être réellement préoccupante. Ce n'est pas parce que Bitcoin a déjà affronté de belles vagues avec succès auparavant qu'il pourra se remettre de celle-ci. Depuis, il y a quelques projets qui ont vu le jour et qui tiennent le cap tout également.

L'avantage de la situation est que la presse parle du Bitcoin malgré elle et sensibilise les gens (que les gens s'interrogent sur le système monétaire actuel est positif).

glub0x

legendary

Activity: 892

Merit: 1013

Quote

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

Compresser la blockchain ne relève pas vraiment du problème soulevé par xt.
Même si on divisait par 1000 la taille de la blockchain grâce a une super compression, 98% des gens contre XT le seront toujours.
Les craintes des anti xt sont plus sur la bande passante, la façon dont à été publié XT, la centralisation ect

mably

sr. member

Activity: 381

Merit: 266

Quote from: ?? on ??

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

anemol

hero member

Activity: 800

Merit: 500

Quote from: glub0x on August 24, 2015, 03:44:09 AM

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.

Quote from: glub0x on August 24, 2015, 03:44:09 AM

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?

Quote from: kcud_dab on August 24, 2015, 04:09:41 AM

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.

kcud_dab

legendary

Activity: 1652

Merit: 1002

Bitcoin enthusiast!

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

glub0x

legendary

Activity: 892

Merit: 1013

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

legendary

Activity: 1652

Merit: 1002

Bitcoin enthusiast!

Quote from: anemol on August 24, 2015, 03:06:37 AM

Quote from: btchip on August 23, 2015, 05:26:01 PM

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

legendary

Activity: 892

Merit: 1013

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

Seldar

sr. member

Activity: 333

Merit: 250

Quote from: anemol on August 24, 2015, 03:06:37 AM

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.

Topic: Bitcoin XT - page 7. (Read 27428 times)