Zum Inhalt springen

Zur Vorbereitung auf stürmische Tage:


Empfohlene Beiträge

 

zu I. Coinmixing

2. Nun besorgt man sich zusätzlich Coins, die irgendwann mal auf der BTCC-Chain gemint wurden (dazu später mehr).
Man hat nun zwei Adressen. Adresse A hält die "alten" Coins und Adresse B die neuen "geminten".
Idee: Man bildet nun eine Transaktion mit zwei Inputs (Adresse A und Adresse B ) und einem Output Adresse C auf der (der Einfachheit halber) gleichen Wallet und schickt sie mit normalen (oder zur Sicherheit besseren) Gebühren ab.
Was passiert? Die Transaktion landet bei einem BTCC-Node, wird validiert, in den Mempool gelegt und irgendwann von einem BTCC-Miner in einen Block aufgenommen, welcher anschließend an die BTCC-Chain angehängt wird. Das BTCC-Wallet synchronisiert und die Überweisung ist fertig. Das bedeuet es exist jetzt auf der BTCC-Chain ein sauber bestätigter Eintrag der gemixten Transaktion. 

 

Anmerkung zu Punkt 2.

Die Schwierigkeit ist jetzt aber, wie man an die "frischen" Coins rankommt. Mir fallen drei Möglichkeiten ein:
 

 

 

 

Wieso müssen die BCC-Coins auf der neuen Chain gemint worden sein? Wenn die BCC-Coins auf einer Adresse in einem BCC-Block liegen, also auf der abgespaltenen neuen Chain, und die Adresse wurde vorher noch in keinem Netzwerk benutzt, hat also nur 1 Transaktion, nämlich den Input von BCC, dann spielt es doch keine Rolle, woher diese BCC ursprünglich stammen oder nicht? Ein Wallet prüft doch nur, in welchen Blöcken die Adresse steht, und nicht, wo der Coin ursprünglich herkommt oder sehe ich das falsch?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Zufall, das er mit Axiom Ähnlichkeiten aufweist?

 

 

Reiner Zufall. Ich seh da auch keine Ähnlichkeit, wenn bei einem Nick lediglich zwei Buchstaben am Anfang gleich sind und mein a noch kleingeschrieben ist. Ich hab irgendwas kurzes mit Bitcoin gesucht als Nickname, auf die Tastatur geschaut und auf a und x getippt und bitcoin mit bit abgekürzt, fertig war der Nick. :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Gespaltene Persönlichkeiten scheint es in diesem Forum öfter zu geben. Vielleicht ists ja wirklich Zufall. Mir ists schnuppe. Ich antworte einfach mal, haben ja alle was von. 

 

Also ...

du kannst mit allen Coins mixen, die einen Output erzeugen, der auf der einen Chain gültig ist und auf der anderen zum Widerspruch führt. Mit geminten Coins ist das nur einfacher zu erklären. 

 

... Ein Wallet prüft doch nur, in welchen Blöcken die Adresse steht, und nicht, wo der Coin ursprünglich herkommt oder sehe ich das falsch? ...

Genau das siehst du falsch! Wenn das nicht gegeben wäre, würde das gesamte Netzwerk nicht funktionieren. Ich schreib einfach nochmal ein paar Sachen zum besser Verstehen auf.

 

Kurz und Kompakt: Was sind Nodes? 

Es gibt ein paar unterschiedliche Sorten davon. Die bekanntesten sind Full Nodes, Miner Nodes und Light Nodes (SPV).

Die Miner Nodes erbringen den Arbeitsnachweis und bauen den Block, hängen ihn an und schicken ihn ins Netzwerk. Damit keiner Mist reinschreibt gibts andere Nodes die den Block kontrollieren, die Full Nodes. Full Nodes sind die, die die gesamte Blockchain herrunterladen und regelmäßig synchronisieren. Und sie machen genau dass, was du glaubst was nicht passiert. Sie kontrollieren jede  einzelne Transaktion für sich auf Korrektheit und verfolgen jeden einzelnen Input davon die komplette Kette bis zum Ursprung zurück. Wenn kein Fehler gefunden wird, ist die Transaktionshistory valide, wenn im ganzen Block kein Fehler gefunden wird ist der Block valide. Genau das ist der Validierungsprozess.

 

Kurz und Kompakt: Was ist eine Transaktion?

