Topic: Transaktion hängt fest? Was tun wenns klemmt. - page 19. (Read 217105 times)

Stimmt das ist mir auch aufgefallen, werds gleich einbauen.

---

Ja, da steckt nicht viel hinter. Ich mach jetzt n Update und zieh das Kapitel einfach vor. Chris601 kann ja gerne seine Version posten, dann gibts mehr Auswahl.

Erstmal vorweg: Schöne Idee!

Zur Frage: als "Zwischenstation" zwischen Hardware-Wallet und Exchange nutze ich gerne das Mycelium-Wallet unter Android. Da ich hier quasi nie die selbe Fee in ansonsten gleichen Situationen zahle, scheint hier die Gebühr dynamisch berechnet zu werden.
Allerdings weiß ich weder wo noch auf welcher Grundlage.

Cool danke!

Genaugenommen ist es nicht mal ein Script sondern einfach nur das RPC-Kommando: "bitcoin-cli sendrawtransaction".

Das kann man einfach händisch eintippen oder eben als Script einfach nur diesen Befehl regelmäßig absetzen lassen.

und wie geht das, bzw würdest Du das Script hier posten?
Gibt bestimt auch Anfänger mit Problemen, die bereits einen Full-Node betreiben 

Ja natürlich geht das. Wenn man mit Core (samt wallet) eine Überweisung tätigt, rebroadcastet Core diese TX sowieso alle 30 min.

Auf dem Raspberry z.B. läuft Core in der Regel aber ohne Wallet und kennt also nicht unbedingt die zu pushende TX bzw. bzw. vergisst sie nach eingestellter Zeit.
Es ist aber sehr einfach dort ein Script zu basteln was im gewünschten Intervall die TX pusht (oder man macht das mit einem Befahl manuell). Diese TX muss auch keine eigene sein sondern kann eine beliebige signierte TX sein.
Das war übrigens einer der Gründe, die mich zum Betrieb eines Fullnodes auf dem Raspi bewegt haben. Das regelmäßigt Pushen meiner hängenden TXen.

Schöne Anleitung 
Wenn man die Möglichkeiten sieht, die die neuen clients bieten, ist es wahrscheinlich nötig sich demnächst von den "alten" wallets wie Multibit-Classic zu verabschieden 
Was mich noch interessieren würde, ist das Rebroadcasting mit Core.
Du schreibst:

Kann man sowas auch mit einem kleinen zu Hause betriebenen Fullnode machen, der täglich 24h läuft auf Basis eines Raspberry? Denke das bedeutet, das man die TX immer wieder pushed oder?

Arbeite gerade an dem Bereich für dynamische Gebühren. Wenn jemand noch (Handy-) Wallets und Services weiß die das auch können, gerne hier posten. Genauso zum Bereich Eingänge, ich hab mir zwar so gut wie jede Wallet schonmal angesehen, aber in der Regel habe ich da nie Coins drauf. Entsprechend weiß ich nicht wie sich das mit den Eingängen verhällt. Danke!

Danke.


Ich guck das ich bei längeren Abschnitten immer ein tl;dr einbaue. Gibts davon eigentlich eine deutsche Variante? zl;ng (zu lang; nicht gelesen)?


Seh ich auch so, es gibt aber auch immer die Möglichkeit das über Web Interfaces zu machen oder sich an jemanden mit Full Node zu wenden. Ich hab dafür Ruby Code und müsste noch irgendwo eine Batch Datei haben die das automatisieren.


Stimmt. Ich will auch noch eine Art Rating einbauen damit auf den ersten Blick klar ist was wie einfach oder komplex und hilfreich ist. Bin mir noch nicht ganz sicher wie, da ich das Inahltsverzeichnis auch nicht überladen will. Ggf. eine Extra Tabelle oder einen eindeutigen Farbcode (z.B.: rot, orange, gelb, grün).

Schönes Konzept.

Hoffentlich schreckt der Umfang der Ausarbeitung nicht User ab, die schnell Hilfe suchen. Aber das Klicken durch die Menüs ist super und führt hoffentlich schnell zum Ziel.

Zwei Gedanken meinerseits:
* Gut, dass du bei Rettungsmaßnahmen "Lass dir Zeit - rebroadcasting" als erstes genannt hast. Man kann vielleicht betonen, dass bisher ALLE gültigen Tranasaktionen irgendwann in einem Block untergekommen sind. Sogar alle Transaktionen ohne Fee. (Ich überweise zum Zusammenführen kleiner Beträge bei mir regelmäßig ohne Fee auf eine Sammeladresse. Das hat bis jetzt maximal 266 Tage gedauert. U.U. funktioniert das aber wirklich nur mit Rebroadcasting - also z.B. Core.)
Meiner Meinung nach genügt bei zeitunkritischen Transaktionen mit Fee einfaches Warten absolut aus.

