Warum SOLLTE die Finanzierung tx BIP 141 Inputs verbrauchen?

In BOLT 02 lesen wir, dass der Finanzierungs-TX nur Segwit-Inputs verbrauchen sollte .

Der Absender: SOLLTE beim Erstellen der Finanzierungstransaktion nur BIP141-Eingaben (Segregated Witness) verwenden.

Was ist der Grund dafür? Wenn es um die Verhinderung der TX-Formbarkeit ginge, sollte es ein MUSS sein. Ich dachte auch, die Inputs, die verbraucht werden, spielen für diesen Kontext keine Rolle.

Antworten (2)

Das Folgende ist mein bescheidenes Verständnis, ich bin kein Experte für BOLTs.

Erstens ist der Grund für die Einbeziehung dieser Anforderung in der Tat die Transaktionsformbarkeit. Wenn flexible Outputs für die Finanzierungstransaktionen verbraucht werden, dann:

  • funding_txidkann sich ändern, nachdem die Transaktion gesendet wurde;
  • Überprüfung des Status des TX kann fehlschlagen ( funding_locked);
  • Der Kanal wird nie eingerichtet, obwohl die Finanzierungs-TX gesendet wird.

Zweitens, warum dies ein SOLLTE statt ein MUSS ist. Das hat mit der IETF-Definition zu tun :

SOLLTE Dieses Wort oder das Adjektiv „EMPFOHLEN“ bedeutet, dass es unter bestimmten Umständen triftige Gründe geben kann, einen bestimmten Punkt zu ignorieren, aber die gesamten Auswirkungen müssen verstanden und sorgfältig abgewogen werden, bevor ein anderer Kurs gewählt wird.

SOLLTE ist für die Spezifikationen nicht kritisch, und einige Kunden haben möglicherweise einen Grund, diese Empfehlung zu ignorieren. Zum Beispiel kann ich einen Client schreiben, der keine BIP141-On-Chain-Bitcoin-Brieftasche enthält und stattdessen eine Verbindung zu einer vorhandenen herstellt. Dadurch wird die Einrichtung für einige Benutzer einfacher und billiger (keine zusätzliche On-Chain-Transaktion). Aber ich muss die Auswirkungen verstehen und formbare Transaktionen handhaben, falls sich diese txidändern.

Wenn [eine Finanzierungstransaktion, die nur Segwit-Inputs verbraucht] dazu dienen sollte, die Formbarkeit von TX zu verhindern, sollte dies ein MUSS sein.

Etwas oberhalb des zitierten Textes heißt es: "Der Sender MUSS setzen: [...] funding_txidauf die Transaktions-ID einer nicht formbaren Transaktion."

Segwit-Eingaben sind nicht erforderlich, falls der Sender einen Nicht-Segwit-Weg kennt, um eine verformungsresistente Finanzierungstransaktion zu erstellen. Zum Beispiel könnte der Absender ein Miner sein, der seine eigenen Transaktionen schürft und keine Reorgs erwartet (ein dummes Beispiel, gebe ich zu).

Es lohnt sich zu überlegen, was passiert, wenn die Finanzierungstransaktion verändert wird. Die Finanzierungstransaktion zahlt eine 2-von-2-Multisig, aber wir möchten sicherstellen, dass der Sender sein Geld zurückerhalten kann, wenn der Empfänger unkooperativ wird, sodass der Empfänger die erste Verpflichtungstransaktion (anfänglicher Kanalsaldo) unterzeichnet, bevor die Finanzierungstransaktion gesendet wird , wenn sich also die txid der Finanzierungstransaktion ändert, ist die erste Zusage ungültig und der Absender kann seine anfängliche Einzahlung nur zurückerhalten, indem er den Empfänger bittet, eine weitere Signatur für die 2-von-2-Multisig bereitzustellen. In diesem Fehlerfall verliert der Empfänger nichts und kann sogar profitieren, indem er eine Gebühr für seine Signatur erhebt. Das bedeutet, dass sich nur der Absender darum kümmern muss, eine verformungsresistente Eingabe auszuwählen. Da dies der Fall ist,

Der letzte Teil Ihrer Antwort gilt jedoch für die Ergebnisse des Findens von TX, die nicht formbar sein dürfen, da die Finanzierung von TX geändert werden könnte, wie Sie erwähnt haben. Aber das sollte für die Inputs der Funding TX keine Rolle spielen, da sie vorher abgebaut werden und sich sowieso nicht ändern sollten?
Der Teil einer Transaktion, der der Formbarkeit durch Dritte unterliegt, ist das scriptSig-Feld, das Teil des Eingabefelds einer Transaktion ist. Denken Sie daran, dass eine Eingabe nicht die vorherige ausgegebene Ausgabe ist, die Eingabe ist ein Verweis auf die vorherige Ausgabe zusammen mit einer Unterschrift (oder einem anderen Beweis), dass die Ausgabe autorisiert ist.