2,66 BTC Gebuehren fuer eine einzelne Bitcoin-Transaktion

[btctester.com]

Wer entscheidet über die Höhe der Gebühren für eine Bitcoin-Transaktion? Es ist der Sender alleine, ausser er hat diese Entscheidung an seine Wallet oder seinen Provider delegiert. Z.B. in der BTC-Transaktion 3ba0c9eaf3185898164518cda7e3433d1d2049188d737f2b2a7e188aaeb8b4de hat jemand 0,01088549 BTC gesendet und eine Gebühr von 2,66038352 BTC bezahlt.

Die Standarderklärung dafür ist, dass es ein Fehler des Absenders war. Es könnte aber auch Geldwäsche sein. Wenn der Absender der Miner oder eine Person ist, die mit dem Miner zu tun hat, könnte es sein, dass diese Gebühr von fast 80 Tausend Euro mit der Absicht gezahlt wurde, Bitcoin aus kriminellen Aktivitäten in Miner-coins umzuwandeln, die normalerweise als jungfräuliche Münzen ohne Schuld aus der Vergangenheit angesehen werden. Diese Gebuehren landen ja auf der gleichen Bitcoinadresse wie die frisch geschoepften 6,25 BTC.

Wie kann man das untersuchen? Wenn die Transaktion nicht im Mempool der meisten Knoten war oder wenn die Transaktion nicht in verwaisten Blöcken zur gleichen Zeit war, dann ist es sehr verdächtig, dass die Gebühr an den Miner mit der Absicht gegeben wurde, die bitcoin zu waschen.

[Jokin]

Bei dieser Transaktion sind 753 Inputadressen angezogen worden und nur eine Output-Adresse.

Sieht mir eher danach aus als ob da jemand einen Fehler gemacht hat weil das nicht gerade eine Standardtransaktion ist. Eventuell wollte er wirklich nur diesen kleinen Betrag versenden hat jedoch seine gesamte Wallet geleert.

Dein "Geldwäscheszenario" halte ich für arg weit hergeholt. Da gibt es sicher einfachere Möglichkeiten Bitcoin zu "waschen". Denn wenn jemand die Coins nachverfolgt, dann wird er auch auf diese ungewöhnliche Transaktion stoßen und genau bei diesem Miner genauere Untersuchungen anstellen.

Darüber hinaus halte ich 80.000 USD nun nicht wirklich viel um einen derartigen Aufwand zu betreiben, da kann man die Bitcoin auch mal kurz Peer-to-Peer über drei Moneymules hin und herverkaufen und fertig ist die Geldwäsche.

[Morama]

Muss @Jokin zustimmen. Geldwäsche halte ich ebenfalls für ausgeschlossen bei diesem kleinen Popelbetrag. Wären es 2.6 Millionen $ wie damals bei ETH gewesen, geht es schon eher in die Richtung, wo ein derartiger Plan Sinn machen würde. Eher noch höhere Beträge mitlerweile bei BTC. Das Risiko muss sich auch tragen und das wäre sicher erst sinnvoll, wenn der gewaschene Betrag den Blockreward bei weitem übersteigt.

Hier sieht es nach Fehler aus.

[btctester.com]

Ich stimme euch zu, dass es in diesem Fall wohl wahrscheinlich ein Fehler des Senders war. Ich wollte die generelle Moeglichkeit aufzeigen. Da ist es nicht fernliegend, dass Leute mit Minern zusammenarbeiten. Ich weiss aus Polizeikreisen, dass viele versuchen Minern ihre jungfraeulichen coins abzukaufen fuer ueberhoehte Preisen. Oder dass sie selbst zu Minern werden, wenn es weniger risikoreich ist mit schmutzigen coins Strom zu zahlen als es an einer Boerse gegen fiat umzutauschen.

[Arther]

Spannender Gedankengang. Man müsste den Mempool tracken um zu sehen, ob die Transaktion mit hoher Wahrscheinlichkeit regulär eingepflegt worden ist oder "privat" an einen MIner gesendet wurde.