* Doublespend als Rettungsmaßname (z.B. nach -zapwallettxes) ist in der Praxis praktisch kaum noch möglich und birgt die Gefahr, dass es zum Glücksspiel wird, WELCHE TX dann wirklich bestätigt wird.
Der Mempool "vergisst" kaum noch und solange die ursprüngliche TX da rumgeistert, wird die neue nicht  verbreitet (auch nicht mit besserer Fee). -zapwallettxes halte ich deshalb für trügerisch, weil die Coins dann zwar "wieder da" zu sein scheinen, aber eben "verbrannt" sind und nicht so ohne weiteres neu ausgegeben werden können.

Das "Zurückholen" der Coins und u.U. Doublespend muss in dieser Ausarbeitung der Vollständigkeit halber natürlich erwähnt werden, aber es sollte aktuell eben davor für Anfänger gewarnt werden, was passieren kann.

-reserve-

Double-Spend
zurück zum Inhaltsverzeichnis.

Status: unvollständig

Vorbemerkungen:

Ein Double-Spend, also ein und dieselben Coins mehrfach ausgeben, ist mit Bitcoin nicht möglich. Der Begriff bezeichnet den Prozess eine unbestätigte Transaktion durch eine andere zu ersetzen. Eine solche neue Transaktion wird als Double-Spend(-Angriff) bezeichnet. Sei A die ursprüngliche Transaktion und B der Double-Spend, dann wird ein Full der A kennt B nicht akzeptieren. Ausnahmen wie RBF lassen wir dabei außer acht. Aus sicht des Netzwerks insgesamt sind A und B gleichwertig. Wenn eine der beiden einen Knoten zuerst erreich, ist die andere für den Knoten ungültig. Da wir aus dem Abschnitt über den Mempool wissen das Full Nodes Transaktionen im Normalfall nach 72 Stunden vergessen, können wir das nutzen um mit einem Double-Spend die Transaktionsgebühr nachträglich zu erhöhen. Als Angriff wird diese Technik bezeichnet, weil wir dabei auch ändern können wohin die Bitcoin gesendet werden.

---

Praxis:

Wie geht nun also ein solcher Angriff in der Praxis? Am einfachsten ist es, wenn die Wallet Software die man benutzt es einem erlaubt eine unbestäitgte Transaktion zu entfernen. Dann erzeugt man danach einfach wie gewohnt eine neue und lässt sich zur Not ein bisschen beim broadcasten helfen.

Transaktionen entfernen:

Bitcoin Core:

Bitcoin Core (und analog vermutlich auch Bitcoin Unlimited) bietet seit Version 0.12 zwei Möglichkeiten Transaktionen zu entfernen. Zum einen gibt es den Punkt 'Abandon transaction' wenn man mit der rechten Maustaste auf eine unbesätigte Transaktion klickt. Sollte dies nicht funktionieren gibt es die Möglichkeit beim Starten -zapwallettxes zu übergeben. Dies entfernt alle Transaktionen aus der Wallet und fügt alle bestätigten wieder hinzu. Unbestätigte Transaktionen gehen mehr als Nebeneffekt verloren. Unter Linux/Mac startet man aus dem Terminal heraus und fügt den Wert an.

Windows:

#1 Bitcoin Client beenden
#2 Mit Win + R "Ausführen" öffnen
#3 c:\Program Files\Bitcoin\bitcoin-qt.exe -zapwallettxes eingeben. Notfals den Pfad anpassen und andere Startparameter (wie -datadir=) anfügen.
#4 Mit eine klick auf "OK" bestätigen.

Electrum:

Electrum bietet keine einfache Möglichkeit unbesätigte Transaktionen aus der Wallet zu entfernen. Selbst wenn man vom Seed wiederherstellt bekommt man vom Electrum-Server auch die unbesätigte Transaktion wieder übertragen. Hier ist also Handarbeit angesagt. Danke den Reddit User jcoinner für die ursprüngliche Anleitung.

