Topic: Questions conne de statistique (Read 709 times)

Non, ce n'est pas comme ça. Il n'y a pas X hash valables parmi Y (dans l'espace mathématique de recherche). Il n'y a pas un nombre défini de bloc/hash valides dans l'espace potentiel de recherche. Chaque hash effectué (coup de pioche) a une probabilité X/Y de trouver un hash "valide". mais ce n'est pas parce que tu viens de trouver un hash, que celui d'à coté n'est pas valide, ou a moins de chances de l'être.
Après "statistiquement", ça revient au même, il y a "en gros"* x/y blocs valides dans un espace défini mais, chaque "coup de pioche" est indépendant des autres. Et il est impossible de savoir ce que l'on va trouver sous la pioche (hash valide), avant de calculer complètement le hash (propriété d'une fonction de hash secure).


Non, chaque hash est totalement indépendant des autres, donc le travail passé n'influe pas sur le futur. Dans un jeu de cartes, c'est comme si à chaque carte, la carte pouvait être n'importe laquelle des 52 à chaque carte. Par exemple au blackjack, si tu tires le 7♣ au départ, ca veut dire qu'il ne reste plus que 5 autres dans le talon. Avec PoW Bitcoin, c'est différent, tu ne peux pas en tirer d'information pour la suite. Imagine, si tu tires le 7♣, et bien chaque carte tirées par la suite, auront 1/52 chances d'être cette même carte. dans un bloc de 324 cartes, tu pourras trouver 5, 6 ou 7 cartes qui sont 7♣ (*gaussienne autour de 6).
De même avec les 324 cartes classiques, tu pourras déduire la dernière carte (ou 50% l'avant-dernière, etc...) car les valeurs des cartes ne sont pas indépendantes. En PoW Bitcoin, tu ne peux jamais prédire un hash (de par la conception, sinon SHA256 est cassé, et on pourra meme faire des fausses signatures). Un peu comme si chaque carte s'imprimait à chaque tirage, comme une photo Polaroid. Chaque hash est comme "random", SHA est plus ou moins utilisé en PRNG, mais chaque sortie nécessite beaucoup de calculs (comme une KDF).

PS: Et pour le blackjack, je ne connais rien aux cartes, mais j'imagine que c'est simplement au départ tu n'a pas assez d'information, et donc tu ne peux pas t'en servir. Toutefois il est utile de compter les cartes dès le départ pour amasser de l'information au fur et à mesure. (mais je crois que c'est interdit).
Posted from Bitcointa.lk - #b08fFQLCepyyx4eP

Donc on est bien daccord

La ou je suis pas tous a fait dacord et sur le fait que l'on a rien commencé.

Pour un blob donnée il y a X hash qui valide le block sur Z hash possible
X/Z   par ex  200/20000 (  200Hash sur 20000 possible )

Si je change le blob X ( merkle root mise a jours ) , je repart a zéro avec X.
Je pense que vu les echelle en place qui ne sont pas de 1% mais de 1/10000000.0000% .
Cela ne change rien ou c'est négligeable et largement compensé par les transactions en plus dans le blocs.

Pour reprend mon analogie du blackjack.
Cela ne sers a rien de compter les carte si on a que 12 cartes sur les 324 possible ( 6*52 ) de sortis quand un shuffle est présent.
 

On ne peut effectivement pas parler de pourcentage de travail effectué, chaque hash est indépendant. Donc tu ne peux pas dire "je vais plutot finir le travail, sinon je vais repartir de zéro". En changeant le merkle-root, tu ne repars pas de zéro (ou du moins tu est toujours à zéro)

Les mineurs ont interet à inclure le plus possible de transactions pour récupérer les fees associées. Le mieux est de continuer à miner (calculer des hash) en parallèle du recalcul du merkle-root. Concrètement les mineurs attendent la fin d'un "scan de nonce" pour modifier leur block, par celui fourni par le CPU/pool. C'est d'autant plus facile de continuer de miner en parallèle avec les ASIC et les mining pools (avec un pool, c'est le pool qui propose le merkle-root, mais je parle globalement). Il y aura toujours une ou deux transactions non incluses (inclues au prochain block), mais sinon le pool/node n'enverrait jamais de work aux miners.


Je ne vois pas de rapport avec le problème de Hall: chaque hash est totalement indépendant et correspond à un tirage au sort, dont l'issue ne dépend pas des autres actions ni calculs. Contrairement au problème de Hall, ou il n'y a qu'un seul lot pour X portes.
 

Je sais que répondre avec Hollywood n'est jamais une bonne solution mais je crois que ce problème est traité dans cet extrait, non ? http://www.vodkaster.com/Films/Las-Vegas-21/20410 sinon pour le problème original http://fr.wikipedia.org/wiki/Probl%C3%A8me_de_Monty_Hall

Question conne.
Je parle de bitcoin mais le raisonnement est valable pour tous.

J'ai X hash  contre des Y de hashrate.

La configuration clasic me fait recalculer un template de block toutes les X secondes ( par ex 20 Secondes ), ce qui revient a changer le block tester tous les 20 secondes ( Merkle root )

1.) Vaut il mieux continuer avec le même block du debut a la fin et ne pas inclure les transactions.
2.) Ou prendre un nouveau block( nouveau template du block courant ) et recommencer a zéro .

Mon instinct premier dirait de faire la premieres solutions. Car autant finir ce que l'on a commencé et n'est pas refaire. ( J'ai déjà parcourus déjà 5% des possibilité, il ne me reste que 95% a parcourir )

Ma vision logicienne de joueur de blackjack me dit que pour chaque hash tester.
Que je sois a 0 sec du block ou as 2 minutes il as la même valeur statistique d’être valide
Un peu comme au blackjack cela ne changerai rien au statistique si ou mélange le desk des cartes restantes après chaque tirage de carte .


Vous en pensez quoi ?
Si c'est le point 2 comme je le pense qu'elle est reelement l’intérêt de ne pas inclure les transactions pour un mineur ? Et ja parle pas du CPU pour faire le template, la charge est ridicule.