BCH2: Bitcoin Cash II

Kurzfassung

BCH2 (Bitcoin Cash II) ist eine SHA-256-Kryptowährung, die das bewährte Bitcoin-Cash-Protokoll mit einem fairen Verteilungsmodell verbindet: einem 1:1-Fork von BC2 (BitcoinII). Durch den Fork bei Blockhöhe 53.200 übernimmt BCH2 die vollständige Transaktionshistorie von BC2 und wechselt zugleich auf die Konsensregeln von Bitcoin Cash – darunter der ASERT-Algorithmus zur Schwierigkeitsanpassung (mit angriffsresistenter Halbwertszeit von 1 Stunde zum Start), 32-MB-Blöcke, CashAddr-Adressen und sämtliche BCH-Protokoll-Upgrades bis einschließlich Upgrade 11 (ABLA).

Während Bitcoin und seine Ableger von industriellen Mining-Betrieben beherrscht werden, bietet BCH2 einen Neuanfang mit erreichbaren Schwierigkeitsgraden. Ohne Premine, ohne Entwicklergebühren und mit fairer 1:1-Fork-Verteilung an bestehende BC2-Inhaber steht BCH2 für die Rückkehr zu jenem dezentralen Mining-Ethos, das Bitcoin revolutionär gemacht hat.

1. Einleitung

1.1 Die ursprüngliche Vision

Als Satoshi Nakamoto 2009 Bitcoin startete, konnte jeder mit einem PC Blöcke minen und Belohnungen verdienen. Diese Zugänglichkeit war grundlegend für die dezentrale Natur von Bitcoin – Tausende unabhängige Miner sicherten das Netz, jeder mit einer fairen Chance auf die Blockbelohnung.

1.2 Die Entwicklung von Bitcoin

Mit dem Wachstum von Bitcoin führten Meinungsverschiedenheiten über Skalierung und Philosophie zu wichtigen Entwicklungen:

• 2017: Bitcoin Cash (BCH) spaltete sich bei Block 478.558 von Bitcoin ab und erhöhte die Blockgröße auf 8 MB (später 32 MB), um mehr Transaktionen und niedrigere Gebühren zu ermöglichen. BCH wurde seither stetig verbessert: 2020 kam der Schwierigkeitsalgorithmus ASERT hinzu, dazu zahlreiche Protokollverbesserungen bis 2025.
• 2025: BC2 (BitcoinII) startete als neue Umsetzung auf Basis von Bitcoin Core v27 mit eigenem Genesis-Block und bot damit eine saubere Blockchain für Experimente und neue Anwendungen.
• 2026: BCH2 (Bitcoin Cash II) spaltet sich bei Blockhöhe 53.200 von BC2 ab, bewahrt die vollständige Geschichte von BC2 und wechselt zugleich auf die Konsensregeln von Bitcoin Cash. So entsteht eine einzigartige Verbindung: die faire Anfangsverteilung von BC2 mit den praxiserprobten Protokollverbesserungen von BCH.

1.3 Das heutige Problem

Die Netzwerkschwierigkeit von Bitcoin hat astronomische Werte erreicht, ebenso bei BCH und den meisten SHA-256-Ablegern. Daraus ergeben sich mehrere Probleme:

1. Vorherrschaft der Industrie — Nur Großbetriebe mit billigem Strom und ASIC-Großeinkauf können auf den großen Chains profitabel minen.
2. Ausschluss von Heim-Minern — Einzelne mit kleinen Geräten haben in Netzen mit hoher Schwierigkeit praktisch keine Chance, einen Block zu finden.
3. Zentralisierung durch Pools — Miner werden in Pools gedrängt, zahlen Gebühren und müssen den Betreibern vertrauen – das schwächt den Peer-to-Peer-Charakter von Kryptowährung.
4. Veraltete Schwierigkeitsalgorithmen — Chains mit dem 2016-Block-Anpassungsintervall von Bitcoin können bei schwankender Hashrate extreme Unterschiede in den Blockzeiten erleben.

