Zum Inhalt springen
Financial Context Wiki

Bitcoin-Mining: Blockvorlagen, Proof of Work, Pools und Wirtschaftlichkeit

Bitcoin-Mining erstellt Blockkandidaten und durchsucht SHA-256d-Header nach einem Arbeitsnachweis unter dem Netzwerkziel. Trenne Vorlagenidentität, Transaktions- und Coinbase-Gültigkeit, Nonce- und Extranonce-Suche, Node-Validierung, Verbreitung, Stale-Risiko, Pool-Shares, Auszahlung, Difficulty, Energie und Wirtschaftlichkeit.

Aktualisiert

Nur zur Weiterbildung über Protokoll und Mining; keine Anlage- oder Betriebsberatung. Ergebnisse sind zufällig und hängen von Regeln, Difficulty, Gebühren, Poolbedingungen, Verfügbarkeit, Hardware, Energie, Finanzierung, Steuern und Preisen ab; prognostizierte Erträge oder Hashanteile garantieren weder Blöcke noch Auszahlungen oder Gewinn.

Direkte Antwort

Bitcoin-Mining erstellt gültige Blockkandidaten und hasht deren 80-Byte-Header wiederholt mit SHA-256d, bis ein Ergebnis numerisch höchstens dem Konsensziel entspricht. Der erfolgreiche Miner schlägt den Block nur vor. Er kann keine ungültige Transaktion gültig machen, externe Wahrheit bestimmen oder fremde Coins kontrollieren: Jeder Full Node prüft Arbeitsnachweis, Header, Transaktionen, Skripte, ausgegebene Outputs, Blockgrenzen und zulässigen Coinbase-Wert selbst.

Mining-Node oder Pool beziehen Kandidatendaten über Schnittstellen wie getblocktemplate. Wichtige Felder sind version, previousblockhash, transactions, coinbasevalue, target, bits, height, weightlimit und sigoplimit. Die Vorlage ist ein per Policy gewählter Ausgangspunkt; sie garantiert weder jede Transaktion noch die Annahme eines geänderten Blocks. Konsensgültigkeit, Mempool-Policy, Gebührenauswahl und Poolregeln sind verschiedene Ebenen.

Hardware durchsucht Headervarianten. Nach dem 32-Bit-Nonce-Bereich ändert Software die Coinbase-Extranonce, baut die Merkle Root neu und kann erlaubte Zeit- oder Versionsfelder aktualisieren. Jeder Hash ist ein unabhängiger Versuch. Mehr kompatible Hashrate erhöht die erwartete Erfolgsfrequenz, terminiert aber keinen Block und garantiert keine Frist.

Solo-Mining erhält den gesamten zulässigen Coinbase-Output, hat jedoch hohe Varianz. Pools bündeln Arbeit und messen Beiträge mit leichteren Share-Zielen; nur ein Share, der auch das Netzwerkziel erfüllt, kann ein Block werden. Ein Pool verringert Auszahlungsvarianz, nicht die erwartete Netzemission. Verwahrung, Vorlagenkontrolle, Share-Prüfung und PPS-, PPLNS- oder andere Verbindlichkeiten schaffen Gegenparteien- und Konzentrationsrisiken.

