Warum fügen Sie dem Tapscript in Taproot kein Salz hinzu?

Der entsprechende Merkle-Nachweis muss beim Entsperren von UTXO mit MAST erbracht werden, wobei der Hash eines nicht verwendeten Skripts enthalten ist. Für die Beobachtung scheint es möglich, das ungenutzte Skript aus dem Hash zu erraten. Zum Beispiel könnte ich einige öffentliche Schlüssel aus dem Skript erhalten, das tatsächlich ausgeführt wird, und dann kombiniere ich einen davon mit einigen Zeitsperren, um zu versuchen, Hash-Kollisionen durchzuführen.

Das Hinzufügen von Salz zum Skript scheint dies leicht zu verhindern, also warum hat Taproot dies nicht getan? Liegt das daran, dass die oben beschriebene Hash-Kollision im Grunde nicht durchführbar ist und das Hinzufügen von Salz zusätzlichen Zeugenraum beansprucht?

Antworten (2)

Im Allgemeinen sollte dies kein Problem sein, da jedes Skript mit ziemlicher Sicherheit mindestens einen öffentlichen Schlüssel enthält und Sie in jedem Zweig neue öffentliche Schlüssel verwenden können.

Wenn Sie sich immer noch Sorgen um die Privatsphäre des offenbarten Skripts machen, können Sie die darin enthaltenen öffentlichen Schlüssel manuell mit einem Geheimnis optimieren, das von allen Teilnehmern geteilt wird (z. B. der Hash der Verkettung aller darin enthaltenen Skripte vor dem Optimieren). Oder Sie können sogar zusätzliche Daten hinzufügen, indem Sie einen Push-Opcode und OP_DROP verwenden.

Salts werden für Dinge wie die Speicherung von Passwörtern verwendet, bei denen mehrere Benutzer möglicherweise dasselbe Passwort verwenden. Durch die Verwendung eines Salts verschleiert es für einen Beobachter der Datenbank, welche Benutzer aufgrund unterschiedlicher Salts dasselbe Passwort verwenden. Die einzige Motivation für die Verwendung eines Salt in Taproot-Skripten wäre, wenn Benutzer dieselben Taproot-Skripte verwenden würden. Aber zumindest werden die öffentlichen Schlüssel der Benutzer unterschiedlich sein (es sei denn, sie verwenden denselben privaten Schlüssel), und daher sind keine Taproot-Skripte gleich, es sei denn, sie werden von demselben Benutzer kontrolliert.

Zu sagen, dass die offensichtlichen Benutzer nicht dasselbe Passwort (schreckliche Passworthygiene) für Nicht-Bitcoin-Dienste verwenden sollten, aber es ist noch ernster für Bitcoin. Wenn Benutzer keinen privaten Bitcoin-Schlüssel mit ausreichender Entropie generieren, wird ihr Bitcoin wahrscheinlich gestohlen.

Für die Beobachtung ist es möglich, das ungenutzte Skript aus dem Hash zu erraten.

Es ist nicht möglich, das Urbild einer sicheren Hash-Funktion zu erraten. Es kann nur durch rohe Gewalt (Ausprobieren vieler möglicher Vorbilder) erreicht werden, aber es gibt so viele mögliche Vorbilder, dass es ist, als würde man nach einer Nadel im Heuhaufen suchen.

Ja, es wäre sehr schwierig, Hash-Kollisionen zu finden, aber wäre es einfacher, wenn es einige Einschränkungen gäbe? Zum Beispiel sind die drei Entsperrbedingungen in einem MAST 1. Signal von A && Signal B && Zeitsperre 10 Blöcke 2. Signal von A && Zeitsperre 100 Blöcke 3. Signal von B && Zeitsperre 200 Blöcke Sie werden dann schließlich mit Bedingung 1 entsperrt Der Beobachter versucht dann, den öffentlichen Schlüssel von A + das Zeitschloss zu kollidieren. Ich weiß, das ist ein seltenes Beispiel, aber es funktioniert trotzdem, oder? Und wenn Sie dem Skript Salz hinzufügen, scheint es es zu stoppen?
Ich frage nur, ob ich deine Frage verstehe. In Ihrem Szenario wird ein Skript aufgedeckt und ein Blockchain-Beobachter verwendet die Details dieses Skripts, um zu versuchen, durch (informierte) Brute Force die anderen Skripte im Taproot-Baum (MAST) zu ermitteln, die nicht aufgedeckt wurden und verwendet wurden? Oder verwendet er die Details dieses Skripts, um zu versuchen, die anderen Skripte in anderen Taproot-Bäumen auszuarbeiten? Denn offensichtlich kennt der Beobachter/Angreifer den/die privaten Schlüssel nicht und kann daher die Gelder nicht stehlen, selbst wenn es ihm/ihr gelingt, ein bestimmtes Skript aus einem Hash brutal zu erzwingen.
Nein, ich möchte hier nicht diskutieren, ob ein Angreifer dieses UTXO ausgeben könnte, sondern nur, ob dies zu einem Durchsickern ungenutzter Skripte führen würde, da dies den ursprünglichen Zweck von Taproot zunichte zu machen scheint? Und durch das Hinzufügen von Salz zum Skript kann ein Beobachter, selbst wenn er einige Informationen kennt, das dem Hash entsprechende Skript nicht kennen (aufgrund des Vorhandenseins des Salzes).
Ich denke, die Antwort auf Ihre Frage lautet dann, dass getaggte Hashes in ganz Taproot verwendet werden und dies eine ähnliche Rolle wie ein Salz spielt. github.com/bitcoinops/taproot-workshop/blob/…
Tagged Hash scheint zu verhindern, dass ein Zweigknoten als Blattknoten interpretiert werden kann. Und alle Tags für Blattknoten, als ich BIP 341 las, waren Tapleaf . Ich denke, es ist immer noch anders als das, was Salz bedeutet.
Wenn jeder Blattknoten ein anderes Tag hat, wäre das in der Tat meine Antwort, aber ich sehe im Moment nicht, dass sie unterschiedlich sind (korrigieren Sie mich, wenn ich falsch liege). Und vielen Dank für deine Antwort!
@MichaelFolkson Da der markierte Hash vorhersehbar ist, kann er nicht als Salz fungieren. Es verhindert, dass die zu hashenden Daten versehentlich mit einem Hash übereinstimmen, der in einem anderen Kontext verwendet wird, aber es kann keine Privatsphäre bieten, da das Tag nicht geheim ist.
Warum fügen Sie dem Tapscript in Taproot kein Salz hinzu?
AntwortenHierDatenschutz-Bestimmungen1y, 0v