#1 Erstellt eine Kopie der Wallet Datei. Besser eine Kopie zu viel als hinterher kaputte Dateien.
#2 Stell sicher das Electrum geschlossen ist.
#3 Finde die Wallet Datei.
#3.1 Windows: Win + R -> %APPDATA%\Electrum\wallets -> OK
#3.2 Mac: Finder -> Folder (shift+cmd+G) -> ~/.electrum
#3.3 Linux: ~/.electrum
#4 Öffne die Datei mit einem Texteditor (nicht Word o.ä.), wie notepad(++), leafpad, nano, vi, sublime, etc.
#5 Suche nach dem Abschnitt verified_tx3, der oberste Eintrag ist die letzte Transaktion. Kopiere die ID.
#5.1 Einige ältere Versionen von Electrum benutzen ein anderes Datei Format. Bei diesen kann ich (oder jmd. anderes) ggf. aushelfen wenn ich die Datei sehe. Solange die Datei mit einem guten Password gesichert ist geht man kein Risiko ein seine Bitcoin zu verlieren.
#6 Such nach dieser Transaktion in den Abschnitten transactions, txi und txo und entferne sie.
#6.1 Wichtig hier ist es nicht das Format (JSON) zu beschädigen. Ein Komma am Ende der Zeile muss ggf. ebenso entfernt werden wie Klammer-Blöcke.
#7 Speicher die Datei
#8 Trenne die Verbindung zum Internet.
#9 Öffne die modifizierte Datei in Electrum.
#9.1 Ist die unbesätigte Transaktion verschwunden, erstell eine neue.
#9.2 Lässt sich die Datei nicht öffnen oder ist die Transaktion noch vorhanden GOTO #4
#10 Speichere die neue Transaktion als Datei

Link zum Bild: https://i.imgur.com/LzQOLWA.png
#11 Stell die Verbindung zum Internet wieder her und sende die Transaktion.
#11.1 Sie kann im Zweifel Über Werkzeuge -> Transaktion laden -> Aus Datei erneut geöffnet werden.
#11.2 Vermutlich wird der Electrum Server sie nicht akzeptieren, mit eine klick auf Kopieren (im Fenster nach #11.1) erhällt man die roh Transaktion und kann sich damit beim broadcasten helfen (lassen).

---

---

-reserve-

Double-Spend Notitzen:

Bitcoin Transaction Fee Booster by achow101 -> https://bitcointalksearch.org/topic/ann-bitcoin-transaction-fee-booster-1506632
Electrum TX removal -> https://www.reddit.com/r/Bitcoin/comments/59g849/how_to_delete_unconfirmed_transactions_on_electrum/?st=izu4gsbd&sh=436241b5

Mein Freund der Miner:

kauf dir nen Freund (mit CC): https://pushtx.btc.com/ - scam?

RBF in Schildbach ? -> https://bitcointalksearch.org/topic/raise-network-fee-assumes-1kb-transaction-and-spends-outrageous-fee-1811078

Einleitung:

Bitcoin 2017, die Blöcke sind voll und es kommt immer wieder zu Verzögerungen bei Transaktionen. Dieser Thread soll eine Übersicht bieten, über die Möglichkeiten die einem bleiben wenn es erstmal klemmt, aber auch über Möglichkeiten vorzubeugen. Der Thread wird kontinuierlich erweitert, Fragen, Anregungen, Verbesserungen, Hinweise auf grobe und weniger grobe Schnitzer sind gerne gesehen.

---

---

Inhaltsverzeichnis:

• Einleitung
• Allgemeine Techniken und Konzepte
  
  • Bestätigungen - auf die erste kommt es an.
  • Transaktionen - auf die Größe kommt es an.
  • Eingänge - was macht meine Wallet da?
  • Priority - warum das ein alter Hut ist.
  • Varianz - warum es manchmal einfach dauert.
  • Verweiste Blöcke - warum wir uns darüber nicht den Kopf zerbrechen.
  • Mempool - was ist das und wie funktioniert es?
• Vorbeugende Maßnahmen.
  • Die 'richtige' Gebühr
    
    • Programme mit dynamischen Gebühren
    • Cointape
  • Die 'richtige' Zeit
  • Replace By Fee - RBF
• Rettungsmaßnahmen - Was tun wenns klemmt?
  • Lass dir Zeit - rebroadcasting
  • Child Pays For Parent - CPFP
  • Double Spend
  • Mein Freund der Miner

---

---

Allgemeine Techniken und Konzepte:
zurück zum Inhaltsverzeichnis.

In diesem Abschnitt sollen allgemeine Techniken und Konzepte erklärt werden, auf die in anderen Bereichen zurückgegriffen wird.

---

Bestätigungen - auf die erste kommt es an.
zurück zum Inhaltsverzeichnis.

Eine unbestätigte Transaktion konkuriert mit alle anderen unbestätigten Transaktionen um begrenzten Platz in einem Block. Die erste Bestätigung bedeutet, dass ein Block gefunden wurde, welcher die Transaktion beinhaltet. Alle folgenden Bestätigungen dienen nur der zusätzlichen Sicherheit, benötigen aber keinen weiteren Platz in anderen Blöcken.

---

Transaktionen - auf die Größe kommt es an.
zurück zum Inhaltsverzeichnis.