1.4 Die Lösung von BCH2

BCH2 begegnet diesen Problemen so:

• Start auf einem erreichbaren Schwierigkeitsniveau, übernommen aus der frühen Blockchain von BC2
• Einsatz von ASERT mit einer Halbwertszeit von 1 Stunde, damit sich die Schwierigkeit nach Manipulationsangriffen schnell erholt
• 32-MB-Blöcke für künftige Skalierbarkeit
• Das CashAddr-Format für nutzerfreundliche Adressen
• Volle Kompatibilität mit den Protokollverbesserungen von Bitcoin Cash
• Automatischer Wechsel der ASERT-Halbwertszeit von 1 Stunde auf 2 Tage bei Block 92.736 (etwa 9 Monate nach dem Fork) – ohne Hard Fork

2. Warum BCH2

2.1 Grundsätze eines fairen Starts

BCH2 lehnt die ausbeuterischen Token-Modelle ab, die jüngste Kryptostarts geprägt haben:

Kein Premine: Die gesamte BCH2-Menge beim Fork geht an die BC2-Inhaber, entsprechend ihrem Bestand im Fork-Block. Für Entwickler, Stiftungen oder Insider werden keine Coins erzeugt.

Keine Entwicklergebühr: 100 % der Blockbelohnungen gehen an die Miner. Die Entwicklung ist community-finanziert und freiwillig, nicht aus den Blockbelohnungen abgezweigt.

Kein ICO/IEO: BCH2 wird nicht verkauft oder vorab zugeteilt. Die Verteilung erfolgt über den BC2-Fork und das laufende Mining.

Bewährte Codebasis: BCH2 baut auf BitcoinII Core v27.1 auf – demselben Fundament, das bei Bitcoin und seinen Ablegern Werte in Milliardenhöhe absichert.

2.2 Fork-Verteilung an BC2-Inhaber

Nach dem Vorbild von Bitcoin Cash aus dem Jahr 2017 erkennt BCH2 bestehende BC2-Inhaber durch einen 1:1-Fork an:

• Alle BC2-Guthaben im Fork-Block werden als BCH2 gutgeschrieben (rund 2.660.000 Coins beim Fork)
• Wer die privaten Schlüssel zu BC2 besitzt, verfügt automatisch über die entsprechenden BCH2
• Keine Anmeldung, kein Claim, kein KYC – die Schlüssel einfach in eine BCH2-Wallet importieren

Dieses Modell stellt sicher:

• Faire Verteilung an alle, die BC2 unterstützt haben
• Liquidität von Tag eins an
• Keine Konzentration des Angebots in Entwicklerhand
• Gleichlauf der Interessen früher Unterstützer und des Netzerfolgs

2.3 Mining wieder zugänglich machen

Die Schwierigkeit von BCH2 beim Fork eröffnet kleineren Minern realistische Chancen:

• Lotterie-Miner willkommen — Geräte wie Bitaxe, Nerdminer und ähnliche Miner mit geringer Hashrate haben eine echte Chance, Blöcke zu finden.
• Heim-Mining lohnt sich — ASICs für Privatanwender können um die vollen Blockbelohnungen mitspielen.
• Solo-Mining kehrt zurück — Einzelne können direkt minen, ohne zwingend einem Pool beizutreten.
• Natürliches Wachstum — Mit der Verbreitung steigt die Schwierigkeit organisch mit dem Netz.

3. Technische Daten

3.1 Konsensparameter

3.2 Fork-Parameter

3.3 Netzwerkkonfiguration

3.4 Aktivierungshöhen vor dem Fork (BC2-Historie)

Diese Aktivierungen fanden in der Geschichte von BC2 statt und bleiben in BCH2 erhalten:

3.5 BCH2-Aktivierungen (nach dem Fork)

Alle Bitcoin-Cash-Protokoll-Upgrades werden gleichzeitig bei Block 53.201 aktiv:

3.6 Deaktivierte Funktionen (ggü. BTC/BC2)