Eine Transaktion (TX) ist im einfachsten (häufigsten) Fall einfach das bilden von Inputs und Outputs. Dies geschieht nach gewissen Protokollregeln, ähnlich wie bei einer Bitcoin-Adresse. Eine Full Node kontrolliert selbst ob die TX gültig ist und sendet sie raus an alle anderen Nodes. Diese kontrollieren die TX wiederum. Wenn ok geht sie in den Transaktionspool (Mempool). Eine TX hat zudem ähnlich wie ein Block, einen Header in dem unter anderem ein Eintrag steht, der bestimmt, wie die TX gehasht werden soll. Außerdem hat eine klassische BTC-Transaktion am Ende ein Script mit einer Signatur und dem Public Key.

 

Kurz und Kompakt: Warum splittet eine Chain?

Eine Chain splittet, wenn "wichtiger" Konsens nicht mehr besteht gepaart mit noch anderen Faktoren (Es existieren neue Miner für den Fork etc.) In diesem Fall (BTC-BTCC) splittet die Chain, weil sich einfach gesagt das Blockformat ändert. Knapp: BTC -> Segwit-Blöcke mit (erstmal weiterhin 1MB) vs. BTCC >1MB Blöcke. (Am Rande: Eine wesentliche Protokolländerung bei Segwit ist bspw, dass die Signatur und der Pubkey von jeder TX nicht mehr in den Block integriert werden und in einen Extended Block ausgelagert werden. Das ist auch der Grund warum dann mehr TX reinpassen und soweit ich weiß übrigens ASIC-Boost nicht mehr funktioniert. Asic Boost funktioniert nur mit der alten Blockstruktur.)

 

Kurz und Kompakt: Warum hab ich nach einer Hardfork automatisch zwei Coins?

Es ist einfacher zu verstehen, wenn man sich die Chain-Timeline vor Augen führt. Sagen wir die Chain ist zum Zeitpunkt t0 noch nicht gesplittet und t1 ein Zeitpunkt nach dem Forkereignis. Hat man bei t0 sagen wir 10 BTC hat man bei t1 ebenfalls 10 BTCC. Warum? Wir erinnern uns: Eine Blockchain ist letztendlich eine Timeline-Datenbank. Wenn ein Node aus Sicht der BTC Chain vom Zeitpunkt t1 rückwärts

die Blöcke durchgeht, findet er irgendwann den Block mit der Adresse, die die 10 BTC Coins hält. Aus Sicht eines BTCC Nodes ebenfalls zum Zeitpunkt t1 passiert das gleiche. Für den Node existiert jeweils nur eine eigene gültige Chain. Das allein ist schon die Erklärung.

 

 

Kurz und Kompakt: Was genau ist eigentlich eine Replay-TX

Jetzt gehts an das eigentliche Problem. Viele Leute denken (ich bis vor kurzem auch), dass man beide Coins nach einem Fork einfach

ganz normal weiterverwenden kann, weil die Chains doch nix mehr voneinander wissen. Wir haben ja gerade im Absatz drüber "bewiesen",

dass jede Chain einzigartig ist, wo ist jetzt also das Problem? Der Grund ist, dass man anfangs nur die Blöcke im Auge hat und den Rest

des Protokolls vergißt, der noch Konsens hat. Es stimmt, dass die Blöcke zueinander inkompatibel sind, aber es stimmt auch, dass,

wie in diesem Fall, der Prozess der Transaktionbildung in beiden Protokollen weiterhin identisch ist. Das bedeutet wenn keine

Vorkehrungen getroffen sind, landet ein und dieselbe Transaktion, nur einmal abgeschickt sehr wahrscheinlich in jedem Mempool von jedem

Full-Node und dann irgendwann auch Miner-Node (beide BTC-Nodes und BTCC-Nodes). Was bedeutet das? Sagen wir es findet eine Transaktion auf der BTC-Seite statt. Die Transaktion wird wie gewünscht vom BTC-Miner aufgenommen und ist somit ausgeführt. Diejenigen Transaktionen, die es in den Block geschafft haben, fliegen normalerweise aus dem Mempool raus und dieser Zustand synchronisiert sich dann über das Netzwerk. Wenn man aber Pech hat und ein BTCC-Miner findet einen Block, bevor die Synchronisierung bei ihm angekommen ist, dann ist die ursprüngliche TX ja noch noch in dessen Mempool vorhanden. Findet er zudem dann auch noch vorher einen Block, dann kann die gleiche TX da auch noch reinrutschen. Ergebnis: Die Coins sind auf beiden Chains überwiesen, obwohl man nur auf einer Seite transferieren wollte. Genau das nennt man "Übersprechen" oder "Replay".