[Jokin]

vor 50 Minuten schrieb Arther:

Spannender Gedankengang. Man müsste den Mempool tracken um zu sehen, ob die Transaktion mit hoher Wahrscheinlichkeit regulär eingepflegt worden ist oder "privat" an einen MIner gesendet wurde.

Den Gedankengang finde ich auch interessant.

Wie kann das funktionieren?

1. Ich muss sicherstellen, dass meine Transaktion nur von dem Miner in die Blockchain aufgenommen wird mit dem ich einen entsprechenden Deal habe.

2. Der Miner muss sicherstellen, dass kein anderer Miner diese Transaktion in die Blockchain übernimmt.

3. Somit muss ich die Transaktion direkt an den Node des Miners übergeben, das ist ja nicht schwer.

4. Der Node muss daran gehindert werden diese Transaktion an andere Nodes weiter zu geben. Und das wird schon schwieriger. Mit irgendwelchen Firewallregeln kann das durchaus klappen.

5. Sobald ein Block mit dieser Transaktion gefunden wurde, muss dieser Block an das Netzwerk weiter gegeben werden. Damit der Block gültig ist muss aber auch diese Transaktion den anderen Nodes bekannt gemacht werden, denn ansonsten ist für die anderen Nodes der Block ungültig, da nicht validierbar.

Und nun wird's richtig brenzlig, denn dieser eine Minernode muss die Firewallregeln fallen lassen und propagiert nun nicht nur den Block sondern auch die Transaktion dazu.

Das größte Risiko besteht nun daran, dass am anderen Ende der Welt auch ein Block gefunden worden sein könnte und somit laufen nun zwei gültige Blöcke durch das Bitcoinnetzwerk. 

Wenn nun ein Miner auf dem "anderen" Block und mit dieser nun durch das Netzwerk getragenen Geldwäsche-Transaktion einen weiteren Block findet, dann war's das mit dem Plan.

Diese Gebühren gehen nun an den anderen Miner - alles futsch.

Wer wirklich Geld waschen will, der wird dieses Risiko scheuen.

[Arther]

vor 48 Minuten schrieb Jokin:

Wie kann das funktionieren?

Punkte 1-4 sind  ziemlich unkritisch, aber die race condition ist natürilch ein prinzipielles Problem. Wie oft kommt sowas denn vor, dass zwei Blöcke "fast zeitgleich" entstehen und dann die Verbreitungsgeschwindigkeit entscheidet, welcher Block übernommen word?

Zu Punkt 5: Die Transaktion muss natürlich nicht "separat" bekannt gemacht werden, aber sobald sie im Block steht und veröffentlicht wird könnte natürlich so wie du beschrieben hast ein anderer Miner diese aufgreifen und schreiben. Auch hier, unter der Annahme, dass es zu einer race condition kam. In dem Fall hat der ursprüngliche Miner aber natürlich noch einen Versuch :D.

Bearbeitet 26. Juli 2021 von Arther

[Jokin]

vor 41 Minuten schrieb Arther:

Zu Punkt 5: Die Transaktion muss natürlich nicht "separat" bekannt gemacht werden, aber sobald sie im Block steht und veröffentlicht wird könnte natürlich so wie du beschrieben hast ein anderer Miner diese aufgreifen und schreiben. Auch hier, unter der Annahme, dass es zu einer race condition kam. In dem Fall hat der ursprüngliche Miner aber natürlich noch einen Versuch :D.

Mit einem Block werden doch nur die Transaction-IDs übermittelt, oder?

Somit muss ein Node, der den Block validiert auch sämtliche dazu gehörige Transaktionen in seinem Mempool haben oder sich diese erst von anderen Nodes besorgen.

Oder lieg ich nun falsch?

 

vor 41 Minuten schrieb Arther:

Wie oft kommt sowas denn vor, dass zwei Blöcke "fast zeitgleich" entstehen und dann die Verbreitungsgeschwindigkeit entscheidet, welcher Block übernommen word?

