Topic: So wählt ihr die passende Gebühr für Bitcoin-Transaktionen - page 3. (Read 1999 times)

Yes da stimme ich dir zu. https://bitcoinfees.net ist auf jeden Fall übersichtlicher und hat heute 2x perfekt gepasst.
1x war es die Rekordtransaktion wie vorhin beschrieben und beim zweiten Versuch mit ~20sat (geschätzt war ≤ 6 hours) wurde die Zeit mit 3 Blöcken Wartezeit deutlich unterboten. Also entweder ich hatte heute sehr viel Glück oder die vorgeschlagenen Werte funktionieren tatsächlich so gut

Und das byte/vbyte Thema hatte ich hier in #15 und danach schon mal angesprochen. Dachte mir doch dass mich das schon mal aufs Glatteis gebracht hat. In Zukunft weiß ich endgültig Bescheid... danke nochmal!

https://bitcoinfees.earn.com/ finde ich sehr verwirrend. Die Transaktionen anzuzeigen, die heute schon für eine bestimmte Fee bestätigt wurden halte ich für vollkommen irrelevante und verwirrende Information.
Dementsprechend ungenau ist auch die Schätzung welche Durchführungszeit eine bestimmte Transaktion mit einer bestimmten Fee hat.
Wenn ich dagegen weiß, dass aktuell x Transaktionen mit einer Fee von y laut Bitcoinfees.net auf Bestätigung warten und in einen Block 1500 - 2500 Transaktionen passen, kann ich für mich viel genauer abschätzen welche Fee ich wählen muss um recht schnell oder ganz besonders schnell bestätigt zu werden.

Dem Unterschied zwischen byte und vbyte liegt Segwit zugrunde, eine Erklärung findet sich hier: https://bitcoin.stackexchange.com/questions/92689/how-is-the-size-of-a-bitcoin-transaction-calculated/92700#92700

https://bitcoinfees.net ist aktuell down aber ich konnte vorhin noch einen aktuellen Wert ablesen.
Die Daten sind grundsätzlich aber schon sehr unterschiedlich wenn man z.B. mit https://bitcoinfees.earn.com/ vergleicht.
Ich habe vorhin eine 50 sat/byte Transaktion durchgeführt die ein voraussichtliche Durchführungsdauer von ~1 Stunde hatte.
Die erste confirmation war nach 3 Minuten durch. Das war absoluter Rekord

Diese 50.1 sat/byte aus Electrum werden auf blockchair.com aber so angezeigt:
Das Thema wirft immer wieder neue Fragen auf
Aber danke euch für die RBF Erklärung... das mit der falschen Übersetzung ist einleuchtend und der Ablauf ist verständlich.

Nein, der Punkt ist, dass RBF-Transaktionen recht einfach "gecancelt" werden können, SOLANGE sie nicht bestätigt sind.
Deswegen gilt hier, dass ganz einfach unbedingt auf eine Bestätigung gewartet werden muss.
Ich mache so gut wie alle Transaktionen mit RBF, weil ich gerne möglichst effizient versende (und daher mich an der Skala von https://bitcoinfees.net/ orientiere) und mit Pech kann es halt sein, dass länger kein Block gefunden wird oder auf einmal viele Transaktionen mit einer höheren Gebühr reinkommen und ich dann recht lange warten muss. Für diesen Fall kann ich die Fee dann mittels RBF hochsetzen.

Keine Angst.

Zu 1), die deutsche Übersetzung scheint einfach sehr kaputt zu sein.
Was damit gemeint ist, ist dass die Transaktion als "replacable" also "ersetzbar" gekennzeichnet ist.

Wenn eine Transaktion in einen Block aufgenommen wurde, dann ist sie bestätigt (1 Bestätigung). Da ist es dann egal ob sie den RBF tag hat oder nicht.
Nach der Bestätigung bringt dir das nichts mehr, du kannst sie also nicht mehr ersetzten.


