Ein BRC20-Token-Dual-Offline-Zahlungsprotokoll basierend auf verbesserten Hash-Time-Lock-Verträgen (HTLC) und teilweise signierten Bitcoin-Transaktionen (PSBT)
Zusammenfassung
Dieses Whitepaper präsentiert ein technisches Protokoll namens Bitcoin-itip, das darauf abzielt, BRC20-Token in einer vollständig Offline-Umgebung für Peer-to-Peer-Werttransfers zu implementieren. Dieses Protokoll kombiniert verbesserte Hash-Time-Lock-Verträge (HTLC) von nativen Bitcoin-Skripten, teilweise signierte Bitcoin-Transaktionen (PSBT) und einen zustandsverpflichtenden Mechanismus, der auf einem BRC20-Indexer basiert, um eine sichere, überprüfbare und letztendlich von der Bitcoin-Hauptnetz-Settlement abgeschlossene duale Offline-Zahlungsschicht zu schaffen. Diese Lösung ist unabhängig von zentralisierten Servern oder Sidechains und folgt strikt den Sicherheitsannahmen des Bitcoin-Netzwerks und den Spezifikationen des BRC20-Protokolls, um innovative Lösungen für den Fluss digitaler Vermögenswerte in Szenarien ohne Netzwerk, mit schwachem Netzwerk oder hoher Latenz zu bieten.
1. Einleitung: Probleme und Ziele
Der BRC20-Token-Standard nutzt das Ordinals-Protokoll von Bitcoin, um die Token-Daten in Satoshis einzuprägen, jedoch hängt die Übertragung vollständig davon ab, dass Transaktionen im Bitcoin-Netzwerk gesendet werden, um den Status des Indexers zu aktualisieren. Dies führt dazu, dass die Zahlungsfunktion in Szenarien ohne Internetverbindung (z. B. abgelegene Gebiete, Notfallzahlungen, spezifische Hochsicherheitsumgebungen) nicht funktioniert. Traditionelle doppelte Offline-Zahlungslösungen stehen vor den beiden zentralen Herausforderungen "Double-Spending-Angriffe" und "Status-Synchronisationsverzögerungen".
Das Ziel des Bitcoin-itip-Protokolls ist:
1. Vollständige Offline-Zahlungen ermöglichen: Erlaubt es, die Eigentumsversprechen der BRC20-Token sicher zwischen zwei Offline-Geräten zu übertragen.
2. Verhinderung von Double-Spending-Angriffen: Durch Kryptographie und On-Chain-Verträge sicherstellen, dass jede Offline-Transaktion bei der endgültigen On-Chain-Übertragung Einzigartigkeit und Determinismus hat.
3. Sicherstellen der Kompatibilität mit BRC20: Alle Offline-Operationen werden schließlich in On-Chain-Transaktionen umgewandelt, die den BRC20-Standards entsprechen.
4. Minimierung der Vertrauensannahmen: Vertraut nur auf die Sicherheit des Bitcoin-Netzwerks und den temporären Zustand der Geräte beider Parteien.
2. Kernprinzipien
Das Kernstück des Protokolls besteht darin, eine einmalige Offline-Zahlung in drei untrennbare Phasen zu zerlegen. Ihre logische Beziehung und der Datenfluss sind in der nachstehenden Grafik dargestellt:
```mermaid
flowchart TD
subgraph A [Erste Phase: Online-Vorbereitung]
direction LR
A1["Erstellen und kapitalisieren <br\u003e Mehrfachsignatur-Wallet"] --\u003e A2["Generieren und synchronisieren <br\u003e Anfangs-Guthaben-Zertifikat (S0)"]
end
subgraph B [Zweite Phase: Offline-Zahlung]
direction LR
B1["Überprüfung der Empfangsbestätigung des Zahlungsempfängers (Rx)<br\u003e mit dem aktuellen Status (Sx)"] --\u003e B2["Kooperativ erstellen und austauschen<br\u003eP
SBT und entschlüsselter Ciphertext (Cx)”]
B2 --\u003e B3["Aktualisieren des lokalen Status auf Sx+1"]
end
subgraph C [Dritte Phase: Online-Abrechnung]
C1["Broadcasten des endgültigen Statusnachweises (Sfinal) <br\u003e im Bitcoin-Netzwerk"] --\u003e C2["BRC20-Indexer <br\u003e analysieren und das Guthaben aktualisieren"]
end
A -- "Initialisierung des Offline-Wallet-Status" --\u003e B
B -- "Abrechnung des endgültigen Status On-Chain" --\u003e C
Erste Phase (Online-Vorbereitung) ist die Grundlage für alle Offline-Operationen. Die beiden Zahlungspartner müssen im Voraus eine Bitcoin-Adresse (P2WSH) einrichten, die von einer 2-von-2-Multiplesignatur kontrolliert wird, und die für den Offline-Verkehr verwendeten BRC20-Token auf diese Adresse übertragen. Diese Adresse ist mit einem sorgfältig gestalteten verbesserten HTLC-Skript verbunden, das nicht nur Bitcoin verwaltet, sondern auch den Offline-Bestand der BRC20-Token (S0) durch spezifische Datenprägungen (Commitment Inscription) aufzeichnet. Diese Online-Synchronisation in dieser Phase stellt sicher, dass beide Parteien einen Konsens über den Ausgangszustand erzielen.
Zweite Phase (Offline-Zahlung) ist der Kern des Protokolls. Wenn beide Geräte offline sind, wird der Zahlungsprozess durch vier Schritte kryptografischer Interaktionen abgeschlossen:
1. Verifizieren und Initiieren: Der Zahler überprüft die vom Zahlungsempfänger bereitgestellte Empfangsbestätigung (Rx) und vergleicht sie mit dem lokal gespeicherten aktuellen Statusnachweis (Sx), um die Zahlungsfähigkeit zu bestätigen.
2. Transaktionsaufbau: Beide Parteien basierend auf Sx, nutzen den PSBT-Rahmen, um eine "unvollendete" Bitcoin-Transaktion zu erstellen. Diese Transaktion enthält zwei Ausgaben: Eine, die an die ursprüngliche Mehrfachsignaturadresse zeigt (aber der Betrag verringert sich, was den Token-Transfer darstellt), und eine andere für das Wechselgeld. Der Schlüssel ist, dass das UTXO, das Sx entspricht, die Anforderungen des HTLC-Skripts erfüllen muss.
3. Bedingungstausch: Der Zahler generiert einen zufälligen Schlüssel (Preimage) und berechnet dessen Hashwert (H). Er bettet H in die Transaktion ein und überträgt den PSBT-Teil, der das neue Statuscommitment (Sx+1) enthält, nach partieller Signatur an den Zahlungsempfänger. Gleichzeitig überträgt er den entschlüsselten Ciphertext (Cx) (d.h. das Preimage, das mit dem öffentlichen Schlüssel des Zahlungsempfängers verschlüsselt wurde) offline (z.B. über NFC oder QR-Code).
4. Statusaktualisierung: Der Zahlungsempfänger entschlüsselt Cx, um die Preimage zu erhalten, und vollzieht damit die endgültige Signatur für die PSBT, um eine gültige vollwertige signierte Transaktion zu erhalten. Beide Parteien aktualisieren lokal den Status auf Sx+1. Damit wurde das Offline-Eigentum an den BRC20-Token übertragen, jedoch bleibt der Status auf der Bitcoin-Blockchain unverändert.
Dritte Phase (Online-Abrechnung) - Die endgültige Bestätigung des Wertes. Sobald eines der Geräte wieder online ist, kann der endgültige Statusnachweis (Sfinal), der durch die letzte Offline-Zahlung generierte vollwertige signierte Transaktion, ins Bitcoin-Netzwerk gesendet werden. Miner werden überprüfen, ob die Transaktion den HTLC-Skriptanforderungen entspricht (d.h. ob das korrekte Preimage bereitgestellt wurde). Nach der Bestätigung der Transaktion wird der BRC20-Indexer die Transaktion und das darin eingepresste neue Statuscommitment analysieren, um die öffentlichen Guthaben beider Parteien in der Blockchain zu aktualisieren und den gesamten Offline-Zahlungszyklus abzuschließen.
3. Schlüsseltechnologische Komponenten
3.1 Verbesserte Hash-Time-Lock-Verträge (HTLC) Skripte
Dieses Skript ist das Herzstück der Sicherheit der Gelder und der logischen Ausführung. Ein Standard-Zahlungsskript sieht wie folgt aus:
OP_IF
OP_SHA256 <H> OP_EQUALVERIFY
<Zahlungsempfänger-Öffentlicher Schlüssel>
OP_ELSE
<Locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
<Zahler-Öffentlicher Schlüssel>
OP_ENDIF
OP_CHECKSIG
Die Verbesserungen von Bitcoin-itip bestehen in:
· Statusbindung: <H> nicht nur der Hash des zufälligen Preimage, sondern auch abgeleitet aus "Hash des vorherigen Zustands (Sx) + neue Transaktionsdetails", sodass jedes Preimage nur für einen spezifischen Zustandsübergang gültig ist.
· Doppelausgabe: Der OP_ELSE-Zweig ermöglicht es dem Zahler, nach der Sperrzeit (z. B. 24 Stunden) die Gelder zurückzufordern, um zu verhindern, dass der Zahlungsempfänger die Transaktion niemals sendet.
· Datenträger: Die Transaktionsausgabe enthält eine spezielle OP_RETURN-Ausgabe, die das Hash-Commitment des neuen Status Sx+1 enthält, damit der BRC20-Indexer es erkennen kann.
3.2 Teilweise signierte Bitcoin-Transaktionen (PSBT) Rahmen
PSBT ermöglicht es, Transaktionen schrittweise zwischen mehreren Parteien zu erstellen und zu signieren und eignet sich perfekt für mehrstufige Interaktionen in Offline-Szenarien. In Bitcoin-itip beinhaltet eine Offline-Zahlungs-PSBT:
· Unsignierte Eingaben (die auf UTXOs zeigen, die BRC20-Token enthalten).
· Ausstehende Ausgaben (neue Token-Zuweisung und Wechselgeld).
· Notwendige Skripte und Hash-Lock-Informationen.
· Die von beiden Seiten nacheinander hinzugefügten Signaturen.
3.3 Offline-Übertragungskanal
Das Protokoll schränkt die physikalische Ebene nicht ein und kann verwendet werden:
· QR-Code: Einseitige oder zweiseitige Anzeige, kodiert PSBT-Daten, verschlüsselte Preimage oder Signatur.
· NFC: Für Nahfeldinteraktionen, um ein flüssigeres Erlebnis zu bieten.
· Bluetooth: Geeignet für mehrere aufeinanderfolgende Zahlungen.
4. Detaillierte Schritt-für-Schritt-Anleitung
Schritt 1: Brieftasche initialisieren und Geldmittel einspeisen (online)
1. Die Brieftaschenanwendungen von Zahler und Zahlungsempfänger generieren ein spezielles BRC20-Offlined-Zahlungs-Schlüsselpaar.
2. Kooperativ einen 2-von-2-Multiplesignatur-P2WSH-Adresse erstellen und das Anfangsstatuscommitment S0 generieren.
3. Der Zahler initiiert eine Standard-BRC20-Überweisung und sendet eine bestimmte Anzahl von Tokens an diese P2WSH-Adresse. Nach der Bestätigung dieser Transaktion wird der Offline-Geldpool eingerichtet.
Schritt 2: Einmaliger Offline-Zahlungsprozess (offline)
1. Verhandlungen: Die Geräte beider Parteien richten offline eine Sitzung ein. Der Zahlungsempfänger zeigt eine Empfangsbestätigung Rx mit seinem öffentlichen Schlüssel und der aktuellen Transaktionsnummer vor.
2. Aufbau: Die Brieftasche des Zahlers überprüft Rx, erstellt basierend auf dem aktuellen Status Sx und dem Zahlungsbetrag einen neuen PSBT-Entwurf und berechnet den neuen Status-Hash Sx+1.
3. Sperre: Der Zahler generiert eine Zufallszahl R, berechnet H = SHA256(Sx || R || Betrag) und setzt H in die Skriptbedingungen der PSBT ein. Mit dem öffentlichen Schlüssel des Zahlungsempfängers wird R verschlüsselt, um den Ciphertext Cx zu erhalten.
4. Austausch: Der Zahler führt die erste partielle Signatur für die PSBT durch und sendet die PSBT und Cx an den Zahlungsempfänger.
5. Entsperren: Der Zahlungsempfänger entschlüsselt Cx, um R zu erhalten, und überprüft H ?= SHA256(Sx || R || Betrag). Nach erfolgreicher Überprüfung wird R verwendet, um die PSBT ein zweites Mal zu signieren. Zu diesem Zeitpunkt ist die Transaktion vollständig signiert, aber noch nicht gesendet.
6. Bestätigung: Der Zahlungsempfänger sendet die signierte Transaktionskopie an den Zahler zurück. Beide Parteien speichern diese Transaktion lokal sicher und aktualisieren das Statusbuch auf Sx+1.
Schritt 3: Finale Abrechnung (online)
1. Wenn das Gerät (Zahler oder Zahlungsempfänger) mit dem Netzwerk verbunden ist, sendet die Brieftasche automatisch oder manuell die lokal gespeicherte vollwertige signierte Transaktion mit der höchsten Seriennummer (d.h. die neueste) ins Bitcoin-Netzwerk.
2. Netzwerk-Miner verarbeiten diese Transaktion. Da das richtige R bereitgestellt wurde, wird das Skript erfolgreich validiert und die Transaktion in einen Block gepackt.
3. Der BRC20-Indexer scannt diesen Block, erkennt die OP_RETURN-Daten in der Transaktion (die Sfinal enthalten) und analysiert die entsprechenden Änderungen in der Token-Zuweisung, um die Salden beider Parteien in der Off-Chain-Indexdatenbank zu aktualisieren.
5. Sicherheits- und Risikoanalyse
· Abwehr von Double-Spending-Angriffen: Jede Offline-Zahlung ist eindeutig an ein On-Chain-UTXO und eine fortlaufende Statusreihe (S0, S1, S2…) gebunden. Jeder Versuch, zwei verschiedene endgültige Status (Sfinal) zu senden, wird vom Bitcoin-Netzwerk abgelehnt, nachdem die erste Bestätigung erfolgt ist, da das gleiche UTXO verwendet wird. Die Offline-PSBT selbst ist ungültig, bis das korrekte Preimage bereitgestellt wird.
· Risiko eines Denial-of-Service: Der Zahlungsempfänger kann sich weigern, die signierte Transaktion nach Erhalt zu senden, was dazu führen kann, dass die Gelder des Zahlers gesperrt werden. Durch den OP_ELSE-Zweig von HTLC kann der Zahler nach der Sperrfrist einseitig die Gelder zurückfordern, was die Grundsicherheit gewährleistet.
· Datenschutzüberlegungen: Details zu Offline-Zahlungen werden nur zwischen den beiden Parteien ausgetauscht und erst bei der endgültigen Transaktionsübertragung an die Blockchain veröffentlicht, was eine zusätzliche Datenschicht bietet.
· Gerätesicherheit: Die sichere Speicherung der privaten Schlüssel ist eine grundlegende Voraussetzung. Es wird empfohlen, sichere Elemente (SE) oder vertrauenswürdige Ausführungsumgebungen (TEE) zu verwenden.
6. Einschränkungen und zukünftige Arbeiten
· Komplexität: Das Protokoll umfasst Mehrfachsignaturen, komplexe Skripte und Offline-Interaktionen und stellt hohe Anforderungen an Wallet-Entwickler und die Benutzererfahrung.
· Kapazitätsgrenzen: Der Bitcoin-Blockraum ist begrenzt, und häufige Abrechnungen kleiner, offline Zahlungen sind kostspielig. Zukünftig könnte erforscht werden, mehrere Offline-Transaktionen zu einer On-Chain-Abrechnungstransaktion (Kanalnetzwerk) zusammenzuführen.
· Abhängigkeit des Indexers: Die endgültige Aktualisierung des BRC20-Guthabens hängt von der Unterstützung des Indexers für das spezifische Format von Bitcoin-itip ab und erfordert einen Konsens der Community.
· Anfangsinvestitionskosten: Jeder Transaktionspartner muss ein spezielles Mehrfachsignaturadresse einrichten und kapitalisieren, was gewisse Initialkosten mit sich bringt.
7. Fazit
Das Bitcoin-itip-Protokoll hat erstmals systematisch die Machbarkeit der sicheren doppelten Offline-Zahlung für BRC20-Token nachgewiesen. Durch die geschickte Integration der Programmierbarkeit von Bitcoin-Skripten, der interaktiven Flexibilität von PSBT und der Kontinuität von Status-Commitments hat das Protokoll eine robuste offline Wertübertragungs-Schicht geschaffen, ohne zusätzliche Vertrauensannahmen einzuführen. Es erweitert die Anwendbarkeit von Bitcoin und BRC20-Token und bietet einen entscheidenden technologischen Weg zur Schaffung einer widerstandsfähigeren und inklusiveren Finanzinfrastruktur. Die Implementierung dieses Protokolls hängt von der gemeinsamen Förderung durch Wallet-Anbieter, Indexdienstleister und die Community ab, und seine erfolgreiche Einführung wird einen wichtigen Meilenstein für Innovationen auf der Anwendungsebene von Bitcoin darstellen.
Haftungsausschluss: Das im Whitepaper beschriebene Protokoll ist ein technischer Vorschlag und wurde noch nicht umfassend sicherheitstechnisch geprüft oder im praktischen Einsatz getestet. Entwickler und Benutzer sollten sich der Risiken bei experimentellen Implementierungen bewusst sein. Bitcoin und das BRC20-Ökosystem entwickeln sich weiterhin schnell, und spezifische Implementierungsdetails müssen möglicherweise mit jeder Protokollaktualisierung angepasst werden.
#比特赏银itip #比特币生态 #Bitcoin谷歌搜索量暴升
BRC20 itip Protokoll Kern-Community-Kontakt: itip2024@outlook.com
@币安广场 @Binance BiBi @CZ @Sun Research 孙宇晨研究 @Jiayi Li @迪大户 @唐华斑竹 @周周1688 @金先生聊MEME @欧吉巴克 @Yi He @Luna春婷 @Walrus 🦭/acc