Mining richtig analysieren

  1. Identität und Befugnis festlegen. Erfasse chain, network, client version, Regeln, bestblockhash, Vorlagenanbieter, Pool-Endpunkt, Zahlungsempfänger und Zeit. Trenne Node, Builder, Poolbetreiber, Firmware, Anlage und Geräteeigentümer.
  2. Kandidatenauswahl reproduzieren. Sichere mempool und UTXO set; prüfe Gültigkeit, Abhängigkeiten, Gebühren, Gewicht, Signaturoperationen, Locktime und Witness Commitments. Baue den Kandidaten nach und erkläre Policy; Gebührenrate ist kein Konsens.
  3. Coinbase und Header abgleichen. Prüfe höhenabhängige Subsidy, Gebühren, Outputs, Commitments, vorherigen Hash und Merkle Tree. Verfolge nonce, Coinbase-extranonce, Merkle root, time und version bits; verwerfe Vorlagen außerhalb der Grenzen.
  4. Suche und Einreichung prüfen. Decodiere das kompakte Ziel und teste block_hash <= target mit Byteordnung und Hashregeln des Netzes. Rekonstruiere bei einem Treffer den Block, sende ihn über submitblock oder das eingesetzte Protokoll und sichere Annahme oder Ablehnung.
  5. Unabhängige Validierung und Verbreitung verfolgen. Vergleiche Full Nodes bei Header, Transaktionen, Skripten, Coinbase und Chainwork. Miss Verbreitung, konkurrierende Spitzen, stale oder orphan Ergebnisse und Reorganisation; ein Treffer garantiert keine kanonische Dauer.
  6. Belohnung und Poolbuchhaltung abgleichen. Trenne coinbase, subsidy + transaction fees, Poolgebühr und Reserven, pool target, network target, akzeptierten share, stale Shares, Methode, Reife, Minimum, Verwahrung und Gegenpartei.
  7. Wirtschaft und Sicherheit stressen. Nenne effektive Rate, Verfügbarkeit, Effizienz, Strom, Kühlung, Personal, Hosting, Wartung, Abschreibung, Finanzierung, Steuern, Drosselung, Subsidy, Gebühren, Preis und Difficulty. Teste Varianz, Ausfall, Schocks, Verzögerung, Poolausfall, Zensur, Konzentration und Reorg.

Das Ergebnis ist ein Blockvorschlag plus Nachweis rechnerischer Suche. Nodes entscheiden Gültigkeit; Fork Choice wählt den aktiven gültigen Ast; Difficulty ändert das Ziel nur an ihrer Grenze; Anwendungen bestimmen Bestätigungen. Mining beteiligt sich, ersetzt aber nichts davon.

Rechenbeispiele

1. Die Nonce ist nicht der ganze Suchraum

Der 80-Byte-Header hat eine 32-Bit-Nonce mit 2^32 = 4,294,967,296 Werten. Bei 200 TH/s dauert so viele Header zu testen ungefähr:

4,294,967,296 / 200,000,000,000,000 = 0.0000214748 seconds

Die Arbeit geht weiter: Coinbase-Extranonce ändern, neue Merkle Root ableiten und erlaubte Felder aktualisieren eröffnet einen weiteren Nonce-Raum. Die Nonce als gesamte Kapazität anzusehen ist ein Kategorienfehler.

2. Solo-Varianz und Strom

Bei Netz 600 EH/s und effektivem Miner 200 TH/s beträgt der vereinfachte Anteil 200 TH/s / 600 EH/s = 0.0000333333%. Für 144 Blöcke täglich ist die Erwartung lambda = 144 * 0.000000333333 = 0.000048 blocks/day, die mittlere Wartezeit 1 / 0.000048 = 20,833.33 days. Poisson ergibt P(0) = exp(-0.000048) = 99.9952001152% für null Tagesblöcke.

Ein 3,5-kW-Gerät zu USD 0,06/kWh kostet direkt 3.5 kW * 24 * USD 0.06/kWh = USD 5.04/day. Kühlung, Hosting, Stillstand, Reparatur, Abschreibung, Finanzierung und Steuer fehlen. Erwartungswert ist kein Zahlungstermin; ein seltener Solotreffer keine tägliche Forderung.

3. Coinbase-Buchhaltung und Reife

Die Subsidy sei 3.125 BTC, gültige Gebühren 0.42 BTC. Maximal erstellt die Coinbase 3.125 + 0.42 = 3.545 BTC; mehr macht den Block ungültig, weniger verzichtet auf Wert.

Der Coinbase-Output benötigt 100 blocks Reife vor Ausgabe. Der Block kann stale oder reorganisiert werden. Pool-Dashboard, unreifer Output und endgültige externe Zahlung sind verschiedene Ansprüche und Risiken.

4. Pool-Shares und Auszahlungsannahmen

Bei gleich schwierigen akzeptierten Shares erfasst der Pool 2,000,000, ein Miner 50,000: sein Anteil ist 50,000 / 2,000,000 = 2.5%. Bei 3,545 BTC Blockwert und 2% Poolgebühr sind 3.545 * (1 - 0.02) = 3.4741 BTC verteilbar und 3.4741 * 2.5% = 0.0868525 BTC proportional.