Zu 2), Die werden immer und überall akzeptiert.
Was damit gemeint war ist vermutlich, dass es manche Services gibt, die auch Transaktionen ohne Bestätigung (also bevor sie in einen Block aufgenommen wurden) akzeptieren.
Da darf das Flag dann nicht gesetzt sein. Sonst könntest du die Transaktion ja absenden, deinen Key (oder was auch immer du digital sofort im Tausch bekommst) erhalten und die Transaktion ersetzten.

Bei solchen Services (die sehr sehr selten sind, da es einfach nur dumm ist 0-conf Transaktionen anzunehmen), muss die Transaktion eben ohne Flag gesendet werden oder du musst auf 1 Bestätigung warten.


Also im Fazit: Einfach immer mit dem Flag versenden. Praktisch schadet es nie.

Ich hätte noch mal eine Frage zu "Replace-by-Fee" (in Electrum). Es wird ja hier empfohlen das anzuhaken, weil man auf die Art noch mal mit höherer Gebühr nachschießen kann, sollte man feststellen, dass die Transaktion mit den vorher gewählten Gebühren nicht wunschgemäß durchläuft.
Theoretisch also eine gute Sache.

Jetzt lese aber dazu etwas verwirrende Aussagen. In Electrum selbst öffnet sich so eine Info-Blase, wenn man die Maus über "Replace-by-Fee" legt:
Hmm .. heißt, diese Transaktionen werden niemals als bestätigt gekennzeichnet, auch nicht, wenn sie Bestätigungen erhalten haben? Ich meine, dass Händler, Mixer, Exchanger usw. auf eine oder mehrere Bestätigungen warten, bevor sie den Zahlungsvorgang als akzeptiert ansehen, ist ja klar. Das ist ja eigentlich grundsätzlich der Fall (unabhängig von "Replace-by-Fee"), da bräuchte ja Electrum nicht extra drauf hin zu weisen.

Nach ein wenig Recherche habe ich u.a. hier noch eine Aussage dazu gefunden:
https://kryptozeitung.com/electrum-bitcoin-wallet-leitfaden/
Wieder ein klares "Hmm .."!
Das wäre ja soz. der GAU, wenn meine Bezahlung irgendwo oder meine Überweisung zum Exchanger abgelehnt wird (was passiert dann eigentlich, es kommt dann wieder automatisch zu mir zurück?), nur weil ich dieses Häkchen gesetzt hatte!
Falls dieses Risiko bestünde, würde ich dann (in wichtigen Fällen) doch lieber gleich eine etwas höhere Gebühr einsetzen, damit die Übweisung möglichst in der gewünschten Zeit durchläuft und vor allem nicht Gefahr läuft, abgelehnt zu werden.

Entscheidend bei der Gebühr ist die Sender Adresse, nicht die Empfangsadresse.
Eine bech32 -> legacy Transaktion kostet genau so viel wie eine bech32 -> bech32 Transaktion.

---

Dein Nachtrag ist korrekt.

Es kommt auf die gesamte Anzahl an Inputs an.
Jeder Input hat eine bestimmte "Größe". Hierbei spielt es keine Rolle wie viele Adressen im Spiel sind.
Auf dem technischen Level existieren keine Adressen, nur UTXO. Adressen sind für Menschen geschaffen um alles zu vereinfachen.




Die Privatsphäre schützen ist mit Bitcoin ziemlich komplex.
Da darf man sich mit Coin Control (also das Entscheiden wann welche UTXO an wen gesendet werden) keinen Fehler erlauben.

Zum Glück gibt es jedoch schon Protokolle, die es erlauben die BTC dezentral und ohne Vertrauen zu mixen (CoinJoin). Das Wallet Wasabi hat CoinJoin z.B. integriert.

