Topic: Bitcoins zurückholen (Read 585 times)

Deine Transaktion landet einfach wieder im mempool.
Du könntest natürlich auch eine neue tx erstellen und diese in die neue Chain aufnehmen, dann hättest du erfolgreich einen double spend durchgeführt.
Die erste tx wäre nun obsolet bzw. erfolgreich rückgängig gemacht worden.

Meine Aussage war aber die Folgende.



ja, die Transaktionen aus den verwaisten Blöcken landen wieder im mempool AUSSER die Transaktionen waren auch in der 'Gewinner'- Chain vorhanden (wie es bei einem double spend der Fall ist).

Die Coins woanders hinschicken macht aber auch nur der Angreifer. "nicht doch noch irgendwann ausgeführt" heißt hier, dass die Transaktion von jedem gebroatcastet werden kann, da es eine gültige Signatur enthält.

Als Unbeteiligter bekomme ich das jedoch erst später mit. Wird meine Transaktion dann wieder in den Mempool gepackt?

Du hast keinen Denkfehler.
Es ist auch nicht zwangsläufig notwendig die Kette so lange zurück zu halten oder nur leere Blöcke zu minen, nur die eine TX nimmst du halt nicht auf

EDIT: Du schiebst aber natürlich die Coins woanders hin damit die TX nicht doch noch irgendwann ausgeführt wird. Also definitiv nicht nur leere blöcke minen.

Offtopic, da das sicherlich nicht der tatsächliche Angriff war:



Warum nicht?
Nehmen wir obiges Szenario an, in der grünen Chain passiert folgendes:
Ich schicke dir in Block 39 0,01 Coins, da du im BTC Talk Gewinnspiel richtig getippt hast. Somit verschwindet meine Tx aus dem Mempool. Die Transaktion wird durch das Finden von Block 40 bestätigt.
In Block 40 hat Käufer K 100 BTC an den Juwelier überwiesen - danach wird Block 41 gemined und die Tx erhält eine Bestätigung. Mein Output hat nun bereits 2 Bestätigungen während K gemütlich aus dem Laden herausspaziert.

Währenddessen hat K jedoch leere Blöcke gemined. Nach dem Finden von Block 41 veröffentlicht K nun seine Chain bis inklusive Block 42, woraufhin die rote Chain die längste wird.
Nun wurde meine Transaktion an dich rückgängig gemacht und muss nochmal gemined werden. Wo ist mein Gedankenfehler?

Ja, wenn man davon ausgeht, dass die Leute die das Geschäft verlassen auch die Täter sind, dann hast du natürlich recht. 
In den paar Sätzen sind mir zu wenig Hinweise, um auf einen bestimmten Sachverhalt zu schließen.

Da mole einen 51% Angriff erwähnt hat, wollte ich letztlich nur darauf hinaus, dass die Möglichkeiten bei einem solchen Angriff generell limitiert sind.

Aber ja, wird in dem Szenario vermutlich auf eine unbestätigte Transaktion + RBF hinauslaufen.

Hätten die mal eine Confirmation gewartet ...

Sehe ich anders. Für mich stellt es sich so dar, dass die Betrüger eine komische TX gesendet haben, die sie anschließend mit den o.g. Möglichkeiten (vermutlich aber eher nicht mit 51%) aber wieder verändert haben. Das war dann aber eben die EIGENE TX. Ich sehe hier keine "fremde" TX, die es zu verhindern galt.

Die haben mit ziemlicher Sicherheit Coins gesendet, und dann mit Doublespend die gleichen Coins woanders hin gesendet. D.h. die Coins waren unbestätigt. Ist inzwischen auch bei Face2Face ein gängiger Trickbetrug

Nein. Du kannst verhindern, dass eine (oder von mir aus auch alle) Transaktionen bestätigt werden.
Das macht die Transaktion aber nicht rückgängig.



Genau darum gings im Beispiel von mole0815, siehe:


Im Falle eines 51% Angriffs (genau darum geht es ja hier) profitiert man hauptsächlich durch einen double spend. 

Irrtum. Wenn ich mit einer 51%-Attake einen Block verwaisen lasse, werden zwar die entsprechenden TXes ungültig, ich habe es als dritte Partei allerdings sehr schwer die fremde TX dann dauerhaft daran zu hindern aufgenommen zu werden. Das halte ich für praktisch ausgeschlossen.
Aber wie oben geschrieben denke ich, dass es darum auch nicht geht.

Wie kommst du darauf, dass man "fremde" Transaktionen rückabwickeln will? Im Betrugsfall will man in der Regel die eigenen Transaktionen (oder Coins) nicht mehr in der Blockchain sehen - oder zumindest nicht in der Ursprünglichen Version.

Doch. Bei einem 51% Angriff werden alle Transaktionen der verwaisten Blöcke als nicht ausgeführt betrachtet. Schließlich sind alle Transaktionen der Blöcke nicht mehr in der längsten Chain, unabhängig davon ob der Angreifer die zugehörigen geheimen Schlüssel besitzt und die TX gebroadcastet hat.


Stimmt.

Auch wenn man 51% der Hashrate kontrolliert, kann ein Angreifer keine Transaktionen anderer Teilnehmer rückgängig machen. Es ist auch nicht möglich Coins zu versenden, die einem nicht gehören.
Seine eigenen Transaktionen könnte ein Angreifer aber rückgängig machen.


Kommt drauf an.
Für viele Exchanges reicht eine Confirmation nicht, die verlangen häufig drei.

Aber für die meisten use- cases ist eine natürlich vollkommen ausreichend.

sorry zuerst mal fürs ausgraben dieses alten threads... den hat mir die suche aber geliefert und ich denke es passt hier gut rein.

ich bin am wochennede über diesen artikel gestolpert: https://kurier.at/chronik/wien/bitcoin-betrug-teure-uhren-in-der-innenstadt-erschwindelt/400742007

das ist so doch nicht möglich. es gibt hier kurz zusammengefasst nur die möglichkeit per RBF oder race attack (oder 51% was wir mal ausschließen ) über den tisch gezogen worden zu sein, oder?
reicht es aus 1 bestätigung abzuwarten oder ist es erst ab 3-6 confirmations 100% safe?

vielleicht waren es hier aber auch ganz andere gründe wie ein verkäufer der sich blenden lies oÄ.
trotzdem wäre es interessant zu wissen wie es jetzt genau ist

@bob: Daran habe ich noch gar nicht gedacht, danke für die Ausführung.
So ein Angriff geht aber natürlich direkt an eine Node, sprich zB Exchange.
Wenn Du ein Lightwallet zB electrum verwendest, müsste der Angreifer schon wissen, mit welchem Server Dein Client sich verbindet.

Jedenfalls der einfache Angriff mittels rbf ist ein inzwischen gar nicht selten praktizierter Scam.
Deshalb lohnt es sich beim Annehmen von coins ein Wallet wie elektrum(PC-Version) oder Mycelium zu verwenden, daß ChildPayForParent kann, damit man eine evtl. absichtlich zu niedrige Fee "aufstocken" kann und nicht zB beim P2P-Treffen der evtl. unendlichen Wartezeit bis zur ersten Bestätigung ausgeliefert ist.

Viel Exchanges verlangen bei BTC heute bereits nur noch 2 Bestätigungen.
Für den Hausgebrauch und bei Existenziellen Beträgen reicht heutzutage aber schon eine.

@bob123
Das ist korrekt. Obwohl da muss man immer schauen nach der Verhältnismäßigkeit.

Für ein Kaffee oder Pizza die bezahlt wird, reicht es wirklich wenn etwas im Mempool gelandet ist.
Sollte jemand auf die Idee kommen ein Double Spend durchzuführen so ist die zu verschmerzen.

Bei höheren Beträgen reicht eigentlich schon 1 Bestätigung aus.