Die folgenden BTC/BC2-Funktionen sind nach dem Fork deaktiviert, im Einklang mit dem BCH-Konsens:

3.7 ASERT-Algorithmus zur Schwierigkeitsanpassung

BCH2 verwendet ASERT (Absolutely Scheduled Exponentially Rising Targets), den Algorithmus zur Schwierigkeitsanpassung, den Bitcoin Cash im November 2020 übernommen hat (Axion-Upgrade). BCH2 nutzt aserti3-2d exakt wie in BCHN v29.0.0 implementiert, mit angepasster Halbwertszeit für die Sicherheit beim Start.

Kernalgorithmus:

ASERT berechnet die Schwierigkeit aus der seit einem „Ankerblock“ (bei BCH2 der Fork-Block) verstrichenen Zeit und zielt im Mittel auf genau 10 Minuten pro Block:

next_target = anchor_target * 2^((actual_time - scheduled_time) / halflife)

Dabei gilt:

• anchor_target = Schwierigkeitsziel im Ankerblock (Fork-Block)
• actual_time = seit dem Vorgänger des Ankerblocks verstrichene Zeit
• scheduled_time = erwartete Zeit, berechnet als Höhendifferenz × 600 Sekunden
• halflife = Zeitkonstante, die die Anpassungsgeschwindigkeit bestimmt

ASERT-Halbwertszeit: entscheidender Startparameter:

Begründung für die Halbwertszeit von 1 Stunde:

Eine neue Chain mit begrenzter Hashrate (~1 PH/s) ist anfällig für Angriffe durch Schwierigkeitsmanipulation. Wer über viel Hashpower verfügt, kann rasch Blöcke minen, die Schwierigkeit hochtreiben und die Hashpower dann abziehen – ehrliche Miner finden bei der aufgeblähten Schwierigkeit keine Blöcke mehr. Mit der 2-Tage-Halbwertszeit von BCHN dauerte die Erholung von einem 10×-Anstieg rund 6,6 Tage: Das Netz wäre fast eine Woche unbrauchbar, Miner würden zu lohnenderen Chains abwandern, und es drohte eine Todesspirale.

Mit der 1-Stunden-Halbwertszeit von BCH2 führt derselbe Angriff nur zu etwa 7 Stunden langsamer Blöcke, dann läuft alles wieder normal. Miner können abwarten oder weiterminen, und die Kosten des Angreifers sind vergeudet.

Abwägung:

Die 1-Stunden-Halbwertszeit passt zur Startphase von BCH2 mit begrenzter Hashrate. Die höhere Schwankung ist ein vertretbarer Preis für die Angriffsresistenz.

ASERT-Ankerkonfiguration:

4. Adressformat

4.1 CashAddr-Spezifikation

BCH2 nutzt das von Bitcoin Cash entwickelte CashAddr-Format. Es bietet:

• Lesbares Präfix, das das Netzwerk benennt
• Fehlererkennung über eine BCH-Code-Prüfsumme
• Groß- und Kleinschreibung spielt keine Rolle – das erleichtert die Eingabe
• Klare Unterscheidung von Bitcoin-/BC2-Adressen

4.2 Adressbeispiele

P2PKH (Pay to Public Key Hash):

bitcoincashii:qz2p8hv43kuq8s6gfa5lkm9a2jcm0m5vfcr7hxlmnj

P2SH (Pay to Script Hash):

bitcoincashii:pz2p8hv43kuq8s6gfa5lkm9a2jcm0m5vfcfnk4xmwy

4.3 Kennzeichen der Adresstypen

5. Transaktionsparameter

5.1 Transaktionsspezifikationen

5.2 Replay-Schutz

Signaturen enthalten die Fork-ID im Sighash-Preimage und verhindern so das Wiedereinspielen von Transaktionen zwischen den Chains. Nach Block 53.200 signierte BCH2-Transaktionen sind auf BC2 ungültig, BC2-Transaktionen auf BCH2 ebenso.

