nachdem ich gerade noch eine Überweisung gemacht habe und schon bei 0Bestätigungen der "Lock wait timeout exceeded; try restarting transaction" Fehler kam, ist blockchain.info gerade nicht mehr erreichbar O.ô
Connection timed out error 522
laut http://www.justdownforme.com/ ist blockchain.info tatsächlich down. gibts noch ne andre Website, wo man Transaktionen verfolgen kann?
edit:
blockchain.info alternative
Topic: Bitcoin überweisungen verhalten sich merkwürdig - page 2. (Read 2672 times)
Quote
Naja, dein Client hat TX 1 gesendet. Die identische TX 2 wird aber bestätigt.
Wo kommt denn deine TX 2 her?Wenn ich eine TX schicke, jemand verändert den Hash, die "gefälschte tx" kommt in einen Block, dann erkennt QT, dass es sich um die selbe TX handelt. Also hier entstehen keine 2 identischen TX in der Wallet.
Probleme gibt es bei TXs, die auf den unbestätigten Changes der oben genannten TXs basieren. Nur wieso verbucht QT dadurch 2 TX?
Beispiel:
1. Ich erhalte auf A 2 Bitcoins
2. Ich sende von A 1 Bitcoin nach B und der Client sendet 1 Bitcoin zurück an mich (C) -> TX1
3. Ich sende 1 Bitcoin von C nach D -> TX3 (TX1 noch unbestätigt)
4. Angreifer manipuliert TX1 und es ensteht TX2, welche in einen Block aufgenommen wird. TX1 wird als Double spend makiert
5. Da TX1 eine double spend Transaction ist, wird TX3 als ungültig betrachtet
Wieso kommt es jetzt zu einer zweiten Version von TX3 unter QT?
OT: Mir ist auch nicht klar warum Mtgox Nutzer ihre Bitcoins nicht erhalten haben. Die User hier können ja nicht oft genug bestätigen, dass Malability eigentlich kein Problem ist, da ja alle Coins richtig verbucht werden.
Quote
So weit alles gut. Nur eine der zwei TX wird jemals bestätigt, korrekte Menge Coins am korrekten Ziel.
vielen dank, meine frage ging aber mehr in die richtung:
-was kann das bedeuten (worst case) ?
-wer macht das/ wer profitiert davon ?
-was kann das bedeuten (worst case) ?
-wer macht das/ wer profitiert davon ?
Worst Case, ein Haufen abgefressener Noobs, die denken ihre Coins wären gestohlen und technisch nicht in der Lage sind, dass zu korrigieren.
Monate an Arbei für jemanden wie MT.Gox, wenn in einer Wallet z.B. 500.000 Transaktionen drin sind und 1.000 ganz spezielle per Hand gelöscht werden müssen. Einfaches Exportieren aller Private Keys und importieren in eine neue Wallet, sollte das aber auch beheben.
Profitieren kann man davon eigentlich kaum. Man bekommt ja keine 2 Fache Zahlung.
Das einzige, wäre, wenn ein Automatisches Programm nur auf die TX-ID schaut um zu bestimmen ob Coins gesendet/empfangen wurden. So eins könnte man evtl. reinlegen, dass es z.B. nochmal sendet, bzw. dir ein Guthaben nicht gut schreibt. Wär aber von vorne rein bescheuert programmiert.
http://falkvinge.net/2014/02/11/the-embarrassing-fact-mtgox-left-out-of-their-press-release/
Schoen beim Luegen erwischt.
Schoen beim Luegen erwischt.
Es ist aber tatsächlich ein Problem. Scheinbar versucht jemand derzeit etwas zu beweisen und es werden massiv Transaktionen verändert.
Dein Klient zeigt dir dann beim Senden sowas an:
Nur eine von diesen beiden wird jemals bestätigt werden. Soweit so gut. Aber wenn die die nicht von dir ist bestätigt wird, wird dein Client die von ihm gesendete niemals entfernen. D.h. die Coins bleiben gesperrt. Lösung ist, das man mit z.B. PyWallet, die Transaktion per Hand entfernt.
Für Leute wie mich OK, aber für "Mainstream User" unmöglich. Und wenn man wie MT.Gox womöglich tausende Transaktionen per Hand entfernen muss, kann das wirklich problematisch werden.
Edit: #%&!-Image Server. Fixxed.
bitte erläutere etwas detaillierter was das bedeutet/bedeuten kann, cui bono ?
Naja, dein Client hat TX 1 gesendet. Die identische TX 2 wird aber bestätigt.
Das Netzwerk wird TX 1 nun für einen double Spend halten und komplett blocken.
So weit alles gut. Nur eine der zwei TX wird jemals bestätigt, korrekte Menge Coins am korrekten Ziel.
Nur dein Klient, schreibt die TX 1 in dem Moment in dem er sie sendet in deine Wallet.dat (mit Change Adresse, usw).
Diese wird nie bestätigt werden, dein Client stellt dir die BTC aber trotzdem nicht mehr zur Verfügung.
Die einzige Möglichkeit wieder an deine BTC zu kommen, ist ein Backup deiner Wallet.dat zu laden, oder diese TX mit einem Editor per Hand aus der Wallet.dat zu entfernen, damit dein Client diese TX wieder vergisst.
(*wenn in der neuen Version vom QT schon implementiert ist, dass auch eigen Transaktionen nach einer Weile wieder vergessen werden, rede ich hier natürlich blödsinn)
vielen dank, meine frage ging aber mehr in die richtung:
-was kann das bedeuten (worst case) ?
-wer macht das/ wer profitiert davon ?
http://falkvinge.net/2014/02/11/the-embarrassing-fact-mtgox-left-out-of-their-press-release/
Schoen beim Luegen erwischt.
Schoen beim Luegen erwischt.
Es ist aber tatsächlich ein Problem. Scheinbar versucht jemand derzeit etwas zu beweisen und es werden massiv Transaktionen verändert.
Dein Klient zeigt dir dann beim Senden sowas an:
Nur eine von diesen beiden wird jemals bestätigt werden. Soweit so gut. Aber wenn die die nicht von dir ist bestätigt wird, wird dein Client die von ihm gesendete niemals entfernen. D.h. die Coins bleiben gesperrt. Lösung ist, das man mit z.B. PyWallet, die Transaktion per Hand entfernt.
Für Leute wie mich OK, aber für "Mainstream User" unmöglich. Und wenn man wie MT.Gox womöglich tausende Transaktionen per Hand entfernen muss, kann das wirklich problematisch werden.
Edit: #%&!-Image Server. Fixxed.
bitte erläutere etwas detaillierter was das bedeutet/bedeuten kann, cui bono ?
Naja, dein Client hat TX 1 gesendet. Die identische TX 2 wird aber bestätigt.
Das Netzwerk wird TX 1 nun für einen double Spend halten und komplett blocken.
So weit alles gut. Nur eine der zwei TX wird jemals bestätigt, korrekte Menge Coins am korrekten Ziel.
Nur dein Klient, schreibt die TX 1 in dem Moment in dem er sie sendet in deine Wallet.dat (mit Change Adresse, usw).
Diese wird nie bestätigt werden, dein Client stellt dir die BTC aber trotzdem nicht mehr zur Verfügung.
Die einzige Möglichkeit wieder an deine BTC zu kommen, ist ein Backup deiner Wallet.dat zu laden, oder diese TX mit einem Editor per Hand aus der Wallet.dat zu entfernen, damit dein Client diese TX wieder vergisst.
(*wenn in der neuen Version vom QT schon implementiert ist, dass auch eigen Transaktionen nach einer Weile wieder vergessen werden, rede ich hier natürlich blödsinn)
Aber warum geht das erst jetzt los bei den anderen Börsen? Kann es sein dass ein Angreifer jetzt auf andere Börsen ausweicht?
Vielleicht sind jetzt alle Börsen durch die Geschichte mit Mt.gox aufgeschreckt und überprüfen ihre konfigurationen...
Aber warum geht das erst jetzt los bei den anderen Börsen? Kann es sein dass ein Angreifer jetzt auf andere Börsen ausweicht?
Scheint als hätte Mark recht gehabt.
Bitcoin.de, BTC-E, Bitstamp und Coinbase haben alle Probleme mit den Auszahlungen.
PS: Auf der Suche nach einer ordentlichen Erklärung, warum bei Mtgox Auszahlungen die TX geändert wurden. Finde nur allgemeinen Unsinn, aber nichts genaues ob MtGox die Tx falsch encodiert/formatiert oder ob jemand das Netzwerk manipuliert.
https://bitcointalksearch.org/topic/stats-on-malled-transactions-459678
Standartmäßig können Change Inputs (Überweisungen von und an die eigene Wallet) ohne Bestätigungen abzuwarten für Transactionen verwendet werden. Wenn allerdings die Transaktion, in der der Change Input entstanden ist, durch die Malleability Attack als Double Spend makiert wird, dann basiert die 2. Transaktion auf einenm Double Spend Input und wird daher vom Netzwerk nicht weitergeleitet.
Mir ist allerdings nicht klar, warum diese TX nicht auf Blockchain.info auftrauchen. Die listen doch normalen jede noch so krumme Transaction.
Und warum rebroadcasted der Client schon nach 10 Minuten?
Bitcoin.de, BTC-E, Bitstamp und Coinbase haben alle Probleme mit den Auszahlungen.
PS: Auf der Suche nach einer ordentlichen Erklärung, warum bei Mtgox Auszahlungen die TX geändert wurden. Finde nur allgemeinen Unsinn, aber nichts genaues ob MtGox die Tx falsch encodiert/formatiert oder ob jemand das Netzwerk manipuliert.
https://bitcointalksearch.org/topic/stats-on-malled-transactions-459678
Quote
Aber warum geht das erst jetzt los bei den anderen Börsen? Kann es sein dass ein Angreifer jetzt auf andere Börsen ausweicht?
Scheinbar betrifft das Problem der Malleability auch die Referenz Implementierung (z.B. QT, darauf basierende Versionen).Standartmäßig können Change Inputs (Überweisungen von und an die eigene Wallet) ohne Bestätigungen abzuwarten für Transactionen verwendet werden. Wenn allerdings die Transaktion, in der der Change Input entstanden ist, durch die Malleability Attack als Double Spend makiert wird, dann basiert die 2. Transaktion auf einenm Double Spend Input und wird daher vom Netzwerk nicht weitergeleitet.
Mir ist allerdings nicht klar, warum diese TX nicht auf Blockchain.info auftrauchen. Die listen doch normalen jede noch so krumme Transaction.
Und warum rebroadcasted der Client schon nach 10 Minuten?
Hi, ich eröffne mal einen neuen Thread zur Diskussion darüber.
Z.b. nachzulesen hier: https://forum.bitcoin.de/threads/2783-Auszahlung-im-Nirvana
und auch im Thread zum aktuellen Kursverlauf kamen schon ein paar aussagen, dass Überweisungen auf sich warten lassen.
Was meint ihr dazu? Z.b auch zu meinem Post im bitcoin.de Thread mit dem "Lock wait timeout exceeded; try restarting transaction" ?
Z.b. nachzulesen hier: https://forum.bitcoin.de/threads/2783-Auszahlung-im-Nirvana
und auch im Thread zum aktuellen Kursverlauf kamen schon ein paar aussagen, dass Überweisungen auf sich warten lassen.
Was meint ihr dazu? Z.b auch zu meinem Post im bitcoin.de Thread mit dem "Lock wait timeout exceeded; try restarting transaction" ?
Jump to: