How to guarantee no risks of double spending

[manselr]

As we all known, Bitmain and Roger Ver have decide to create their own altcoin in Aug 1st. I want to be ready, so I got all of my coins on my local wallet where I control everything. I run a Bitcoin Core full node with the latest version.

When the split happens, how do I guarantee that I don't lose my coins? My plan is to dump BCC for BTC in whatever exchange has the most liquidity. I will probably wait some hours for things to stabilize a bit and see how the market reacts, I also don't want to be the first sucker to test if this even works with their own bitcoin.

Anyway, how to do this safely knowing you aren't spending your legacy-chain coins?

[achow101]

Bitcoin Cash has implemented two way replay protection so any transactions created with a Bitcoin Cash wallet (e.g. Bitcoin ABC) will be invalid to the Bitcoin network and anything created with a Bitcoin wallet (e.g. Bitcoin Core) will be invalid to the Bitcoin Cash network.

[cpfreeplz]

Bitcoin Cash has implemented two way replay protection so any transactions created with a Bitcoin Cash wallet (e.g. Bitcoin ABC) will be invalid to the Bitcoin network and anything created with a Bitcoin wallet (e.g. Bitcoin Core) will be invalid to the Bitcoin Cash network.

You just mean if any new address is generated after August first or any address generated on a bitcoin wallet at all will be invalid to BCC after August first?

I'm going to be dumping mine asap too, I will gladly be the first one to test the transactions .

[hexafraction]

Bitcoin Cash has implemented two way replay protection so any transactions created with a Bitcoin Cash wallet (e.g. Bitcoin ABC) will be invalid to the Bitcoin network and anything created with a Bitcoin wallet (e.g. Bitcoin Core) will be invalid to the Bitcoin Cash network.

You just mean if any new address is generated after August first or any address generated on a bitcoin wallet at all will be invalid to BCC after August first?

I'm going to be dumping mine asap too, I will gladly be the first one to test the transactions .

