Warum wird von OP_RETURN-Transaktionen abgeraten? Macht die Verwendung von Version oder Sperrzeit einen Unterschied?

Warum wird von OP_RETURN-Transaktionen abgeraten? Zahlen sie im Vergleich zu anderen Transaktionen weniger Gebühren?

Wird es einen Unterschied machen, wenn dasselbe mit Version oder Sperrzeit gemacht wird, wenn die Daten entweder 1 oder 2 sind?

Beispiel:

OP_RETURN

createrawtransaction '[]' '{"data":"32"}'

Sperrzeit

createrawtransaction '[]' 2

AUSFÜHRUNG

Ändern Sie den Quellcode und machen Sie ihn konfigurierbar, obwohl er bereits 2 ist, also müssen Sie ihn für dieses Beispiel nicht ändern: https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/primitives/transaction.h#L263

Antworten (2)

Sie können dasselbe nicht erreichen, wenn Sie die Teile ohne Konsensbedeutung von nSequence+ verwenden nLockTime(wie es zum Beispiel Lightning tut ). Es ist einfach nicht genug Platz: 48 "freie" Bits.

Das Ändern der Version ist eine schlechte Idee, da es verwendet werden könnte, um sich für einen zukünftigen Soft Fork anzumelden, dessen Regeln noch nicht definiert wurden. Transaktionen mit einer Version < 2sind auch (und daher) keine Standards.

Danke. Ich habe gerade festgestellt, dass es einen großen Größenunterschied gibt (4 Bytes gegenüber 80 Bytes), wenn wir OP_RETURN mit den anderen beiden vergleichen. Auch die Sperrzeit ist nur nützlich, wenn sie zwischen 0 und dem letzten Block liegt, die Version ist für Standardtransaktionen auf 1 und 2 beschränkt. Sie sind sich immer noch nicht sicher, warum von OP_RETURN-Transaktionen abgeraten wird? Ein 40-Byte-OP_RETURN-Tx und ein normaler Segwit-Tx von 40 Byte sollten von vollständigen Knoten als gleich angesehen werden? Beide zahlen Gebühren für den Blockplatz.
OP_RETURN scriptPubKeys sollten bevorzugt Daten übertragen, da sie leicht identifiziert und gekürzt werden können. Der Speicherplatz der UTXO-Datenbank ist eine viel knappere Ressource als die der Blockchain.

Ob von OP_RETURN-Transaktionen abgeraten wird oder nicht, ist Ansichtssache.

Persönlich denke ich, dass Transaktionen keine Daten speichern sollten, die nicht für die Welt benötigt werden, um sie zu überprüfen, was per Definition für die in OP_RETURNs gespeicherten Daten der Fall ist. Entweder Sie verwenden es, um die Blockchain als Datenspeicher zu verwenden (was eine lächerlich ineffiziente Technologie für den Zweck ist, dem es dient, und bei ausreichendem Gebührendruck sehr teuer), oder Sie verwenden es, um dem Empfänger etwas mitzuteilen, das dies könnte wurden stattdessen außerhalb der Band gemacht.

Es ist also keine Kritik an OP_RETURN selbst – es ist eine Kritik an dem, was Sie damit zu tun versuchen. Es würde gleichermaßen für den Versuch gelten, Locktime oder Versions- oder Sequenznummern für denselben Zweck zu verwenden: Meiner Ansicht nach ist dies alles nur der Aufbau technisch minderwertiger Lösungen, die vollständig andere Ansätze (nicht die Verwendung der Blockchain) verwenden sollten.

Es gibt keinen Preisunterschied; die Bytes im OP_RETURN zählen genauso viel wie alle anderen (nicht-segwit) Bytes. Warum ist das besorgniserregend? Das Problem ist, dass jede Transaktion, selbst solche mit Ausgaben, die es nicht in das UTXO-Set schaffen, Kosten für das Netzwerk verursacht. Jeder vollständige Knoten muss es herunterladen und verarbeiten. Transaktionen zahlen eine Gebühr, aber diese Gebühr geht an Miner, nicht an Full-Node-Betreiber. Es gibt verschiedene Gründe für den Betrieb eines Knotens, aber alle beziehen sich auf die eine oder andere Weise darauf, dass er die Teilnahme an der Bitcoin-Wirtschaft ermöglicht. Sie tun dies nicht, um mit Ihren persönlichen und/privaten Daten umzugehen.

Ich glaube nicht, dass dies langfristig ein Problem darstellt – der Gebührendruck wird sinnlose Nutzungen der Blockchain auf andere Systeme verdrängen (und hat dies weitgehend verdrängt). Das Bitcoin-Ökosystem ist jedoch noch relativ jung, und um sein Wachstum nicht zu ersticken, finde ich es klug, Menschen davon abzuhalten, Knoten mit Transaktionsdaten zu belasten, die dem Ökosystem nicht helfen.

Wenn Sie aus irgendeinem Grund sowieso eine Datenspeicherlösung auf Basis der Blockchain erstellen, verwenden Sie auf jeden Fall OP_RETURN. Auf diese Weise belasten Sie zumindest die Blockchain und nicht das UTXO-Set.

Ich kann das UTXO-Set-Argument verstehen, aber die „Belastung der Blockchain“ geht über mein Verständnis hinaus. Die Halbierung von Bitcoin reduziert die Belohnungen alle 210.000 Blöcke. Bitcoin braucht also Transaktionen und Gebühren, um langfristig zu überleben. Wenn ein Projekt die Bitcoin-Transaktionen und -Gebühren erhöht, ist es netto positiv und sollte gefördert werden. Der vollständige Knoten muss alles verifizieren, also wie wichtig ist es, was verifiziert wird?
Wenn Menschen anfangen, Blockchain-Transaktionen für Aktivitäten zu verwenden, die nicht zur Bitcoin-Wirtschaft beitragen (z. B. nicht mit wirtschaftlichen Aktivitäten zusammenhängen, bei denen BTC bewegt wird), sind dies Opportunitätskosten für andere, die dies tun. Dies ist vor allem eine Sorge um Systeme wie Omni und Counterparty, die die Blockchain parasitär für die wirtschaftliche Aktivität konkurrierender Systeme nutzen. Schon früh – und vielleicht nicht mehr – stellten sie meiner Meinung nach eine sehr reale Bedrohung für Bitcoin dar, indem sie echte BTC-Aktivitäten auspreisten.
@Prayanks Argument scheint mir eine Planung für ein Scheitern zu sein. Ja, Bitcoin braucht Gebühren, um langfristig zu überleben. Aber zumindest für mich wird Bitcoin gescheitert sein, wenn es diese Gebühren nur durch OP_RETURNs erhalten kann. Hochwertige Transaktionen, Lightning Channel öffnen und schließen, was auch immer andere L2-Protokolle von der Blockchain benötigen, wird im Erfolgsfall konkurrieren. Und diese Anwendungsfälle würden den OP_RETURN-Anwendungsfall auspreisen. Ich glaube nicht, dass Bitcoin langfristig wirtschaftlich bedeutsam sein wird, wenn OP_RETURNS dazu beiträgt, die Transaktionsgebühren zu stützen.