Ist so etwas überhaupt feststellbar? Das können nur die Miner wissen, die einen fertigen Block rausschicken, der dann im Nachhinein abgewiesen wird?

Bearbeitet 26. Juli 2021 von Jokin

[Arther]

vor einer Stunde schrieb Jokin:

Mit einem Block werden doch nur die Transaction-IDs übermittelt, oder?

Somit muss ein Node, der den Block validiert auch sämtliche dazu gehörige Transaktionen in seinem Mempool haben oder sich diese erst von anderen Nodes besorgen.

Oder lieg ich nun falsch?

Das wäre eher überraschend, die einzige Wahrheit liegt auf der Blockchain und die Korrektheit (also z.B. Abwesenheit von Double Spends) wird bzw. kann validiert werden ohne externe Informationen hinzu zu ziehen. Der Mempool ist in dem Sinne nur ein Implementierungs-Detail bzw. eine "Komfort Funktion".

vor einer Stunde schrieb Jokin:

Ist so etwas überhaupt feststellbar? Das können nur die Miner wissen, die einen fertigen Block rausschicken, der dann im Nachhinein abgewiesen wird?

Ein Block wird theoretisch an "alle" Nodes geschickt, ich vermute Nodes valideren immer nur die längste Kette bzw. verwerfen ihre sofort, wenn sie eine längere Kette zugeschickt bekommen und sie die validieren konnten. Wie dann ein Konsens hergestellt wird, wenn gerade zwei valide Blöcke gleichzeitig umher gehen weiß ich nicht, vermutlich verwenden Miner Heuristiken um zu entscheiden, welcher Block am "ältesten" ist und bauen dann an diesem weiter. Es kann auch sein, dass die konkrete Implementierung abweicht. Große Miner sind ja im Prinzip große Konzerne und diese Technologie ist deren Hauptgeschäft, die werden vermutlich schlauere Dinge tun als einfach die Standard-Implementierung in Bitcoin-Core zu verwenden. Vielleicht gibt es auch Miner, die explizit zusammen arbeiten und sich immer früh gegenseitig informieren. Oder sie stehen in Konkurrenz und versuchen das genaue Gegenteil, ka.

Naja, jedenfalls so ein verwaister Block würde halt von "genug" Nodes empfangen werden. Der Terminology nach sind das wohl "Orphan Blocks".

Bearbeitet 26. Juli 2021 von Arther

[Jokin]

vor einer Stunde schrieb Arther:

Das wäre eher überraschend, die einzige Wahrheit liegt auf der Blockchain und die Korrektheit (also z.B. Abwesenheit von Double Spends) wird bzw. kann validiert werden ohne externe Informationen hinzu zu ziehen. Der Mempool ist in dem Sinne nur ein Implementierungs-Detail bzw. eine "Komfort Funktion".

Ich hab nun doch nochmal recherchiert: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki

Offenbar ist es so wie ich das schrieb: Es werden nur Blockheader und die darin enthaltenen Transaktions-IDs übermittelt. Den Rest muss der empfangende Node selber haben oder sich zügig besorgen.

Interessant dabei ist, dass es auch Geschwindigkeitsoptimierungen gibt. Verbundene Nodes, die auch sonst schnell sind bekommen ofenbar den neuen Block zuerst, was ja auch absolut sinnvoll ist.

vor 1 Stunde schrieb Arther:

Ein Block wird theoretisch an "alle" Nodes geschickt, ich vermute Nodes valideren immer nur die längste Kette bzw. verwerfen ihre sofort, wenn sie eine längere Kette zugeschickt bekommen und sie die validieren konnten.

Ein Block wird an die Nodes geschickt, die mit dem Minernode verbunden sind, das sollten natürlich möglichst viele sein, bzw. der Minder hat selber noch eine handvoll schnelle Nodes, die ihrerseits schnelle Verbindungen zu anderen Nodes aufrecht halten und diese immer mit allen Transaktionen versorgen damit die Blockvalidierung maximal schnell geht. Sobald ein Node erst eine Transaktion nachfragen muss, verliert er wertvolle Zeit.

