Mineur de bitcoin - page 8

 
Andrey F. Zelinsky:

On a l'impression que les "experts" des marchés financiers sont tombés de la lune sur ce forum.

Oui, j'ai la même opinion de vous aussi. Peut-être que vous avez la mauvaise réponse.

Il existe de nombreux ouvrages devulgarisation scientifique sur l'organisation du système financier mondial et de chaque pays.

Il y a desconférences vidéo sur youtube, par exemple Katasonov -- il l'explique de manière populaire.

Si vous n'aimez pas lalittérature académique etspécialisée, lisez ou écoutez Starikov qui, pour les plus lents d'entre nous, explique clairement quoi, comment et pourquoi.

Ce n'est pas sérieux pour toi, il est temps d'avoir ta propre opinion.

S'il n'y a pas d'autorité pour vous - "les moustaches, les pattes et la queue du chat de Matrosskin" est la seule autorité - alors même la bosse grave ne réparera pas la bosse.

Et ça, c'est hors limite ! Qu'ai-je fait pour vous offenser ?

 
Sergey Chalyshev:

Et ça, c'est hors limite ! Qu'ai-je fait pour vous offenser ?

Sans vouloir vous offenser à notre époque, il s'agit simplement d'une tournure de phrase amusante que vous pouvez citer.
 
Andrey F. Zelinsky:
Sans rancune à notre époque, rien de plus qu'une tournure de phrase amusante, que vous pouvez citer.

Je ne comprends pas, quelle est la citation ?

Vous voulez dire que vous souhaitez aussi ?

Non, je ne le ferai pas, tu ne le feras pas.

 
Sergey Chalyshev:

Je ne comprends pas, quelle est la citation ?

Vous voulez dire que vous souhaitez aussi ?

Non, je ne le ferai pas, tu ne le feras pas.


Je ne comprends pas ce que vous dites.

 
anonymous:

1. Recherchez sur Internet le terme "pool minier" ; les sites Web contiennent généralement des instructions sur la manière de s'y inscrire. En général, cela se présente comme suit : le logiciel d'exploitation minière doit passer un lien de paramètre au pool, à partir duquel il prendra les données initiales à partir desquelles les nouveaux blocs seront exploités.

2. Je n'en ai aucune idée. Au minimum, je devrais développer un logiciel qui distribue les tâches de minage + si elles sont trouvées, les transfère rapidement aux nœuds bitcoin + calcule le taux de hachage de tous les participants au pool + contrôle l'équité des participants.

3. Disons 100 MBit / protection ddos / redondance en cas de défaillance du canal.

Environ un bloc par jour : pour cela, vous devez avoir entre les mains ~1/144 de la puissance de tout le réseau bitcoin. Il suffit de calculer le nombre d'ASIC S9 dont vous avez besoin pour cela et la quantité d'énergie qu'ils consomment. C'est le coût minimum, pour ainsi dire.


Je vois que vous vous y connaissez en la matière, permettez-moi de vous poser une question : les hashs sont énumérés de manière aléatoire, et peuvent essentiellement être répétés pour différents utilisateurs, ou existe-t-il un mécanisme commun pour notifier qu'un tel hash avec les données sources existe (sur lesquelles il a été obtenu) et qu'il ne doit pas être compté ? Ou simplement les pools sont assez forts pour fusionner les informations sur les hachages déjà calculés par le pool, ce qui exclut tout nouveau calcul ?

 
Aleksey Vyazmikin:

Je vois que vous comprenez le sujet, laissez-moi vous demander - une question me laisse perplexe - les hashs sont recherchés de manière aléatoire, et en fait peuvent être répétés pour différents utilisateurs, ou bien il existe un mécanisme unifié notifiant qu'un tel hash avec les données sources existe (sur lesquelles il a été obtenu) et qu'il n'est pas nécessaire de le calculer ? Ou est-ce que les pools sont forts parce qu'ils combinent des informations sur les hachages déjà calculés par le pool, ce qui empêche un nouveau calcul ?

L'extraction a été faite pour la dernière fois en février 2011 :D Mais vous pouvez penser et deviner comment cela devrait fonctionner...

Les mineurs indépendants et les différents pools répètent naturellement leurs calculs. Ils sont en concurrence les uns avec les autres.

Dans le cas d'un seul pool, il est logique de donner aux mineurs des blocs pour une recherche complète, limitée par une certaine plage de extraNonce (le champ nonce est entièrement recherché, et très, très rapidement) ; si aucune réponse n'est reçue des mineurs dans un certain temps, inversement proportionnel à leur taux de hachage - leur contribution au pool n'est pas comptée. De plus, une protection est nécessaire en cas de telles attaques :

1. Un mineur prend une tâche dans le pool et renvoie une réponse à un moment donné - "il n'y a pas de solution appropriée pour le bloc dans cette tâche" - sans effectuer de calcul. La protection est possible en distribuant des blocs qui se chevauchent ou en dupliquant des tâches à différents mineurs et en comparant les solutions. Quiconque est pris à plusieurs reprises dans une telle attaque est banni.