Not addresses, but transactions. Let's say you have 1 BTC at address 1Addr.... After the split, you have 1 BTC on the BTC network at address 1Addr... and 1 Bitcoin Cash on the Bitcoin Cash network, also at address 1Addr.... What this means is that if you were to have a transaction that spends 1 Bitcoin Cash to address 1Xyz..., a type of attack known as a replay attack would't be possible. A replay attack is an attack where someone copies your transaction exactly, and uses it on the other network. In this example, if the replay attack was performed (it can't because BCC has features to prevent it), then your 1 BTC on the Bitcoin network would also move to 1Xyz... (BTC address), even though you only intended to send BCC to 1Xyz...

[RedditMaster]

As we all known, Bitmain and Roger Ver have decide to create their own altcoin in Aug 1st. I want to be ready, so I got all of my coins on my local wallet where I control everything. I run a Bitcoin Core full node with the latest version.

When the split happens, how do I guarantee that I don't lose my coins? My plan is to dump BCC for BTC in whatever exchange has the most liquidity. I will probably wait some hours for things to stabilize a bit and see how the market reacts, I also don't want to be the first sucker to test if this even works with their own bitcoin.

Anyway, how to do this safely knowing you aren't spending your legacy-chain coins?

This might be the biggest altcoin dump in history. It is going to be hilarious. Who in their right mind would hold BCC when they could dump it for BTC? Makes no sense to me. lmao

[alani123]

As we all known, Bitmain and Roger Ver have decide to create their own altcoin in Aug 1st. I want to be ready, so I got all of my coins on my local wallet where I control everything. I run a Bitcoin Core full node with the latest version.

When the split happens, how do I guarantee that I don't lose my coins? My plan is to dump BCC for BTC in whatever exchange has the most liquidity. I will probably wait some hours for things to stabilize a bit and see how the market reacts, I also don't want to be the first sucker to test if this even works with their own bitcoin.

Anyway, how to do this safely knowing you aren't spending your legacy-chain coins?

This might be the biggest altcoin dump in history. It is going to be hilarious. Who in their right mind would hold BCC when they could dump it for BTC? Makes no sense to me. lmao

Surely some parties are interested in BCC's longevity but wouldn't risk much to maintain it as the monetary incentives are huge. Even bitmain has announced to drop support for BCC if the community shifts away from it.

[mamaya]

My suggestion despite some of the protections that have been put in place to avoid this, is to just let the exchanges split the coins for you rather than trying to do it yourself. That way your coins will already be on the exchange at the right time to dump and you don't need to worry about the technical aspects of it.

Just make sure you put it on an exchange that has already promised to credit you your BCC, bittrex is one that comes to mind for me.

[cpfreeplz]

Bitcoin Cash has implemented two way replay protection so any transactions created with a Bitcoin Cash wallet (e.g. Bitcoin ABC) will be invalid to the Bitcoin network and anything created with a Bitcoin wallet (e.g. Bitcoin Core) will be invalid to the Bitcoin Cash network.

You just mean if any new address is generated after August first or any address generated on a bitcoin wallet at all will be invalid to BCC after August first?

I'm going to be dumping mine asap too, I will gladly be the first one to test the transactions .

Not addresses, but transactions. Let's say you have 1 BTC at address 1Addr.... After the split, you have 1 BTC on the BTC network at address 1Addr... and 1 Bitcoin Cash on the Bitcoin Cash network, also at address 1Addr.... What this means is that if you were to have a transaction that spends 1 Bitcoin Cash to address 1Xyz..., a type of attack known as a replay attack would't be possible. A replay attack is an attack where someone copies your transaction exactly, and uses it on the other network. In this example, if the replay attack was performed (it can't because BCC has features to prevent it), then your 1 BTC on the Bitcoin network would also move to 1Xyz... (BTC address), even though you only intended to send BCC to 1Xyz...

Ahhh!! I never would have even thought of that but it makes sense. I guess that's why I'm not a bitcoin ( or BCC) developer. Thanks for the good explanation.

[yinoye]

Not addresses, but transactions. Let's say you have 1 BTC at address 1Addr.... After the split, you have 1 BTC on the BTC network at address 1Addr... and 1 Bitcoin Cash on the Bitcoin Cash network, also at address 1Addr.... What this means is that if you were to have a transaction that spends 1 Bitcoin Cash to address 1Xyz..., a type of attack known as a replay attack would't be possible. A replay attack is an attack where someone copies your transaction exactly, and uses it on the other network. In this example, if the replay attack was performed (it can't because BCC has features to prevent it), then your 1 BTC on the Bitcoin network would also move to 1Xyz... (BTC address), even though you only intended to send BCC to 1Xyz...

So this is a sort of prevention of double spending or loss of coins as a result of sending any of the btc to the wrong node ?

[yinoye]

This might be the biggest altcoin dump in history. It is going to be hilarious. Who in their right mind would hold BCC when they could dump it for BTC? Makes no sense to me. lmao

Somethings unknown could still be behind the scenes. Bitmain and Roger Ver will definitely anticipate the possible dump of BCC

[HCP]

So this is a sort of prevention of double spending or loss of coins as a result of sending any of the btc to the wrong node ?

No, it isn't related to "double spending". "Double spending" is an attempt to spend the same coins on the same network twice (usually, but not always, as a means of committing fraud).

It also isn't related to "sending btc to the wrong node"... this doesn't actually make any sense. You don't send btc to a node. You transfer control of BTC from one address to another address (Technially, it is actually transferring control from a private key to another private key, but for the sake of keeping things simple, we'll say "address")...

As BTC and BCC share a common history and (mostly) common technology... without replay protection, it would be simple for a person to take a transaction from BCC network and rebroadcast it on BTC network... or vice versa.

So, theoretically, if one currency isn't worth as much as the other (ie. 1 BTC = 10 BCC) someone could be like... "Hey, I see you have 10 BCC... I'll buy it off your for 5 BTC"... you send them the BCC, thinking you got a good deal (5x!!?! wooooo! )... they then broadcast this exact same transaction on the BTC network... and you suddenly find your 10 BTC has been sent to that person!

(Two-way) Replay protection, which is what has been implemented by the BCC devs, makes it so that a BTC transaction is NOT valid on the BCC network... and a BCC transaction is NOT valid on the BTC network. The result being that you don't have to worry about someone being able to take the coins from you unless you specifically create a transaction on that particular network.

[djeZo]

What about if transaction isn't confirmed yet (was broadcasted BEFORE fork at 12:20 UTC)? When does replay protection kicks in?

[HCP]

What about if transaction isn't confirmed yet (was broadcasted BEFORE fork at 12:20 UTC)? When does replay protection kicks in?

Given that the fork actually occurs at 12:20 MTP (Mean Time Past)... which is theoretically about 6 blocks AFTER 1220 UTC... it gets a bit tricky

The criterion for activation of the Bitcoin Cash hard fork activation is based on "Median Time Past", or MTP. This means that the chain split will not occur at exactly 12:20 UTC on Aug. 1st, but some time after.
 
MTP is a statistic calculated over 11 blocks, and trails behind wall clock time by about 6 blocks. This means that the last common block will be approximately the 6th block with a timestamp after 12:20pm. The block after that will be different on either chain.

If you broadcast the transaction, and it doesn't confirm before the fork actually occurs... (ie. the last common block or earlier) then it should NOT be included in the BCC network, as their miners/nodes should refuse the transaction as it does not conform to their rules... and should be regarded as invalid.

Just be aware that because the fork doesn't occur until some time AFTER 12:20 UTC... that if you broadcast a transaction at 12:19 UTC, there is a chance it will still confirm BEFORE the fork actually takes place and thus be present in both chains AFTER the fork.

[djeZo]

What about if transaction isn't confirmed yet (was broadcasted BEFORE fork at 12:20 UTC)? When does replay protection kicks in?

Given that the fork actually occurs at 12:20 MTP (Mean Time Past)... which is theoretically about 6 blocks AFTER 1220 UTC... it gets a bit tricky

The criterion for activation of the Bitcoin Cash hard fork activation is based on "Median Time Past", or MTP. This means that the chain split will not occur at exactly 12:20 UTC on Aug. 1st, but some time after.
 
MTP is a statistic calculated over 11 blocks, and trails behind wall clock time by about 6 blocks. This means that the last common block will be approximately the 6th block with a timestamp after 12:20pm. The block after that will be different on either chain.

If you broadcast the transaction, and it doesn't confirm before the fork actually occurs... (ie. the last common block or earlier) then it should NOT be included in the BCC network, as their miners/nodes should refuse the transaction as it does not conform to their rules... and should be regarded as invalid.

Just be aware that because the fork doesn't occur until some time AFTER 12:20 UTC... that if you broadcast a transaction at 12:19 UTC, there is a chance it will still confirm BEFORE the fork actually takes place and thus be present in both chains AFTER the fork.

Thanks, that was good to know, so we know how to schedule some payouts.