vor 1 Stunde schrieb Arther:

Wie dann ein Konsens hergestellt wird, wenn gerade zwei valide Blöcke gleichzeitig umher gehen weiß ich nicht, vermutlich verwenden Miner Heuristiken um zu entscheiden, welcher Block am "ältesten" ist und bauen dann an diesem weiter.

Nein, Miner bauen nicht auf dem "ältesten" sondern auf den "jüngsten Block" auf. Denn ansonsten würden sie wertvolle Zeit vergeuden, denn ansonsten würden sie das Risiko eingehen in der kürzeren Kette zu verhungern.

 

vor 1 Stunde schrieb Arther:

Es kann auch sein, dass die konkrete Implementierung abweicht. Große Miner sind ja im Prinzip große Konzerne und diese Technologie ist deren Hauptgeschäft, die werden vermutlich schlauere Dinge tun als einfach die Standard-Implementierung in Bitcoin-Core zu verwenden.

Das wird ganz sicher so sein, denn Miner schieben auch immer gern mal leere Blöcke zwischendurch ein. Sobald der neue Block als Blockhash bekannt ist, fangen die Miner sofort an zu rechnen - auch ohne Transaktionen.

Während die Miner also schon rechnen arbeitet der Node noch daran die Transaktionen aus dem Mempool zu schmeißen (eher "kennzeichnen"), die im jüngsten Block enthalten waren. Danach startet er und baut die wertvollsten verbliebenen Transaktionen zu einem Block zusammen und übergibt dann den Hash an die Minerfarm, die dann durch Raten der Nonce immer wieder einen neuen Hashwert ermittelt und prüft ob dieser ausreichend viele Nullen zu Beginn hat (Difficulty-Anforderung erfüllen).

Während der Node also den Mempool durcharbeitet kann es durchaus sein, dass ein weiterer Block gefunden wurde und zack, dann geht der ins Netzwerk raus.

vor 1 Stunde schrieb Arther:

Vielleicht gibt es auch Miner, die explizit zusammen arbeiten und sich immer früh gegenseitig informieren. Oder sie stehen in Konkurrenz und versuchen das genaue Gegenteil, ka.

Auch das halte ich für durchaus möglich, das ist sogar gewollt von den Minern und sie sind mit ziemlicher Sicherheit direkt miteinander verbunden, denn wer will schon auf einen Block warten, der erstmal durch 10 Nodes validiert wurde.

(und ja, ich sehe auch, dass ich mich etwas widerspreche - ich stecke soooo tief da nun auch wieder nicht drin)

[skunk]

vor 5 Stunden schrieb Jokin:

4. Der Node muss daran gehindert werden diese Transaktion an andere Nodes weiter zu geben. Und das wird schon schwieriger. Mit irgendwelchen Firewallregeln kann das durchaus klappen.

Ich würde mir das ganz einfach machen. Der Code von Bitcoin Core ist Open Source. Fragt mich eine Node nach meinem Mempool dann Manipuliere ich die Antwort ein wenig und filtere da die Transaktionen raus, die mir eine besonders hohe Transaktionsgebühr bescheren würden. Ich würde das jedoch nur beim Mempool machen. Hat die Transaktion es in einen Block geschafft, ist das eine andere Codestrecke und damit greift meine Manipulation dort nicht mehr. Ein weiterer Vorteil ist, dass es für andere Nodes nicht so einfach überprüfbar ist. Für andere Nodes sieht das nach fehlerfreiem Verhalten aus.

[Jokin]

vor 7 Minuten schrieb skunk:

Fragt mich eine Node nach meinem Mempool dann Manipuliere ich die Antwort ein wenig und filtere da die Transaktionen raus, die mir eine besonders hohe Transaktionsgebühr bescheren würden.

Sehr gutes Beispiel dafür wie wichtig es ist Raspi-Nodes im Netzwerk zu haben, die frei von eigenen Interessen sind 👍

[btctester.com]

6 hours ago, Jokin said:

