Wie wäre es, die Verwendung eines unausgeglichenen Merkle-Baums in Taproot zu erzwingen?

Ich habe diesen Satz in Taproot über den MAST-Build bemerkt.

Die verbleibenden Skripte sollten in den Blättern eines binären Baums organisiert werden. Dies kann ein ausgewogener Baum sein, wenn jede der Bedingungen, denen diese Skripte entsprechen, gleich wahrscheinlich ist. Wenn Wahrscheinlichkeiten für jede Bedingung bekannt sind, erwägen Sie, den Baum als Huffman-Baum zu konstruieren.

Aber im Fall eines ausgeglichenen Merkle-Baums kann ein Beobachter durch den Merkle-Beweis auf die Anzahl der Schichten im Baum schließen und erhält so eine ungefähre Anzahl von Blättern (Skripten). Zum Beispiel wird ein P2TR mit einem Zeitschloss entsperrt, und ich schließe aus dem Merkle-Beweis, dass es insgesamt 2 Skripte gibt. Dann kann ich vermuten, dass die andere Sperre eine Hash-Sperre ist (da dies das häufigste Skript mit zwei Bedingungen ist und eine davon eine Zeitsperre ist).

Es scheint, dass es auch eine Option wäre, den Benutzer zu zwingen, einen unausgeglichenen Merkle-Baum zu verwenden (z. B. die Koeffizienten zufällig zu initialisieren und dann einen Huffman-Baum zu konstruieren)? Oder vielleicht ein paar künstliche Blätter hineinlegen?

Entschuldigung für die Verwirrung des Konzepts eines ausgeglichenen Binärbaums, das Beispiel in der Frage ist nicht genau.

Antworten (2)

Zum Beispiel wird ein P2TR mit einem Zeitschloss entsperrt, und ich schließe aus dem Merkle-Beweis, dass es insgesamt zwei Skripte gibt.

Das kannst du nicht sicher ableiten. Sie wissen, aus welcher Schicht des Merkle-Baums das Skript stammt (in diesem Fall aus der ersten Schicht), aber es können Skripte auf der zweiten, dritten, vierten Schicht usw. vorhanden sein, von denen Sie nichts wissen. Ich stimme zu, dass, wenn ein Skript aus der ersten Schicht genommen wird, es möglich (vielleicht wahrscheinlich) ist, dass es zwei Skripte gibt.

Dann kann ich vermuten, dass dies ein MAST ist, der eine Hash-Zeitsperre enthält (da dies das häufigste Skript mit zwei Bedingungen ist und eine davon eine Zeitsperre ist).

Ich bin mir nicht sicher, warum Sie denken, dass ein Blattskript mit einem Timelock darauf schließen lässt, dass ein anderes Blattskript ein Hash-Timelock enthält. Wenn Sie sich auf Lightning beziehen, sind die häufigsten Kanalschließungen kooperative 2-von-2-Schließungen, bei denen keine alternativen Skriptpfade in die Ausgabe aufgenommen werden müssen. Bei selteneren unkooperativen Closes ist es für einen Blockchain-Beobachter offensichtlich, dass es sich um einen unkooperativen Lightning Channel Close handelt, das kann man nicht verbergen.

Es scheint, dass es auch eine Option wäre, den Benutzer zu zwingen, einen unausgeglichenen Merkle-Baum zu verwenden (z. B. die Koeffizienten zufällig zu initialisieren und dann einen Huffman-Baum zu konstruieren)? Oder vielleicht ein paar künstliche Blätter hineinlegen?

Sie können den Pfahlwurzelbaum auf jeden Fall so konstruieren, wie Sie es wünschen. Sie können Skripte in niedrigeren Ebenen ablegen, als sie sein müssen, sodass es für einen Blockchain-Beobachter so aussieht, als gäbe es mehr Skriptpfade, als tatsächlich vorhanden sind. Um Gebühren zu sparen, werden Sie normalerweise das Skript, das Sie am wahrscheinlichsten verwenden, auf einer höheren Ebene des Merkle-Baums platzieren wollen, aber wenn Sie sich mehr um den Datenschutz sorgen, können Sie sich dagegen entscheiden.

