TRUC-Transaktion

TRUC ist eine Relay-Richtlinie, für die sich ein Absender entscheidet, indem er die Version einer Transaktion auf 3 setzt, keine Konsensregel. Bitcoin Core 28.0 machte sie unter BIP 431 zum Standard, das die Transaktion auf 10.000 virtuelle Bytes und ihre Kindtransaktion auf 1.000 begrenzt. Sie werden sie nicht selbst setzen: BIP 431 richtet die Richtlinie auf Protokolle wie Lightning aus, deren Commitment-Transaktionen vorab signiert und zum Zeitpunkt des Sendens mit einer höheren Gebühr versehen werden.

Wie sie funktioniert

TRUC sind sechs Regeln, die einer gewöhnlichen Transaktion angehängt werden, und ein Absender schaltet alle sechs auf einmal ein, indem er das Versionsfeld auf 3 setzt.

Regel eins macht die Transaktion ersetzbar, ob sie nun nach alter BIP125-Art signalisiert oder nicht, eine Unterscheidung, die dieselbe Version ohnehin dadurch gegenstandslos machte, dass sie vollständiges Replace-by-Fee zum Standard machte. Regel zwei macht die Wahl dauerhaft: Jeder unbestätigte Vorfahre einer TRUC-Transaktion muss TRUC sein, und jeder Nachkomme einer unbestätigten TRUC-Transaktion muss ebenfalls TRUC sein, sodass niemand die Grenzen umgeht, indem er eine gewöhnliche Kindtransaktion anhängt, wobei bestätigte Coins in beide Richtungen ausgenommen sind. Regel drei ist die Beschränkung, von der der Name stammt: ein unbestätigter Vorfahre und ein unbestätigter Nachkomme, ohne CPFP-Ausnahme. Regel vier begrenzt die Transaktion auf 10.000 virtuelle Bytes, gegenüber einer Standardgrenze von 100.000 für alles andere. Regel fünf begrenzt die Kindtransaktion auf 1.000 virtuelle Bytes, was mit Taproot-Eingängen noch Platz für 15 Eingänge und 2 Ausgänge lässt. Regel sechs lässt zu, dass die Transaktion unter der Mindestweiterleitungsgebühr des Nodes liegt, auch bei null, solange das Paket um sie herum genug zahlt.

Der Grund für all das ist Pinning: Der Müll eines anderen macht Ihre Transaktion nicht anhebbar. Ersetzungsregeln verlangen von einer Ersetzung, dass sie mehr absolute Gebühr zahlt als alles, was sie verdrängt, und lehnen jede Ersetzung rundheraus ab, die mehr als 100 Transaktionen verdrängen würde. BIP 431 beziffert, wie leicht das missbraucht wird. Wenn Sie fünf eigene Transaktionen ersetzen wollen und eine Gegenpartei an jede 21 Nachkommen angehängt hat, wird Ihre Ersetzung allein wegen der Anzahl abgelehnt, egal was sie zahlt. Wer billige Nachkommen an Ihre unbestätigte Transaktion hängen kann, bestimmt den Preis für Ihre eigene Gebührenerhöhung.

Das Limit von 1.000 virtuellen Bytes für die Kindtransaktion ist die direkte Antwort darauf. Unter den standardmäßigen Nachkommengrenzen kann eine gebührenerhöhende Kindtransaktion selbst 100.000 virtuelle Bytes groß sein, und bei einem Satoshi pro virtuellem Byte sind das 100.000 Satoshis oder mehr, die eine Ersetzung decken muss, bevor sie überhaupt aufgrund eigener Vorzüge konkurrieren kann. Die Begrenzung der Kindtransaktion auf 1.000 senkt die Obergrenze um den Faktor hundert.