tl;dr: Wer seine Bitcoin in kleinen Häppchen erhält, zahlt im Schnitt eine höhere Gebühr.

Eine Transaktion braucht Platz - in Byte - in einem Block. Dafür wird eine Gebühr - in Bitcoin - gezahlt. Die Gebühr pro Byte ist das wichtigste Kriterium für Miner Transaktionen für die Bestätigung auszuwählen. Andere Konzepte wie Priority spielen keine Rolle mehr. Für eine große Transaktion muss man eine entsprechende hohe Gebühr bezahlen. Wie aber wird festgelegt wie groß eine Transaktion ist? Ganz einfach

komprimierter pubkey:

unkomprimierter pubkey (inzwischen unüblich, außer für z.B. Vanity Adressen):


Ein Eingang bezeichnet dabei Bitcoin die früher empfangen wurden. Dabei spielt es keine Rolle ob auf der gleichen Adresse oder jeweils einer neuen.
Ein Ausgang bezeichnet alle Bitcoin die transferiert werden. Der übliche Fall ist ein Ausgang zu jemandem den man bezahlt und ein Ausgang mit dem Wechselgeld zurück in die eigene Wallet.

Wer also seine Bitcoin immer in kleinen Häppchen erhält, zahlt im Schnitt eine höhere Gebühr als jemand der größere Überweisungen erhält. Ein kleines Beispiel um dies zu verdeutlichen.

Ernie und Bert erhalten zusätzlich zu ihrer normalen Gage 0,1 Bitcoin für jeden wöchentlichen Auftritt in der Sesamstraße. Eine übliche Gebühr für eine zügige Bestätigung nehmen wir mit 100 Satoshi pro Byte an. Ernie lässt sich direkt nach jeder Show auszahlen, Bert wartet und erhält alle 13 Wochen (4x im Jahr bei 52 KW) eine Transaktion über je 1,3 Bitcoin. Nach einem Jahr haben beide 5,2 Bitcoin angespart. Beide wollen nun für 5 Bitcoin etwas kaufen. Ernie nutzt dafür 51 Eingänge zu je 0,1 BTC. 50 für den 5 Bitcoin Ausgang und einen weiteren für die nötigen Gebühren. Ein weiterer Ausgang wird für das Wechselgeld verwendet. Bert nutzt alle 4 Eingänge und erzeugt ebenfalls 2 Ausgänge.

Berechnung der Größe:


Das entspricht einer Gebühr von:


bzw. einem Anteil an den übertragenen Bitcoin von:

---

Eingänge - was macht meine Wallet da?
zurück zum Inhaltsverzeichnis.

Wer den Abschnitt zur Größe einer Transaktion gelesen hat, wird sich vermutlich Fragen wie man den nun weiß wieviele Eingänge man braucht. Meistens gibt man ja nur einen Bruchteil. Die Antwort ist kompliziert und hängt vom verwendeten Programm/Service, ab, daher eine Auflistung:

• Bitcoin Core 0.13.x - einzelne Eingänge wählen mit Coin Control.
• Electrum 2.7.x+ - mit 'Freeze' Eingänge von bestimmten Adressen blockieren oder mit 'Send from' nur Eingänge einer Adresse nutzen.
• Multibit HD - ?

---

Priority - warum das ein alter Hut ist.
zurück zum Inhaltsverzeichnis.

Als der Platz in den Blöcken noch nicht so knapp war, gab es ein weiteres Kriterium nach dem Miner Transaktionen vorsortiert haben. Die Priority [engl. Priorität], auch bekannt als der Bitcoin-Tag. Ein Bitcoin-Tag ist ein Eingang, im Wert von 1,0 Bitcoin mit 144 Bestätigungen (entspricht einem Tag). Das Verhalten war relativ verlässlich. Hatte ein Eingang mindestens die Priority von einem Bitcoin-Tag konnte er ohne Gebühr verwendet werden. Alternativ zahlte man eine relativ selten wechselnde feste Gebühr. War der Eingang weniger als einen Bitcoin wert musste man einfach länger warten. 0,1 Bitcoin benötigten zehn Tage, 0,5 Bitcoin zwei Tage und 2 Bitcoin nur einen halben Tag. In jedem Block war ein kleiner Bereich für diese Transaktionen reserviert.

Pingel-Bereich: Die Formel für die Priority die einem Bitcoin-Tag entspricht geht von einer TX Größe von 250 Byte aus. Mit komprimiertem pubkey war man also leicht im Vorteil.

---

Varianz - warum es manchmal einfach dauert.
zurück zum Inhaltsverzeichnis.

