Offenes Format für Anschaffungsdaten

Anschaffungsdaten aus Holdstamp: Dateiformate und Prüfung, Fassung 1.0

Status: veröffentlicht. Fassung 1.0, Stand 24.10.2026. Herausgeber: Timo Siegle, SiegleCommerce (Holdstamp). Lizenz: CC BY 4.0 (Abschnitt 13). Veröffentlicht unter holdstamp.de/format.

Dieses Dokument beschreibt, wie Holdstamp Dateien zu Anschaffungsdaten heute schreibt und wie ein Empfänger sie prüft. Es führt kein neues Format ein. Eine Prüfung nach diesem Dokument belegt Zeitpunkt und Unversehrtheit einer Datei, nicht die Richtigkeit ihrer Angaben.

1. Zweck und Geltung

Holdstamp erzeugt Dateien, mit denen ein Anleger Anschaffungsdatum und Anschaffungskosten von Kryptowerten belegt. Wer eine solche Datei bekommt (eine Börse bei der Einlieferung, eine Bank, eine Kanzlei, ein Finanzamt, Erben, ein Notar), soll sie ohne Holdstamp lesen und prüfen können. Dieses Dokument legt dafür fest:

• wie die Dateien aufgebaut sind (Kodierung, Kopfzeilen, Spalten, Felder),
• welche Fassungen es gibt und woran man sie erkennt,
• welche Prüfschritte ein Empfänger ohne Daten des Inhabers ausführen kann und was sie belegen.

Was die Formate belegen und was nicht. Eine Prüfung nach diesem Dokument zeigt, dass eine Datei in sich stimmig ist und, mit Zeitstempel, dass genau diese Datei spätestens zu einem Zeitpunkt vorlag und seither unverändert ist. Sie zeigt nicht, dass die Angaben stimmen: Anschaffungsdaten, Mengen und Kosten stammen aus den Daten, die der Inhaber in Holdstamp eingelesen hat. Holdstamp bestätigt keine Angaben, berechnet keine Steuerschuld und gibt keine steuerliche Würdigung ab.

Die Schlüsselwörter MUSS, DARF NICHT, SOLL und KANN sind wie in RFC 2119 zu lesen.

1.1 Bezug zum Gesetzgebungsverfahren

Der Referentenentwurf des Bundesministeriums der Finanzen vom 30.09.2026 (nicht beschlossen) sieht vor, dass inländische Anbieter ab 2028 Steuer auf Gewinne aus Kryptowerten abziehen und dabei Anschaffungszeitpunkt und Anschaffungskosten nach den Angaben des Kunden ansetzen; fehlen sie, gelten 50 % des Erlöses als Bemessungsgrundlage. Inhalt und Prüfung dieser Angaben soll eine Verordnung nach § 43a Abs. 2 EStG-E regeln, die es noch nicht gibt.

Der Einlieferungs-Begleitschein (Abschnitt 4) ist darum als Entwurf gekennzeichnet. Seine Form folgt der Verordnung, sobald sie vorliegt; dann entsteht eine neue Fassung dieses Dokuments. Für Österreich gelten § 93 Abs. 4a EStG und die Kryptowährungsverordnung (BGBl. II Nr. 455/2022); dort legt die Börse Inhalt und Form der Angaben fest.

2. Übersicht der Dateien

Weitere Dateien mit eigener erster Zeile (Herkunftsnachweis, Herkunftsnachweis zur geplanten Auszahlung, Kettennachweis, Stichtagsbericht) folgen denselben Grundregeln (Abschnitt 3). Ihre Spalten sind nicht Gegenstand dieser Fassung.

Dateinamen im Paket: holdstamp-nachweis-JJJJMMTT-lots.csv, holdstamp-nachweis-JJJJMMTT-stempelblatt.json, …-besitz.json, einlieferung-JJJJMMTT-<coin>.csv, eingangsblatt-JJJJMMTT.json, lot-auszug.json; der Zeitstempel einer Datei heißt wie sie mit angehängtem .tsr bzw. .ots. Dateinamen sind nicht Teil der Prüfung; ein Prüfer SOLL Dateien am Inhalt erkennen.