5.3 Schutz vor Double-Spends (DSProof)

BCH2 integriert DSProof (Double-Spend Proof), einen Mechanismus auf Protokollebene zur Echtzeit-Erkennung von Double-Spend-Versuchen bei unbestätigten Transaktionen. Ursprünglich für Bitcoin Cash entwickelt, stärkt DSProof die Sicherheit ohne Bestätigung für Händler und Zahlungsdienstleister.

Erkennt ein Knoten widersprüchliche Transaktionen, die denselben Input ausgeben, erstellt er eine DSProof-Nachricht und verbreitet sie im Netz. Händler und Wallets, die auf DSProof-Meldungen achten, können verdächtige Transaktionen innerhalb von Sekunden markieren, ohne auf eine Bestätigung zu warten.

Das macht Handel ohne Bestätigung sicherer – ein zentraler Anwendungsfall für elektronisches Peer-to-Peer-Bargeld.

5.4 Migration von SegWit-UTXOs (Witness über ScriptSig)

BC2 hat SegWit von Bitcoin geerbt; im UTXO-Satz des Fork-Blocks liegen daher Coins in SegWit-Outputs (P2WPKH, P2WSH, P2TR und P2SH-umhüllte Varianten). Da BCH2 die SegWit-Konsensregeln entfernt, wären diese UTXOs nach dem Fork normalerweise nicht mehr ausgebbar.

BCH2 löst das mit Witness über scriptSig – einem Migrationsmechanismus, mit dem Inhaber vorhandene SegWit-UTXOs ausgeben können, indem die Signaturdaten im klassischen scriptSig-Feld statt im Witness-Feld stehen.

Prüfablauf:

• P2WPKH (v0, 20 Byte): Erwartet [Signatur, Pubkey] im scriptSig. Der Knoten bildet daraus implizit ein P2PKH-Script und prüft dagegen.
• P2WSH (v0, 32 Byte): Erwartet [...Argumente, Script] im scriptSig. Der Knoten prüft, ob SHA256(Script) dem Hash im Output entspricht.
• P2TR (v1, 32 Byte): Erwartet [Schnorr-Signatur] im scriptSig, ausschließlich für Key-Path-Ausgaben.
• P2SH-umhüllt: Das Redeem-Script steht gemeinsam mit den Signaturdaten im scriptSig.

Sicherheit:

• Dieselbe kryptografische Sicherheit wie SegWit – gültige Signaturen bleiben Pflicht
• SIGHASH_FORKID wird bei allen Signaturen nach dem Fork erzwungen (Replay-Schutz)
• Das Ausgeben über den Taproot-Script-Path wird nicht unterstützt – nur der Key-Path. Wer komplexe Taproot-Scripts nutzt, sollte die Coins vor dem Fork umziehen.

Wichtig: Dieser Mechanismus gilt nur für SegWit-UTXOs, die beim Fork-Block oder davor bestanden. Nach dem Fork lassen sich keine neuen SegWit-Outputs erzeugen – der BCH2-Konsens weist sie ab.

Sighash-Algorithmus:

SegWit-UTXOs auf BCH2 werden mit dem BIP143-Sighash-Algorithmus und SIGHASH_FORKID (0x41) ausgegeben:

sighash = SHA256(SHA256(
    nVersion ||
    hashPrevouts ||
    hashSequence ||
    outpoint ||
    scriptCode ||      // P2PKH script for pubkeyhash
    value ||           // 8-byte little-endian satoshis
    nSequence ||
    hashOutputs ||
    nLockTime ||
    hashType           // SIGHASH_ALL | SIGHASH_FORKID (0x41)
))

Die Signatur steht im scriptSig statt im Witness: scriptSig: <signature> <pubkey>, witness: (leer)

Für die Migration unterstützte Adresstypen:

5.5 Ablauf zum Einfordern der Fork-Verteilung