So mehr oder weniger!
Nachfrage zu den Begrifflichkeiten: Mit "Adresse" ist dann eine einzelne BTC-Adresse gemeint (z.B. im Falle von bech32 "bc1...yz"), nicht die gesamte Wallet? Also wäre das mit diesen Inputs nur ein Problem, wenn immer wieder an diese eine Adresse gesendet wird. Wenn ich aber für jede Transaktion eine neue Wallet-Adresse von Electrum generieren lasse, dann nicht oder?
Also, wenn ich 20 kleine Eingänge in einer Wallet habe, die aber alle auf eine eigene Adresse gesendet wurden, besteht kein "Konsolidierungsbedarf"?

Ich glaube, das hat sich für mich schon aufgrund deiner obigen Antwort geklärt. Ich dachte, wenn ich jetzt bspw. nach einer Abschätzung 8 sat/byte investieren wollte, damit die Transaktion flüssig innerhalb der nächsten paar Blocks aufgenommen wird, meine Überweisung aber aufgrund der vielen vorherigen Inputs damit nicht hinkäme ... Der Denkfehler war aber wahrscheinlich, dass ich vergessen hatte, dass ja immer noch eine Multiplikation mit den Bytes stattfindet.
D.h. Electrum setzt diese Größe (die Bytes) schon immer richtig an, entsprechend des eingesetzten Betrages und dann damit verbunden, der vorhandenen Inputs. (Und genau darum geht es ja dann, dass man letzteres durch eine vorherige Konsolidierung drücken würde.)


PS:
Nachdem ich jetzt noch mal den von dir verlinkten Beitrag "Fees are low, use this opportunity to Consolidate your small inputs!" gelesen habe, denke ich, spielt es wohl keine Rolle, ob die Eingäge alle auf die selbe Adresse oder verschiedene Adressen gingen.

Denn unter "Privacy" schreibt er:
Der Hinweis würde ja keinen Sinn machen, wenn vorher eh schon alles auf eine Adresse gegangen wäre!
Übrigens interessanter Hinweis, der einem noch mal verdeutlicht, wie durchsichtig alles ist, bzw. wird, wenn man nicht aufpasst!

Das kann man aber kaum selbst entscheiden, da entscheident ist zu welcher adresse man schickt.

Ich würde ja gerne alle webseiten die ich nutze dazu zwingen bech32 zu nutzen, habe es aber noch nicht geschafft  

Aber natürlich macht es Sinn bech32 zu nutzen zum Konsolidieren. Keine Frage.

Edit:

Ich lag total falsch. Siehe bob123's post

Sehr schön, wenn es hilft, Gebühren zu sparen, das ist ja auch der Sinn dieses Beitrags.  

Ja genau, es ist relevant, wie viele Eingänge deine Adresse vor dem jeweiligen Sendevorgang erhalten hat.
Je mehr einzelne Transaktionen auf eine Adresse gesendet werden (die sogenannten Inputs), desto größer (gemessen in Bytes) wird die Transaktion, wenn man irgendwann wieder von dieser Adresse etwas versendet. Und da die Gebühr für jede Transaktion in Satoshis/byte gerechnet wird, muss man mehr Satoshis insgesamt dafür zahlen, da die Transaktion insgesamt größer ist. Klar soweit?

---

Genau, es lohnt sich immer, eine Adresse mit vielen Eingängen zu "konsolidieren", wenn die Gebühren niedrig sind, dazu gibt es einen berühmten Beitrag von LoyceV: [Aug 2020] Fees are low, use this opportunity to Consolidate your small inputs!
Was meinst du genau mit Komplikationen / einen Strich durch die Rechnung machen? Das einzige, was passieren kann, ist eine sehr hohe Gebühr, wenn du von einer Adresse mit vielen Eingängen sendest, wenn du sie mit einer hohen sat/byte Rate versendest oder die Transaktion braucht halt sehr lange, bis sie ankommt (sieht man an der aktuellen "Füllhöhe" des Mempools).

Und wenn du maximal sparen willst, nimmst du am besten SegWit bech32- Adressen: Wie erkennt man SegWit Adressen?

Sehr informativer Thread, obwohl ich nur einen Bruchteil davon verstehe! Aber das reicht, um seither bei ein paar Überweisungen jeweils eine satte Ersparnis rauszuholen, gegenüber der von Electrum vorgeschlagenen Gebühr.

