Beeinträchtigt die zukünftige SIGHASH_ANYPREVOUT-Funktion die Privatsphäre von Taproot-Lightning-Kanälen?

Einer der Vorteile, die ich über Taproot gehört habe, ist, dass alle Transaktionen für einen Blockchain-Beobachter identisch erscheinen. Dies würde natürlich auch für das Öffnen/Schließen von Lightning-Channel-Transaktionen gelten, was ein großer Datenschutzvorteil für Lightning-Benutzer wäre.

Soweit ich das vorgeschlagene ANYPREVOUT-Upgrade verstehe, wird es auf Taproot aufbauen, muss aber einen Pubkey mit einer anderen Länge verwenden. Wäre es für einen Beobachter möglich, die Blockchain nach dieser Pubkey-Länge zu scannen, um festzustellen, welche Transaktionen ANYPREVOUT verwenden und daher wahrscheinlich blitzbezogen sind? Oder ist es möglich, dies irgendwie in Taproot so zu verstecken, dass die Privatsphäre weiterhin gewahrt bleibt?

Antworten (1)

Die Grundlage eines Kanals ist ein Multisig-Ausgang, der bei Verwendung von Musig und Taproot nicht von anderen Ausgängen unterschieden werden kann.

Die gegenseitige Kanalschließung ist nur ein normaler TX, der diese Ausgabe ausgibt, daher würde ich sagen, dass es schwierig sein wird, dies ohne andere Daten als Blitzkanal zu erkennen (ähnlich wie bei aktuellen Kanälen).

Das einseitige Schließen ist jedoch anders und hinterlässt einen Fußabdruck des Kanalzustands. Ich denke, die Update-Transaktion, die zum Kicken des Settlement-Tx verwendet wird, könnte die erkennbare Struktur haben, auf die Sie sich bezogen haben. (Ich würde Sie gerne nach Ihrer Quelle fragen)

Ich bin mir der Einschränkungen des aktuellen Taproot-Vorschlags im Falle eines nicht kooperativen Abschlusses bewusst. Was ich mich jedoch frage, ist, ob sich Anyprevout sogar auf den kooperativen Fall auswirken würde, da vorgeschlagen wird, eine andere Pubkey-Länge zu verwenden? Wenn ich (höchstwahrscheinlich) nichts falsch verstehe, scheint es, als hätte jeder, der das Eltoo-Protokoll mit Anyprevout verwendet, seine Kanaloperationen in der Kette leicht sichtbar. Meine Quelle für den Unterschied der Pubkey-Länge ist dieser Ausschnitt von AJ Towns im Podcast von Stephan Livera: youtu.be/8S7D_FdZfE8?t=2978
Ich denke, die Update-TXS verwenden Anyprevout, aber im Fall des gegenseitigen Schließens wird es nur eine regelmäßige Ausgabe sein, wie erwähnt, ohne dass Anyprevout erforderlich ist. (Es wird kein Update-TX im gegenseitigen Abschluss geben, da Partner die Ausgaben aus dem Finanzierungs-TX direkt verhandeln können - es sei denn, ich vermisse etwas, was auch passieren könnte.
Ok interessant. Dann wäre also die Nutzung von anyprevout für eltoo nur sichtbar, wenn der Kanal einseitig geschlossen wurde? Das entspricht eher der ursprünglichen Annahme von Taproot. Wenn es möglich ist, die Kette einfach nach 33-Byte-Pubkeys zu scannen, scheint Eltoo trotz der Skalierungsvorteile, die es bringen kann, nicht viel Privatsphäre zu haben
Beeinträchtigt die zukünftige SIGHASH_ANYPREVOUT-Funktion die Privatsphäre von Taproot-Lightning-Kanälen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v