Den Gedankengang finde ich auch interessant.

Wie kann das funktionieren?

1. Ich muss sicherstellen, dass meine Transaktion nur von dem Miner in die Blockchain aufgenommen wird mit dem ich einen entsprechenden Deal habe.

2. Der Miner muss sicherstellen, dass kein anderer Miner diese Transaktion in die Blockchain übernimmt.

3. Somit muss ich die Transaktion direkt an den Node des Miners übergeben, das ist ja nicht schwer.

4. Der Node muss daran gehindert werden diese Transaktion an andere Nodes weiter zu geben. Und das wird schon schwieriger. Mit irgendwelchen Firewallregeln kann das durchaus klappen.

5. Sobald ein Block mit dieser Transaktion gefunden wurde, muss dieser Block an das Netzwerk weiter gegeben werden. Damit der Block gültig ist muss aber auch diese Transaktion den anderen Nodes bekannt gemacht werden, denn ansonsten ist für die anderen Nodes der Block ungültig, da nicht validierbar.

Und nun wird's richtig brenzlig, denn dieser eine Minernode muss die Firewallregeln fallen lassen und propagiert nun nicht nur den Block sondern auch die Transaktion dazu.

Das größte Risiko besteht nun daran, dass am anderen Ende der Welt auch ein Block gefunden worden sein könnte und somit laufen nun zwei gültige Blöcke durch das Bitcoinnetzwerk. 

Wenn nun ein Miner auf dem "anderen" Block und mit dieser nun durch das Netzwerk getragenen Geldwäsche-Transaktion einen weiteren Block findet, dann war's das mit dem Plan.

Diese Gebühren gehen nun an den anderen Miner - alles futsch.

Wer wirklich Geld waschen will, der wird dieses Risiko scheuen.

Zu 4. Da der code ja open source ist koennte man das so abaendern, dass diese eine Transaktion nicht bei Bekanntwerden propagiert wird.

Ja das Risiko ist, dass der Block verwaist aber durch seine Veroeffentlichung wird die Transaktion mit der hohen Gebuehr bekannt. Das wird zwar meistens gut gehen, aber das Risiko besteht.

[Cricktor]

Interessanter Ansatz um schmutzige Coins über eine exorbitante Transaktionsgebühr zu waschen, wenn auch sehr auffällig.

(Gestern hatte ich eine Transaktion rausgesucht, wo 54,0017 BTC Transaktionsgebühr bezahlt wurden, in Block 260343 war das. Tippe bei der Transaktion aber mal auf einen ganz schlecht debuggten Skript-Murks aus. Auch wenn 2013 der Kurs ein anderer war, hat das coin-technisch ganz heftig weh getan. Transaktion 4628c6edb3b0f0e1b79254c6ea3cc8934b1b34c6913fca7b528b753ed63c77f3 vom 2013-09-27 06:07, autsch!)

So eine Transaktion, also jetzt nicht der Mega-Fail von 2013, muss ja vom Miner konspirativ vor anderen zurückgehalten werden, um zu vermeiden, daß sie aus dem Mempool des Miners in andere Mempools übertragen wird und u.U. von einem anderen Pool in einen Block geschürft wird. Bis der konspirative Miner einen Block findet, der so eine Transaktion enthält, kann er die ja auch "geheim" halten, glaube ich jedenfalls. Die potentielle "Race-Condition" mit einem anderen zeitnahen Block besteht.
Wo ich bitcoin-protokolltechnisch nicht sattelfest bin, ob es ein Problem mit der Validierung geben könnte, wenn der konspirative Miner "seinen" Block ins Netzwerk überträgt und andere Nodes dann bei der Validierung dieses Blocks diese "spezielle Transaktion" nicht in ihrem Mempool finden können. Andererseits ist das vielleicht garnicht nötig, wenn der Block sonst alle Validierungsregeln erfüllt, sprich (sehr vereinfacht) nur valide UTXOs in den Transaktionen des Blocks sind und der Merkle-Root und Blockheader insgesamt den Regeln nach passen.

