Topic: nombre de transactions par bloc, frais de transaction et autres concepts... (Read 437 times)

N'hésite pas si tu as des questions, en plus le deuxième post est un peu plus complexe ^^

Le poids d'une transaction
Pour comprendre le poids d'une transaction il faut connaître sa structure en détail, la voici :
version : 4 octets
nb_inputs : de 1 à 4 octets
Pour chaque input :
     l'id de la transaction contenant l'output que dépense cet input : 32 octets
     index : 4 octets
     taille_script : 1 à 4 octets
     script : octets
     sequence : 4 octets
nb_outputs : 1 à 4 octets
Pour chaque output :
     valeur (en satoshis) : 8 octets
     taille_script : 1 à 4 octets
     script : octets
locktime : 4 octets

Donc la taille minimale d'une transaction P2PKH est d'environ (après un test)

Code:

4 + 1 + 32 + 4 + 1 + 106 + 4 + 1 + 8 + 1 + 25 + 4 = 191 octets

Il me semble que la taille moyenne des transactions est actuellement de ~550 octets.
La taille de la transaction ne dépend donc pas d'une équation mais du nombre d'inputs et d'outputs présents dans celle-ci (et surtout du nombre d'inputs dont le script est plus grand) : Si vous avez reçu pleins de petits paiements pour en faire un gros vous allez utiliser plein de petits inputs pour en créer un gros et c'est là que les fees vont être élevées.


Segwit
Alors sans rentrer dans les détails, car Segwit a changé beaucoup de choses, pour ce qui nous intéresse : Segwit est un soft fork. Les anciens clients peuvent recevoir des blocs avec des transactions Segwit (je le dis au début mais c'est important). Segwit est un acronyme anglais pour "Segregated Witness" qui signifie littéralement "Témoin séparé", le "témoin" dans une transaction est la signature : une transaction Segwit a donc une nouvelle forme et une signature à part des inputs.En plus de ça le consensus sur la taille des blocs a été modifié et passé de :

Code:

static const unsigned int MAX_BLOCK_SIZE = 1000000;

à

Code:

static const unsigned int MAX_BLOCK_WEIGHT = 4000000;

Avec

Code:

BLOCK_WEIGHT = 4 * NON_SEGWIT_DATA + 1 * SEGWIT_DATA

On a pu comme ça augmenter la taille des blocs sans pour autant qu'ils soient rejetés par les anciens clients, qui ne voient pas les SEGWIT_DATA et donc pour un client non Segwit compatible ça donne :

Code:

BLOCK_WEIGHT = 4 * NON_SEGWIT_DATA + 1 * SEGWIT_DATA;
BLOCK_WEIGHT = 4 * NON_SEGWIT_DATA + 0 ;// Un ancien client ne telecharge pas les Segwit datas
MAX_BLOCK_SIZE = MAX_BLOCK_WEIGHT / 4 = 1000000; // On retombe sur nos pattes :)

tout n'est pas facilement compréhensible, mais j'attends la suite avec impatience...

Salut,

je suis venu voir la board française depuis peu et je suis tombé sur ton post. Je me motive pour répondre à tes interrogations, et corriger certaines choses.

Pour commencer et essayer d'être le plus clair possible sans que ça ne nécessite des notions techniques trop avancées je vais détailler la structure d'une transaction "de base" plutôt que de te quote et de répondre à chaque chose.
Pour détailler une transaction il faut comprendre son rôle. Une transaction débloque des coins pour les rebloquer ensuite (ou pas mais on va rester dans la base), c'est ce dont tu parlais vagument avec les entrées/sorties. Une transaction comporte des metadonnées (des données qui en décrivent d'autres, typiquement un timestamp) et une liste d'"inputs" accompagnée d'une liste d'"outputs". Les inputs sont des coins qui ont été bloqués et qui peuvent être débloqués sous certaines conditions qui sont déclarées avec Script, le langage de script utilisé sur Bitcoin. Quand on dit qu'un node Bitcoin "vérifie les transactions" c'est que, entres autres, le logiciel (typiquement bitcoin-core mais il y a d'autres implems) vérifie que la transaction remplisse les conditions données par les inputs, lui donnant la possibilité de les dépenser.
Dépenser un input, c'est créer un output dans cette transaction qui va lui-même donner des conditions sous lesquels il débloquera les coins. Il peut donner les mêmes conditions que celles données dans l'input, ce qui revient à se renvoyer des coins à soi-même, ou en donner d'autres. Les input des transactions sont tous des outputs d'une transaction précédente, il n'y a qu'un seul type de transaction qui est validée même si son input ne provient pas d'un output d'une autre transaction (ce qui revient à créer des coins depuis rien) : la coinbase transaction. Il y a une seule coinbase transaction par bloc qui comporte un (ou plusieurs) output(s) et un seul input dont on note la provenance (l'id de la tx précédente) 0000000000000000000000000.

Et quelles sont ces conditions ?
Typiquement, les conditions de débloquage sont (en français) "c'est ok je débloque si tu me donne une clef tel que son hash est et une signature qui provient de cette clef" (en Script) "OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG".
La signification de cette condition
"Me donner une clef tel que son hash est " == Me donner la clef publique qui correspond à l'addresse : une addresse Bitcoin est le hash d'une clef publique
"Me donner une signature qui provient de cette clef" == Me prouver que tu as la clef privée correspondant à la clef publique (et donc à l'adresse, qui n'est que son hash)

C'est donc ce qu'il se passe réellement derrière l'abastraction "envoyer des bitcoins à une adresse". La block chain ne contient pas les adresses et leur balance, que des transactions (c'est bien pour ça que "technologie blockchain" ça ne veut rien dire, la technologie c'est le protocole Bitcoin pas la base de donnée). La balance d'une adresse est calculée en additionant la valeur de tous les outputs de toutes les transactions impliquant cette adresse (le hash d'une clef publique se trouve dans le script donc dans l'output, on peut donc le faire "facilement") qui n'ont pas encore été débloqués (=dépensés).

Ce type de transaction est appelé Pay 2 Public Key Hash (P2PKH) et ce n'est pas le seul, mais le plus basique et surtout celui qui permet de comprendre le fonctionnement. Comme ça commence à être long je reviendrai expliquer Segwit et la taille d'une transaction dès que j'ai fini ce que j'avais à faire avant de tomber sur ce post ^^. (j'espère que c'était clair dites moi si il y a des trucs qui sont mals dits/expliqués)

exact, j'avais lu trop vite.
je corrige donc :
le poids en octets varie donc de "179 entrées + 34 sorties + 10" à "181 entrées + 34 sorties + 10"

sans vouloir être trop affirmatif, j'ai l'impression que c'était avant, en legacy donc...

j'ai encore d'autre posts à rédiger ici dans ce sujet, je reprendrai dès que j'aurai une minute. pour l'instant , je dois retrouver un titre de propriété pour que le notaire finalise un compromis de vente. je l'avais dans la main il y a quelques semaines, mais je n'arrive plus à le retrouver...

C'est +/- entrées et pas +/- 10 entrées.

Sinon super post, merci !

EDIT : les données de ton post c'est en segwit ou en legacy ?

 

---

ça veut dire que WU c'est mieux ! ??   

---

En tt cas je peut te dire que pour (le passage par deux sorties obligatoires) le client portefeuille qui génère une nouvelle adresse pour y mettre la monnaie, ça n'existait pas au début, j'envoyai des bitcoins et le reste restait sur la même addresse. Un peut à la manière de Bitcoincash aujourd'hui

j'ai mis longtemps à trouver l'équation mathématique permettant de calculer théoriquement soi même dans son coin le poids d'une transaction.
il y a plusieurs mois, j'avais trouvé, et je ne sais plus où, une équation que j'avais noté :
le poids en octets = 180 entrées + 34 sorties + 10
on peut donc calculer que pour une transaction classique avec 1 entrée et 2 sorties, on a une transaction qui pèse 258 octets. quand on connait les frais en satoshi par octet, on arrive alors à calculer en dollar ou en euros un ordre de grandeur du montant de la transaction.
on comprend que les transactions qui nécessitent 2 entrées et 2 sorties pèsent beaucoup plus lourds : tout de suite 438 octets...
on comprend qu'ajouter une sortie supplémentaire ne coûte pas grand chose et permet même en cas de besoin de rendre moins coûteuse la transaction.

par exemple, si on doit payer plusieurs personnes, si on les paye chacune à leur tour, on paye 258 octets pour chacun.
si on arrive à en payer 2 en une seule opération, on paye 292 octets pour les deux, c'est à dire 146 octets pour chacun.
si on arrive à en payer 3 en une seule opération, on paye 326 octets pour les trois, c'est à dire 109 octets pour chacun.
si on arrive à en payer 4 en une seule opération, on paye 360 octets pour les quatre, c'est à dire 90 octets pour chacun.
si on arrive à en payer 10 en une seule opération, on paye 564 octets pour les deux, c'est à dire 56 octets pour chacun.
si on arrive à en payer 20 en une seule opération, on paye 904 octets pour les deux, c'est à dire 45 octets pour chacun...

on comprend que les échanges sont avantagés à ce petit jeu, ils ont tout intérêt à construire de grosses transactions, c'est beaucoup plus économique.
ici, je me dis que j'aimerais bien aussi pouvoir et savoir grouper mes paiements en une seule transaction (si quelqu'un sait comment faire avec le bitcoin core, il est le bienvenu).
on comprend enfin que si les échanges font de grosses transactions de 1 000 ou 2 000 octets, la moyenne du poids des transactions analysée dans le premier post de cette file tend à grossir de plus en plus et que donc le nombre de transactions par seconde va encore diminuer. on n'a jamais eu 7 transactions par seconde, ni même 6, ni même 5; si la tendance se poursuit, on ne verra plus non plus dans le futur les 4 transactions par seconde sur le réseau principal (c'est à dire sans prendre en compte le réseau foudre) et les 3 transactions par seconde ne seront plus qu'un souvenir également.