BCH2 verteilt alle BC2-Guthaben bei Forkhöhe 53.200 im Verhältnis 1:1. Der Claim-Vorgang unterstützt alle Adresstypen über eine einheitliche Wallet-Oberfläche.

Ableitung und Suche:

Die Wallet leitet Adressen aus einer BIP39-Mnemonik über die üblichen Ableitungspfade ab:

Es werden sowohl die externe (Empfangs-) als auch die interne (Wechselgeld-)Adresskette durchsucht, um alle fork-berechtigten UTXOs zu finden.

Schutz vor Missbrauch:

Damit niemand durch Wechsel des Adresstyps zweimal beansprucht, prüft die Wallet die Herkunft des Guthabens:

isFromForkDistribution = (BC2_balance > 0)

Besteht ein BCH2-Guthaben, während das zugehörige BC2-Guthaben null ist, sind die Mittel nach dem Fork eingegangen und werden als nicht aus der Fork-Verteilung markiert. Das verhindert folgenden Angriffsweg:

1. BCH2 auf einer SegWit-Adresse beanspruchen
2. Die ursprünglichen BC2-Mittel auf eine Legacy-Adresse verschieben
3. Erneut auf der Legacy-Adresse beanspruchen

Die Wallet zeigt passende Hinweise, die Einzahlungen nach dem Fork von Guthaben aus der Fork-Verteilung unterscheiden.

6. Script-Fähigkeiten (nach dem Fork)

BCH2 unterstützt den vollständigen BCH-Script-Befehlssatz:

7. Sicherheitsparameter der Chain

8. Übergang der ASERT-Halbwertszeit

8.1 Automatischer Übergang

Die ASERT-Halbwertszeit von BCH2 wechselt bei einer festgelegten Blockhöhe automatisch von 1 Stunde auf 2 Tage. Ein Hard Fork ist nicht nötig.

8.2 Mechanismus des Übergangs

Die Halbwertszeit richtet sich nach der Blockhöhe:

if (height < 92736):
    nASERTHalfLife = 3600       (1 hour)
else:
    nASERTHalfLife = 172800     (2 days, matching BCHN)

Block 92.736 entspricht Epoche 46, etwa 9,15 Monate nach dem Fork bei Block 53.200. Die ASERT-Ankerparameter bleiben unverändert – nur die Halbwertszeit-Konstante ändert sich.

8.3 Begründung

Eine feste Übergangshöhe macht einen koordinierten Hard Fork und die damit verbundenen Ermessensfragen unnötig. Nach 9 Monaten hatte das Netz genug Zeit, eine stabile Hashrate und eine vielfältige Minerlandschaft aufzubauen. Der Übergang steckt von Anfang an in den Konsensregeln, sodass alle Knoten ihn ohne weitere Absprache mittragen.

9. Mining

9.1 Plan der Blockbelohnungen

BCH2 folgt dem ursprünglichen Emissionsplan von Bitcoin:

9.2 Mining-Pool

Der Forge Pool stellt die Mining-Infrastruktur für BCH2 bereit, mit weltweit verteilter Architektur:

Verbindungsdaten:

Stratum: stratum+tcp://pool.bch2.org:3333

Funktionen:

• Eine einzige Adresse — Verbindung über eine Adresse, mit automatischer Weiterleitung zum nächstgelegenen regionalen Proxy
• Weltweites Proxy-Netz — Verbindungen mit geringer Latenz von jedem Ort aus
• Steuerung per Web-Oberfläche — Mining-Verfahren (solo/Pool) und Schwierigkeitseinstellungen ändern, ohne den Miner neu zu konfigurieren
• Solo-Auszahlung — Solo minen und die vollen Blockbelohnungen direkt in die eigene Wallet erhalten
• Vardiff — Automatische Anpassung der Schwierigkeit an die eigene Hashrate
• PPLNS-Auszahlung — Faire Verteilung der Belohnung nach eingebrachten Shares
• Mindestauszahlung: 5 BCH2
• Pool-Gebühr: 1 % (0,5 % beim Solo-Mining)

9.3 Solo-Mining

