Bitcoin Forum
July 12, 2025, 05:36:01 PM *
News: Latest Bitcoin Core release: 29.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 »
1  Other / Meta / should be in service discussion not a scam accusation on: July 23, 2017, 02:37:45 PM
I think threads about (potential) scammy services that have no bitcointalk.org account associated with them should not be in scam accusation, but in service discussion (or whichever other board fits better, e.g. digital goods). I think the main reason for the scam accusation board was to get help from DT members in case of a dispute. While this was mainly a user to user thing, bitcoin has moved on and a large number of disputes are between users and services. However if the service has no account here, there is no help from DT possible. Thus a warning in a section that is read more frequently when trying to inform oneself about a service in particular or in general would be more useful. This section is unlikely to be scam accusation and most likely service discussion (or digital goods or whichever other board fits best).

I dont know of a writen definition what should or should not go into scam accusation. If there is consensus about this among the mods, feel free to correct me and lock this thread.
2  Local / Anfänger und Hilfe / Transaktion hängt fest? Was tun wenns klemmt. on: February 14, 2017, 10:56:18 PM
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:





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:
Code:
148 Byte * Anzahl Eingänge + 34 Byte * Anzahl Ausgänge + 10 Byte Overhead

unkomprimierter pubkey (inzwischen unüblich, außer für z.B. Vanity Adressen):
Code:
180 Byte * Anzahl Eingänge + 34 Byte * Anzahl Ausgänge + 10 Byte Overhead


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:

Code:
Ernie: 148 byte * 51 Eingänge + 34 byte * 2 Ausgänge + 10 Byte Overhead = 7 626 byte
Bert : 148 byte *  4 Eingänge + 34 byte * 2 Ausgänge + 10 Byte Overhead =   670 byte

Das entspricht einer Gebühr von:

Code:
Ernie: 7 626 byte * 100 satoshi/byte = 762 600 satoshi = 0,007626 BTC
Bert :   670 byte * 100 satoshi/byte =  67 000 satoshi = 0,000670 BTC

bzw. einem Anteil an den übertragenen Bitcoin von:

Code:
Ernie: 0,007626 BTC / 5 BTC = 0,15%
Bert : 0,000670 BTC / 5 BTC = 0,01%



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
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.

Code:
10^8 Satoshi = 1 Bitcoin
1000 Byte = 1Kilobyte[1]
(Satoshi/Byte) /100 000 = Bitcoin / Kilobyte

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.


Übersichtstabelle