3. Grundregeln für CSV-Dateien

3.1 Zwei Formen

Beide Formen bleiben gültig, denn die Prüfsumme einer einmal ausgegebenen Datei hängt an ihren Bytes. Ein Leser MUSS beide Formen lesen. Die Form ist je Datensatz eindeutig: Steht ein ; außerhalb von Anführungszeichen, ist es die Excel-Form, sonst die Komma-Form.

Weitere Regeln, beide Formen:

• Zellen nach RFC 4180: Eine Zelle mit Trennzeichen, " oder Zeilenumbruch steht in Anführungszeichen, innere " verdoppelt. Die Komma-Form setzt auch Zellen mit ; in Anführungszeichen.
• Zahlen ohne Tausendertrennzeichen und ohne Exponent. Beträge in Euro mit zwei Nachkommastellen, wo die Datei sie rechnet (Begleitschein), sonst wie aus den Daten (Nachweis-CSV: 2495).
• Datumswerte JJJJ-MM-TT, UTC.
• Ja/Nein-Spalten tragen ja oder nein.
• Kommentarzeilen beginnen mit # (in der Excel-Form ggf. als "#…"). Ein Leser SOLL leere Zellen hinter einem Kommentar übergehen, die eine Tabellenkalkulation beim Speichern anhängt.
• Kopfzeilen (Kommentare) schreiben Zahlen in beiden Formen mit Dezimalpunkt (0.75 BTC); nur Zellen der Tabelle folgen der Form.
• Keine Erstellzeit, keine Namen von Personen: Derselbe Datenstand ergibt dieselbe Datei und dieselbe Prüfsumme.
• Der Begleitschein entschärft Zellen, die mit =, +, -, @ oder einem Steuerzeichen beginnen und keine Zahl sind, mit einem vorangestellten '. Die Nachweis-CSV tut das nicht; ihre Zellen stehen unverändert.

3.2 Prüfsumme

Die Prüfsumme einer CSV ist SHA-256 über die Bytes der Datei, wie sie im Paket liegt (mit BOM und Zeilenenden), hexadezimal in Kleinbuchstaben. Eine in einer Tabellenkalkulation geöffnete und neu gespeicherte Datei hat in der Regel eine andere Prüfsumme; für die Prüfung zählt die Originaldatei.

4. Einlieferungs-Begleitschein

4.1 Aufbau

Kopfzeilen in dieser Reihenfolge (Zeilen in eckigen Klammern nur, wenn zutreffend):

