[[alloc] init] veröffentlicht Vorschlag für abgeschirmtes Bitcoin für private Bitcoin-Transaktionen

Bitcoin Magazin

[[alloc] init] veröffentlicht Vorschlag für Shielded Bitcoin für private Bitcoin-Transaktionen

Shielded Bitcoin ist ein Vorschlag der Forscherinnen und Forscher Clara Shikhelman, Misha Komarov und Aleksei Moskvin von [[alloc] init] für ein neuartiges Datenschutz-Metaprotokoll auf der Bitcoin-Basisschicht, das abgeschirmte Bitcoin-Transaktionen ermöglichen soll, ohne Betreiber, Soft Forks oder andere Änderungen am Bitcoin-Konsens zu erfordern. Das Whitepaper finden Sie hier und die Ankündigung im Blog hier. 

Das Protokoll definiert eine Transaktionsstruktur und ein Indexierungsprotokoll für Transaktionen mit starkem Datenschutz, während es sich für das Ein- und Ausbuchen von Geldern in das beziehungsweise aus dem System auf Bitcoin-PIPEs stützt. Mehr zum PIPEs-Mechanismus am Ende des Artikels. 

Das Design ist dem von Bitcoin sehr ähnlich: Es gibt ein Äquivalent zu einer UTXO (eine Note), Transaktionen verbrauchen Notes als Eingaben wie bei einer regulären Bitcoin-Transaktion, ein Witness weist nach, dass die verbrauchten Eingaben ordnungsgemäß autorisiert sind, und Knoten (im Fall eines Metaprotokolls Indexer) analysieren den Transaktionsverlauf und erstellen einen aktuellen Stand darüber, welche Coins ausgegeben und welche noch nicht ausgegeben wurden usw. 

Alle Details unterscheiden sich jedoch erheblich. 

Eine Shielded-Bitcoin-Transaktion ist lediglich ein Datenblock mit einem Präfix (etwa „shbtc:“), der mithilfe von OP_RETURN, des Witness-Felds oder einer anderen Methode zur Übertragung von Daten in eine Bitcoin-Transaktion eingebunden wird. Für Bitcoin hat sie keinerlei Bedeutung: Das Bitcoin-Netzwerk überprüft sie nicht und setzt keinerlei Regeln in Bezug auf sie durch. Es ist durchaus möglich, dass ungültige Shielded-Bitcoin-Transaktionen in der Blockchain landen. Es ist Aufgabe eines Shielded-Bitcoin-Indexers, der die Blockchain passiv beobachtet (sprich: eines Nodes), solche Transaktionen bei fehlgeschlagener Validierung zu ignorieren und ihre Anwendung auf den Netzwerk-Guthabenstand zu verweigern.

Ein Indexer entfernt Notes nicht wie Bitcoin UTXOs aus einer Menge unverbrauchter Notes. Stattdessen verwendet er eine Nullifier-Menge. Damit kann ein Nutzer öffentlich einen verschlüsselten Nachweis und einen Nullifier veröffentlichen, dass eine Note ausgegeben wurde, ohne offenzulegen, welche Note ausgegeben wurde. Anstatt also zu prüfen, ob sich eine Note in der „Menge unverbrauchter Notes“ befindet, prüft man, ob ein Nullifier bereits verwendet wurde. Indexer erstellen einen Merkle-Baum, der unendlich weiterwächst und dem ausschließlich Einträge hinzugefügt werden können. Er enthält jede erzeugte Note-Ausgabe sowie anschließend die Nullifier-Menge.

Für die Nutzung dieses Protokolls benötigen Sie lediglich einen Bitcoin-Node und einen Shielded-Bitcoin-Indexer. Zur Wiederherstellung von Geldern ist weder ein Dienstleister noch ein Koordinator oder ein Off-Chain-Zustand erforderlich. Es funktioniert genau wie Bitcoin direkt auf der Blockchain: Sie benötigen lediglich Ihren Node/Indexer und Ihre Schlüssel.

Jede Benutzer-Wallet leitet einen geheimen Hauptschlüssel ab, aus dem alle weiteren beteiligten Schlüsselgruppen erzeugt werden.

Stell dir das ähnlich wie eine HD-Wallet bei Bitcoin vor. Mit dieser Beziehung kannst du viele Adressgruppen generieren.Sk_spend ist dein privater Schlüssel, der sk_nf wird verwendet, um Note-Outputs zu nullifizieren, der vk_in wird verwendet, um eingehende Notes zu entschlüsseln und anzuzeigen, der vk_out um deine ausgehenden Transaktionen anzuzeigen, und der sk_view wird zur Generierung einer Empfangsadresse verwendet. 

Wenn ein Nutzer jemandem eine Adresse geben möchte, an die ihm Geld gesendet werden kann, generiert er einen Diversifiziererwert d ähnlich einem Ableitungswert und multipliziert diesen Wert anschließend mit seinem sk_view Schlüssel. Dieser resultierende öffentliche Schlüssel, pk_d und d ist die Adresse des Nutzers. 