Ein neuer Block wird im Schnitt alle 10 Minuten gefunden. Es kann aber auch mal länger dauern. Es ist also möglich das die Gebühr einer Transaktion völlig in Ordnung ist, aber gerade einfach niemand einen Block findet. Egal wie hoch die Gebühr ist, daran lässt sich nichts ändern. Zum Beispiel wurde Block 451716 am 5. Februar um 20:07:56 gefunden und Block 451717 am selben Tag um 21:11:04, also über eine Stunden später.

Pingel-Bereich: Die Zeiten zu denen ein Block gefunden wurde können in einem gewissen Rahmen abweichen und werden von Minern teilweise bewusst manipuliert um unterschiedliche Hashes testen zu können.

---

Mempool - was ist das und wie funktioniert es?
zurück zum Inhaltsverzeichnis.

Nachdem eine Transaktion erstellt und signiert wurde muss sie irgendwie zu einem Miner um bestätigt zu werden. Das Funktioniert über die Mempools. Deine Wallet ist als sogenannte Full Node entweder Teil des Netzwerks oder irgendwie indirekt mit einem solchen verbunden. Ein Full Node prüft ob deine Transaktion die Regeln des Netzwerks einhällt. Ist die Unterschrift korrekt? Sind die Coins noch verfügbar oder schon ausgegeben? Wenn alles mit rechten Dingen zugeht, wird die Transaktion im Arbeitsspeicher des Computers (engl. memory) gespeichert und an alle verbundenen (Full) Nodes bzw. Knoten weitergeleitet. So erfährt man auch das einem jemand Bitcoins schickt, obwohl die Transaktion noch nicht bestätigt ist. Bis eine Transaktion an alle Knoten weitergeleitet wurde vergehen in der Regel nur ein paar Sekunden.

Dieser Speicher in dem die unbestätigten Transaktionen sind heißt mempool. Er ist individuell für jeden Knoten und kann daher auch unterscheidlich aussehen. Mein Server der fast immer läuft hat oft 50 000 oder mehr Transaktionen im mempool. Meine Wallet zu Hause die nur ab und zu mal läuft, hat selten über 5 000. Aktuelle Versionen (12.0+) von Bitcoin Core und Bitcoin Unlimited haben diverse Regeln nach denen Transaktionen aus dem mempool entfernt werden. Die entsprechenden Änderungen im Quellcode gibt es hier. Im Detail ist für uns hauptsächlich wichtig, dass eine Transaktion nach 72 Stunden aus dem mempool entfernt wird. Das darf natürlich jeder Knoten ändern, das können wir aber nicht berücksichtigen.

---

---

Vorbeugende Maßnahmen:
zurück zum Inhaltsverzeichnis.

Die meisten Probleme mit feststeckenden Transaktion lassen sich vorher absehen oder ganz vermeiden. Wie das geht, soll hier geklärt werden.

---

Die 'richtige' Gebühr.
zurück zum Inhaltsverzeichnis.

Unbestätigte Transaktionen befinden sich in einer Art Warteschlange. Sie ist sortiert nach Gebühren pro Byte. Man muss also nicht hinten anstehen wie beim Amt und auf den Aufruf seiner Nummer warten. Man kann sich einfach einen Platz im nächsten Block erkaufen. Die Warteschlange ist aber für Menschen schwer einsehbar. Mit der richtigen Wallet ist das aber kein Problem.

Pingel-Bereich: Die Warteschlange ist nicht identisch auf allen Systemen, jeder Node hat seine eigene. Siehe Mempool.

Programme mit dynamischen Gebühren.
zurück zum Inhaltsverzeichnis.

Weil man sich eigentlich mit dem ganzen kram eh nicht beschäftigen will, gibt es Wallets die das für einen erledigen und einem eine Abschätzung einer guten Gebühr geben.

• Bitcoin Core
• Electrum
• Mycelium

Bitcoin Core
zurück zur Programmübersicht.

Im "Überweisen" Bereich findet sich im unteren Bereich ein "Auswählen" Button. Klickt man darauf erscheint ein neuer Bereich. Dort kann man die Gebühren anpassen. Es ist zu beachten, dass die Empfehlung etwas Zeit braucht und das nur weil dort "with 25 Blocks" steht, man nicht davon ausgehen kann nach 25 Blöcken auch sicher eine Bestätigung zu haben. Ich persönlich habe gute Erfahrungen im Bereich 5-10 Blöcken gemacht, wenn es nicht eilt und nehme 2 Blöcke wenn es mal schnell gehen soll. 1 Block ist fast immer überteuert, liefert aber in der Regel auch was es verspricht.


Link zum Bild: https://i.imgur.com/2DYNI6W.png

---

Electrum
zurück zur Programmübersicht.

Unter Werkzeuge -> Einstellungen -> Fees findet sich Use dynamic fee.


Link zum Bild: https://i.imgur.com/FfyeyRh.png