Geht man jetzt von diesem Zeitpunkt t3 auf der Zeitachse in der Blockchain zurück ist aber trotzdem in jeder Chain eine valide History zu vorzufinden. Die Protokolle haben korrekt gearbeitet.

Ausflug Replay-Attacke: 

Eine Replay-Attacke ist das selbe wie normaler Replay, nur das Transaktionen trotz Schutzmechanismen, die eine TX-Vermischung verhindern sollen künstlich in das jeweilige andere Netzwerk überführt werden. Z.B. ein MITM-Node, der die TX abfängt und ins andere Netz durchreicht. Oder einfach ein böser Händler, eine einzelne Transaktion in das andere Netz injiziert und so die Coins aus der anderen Chain klaut.

 

Kurz und kompakt: Was hat das ganze am Ende mit Coinsplitting zu tun?

Coinsplitting ist letztlich nix anderes als eine Art Replay-Schutz, den jeder selber bauen kann. Wie es geht hab ich im Post drüber ja schon beschrieben. Nochmal knapp: Man muß eine TX bauen, die auf einer Seite des Forks zum Widerspruch führen muß. Und das geht indem man als Input alte Coins mit neuen mixt, dessen Historie zeitlich nach dem Hardfork beginnt. Am leichtesten zu verstehen ist das mit geminten Coins. Wenn Coins auf einer Chain bei t3 also nach der Fork gemint werden, können sie nicht auf der jeweils anderen Seite existieren. Nimmt man davon welche mit in die TX validiert sie nur auf einer Seite. Ergebnis: Der Split ist vollzogen.

Deshalb übrigens nach einem Chain-Fork immer erst zu eigenen Adressen mit kleinen Beträgen überweisen und testen. Falls die Überweisung in der anderen Chain nachgespielt wird, dann hat man nur die Gebühren verloren.

 

Kurz und kompakt: Was ist eine Replay-Protection? (Speziell jetzt bei BTC Cash).

Wie oben gelernt, sind die Blöcke von BTCC unterschiedlich (daher Fork), aber die die TX gleich und Replay findet statt. Da Bitcoin Cash "sauber" forken will, haben sie selbst einen Replay-Schutz ins Protokoll eingebaut. Dieser Schutz sieht vereinfacht gesagt so aus, dass die Regel, wie eine Transaktion gehasht wird bei BTCC-Nodes nun anders ist. Dies wird erreicht in dem im oben erwähnten TX-Header ein bestimmtes Flag gesetzt wird. (Für die Experten: Technische Details in den Links weiter oben). Im Ergebnis nehmen BTCC-Miner nur noch diese neuen Transaktionen an und weisen BTC-Node-gebaute TX ab. Ein Replay auf der BCC-Chain, wie oben beschrieben sollte also nicht stattfinden können. Man muß einfach irgendwann nach dem Fork (dass ist nicht allzu zeitkritisch, falls man nicht ein Hardcore-Trader ist) seine BTC auf eine eigene neue Adresse überweisen und die BCC bleiben dann da wo sie sind. 

Siehe hier das Announcement: https://www.bitcoincash.org/replay

 

Info: Ich übernehme keine Verantwortung dafür, wenn das hier jemand ausprobiert und die Coins sind dann weg, weil es doch nicht so funktioniert wie gedacht! Jeder ist für sein Handeln selbst verantwortlich!

 

Man könnte jetzt so vorgehen: 

1. Einfach dem Replay-Schutz von Bitcoin Cash vertrauen und nix machen.

2. Wie gehabt irgendwie frisch geminte coins (am besten auf der BTC Seite) nach dem Fork besorgen und dann alt mit neu auf eine neue Adresse mixen, das müsste doppelt sicher sein. Versprochener Replay-Schutz von BTC-Cash + Coins mit History-Start nach dem Fork.

3. Man baut sich selbst einen einmaligen coin durch testen. Z.B. erstmal nur 0,1 BTC auf eine neue BTC Adresse überweisen. Lange warten und schauen ob die Replay-Protection funktioniert hat. Einfach im Blockexplorer auf beiden Chains nach der Überweisung suchen. Wenn nur auf einer Kette ein Eintag existiert, dann hat es geklappt. Am besten 10-20 oder mehr Bestätigungen abwarten. Dann kann man zusammen mit dem

0,1 BTC "magic input" nochmal den Rest auf eine neue Adresse überweisen und verankert somit den Rest auch. Danach die alten Schlüssel und Adressen im BTCC-Konto einlesen und dort auf neue ungleiche Adressen, am besten komplett neues HD-Wallet überweisen. Fertig.

 



