Candidate Set Formation Policy for Mining Pools
Notice bibliographique
Résumé
Cryptocurrencies like Bitcoin use the blockchain technology to record transactions in a distributed and secure way. Miners are distributed entities responsible for validating the transactions in the network and producing and verifying new blocks of confirmed transactions. In addition, they are responsible for keeping the protocol’s integrity, protecting it against the double-spending problem. Miners are rewarded when they add new blocks to the blockchain. The reward consists of fresh coins created after adding a new block as well as the fees collected from the transactions inside the added block. The amount of new coins generated with new blocks is diminishing by the protocol over time. As such, the significance of collected fees is increasing for the miners.A recent trend in large mining pools is to allow miners to select transactions in the block they aim to mine. Allowing miners to select transactions increases transparency via discretization and also helps to avoid conflict of interest with the mining pool managers. Assuming that forming blocks is in miners’ hands, miners should have a strategy to maintain transactions inside the block in a way to maximize their collected fees. The mining process is a random process that is "progress free". That is, a miner can update the transactions inside the block without any impact on its chance of succeeding in adding the block. Given that transactions with higher fees might arrive at any time in an online manner, it is profitable for a miner to "refresh" its block during the mining process. In this paper, we study the impact of refreshing blocks via an experimental analysis on real-world data from Bitcoin on a controlled environment that is carefully tuned to match the real world. Our results indicate that refreshing blocks is essential for increasing miners’ collected fees, and overlooking it will have a significant impact on miners’ revenues.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,000 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,000 |
| Études des sciences et des technologies | 0,000 | 0,000 |
| Communication savante | 0,000 | 0,001 |
| Science ouverte | 0,000 | 0,000 |
| Intégrité de la recherche | 0,000 | 0,000 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».