Hat man den entsprechenden Haken gesetzt erscheint im Sendebereich ein Schieberegler mit dem sich die Gebühr anpassen lässt. Man wählt zwischen 25, 10, 5, 2 und dem nächsten Block. Das ist aber nur eine Schätzung des Electrum Servers mit dem man gerade verbunden ist. Es kann immer auch länger dauern oder schneller gehen. Eine Einstellung im mittleren Bereich (5 bzw. 10 Blöcke) sollte für die meisten Fälle ausreichen.


Link zum Bild: https://i.imgur.com/wxxFBvX.png

---

Mycelium
zurück zur Programmübersicht.

Mycelium als App für Android bietet beim Erstellen einer Transaktion die Option zwischen vier Stufen zu wählen. Niedrigste Priorität, Economy, Normal und Priority. Die Gebühr ist dabei nicht fest pro Stufe hinterlegt, sondern wird dynamisch angepasst. Ich persönlich habe mit Normal gute Erfahrungen gemacht und musste in der Regel nur wenige (<5) Blöcke auf eine Bestätigung warten.

---

Cointape
zurück zum Inhaltsverzeichnis.

Das aber tun wenn man nunmal keine der obigen Wallets nutzt? Dann gibt es Seiten wie Cointape. Inzwischen ist die korrekte URL https://bitcoinfees.21.co/, aber die alte URL cointape.com funktioniert immer noch und leitet entsprechend um. Die Seite zeigt einem wieviele Transaktionen derzeit auf eine Bestätigung warten und wieviel Gebühr in Satoshi pro Byte diese jeweils Zahlen. Weiterhin gibt es eine ziemlich gute Abschätzung wieviel Gebühr man zahlen sollte, wenn man seine Transaktion im nächsten Block sehen möchte. Die meisten Wallets geben die Gebühr in Bitcoin pro Kilobyte an. Man muss also ein bisschen umrechnen.


Zeigt cointape also z.B. 180 Sat/Byte, dann trägt man 0,0018 Bitcoin/KByte als Gebühr in seine Wallet ein.

Sehr ähnlich wie Cointape funktioniert dieser Service von BTC.com. Die Empfehlung basiert aber auf Daten des Pools, es bietet sich bei großen Unterschieden also an die Transaktion auch direkt an BTC.com senden. Dafür bietet der Pool hier ein Tool an.

Für Fortgeschrittene Nutzer kann https://anduck.net/bitcoin/fees/ ebenfalls aufschlussreich sein. Die Seite zeigt für die letzten 144 Blöcke (1 Tag), wie hoch die Gebühren der bestätigten Transaktionen waren. Das erlaubt eine etwas bessere Abschätzung insbesondere für niedrige Gebühren.


https://statoshi.info/dashboard/db/fee-estimates zeigt ebenfalls eine Historie der Einschätzungen einer modifierten Variante von Bitcoin Core, sowie eine Historie der durchschnittlichen Gebühr pro Byte.

---

Die 'richtige' Zeit.
zurück zum Inhaltsverzeichnis.

Bitcoin verhält sich wie vieles andere in unserem Leben auch. Morgens wenn der Großteil zur Arbeit will ist die Straße voll, Nachts um 4 hat man meistens freie Bahn. Man sollte nun meinen bei einer globalen Währung wie Bitcoin, ist immer irgendwo Morgens und es werden Transaktionen getätigt und das ist auch so. Trotzdem gibt es Zeiten zu denen weniger los ist und man mit einer geringeren Gebühr eine Bestätigung erhalten kann. Das folgende Bild zeigt unbesätitgte Transaktionen aus Sicht meines Servers vom 22.01.2017 bis 20.02.2017. Es zeigt sich deutlich mehr Volumen am 24. bis 26.01. (Di - Do), 03. bis 04.02. (Fr, Sa), 07. bis 09.02. (Di - Do) und 17. bis 18.02. (Fr, Sa). Warum genau an diesen Tagen mehr los ist weiß ich nicht und ich kann auch nicht sagen ob sich die Tage verändern. Was ich definitiv sagen kann ist, dass deutlich mehr Transaktionen unterwegs sind wenn der Preis stark schwankt. Man kann sicher aber die Graphen bei mir oder Statoshi ansehen und versuchen das in seine Planung einzubauen.


link zum Bild: https://i.imgur.com/nlCp8KZ.png

---

Replace By Fee - RBF
zurück zum Inhaltsverzeichnis.