Info: Ich übernehme keine Verantwortung dafür, wenn das hier jemand ausprobiert und die Coins sind dann weg, weil es doch nicht so funktioniert wie gedacht! Jeder ist für sein Handeln selbst verantwortlich!

 


In dem Sinne. Gut Coin.

Bearbeitet von bavarian
  • Love it 4
Link zu diesem Kommentar
Auf anderen Seiten teilen

Danke, das finde ich mal eine gute Erklärung!

 

Noch eine Frage, ich habe hier noch ein Paperwallet, was schon einige Jahre liegt und das möchte ich ungerne jetzt verändern.

Wenn ich das dann irgendwann doch benutze würde es ausreichen das dann als erstes auf eine eigene neue Adresse zu transferieren um safe zu sein?

(Und die andere Chain einige Zeit zu überprüfen ob die Transkation dort nicht auch ausgeführt wird)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Danke, das finde ich mal eine gute Erklärung!

 

Noch eine Frage, ich habe hier noch ein Paperwallet, was schon einige Jahre liegt und das möchte ich ungerne jetzt verändern.

Wenn ich das dann irgendwann doch benutze würde es ausreichen das dann als erstes auf eine eigene neue Adresse zu transferieren um safe zu sein?

(Und die andere Chain einige Zeit zu überprüfen ob die Transkation dort nicht auch ausgeführt wird)

Ja würde genügen.

  • Love it 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

 

Gespaltene Persönlichkeiten scheint es in diesem Forum öfter zu geben. Vielleicht ists ja wirklich Zufall. Mir ists schnuppe. Ich antworte einfach mal, haben ja alle was von. 
 

Mir war und ist mein Nick völlig egal. Wenn ich geahnt hätte, dass das zu einer Diskussion führt, hätt ich mich auch Hans Muff oder Nikolaus oder xyz genannt. Also nochmal für alle:

 

Mit Axion0815 habe ich nichts zu tun, wir sind weder verwandt, noch verschwägert und kennen uns nicht. Mein Nick hat mit seinem nichts zu tun, es handelt sich um zwei völlig verschiedene Personen. Wenn ein Moderator die beiden Nicks zu ähnlich finden sollte, dann kann er mich gerne in einen beliebigen anderen Nick umbenennen.

 

Zu Deiner Erklärung, herzlichen Dank. Ich wusste beispielsweise nicht, dass Fullnotes die Transaktionen prüfen und dann in den Mempool stellen. Ich dachte, die Miner würden alles alleine überprüfen, ausrechnen und hashen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Meine Vorgehensweise war folgende.
 
Electrum

  1. In Electrum eine neue Wallet mit neuem Seed angelegt.
  2. Alle BTC zu einer neuen Adresse in die neue Wallet senden. 
  3. Fertig.

Die BTC sind mit genügend Bestätigungen in einem Block NACH dem Splitt..
Die BCH sind noch immer in dem Block VOR dem Splitt.
 
 
Wenn ich dann irgendwann die BCH versende gehe ich genauso vor (wobei das eigentlich nicht mehr nötig wäre, denn jetzt kann mit den BCH nichts mehr passieren). 
 
Electron

  1. In Electron eine Wallet mit dem alten Seed anlegen, ODER die Private-Keys mit Guthaben importieren.
  2. Eine neue Wallet mit neuem Seed angelegt.
  3. Alle BCH zu Adresse(n) der neuen Wallet senden. 
  4. Fertig.

 
Man muss bei (diesem Fork) nichts mit (neuen Coins) mischen oder dergleichen.
Das wichtigste bzw. der beste Schutz ist, wenn man alle Coins nach einer Fork, an sich selber[1] sendet. Dann kann nichts passieren. 
 

bavarian hat es schon ausführlich erklärt, aber ich probiere nochmal die Replay-Attacke in Kurzform zu erklären:

 
Das Problem einer Replay-Attacke ist folgendes.

Da Transaktionen an sich, in beiden Chains gültig sind (TxIn im UTXO, Signatur gültig ...), kann ein "Böser Bube" hergehen und die Transaktion einfach kopieren, weil er sich somit die Transaktionsgebühr "erschleichen" könnte.

Das eigentliche Problem einer Replay-Attacke ist, die anderen Coins werden dabei auch dem Besitzer übertragen dem die Empfangs-Adresse gehört.

Deshalb ist es das beste, alle Coins nach einem Fork zuerst, an sich selber zu senden[1].