Beim Lambo würde ich 6 Bestätigungen abwarten.

Nur der Vollständigkeit halber:

Das RBF-flag muss nicht gesetzt sein um einen Double spend durchzuführen.

Es gibt mehrere Ansätze eine noch nicht bestätigte Transaktion zu 'double-spenden'. Diese sind definitiv nicht trivial und haben keine Garantie zu funktionieren.
Dennoch besteht die Möglichkeit - unter gegebenen Vorraussetzungen - einen Double spend durchzuführen. Zumindest für technisch affine Personen. Selbst ohne RBF-flag.


Ein Beispiel wäre der 'Race attack':
Ein Angreifer bereitet beide Transaktionen vor (die double-spending und die, die das Opfer sehen soll).
Dann sorgt der Angreifer dafür, dass er direkt mit dem Opfer connected ist und zugleich mehrere 'Helfer-nodes' hat, die die double-spend Transaktion broadcasten.

Dann wird die 'originale' (zu ersetzende) Transaktion mit dem Node, welcher mit dem Opfer connected ist, gebroadcastet und gleichzeitig broadcasten die Helfer-nodes die Double-spend Transaktion.

Wenn dies richtig gemacht wird, sieht die Mehrheit des Netzwerkes die Double-Spend Transaktion als die 'erste' an und speichert diese im Mempool ab während das Opfer die zu ersetztende TX sieht und die zweite abweist (mempool conflict).

In diesem Fall stehen die Chancen gut, dass die Double-spend Transaktion bestätigt wird.


Es gibt mehrere solcher Angriffe. Und aus diesem Grund ist es auch nicht empfehlenswert 0-conf Transaktionen für 'höhere' Beträge zu akzeptieren.

Eine wunderschöne, vollständige und fehlerfreie Zusammenfassung. Prima!

Es gibt durchaus die Möglichkeit eines Doublespends, dh so lange noch nichts bestätigt ist und die Tx mit dem entsprechenden Flag(rbf) gesendet wurde, kann sie durch eine andere Tx ersetzt werden, also die Coins wo anders hingeschickt werden.
Ausserdem kann eine sehr unglücklich gesendete TX(zB zu wenig Fee oder Verstoss gegen die Dustregel)vom Netzwerk abgelehnt werden und dadurch aus dem Mempool herausfallen, also praktisch nie gesendet worden sein.
Was aber bestätigt ist, bleibt es auch, es sei denn der Block wird abgelehnt(Fork), was aber praktisch nicht vorkommt bei BTC.
Das alles betrifft Transaktionen in der Blockchain.

Datenbanktransaktionen in zB einer Börse kann natürlich so oder so behandelt werden, so lange noch nichts ins BTC-Netzwerk gebroadcastet wurde.

Bitcoin ist (fast)absolut sicher, nur wie damit umgegangen wird,zB auf Exchanges, kann es unsicher machen.

Ich denke damit hat er einfach nur der Zeitraum gemeint, in dem man z.B. die Auszahlung von einer Börse noch verhindern kann. Direkt nach dem Auftrag steht diese auf "Pending" und lässt sich stornieren. Falls die Tx bereits geschickt wurde, ist es wie Du schon sagst, dafür längst zu spät.

Was ist denn das für eine Aussage? Wenn eine Transaktion von irgendwem vor dem Senden "zurückgehalten wird", ist sie ja gar nicht erst gesendet wurden und braucht deshalb auch nicht zurückgezogen werden.
Das ist wie wenn du die Frage "Ob man eine Einzahlung auf ein Giro-Konto zurückziehen kann" beantwortest mit "Wenn Du Geld hast, was du einzahlen willst und dir das dann doch anders überlegst und behältst, dann kannst du das tun."

Wenn sie gesendet wurde, bleiben nur die oben beschriebenen Möglichkeiten. Unbestätigt aus dem Mempool ist vielleicht noch denkbar (Doublespend), aber wenn sie bestätigt wurde, ist es in den meisten Fällen praktisch aussichtslos.