Zwei Mechanismen laufen mit den Regeln einher. Die Verdrängung von Geschwistern erlaubt es einem Node, der auf eine zweite, besser zahlende Kindtransaktion trifft, die erste nach den Ersetzungsregeln zu verdrängen, statt die neue abzulehnen, und da immer nur eine Kindtransaktion existieren kann, muss nicht geraten werden, welche fallen soll. Das Paket-Replace-by-Fee, das Bitcoin Core 28.0 für verbundene Gruppen der Größe zwei aktivierte, wirkt dann auf TRUC-Transaktionen, weil diese Form garantiert ist.

Warum das beim Bitcoin-Kauf zählt

TRUC erreicht einen gewöhnlichen Bitcoin-Besitzer in einem einzigen Moment, nämlich wenn ein Lightning-Kanal On-Chain geschlossen werden muss und die Gebühr erhöht werden muss, nachdem die Transaktion signiert wurde.

Beim Kauf schlägt es nicht zu. Von den 41 Wallet-Bewertungen auf dieser Website sind diejenigen, die einen echten Lightning-Node auf Ihrem Smartphone installieren, der Punkt, an dem die Richtlinie aufhört, eine Randnotiz zu sein. Phoenix, von ACINQ, wird hier mit 4,0 bewertet und betreibt einen eigenständigen Node hinter einer Seed-Phrase mit 12 Wörtern, und der Notfallweg, den ACINQ dokumentiert, ist der erzwungene Abschluss, das Warten von ungefähr 720 Blöcken, etwa fünf Tagen, und das Wiedererlangen der Mittel On-Chain mit einem Werkzeug wie Electrum. Dieser Abschluss sendet eine Commitment-Transaktion, die BIP 431 als diejenige nennt, die sich auf die CPFP-Ausnahme stützt, um Pinning zu vermeiden. Eine Commitment-Transaktion, die nicht vor Ablauf einer Frist in einen Block gelangen kann, bleibt nicht einfach liegen: Das Geld, das sie schützte, wird für die andere Seite beanspruchbar.

Die Verwahrung verschiebt das Risiko, und das ist der Unterschied zwischen unseren Einträgen. Strike, bewertet mit 4,6, lässt Sie über Lightning auszahlen und erhebt bei Transfers keine eigene Gebühr, doch die Guthaben werden verwahrend gehalten, solange sie in der App liegen, sodass die Kanäle und ihre Abschlüsse Strike gehören. Muun, bewertet mit 3,8, zeigt On-Chain und Lightning als ein Guthaben und wechselt über Submarine Swaps zwischen beiden. Je mehr von einem Kanal Sie tatsächlich halten, desto mehr ist eine zuverlässige Gebührenerhöhung Ihr Problem, und TRUC ist die Richtlinie, die geschrieben wurde, um eine solche innerhalb der Gruppe von Nodes zu liefern, die sie ausführen.

Ein erzwungener Abschluss bei Phoenix, mit und ohne Pinning

Ein erzwungener Abschluss bei Phoenix ist der klarste Ort, um TRUC bei der Arbeit zu beobachten, weil die Transaktion, die gesendet wird, lange bevor jemand wusste, wie der Gebührenmarkt aussehen würde, signiert wurde.

Nehmen Sie zuerst die alte Anordnung. Ihr Commitment ist eine gewöhnliche Transaktion, die nicht Version 3 angibt, gesendet mit einer Kindtransaktion, die für beide zahlt. Ihre Gegenpartei hält den zweiten Anker-Ausgang, der existiert, damit beide Seiten die Gebühr erhöhen können, und sie nutzt ihn, um eine eigene Kindtransaktion anzuhängen, die 100.000 virtuelle Bytes groß ist und ein Satoshi pro virtuellem Byte zahlt. Nichts davon ist ungültig. Die CPFP-Ausnahme ließ Sie eine zusätzliche Kindtransaktion an der Nachkommengrenze vorbeischleusen, aber den Ersetzungsregeln ist das gleich: Die Kindtransaktion der Gegenpartei zu verdrängen bedeutet, die 100.000 Satoshis Gebühr zu zahlen, die sie bereits trägt, bevor Ihre eigene Gebühr überhaupt zählt, und die Ausnahme gewährte genau eine zusätzliche Kindtransaktion, sodass sie in dem Moment scheiterte, als ein Dritter an der Transaktion beteiligt war. Ihr Abschluss wird durch Müll gepinnt, der seinen Urheber fast nichts kostete.

