How to protect the early stages of a proof-of-work application?

Question

For a given cryptocurrency or other blockchain application, proof-of-work provides intrinsic security in the algorithm itself that makes it unlikely that someone can attack the network unless they have more than 50% of the computational power of the network under their control.

This makes sense and works once the network has a considerable size, but every network has to start somewhere, and when a new application is born and the number of miners is still very small, it would seem very easy to outpower the network to insert fraudulent transactions and still be the longest chain of blocks.

Is there a way to mitigate this risk?

Answer 1

... insert fraudulent transactions ...

No, fraudulent transactions and blocks containing them are rejected when nodes follow the consensus rules.

There is a greater risk of chain reorganisation, meaning miners who successfully mined a block may not eventually have the reward for that when their block is no longer part of the longest chain.

The great risk of a 51% attack is that the attacker could outpace the rest of the network to assert that the attacker's version of the blockchain is longer, re-writing history with valid transactions and claiming block rewards, or undoing their own transactions when re-writing history by spending the utxo's back to themselves first, making their previously valid transaction seem like a double spend, for example, and stealing from a merchant.

To protect a new proof-of-work application it is only necessary that the work is reasonably distributed. For example, in the case of a Bitcoin full clone the same ASIC miners would be valid, however, the cost-for-benefit would be very low initially and so an attacker must ask, what benefit do I derive?

Answer 2

I don't think there is a risk of this happening because there would be very little incentive for someone to insert fraudulent transactions. Bitcoin has achieved success and is a significant store of value so there is huge incentive to launch 51% attacks against it but because of the size of the network and the amount of honest miners it has not happened yet. So, in my view until a cryptocurrency achieves a significant value or use it has no risk of fraudulent activities and by the time it reaches a value that makes it worthwhile to hack then the network is too large to launch attacks against it.

Answer 3

Yes, you are absolutely right. This can happen! Which is why it's very important to use a proof of work algorithm that is centralization resistant. In other words ASIC/mining-whale attack resistant. In other words come up with a novel proof of work which can only be mined on CPU's (single entities not entire pools) or GPU's. This is not an easy thing to do and one of the coins which has done this very well is Biblepay. There are of course other ways to do this like adjusting the difficulty and other features but nothing as good as a great POW algorithm

Answer 4

Yours is a valid question, even though you can't include fraudolent transactions in a environment where the witness nodes are honest.

Early attacks on blockchains are a thing and already happened (CoiledCoin for example), and the biggest threat in such attacks is that attackers willingfully lose their money in order to sabotage the newly created currency.

Risk mitigation depends on how much the system is decentralized, adjusting the difficulty so that the attacker wastes lot of resources on computing the PoW (thus this would be giving up system availability for a while). One can even think to ask other mining pools for cooperation to keep the hashing power uniformely distributed during the early stages of a new cryptocurrency.

Answer 5

1. Use SHA256 : Force the attacker to think whether its worth their time loosing bitcoin in attacking you
2. Publicize : You need as many people to mine since the start as possible
3. Ponder why you are asking this question : If the product you built is truly decentralized(and not for your profit) and has utility, don't worry about it dying. The code cannot die. Give it a few years and somebody will reboot it and will do what it was meant to do, out there in the world.