Die erreichbare Schwierigkeit von BCH2 macht Solo-Mining praktikabel. Richten Sie Ihren Miner so ein, dass er sich direkt mit Ihrem BCH2-Knoten verbindet:

# bitcoincashII.conf for solo mining
server=1
rpcuser=your_username
rpcpassword=your_password
rpcallowip=127.0.0.1

10. Infrastruktur

10.1 Weltweites Node-Netzwerk

BCH2 betreibt Seed-Knoten auf mehreren Kontinenten:

10.2 Dienste

10.3 Wallet-Kompatibilität

BCH2 ist mit der Wallet-Infrastruktur von Bitcoin Cash kompatibel:

• Übliche HD-Wallet-Ableitung nach BIP32/39/44
• CashAddr-Adresscodierung (Präfix: bitcoincashii:)
• Übliches Transaktionsformat (mit SIGHASH_FORKID)
• Eigener BCH2-Ableitungspfad: m/44'/145'/0'/0/x
• Das Legacy-Format (1xxx) bleibt zur Anzeigekompatibilität gültig

Adressformat:

bitcoincashii:qp63uahgrxged4z5jswyt5dn5v3lzsem6cy74rqsfs

10.4 Integration des Electrum-Protokolls

Abfragen von Guthaben und UTXOs laufen über Scripthash-Methoden, damit alle Adresstypen unterstützt werden:

scripthash = REVERSE(SHA256(scriptPubKey))

11. Tokenomics

11.1 Mengenverteilung beim Fork

11.2 Laufende Verteilung

Neue BCH2 kommen ausschließlich durch Mining in Umlauf:

• Blockbelohnung: 50 BCH2 pro Block
• Anteil der Miner: 100 %
• Entwicklergebühr: 0 %
• Verteilungsweg: ausschließlich Proof of Work

11.3 Mengenplan

12. Governance

12.1 Dezentrale Entwicklung

BCH2 arbeitet ohne zentrale Instanz:

• Keine Stiftung: Keine juristische Person kontrolliert BCH2
• Kein gütiger Diktator: Keine Einzelperson hat besondere Befugnisse über das Protokoll
• Offener Quellcode: Der gesamte Code ist unter MIT-Lizenz öffentlich prüfbar
• Von der Gemeinschaft finanziert: Die Entwicklung lebt von freiwilligen Beiträgen

12.2 Protokoll-Upgrades

Änderungen an den Konsensregeln von BCH2 erfordern:

1. Vorschlag: öffentliche Spezifikation der geplanten Änderungen
2. Prüfung: Analyse durch Gemeinschaft und Entwickler
3. Umsetzung: Entwicklung und Test des Codes
4. Signalisierung: Messung der Unterstützung durch Miner und Knotenbetreiber
5. Aktivierung: koordiniertes Upgrade zu festgelegter Höhe bzw. Zeit

12.3 Ausrichtung an Bitcoin Cash

BCH2 will mit den Protokollverbesserungen von Bitcoin Cash kompatibel bleiben:

• ASERT-DAA (umgesetzt)
• 32-MB-Blöcke (umgesetzt)
• Native Introspection (umgesetzt)
• Künftige BCH-Upgrades werden auf Übernahme geprüft

13. Roadmap

Phase 1: Start ✓

• Fork von BC2 bei der festgelegten Blockhöhe
• ASERT-Schwierigkeitsanpassung aktiv
• 32-MB-Blockgröße aktiviert
• CashAddr-Adressierung (bitcoincashii:)
• Weltweites Knotennetz in Betrieb
• Mining-Pool (Forge Pool) in Betrieb
• Software für vollständige Knoten veröffentlicht

Phase 2: Verbreitung

• Desktop-Wallets (Fork von Electron Cash)
• Mobile Wallets (Android, iOS)
• Web-Wallet
• Verbesserungen am Block-Explorer
• Weitere Mining-Pools
• Listungen an Handelsplätzen

Phase 3: Ökosystem