Setzen Sie nun beide Transaktionen auf Version 3. Das Commitment darf gar nichts zahlen, weil Regel sechs es unter der Relay-Untergrenze akzeptiert, solange das Paket die Hürde nimmt, was eine Monate im Voraus signierte Transaktion braucht. Es darf nur eine Kindtransaktion existieren, und sie darf 1.000 virtuelle Bytes nicht überschreiten, sodass die schlimmste Rechnung, die Ihnen jemand ausstellen kann, ein Hundertstel der alten beträgt. Kommt die Gegenpartei mit ihrer Kindtransaktion zuerst, verdrängt Ihre sie, indem sie mehr zahlt. Und das Paar reist als Einheit, weil Bitcoin Core 28.0 in derselben Version die Paketweiterleitung mit einem Elternteil und einem Kind auslieferte, wobei TRUC-Elternteile unter der Mindestrelaygebühr zugelassen sind.

Der ehrliche Vorbehalt ist die Verbreitung. BIP 431 sagt, dass der Nutzen gegen Pinning auf den Mempool eines einzelnen Nodes begrenzt ist, und wie sicher Ihre Transaktion ist, hängt davon ab, wie viel vom Netzwerk die Richtlinie ausführt. Version 3 war vor Bitcoin Core 28.0 nicht standardkonform, sodass ein Node, der noch auf einer älteren Version läuft, sie überhaupt nicht weiterleitet, und die Versionshinweise nennen diese neue Paketweiterleitung begrenzt und unter widrigen Bedingungen noch nicht zuverlässig.

TRUC-Transaktion vs. Transaktionsversionsnummer

Die Transaktionsversionsnummer ist ein Feld, das jede Bitcoin-Transaktion trägt, und TRUC ist das Bündel von Regeln, das ein Wert dieses Feldes nun kauft.

Die Version auf 3 zu setzen, ist die Art, wie ein Absender sich dafür entscheidet, aber die Regeln leben nicht in dem Feld. Es ist ein Kennzeichen; alles, was zählt, geschieht im Richtliniencode eines Nodes, weshalb ein aktualisierter Node die Transaktion weiterleitet, die ein älterer ablehnt. Der Konsens hat sich nie in die eine oder andere Richtung festgelegt. BIP 431 hält fest, dass Version 3 zuvor nicht standardkonform war und keine bekannten Konflikte mit früherer Verwendung hatte, sodass sich in Bitcoin Core 28.0 die Weiterleitbarkeit änderte, nicht die Gültigkeit.

TRUC-Transaktion vs. Cluster-Mempool

Cluster-Mempool wendet Topologiegrenzen auf jede Transaktion im Mempool eines Nodes an, während TRUC viel engere Grenzen nur auf Transaktionen anwendet, die sie anfordern.

Die beiden sind verwandte Arbeiten und keine Rivalen, und BIP 431 sagt das direkt: Cluster-Mempool begrenzt die Clustergröße für alle Transaktionen, nicht nur für die, die sich dafür entscheiden, und ist viel weniger restriktiv als die TRUC-Grenzen. Es lässt auch Lücken, die BIP 431 nennt: Cluster-Mempool löst Pinning weder über absolute Gebühren noch über die Anzahl der Konflikte und ist mit der CPFP-Ausnahme unvereinbar, auf die sich das ältere Lightning-Kanal-Design stützte. TRUC, die Verdrängung von Geschwistern und die Paketersetzung sind der Weg, der den Protokollen angeboten wird, die sich darauf stützten.