1. # Einlieferungs-Begleitschein (Entwurf): Anschaffungsdaten je eingeliefertem Lot
2. # Einlieferung: <Tag>; <Menge> <Coin> von <Absender> an <Ziel>; Tx-Hash: <Hash oder „nicht angegeben“>; <„geplant“ oder „erfolgt laut Daten“>
3. [# Vorab gestempelt: <Dateiname>; SHA-256: <64 Hex>] seit 09.10.2026, nur bei einer erfolgten Einlieferung, die sich auf einen vorher gestempelten Begleitschein bezieht
4. # Länderprofil: <Deutschland|Österreich>; Grundlage: <Rechtsgrundlage>
5. Deutschland: # Regelstand: <Name des Regelstands>; Österreich: # Einordnung: Altvermögen bei Anschaffung bis 28.02.2021, Neuvermögen danach, offen bei nur spätestem Datum danach (Datum in UTC)
6. [Österreich] # Neuvermögen: <Menge> <Coin>; gleitender Durchschnittspreis im Konto <Absender> am <Tag>: <Preis> EUR je <Coin>|unbekannt (…); [Anschaffungskosten nach Durchschnittspreis: <Betrag> EUR|unbekannt; ][Anschaffungszeitraum: <von> bis <bis>; ]Kosten aus steuerneutralem Tausch im Durchschnitt: ja|nein
7. # Summe: <Menge> <Coin> in <n> Zeilen; Anschaffungskosten bekannt für <Menge> <Coin>: <Betrag> EUR; unbekannt für <Menge> <Coin>
8. # <Kennzeichnung des Länderprofils> (Entwurf, was die Börse braucht, wer entscheidet)
9. # <Erläuterung der Kosten>
10. # <Hinweis: Datenaufbereitung ohne Steuerberatung>

Freitext in den Kopfzeilen (Coin, Absender, Ziel, Tx-Hash, Dateiname) steht ohne ,, ;, " und Zeilenumbruch; solche Zeichen werden zu einem Leerzeichen.

Danach die Spaltenzeile und je eingeliefertem Lot eine Zeile.

Spalten, Profil Deutschland: nr;coin;menge;lot_menge;teil_lot;anschaffung;anschaffung_spaetestens;kosten_eur;kosten_bekannt;status;steuerfrei_ab;nachweis;herkunft;transfers;tx_hashes;lot_id

Spalten, Profil Österreich: nr;coin;menge;lot_menge;teil_lot;anschaffung;anschaffung_spaetestens;kosten_eur;kosten_bekannt;vermoegen_at;tausch;tausch_steuerneutral;kosten_at_eur;durchschnittspreis_eur;ursprung;nachweis;herkunft;transfers;tx_hashes;lot_id

4.2 Beispiel (erfundene Daten, Hashes und Hinweise gekürzt)

# Einlieferungs-Begleitschein (Entwurf): Anschaffungsdaten je eingeliefertem Lot
"# Einlieferung: 2026-10-06; 0.75 BTC von Wallet C an Börse B; Tx-Hash: b2b2…b2b2; geplant"
"# Länderprofil: Deutschland; Grundlage: Referentenentwurf des BMF vom 30.09.2026, § 43a Abs. 2 EStG-E (nicht beschlossen)"
# Regelstand: Deutschland, BMF-Referentenentwurf September 2026 (nicht beschlossen)
"# Summe: 0.75 BTC in 4 Zeilen; Anschaffungskosten bekannt für 0.5 BTC: 29000.00 EUR; unbekannt für 0.25 BTC"
"# Entwurf: Laut Referentenentwurf (nicht beschlossen) … Die Börse entscheidet, ob sie den Beleg annimmt."
# Die Kosten je Lot stammen aus den Kaufbelegen, zugeordnet nach FIFO je Wallet. …
# Datenaufbereitung ohne Steuerberatung. …
nr;coin;menge;lot_menge;teil_lot;anschaffung;anschaffung_spaetestens;kosten_eur;kosten_bekannt;status;steuerfrei_ab;nachweis;herkunft;transfers;tx_hashes;lot_id
1;BTC;0,1;0,1;nein;2020-12-01;ja;;nein;Altbestand, Haltefrist abgelaufen;2021-12-02;Einzahlung ohne Herkunft;Bestand ohne Historie am 01.12.2020 in Wallet C;;;fx-d1#0
2;BTC;0,2;0,2;nein;2021-02-28;nein;8000,00;ja;Altbestand, Haltefrist abgelaufen;2022-03-01;Import;Kauf am 28.02.2021 in Börse A;2026-01-15 Börse A > Wallet C;a1a1…a1a1;fx-b1#0>fx-t1#0
3;BTC;0,3;0,3;nein;2025-11-03;nein;21000,00;ja;Altbestand, Haltefrist läuft;2026-11-04;Import;Kauf am 03.11.2025 in Börse A;2026-01-15 Börse A > Wallet C;a1a1…a1a1;fx-b2#0>fx-t1#1
4;BTC;0,15;;nein;2026-10-06;ja;;nein;Altbestand, Haltefrist läuft;2027-10-07;Ohne Lot im Absender-Wallet;;;;

Die Datei beginnt mit BOM, jede Zeile endet mit CRLF.

4.3 Vorab gestempelt

Eine geplante Einlieferung KANN vor dem Transfer gestempelt werden. Der spätere Begleitschein zur erfolgten Einlieferung nennt dann in Kopfzeile 3 Namen und SHA-256 des vorab gestempelten, etwa # Vorab gestempelt: einlieferung-20261006-btc.csv; SHA-256: c941ec0d…0421071f. Im Paket liegen dessen Zeitstempel unter vorab-gestempelt/<Dateiname>.tsr|.ots; die CSV selbst liegt im früheren Paket.

4.4 Prüfschritte

Ein Prüfer MUSS die Datei an der ersten Zeile erkennen und Kopfzeilen 2 und 4 lesen können, sonst ist sie kein Begleitschein. Danach, nur aus der Datei:

1. Zahl der Zeilen gleich der Zahl in Summe.
2. Jede Zeile nennt den Coin der Einlieferung.
3. menge ≤ lot_menge, wo lot_menge gefüllt ist.
4. Summe von menge = Menge der Einlieferung = Menge in Summe.
5. Summe kosten_eur der Zeilen mit kosten_bekannt = ja = Betrag in Summe; ebenso die Mengen mit und ohne bekannte Kosten. Gerechnet wird dezimal (mindestens 40 Stellen), nie mit Gleitkommazahlen.
6. Deutschland: status und steuerfrei_ab jeder Zeile folgen aus anschaffung, anschaffung_spaetestens, dem Regelstand (Name in Kopfzeile 5) und dem Tag der Einlieferung. Kennt der Prüfer den Regelstand nicht, prüft er diesen Schritt nicht und sagt das.
7. Österreich: vermoegen_at folgt aus dem Anschaffungsdatum (Altvermögen bis 28.02.2021; nur ein spätestes Datum danach ergibt offen). Menge des Neuvermögens (Zeilen Neuvermögen und offen) = Menge in Kopfzeile 6; durchschnittspreis_eur jeder solchen Zeile mit Lot = Preis der Kopfzeile; kosten_at_eur = menge × Durchschnittspreis mit einer Abweichung von höchstens menge × 0,005 + 0,005 EUR (die Kopfzeile nennt den Preis auf Cent gerundet); Summe kosten_at_eur = Kosten in Kopfzeile 6.
8. Mit PDF: Die SHA-256 der CSV gleicht der im Stichwort holdstamp-begleitschein:1: des PDF (Abschnitt 9).
9. Mit Zeitstempel: Der Stempel gilt der SHA-256 der CSV (Abschnitt 8). Bei einer geplanten Einlieferung SOLL der Prüfer sagen, ob der Stempel vor ihrem Tag liegt.
10. Mit vorab gestempeltem Begleitschein: Seine SHA-256 gleicht der in Kopfzeile 3. Er beschreibt eine geplante Einlieferung mit demselben Absender, Coin und derselben Menge. Andere Lots als dort sind ein Hinweis, kein Fehler: Vorgänge zwischen Plan und Einlieferung ändern, welche Lots nach FIFO mitgehen.
11. Mit Lot-Auszug (Abschnitt 6): Die lot_id einer Zeile gleicht der des Auszugs oder beginnt mit ihr und > (dasselbe Lot nach späteren Transfers); dann SOLL die Anschaffung übereinstimmen.

Nicht prüfbar ohne Daten des Inhabers: welche Lots nach FIFO mitgehen, die Kosten aus den Kaufbelegen, ob die Transfers stattfanden.

5. Nachweis-CSV

5.1 Aufbau

# Anschaffungsnachweis, vollständig je Lot
# Auswertungstag: <Tag>; Regelstand: <Name>; <Auswahl in Worten>
# <Hinweis: Datenaufbereitung ohne Steuerberatung>
# Prüfangaben: {"asOf":"<Tag>","ruleSet":"<Kennung>","coins":[…],"accounts":[…]}
coin;konto;menge;anschaffung;anschaffung_spaetestens;kosten_eur;status;steuerfrei_ab;nachweis;beleg;quelle;transferkette;lot_id

Prüfangaben ist JSON in fester Feldfolge; leere Listen heißen „alle“. In der Excel-Form stehen Kopfzeilen mit ; oder " als eine Zelle in Anführungszeichen (innere " verdoppelt). Dateien vor dem 04.10.2026 tragen als erste Zeile # Coin-Pass, vollständiger Nachweis je Lot (Komma-Form).