Replace by Fee (engl. Ersetzen durch Gebühr) kurz RBC ist eine Technik um die Gebühr nachträglich zuhöhen. Damit das funktioniert muss man aber schon beim erstellen der Transaktion handeln. Daher taucht dieser Abschnitt auch unter den vorbeugenden Maßnahmen auf. Der einzige mit bekannte Client der RBF erlaubt ist Electrum. Nachdem man unter Werkzeuge -> Einstellungen -> Fees bei Enable Replace-By-Fee ein Haken gesetzt hat, kann man im Senden Bereich ein Haken Replaceable setzen. Dieser schaltet RBF für die aktuelle Transaktion ein.


Link zum Bild: https://i.imgur.com/xSOYpTc.png

Wenn so eine Transaktion erstellt wurde, wird sie als Replaceable in der Übersicht angezeigt.


Link zum Bild: https://i.imgur.com/svb361M.png

Als Empfänger wird man von einigen Wallets (hier Mycelium) und Blockchain Explorern (hier Blocktrail) entsprechend informiert.


Link zum Bild: https://i.imgur.com/5JvwzSm.png


Link zum Bild: https://i.imgur.com/h32vffb.png

Um Die Gebühr zu erhöhren klickt man mit der rechten Maustaste auf die Transaktion und wählt Increase Fee. In dem neuen sich öffnenden Fenster stellt man die neue Gebühr entsprechend ein und bestätigt mit einem Klick auf OK.


Link zum Bild: https://i.imgur.com/XVzFjjF.png

Wie sonst auch Passwort eingeben um die neue Transaktion zu signieren und zu übertragen.


Link zum Bild: https://i.imgur.com/uAggYOr.png


Link zum Bild: https://i.imgur.com/YwTe5po.png

Sollte man versuchen die vorherige Transaktion erneut ins Netzwerk zu schicken, zum Beispiel mit Bitcoin Core, erhält man eine Fehlermeldung. Lediglich die Transaktion mit der höhsten Gebühr wird als gültig anerkannt.


Link zum Bild: https://i.imgur.com/msCRSoP.png

Blockchain Explorer zeigen ebenfalls eine Double-Spend Warnung.


Link zum Bild: https://i.imgur.com/8OQHRC8.png

Vorsichtig aber als Empfänger kann einem die Transaktion doppelt angezeigt werden und auch der Gesamtbetrag der Wallet kann falsch sein (kein Bild).


Link zum Bild: https://i.imgur.com/29aSgVf.png

In diesem Test hat Mycelium mir auf der Hauptseite die Summe beider Transaktionen als verfügbare Bitcoin angezeigt. Man muss also die alte Transaktion markieren und löschen ehe einem der korrekte Stand der Wallet angezeigt wird.


Link zum Bild: https://i.imgur.com/mP9TL3b.png


Link zum Bild: https://i.imgur.com/68oWJCH.png

---

---

Rettungsmaßnahmen - Was tun wenns klemmt?
zurück zum Inhaltsverzeichnis.

Was tun wenn das sprichwörtliche Kind schon im Brunnen ist? Was aber tun, wenn die Gebühr zu niedrig war, die Transaktion zu groß oder gar beides? Die Antwort hängt von diversen Faktoren ab und keine der hier Vorgeschlagenen Lösungen ist perfekt.

---

---

---

Lass dir Zeit - rebroadcasting
zurück zum Inhaltsverzeichnis.

Rebroadcasting, also die Transaktion nochmal ins Netzwerk schicken ändert die Transaktion nicht. Die Gebühr wird nicht höher und die Größe nicht kleiner. Alles was passiert ist, dass wir alle Teilnehmer im Netzwerk daran erinnern das da noch eine Transaktion zu bestätigen ist. Das kann entsprechend auch jemand für dich übernehmen. Ich z.B. mach das öfter über meinen Server. Alles was man dafür braucht ist die Transaktion in ihrer rohen Form. Mehr dazu gleich. Warum sollte das helfen? Wie wir wissen (mempool) hat jeder Teil des Bitcoin Netzwerks seine eigene Ansicht darüber was gerade los ist und die Ansicht ändert sich ständig. Es ist also gut möglich das Teile des Netzwerks und darunter auch die wirklich kritischen, die Miner, unsere Transaktion schon vergessen haben. Also verhalten wir uns einfach wie kleine Kinder mit viel Zucker im Blut und einer kurzen Aufmerksamkeitsspanne. Wir erinner jeden alle paar Minuten daran das wir auch noch eine Bestätigung wollen. Das ist je nach Gebühr mehr oder weniger hilfreich. Ist die Gebühr nur minimal zu gering dann kann es mit einem einzigen neu senden schon getan sein, manchmal muss man aber auch eine Woche nölen bis sich was tut.

Alles klar? Dann zum praktischen Teil. Wie genau machen wir das.