dernier problème encore, en voulant vérifier si l'équation "180 entrées + 34 sorties + 10 = le poids en octets" est correcte, ben en fait, ça marche pas, cette équation est fausse...
j'ai trouvé récemment une équation "un peu plus floue" dans laquelle je ne comprends pas tout, elle est ici : https://www.kryptomole.fr/?p=2094 et elle modifie l'équation en introduisant une incertitude à mon niveau présent de compréhension :
le poids en octets = 180 entrées + 34 sorties + 10 +/- 10 entrées
en fait, l'équation varierait de "170 entrées + 34 sorties +10" à "190 entrées + 34 sorties + 10"...

nouvelles questions à ce stade : en fonction de quoi varie ce coefficient de +/- 10 sur les entrées ?
le segwit était sensé permettre plus de transactions dans un bloc, est ce que ça a un rapport avec ce plus ou moins ?
originellement, les adresses bitcoins avant le segwit commençaient toutes par "1", aujourd'hui, les adresses compatibles segwit commencent par "3", voilà une piste à explorer, ce que je ferai dans un futur proche. mais pas maintenant, car demain, je me lève à 08 heures et je pars une semaine en vacances.

j'ai donc cherché à savoir combien pèse une transaction, depuis plus d'un an, en fait, pas loin de deux ans.
j'ai plusieurs fois essayé de tirer les vers du nez à meuh, mais il était peu loquace sur ce point.
j'ai fini par comprendre peu à peu que le poids d'une transaction dépend du nombre d'entrées et du nombre de sorties. les entrées et les sorties sont des adresses bitcoin sur lesquelles il y a un certain nombre de bitcoins...
combien d'entrées ? combien de sorties ? combien pèse une entrée ? combien pèse une sortie ?
on cherche ici à calculer le nombre d'octets d'une transaction.
le but final est de calculer le coût d'une transaction, la mienne, celle que je vais faire là, maintenant, et pas le prix prix moyen d'une transaction moyenne d'aujourd'hui. ainsi, par exemple, pour reprendre la date du 14/12/17 avec ses 490 000 transactions, ce jour là, les frais de transaction de la journée s'élevaient à 10 750 000 dollars, soit une moyenne de 22 dollars par transaction ( https://www.blockchain.com/fr/charts/transaction-fees-usd ). les frais maximaux sont montés jusqu'à 60 dollars par transaction en moyenne le 22/12/17...

