Bitcoin Forum

Alternate cryptocurrencies => Altcoin Discussion => Topic started by: minerapia on August 09, 2013, 10:10:48 PM



Title: [ANN] DEVS, read this, You're code is prolly vulnerable to this (a type of 51%)
Post by: minerapia on August 09, 2013, 10:10:48 PM
While doing stuff with powercoin I found something dubious in the code (main.cpp)
Code:
if (vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees))
that line checks that the block send to you, hasnt bigger subsidy that it's supposed to be.  Now what this allows is to make client which subsidy is, say
[orginal subsidy] - 0.0000001.

This creates situation where hacked client only accepts its own shares, but the unhacked clients allow both unhacked and hacked shares. Now if blockchain generated by the hacked client is at any time longer than the blockchain of unhacked ones it naturally takes order. So you can constantly have chance to override every block created with PoW if you have 51% of the network hashspeed.

Thus allowing ppl with 51% mine each and every block.
Situtation is somewhat equal with hybrid PoW/PoS coins, the race is just between the PoS blocks.

btw. I changed that greater-than to to equal and ran lvl 6 checks thru blockchain and didnt find any invalidated blocks because of it.


Title: Re: [ANN] DEVS, read this, You're code is prolly vulnerable to this (a type of 51%)
Post by: digitalindustry on August 09, 2013, 10:15:22 PM
Thank you for this info - I'm going to check it out , i oft thought that many of the "coin makers" would write flaws into the code at various spots, some of the most notorious have already done so obviously .


Title: Re: [ANN] DEVS, read this, You're code is prolly vulnerable to this (a type of 51%)
Post by: markm on August 09, 2013, 10:20:29 PM
I do not understand what you mean.

You are allowed to mint less coins than the limit, that has always been the case, but you cannot mint more.

There is nothing wrong with mining a fraction less coins than normal, it has always been allowed way back since bitcoin was invented.

Also people with 51% have always been able to do 51% attacks, so nothing new in that part either.

-MarkM-


Title: Re: [ANN] DEVS, read this, You're code is prolly vulnerable to this (a type of 51%)
Post by: minerapia on August 09, 2013, 10:22:40 PM
Minting fraction less coins than normal leaves 49% of miners empty handed (if guy minting fraction less has 51% of hash rate). Thats the problem.


Title: Re: [ANN] DEVS, read this, You're code is prolly vulnerable to this (a type of 51%)
Post by: digitalindustry on August 09, 2013, 10:24:40 PM
MarkM is your other iteration Hazard ?

: D

jokes.


Title: Re: [ANN] DEVS, read this, You're code is prolly vulnerable to this (a type of 51%)
Post by: markm on August 09, 2013, 10:26:27 PM
Rejecting blocks that mint full amount is actually a less bad 51% attack though than simply rejecting all blocks you didn't mine yourself, though in practice it probably ends up being the same thing since it is not likely anyone else will be mining less than the full amount.

So really I still don't see how it is in any way new or interesting, it is maybe just an example of a simple way of implementing in your code a method of rejecting blocks you didn't mine yourself.

-MarkM-


Title: Re: [ANN] DEVS, read this, You're code is prolly vulnerable to this (a type of 51%)
Post by: minerapia on August 09, 2013, 10:32:31 PM
Rejecting blocks that mint full amount is actually a less bad 51% attack though than simply rejecting all blocks you didn't mine yourself, though in practice it probably ends up being the same thing since it is not likely anyone else will be mining less than the full amount.

So really I still don't see how it is in any way new or interesting, it is maybe just an example of a simple way of implementing in your code a method of rejecting blocks you didn't mine yourself.

-MarkM-


Difference here is that:
a) it really simple to implement (and fix) (oh well ok, its not hard to code client that just doesnt accept blocks from network either)
b) this creates thousands of mini reorganizes instead of one huge, so its harder to detect (its not hard to code client to refuse to reorganize more than amount of confirmations needed for "valid" transactions, thus preventing double spend until checkpoints are fixed etc...)