Ist das Poolziel 1,000-mal leichter, hat ein akzeptierter Share vereinfacht 1 / 1,000 Chance, auch das Netzwerkziel zu treffen. Reale Buchhaltung normalisiert variable Schwierigkeit, verwirft Duplikate und stale Arbeit, wendet PPS, FPPS, PPLNS oder den Vertrag an und trennt Pool-Erwartungszahlung von blockbedingtem Ertrag.

Risiken und Prüfungsfehler

Protokoll- und Vorlagenfehler

  • Behaupten, Miner machten Transaktionen gültig, statt Kandidaten für unabhängige Node-Prüfung zu wählen.
  • Kette, Netz, Fork, Spitze, Client, Anbieter oder Pool vermischen.
  • Mempool oder Vorlage als Konsens, vollständige Menge oder garantierten Zukunftsblock behandeln.
  • Nach Einzelgebühr auswählen und Vorfahren, Nachfolger, Gewicht, Signaturen, Sperren und Commitments ignorieren.
  • Subsidy-Höhe, Gebühren, Coinbase-Outputs, Witness oder Merkle Root falsch berechnen.
  • Nach neuer Spitze auf altem Vorgängerhash, Ziel, Zeit- oder Versionsraum suchen.
  • Hash und Ziel mit falscher Codierung, Byteordnung oder Algorithmus vergleichen.

Pool- und Betriebsfehler

  • Akzeptierten Share mit Netzblock gleichsetzen oder Shares ohne Schwierigkeitsnormalisierung zählen.
  • Erwarteten Anteil in garantierte Blöcke, Erträge oder Zahlungstermine umwandeln.
  • Poolanteil als dauerhaftes Hardwareeigentum sehen oder Konzentration ausblenden.
  • Stale und abgelehnte Shares, Latenz, Firmware, Temperatur, Verfügbarkeit, Drosselung und Ausfall weglassen.
  • Methode, Gebührenbasis, Reserven, Minimum, Reife, Verwahrung, Abhebung und Ausfallbedingungen ignorieren.
  • Gefundenen Block vor Annahme, Verbreitung, Auswahl und Reorganisationsprüfung final nennen.
  • Zugangsdaten, Adressen oder Remote-Firmware ohne Authentisierung, Kontrolle und Incident Response wiederverwenden.

Wirtschafts- und Sicherheitsfehler

  • Brutto-BTC-Erwartung ohne Preis, Difficulty, Gebühren, Strom, Kühlung, Arbeit, Abschreibung, Finanzierung und Steuer Fiat-Gewinn nennen.
  • Strom oder Emissionen ohne Effizienz, Auslastung, Kühlung, Ort, Zeit und Energiemix aus Hashrate ableiten.
  • Sofortige Difficulty-Reaktion oder planmäßige Zehn-Minuten-Blöcke annehmen.
  • Behaupten, Halving garantiere Preis, Kapitulation oder gleichbleibende Sicherheitsausgaben.
  • Behaupten, Hashmehrheit fälsche Signaturen, stehle Coins oder erzwinge ungültige Inflation.
  • Hohe Rate als Beweis gegen Pool-, Hersteller-, Firmware-, Geo-, Energie-, Netz- oder Softwarekonzentration nutzen.

Häufige Irrtümer

  • Miner können jede Transaktion gültig genehmigen. Sie wählen und ordnen; ehrliche Nodes verwerfen konsenswidrige Blöcke.
  • Nur die Nonce ist veränderbar. Extranonce ändert Coinbase und Merkle Root; erlaubte Zeit und Version erweitern ebenfalls den Raum.
  • Ein Pool-Share ist ein Teil eines Blocks. Er belegt Arbeit unter einem leichteren Ziel; meist erfüllt er das Netzwerkziel nicht.
  • Erwarteter Tagesertrag ist garantierte Zahlung. Fund ist zufällig, Zahlung hängt auch von Vertrag, Reife und Gegenpartei ab.
  • Mehr Hashrate bedeutet automatisch mehr Gewinn. Anteil, Difficulty, Gebühren, Preis, Effizienz, Strom und Kosten bestimmen ihn.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...