• Zahlungswerkzeuge für Händler
• Unterstützung für Hardware-Wallets (Ledger, Trezor)
• Umsetzung der CashFusion-Privatsphäre
• Einbindung von CashTokens
• SDK und Dokumentation für Entwickler

Phase 4: Wachstum

• Weiterhin Gleichlauf mit dem BCH-Protokoll
• Verbesserungen der Privatsphäre
• Aufbau eines Token-/NFT-Ökosystems
• Weitere Dezentralisierung der Infrastruktur
• Von der Gemeinschaft getriebene Weiterentwicklung

14. Sicherheitsüberlegungen

14.1 Sicherheit von SHA-256

BCH2 nutzt denselben SHA-256-Proof-of-Work-Algorithmus, der Bitcoin seit 2009 schützt:

• Keine neuartigen kryptografischen Annahmen
• Mining-Hardware im Milliardenwert ist kompatibel
• Mehr als 15 Jahre in der Praxis bewährte Sicherheit

14.2 Replay-Schutz

BCH2 setzt den Replay-Schutz über SIGHASH_FORKID um:

• Für BCH2 signierte Transaktionen sind auf BC2 ungültig
• Für BC2 signierte Transaktionen sind auf BCH2 ungültig
• Niemand kann aus Versehen auf der falschen Chain ausgeben

14.3 Stand der Code-Audits

BCH2 beruht auf:

• BitcoinII Core v27.1 (auf Basis des eingehend geprüften Bitcoin Core)
• Protokolländerungen von Bitcoin Cash (seit 2017 in der Praxis erprobt)
• Die CashAddr-Umsetzung (Standardcode von BCH)
• Die ASERT-Umsetzung (auf BCH seit 2020 im Einsatz)

15. Fazit

BCH2 verbindet die bewährten Protokollverbesserungen von Bitcoin Cash mit einem fairen Verteilungsmodell. Durch den Fork von BC2 bei Blockhöhe 53.200 bietet BCH2:

Für BC2-Inhaber:

• Automatische 1:1-Verteilung von BCH2 beim Fork
• Nichts zu tun – die gleichen Schlüssel funktionieren auf beiden Chains
• Der Wert des BC2-Engagements bleibt erhalten

Für Miner:

• Erreichbare Schwierigkeitsniveaus
• ASERT mit 1-Stunden-Halbwertszeit sorgt für schnelle Erholung nach Angriffen auf die Schwierigkeit
• Geplante Rückkehr der Halbwertszeit auf 2 Tage, sobald sich die Hashrate stabilisiert hat
• 100 % der Blockbelohnungen (keine Entwicklergebühr)

Für Nutzer:

• 32-MB-Blöcke für die Skalierbarkeit
• Niedrige Gebühren dank reichlich Blockplatz
• CashAddr für nutzerfreundliche Adressen
• Zügige Bestätigungen durch gleichmäßige Blockzeiten
• Der volle BCH-Script-Umfang, einschließlich Covenants und Introspection

Für das Ökosystem:

• Kein Premine, keine Zuteilung an Insider
• Steuerung durch die Gemeinschaft
• Entwicklung im offenen Quellcode
• Kompatibilität mit dem Bitcoin-Cash-Protokoll
• Ein klarer Weg zur vollständigen Angleichung an die BCHN-Parameter

BCH2 ist Kryptowährung, wie sie gedacht war: offen, zugänglich, fair und wirklich dezentral.

16. Quellen

1. Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System"
2. Bitcoin Cash Protocol Documentation, https://documentation.cash/
3. Sechet, A. (2020). "ASERT DAA Specification"
4. CashAddr Specification, https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/cashaddr.md
5. BC2 (BitcoinII) Technical Documentation
6. BCHN v29.0.0 ASERT Implementation Reference

17. Anhang A: Schnellstart

Einen Vollknoten betreiben

Download:

https://bch2.org/downloads/

Konfiguration (~/.bitcoincashII/bitcoincashII.conf):