Beispiel einer Lot-Zeile (erfundene Daten, Excel-Form):

BTC;Börse A (Hauptkonto);0,0499;2021-03-15;nein;2495;Altbestand, Haltefrist abgelaufen;2022-03-16;Import;;fx-1;;fx-1#0

5.2 Prüfschritte

1. Prüfsumme (3.2) bilden.
2. PDF dazu: Stichwort holdstamp-nachweis:1: (vor dem 04.10.2026 coinpass-nachweis:1:) nennt dieselbe Prüfsumme, denselben Auswertungstag und Regelstand.
3. Zeitstempel dazu (Abschnitt 8).
4. Zahl der Lots und Mengen je Coin ausgeben; die Kopfzeilen nennen Auswertungstag und Regelstand.

Wer Zugriff auf die Daten hat (der Inhaber in Holdstamp), bildet die CSV aus dem Datenstand neu und vergleicht Byte für Byte; dafür MUSS die Form der Datei unverändert bleiben. Ein Empfänger ohne die Daten kann das nicht.

6. Stempelblatt und Lot-Auszug

6.1 Stempelblatt (Art lots)

JSON, zwei Leerzeichen Einzug, Zeilenende \n am Ende, Felder in dieser Reihenfolge. Gestempelt wird genau dieser Text.