Warum, hat das etwas mit diesen UTXOs zu tun?
Sagen wir, ich hätte wiederkehrend kleinere BTC-Eingänge (so irgendwo im - umgerechnet - zweistelligen Eurobereich). D.h. also z.B. in meiner Electrum-Wallet würden sich allmählich 10 ... 20 solcher Einzahlungen ansammeln.
Wäre es dann vielleicht clever, das mal in einem Schwung auf eine andere Wallet zu überweisen, wenn gerade die Gebühren niedrig sind? Damit ich dann im Falle einer späteren Weiterüberweisung keine Komplikationen wegen vieler UTXOs zu befürchten habe?
Und damit zusammenhängend meine nächste Frage: Kann es sein, dass mir die Sache mit diesen UTXOs einen Strich durch die Gebührenrechnung macht?

Aktuelle ASICS, wie der Antminer S9 machen 110 TH/s, also 110.000.000.000.000 Hashes pro Sekunde.
Das Nonce Feld beträgt 4 byte, also 32 bit. Ein ASIC geht also 2^32 Nonce values durch, macht 4.294.967.296 Möglichkeiten.

In einer Sekunde kann ein ASIC 25611 Mal alle Nonce values durchgehen und einen Hash berechnen.

Sollte also eine tx auftauchen die 'teurer' ist, kann diese in einem Sekundenbruchteil aufgenommen werden, anschließend werden wieder alle 2^32 möglichen Nonce values durchprobiert.
So lange bis der Hash value kleiner als die difficulty ist.

Es können aber auch andere Felder verändert werden:
- In der Coinbase Transaktion kann der "extraNonce" verändert werden -> ändert Merkle Root
- neue TX kann aufgenommen werden -> ändert Merkle Root
- der timestamp (gültig wenn: größer als median der letzten 11 Blöcke && kleiner als "network-adjusted time" + 2 Stunden)
- (auch die Block version kann geändert werden)

... und nach jeder dieser Änderungen (z.B. neue TX oder extraNonce) können wieder alle 4.294.967.296 Nonce values durchprobiert werden.

Es ist schlicht irrelevant, WAS in einem potentiellen Block geändert wird, bevor dieser gehasht und auf eine mögliche Gültigkeit geprüft wird. Das KANN der Nonce sein, die enthaltenen Transaktionen oder auch beispielsweise einfach die Zeit.
Kommt jetzt eine gewinnbringendere Transaktion rein, kann diese einfach mit eingebaut werden und eine andere TX fliegt raus. Das ist Teil des Spiels. Mann muss dann nicht "von vorn" beginnen sondern man puzzlet einfach weiter. Man verliert auch keine bisher geleistete Arbeit. Vielleicht geht ein bisschen Zeit verloren, weil man einen neuen Block zusammenpuzzlen (und ggf. in einem Pool an die Mitstreiter verteilen) muss aber dafür braucht man das ja auch nur relativ selten zu tun.

Ich würde vermuten, dass der Vorgang des "Zusammenbastelns" extrem schnell vonstatten geht und Miner mit einer hohen "Hashrate" entsprechend viele dieser Vorgänge pro Sekunde abwickeln können. Und bei jedem dieser Vorgänge wären dann die zu dieser Zeit im Mempool vorhandenen Transaktionen relevant.

Vielleicht wäre das eine Frage für nach "Mining" oder in den internationalen Bereich, weil selbst wenn meine Variante stimmen würde, wäre der Erklärungsansatz möglicherweise etwas daneben. Aber so habe ich das verstanden.

Spannende Fragen. Denke ich sollte mit mal etwas einfach verständliche (falls es sowas überhaupt gibt) Lektüre zum Thema Mining zulegen. Da gibt es ja noch viel viel mehr mit dem man im Alltag garnicht zu tun hat. Aber wäre schon interessant solche Dinge zu wissen

Außerdem... wir sind ja alle wegen der Technik hier