server=1
daemon=1
listen=1
port=8339
rpcport=8342
rpcuser=your_username
rpcpassword=your_secure_password

# Seed nodes
addnode=144.202.73.66:8339
addnode=108.61.190.83:8339
addnode=64.176.215.202:8339
addnode=139.180.132.24:8339

Starten:

bitcoincashIId -daemon

Mining

Pool-Mining:

Pool: stratum+tcp://pool.bch2.org:3333
Worker: your_bch2_address
Password: x

Solo-Mining:

Richten Sie Ihren ASIC so ein, dass er sich mit dem RPC-Port Ihres lokalen Knotens verbindet.

Die BC2-Fork-Verteilung einfordern

Wenn Sie bei Block 53.200 BC2 hielten:

1. Exportieren Sie Ihre privaten BC2-Schlüssel (WIF-Format)
2. Importieren Sie sie in eine BCH2-Wallet
3. Ihr BCH2-Guthaben entspricht Ihrem BC2-Guthaben beim Fork

18. Anhang B: Technischer Vergleich

BCH2 und BCHN im Überblick

19. Anhang C: Häufige Fragen

Ist BCH2 ein Fork von Bitcoin Cash?

BCH2 ist ein Fork von BC2 (BitcoinII) bei Blockhöhe 53.200, der die Konsensregeln von Bitcoin Cash übernimmt. Die Blockchain-Geschichte von BC2 bleibt erhalten, die Protokollverbesserungen von BCH kommen hinzu.

Muss ich etwas tun, um mein BCH2 zu erhalten?

Nein. Wer bei Block 53.200 die privaten BC2-Schlüssel kontrollierte, besitzt durch den Fork automatisch denselben Betrag in BCH2. Importieren Sie die Schlüssel einfach in eine BCH2-Wallet.

Warum BC2 forken statt direkt BCH?

BC2 hatte von seinem Genesis-Block an eine faire Verteilung und erreichbares Mining. Indem BCH2 BC2 forkt und auf die BCH-Regeln wechselt, verbindet es faire Verteilung mit bewährten Protokollverbesserungen.

Wird SegWit unterstützt?

Nach dem Fork lassen sich keine neuen SegWit-Outputs erzeugen. Bestehende SegWit-UTXOs aus der Geschichte von BC2 (P2WPKH, P2WSH, P2TR und P2SH-umhüllte Varianten) können jedoch über den Mechanismus „Witness über scriptSig“ ausgegeben werden, der die Signaturdaten aus dem Witness-Feld in das klassische scriptSig verschiebt. Taproot-Ausgaben über den Key-Path werden unterstützt, über den Script-Path nicht – wer komplexe Taproot-Scripts nutzt, sollte die Coins vor dem Fork umziehen. Auch RBF ist deaktiviert.

Welche Wallet soll ich nutzen?

Jede Wallet, die das CashAddr-Format unterstützt, lässt sich für BCH2 anpassen. Offizielle Wallets erscheinen auf Basis der Electron-Cash-Codebasis.

Wie mine ich BCH2?

Verbinden Sie einen beliebigen SHA-256-ASIC mit pool.bch2.org:3333 oder minen Sie solo gegen Ihren eigenen Knoten.

Warum weicht die ASERT-Halbwertszeit von BCH ab?

BCH2 startet mit einer ASERT-Halbwertszeit von 1 Stunde (BCH: 2 Tage), um Angriffe durch Schwierigkeitsmanipulation abzuwehren, die eine junge Chain mit begrenzter Hashrate lahmlegen könnten. Bei Block 92.736 (etwa 9 Monate nach dem Fork) wechselt die Halbwertszeit automatisch auf 2 Tage – ohne Hard Fork.

Wann findet der Fork statt?

Der Fork erfolgt bei BC2-Blockhöhe 53.200; der angestrebte Start liegt etwa beim 7.–9. März 2026. BC2-Inhaber sollten bis dahin sicherstellen, dass sie ihre privaten Schlüssel selbst in der Hand haben.