{
  "format": "holdstamp-stempelblatt",
  "version": 1,
  "kind": "lots",
  "explanation": "Begleitblatt zum Anschaffungsnachweis: …",
  "csv": { "name": "holdstamp-nachweis-20251231-lots.csv", "sha256": "4ea17e32…eba39318" },
  "asOf": "2025-12-31",
  "ruleSet": "DE_GELTEND_2026",
  "lots": 6,
  "merkle": {
    "root": "c559a87d6757849a2fd6a6b0d8ef7eb21f1eeda483bbe967d57e18b286ce57c5",
    "leaf": "SHA-256(0x00 ‖ Salz ‖ Lot-Zeile in UTF-8 ohne Zeilenende)",
    "node": "SHA-256(0x01 ‖ links ‖ rechts); ohne Partner geht ein Knoten unverändert eine Ebene höher"
  }
}

(Im Original steht csv über mehrere Zeilen.)

Merkle-Baum. Die Blätter sind die Lot-Zeilen der CSV in Dateireihenfolge, jede genau so, wie sie in der Datei steht (in der Excel-Form mit ; und Dezimalkomma), ohne Zeilenende; ein Datensatz mit Zeilenumbruch in Anführungszeichen bleibt ein Blatt. Blatt i = SHA-256(0x00 ‖ Salz_i ‖ Zeile_i in UTF-8), Knoten = SHA-256(0x01 ‖ links ‖ rechts). Bleibt auf einer Ebene ein Knoten ohne Partner, geht er unverändert eine Ebene höher (kein Verdoppeln wie bei Bitcoin). Salz_i hat 32 Byte und ist HMAC-SHA256(Startwert, „holdstamp-lot-salz:i“) mit einem geheimen Startwert von 32 Byte, den nur der Tresor des Inhabers kennt; ein Auszug verrät nur sein eigenes Salz.

6.2 Nachtrag Besitz (Art besitz)