Fals dann eine Replay-Attacke stattfinden sollte, ist man wieder selber der Besitzer der Coins, man verliert in diesem Fall "nur" die Transaktionsgebühr.

 

Bei diesem Fork haben die BCH-Entwickler aber einen Replay-Schutz eingebaut der das verhindern soll, bzw. soweit auch tut.

 

 

[1] Beide Coins sollten am ende auch verschiedenen Adressen liegen.

Bearbeitet von c0in
Link zu diesem Kommentar
Auf anderen Seiten teilen

dein Punkt b ) ist das Problem. Wenn man sicher ausschließen könnte, dass BTC-Nodes nicht mit BTCC-Nodes kommunizieren können, können auch keine Transaktionen doppelt ausgeführt werden. Wir hätten nur mehr  das Replay Problem alleine (= Angreifer fängt Transaktion aus BTC-Node ab und injiziert sie in BTCC-Node --> Coins sind weg). Das ist unwahrscheinlich aber möglich. Wenn der neue BTCC-Client bei exakt gleicher Transaktion, also, wenn man genau die gleichen Inputs und Outputs und Coinwerte, Gebühren etc. eingibt, eine andere Signatur erzeugt (Stichwort: Salt), dann ist das Problem m.E. nach gelöst. Es sei denn ich hab noch irgendwas außer Acht gelassen, was gut sein kann.

 

Ist zwar eh schon fast vorüber das ganze, aber das interessiert mich noch.

 

 

Folgendes verwirt mich mal wieder.

Du schreibst: "Wir hätten nur mehr  das Replay Problem alleine (= Angreifer fängt Transaktion aus BTC-Node ab und injiziert sie in BTCC-Node --> Coins sind weg)"

 

Folgende Annahme: Die BTC werden auf eine neue Adresse gesendet die einem selbst gehört. Natürlich nach dem Splitt.

Wenn der Angreifer die TX ins andere Netz injiziert, landen die BTH (BTCC) doch auch nur wieder auf meiner Adresse dann halt in der BTH-Chain. Die TX selber kann er nicht zu seinen Vorteil ändern. Er hat sich dann nur die Gebühren erschlichen. 

 

Warum meinst du die Coins wären weg?

 

Selbst wenn ich z.B. in einem Onlineshop bezahle, hätte dann halt der Onlineshop die BTH zusätzlich, die er mir halt wieder zurücksenden soll. 

Bearbeitet von c0in
Link zu diesem Kommentar
Auf anderen Seiten teilen

Es sollte vielleicht besser ... nur mehr Replay-Attacke Problem ... heißen, um zu verdeutlichen, dass auch böse Buben im Spiel sein können. Wenn du an deine eigene Adresse sendest ist alles gut, dann kommen die Coins natürlich minus der Gebühren wieder bei dir an, hab ich irgendwo oben auch geschrieben. Wenn du vor dem Coin-Splitting an eine fremde Adresse schickst bspw. dein genannter Online-Händler, dann hat nunmal er die Kontrolle über BTC und BTCC, weil seine Adresse --> sein Priv Key. Klar, wenn es ein netter Händler ist und er den Split macht und dir anschließend die anderen Coins wieder zurück überweist, hast halt Glück gehabt, wenn nicht  --> Coins weg. Muß ja auch kein Händler sein. Kann ja auch irgendwas anderes sein. Z.B. ne ICO Sammeladresse oder ne Einzahlung auf ne Börse, die offiziell kein BTCC unterstützt etc. Diese Empfänger könnten alle im Anschluß selber splitten und die Coins klauen.

 

Im Falle der BTC Cash Fork ist es ja jetzt einfach gewesen, da es eben diesen eingebauten Replay-Schutz gab und man muß sich eigentlich keine großen Sorgen machen. Aber wer weiß was bei dem Segwit -> 2x Fork passiert. Da wird es vielleicht keine Protection geben. Also besser safe than sorry.

Bearbeitet von bavarian
Link zu diesem Kommentar
Auf anderen Seiten teilen

Danke dir,

... ja klar bei einem neuem Fork sieht es wieder ganz anders aus.

Mir ging es nur um die harten Worte, "Coins sind weg". Das wichtigste ist, die erste Überweisung an sich selbst zu schicken, dann kann man nichts verlieren.

  • Love it 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...

Wichtige Information

Wir haben Cookies auf Deinem Gerät platziert. Das hilft uns diese Webseite zu verbessern. Du kannst die Cookie-Einstellungen anpassen, andernfalls gehen wir davon aus, dass Du damit einverstanden bist, weiterzumachen.