---
title: "Blockbestätigungen"
description: "Ein prüfungsorientierter Leitfaden zu PoW-Bestätigungstiefe, PoS-Zuständen safe und finalized, Mempool-Ersetzung, Reorganisationen und den Gutschriftrichtlinien von Handelsplattformen."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Blockbestätigungen
> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.
## Direkte Antwort
Eine Blockbestätigung ist eine beobachter- und protokollspezifische Aussage, dass eine Transaktion in einem Block der aktuell vom Beobachter gesehenen kanonischen Chain enthalten ist. Die übliche inklusive Konvention von Bitcoin Core zählt den aufnehmenden Block als erste Bestätigung. Für Inclusion-Höhe `h` und Best-Chain-Höhe `H` beträgt die Tiefe `H - h + 1`. Manche Dienste zeigen nur Nachfolger als `H - h`; deshalb muss die Konvention genannt werden.
Proof-of-Work-Tiefe senkt unter benannten Annahmen das Reorganisationsrisiko, schafft aber keinen magischen Punkt absoluter Finalität. Proof-of-Stake-Systeme können stattdessen protokolleigene Zustände ausweisen. Ethereum unterscheidet `latest`, `safe` und `finalized`; eine feste Anzahl von Blöcken, Slots oder Minuten ersetzt diese Labels nicht. Erkannt, gutgeschrieben, handelbar und auszahlbar sind interne Plattformzustände, die auch nach Erreichen des Chain-Schwellenwerts getrennt bleiben.
## Funktionsweise
1. Fixiere Chain und Netzwerk, Asset, Transaktionskennung, Node oder API, Beobachtungszeit, Konsensmodell und Zählkonvention. Prüfe Empfänger, Betrag sowie Memo oder Tag, bevor du einen passenden Hash als beabsichtigte Zahlung behandelst.
2. Trenne signiert, übertragen, vom lokalen Mempool eines Nodes akzeptiert und propagiert. Mempools sind Policy-Sichten, keine globale Konsenswarteschlange. Prüfe Gebührenstatus, unbestätigte Vorfahren, Replace-by-Fee oder Ersetzung mit gleicher Nonce und konkurrierende Ausgaben.
3. Prüfe Inclusion anhand von Blockhash, Höhe, Transaktionsindex und kanonischer Abstammung, nicht nur anhand der Höhe oder eines Explorer-Symbols. Prüfe bei Account-Chains auch Receipt-Status, Logs und tatsächliche State-Änderung; enthaltene Ausführung kann dennoch revertieren.
4. Wende das Konsensmodell an. Gib bei PoW die Konvention an, berechne die Tiefe und vergleiche unabhängige Sichten auf Best Chain und kumulierte Arbeit. Frage bei PoS die nativen Zustände head, safe, justified oder finalized ab; leite sie nicht aus fester Block- oder Slot-Distanz ab.
5. Erfasse den Lebenszyklus explizit: erstellt, übertragen, lokal im Mempool akzeptiert, enthalten, kanonische Tiefe oder safe/finalized, reorganisiert, wieder aufgenommen, ersetzt oder in Konflikt. Eine Reorganisation garantiert nicht die Rückkehr der ursprünglichen Transaktion in jeden Mempool.
6. Halte das Plattformkonto getrennt: beobachtet, Netzwerkschwelle erreicht, gutgeschrieben, handelbar und auszahlbar. Wende die aktuelle asset-, netzwerk-, betrags- und vorfallspezifische Richtlinie an; Wartung, Compliance und manuelle Prüfung können unabhängige Verzögerungen verursachen.
7. Vergleiche unabhängige Nodes oder Provider und überwache bis zum geforderten Zustand weiter. Protokolliere Hashes, Höhen, Zeitstempel, RPC-Labels und Policy-Snapshot; simuliere Ersetzung, Reorganisation, Finalitätsverzögerung, veralteten Node, Bridge-Relay und Plattformausfall.
## Rechenbeispiele
- **Zählkonvention.** Eine Bitcoin-Transaktion liegt im kanonischen Block `h = 900,000`, der Best-Chain-Tip ist `H = 900,005`. Die inklusive Tiefe beträgt `900,005 - 900,000 + 1 = 6 confirmations`; eine Anzeige, die nur Nachfolger zählt, meldet `900,005 - 900,000 = 5`. Die Differenz ist terminologisch, sofern Blockhash und Abstammung identisch sind.
- **Reorganisation und Wiederaufnahme.** Zunächst hat die Transaktion `1 confirmation` in Block `900,000`; dann verlässt dieser die Best Chain und der Wert fällt auf `0`, sofern die Transaktion gültig und konfliktfrei bleibt. Wird sie in `900,003` wieder aufgenommen und erreicht der Tip `900,006`, beträgt die inklusive Tiefe `900,006 - 900,003 + 1 = 4 confirmations`. Ersetzt sie ein bestätigter Konflikt, kann Bitcoin Core negative Bestätigungen melden.
- **PoS-Labels sind keine Blockzahlen.** Eine Ethereum-Transaktion liege in Execution Block `20,000,000`; ein Node melde auf einer Abstammung `latest = 20,000,020`, `safe = 20,000,012` und `finalized = 19,999,980`. Die numerische latest-Tiefe beträgt `20,000,020 - 20,000,000 + 1 = 21`; die Transaktion ist safe, aber nicht finalized. Erforderlich sind Hash-Abstammung und Konsenslabels; Höhen allein genügen nicht.
- **Chain-Schwelle und Plattformgutschrift.** Die Richtlinie verlangt `6 confirmations`. Eine Einzahlung in Block `900,000` steht bei `5/6`, wenn der Tip `900,004` ist, und erreicht `6/6` bei `900,005`. Folgt eine `15-minute compliance hold`, bleiben Chain-Berechtigung sowie Gutschrift-, Handels- und Auszahlungszeit unterschiedliche Zustände; die Sperre ist keine siebte Bestätigung.
## Risiken
- Prüfung der falschen Chain, des falschen Netzwerks oder Assets.
- Verwendung eines falschen Transaktionshashes, Empfängers, Memos oder Tags.
- Behandlung einer signierten, aber nicht übertragenen Transaktion als pending.
- Behandlung des Mempools eines Nodes als globalen Netzwerkzustand.
- Übersehen von Policy-Ablehnung, Eviction oder fehlender Propagation.
- Übersehen einer RBF-, Same-Nonce- oder Konfliktersetzung.
- Fehlinterpretation unbestätigter Vorfahren, Nachfolger oder Package Fees.
- Vermischung inklusiver und nur Nachfolger zählender Konventionen.
- Vertrauen in einen veralteten, synchronisierenden oder isolierten Node.
- Vergleich von Höhen ohne Prüfung von Blockhashes und Abstammung.
- Verlust von Bestätigungen durch eine kurze PoW-Reorganisation.
- Behandlung einer festen Tiefe als absolute Sicherheit für jeden Wert und Gegner.
- Verwechslung von verstrichener Zeit, Slots, Epochen und erzeugten Blöcken.
- Behandlung eines PoS-Head-Blocks als safe.
- Behandlung eines safe Blocks als finalized.
- Übersehen einer Finalitätsverzögerung bei fortlaufender Blockproduktion.
- Behandlung enthaltener, aber revertierter Ausführung als Anwendungserfolg.
- Verwechslung von Token-Logs oder Explorer-UI mit dem resultierenden State.
- Gleichsetzung von Plattformerkennung, Gutschrift, Handel und Auszahlung.
- Behandlung der Source-Chain-Bestätigung als Abschluss eines Bridge-, Emittenten- oder Zielflows.
## Häufige Irrtümer
- Ein auffindbarer Transaktionshash oder lokaler Mempool-Eintrag ist bereits bestätigt.
- Eine Zählkonvention und sechs Bestätigungen gelten für jede Chain, jeden Betrag und Dienst.
- Eine höhere Gebühr lässt spätere Blöcke oder PoS-Finalität schneller eintreffen.
- Eine feste Ethereum-Block- oder Slot-Zahl entspricht `safe` oder `finalized`.
- Inclusion oder Finalität garantiert erfolgreiche Contract-Ausführung, korrekte Empfängerdaten, Plattformgutschrift oder Bridge-Abschluss.
## Verwandte Themen
- [Mempool](/de/crypto/mempool/)
- [Bitcoin](/de/crypto/bitcoin/)
- [Finalität](/de/crypto/finality/)
## Quellen
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (abgerufen: 2026-08-13)
- [Payment Processing](https://developer.bitcoin.org/devguide/payment_processing.html) - Bitcoin Developer Documentation (abgerufen: 2026-08-13)
- [gettransaction](https://developer.bitcoin.org/reference/rpc/gettransaction.html) - Bitcoin Developer Documentation (abgerufen: 2026-08-13)
- [BIP 125: Opt-in Full Replace-by-Fee Signaling](https://bips.dev/125/) - Bitcoin Improvement Proposals (abgerufen: 2026-08-13)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (abgerufen: 2026-08-13)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (abgerufen: 2026-08-13)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (abgerufen: 2026-08-13)
- [Cryptocurrency deposit processing times](https://support.kraken.com/articles/203325283-cryptocurrency-deposit-processing-times) - Kraken Support (abgerufen: 2026-08-13)
Source: https://wiki.fcontext.com/de/crypto/block-confirmation/index.mdx