Felder format, version (1), kind (besitz), explanation, csv, asOf, message, signatures [{account, chain (btc|eth), address, signature}], nach Adresse geordnet. Die Nachricht lautet Holdstamp Altbestand <SHA-256 der CSV> <TT.MM.JJJJ> (vor dem Stichtag Holdstamp Bestand …). Signaturen: Bitcoin nach BIP-137 oder BIP-322 „simple“ (bc1q, bc1p über den Key-Path), Ethereum nach EIP-191. Der Zeitstempel des Nachtrags begrenzt die Signaturen nach oben, die Prüfsumme der CSV nach unten. Eine Signatur belegt Verfügung über den Schlüssel, nicht, welche Coins unter der Adresse lagen.

6.3 Lot-Auszug

{
  "format": "holdstamp-lot-auszug",
  "version": 1,
  "explanation": "Dieser Auszug belegt, dass das genannte Lot zu dem Bestand gehörte, …",
  "verify": "https://holdstamp.de/pruefen",
  "lot": { "columns": "<Spaltenzeile der CSV>", "line": "<Lot-Zeile genau wie in der CSV>", "salt": "<64 Hex>", "number": 2, "of": 6 },
  "path": [ { "left": "<64 Hex>" }, { "right": "<64 Hex>" }, … ],
  "sheet": "<Text des Stempelblatts, genau wie gestempelt>",
  "timestamp": { "tsr": "<Base64>", "ots": "<Base64>" }
}

path führt vom Blatt zur Wurzel; left heißt, der Nachbar steht links (Knoten = H(0x01 ‖ Nachbar ‖ eigener)). Höchstens 64 Schritte. timestamp gilt dem Stempelblatt; Felder darin sind optional.

6.4 Prüfschritte

1. sheet als Stempelblatt der Art lots lesen.
2. Wurzel aus lot.salt, lot.line und path bilden; sie MUSS merkle.root im Stempelblatt gleichen.
3. Zeitstempel in timestamp gegen SHA-256 von sheet prüfen (Abschnitt 8).
4. Liegt die CSV bei: Ihre SHA-256 gleicht csv.sha256 im Stempelblatt, und lot.line steht als Zeile in ihr.
5. Die Spalten von lot.columns und lot.line ergeben die Angaben des Lots.

7. Eingangsblatt

JSON wie 6.1. Felder: format (holdstamp-eingangsblatt), version, explanation, files [{name, size (Byte), sha256 (der Datei, wie sie gewählt war; bei ZIP das Archiv), account, importedAt (ISO 8601, UTC), [transaction]}]. Jede Prüfsumme einmal (frühester Import zählt), geordnet nach importedAt, name, sha256. Version 1: nur Originaldateien der Börse. Version 2 (seit 07.10.2026): auch abgelegte Belege; ein Eintrag mit transaction (Vorgang in Worten) ist ein Beleg, importedAt dann der Zeitpunkt des Ablegens. Ein Blatt nur mit Börsendateien bleibt Version 1.

Prüfschritte: Zeitstempel gegen SHA-256 des Blatts; je beiliegender Datei die SHA-256 mit dem Eintrag vergleichen (gleicher Name, andere Prüfsumme = verändert oder eine andere Datei). Belegt wird nur, dass Dateien mit diesen Prüfsummen spätestens zum Zeitpunkt des Stempels vorlagen, nicht, dass ihr Inhalt stimmt.

8. Zeitstempel

Gestempelt wird immer die SHA-256 einer Datei (CSV, Stempelblatt, Nachtrag, Eingangsblatt). Der Server von Holdstamp sieht nur diese Prüfsumme und speichert nichts.

8.1 RFC 3161 (.tsr)