|Maßnahme|Wirksamkeit|Beschleunigung|Schwierigkeit|
|Rebroadcasting|mittel-hoch|keine|mittel|
|Child Pays For Parent|hoch-sehr hoch|mittel-sehr hoch|sehr leicht|
|Mein Freund der Miner|hoch-sehr hoch|mittel-sehr hoch|leicht, benötigt ggf. Kontakte|
|Double-Spend|hoch-sehr hoch|hoch-sehr hoch|schwer|



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 (
Code:
user = "your_username_from_the_bitcoin.conf_file"
pass = "your_secret_password_from_the_bitcoin.conf_file"
ip_addr = "127.0.0.1"
port = "8332"

require './bitcoin_rpc.rb'

btc = BitcoinRPC.new("http://#{user}:#{pass}@#{ip_addr}:#{port}")
txs = Array.new
txs << "raw tx here"
txs.each do | raw_tx |
  #p raw_tx
  begin
    answer = btc.sendrawtransaction(raw_tx)
    p answer
  rescue
    puts "[ERROR] unable to broadcast TX."
  end
end
# also see: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list


Windows, Batch, ggf. Pfad anpassen, aus dem Terminal (Win + R, cmd, OK) starten und mit ctrl + c beenden.
Code:
@echo off
:start
echo ---
"c:\Program Files\Bitcoin\daemon\bitcoin-cli.exe" sendrawtransaction 0100000001c85112c62632...
echo ---
echo Time: %time% waiting 30 minutes
timeout /t 1800 /nobreak > NUL
goto start



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:
Code:
inputs konsolidieren (idee: fronti)
dynamic fee
dynamic fee - multibit (classic/hd)
dynamic fee - blockchain.info?
dynamic fee - blocktrail?
Ausblick? (2/4/8MB, SegWit, LN, etc. pp)

changelog:
Code:
2017.02.14 - Erste Fassung, Inhaltsverzeichnis 
2017.02.15 - Dynamic Fee, Bitcoin Core, Electrum
2017.02.17 - Mempool, Rebroadcasting, Dyn Fee Electrum
2017.02.25 - Mein Freund der Miner, RBF
2017.02.26 - Cointape -> btc.com (inkl. pushtx)
2017.03.02 - CPFP
2017.03.19 - Double-Spend v1
2017.10.29 - kein nörgeln als Service zur Zeit, sorry

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.
3  Economy / Games and rounds / keybase.io invite raffle on: December 21, 2016, 01:30:11 PM
Rank: Full or above only.

Guess the correct number between 1 and 100 to win a keybase.io invite.

sha256[1] so I cant cheat
Code:
071d51b265ca824076d594d4fc277c1f19d33e0ace088180b003d9f45765cfc2

[1] http://www.xorbin.com/tools/sha256-hash-calculator
4  Economy / Reputation / P4man [ID: 41363] and Puppet [ID: 65207] on: November 11, 2016, 09:59:26 PM
Posting a short summary here, to avoid cluttering up the stake your address thread and to have a single reference for myself.



Links:

-> https://bitcointalk.org/index.php?action=profile;u=41363
-> https://bitcointalk.org/index.php?action=profile;u=65207

There is staked address for Puppet, which P4man claims to be posted by someone else.

-----BEGIN BITCOIN SIGNED MESSAGE-----
Hello I am Puppet. Today is Oct 27.2016. This is my address
-----BEGIN SIGNATURE-----
1GWaevrghssi7MvQVcxbRP5MZsAvRazZUW
Hz6T+Q6+Q51cNqmcOhSp8fGWQqV48FogPqNM7r/UrjN5KGrCkae2wLTg1Shky6h/PP5Ub+wqupvQgVTLmKBkXRo=
-----END BITCOIN SIGNED MESSAGE-----

This account, which used to be my alter ego, has been hacked. BEWARE



They regained control:

*** my account was stolen ***

regained control of my throw away email and this account. Looks like no damage was done.



Timelord2067 has proof for the connection that comes with old enough addresses.

OK, two weeks ago I made the connection between P4man and Puppet, but my investigations were on going, so I didn't post anything...

I cant obviously. I didnt post that message, whoever hacked my account did. I removed the message you quoted.

Quote
Puppet u=65207

Name:    Puppet
Posts:    4265
Activity:    952
Position:    Legendary
Date Registered:    26 August 2012, 17:51:56

Two weeks ago: https://www.bctalkaccountpricer.info/?token=oc2rhrkc archived here: http://archive.is/ov71g

Today: https://www.bctalkaccountpricer.info/?token=23lav62t http://archive.is/7iBdj

Code:
Summary - P4man 	u=41363 http://archive.is/1vI1M
Name: P4man
Posts: 3015
Activity: 490
Position: Hero Member
Date Registered: 08 September 2011, 02:12:43
Last Active: 24 April 2015, 07:46:50

Two weeks ago: https://www.bctalkaccountpricer.info/?token=out80e2g http://archive.is/xOsUb

Today: https://www.bctalkaccountpricer.info/?token=34vqod43 http://archive.is/M9xsG



http://archive.is/mYpom#selection-2926.1-2977.34 (archived two weeks ago)

here you go:
http://seekcartoon.com/watch/8265-power-rangers-zeo-13-mean-screen.html#.UUHeuklu0gQ

(from 2"20 onwards)

15ZPNczbVbmuP5XjnaBGNVVLSAaWRaPF62


http://archive.is/Mi0Jm#selection-4602.1-4645.78 (archived two weeks ago)

Im not going to post it a millionth time. The google cache page shows it pretty well.
Ive also given him my btc address a million times, but here it is again:
15ZPNczbVbmuP5XjnaBGNVVLSAaWRaPF62

Paying out 20BTC when you got 50BTC and owe 100BTC isnt going to do it though.



http://archive.is/M9xsG#selection-977.0-977.82
http://archive.is/7iBdj#selection-1301.0-1301.79



Donations welcome via the BTC in my signature.



On of the addresses below can be used to remove the rating

I cant obviously. I didnt post that message, whoever hacked my account did. I removed the message you quoted.

One of these might be useful

You can repay on this address:
1NgrU4LpqTs3h6kJA5DaLaDJxbUNrQhqAj
here you go:
http://seekcartoon.com/watch/8265-power-rangers-zeo-13-mean-screen.html#.UUHeuklu0gQ

(from 2"20 onwards)

15ZPNczbVbmuP5XjnaBGNVVLSAaWRaPF62
You can tip me on this address: 15YNTMoAzTCve64rveEka75qCeJMZpmDCx
You can send my 1BTC here: 1KM5LnpqdJD9jUGkLvA6d7qQN6gpjZCUJS


I could probably do that, if I really wanted to (my wallet.dat is in seriously cold storage), but I dont see the point. What do you want me to prove, that Im the real P4man/puppet? What for? If you think I could be the hacker, having hacked both accounts, thats fine, at least you wont rely on the age and reputation of either account to trust it for escrow or whatever his intention was. Its the only reason I posted the warning when I figured out I could no longer log in to my puppet account. For the rest, Ive long lost interest in this forum.
5  Economy / Scam Accusations / glovermee fake escrow scam attempt on: April 27, 2016, 08:23:17 PM
What happened: The user glovermee tried to use a fake escrow message to trick Flooores. Flooores however is a smart person and did not fall for it, they tried to verify with me and I was able to answer before they send any coins.

Scammers Profile Link: https://bitcointalk.org/index.php?action=profile;u=663723

Amount Scammed: 0
Payment Method: netteller for btc
PM/Chat Logs:

!!! WARNING: This user is a newbie. If you are expecting a message from a more veteran member, then this is an imposter !!!


Shorena are you really  don't this escrow here  for me  ?
Sorry for this question






"Flooores" You don't have to worry.Just Follow the guideline.



Hi,

I was asked to Escrow your deal, I assume the below is what you want.

-Sho

Code:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Escrow by shorena from bitcointalk.org (UID: 181801)
for Flooores  as SELLER
and glovermee as BUYER

Item: 0,48475124 BTC  for neteller payment 240$


Steps:
#0 stay calm, things done properly need time.

#1 Flooores sends escrow the above BTC to 18qw5BLBXv3TS3oKjdhBt2nJvBEZmi99mG

#2 Escrow confirms Flooores to have received the correct amount after 1 confirmation

#3 glovermee issues a  USD transfer via netteler to Flooores

#4 Flooores confirms to have received the correct amount

#5 Escrow releases the BTC to glovermee

#6 all are happy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWjUAiAAoJEJQKF9u9a2jizH8QAJLWODpfPrC3wezzm2kNnblv
HhLSZrF4qYHVKKiD46jdBXcXV8Txc7ekw2seOl9pf/A+OwhcZNJIs8tpCIX8d+PF
F4hv1tN2VEzLTrldY8ZCf4x7d85rvJ+DEIyBWeC2EkYR8IsXboqkVTFxdLv08HdO
oBLg1hkMKYU6LcVIedNpD2efZIVM5cmBGvtjr5MZ1SVmoUwxehOyWgaPOcE7LtdP
WNU3mcbChF668AmIZ45xf4njTOcbUyYK8re2l+G8mBM8IV78BlIZbJrwkKYNpPmc
JNAy74bquwJEfL43j80rcfcQ6ERooahntxTmkVLhbSiutASFOrI1p+bCs+jZ4ut1
tm1bwmUKzYRruLFZ3fyFvVxGsBIHWVjtcAmL+WanPul+0rP0tVfBob+0eQtPCeQC
BnGrUqqOyCvfITAcrBF2M0iD174oXsmh1SGQpVw4XYWDn4tC+Tc/1zX1EnLkOVdD
S70MBmtD+BBsZfpYWyw3Ab+uIqdTOSUTp7c7jxzXYo6boml+F9inHo0N8luQN/kH
I8wRSUJhbywlQWvlP5HLqOY6R44euqUu23RaAoJINAk7dK96oE48Rdb+IEL7WfBn
i8ULUVkrkK9Nd4zG1TsuuZHk46hqRHVvPm1YQwt8ZfwA0RP9n5i0ccp9S3/ThLMx
k4cJISkvR9txlI3YV4Xr
=/7Ef
-----END PGP SIGNATURE-----


Additional Notes: I asked Flooores to report the PM to staff so they can be verified. The main reason for this thread is that more people are aware that this is happening. I will always sign escrow agreements. You can verify them here -> https://keybase.io/verify Everything that you can not verify should be considered false.
6  Economy / Auctions / Rent my signature space for one month. on: April 10, 2016, 07:09:56 PM
For auction my signature space for one month (April 12th 2359 CEST till May 12th 2359 CEST (see #1.2))

Starting bid: .1 BTC
Buy it now: 0.75 BTC (only valid until the current bid reaches 0.6 BTC)
End date and time: April 11rd 2016, 2359 CEST[2] (see anti-sniping rule)
Payment methods accepted: BTC only
Minimum Bidding Increment: .01 BTC
Anti-sniping rule: Any bids made within 30 minutes of the end of the auction time will extend the end time by an additional 30 minutes. The winner will be declared April 12th here in this thread.
Additional information:

#1 I will guarantee a minimum of 250 posts.
#1.1 I have made at least 3845 post since Sept 1st; thats an average of 549 posts per month. If you want more details, see here[1]. I have no reason to believe this will change in the near future, but life is full of surprises.
#1.2 The 250 guarantee is not tied to the month and may take me longer.
#2 I reserve the right to reject advertisements for companies/entities that are associated with a scam and/or large amounts of spam.
#2.1 this means I will not advertise for so-called "ponzi games".
#3 Bids of Jr. members or lower are not accepted by default. They must pay in 75% of their bid in order to get it accepted. The pay in will be refunded after the auction ends.
#4 Payment is up front or handled via escrow.
#4.1 My payment address will be 1P6A2X1w3Wxi618fLjVVfgoofTs6ya6CPb. I will not contact you from a different account with a different address.
#4.2 If an escrow agent is involved the buyer (you) pays the fee. If the escrow charges no fee, I expect you to pay a tip of at least 1% for the escrows service.
#5 My avatar and/or personal text are not for sale.
#6 No conditional bids, ask your questions before you bid.
#7 You are free to resell the signature space as long as it meets all above criteria.
#7.1 It can take me up to 24 hours to update the signature.

[1] http://www.bctalkaccountpricer.info/?token=ufc98a6
[2] http://www.timeanddate.com/time/zones/cest
7  Other / Archival / [ABORTED] Buy my signature for a month auction ends 3rd of April 2359 CEST on: March 30, 2016, 11:58:49 AM
For auction my signature space for one month (April 4th 2359 CEST till May 4th 2359 CEST (see #1.2))

Starting bid: .1 BTC
Buy it now: 0.75 BTC (only valid until the current bid reaches 0.6 BTC)
End date and time: April 3rd 2016, 2359 CEST[2]
Payment methods accepted: BTC only
Minimum Bidding Increment: .01 BTC
Anti-sniping rule: Any bids made within 30 minutes of the end of the auction time will extend the end time by an additional 30 minutes. The winner will be declared April 4th here in this thread.
Additional information:

#1 I will guarantee a minimum of 250 posts.
#1.1 I have made at least 3845 post since Sept 1st; thats an average of 549 posts per month. If you want more details, see here[1]. I have no reason to believe this will change in the near future, but life is full of surprises.
#1.2 The 250 guarantee is not tied to the month and may take me longer.
#2 I reserve the right to reject advertisements for companies/entities that are associated with a scam and/or large amounts of spam.
#2.1 this exclused so-called "ponzi games" which I will not advertise for.
#3 Bids of Jr. members or lower are not accepted by default. They must pay in 75% of their bid in order to get it accepted.
#4 Payment is up front or handled via escrow.
#4.1 My payment address will be 19HUmRVgKsREynkba31EqQsav6ic3Z9TXL. I will not contact you from a different account with a different address.
#4.2 If an escrow agent is involved the buyer (you) pays the fee. If the escrow charges no fee, I expect you to pay a tip of at least 1% for the escrows service.
#5 My avatar and/or personal text are not for sale.
#6 No conditional bids, ask your questions before you bid.

[1] http://www.bctalkaccountpricer.info/?token=ufc98a6
[2] http://www.timeanddate.com/time/zones/cest
8  Bitcoin / Development & Technical Discussion / Dain 0.0.1: version 70002 on: March 04, 2016, 05:51:19 PM
I have a peer with the subver Dain 0.0.1: version 70002. It does not behave maliciously or anything like that Im just curious. I couldnt find anything via the common search engines. Does anyone know anything about this node version?

Code:
2016-01-21 22:52:01 receive version message: Dain 0.0.1: version 70002, blocks=394355, us=-:8333, peer=14
2016-01-23 08:41:07 receive version message: Dain 0.0.1: version 70002, blocks=394589, us=-:8333, peer=6
2016-01-24 08:40:54 receive version message: Dain 0.0.1: version 70002, blocks=394763, us=-:8333, peer=5
2016-02-28 18:41:06 receive version message: Dain 0.0.1: version 70002, blocks=1, us=-:8333, peer=562
2016-03-01 23:34:28 receive version message: Dain 0.0.1: version 70002, blocks=400737, us=-:8333, peer=216
9  Local / Anfänger und Hilfe / Core sync oder bootstrap.dat was ist schneller? on: February 08, 2016, 08:37:00 PM
Das Thema kommt öfter mal auf und es scheiden sich die Geister dran was nun schneller ist, einfach core starten und gut oder eine aktuelle bootstrap.dat z.B. vom Bundesverband Bitcoin e.V.[1] nutzen.

Weil mir grad danach ist Teste ich das einfach mal.

OS: Win8.1 Pro via de_windows_8_1_x64_dvd_2707227.iso in VMWare 11.0 frisch installiert (bzw. für den 2. Test vom Snapshot nach der fertigen Installation wiederhergestellt.
CPU: 1 virtuelle CPU mit 2 Kernen auf i5 4460 @ 3.2Ghz Host. 2 Kerne damit die VM nicht von meinen Aktivitäten auf dem Host gebremst werden. Intel VT-x/EPT ist aktiviert, sollte aber keine Rolle spielen.
RAM: 6144 MB
HHD: 180 GB virtuelle Disk, geteilte Dateien auf WDC WD10EZEX 1TB, die Platte ist getrennt vom Host (SSD) und wird während des Tests nicht (oder nur marginal) verwendet.
Anbindung: 27Mbit/s downsteam lt. speedtest.net

Test #1 boostrap.dat

2015.02.08 - 21:33 - core installiert, aber nicht gestartet
2015.02.08 - 21:35 - download bootstrap.part01.rar bis bootstrap.part06.rar gestart
2015.02.08 - 23:40 - downloads laufen noch schätzungen für die restzeit sind 1-3 Stunden.
2015.02.08 - 23:42 - download bootstrap.part07.rar und bootstrap.part08.rar via weiterem browser gestartet um die freie Leitung über Nacht bestmöglich zu nutzen.
2015.02.09 - 06:18 - download ist seit ca. 3 Stunden abgeschlossen, Datei entpacken
2015.02.09 - 06:32 - core gestartet
2015.02.09 - 11:29 - crash

Auszug debug.log
Code:
2016-02-09 10:29:17 UpdateTip: new best=00000000000000000e71bd356d4b1e0f743d98157f7f3ba434a761c6d796bfda  height=310797  log2_work=79.721224  tx=42553228  date=2014-07-15 05:17:08 progress=0.278781  cache=61.2MiB(21670tx)
2016-02-09 10:29:17 IO error: C:\Users\fntest\AppData\Roaming\Bitcoin\chainstate\327115.ldb: Der Vorgang konnte nicht erfolgreich abgeschlossen werden, da die Datei einen Virus oder möglicherweise unerwünschte Software enthält.

2016-02-09 10:29:17 *** System error while flushing: Database I/O error
2016-02-09 10:47:41 socket sending timeout: 1201s

2015.02.09 - 17:20 - neustart core.
2015.02.09 - 17:50 - Zwischenstand, Block 313512, 1 Jahr 27 Wochen zurück, bootstrap.dat wird nicht mehr verwendet.
2015.02.09 - 21:11 - Zwischenstand, Block 329606, 1 Jahr 12 Wochen zurück, 4 GB empfangen, 3 MB übertragen, CPU konstant >92%
2015.02.09 - 21:35 - Test unterbrochen.
2015.02.09 - 23:58 - weiter gehts.
2015.02.10 - 09:10 - Zwischenstand, Block 356875, 38 Wochen zurück, 9 GB empfangen, 6 MB übertragen
2015.02.10 - 09:20 - Keine Blockquelle verfügbar.

Code:
2016-02-10 08:17:50 UpdateTip: new best=00000000000000000aed9276e0421d920bcfe0a99f1308fc944ce8240b14f2c8  height=357225  log2_work=82.810626  tx=69238857  date=2015-05-20 06:17:33 progress=0.714748  cache=49.4MiB(6029tx)
2016-02-10 08:17:50 socket send error Eine vorhandene Verbindung wurde vom Remotehost geschlossen.  (10054)

2015.02.10 - 09:25 - synchronisiere mit Netzwerk (selber remote Node) - 37 Wochen zurück
2015.02.10 - 20:59 - Zwischenstand, Block 381244, 14 Wochen zurück, 11 GB empfangen
2015.02.10 - 21:00 - Test unterbrochen.
2015.02.11 - 07:19 - synchronisiere mit Netzwerk (selber remote Node) - 14 Wochen zurück
2015.02.11 - 18:15 - Test beendet bei Block 397433.

Zeiten abzuziehen (Pausen, crash): 18 Std. 33 Minuten

Gesamtzeit: 2015.02.08 - 21:33 bis 2015.02.11 - 18:15: 68 Std. 42 Minuten
Zeit die tatsächlich mit Synchronisierung verbracht wurde: 68 Std. 42 - 18 Std. 33 Min: 50 Std. 9 Minuten.

Anmerkungen:

Durch den crash wurde die bootstrap.dat vom 31.01.2016 nicht vollständig verwendet. Die "Virus"-Meldung von core ist mir neu und Anti-Virus Software ist nicht installiert. Es ist also durchaus noch potential in der Datei. Die Bremse war aber eindeutig die CPU und nicht die Anbindung oder die Festplatte. Insgesamt bin ich aber überrascht das es so schnell ging die bootstrap.dat auf den Rechner zu bekommen. Wenn man mehr als einen Rechner damit versorgen kann ist man damit auf im Vorteil. Ich gehe nicht davon aus das core in weniger als 25 Stunden voll synchronisiert von daher lohnt es sich bereits ab dem 2. Rechner.



Test #2

Core wurde von dem Testsystem vollständig entfernt (deinstalliert und der %APPDATA%\Bitcoin Ordner gelöscht) und danach neu installiert. Ziel ist Block 397433 um ein vergleichbares Ergebnis zu haben. Ggf. werde ich den Test wieder zwischendurch unterbrechen müssen. Die bitcoin.conf die bis auf 2 Zeilen leer. Die sollen dafür sorgen das von Anfang an mindestens 2 gut angebundene Nodes bekannt sind.

Code:
addnode=37.120.160.55:8333
addnode=178.254.35.104:8333

2015.02.11 - 18:38 - start core.
2015.02.11 - 23:36 - Zwischenstand, Block 303895, 1 Jahr 36 Wochen zurück.

Code:
getpeerinfo
[
{
"id" : 1,
-snip-
"bytessent" : 5752755,
"bytesrecv" : 3007540503,
-snip-
},
{
"id" : 2,
-snip-
"bytessent" : 5440134,
"bytesrecv" : 3005536140,
-snip-
},
{
"id" : 7,
-snip-
"bytessent" : 4678467,
"bytesrecv" : 2999271016,
-snip-
},
{
"id" : 9,
-snip-
"bytessent" : 4051536,
"bytesrecv" : 2623573476,
-snip-
},
{
"id" : 13,
-snip-
"bytessent" : 3548242,
"bytesrecv" : 3333276123,
-snip-
},
{
"id" : 16,
-snip-
"bytessent" : 3486671,
"bytesrecv" : 2892292899,
-snip-
},
{
"id" : 18,
-snip-
"bytessent" : 13065,
"bytesrecv" : 41423,
-snip-
},
{
"id" : 20,
-snip-
"bytessent" : 2404384,
"bytesrecv" : 1729042365,
-snip-
}
]

2015.02.12 - 03:41 - crash

Code:
2016-02-12 02:41:22 UpdateTip: new best=000000000000000003ae8b123ef703ba9cae855abeac1454d3257ff1b7b98656  height=326974  log2_work=81.221699  tx=49733158  date=2014-10-25 19:31:15 progress=0.418696  cache=61.1MiB(13696tx)
2016-02-12 02:41:25 IO error: C:\Users\fntest\AppData\Roaming\Bitcoin\chainstate\568485.ldb: Der Vorgang konnte nicht erfolgreich abgeschlossen werden, da die Datei einen Virus oder möglicherweise unerwünschte Software enthält.

2016-02-12 02:41:25 *** System error while flushing: Database I/O error

2015.02.12 - 07:39 - neustart core
2015.02.12 - 07:39 - crash

Code:
2016-02-12 06:39:39 Pre-allocating up to position 0x5000000 in blk00188.dat
2016-02-12 06:39:41 IO error: C:\Users\fntest\AppData\Roaming\Bitcoin\chainstate\568978.ldb: Der Vorgang konnte nicht erfolgreich abgeschlossen werden, da die Datei einen Virus oder möglicherweise unerwünschte Software enthält.

2016-02-12 06:39:41 *** System error while flushing: Database I/O error

2015.02.12 - 07:44 - neustart core
2015.02.12 - 10:13 - Zwischenstand, Block 337007, 1 Jahr 5 Wochen zurück. Traffic ist wieder relativ gleichmässig zwischen allen 8 peers verteilt.
2015.02.12 - 13:20 - Test unterbrochen
2015.02.15 - 09:36 - start core
2015.02.15 - 11:45 - Wieder ein "Virus" gefunden diesmal konnte ich den Fehler verorten, Windows defender findet Virussignaturen in der Blockchain und beendet dann bitcoin core, Hab den bitcoin Ordner jetzt entsprechend ausgeschlossen. Interesanter weise ist das beim ersten Durchlauf deutlich seltener passiert.
2015.02.15 - 11:46 - neustart core
2015.02.15 - 14:16 - Zwischenstand, Block 351562, 44 Wochen zurück, Traffic ist ein Witz insgesamt 13 MB in der letzten 1 Std.
2015.02.15 - 18:20 - Test unterbrochen, Zwischenstand, Block 351562, 44 Wochen zurück, Traffic ist weiterhin ein Witz, liegt aber nicht an der Leitung. Ein Windows update lief problemlos mit 32Mbit/s.
2015.02.16 - 06:29 - start core
2015.02.16 - 09:00 - Test unterbrochen, Block 351562, 44 Wochen zurück.
2015.02.17 - 21:55 - start core
2015.02.20 - 22:47 - Zwischenstand, Block 351562, 44 Wochen zurück.
2015.02.20 - 22:50 - neustart core erzwinge reindex
2015.02.21 - 12:15 - Zwischenstand, Block 351931, 44 Wochen zurück.
2015.02.21 - 22:22 - Zwischenstand, Block 379829, 17 Wochen zurück.
2015.02.21 - 22:36 - Test unterbrochen, Block 380321
2015.02.23 - 16:00 - start core
2015.02.24 - 01:37 - Test beendet

Code:
2016-02-24 00:37:35 UpdateTip: new best=0000000000000000034b35bec7815d3c6af3b60c91708675bf48e3f3d757ed9e  height=397433  log2_work=84.069784  tx=108815998  date=2016-02-08 21:12:25 progress=0.988712  cache=38.4MiB(5824tx)

Gesamtzeit: 2015.02.11 - 18:38 bis 2015.02.24 - 01:37: 294 Std. 59 Minuten
Zeit die tatsächlich mit Synchronisierung verbracht wurde: 38 Std. 32 Minuten.

Anmerkungen:

Aufgrund der viele Fehler finde ich es schwer ein klares "Ja, ohne bootstrap.dat ist schneller" zu äußern. Ich hab entsprechend beschlossen weitere tests durchzuführen.

[1] https://bitcointalk.org/index.php?topic=947891.msg13811249#msg13811249
10  Bitcoin / Electrum / Type Error: Incorrect padding when verifiying sign message on: February 01, 2016, 10:04:26 AM
I tried to verify this

-----BEGIN BITCOIN SIGNED MESSAGE-----
This is harizen from bitcointalk.org. Today is February 1,2016.
-----BEGIN BITCOIN SIGNATURE-----
1BzFQocxr7QABTpwGz6o9Dsb6tPpBqbWZ8
HyEuQEIIi5KS0dqyCaIWh6a5A3wIMFqkSEehuNa7jOUZTSyLa08czuASi5RUcj78hPI5PMNec0w6Xhz flMbFNcM
-----END BITCOIN SIGNATURE-----

signed message with electrum 2.5.4. (extracted tar.gz) on debian linux and get the following message in terminal (nor error or other message in the GUI)

Code:
Traceback (most recent call last):
  File "-snip-/Electrum-2.5.4/gui/qt/main_window.py", line 2079, in <lambda>
    b.clicked.connect(lambda: self.do_verify(address_e, message_e, signature_e))
  File "-snip-/Electrum-2.5.4/gui/qt/main_window.py", line 2042, in do_verify
    sig = base64.b64decode(str(signature.toPlainText()))
  File "/usr/lib/python2.7/base64.py", line 76, in b64decode
    raise TypeError(msg)
TypeError: Incorrect padding

Is this a wallet issue?
11  Other / Off-topic / [FSF][PGP] EMail self-defense infograhic on: January 24, 2016, 08:57:54 AM
The topic comes up here from time to time, people ask for guides how to use GnuPG and the first steps IMHO should always be to use it for mail, because its the easiest and there are good guides. Here is one of these guides, with a nice inforgraphic. Link to guide.



If you like it, consider a donation to them. Yes the free software foundation accepts bitcoin and litecoin.
12  Bitcoin / Wallet software / Testnet wallet for iPhone on: December 30, 2015, 09:38:53 PM
I just wanted to show someone bitcoin via testnet, its more fun to transfer 1 tBTC than it is to transfer 0.01BTC. I was unable to find a testnet wallet in the appstore though. Is there none?
13  Economy / Reputation / tarsua / node.jps / eden1 on: December 29, 2015, 01:37:39 PM
As posted here -> https://bitcointalk.org/index.php?topic=1307221.0 (self mod)

tarsua -> https://bitcointalk.org/index.php?action=profile;u=387574
node.jps -> https://bitcointalk.org/index.php?action=profile;u=627841
eden1 -> https://bitcointalk.org/index.php?action=profile;u=349725

are alts of eachother.

Address used by tarsua 16jLuS7UNrLXChzDfWbcrA1B8MWPvh7vAC
as posted here -> https://bitcointalk.org/index.php?topic=1174480.msg12366541
archive -> https://web.archive.org/web/20151229113948/https://bitcointalk.org/index.php?topic=1174480.msg12366541

Same address used by eden1
here -> https://bitcointalk.org/index.php?topic=847508.0
archive -> https://web.archive.org/web/20151229114153/https://bitcointalk.org/index.php?topic=847508.0

Address used by tarsua 1EdenrvQXPNz1Utp6gavnBQuFK2BKphtTL
as posted here -> https://bitcointalk.org/index.php?topic=1082477.msg12467967
archive -> https://web.archive.org/web/20151229114443/https://bitcointalk.org/index.php?topic=1082477.msg12467967

Address used by node.jps 17kt3rG6kzSgQPYMVEwYxMH26QFCzwZ2rn
as posted here -> https://bitcointalk.org/index.php?topic=1275755.msg13226848
archive -> https://web.archive.org/web/20151229114543/https://bitcointalk.org/index.php?topic=1275755.msg13226848

17kt3r is linked to Edenrv in this transaction -> https://www.blocktrail.com/BTC/tx/19f33c85f13d2560ba80bfd53491b7c262eaebb09ce56674a149445229585083
14  Bitcoin / Bitcoin Discussion / Bitcoin explained on Computerphile on: December 09, 2015, 05:11:06 PM
https://www.youtube.com/watch?v=JyxRH18YlpA

The assessment of how profitable mining is might be wrong though. I cant judge that.
15  Economy / Services / Bitcoin Vanity Addresses! on: November 21, 2015, 03:18:04 PM
Get your own unique bitcoin address!

Just follow the steps below:

Step 0: Ask for the price for your desired prefix. Consider a case insensetive prefix or any one out of a list as this decreases the difficulty.
Address must start with 1, valid symbols can be found here -> https://en.bitcoin.it/wiki/Base58Check_encoding#Base58_symbol_chart
Step 1: Goto https://www.bitaddress.org/ move your mouse/type in the field until it shows 100% and wait a second.
Step 1.5: Optional but highly recommended. Download the page, verify the download and run it locally.
Step 2: Click Vanity Wallet click the generate buttion next to “Generate your "Step1 Key Pair"
Step 3: Reply to this thread with your public key and the prefix for your address. Save the private key somewhere safe. You will need it later when I generated your partial private key.
Step 4: Either pay me directly or the escrow.
Step 4.5: Optional provide me your PGP pub key for encryption.
Step 5: Once you received your partial private key - this can take several days depending on the difficulty - go back to bitaddress.org and click on Vanity Wallet.
Step 6: Go to step 2 Calculate your vanity wallet. In the first field put the private key you saved and in the second field put the partial private key I gave you. Click Add and Calculate Vanity Wallet
Step 7: Copy the Vanity Private Key (WIF) and import it into your preferred wallet.
Step 8: Enjoy.



For small amounts (<0.001) and donations I will ask for payment to this 1vanityybUbbYsiJjAGiNK7vdJkNCqm2e address. If you are asked to pay to this address please provide a TX ID to avoid confusion.
16  Bitcoin / Bitcoin Technical Support / "absurdly high fees" on: November 15, 2015, 01:27:26 PM
I had a problem with bitcoin core in the past that I was finally able to recreate on the testnet.

I tried to fuse several of my inputs into a single large output. I let bitcoin core determine the fee, but the TX was refuse with a message that indicated I tried to double spend. I knew it was not a double spend, so I just made a raw TX and pushed it via several services. The TX was confirmed quickly and I removed the conflicted one with zapwallettxes. I never understood the error message though.

Now on the testnet I finally had the idea to look into the debug.log and found:

Code:
2015-11-15 13:12:20 CommitTransaction:
CTransaction(hash=44645ad833, ver=1, vin.size=15, vout.size=1, nLockTime=605155)
    CTxIn(COutPoint(4901f65bec, 0), scriptSig=304402206c8bd444ef9bfa95, nSequence=4294967294)
    CTxIn(COutPoint(4a6d2d5d44, 0), scriptSig=3045022100e1b901fe7ca785, nSequence=4294967294)
    CTxIn(COutPoint(fabb3b1985, 1), scriptSig=304402203306d2e695d36916, nSequence=4294967294)
    CTxIn(COutPoint(dae574819e, 1), scriptSig=3044022038a769d8d9eb39aa, nSequence=4294967294)
    CTxIn(COutPoint(af93f5d5ef, 1), scriptSig=3044022039aa1cc0b7c246ba, nSequence=4294967294)
    CTxIn(COutPoint(2295152ff2, 5), scriptSig=3045022100d627eb8baa28b9, nSequence=4294967294)
    CTxIn(COutPoint(b29f5ed3ce, 0), scriptSig=3045022100ea8f46c9aef744, nSequence=4294967294)
    CTxIn(COutPoint(d882102bbf, 0), scriptSig=3044022067dc5121916b5b10, nSequence=4294967294)
    CTxIn(COutPoint(c8eaec76b7, 0), scriptSig=3045022100829c89c815fcc0, nSequence=4294967294)
    CTxIn(COutPoint(0755324b49, 0), scriptSig=3045022100bd583594ea8f1f, nSequence=4294967294)
    CTxIn(COutPoint(1d3ac7f037, 0), scriptSig=3045022100af2e2dae1647b3, nSequence=4294967294)
    CTxIn(COutPoint(855d8b3c13, 1), scriptSig=304502210091fb3631d05934, nSequence=4294967294)
    CTxIn(COutPoint(91d5b5523a, 1), scriptSig=3044022073abe8c0c51ffb5f, nSequence=4294967294)
    CTxIn(COutPoint(b0919fa31e, 0), scriptSig=30440220635f29f518770dbf, nSequence=4294967294)
    CTxIn(COutPoint(2972e0d935, 0), scriptSig=3045022100880fa0fbf2952d, nSequence=4294967294)
    CTxOut(nValue=51.61836368, scriptPubKey=OP_DUP OP_HASH160 e07254d65ea7)
2015-11-15 13:12:20 AddToWallet 44645ad8338862133c7c88f53283014737c8a71fd9895a2f54a30bea782042a2  new
2015-11-15 13:12:20 ERROR: AcceptToMemoryPool: absurdly high fees 44645ad8338862133c7c88f53283014737c8a71fd9895a2f54a30bea782042a2, 22580 > 20000
2015-11-15 13:12:20 CommitTransaction(): Error: Transaction not valid

When I try to create the TX with 1k satoshi per kbyte instead of 10k satoshi per kbyte I can send it just fine. I will probably get a confirmation as well.



I am however a bit unsure how to avoid this issue in the future as core regularly suggests a fee higher than 1k satoshi per kbyte, esp. in middle of spam attacks. I have a workaround by create a TX by hand, but I prefer using the client. Is this something I can modify with limitfreerelay or minrelaytxfee? Currently set to 1500 and 1 satoshi respectivly.

Update: Yes it confirmed quickly as expected. A smaller TX (~192 byte) can also pay a higher fee per byte. 10k satoshi per kbyte works fine if its a single input and a single output.

Update2: It seems that TX with fees above 10k satoshi are refused no matter the number of inputs or the size of the TX. -> https://i.imgur.com/DkxgvHl.png
17  Other / Meta / Post counter bug? on: November 13, 2015, 05:41:48 AM
I noticed the user CryptoStoreTalk[1] has 0 posts and a matching 0 activity in their profile.

Yet they made two posts[2][3] already. Did something break?




[1] https://bitcointalk.org/index.php?action=profile;u=562094
[2] https://bitcointalk.org/index.php?topic=1247938.msg12959045#msg12959045
[3] https://bitcointalk.org/index.php?topic=1238833.msg12898284#msg12898284
18  Bitcoin / Development & Technical Discussion / O(1) Block Propagation, IBLT on: November 10, 2015, 12:07:48 PM
It looks like there is no thread about IBLT yet. Since there are many others out there that know more about it than me, I will mainly collect and link information here.

AFAIK the initial suggestion was made by Gavin.

Quote
O(1) Block Propagation

The problem

Bitcoin miners want their newly-found blocks to propagate across the network as quickly as possible, because every millisecond of delay increases the chances that another block, found at about the same time, wins the "block race."

With today's p2p protocol, this gives miners an incentive to limit the number of transactions included in their blocks. A transaction must pay more fees to the miner than they are statistically likely to lose due to the increased chance of losing a block race, since new block announcements include all of the data for all of the transactions in the block. This is inefficient (transaction data is transmitted across the network twice, using twice as much bandwidth) and artificially increases transaction fees to be much higher than they need to be.

Full text here: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2

Recently Kalle Rosenbaum did some work in the area, which includes a very nice infographic.

Quote
Solution

What if we could exploit the fact that all transactions in the block probably already have propagated the network. Why do we have to send all the transactions in the block again? We don’t. We have a few things to consider:

  • 1. Order of transactions within the block matters
  • 2. There are probably differences between mempools on different nodes
  • 3. We don’t know the differences

Let’s ignore 1 for now. (We can fix that either by canonical ordering of transactions within blocks, or by attaching ordering information with the message.)

This is how we deal with 2 and 3. Buckle up!



Full text (multi part): http://popeller.io/index.php/2015/10/09/bitcoin-block-propagation-with-iblt-infographic/
19  Other / Meta / Nested lists break preview? on: October 23, 2015, 03:30:55 PM
My overview thread[1] looks fine once saved, but when I edit and preview it. I see the following:



I am pretty sure I made no mistakes with the tags. Did I miss an error somehere or is the preview broken for nested lists?

Full code -> http://pastebin.com/9vaD4us9

[1] https://bitcointalk.org/index.php?topic=1217042.0
20  Other / Beginners & Help / [Overview] The one thread to link them all on: October 22, 2015, 07:09:59 AM
This is an attempt to collect and order every single important, useful or interesting thread for bitcointalk.org. This is for now based on my personal watchlist and thus can not be complete. If you think a thread is missing post a link and an ultra short (few words) summary below.

Disclaimer: Some of these threads might be outdated and/or contain wrong information. A linked thread does not equal endorsement.




Contributions sorted by awesomeness (alphabetical on tie)

Code:
8 - mexxer-2
6 - knightdk (aka achow101)
6 - OmegaStarScream
4 - freedomno1
3 - capcher
3 - MadGamer
3 - Mitchełł (aka Mitchell)
3 - SFR10
2 - dogie
2 - dothebeats
2 - Lauda
2 - minifrij
2 - sportis
1 - bL4nkcode
1 - Biitcoin
1 - Elwar
1 - ETFbitcoin
1 - InvoKing
1 - kingcolex
1 - Lutpin
1 - Mickeyb
1 - pereira4
1 - Winalunt
1 - YarkoL


todo:
Code:
more mining related material
more alt coin related material


changelog (noteable changes):
Code:
2015.11.12 - moved to beginners and help
2015.11.10 - added years to history section
2015.11.09 - added history section
2015.10.27 - added altcoin section
2015.10.23 - added mining section
2015.10.22 - added list of contributions
2015.10.22 - started thread
Pages: [1] 2 3 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!