Erstmal vielen Dank für deine Antwort!
Über Blätter in der unteren Schicht: Vielleicht verstehe ich den ausgeglichenen Baum falsch, ich dachte, er mag den Merkle-Baum in SPV, wo sich alle Blätter in der untersten Schicht befinden würden. Zum Beispiel eines Lightning-Netzwerks: Was ich diskutieren möchte, ist, ob es möglich ist, Hash-Zeitsperren von normalen Zeitsperren zu unterscheiden? Dies ist einfach, wenn die Anzahl der Skripte abgeleitet werden kann. Schließlich habe ich den Gleichgewichtsbaum möglicherweise missverstanden. Was ich vorschlagen möchte, ist, wie Sie sagten, wir sollten jede Ebene mit Skripten versehen, anstatt alle Blätter auf die letzte Ebene zu legen.
Sie müssen nicht alle Skripte auf derselben untersten Ebene ablegen. Das wäre ineffizient und kostspieliger, wenn Sie sagen, Sie hätten 3 Skripte und müssten sie alle auf der zweiten Ebene platzieren, anstatt 1 Skript auf der ersten Ebene und 2 Skripte auf der zweiten Ebene. Re Lightning Es tut mir leid, dass ich die Frage nicht verstehe. Das Skript für ein Hash-Timelock enthält offensichtlich sowohl ein Hash-Lock als auch ein Timelock. Ich verstehe nicht, warum das Aufdecken eines Timelock-Skripts darauf schließen lässt, dass ein zweites Skript ein Hash-Timelock ist. Ich vermute, Sie missverstehen, wie Lightning funktioniert (aber ich könnte mich irren)
Oh, mein Fehler, ich habe vergessen, den Kontext zu klären. Ich vermute, dass Lightning Network in Zukunft die Hash-Zeitsperre in zwei separate Skripte aufteilen wird, um Taproot zu treffen, eine Hash-Sperre und eine Zeitsperre. Wenn ich also sehe, dass eine Sperre eine Zeitsperre ist und dass dieser MAST zwei Skripte hat, vermute ich, dass das andere Skript eine Hash-Sperre ist und der MAST den HTLC darstellt.
Sie könnten dies nicht tun, da nur ein Skript (Blatt) im Taproot-Baum verwendet/ausgegeben werden kann. Sie können nicht mehrere Blattskripte kombinieren, um sie aus der Ausgabe auszugeben. Wenn Sie also eine Belastung wünschen, die ein Hashlock und ein Timelock enthält, müssen sich beide in einem einzigen Blattskript befinden
Ja, aber ich denke, was HTLC bedeutet, ist, dass Alice mit Preimage einlösen kann oder Bob nach einer Zeitüberschreitung einlösen kann. Es wäre ein Skript, das aufgeteilt werden könnte.
Nein, Sie verwechseln HTLCs mit unkooperativen Kanalschließungen. Ein HTLC ist ein Skript, das sowohl einen Hashlock als auch einen Timelock enthält. Diese werden jedes Mal erstellt, wenn eine neue Zahlung auf Lightning erfolgt. Ein unkooperativer Kanalabschluss liegt vor, wenn eine Transaktion gesendet wird, die zwei Ausgaben enthält: eine, die Ihre Gegenpartei ohne Zeitsperre bezahlt, und eine Ausgabe, die Sie mit einer Zeitsperre bezahlt. Dies sind eher zwei Ausgaben als zwei Skripte, die kombiniert werden können.
Ja, Sie haben Recht, es gibt zwei Ausgänge beim nicht kooperativen Schließen. Die Ausgabe, die Alice sich selbst gibt, ist durch ein Zeitschloss gesperrt, und eine andere Ausgabe, die Bob sofort erhalten kann (aber ich denke, das sind zwei verschiedene P2TR-Skripte? Ich spreche nur von dem P2TR, das Alice sich selbst gibt). Und das Lightning-Netzwerk ermöglicht es Bob, die Ausgabe von Alice als Strafe über ein Preimage zu nehmen, um zu verhindern, dass eine Partei den alten Zustand festschreibt, ein Mechanismus namens RSMC. Beachten Sie, dass ich nur über das Ausgabeskript spreche, das Alice sich selbst gibt. Der MAST dieser Ausgabe hat zwei Skripte.
Ein Skript für Alice, um die Rückerstattung nach dem Timeout zu erhalten. Ein weiteres Skript für Bob, um das Geld per Preimage zu bekommen, um Alice zu bestrafen.
Das wird lang (und geht zu Lightning über, was nicht der Fokus der ursprünglichen Frage ist), also sollten wir zum Chat übergehen. Aber nein, Bob hat ein Zeitintervall, um eine Bestrafungstransaktion zu senden, die Alices zeitgesperrte Ausgabe an eine Adresse ausgibt, die er kontrolliert, wenn Alice einen widerrufenen Zustand gesendet hat. Das ist eine zusätzliche Transaktion, kein alternativer Skriptpfad innerhalb einer einzelnen Transaktion.
Ja, nehmen wir an, Alices UTXO ist P2TR. Es gibt zwei Skripte in MAST, richtig (eines für Alice, eines für Bob)? Wenn Bob also preimage verwendet, um zu entsperren und zu zeigen, dass es zwei Skripte gibt (nehmen wir an, dass alle Skripte auf derselben Ebene platziert sind). Dann vermutet der Betrachter, dass das andere Skript das Zeitschloss ist, was ich anfangs gemeint habe.
Ausgaben verraten nichts über andere Skripte im selben Baum. Sie können mit nur einem Skript einen Tiefe-128-Baum erstellen. Es wäre jedoch ineffizient, da Sie 128 Dummy-Zweige benötigen.

Die Antwort ist sehr einfach, Sie können nicht unabhängig überprüfen, ob der Benutzer einen unausgeglichenen Merkle-Baum verwendet, ohne dessen Struktur vollständig zu kennen – was alle Anonymitätsvorteile sinnlos macht. Aber Sie überschätzen, wie viele Informationen über den Merkle-Baum abgeleitet werden können. Da während einer Taproot-Ausgabe nur ein Merkle-Pfad aufgedeckt wird, gibt es keine Möglichkeit, sicher zu wissen, wie viele Ausgabenbedingungen definiert wurden, es sei denn, das Skript befindet sich direkt unter der Merkle-Wurzel – in diesem Fall ist es nachweislich das einzige Skript im Baum .

Um jedoch zu verhindern, dass irgendjemand vernünftige Vermutungen anstellt, könnte eine Wallet-Software die Merkle-Baumstruktur bei jeder Transaktion randomisieren, ähnlich wie einige Wallets die Transaktionsausgaben zufällig mischen, um die Änderungsausgabe zu verschleiern.

Wie wäre es, die Verwendung eines unausgeglichenen Merkle-Baums in Taproot zu erzwingen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v