Der Absender generiert dann einen Zufallswert, den r_seed, was für die Verschlüsselung der Note-Ausgabe sowie für das Nullifizieren erforderlich ist (dazu kommen wir gleich). Transaktionsausgaben enthalten nur drei verschlüsselte Dinge: den Wert der Ausgabe, den d Wert, den der Empfänger dem Sender gegeben hat, und den r_seed Wert des Senders. Der Sender verwendet ein geheimes ephemeres Schlüsselpaar und den öffentlichen Schlüssel des Empfängers, um ein gemeinsames Geheimnis zu erzeugen. Beide Parteien können dasselbe Geheimnis erzeugen, indem sie ihren privaten Schlüssel mit dem öffentlichen Schlüssel der jeweils anderen Partei multiplizieren. Die Note-Ausgabe wird mithilfe dieses gemeinsamen Geheimnisses verschlüsselt, und der ephemere sk_eph wird unverschlüsselt mitgesendet, damit der Empfänger das gemeinsame Geheimnis erzeugen kann. 

Auf der Eingabeseite der Abbildung sind zwei Dinge erforderlich, damit eine Transaktion gültig ist: ein öffentlicher Nullifier für die verbrauchten Note-Ausgaben und ein Zero-Knowledge-Beweis, der belegt, dass 1) die Note-Ausgabe im Merkle-Baum der Notes enthalten ist, 2) die Transaktion durch den entsprechenden sk_spend Schlüssel autorisiert ist, 3) der Nullifier korrekt abgeleitet wurde und 4) keine Inflation stattgefunden hat. 

Wenn dir in der obigen Abbildung auffällt, dass der Nullifier den sk_nf Schlüssel verwendet, den ρ-Wert, der abgeleitet wird aus r_seed, und die Position der Note im Merkle-Baum der Note-Ausgaben. Der Zero-Knowledge-Beweis stellt all dies sicher, weshalb man bei Wiederholungen einfach Nullifier zählen kann, anstatt ausgegebene Notes zu löschen. Obwohl man nie weiß, welcher Note-Ausgabe ein Nullifier entspricht, garantieren die Zero-Knowledge-Beweise in jeder Transaktion, dass jeder dem Set hinzugefügte Nullifier aus einer gültigen Note-Ausgabe stammt. Solange es keine Wiederholungen gibt, bietet das dieselbe Double-Spend-Garantie. 

Damit also: Das Protokoll ermöglicht es, im Wesentlichen verschlüsselte Metaprotokoll-Transaktionen in die Bitcoin-Blockchain einzubetten und gleichzeitig zu garantieren, dass nichts doppelt ausgegeben wird und keine Coins aus dem Nichts entstehen. 

Was die Datenschutzeigenschaften angeht, ist dies tatsächlich ein sehr gut konzipiertes System und mit etwas wie den Shielded Pools von Zcash vergleichbar. Beim Ein- und Austritt aus dem Metaprotokoll sind einige Datenschutzaspekte zu berücksichtigen, die in einer demnächst erscheinenden Veröffentlichung näher erläutert werden. Es gibt keine Bedenken hinsichtlich der Messung der Privatsphäre oder eines regelmäßigen Remixings wie bei Coinjoins. 

Also, der Peg. Ziel ist es, mithilfe von PIPEs v2, einem Witness-Encryption-Verfahren, einen Peg aufzubauen. Mit PIPEs lässt sich ein privater Schlüssel mithilfe eines Programms/Mechanismus verschlüsseln, der den Schlüssel nur dann preisgibt, wenn man einen ZK-Beweis dafür erbringen kann, dass eine bestimmte Bedingung erfüllt wurde (z. B. der Zustand eines UTXO oder die Bestätigung einer Transaktion). Dadurch könnte ein Peg ohne Betreiber, Föderation oder Verwahrung der Gelder durch Dritte funktionieren.

Dafür sind keine Softforks oder Protokolländerungen an Bitcoin erforderlich; alles findet vollständig off-chain statt.

Der Plan von Shielded Bitcoin und der nächste Teil ihrer Arbeit sieht einen Pegging-Mechanismus vor, mit dem Nutzer Gelder mithilfe kryptografisch durch PIPEs kontrollierter Schlüssel in Shielded Bitcoin einzahlen können. Diese Gelder würden anschließend „freigeschaltet“, indem ein ZK-Beweis für legitime, on-chain bestätigte Peg-out-Transaktionen erstellt wird.

Derzeit wird an dem Paper gearbeitet, das diesen Aspekt des Systems beschreibt. Es soll in naher Zukunft veröffentlicht werden.

Dieser Beitrag [[alloc] init] veröffentlicht den Vorschlag für Shielded Bitcoin für private Bitcoin-Transaktionen. Er erschien zuerst im Bitcoin Magazine und stammt von Shinobi.

Quelle: BitcoinMagazine