So berechnen Sie die Transaktionsgröße vor dem Senden (Legacy Non-Segwit - P2PKH/P2SH)

Unter der Annahme, dass alle Eingaben, die Sie ausgeben, aus regulären "Pay-to-Address"-Transaktionen stammen, trägt jede Eingabe 180 (plus oder minus 1) Bytes zur Transaktion bei. Jede Ausgabe fügt der Transaktion 34 Bytes hinzu. Und es gibt feste zusätzliche 10 Bytes, die immer vorhanden sind.

Das „plus oder minus 1“ kommt daher, dass jede Eingabe eine Signatur benötigt, um beansprucht zu werden. Die Signatur enthält zwei 32-Byte-Werte, aber wenn einer der Werte ein erstes Byte von 0x80oder mehr hat, wird ihm ein 0x00Byte vorangestellt. Ich gehe also davon aus, dass einer der beiden hoch und der andere niedrig ist. Auf diese Weise bin ich höchstens ein Byte pro Eingang daneben.

Wenn Ihre Transaktion also inEin- und outAusgänge hat, ist die Transaktionsgröße in Byte:

in*180 + out*34 + 10 plus or minus 'in'

Diese Transaktion hat beispielsweise 40 Eingaben und 16 Ausgaben. Das gibt uns eine Transaktionsgröße von

40*180 + 16*34 + 10 +- 40

dh 7754 +- 40Byte. Die tatsächliche Größe ist 7761Byte.

Wenn die Eingaben von "Pay-to-Pubkey"-Transaktionen stammen, dann sind die Eingaben kleiner als für "Pay-to-Address"-Transaktionen. Und dies wird auch für "Pay-to-Script-Hash"-Eingaben unterschiedlich sein, je nachdem, wie/ob dies implementiert ist.

Bearbeiten: Diese Transaktion wurde mit Bitcoins durchgeführt, die beim Linode-Überfall gestohlen wurden, und zeigt eine Transaktionsgröße von 1337 , möglicherweise eine absichtliche Verwendung von Leetspeak in der Blockchain.

Edit2: Jetzt, da komprimierte öffentliche Schlüssel alltäglich sind, ist jede Eingabe 32 Byte kürzer und die Transaktionsgröße ist jetzt:

in*148 + out*34 + 10 plus or minus 'in'

Hier sind einige Berechnungen basierend auf der Protokolldokumentation .

Eine Bitcoin-Transaktion setzt sich wie folgt zusammen:

• Version (4 Byte)
• TxIn-Zähler (1 ~ 9B)
• Für jeden TxIn:
  • Endpunkt (36B)
  • Skriptlänge (1 ~ 9B)
  • ScriptSig(?)
  • Sequenz (4B)
• TxOut-Zähler (1 ~ 9B)
• Für jeden TxOut:
  • Wert (8B)
  • Skriptlänge (1 ~ 9B)*
  • Skript (?)*
• Sperrzeit (4B)

Unter der Annahme, dass eine standardmäßige P2SH/P2PKH-Transaktion erstellt wird, wird die mit Stern markierte Skriptlänge an 1 Byte gebunden, da die Skriptlänge als variable Ganzzahl codiert ist; während die mit Sternchen markierte Skriptgröße an 24 Byte gebunden ist, da sie nur einen Skript-Hash enthält.

Zusammenfassend können wir also davon ausgehen, dass die maximale Grenze jedes TxOut 34 Bytes beträgt, wenn wir an eine P2SH/P2PKH-Adresse zahlen, da in jedem Ausgabeskript 4 Opcodes vorhanden sind. Eine tolle Aufschlüsselung finden Sie hier .

Angenommen, wir geben P2PKH-Outpoints für unseren TxIn aus. Unsere ScriptSig (bestehend aus einer 72-Byte-DER-codierten Transaktionssignatur + 33-Byte-öffentlicher Schlüssel) wäre 146 Byte groß und unsere Skriptlänge verbraucht nur 1 Byte, da die Größe der Script-Sig kleiner als 0xFD ist.

Daher beträgt eine Standard-P2PKH/P2SH-Transaktion, die einen UTXO ausgibt, der mit einer grundlegenden ScriptSig-Zahlung für nur EINEN Ausgang eingelöst werden kann, 189 Bytes. Ansonsten können wir dies auch weiter verallgemeinern zu:

inmarkiert die Anzahl der TxIns

outmarkiert die Anzahl der TxOuts

Unter der Annahme, dass in< 254 und out< 254.

Größe der P2SH/P2PKH-Transaktion = in* 146 + out* 33 + 10

Die Berechnung der Größe von P2SH/P2PKH-Transaktionen, die mit komplexen Eingaben finanziert werden (z. B. UTXOs, die mit M-von-N-Signaturen ausgegeben werden können, gehashte zeitgesperrte Verträge), ist von Natur aus schwierig und hängt von der Komplexität des RedeemScripts ab, das zum Erstellen des scriptHash of verwendet wird die vorherige P2SH-Transaktion.

Es ist wichtig zu verstehen, dass die Transaktionsgebühr, die Sie für eine Zahlung zahlen müssen, davon abhängt, wie Sie die Mittel erhalten haben, die Sie für die Zahlung verwenden. Die ausgehende Zahlung (vorausgesetzt, sie geht nur an einen Ort) wird immer gleich groß sein. Der „out“-Teil wird also immer zwei standardmäßige „Pay-to-Address“-Skripte haben. Die Größe des „in“-Teils hängt davon ab, wie viele Ausgaben Sie beanspruchen müssen, was davon abhängt, wie Sie die Mittel erhalten haben.

Ich würde also nicht vorschlagen, die Transaktionsgebühr der abhebenden Person in Rechnung zu stellen, da Sie den Benutzer dann auf der Grundlage von Parametern abrechnen, über die der Benutzer keine Kontrolle hat. Die Transaktionsgebühren hängen beispielsweise davon ab, wie viele Transaktionsausgaben Sie sammeln müssen, um die benötigten Coins zu erhalten. Das hängt ganz davon ab, wie Ihre Fonds strukturiert sind.

Stellen Sie sich vor, Sie gehen in ein Süßwarengeschäft und erfahren, dass ein Schokoriegel 35 Cent kostet, aber als sie Sie dann anriefen, haben sie eine Gebühr von 15 Cent verlangt. Als Sie sie fragten, wofür es war, erklärten sie, dass der vorherige Kunde sie alle in Pfennigen bezahlt hatte, und um Ihnen Ihr Wechselgeld zu geben, müssten sie all diese Pfennige zählen, und das dauert länger.

Ich denke, Sie wären sauer, weil diese Gebühr damit zu tun hat, wie ihre Gelder strukturiert sind, und nichts mit Ihrer Transaktion zu tun hat. Sie würden erwarten, dass sie diese Kosten entweder auffressen oder in ihre Preise einbauen. Sie würden nicht erwarten, dass sie genau herausfinden, wie viel es kostet, Ihnen einen Schokoriegel zu verkaufen, basierend auf ihrer internen Geschäftskonfiguration, und Sie auf dieser Grundlage persönlich belasten.

Entweder eine pauschale Gebühr pro Abhebung erheben (.01 BTC ist derzeit üblich) oder die Transaktionsgebühren selbst tragen. Und setzen Sie sinnvolle Strategien ein, um Transaktionsgebühren zu senken . Aber meiner Meinung nach möchte man solche Kosten wirklich nicht an einen Kunden weitergeben.