Die rohe Transaktion bekommt man in der Regel bei blockchain.info. Man sucht nach seiner Transaktion, nehmen wir mal an es ist diese hier und fügt ?format=hex hinten an die URL an. Damit landet man auf einer anderen Seite die einem die Transaktion in Rohform anzeigt. Diesen Hexcode kopieren wir. Alternativ bekommt man den Hexcode je nach Wallet auch direkt. Wenn man keinen eigenen Full Node hat, geht man einfach zu jemand anderem und bittet darum das dieser für einen nörgelt. Eine Liste auf Seiten die dies anbieten gibt es hier. Alternativ, schick mir eine PM und ich kümmer mich darum sobald ich kann. Ich komme derzeit leider zeitlich nicht dazu diesen Service weiter anzubieten, ich ändere den Post sollte sich das ändern.

Besser ist es natürlich wenn man selbst nörgeln kann. Es hat aber sicher keiner Lust, alle 10 Minuten Nachts aufzustehen um son Code über eine Homepage neu zu verbreiten. Dazu kommt das die meisten Seiten das nur einmal erlauben. Für sowas gibt es Scripte.

Ruby, benötigt Bitcoin JSON RPC API, kann beliebig viele TX senden, timing über cronjob (

Windows, Batch, ggf. Pfad anpassen, aus dem Terminal (Win + R, cmd, OK) starten und mit ctrl + c beenden.

---

Child Pays For Parent
zurück zum Inhaltsverzeichnis.

Child pays for Parent (kurz CPFP, engl. Kind zahlt für Eltern) ist eine Verbesserung der Miner-Software. Die nicht nur alle derzeit unbestätigten Transaktionen analysiert sondern auch welche davon Ketten bilden. Die Bitcoin die in einer unbestätigten Transaktion übertragen werden können sofort wieder ausgegeben werden. Diese Folgetransation kann aber nur bestätigte werden wenn die vorherige auch bestätigt wird. Genau darauf basiert CPFP. Die Elterntransaktion zahlt eine Gebühr die zu niedrig ist, also zahlt eins der Kinder extra und beide werden zusammen bestätigt. In der Praxis bedeutet das, dass man entweder genau das Wechselgeld ausgibt. Das geht am einfachsten wenn man eine Wallet hat, die einem erlaubt Eingänge zu wählen. Selbst wenn das nicht der Fall ist, kann man einfach alle seine Bitcoin an eine eigene Adresse senden. Je nach Menge der Eingänge die von der Wallet verwaltet wird kann das aber sehr teuer werden.

---

Mein Freund der Miner
zurück zum Inhaltsverzeichnis.

Man stelle sich vor man ist Betreiber eines mittleren Mining Pools und stellt so ca. 10% der Bitcoin Hashleistung zur Verfügung. Dann findet man im Schnitt ca. alle 2 Stunden einen Block. Bei diesem entscheiden man selber welche Transaktionen damit bestätigt werden und welche nicht. Selbstverständlich nicht per Hand, sondern durch entsprechende Software. Nun ist es üblich das diese Software einem die Möglichkeit gibt eine Transaktion unabhängig von Gebühren, Priorität oder sonstigen Regeln (z.B. Sig-OPs Limits) zu bevorzugen. Natürlich muss der Block der dabei ensteht sich an die Regeln des Netzwerks halten, sonst wird er nicht akzeptiert. Trotzdem kann man sich die Gebühren sparen. Nun können nicht beliebig viele Menschen über soviel Hashleistung verfügen und ist die Leistung zu gering muss man zu lange warten. Es gibt aber diverse Pools die einem vielleicht trotzdem helfen.

Zum einen gibt es hier im Forum den User macbook-air. Diese soll, wenn man (auf Englisch) nett fragt, Transaktionen für andere mit Priorität behandeln. Es gibt dafür auch ein Web-Interface. Der nötige Referral Code ist aber nur wenigen bekannt.

Zum anderen gibt es den (Cloud Mining) Pool ViaBTC. Dieses bietet einen Transaction Accelerator (engl. Transaktions Beschleuniger) an. Dieser nimmt bis zu 100 Transaktionen die Stunde an welche eine Gebühr von mindestens 0.0001BTC/KB zahlen. Diese Transaktionen werden mit Priorität behandeln. Ich persönlich halte das Tool für ein Marketing oder gar Propaganda Werkzeug für Bitcoin Unlimited. Das soll aber niemanden davon abhalten es zu nutzen. Was Christoph Bergmann vom Bitcoinblog zu dem Pool geschrieben hat findet sich hier.

---

---

todo:

changelog:

Fußnoten:

[1] Ein Kilobyte sind genau 1000 Byte und nicht 1024. 1024 Byte sind ein KiBiByte. Ein Kilogramm sind aber ja auch nicht 1024 Gramm.