2. Un mineur utilise le même équipement pour participer à plusieurs pools, gonflant ainsi un taux de hachage inexistant. La protection est possible en exigeant que l'ID du pool soit inclus dans le bloc.

Le dépassement aléatoire et le manque de synchronisation dans le cas d'un pool réduisent l'efficacité du matériel car le calcul sera répétitif. Ces pools auront des paiements plus faibles et ne résisteront pas à la concurrence de ceux qui utilisent l'équipement plus efficacement. Pour un pool ASIC autonome qui n'a pas besoin d'être protégé contre les attaques mentionnées ci-dessus, l'option la plus rentable est également de diviser la tâche en blocs plutôt que d'essayer de le faire au hasard.

Google "Protocole d'exploitation minière de strates"

 
anonymous:

La dernière fois que j'ai fait de l'extraction minière, c'était en février 2011 :D Mais vous pouvez penser et deviner comment cela devrait être organisé...

Les mineurs indépendants et les différents pools répètent naturellement leurs calculs. Ils sont en concurrence les uns avec les autres.

Dans le cas d'un pool, il est logique de donner aux mineurs des blocs pour une énumération complète, limitée à une certaine plage de extraNonce (le champ nonce est une énumération complète, et très, très rapide) ; si aucune réponse n'est reçue du mineur dans un certain temps inversement proportionnel à son taux de hachage, sa contribution à l'activité du pool n'est pas comptée. De plus, une protection est nécessaire en cas de telles attaques :

1. Un mineur prend une tâche dans le pool et renvoie une réponse à un moment donné - "il n'y a pas de solution appropriée pour le bloc dans cette tâche" - sans effectuer de calcul. La protection est possible en distribuant des blocs qui se chevauchent ou en dupliquant des tâches à différents mineurs et en comparant les solutions. Quiconque est pris à plusieurs reprises dans une telle attaque est banni.

2. Un mineur utilise le même équipement pour participer à plusieurs pools, gonflant ainsi un taux de hachage inexistant. La protection est possible en exigeant que l'ID du pool soit inclus dans le bloc.

Le dépassement aléatoire et le manque de synchronisation dans le cas d'un pool réduisent l'efficacité du matériel, car le calcul sera répétitif. Ces pools auront des paiements plus faibles et ne résisteront pas à la concurrence de ceux qui utilisent l'équipement plus efficacement. Pour un hangar ASIC autonome qui n'a pas besoin d'être protégé contre les attaques mentionnées ci-dessus, l'option la plus rentable est également de diviser la tâche en blocs plutôt que de l'essayer au hasard.

Google "Protocole d'exploitation minière de strates"


Merci pour l'information. Ainsi, si les mineurs pouvaient partager les hachages qu'ils ont déjà recréés, le processus serait clairement accéléré. Il s'avère que leurs hashs sont stockés sur le PC, mais prennent-ils beaucoup de place ? Peut-être y a-t-il un sens à échanger des hachages contre des hachages calculés ?

 
Aleksey Vyazmikin:

Merci pour ces informations. Ainsi, si les mineurs pouvaient partager les hachages qu'ils ont déjà redistribués, le processus serait clairement accéléré. Il s'avère que leurs hashs sont stockés sur le PC, mais prennent-ils beaucoup de place ? Peut-être y a-t-il un intérêt à échanger des hachages contre des hachages calculés ?

Ils ne sont pas stockés et il est inutile de les stocker. Vous n'avez pas de support pour une telle quantité de données, et même si vous en avez, le taux d'accès sera inférieur au taux de régénération.

 
Sergey Chalyshev:

Votre raisonnement me laisse perplexe.)

Avez-vous la moindre idée de ce sur quoi vous écrivez ?

Si c'est le cas, veuillez expliquer ce que signifie"inflation en profondeur".

Est-ce que vous (tutoyons nous, bordel) voyez les guillemets ?

Mon hypothèse est que, puisque l'inflation du bitcoin est strictement rationnée et que celle des monnaies mondiales ne l'est pas, le bitcoin se divisera et se divisera en morceaux de plus en plus petits. C'est comme ça que je l'ai appelé.

 
Sergey Chalyshev:

Je pense que vous êtes allé trop loin ici. Le rouble n'est même pas près de dépendre du dollar et ne s'est pas déformé, mais seulement déprécié. Jusqu'à présent, la route du rouble n'a été qu'à sens unique.

Exactement... Et selon ses propres termes, son travail est "lié à l'argent".

À mon avis, le rouble dépend aussi très peu du dollar. Beaucoup plus la dépendance du rouble aux ressources énergétiques.

Mais il y a peu de différence - le rouble et le dollar ne sont que du papier, ils n'ont pratiquement aucune valeur d'usage (et aucune valeur pour les monnaies scripturales), on ne peut donc pas dire qu'ils sont garantis par quelque chose. Collatéral - implique la possibilité illimitée d'échanger de la monnaie contre l'objet du collatéral et inversement. Ce n'est pas le cas du dollar, du rouble, du bitcoin ou de toute autre monnaie moderne.