Woher kommt dieses Muster in der Gebührenverteilung pro Block?

Beim Erstellen eines Tools/einer Visualisierung, die die Gebühr einer Transaktion entsprechend ihrer Position in einem bestimmten Block anzeigt, bin ich in einigen Blöcken auf ein Muster gestoßen.

Ich erwarte, dass ein typischer Block mit Transaktionen mit dem höchsten Gebühren-pro-Byte-Verhältnis (Gebührenrate) beginnt und dann mit Transaktionen fortfährt, bei denen die Gebührenrate langsam abnimmt. Oft gibt es einige CPFP-Transaktionen, bei denen auf einen niedrigeren Gebührensatz ein höherer Gebührensatz folgt.

Was ich jedoch sehe, ist, dass in einigen Blöcken (von verschiedenen Minern) 9 Sat/B-Transaktionen mit 5 Sat/B-Transaktionen dazwischen gemischt sind. An einer späteren Position im Block sind es wieder 5 sat/B-Transaktionen. Dies geschieht über mehrere Blöcke und verschiedene Miner. Ich denke, es stammt von getblocktemplate oder etwas ähnlichem.

Ich habe eine Version meines Tools gegabelt und 5 Sat/B-Transaktionen in Blau hervorgehoben (kann hier gefunden werden , fühlen Sie sich frei zu erkunden). Da sich dies noch in der aktiven Entwicklung befindet, werde ich Screenshots einiger Blöcke hinzufügen, falls die Links nicht mehr funktionieren. Ich habe bewusst eine Reihe von Blöcken ausgewählt, bei denen ich denke, dass klar ist, was ich meine.

Musterblöcke:

Block 517361Block #517361 abgebaut von ViaBTC (?)

Block 517363Block #517363 abgebaut von BTC.TOP (?)

Block 517357Block #517357 abgebaut von BTC.com (?)

und hier ist auch einer von Slush.

Fragen:

1) Ist dieses bekannte Verhalten eines Algorithmus, der Blockvorlagen erstellt?

2) Welche Motivation steckt hinter diesem Feature. Ist es ein Fehler?

3) Gibt es häufig verwendete getblocktemplateAlternativen?

Antworten (2)

1) Ist dieses bekannte Verhalten eines Algorithmus, der Blockvorlagen erstellt?

Ja. Dies ist ein Verhalten, das in Bitcoin Core vorhanden ist.

Bitcoin Core bündelt Transaktionen in „Pakete“ aus einer oder mehreren Transaktionen. Jedes Paket besteht aus einer unbestätigten Transaktion und ihren untergeordneten Transaktionen (sofern vorhanden), um den Fall „Child-Pays-For-Eltern“ abzudecken. Der Transaktionsgebührensatz wird für das gesamte Paket berechnet (Gesamtgebühren, die von den Transaktionen im Paket gezahlt werden, dividiert durch die Größe des Pakets).

Wenn Transaktionen ausgewählt werden, sind es wirklich die Pakete, die ausgewählt werden. Da die Pakete in der Reihenfolge der Paketgebühr in den Block eingefügt werden, erhalten Sie manchmal einige Transaktionen mit niedriger Gebühr, gefolgt von einer Transaktion mit wirklich hoher Gebühr, da sie alle Teil derselben Transaktion waren und die Transaktion mit hoher Gebühr ein Kind, das für seine Eltern bezahlt hat.

Dies wird als "Bestellung der Vorfahrengebührensätze" bezeichnet.

2) Welche Motivation steckt hinter diesem Feature. Ist es ein Fehler?

Es ist weder ein Feature noch ein Fehler, es ist nur eine Eigenart, wie die Transaktionsauswahl funktioniert.

Siehe auch: https://bitcointalk.org/index.php?topic=2058831.0

Danke Andreas, aber das beantwortet meine Frage nicht wirklich. Ich habe in meiner Frage CPFP-Transaktionen mit der typischen niedrigeren Gebührenübertragung erwähnt, gefolgt von einer hohen/höheren Gebührenübertragung, die in der Visualisierung leicht zu erkennen sind. Aber das meine ich nicht. ZB in Block #517363 sind ~30 5 sat/B tx, gefolgt von einem einzelnen 9 sat/B tx und dann wieder von mehreren 5 sat/B tx (ungefähr bei Position 1200). Dies (glaube ich zumindest, werde es später überprüfen) scheint nicht wie CPFP zu sein, oder ist zumindest nicht die richtige Position im Block für ein großes Paket dieser 31 TX's. (30*5sat/B + 1*9sat/B)/31tx wäre später im Block.
Ich glaube, Sie berechnen die Gebühr tatsächlich falsch. Ich habe es noch einmal überprüft und erhalte nicht die gleichen Gebühren wie Sie für diese Transaktionen bei den angegebenen Blockindizes. Die Zahlen, die Sie haben, stimmen mit sat/byte überein, nicht mit sat/vbyte. Ich denke, Sie berechnen die Gebühren für Transaktionen, die Segwit-Eingaben ausgeben, nicht richtig.
Ja du hast Recht. Ich habe es vor ungefähr 5 Minuten entdeckt, als ich mir die oben genannten Transaktionen angesehen habe. Danke!
Nebenbei habe ich ein schnelles Python-Skript geschrieben, um zu berechnen, welche Transaktionen in einem bestimmten Block zusammengefasst sind: gist.github.com/achow101/dfb1016f78e653656ec40cd019f8116b . Ich denke, es funktioniert.

Wie Andrew Chow betonte, waren meine Gebührenberechnungen falsch. Ich habe die totalSize der Transaktion verwendet. Richtig wäre gewesen, die virtualSize zu verwenden.

Mit korrekten Berechnungen sieht die Visualisierung viel besser aus, als ich erwartet hatte.

Block 517361Block #517361 (vergleiche oben)

Woher kommt dieses Muster in der Gebührenverteilung pro Block?
AntwortenHierDatenschutz-Bestimmungen1y, 0v