de quoi s'étrangler, surtout quand meuh nous narguait "j'ai passé hier une transaction à 5 dollars", "comment as tu fait ?", "apprenez à utiliser les outils qui existent", "combien pèse une transaction ?", pas de réponse...

une transaction consiste à envoyer un certain nombre de bitcoins d'un endroit à un autre. il peut avoir une ou plusieurs entrées et une ou plusieurs sorties. combien d'entrées ? combien de sorties ? ça dépend...
prenons des exemples pour expliquer les différents cas possibles.
on a sur une adresse1 https://www.blockchain.com/btc/address/1G3oAfdgcgGjMkBXxQoWi9h29AYMRQZKsc 0,02413308 btc et on veut envoyer la totalité vers une adresse2 https://www.blockchain.com/btc/address/145pbkq8kct716JrnAECbjbDvcZqFak4hT les frais de 0,00002712 étant à prélever sur ces 0.02413308 btc, il y a dans ce cas une entrée qui est adresse1 et une sortie qui est adresse2. sauf erreur de compréhension de ma part, les frais ne sont pas comptés comme une sortie https://www.blockchain.com/btc/tree/353216753

autre exemple, on a sur une adresse https://www.blockchain.com/btc/address/14UEoMLBnTESEgPByHxaUp1m7WGjAEyppD 1,1211701 btc et on veut envoyer 0,65 btc vers une adresse https://www.blockchain.com/btc/address/36tEyBPryNHrD4RwYhiEdvF6o5Rmfa1rGi , le logiciel va vider la totalité de l'adresse de départ, va envoyer 0,65 btc vers l'adresse de réception qu'on a choisi, va payer les frais nécessaires de 0,00006780 btc, va créer automatiquement une nouvelle adresse https://www.blockchain.com/btc/address/12nXRU5kFxwViSJd7QQMwe887PgEzbKVUY qui nous appartiendra pour y verser la "monnaie" de notre envoi, soit 0,4711023. il y a dans ce cas une entrée et deux sorties https://www.blockchain.com/btc/tree/353163447

autre exemple, on veut envoyer 3 btc vers une adresse mais on n'a pas une telle somme sur aucune adresse que l'on possède, le logiciel va alors regrouper plusieurs adresses pour atteindre cette somme, par exemple 2 adresses qui possèdent chacune 2,5 btc, la somme fait 5 btc, on est capable d'envoyer les 3 btc, de payer les frais de 0,0001256 btc et de déposer la monnaie de 1,9998744 sur une nouvelle adresse. l'exemple pratique est ici : https://www.blockchain.com/btc/tx/a9bb9b847b1170942e98c2bff5c70e338e16cd7c79595e64d5fed77e35942776 (la représentation graphique des arbres est uniquement descendante, il faut analyser la page telle qu'elle est présentée). il y a dans ce cas 2 entrées et 2 sorties.

il n'y a pas vraiment de limite au concept, il peut y avoir 10 ou 20 ou 50 entrées, et 10, 20 ou 50 sorties.
typiquement, quelqu'un qui se serait amusé avec les robinets à bitcoins pendant 1 ou 2 ans, qui aurait retiré ses satoshis une fois par mois, le jour où il veut envoyer 0,001 btc pour se payer une bière au https://www.timeout.fr/paris/bar/sofs-bar il construira une transactions avec 20 entrées et 2 sorties.
à l'inverse, un échange qui paye ses clients qui veulent retirer leurs fonds, il pourra avoir des dizaines de sorties https://www.blockchain.com/btc/tx/e50f6b8a5e4f68a6eab3e3bd682bf93b583901de9f0a6fa7c66cc37b766b1bed

à ce stade là, j'ai compris à peu près comment se construisent les transactions, en précisant que le logiciel est intelligent et qu'il essaie de minimiser le nombre d'entrées afin d'alléger le plus possible le poids en octets de la transaction.
il reste encore à trouver le poids en octets des entrées, des sorties...