Nachdem ein Block gefunden wurde, bastelt sich jeder Miner einen Block mit den teuersten Transaktionen und fangen an eine Nonce zu suchen. Sollte nun eine Tx hinzukommen die teurer ist und ein Miner diese in seinen Block aufnehmen möchte, muss die Suche nach der Nonce jedoch von vorne beginnen, da die Hashes natürlich andere sind. Keine Ahnung, ob es sich lohnt aufgrund potentiell paar Satoshi Mehreinnahmen die bis dahin stattgefundene Berechnung zu verwerfen und von vorn zu beginnen. 

Hmm, gute Frage.
Ich nehme an, der nächste Block ist ausreichend bzw. würde mir kein plausibler Grund einfallen, warum es erst der übernächste sein sollte. Die Transaktionen sind ja erst dann fix, wenn der Block tatsächlich gefunden wird und zu diesem Zeitpunkt gilt der aktuelle Stand des Mempools als Referenz. Aber keine Garantie ob das 100% stimmt, was anderes wäre halt nur sehr wenig plausibel.

+1

Ist der frühestmögliche tatsächlich der nächste Block oder erst der übernächste?

Super vielen Dank euch beiden!
Dann hatte ich es schon richtig verstanden bzw. im Kopf
War letztens wirklich Pech bzw. hatte sich auch Coinomi verschätzt.
Die knapp 60 Minuten waren richtig bitter... wenn es schnell gehen soll kommt einem das wie eine Ewigkeit vor. Nächstes Mal lieber früher absenden oder eben händisch das vorgeschlagene Maximum x2 nehmen.

Danke euch nochmal und unkritische Transaktionen werde ich (BuLi Tippspiel z.B.) direkt mit Minimalgebühr auf die Reise schicken und beobachten

Vorhersagen kann man das leider nie, vor allem nicht zwei Tage. An sich gibt es wiederkehrende Muster, wie im ersten Beitrag beschrieben (Nachts und am Wochenende kann man teilweise sehr günstig innerhalb der nächsten Blöcke senden, während es unter der Woche Vormittags bis Abends mehr Transaktionsaufkommen gibt).
Es kann also gut sein, dass so viele Transaktionen mit hoher Gebühr neu hinzukommen, dass sich der Mempool immer weiter füllt und die eigene Transaktion dann ewig warten muss.

---

Das kann entweder daran liegen, dass zu dieser Zeit der Mempool sehr voll war und viele Transaktionen mit mehr Gebühr vor deiner bestätigt wurden, bis sie erst dran kam. Oder es lag daran, dass in dieser Zeit kein Block gefunden wurde, sondern erst nach einer Stunde. Wenn kein Block gefunden wird, ist es prinzipiell egal, ob man mit mit 1 sat/byte sendet oder mit 2000. Die frühestmögliche, erste Bestätigung bekommt man im besten Fall erst mit dem nächsten Block. Es kann sogar sein, dass der nächste Block manchmal über eine Stunde auf sich warten lässt.

---

Das macht keinen Unterschied, wann man sie reinsendet. Sie wird jedoch erst dann bestätigt, wenn nach und nach alle anderen "wartenden" Transaktionen mit mehr sat/byte bestätigt worden sind und die eigene dann schließlich zu den Transkationen gehört, die am meisten sat/byte hat. Denn Miner bestätigen immer die Transaktionen zuerst, die die höchsten Gebühren haben, sie bekommen ja nicht nur die Blockbelohnungen, sondern auch die Gebühren.
Wie man am besten sieht, welche Fee man braucht, um die Transaktion in den nächsten Block zu bekommen, steht oben ganz gut bzw. eignet sich die Seite des Mempools ideal dafür, am besten die letzte Grafik "Mempool size". Größte Unbekannte ist da, wann der nächste Block gefunden wird, denn wenn der lange braucht, füllt sich bis dahin der Mempool so sehr, dass dieser nächste Block die eigene Transaktion nicht beinhaltet, weil bis dahin mehr Transaktionen mit mehr Gebühr vor deiner kommen.