• Datei: TimeStampResp (DER) wie vom Dienst erhalten, mit Status und TimeStampToken.
• Anfrage: Version 1, MessageImprint mit SHA-256 (OID 2.16.840.1.101.3.4.2.1, Parameter NULL), Nonce (8 Byte), certReq = TRUE; das Zertifikat des Dienstes liegt also im Stempel.
• Dienste in dieser Reihenfolge, der nächste nur, wenn der vorige nicht erteilt: optional ein eigener Dienst des Betreibers, Sectigo qualifiziert (timestamp.sectigo.com/qualified), Sectigo (timestamp.sectigo.com), FreeTSA (freetsa.org/tsr). Andere Dienste sind nicht angebunden.
• Prüfen: Signatur des Tokens zusammen mit der gestempelten Datei; MessageImprint = SHA-256 der Datei; Signaturzertifikat mit erweiterter Schlüsselverwendung „timeStamping“ (1.3.6.1.5.5.7.3.8) und Kette zum Zeitpunkt des Stempels bis zu einer beim Prüfer hinterlegten Wurzel. „Qualifiziert nach eIDAS“ folgt nur aus der hinterlegten Wurzel, nie aus Angaben im Stempel. Eine vom Stempel mitgelieferte, anders gegengezeichnete Kopie der Wurzel DARF den Weg nicht an der hinterlegten Wurzel vorbeiführen.
• Mit OpenSSL ab 3: openssl ts -reply -in <datei>.tsr -text zeigt Zeit und Prüfsumme; openssl ts -verify -data <datei> -in <datei>.tsr -CAfile <Wurzel des Dienstes> prüft die Signatur.

8.2 OpenTimestamps (.ots)

• Datei im Format von python-opentimestamps (DetachedTimestampFile): Kopf, Version 1, Operation SHA-256, die Prüfsumme der Datei, dann APPEND(Nonce, 16 Byte), SHA256 und die Antworten der Kalender als Zweige. Die Kalender sehen nur SHA-256(Prüfsumme ‖ Nonce).
• Kalender: a.pool.opentimestamps.org, b.pool.opentimestamps.org, a.pool.eternitywall.com. Ein Beleg steht aus, bis ein Kalender ihn in einem Bitcoin-Block verankert hat; Holdstamp rüstet ihn später nach.
• Ohne Netz prüfbar: dass der Beleg zur Prüfsumme gehört, welche Kalender ausstehen, welche Blöcke er nennt und welche Merkle-Wurzel der Block tragen muss. Nur mit der Blockkette prüfbar: ob der Block diese Wurzel trägt (ots verify mit eigenem Knoten).

9. PDF

Das PDF ist für Menschen. Es ist nicht gestempelt. Maschinenlesbar trägt es im Feld „Keywords“ ein Stichwort der Form <Präfix><URL-kodiertes JSON>:

sha256 ist die Prüfsumme der zugehörigen CSV. Ältere Begleitscheine nennen sie nur als Text im PDF.

10. Fassungen und Erkennung

• Eine Datei ändert ihre Form nie, nachdem sie ausgegeben ist; neue Angaben kommen in eine neue Fassung oder ein Begleitdokument (Stempelblatt), damit alte Prüfsummen gültig bleiben.
• JSON-Formate tragen version. Neue Felder nur mit neuer Version; ein Leser DARF eine unbekannte Version NICHT als bekannte lesen.
• CSV-Formate tragen keine Versionsnummer; die Fassung folgt aus erster Zeile, Form (3.1) und optionalen Kopfzeilen (Vorab gestempelt seit 09.10.2026). Der Kettennachweis trägt seit 20.10.2026 # Fassung: 2, wenn er ein Ende „Verlust laut Angabe“ enthält; sonst bleibt er Fassung 1 ohne diese Zeile.
• Dieses Dokument hat die Fassung 1.0. Eine Verordnung nach § 43a Abs. 2 EStG-E, die eine andere Form verlangt, führt zu einer neuen Fassung des Begleitscheins mit eigener erster Zeile; die bisherigen bleiben lesbar.

11. Prüfer zum Herunterladen