je vais ici dans cette file écrire ce que je comprends actuellement de bitcoin. c'est une sorte de cahier de brouillon, que je complèterai quand j'aurai le temps, un endroit où je mettrai à la vue de tout le monde le fruit de mes recherches, les points que j'aurais aimé discuter et comprendre avec meuh... (tout un chacun peut intervenir dans cette file, ça peut aussi me donner d'autres idées ou me permettre de comprendre plus vite les choses. j'ai néanmoins modéré cette file, c'est une première pour moi, on verra bien si je ferai usage de cette modération).

mise à l'échelle (scalabilité) : il est dit sur https://fr.wikipedia.org/wiki/Bitcoin#Évolutivité_du_protocole que les blocs limités à 1 mo a été établie pour limiter le nombre de transactions à 7 par seconde...
ce qui me parait bizarre, c'est qu'on a connu des blocs complètement saturés à 1 mo (*) d'octobre 2017 à mars 2018 ( https://www.blockchain.com/fr/charts/avg-block-size ) mais on n'a jamais eu les 7 transactions par seconde, ce qui équivaut à 605 000 transactions par jour, voir un peu plus si l'on prend en compte l'augmentation du taux de hashs par seconde, on pourrait même voir théoriquement 700 000 transactions par jour les jours où il sort un bloc toutes les 8 minutes 30 au lieu de 10 minutes. or, on n'a jamais dépassé 490 000 transactions en un jour ( https://www.blockchain.com/fr/charts/n-transactions ), c'était le 14/12/17.

* on remarque que blockchain.com reporte des blocs qui peuvent être plus lourds que 1 mo, c'est à cause du segwit (signatures séparées), en effet, les données liées aux signatures des transactions utilisant le protocole segwit sont stockées quelque part "ailleurs" en dehors de la chaîne de blocs, mais le site les reporte quand même. ici, je ne comprends pas tout, c'est un peu confus...

la question que je me pose est pourquoi on n'a jamais eu plus de 500 000 transactions en un jour ?
je reprends les historiques et je construis le tableau ci dessous, je procède par sondage, début janvier et début juillet, c'est la première colonne.
la deuxième colonne vient de https://www.blockchain.com/fr/charts/avg-block-size?timespan=all
la troisième colonne vient de https://www.blockchain.com/fr/charts/n-transactions?timespan=all
la quatrième colonne est obtenue en faisant une simple division de la deuxième colonne par la troisième, en supposant que le temps de bloc est effectivement de 10 minutes, c'est à dire sans corriger par le temps réel (si je l'avais fait, les résultats seraient encore pires).
la dernière colonne représente le nombre maximum de transactions par seconde que l'on aurait réellement pu atteindre si le bloc avait été rempli à 100 %, c'est une fonction inverse de la quatrième colonne.


date       remplissage   transactions   octet par      transactions
              blocs en Mo      par jour     transaction   par seconde
                                                                        maximum
            
01/07/11    0,025           9 454              399           4,4
01/01/12    0,020           5 809              520           3,4
01/07/12    0,062         25 272              370           4,7
01/01/13    0,110         38 986              426           4,1
01/07/13    0,103         34 053              457           3,8
01/01/14    0,103         41 476              375           4,7
01/07/14    0,291         67 724              649           2,7
01/01/15    0,252         72 234              527           3,3
01/07/15    0,625       150 917              625           2,8
01/01/16    0,469       123 623              573           3,1
01/07/16    0,752       210 409              540           3,2
01/01/17    0,699       180 502              585           3,0
01/07/17    0,780       196 539              599           2,9
01/01/18    1,041       340 980              461           3,8
01/07/18    0,705       156 247              681           2,6

les 7 transactions théoriques par seconde n'ont jamais été atteints. et plus que cela, au fur et à mesure que le temps passe, moins ce 7 théorique semble accessible. en effet, la transaction moyenne semble s'alourdir lentement mais surement en fonction du temps qui passe.
ce qui m'amène à d'autres questions et d'autres réflexions, développées dans le prochain post.