Topic: attacks on the blockchain (Read 776 times)

wow,

Thant's heavy!

It probably worth pointing out that you can easily protect yourself from a replay attack by sending all your pre-fork coins to an address that you control before spending them. This should be done on both chains at the same time. There is a small window where somebody may do a "mischief replay" on one of your transactions, but since you control the private keys to the receiving addresses on both chains you can easily recover from this.

Not on the same chain.  Each chain becomes it's own coin.  Coins from before the fork are effectively split into 2 identical coins (1 on each chain).  Coins spent on one chain can't be double spent on that chain, but if you don't manage your transactions carefully enough you can be forced to send the twin coins on the other chain to the same address on that chain.

Those that are technically aware enough can take precautions to prevent this, but the average user is likely to have a problem and not know it until it is too late.


A contentious fork is already likely to be pretty damaging.  Replay attacks are a known vulnerability with known methods of avoiding the problem.  They aren't likely to make it much worse.


I think both SW and BU are not great ideas.  They are each attempting to be "good enough", but they each have issues. I'm not sure if there is a good solution.  Perhaps we're about to discover that the whole cryptocurrency experiment is unsustainable.

You are saying that if bitcoin splits in two chains then we could literally double spend more than 16.3M BTC successfully and get away with it?

Wouldn't that destroy everything that bitcoin claimed to do and be?
Which one is better in your opinion, supporting SW and activating it and if we do then could we hard fork if it back fired and wouldn't that be the reasonable solution?

Oh! Thank guys. I understand it now.
สล็อต

Yep, so you'll know, but you can't do anything about it.


They don't need it.  The only thing you need the private key for is to sign the transaction.  You've already signed that transaction, so it's just as valid on the other chain.


Sure, but why would they?

@DH, after sending a transaction using old coins existed and generated prior to the block 460,000 couldn't either parties(nodes) be programmed some how to cross reference the both chains to see if a transaction is being double-spent? and how can someone send your coins from other chain without your permission if they don't have the private key?
Also miners could as well ignore all transactions and mine empty blocks for as long as it takes to sort things out correct?

Not quickly or easily.

Miners assemble transactions into blocks and then perform hashing on the header of the block to establish a proof-of-work.  The target value that establishes how difficult it is to find a valid hash is adjusted every 2016 blocks to make sure that with the combined hash power of the entire world it will take on average 10 minutes to successfully find a valid hash.

The chances of finding a successful hash for a block are directly proportional to the percentage of the hash power you have.  So, if a miner or pool controls 10% of the global hash power (leaving 90% for the rest of the world), then that miner would find successful hashes 10% of the time (and the rest of the world would find successful hashes 90% of the time).

Every node and every miner agree to always build on top of the chain that has the most proof-of-work (which in typical cases means the chain with the most blocks).  If a miner with less than the combined hash power of the entire world were to refuse to build on the longest chain, the whole world would simply ignore his blocks.  He'd be wasting his time and money since he'd never receive a spendable block reward.
 
As that miner approaches 50% of the global hash power, the amount of hashing the rest of the world is doing falls towards 50% (since, obviously, the sum of that miner and the rest of the world must be 100%).  At 50%, the miner (or pool) is producing just as much hash power as the rest of the world combined. They are finding half of the blocks and if they were to ignore all the blocks produced by everyone else their chain would grow at the same rate as the rest of the world's chain.  In the long run, this isn't enough to get ahead and therefore limits what they can change.

Once a miner has more than 50% of the global hash power, they will find successful hashes MORE OFTEN than the rest of the world.  As such, given enough time, they can start at any depth and build replacement blocks knowing that they will eventually pass up the chain everyone else is working on. When they do, the entire network will abandon their own chain and start building on top of this other, now longer, chain.  The higher percentage the attacker has, the faster and easier they can pull off the attack, but it becomes mathematically possible as soon as they exceed 50%, therefore it is commonly called a 51% attack.

Note that once a single entity controls more than 50% of the hash power, they can effectively shut out ALL other miners and mine 100% of the blocks.  This is because if any miner succeeds in mining a block, the attacker can simply ignore that block (and any blocks on top of it) and continue to build on their own blocks until they pass up the chain the other miner attempted to fork.  Since other miners can no longer generate any revenue, they will have no incentive to continue mining and will simply shut off their equipment.  This reduces the amount of "other" hash power on the network and makes it even easier for the attacker to maintain their attack (since they now have an even higher percentage of the remaining hash power).


Ok, lets create a hypothetical situation here...

Let us say that starting immediately after the 460,000^th block in the blockchain 70% of bitcoin users, miners, merchants, nodes, exchanges, hashpower, etc decide they want the maximum allowable blocksize to be 2 megabytes. For clarity, we'll call this "BitcoinNew"

Let us say the other 30% continue to run the old version of bitcoin that had a maximum allowable blocksize of 1 megabyte. For clarity we'll call this software "BitcoinOrig"

Miners using BitcoinNew software will find solutions to blocks 7 times for every 3 times that those using BitcoinOrig software do. However, BitcoinOrig software will not recognize blocks bigger than 1 megabyte as valid, so won't include them in their chain at all no matter how long the chain gets.

So, in this situation, a BitcoinNew miner can build a 1.5 megabyte 460,001^st block, and all the other BitcoinNew miners will build on top of it.  All the BitcoinNew users will see and accept these blocks.  Meanwhile, BitcoinOrig miners will simply ignore the 1.5 megabyte block as invalid. Since they see it as invalid, they don't recognize any of the blocks on top of it as valid either. Instead, they will build their own 460,001^st block that is 1 megabyte or less.

This means that at the 460,001^st block there will be TWO block rewards.  One that is only valid on the BitcoinNew, and another that is only valid on the BitcoinOrig chain.  The BitcoinOrig miners won't be able to get those transactions confirmed on the other chain and vice versa.

However, since the fork happened at the 460,001^st block, that means that BOTH BitcoinNew AND BitcoinOrig recognize block number 460,000 (and all the earlier blocks) as being a valid part of their own chain.  So if you have any bitcoins that you received in one of those earlier blocks, you can use them and get them confirmed in later blocks in either (or both) of those forks.

This is where the "replay" attack becomes a problem.

Lets say there is a merchant that says he is running BitcoinOrig and only accepts BitcoinOrig transactions.  You create a transaction spending bitcoins that you receive before the fork and transmit it to BitcoinOrig peers.  It eventually gets confirmed in a new block in the BitcoinOrig fork.  So far so good. Except, since that anyone that sees that transaction in the BitcoinOrig fork can now re-broadcast the exact same transaction to a BitcoinNew peer.  Since the transaction already has your valid signature on it, it will get relayed across the BitcoinNew network and eventually confirmed in the BitcoinNew even though you only intended to pay a BitcoinOrig with BitcoinOrig coins.  The transaction has been "re-played" on the other fork, which is why it's called a "replay attack".

The same can occur going the other way (you send BitcoinNew bitcoins to a BitcoinNew merchant, and someone replays that transaction on the BitcoinOrig network and into the BitcoinOrig fork without your permission.

Can anyone please explain what a 51% attack and what a replay attack are?

Also, I have been reading some news in regards to exchanges contingency plans, in case bitcoin forks, some exchanges are saying that they will not be trading BU if there are no mitigations to stop replay attacks. Can someone please explain this?

Thank-You in advance.