Riskant ist das schon und in der Blockchain dann extrem auffällig. Glaubt einem dann auch schnell keiner, wenn man sowas öfter machen sollte. Außerdem müsste das ein Miner sein, der keine Pool-Teilnehmer hat, sonst wundern die sich doch, daß der fette Blockreward nicht mit den dicken Gebühren verteilt wird.

[Arther]

vor 16 Stunden schrieb Jokin:

Ich hab nun doch nochmal recherchiert: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki

Offenbar ist es so wie ich das schrieb: Es werden nur Blockheader und die darin enthaltenen Transaktions-IDs übermittelt. Den Rest muss der empfangende Node selber haben oder sich zügig besorgen.

Spannend, danke fürs raussuchen. So wie ich das verstehe ist aber auch vorgesehen, neben Tx IDs auch vollständige Tx mitzuliefern (prefilled). Genau das würde in dem aktuellen Szenario dann ja auch gemacht werden.

  

vor 16 Stunden schrieb Jokin:

Nein, Miner bauen nicht auf dem "ältesten" sondern auf den "jüngsten Block" auf. Denn ansonsten würden sie wertvolle Zeit vergeuden, denn ansonsten würden sie das Risiko eingehen in der kürzeren Kette zu verhungern.

Vielleicht missverstehen wir uns. Ich sprach von dem Szenario, dass es einen neuen Block N1 gibt. Dann, sagen wir 1 Sekunde später, gibt es einen alternativen Block N2. Beide kursieren nun im Netzwerk. Wie wird nun entschieden, an welchem Block die Miner weiter dran arbeiten? Wieso wäre es ein Nachteil, an N1 zu arbeiten?

Bearbeitet 27. Juli 2021 von Arther

[Cricktor]

Du meinst den Fall, daß der zu N1 alternative Block N2 zufällig eine Verzweigung ergibt? Der Konsens ergibt sich, da die längere Kette gewinnt, was sich vielleicht erst mit dem Nachfolger von N1 oder N2 ergibt. Es wird Miner geben, die an N1 weiter anzuknüpfen versuchen, ggf. andere, die an N2 anknüpfen.

Ich denke, daß große Pools untereinander gut und schnell angebunden sind, um sicher zu stellen, daß ein Miner immer so schnell wie möglich Kenntnis vom jüngsten Block erlangt. Stellt man eine zufällig nahezu gleichzeitige Verzweigung fest, ist guter Rat "teuer". Keine Ahnung, wonach dann ein Miner entscheidet, an welcher Teilkette am besten weiter angeknüpft wird.

[Jokin]

vor 21 Minuten schrieb Cricktor:

Du meinst den Fall, daß der zu N1 alternative Block N2 zufällig eine Verzweigung ergibt? Der Konsens ergibt sich, da die längere Kette gewinnt, was sich vielleicht erst mit dem Nachfolger von N1 oder N2 ergibt. Es wird Miner geben, die an N1 weiter anzuknüpfen versuchen, ggf. andere, die an N2 anknüpfen.

Genau weiß ich das auch nicht.

Nur mal rein vom strategischen Gedanken her:

Wenn ich als Miner meinen fertigen Block N1 in die Welt rausschicke und ich bekomme vom Netzwerk den alternativen Block N2 zurück, dann kann ich als Miner davon ausgehen, dass es ein ziemlich großer Zufall ist wenn die anderen Miner den Block N1 eher erhalten haben. Ich halte es für wahrscheinlicher, dass mein Block N1 von den anderen Minernodes verworfen wird wenn sie diesen später erhalten haben.

Dennoch wird erst der Block N3 zeigen ob der auf N1 oder N2 aufgebaut wurde und somit die längste Kette ergibt.

 

Offenbar geschieht das immer seltener weil auch der Bitcoin-Code immer weiter optimiert wird: https://www.dsn.kastel.kit.edu/bitcoin/forks/

 

[Drayton]

Am 26.7.2021 um 00:00 schrieb btctester.com:

