Wie schütze ich mich vor Verlust von Bitcoins durch einen Replay Angriff?

[MoinCoin]

Ggf. ist das Thema erstmal verschoben:
Bitcoin Cash implements strong replay protection

https://www.bitcoincash.org/replay

Allerdings war der commit bei BitcoinABC nur auf P2P Ebene und nicht auf Consensus Ebene.
Damit wäre es immer noch unsicher, ob ein Replay Angriff erfolgt oder nicht.
Also mal abwarten.

[raay]

Ich versuche es mal etwas grafischer:

Danke jetzt hab ich es.

Der Trick ist, dass die Börsen gezwungen sind sich selbst vor Replay Angriffen zu schützen, weil sie sonst viel Geld verlieren könnten.

Ja so verstehe ich es auch , denn damit ist mal relativ klar wie "leicht" man zu Taint kommt.

[shorena]

-snip-

Erstmal danke für den schönen Beitrag.

In einem Block-Explorer für Bitcoin und einem für Bitcoin Cash sollte man dann überprüfen, ob die Bitcoins tatsächlich Replay geschützt sind.
Das erkennt man daran, dass die Kombination aus den Inputs für die Transaktion auf der anderen Kette unmöglich ist.

Reicht das? Kann ich als Angreifer nicht die jeweilige Signatur für den Input nehmen der auf meiner Chain gültig ist und mir daraus ...

Ich denke ich habs selber beantwortet. Nein, sofern SIGHASH_ALL benutzt wird, da die Outputs verändert werden... -> https://bitcoin.org/en/developer-guide#signature-hash-types

Es sei den die Adresse kann mir egal sein, muss sie mir bei einem Replay Angriff ohnehin, und ich schaffe es ausreichend Inputs zu sammeln um die nötige Menge an Coins zu sammeln. Muss nicht 100% passen, zur Not ist meine Fee halt höher/geringer. Ich werd da glaub ich noch ein bisschen drauf rumdenken müssen bis mir das klar ist. Gerne in die richtige Richtung schupsen.

[MoinCoin]

Ich denke ich habs selber beantwortet. Nein, sofern SIGHASH_ALL benutzt wird, da die Outputs verändert werden... -> https://bitcoin.org/en/developer-guide#signature-hash-types

Genau - Technischer Hintergrund: SIGHASH_ALL ist Standard für eine normale Transaktion bei Bitcoin und SIGHASH_FORKID ist Standard bei Bitcoin Cash.
Beide signieren alle Inputs.
Wenn sich ein Input ändert, werden die Signaturen ungültig und müssen neu erstellt werden.
Das heißt es reicht ein Input, den es nur auf einer Chain gibt (wird "Taint" genannt), für die Replay Protection.

Und der Input enthält ja nicht die Bitcoin Adresse - die ist also sowieso vollkommen egal für den Replay Schutz, sondern den Hash der vorherigen Transaktion (Transaktions ID) und welcher Output (Nummer) dieser Input in der vorherigen Transaktions war. Diese Daten werden dann von der Signatur geschützt.

Wenn man sich das ganze in Blockexplorern anguckt, sollte man meinen die Adressen wären viel wichtiger, aber tatsächlich sind diese nur eine Abstraktion für uns Menschen und werden auch dort nur genutzt, damit es anschaulicher ist. Tatsächlich bedeuten die Adressen nämlich nur, wie das Feld scriptPupKey im Output der Transaktion zu erstellen ist.

Danach ist die Signatur also nie wieder gültig, weil es die Inputs so nicht mehr gibt, auch nicht auf der anderen Chain.

[shorena]

Ich denke ich habs selber beantwortet. Nein, sofern SIGHASH_ALL benutzt wird, da die Outputs verändert werden... -> https://bitcoin.org/en/developer-guide#signature-hash-types

Genau - Technischer Hintergrund: SIGHASH_ALL ist Standard für eine normale Transaktion bei Bitcoin und SIGHASH_FORKID ist Standard bei Bitcoin Cash.
Beide signieren alle Inputs.
Wenn sich ein Input ändert, werden die Signaturen ungültig und müssen neu erstellt werden.
Das heißt es reicht ein Input, den es nur auf einer Chain gibt (wird "Taint" genannt), für die Replay Protection.

Ok, ich war mir nicht sicher ob alle inputs oder nur der spezifische für den die Unterschrift nötig ist signiert werden.

Und der Input enthält ja nicht die Bitcoin Adresse - die ist also sowieso vollkommen egal für den Replay Schutz, sondern den Hash der vorherigen Transaktion (Transaktions ID) und welcher Output (Nummer) dieser Input in der vorherigen Transaktions war. Diese Daten werden dann von der Signatur geschützt.

Wenn man sich das ganze in Blockexplorern anguckt, sollte man meinen die Adressen wären viel wichtiger, aber tatsächlich sind diese nur eine Abstraktion für uns Menschen und werden auch dort nur genutzt, damit es anschaulicher ist. Tatsächlich bedeuten die Adressen nämlich nur, wie das Feld scriptPupKey im Output der Transaktion zu erstellen ist.

Danach ist die Signatur also nie wieder gültig, weil es die Inputs so nicht mehr gibt, auch nicht auf der anderen Chain.

Bei der Adresse ging es mir um den Output statt um den Input. Danke.

[raay]

https://electrum.org/bcc.txt

[coinling]

OK also so wie ich das verstehe, kann ich nun einfach unmittelbar nach dem Fork meine Bitcoins mit Electrum oder whatever verschicken und da BCC replay protection hat, kann ich irgendwann später , wann immer ich will ein BCC Wallet runterladen und dort meinen private key von den Bitcoins die ich damals verschickt habe eingeben und damit BCC versenden ?
Und das ist 100%ig safe, also ich brauch sie nicht vorher zu splitten wie bei ETH und ETC ?


"How to redeem my BCC?
---------------------

BCC wallets will require you to import your seed or your private keys,
which can be exported from Electrum. Doing so will expose all your
Bitcoin funds associated with that seed to the BCC wallet you decide
to use.

Therefore, *after* the BCC fork, but *before* you enter a seed or
private key in a BCC wallet, you should move all your funds to a new
Electrum wallet, with a new seed. You will still be able to use the
old seed or private key with BCC, because BCC has replay
protection. Wait until your funds are confirmed in your new Bitcoin
wallet, before you enter the old private key in a BCC wallet. This
will protect your BTC funds from rogue/untrusted software."

[MoinCoin]

Das ist eben so safe, wie die BCC Software die man verwendet.
Warten wir erstmal ab, ob die Leute es geschafft haben das zu implementieren, was in der Spec steht.

+RATIONALE: To provide strong protection against replay of existing
+transactions on the UAHF chain, only transactions signed with the new
+hash algorithm and having SIGHASH_FORKID set will be accepted, by consensus.

Quelle: https://github.com/Bitcoin-UAHF/spec/commit/f6a3864428352ed6ad8988b7cd4017f3096f245f

Also ja - so wie es aussieht muss man sich keine Sorgen machen über die Replay Protection / Replay Angriffe.
Man braucht wohl kein "Taint" und muss nicht vorher splitten.

Im normalen Bitcoin-Netzwerk könnte es ggf. zu einer erhöhten Transaktionslast dadurch kommen, nach dem Hard Fork.