Holdstamp veröffentlicht unter holdstamp.de/format einen eigenständigen Prüfer, der die Prüfschritte dieses Dokuments ausführt: eine einzelne HTML-Datei, die ohne Netz im Browser läuft.

• Fassungen: Die Datei trägt ihre Fassung im Namen (holdstamp-pruefer-1.0.0.html). Eine veröffentlichte Fassung ändert sich nie; geänderter Code erscheint nur als neue Fassung mit neuer Nummer. Neben jeder Datei steht ihre SHA-256 im Format von shasum -a 256 und eine Datei mit den Lizenzhinweisen.
• Reproduzierbar: Derselbe Quellstand ergibt Byte für Byte dieselbe Datei; die Datei enthält weder Zeitpunkt noch Pfade des Rechners, auf dem sie entstand.
• Ohne Netz: Skript und Stil stehen in der Datei. Eine Content Security Policy als <meta> erlaubt nur genau dieses Skript und diesen Stil (per SHA-256) und verbietet jede Verbindung (default-src 'none', connect-src 'none', form-action 'none'). Sie gilt auch beim Öffnen über file://, wo es keine Header gibt.
• Vertrauen: Ein Prüfer, der im zu prüfenden Paket mitkommt, ist nicht vertrauenswürdig; ein gefälschtes Paket könnte einen Prüfer mitbringen, der immer „gültig“ meldet. Den Prüfer nie aus einem zu prüfenden Paket nehmen. Ein Empfänger lädt ihn selbst herunter und vergleicht seine SHA-256 mit der veröffentlichten Prüfsumme.
• Grenze: Die Wurzeln der Zeitstempeldienste sind im Prüfer hinterlegt. Ein Prüfer von heute erkennt einen Stempel mit einer später eingeführten Wurzel nicht mit Namen; die Signatur lässt sich dann mit OpenSSL prüfen (8.1).

12. Langzeitprüfbarkeit

Altbestand bleibt Altbestand, bis er veräußert wird; das kann Jahrzehnte dauern, bei Erben länger. Was heute gilt:

• RFC 3161: Die Signatur eines Stempels hängt an Zertifikat und Signaturverfahren des Dienstes und an SHA-256. Laufen Zertifikate ab oder werden Verfahren schwach, verliert der Stempel an Beweiswert, nicht an Inhalt.
• OpenTimestamps: hängt nur an SHA-256 und der Bitcoin-Blockkette, nicht an Zertifikaten.
• Prüfbarkeit ohne Holdstamp: Der Prüfer und OpenSSL arbeiten ohne Holdstamp; der Prüfer braucht für neue Dienste eine neue Fassung mit deren Wurzel.
• Erneuern: Ein Erneuern der Stempel nach RFC 4998 (Evidence Record Syntax) ist in dieser Fassung nicht beschrieben. Wer Nachweise lange aufbewahrt, bewahrt CSV, Stempelblätter, Lot-Auszüge und Zeitstempel als Originaldateien auf, nicht nur ihre Prüfsummen. Eine Konformität mit BSI TR-03125 (TR-ESOR) wird nicht behauptet.

13. Lizenz

Copyright 2026 Timo Siegle, SiegleCommerce. Dieses Dokument steht unter der Lizenz Creative Commons Namensnennung 4.0 International (CC BY 4.0). Es darf geteilt und bearbeitet werden, auch kommerziell, mit Namensnennung: „Anschaffungsdaten aus Holdstamp, Fassung 1.0, Timo Siegle, SiegleCommerce, holdstamp.de/format, CC BY 4.0“ und einem Hinweis, ob es geändert wurde. Die Lizenz umfasst keine Rechte an Namen oder Marken.

Der Prüfer zum Herunterladen (Abschnitt 11) steht in seinen Holdstamp-Teilen unter der Apache License 2.0; er enthält Bibliotheken anderer Urheber unter deren Lizenzen. Die Hinweise stehen in der Datei und in der Hinweisdatei daneben.