Die Standarderklärung dafür ist, dass es ein Fehler des Absenders war. Es könnte aber auch Geldwäsche sein. Wenn der Absender der Miner oder eine Person ist, die mit dem Miner zu tun hat, könnte es sein, dass diese Gebühr von fast 80 Tausend Euro mit der Absicht gezahlt wurde, Bitcoin aus kriminellen Aktivitäten in Miner-coins umzuwandeln, die normalerweise als jungfräuliche Münzen ohne Schuld aus der Vergangenheit angesehen werden. Diese Gebuehren landen ja auf der gleichen Bitcoinadresse wie die frisch geschoepften 6,25 BTC.

Vielleicht sind einige so "schlau", auf diese Weise BTC zu waschen. Von der "Auffälligkeit" her könnte man das nur noch übertreffen, wenn sich die Geldwäscher mit einer Waschmaschine direkt vors FA stellen...  

[SkaliertDoch]

Am 26.7.2021 um 00:00 schrieb btctester.com:

Wer entscheidet über die Höhe der Gebühren für eine Bitcoin-Transaktion? Es ist der Sender alleine, ausser er hat diese Entscheidung an seine Wallet oder seinen Provider delegiert. Z.B. in der BTC-Transaktion 3ba0c9eaf3185898164518cda7e3433d1d2049188d737f2b2a7e188aaeb8b4de hat jemand 0,01088549 BTC gesendet und eine Gebühr von 2,66038352 BTC bezahlt.

Die Standarderklärung dafür ist, dass es ein Fehler des Absenders war. Es könnte aber auch Geldwäsche sein. Wenn der Absender der Miner oder eine Person ist, die mit dem Miner zu tun hat, könnte es sein, dass diese Gebühr von fast 80 Tausend Euro mit der Absicht gezahlt wurde, Bitcoin aus kriminellen Aktivitäten in Miner-coins umzuwandeln, die normalerweise als jungfräuliche Münzen ohne Schuld aus der Vergangenheit angesehen werden. Diese Gebuehren landen ja auf der gleichen Bitcoinadresse wie die frisch geschoepften 6,25 BTC.

Wie kann man das untersuchen? Wenn die Transaktion nicht im Mempool der meisten Knoten war oder wenn die Transaktion nicht in verwaisten Blöcken zur gleichen Zeit war, dann ist es sehr verdächtig, dass die Gebühr an den Miner mit der Absicht gegeben wurde, die bitcoin zu waschen.

Mein erster Gedanke ist, dass da jemand keinen UTXO für das Wechselgeld kreiert hat, was Wallets eigentlich von selbst machen. Ohne diesen "Wechselgeld" Output an die eigene Adresse geht der den UTXO an die Empfangsadresse übersteigenden Wert als fee an den Miner.

[Firith]

vor 18 Stunden schrieb SkaliertDoch:

Mein erster Gedanke ist, dass da jemand keinen UTXO für das Wechselgeld kreiert hat, was Wallets eigentlich von selbst machen. Ohne diesen "Wechselgeld" Output an die eigene Adresse geht der den UTXO an die Empfangsadresse übersteigenden Wert als fee an den Miner.

Das ist ja sehr gruselig wenn so etwas im Bereich des Möglichen liegt. Also das durch einen Bug oder Fehler in der Wallet kein Wechselgeld zurück kommt, wovon der User ja davon ausgeht das es automatisch geschehen sollte.

[SkaliertDoch]

vor 20 Minuten schrieb Firith:

Das ist ja sehr gruselig wenn so etwas im Bereich des Möglichen liegt. Also das durch einen Bug oder Fehler in der Wallet kein Wechselgeld zurück kommt, wovon der User ja davon ausgeht das es automatisch geschehen sollte.

Nein. Das ist kein Bug in der Wallet. So etwas passiert eher bei Überweisungen an Btc Automaten, wenn man dort die Eingabefelder verwechselt. Ich war ja nicht dabei, also ist das eine reine Vermutung,  aber ich denke, das war ein Anwenderfehler.