first we had one category of attack related to 51%, other can occur and possibly to a lesser extend have occur that we just not have been seen as it’s small disruption not major (I suspect some pool have been time warp during 51%, but this can’t be confirm (I just have 2-3 weird coincidence of weird times)so look t it later if needed). but I think we should look at 51% attack as this is the most concerning one at the moment.

first 51% occur on low hash rate this is the pre condition (how low is a big question at first I said the time indicate block at 6 min at 188 diff for 2.5Gh/s from the attacker, but he proves after he manipulate the time so need to take the difference between the previous block and next block found by non attacker divided by the number of block from the attacker in it and alternate chain to find out the real time between blocs so his real hash rate, even so this would be his minimum)

for the attack nothing can warn about it, absolutely nothing can detect it before it is done at the moment. as releasing 6 blocs to invalidate 5 from legitimate chain can occur instantly. the attacker hold and release all at the same time or gradually if he want.

we have misbehavior that occur before or during, but are not needed for the attack.

• big spending (will be double spend and erase in the new chain) this is a pre-condition
• invalidating block with recent time stamp with older blocks

[b]so invalidating more then 2 blocks in one reorganisation or more then 3 time one in 10 block are what can be the absolute way to detect 51% attacks, can occur once or twice a year for network issues.[/b]

Bitcoin on blockchain.info has a very nice display of split. you will see that for bicoin no longer orphan chain then 1 block have occur since march 25. you can also see the very long split from the incompatibility between 0.7 and 0.8 version on march 12. (orphaned is on the right side, red X is end of the orphan chain --> means goto next block)
http://blockchain.info/orphaned-blocks

you can do this manually in the explorer by clicking next or previous(depending where you start and where you want to look) on a block and any next with 2 entries is a split, the top block is the chain the second the orphan. if you click the orphan and he has no next the orphan chain is 1 long and has ended(usually normal). if it has a next then same process. if you get 4 or more in the orphan and are after block 34000 in the chain of feathercoin send me a PM I will analyse it with you as you probably found something. As far as I know none occur after 34000. I check mostly every day many blocks (between 100 and 500) but my time is limited and 500-600 every day is a bit too much block to check all manually for the time I have. (I also check other things but will not disclose it so it can still be used to help my manual process until something is in place to detect or better prevent it from happening)

[quote name=“Bushstar” post=“26451” timestamp=“1377676845”]
Gangsters can kidnap me and chop my fingers off but I would not be able to checkpoint their blocks. That would be an unpleasant misunderstanding. The only control I have in the software is how deep the checkpoint is. I cannot remove existing checkpoints in the system.
[/quote]

for remove it’s absolutely true.

for checkpointing other blocks, unfortunately that is true only with unmodified code in real network. You have the private key to checkpoint, this is what in fact can make a checkpoint. so a modified or isolated checkpointer can checkpoint any block [b]after[/b] the last checkpointed block. So it can not checkpoint some block in a chain(not seen because it’s isolated or ignore via code change) and then checkpoint another chain block orphaning the first chain without checkpoint (i’m not sure what would happen if checkpoint on both conficting chain would be send. )

Nice this sound good. I’m happy to see no real damage seems to have been done. :) :) :)

For the records I send a message to Bushstar with preliminary info and he tell me to put it public on the forum, more person can then look at it. So it was!
I had to make those public after I found them. I can’t find if damage or not has occur by looking at block chain. so i say: can be real damage or not.

just a small addition to Bushstar description:
[quote]A typical 51% attack tries to reverse transactions. To do this someone generates their own blockchain separate from the network, then they spend their coins on the genuine network but not on their own. After the coins have been spent they use their 51% hash power to get the network to accept their own blockchain where the coins have not been spent. The effect is that the transaction where they spent their coins, disappears from the network entirely.[/quote]
if the transaction where he spend the coins had been accepted with low confirmation number by party A for an immediate irreversible good. the result would be send by A and go to the attacker but the transaction form the attacker would disappear from the blockchain and A will not get the coins. so high number of confirm is a must.

One pretty technical questions: if I add an orphan block now at 33001 orphan block do it will be accepted as orphan in the orphan chain or is the “11 block means time” use to accept block would prevent this?

here in attachment you will find Ghostlander simulation with a more agressive hashrate change vs diff that don’t converge. anything without damping oscillate. 100-500 or 126/504 seesm to be the good choice with .25 or possibly an even more aggressive damping

[attachment deleted by admin]

I made a simulation but have no time to make more for now,

it’s a work in progress, copy of sheet1 with graph on sheet 5 are the latest test, as far as I see it 20-126-504 damping .25 seems better as 126-504 has a reapeat every 126 that seems exploitable if you throw then stop some hash at well choose point.
[url=https://docs.google.com/spreadsheet/ccc?key=0ApYFJvIJozEwdEJla3d2M1NCXy1XYXJCNUJPZVFzYVE&usp=sharing]https://docs.google.com/spreadsheet/ccc?key=0ApYFJvIJozEwdEJla3d2M1NCXy1XYXJCNUJPZVFzYVE&usp=sharing[/url]

all this seems ok, i have 2 comments
[quote]the third thing to do is a faster retargetting with a better averaging. 9% difficulty limiter over 126 blocks is a good choice in general, but 1% over 20 blocks (~30 minutes) seems better. As for averaging, my choice is a combined average of the past 126 and 504 blocks with 0.25 damping as it seems to do really well.[/quote]
change using longer sampling usually gives some weird effect as pre-last change is reused and is likely to make he next go the opposite way as the new state. But the 1% can possibly make this safe, I don’t have time to simulate that. but from what i see from FTC and the 2-3Gh/s switch from a pool switcher(not multipool only 1G). the switch to one side to the other is instant and can even occur back and forth depending on price 2-3 times in a 126 blocks . You can’t get switcher out you need to make sure you play with them nicely without starving yourself because of history. i wouls try to put 10M- 1G on a 0.5 diff switching in a simulation and play with 1-2 change to see the effect. the damping will probably do nothing in this case as damping would need to be an order of magnitude more , but that would make the coin too much irresponsive.

[quote]What comes to the block chain protection agaisnt 51% attacks including time warps, we need to reduce the future time limit from 2 hours to 30 minutes. nMedianTimespan has to be increased from 11 to 19 blocks accordingly. [/quote]
depending on ACP depth i would add a bit more then 19 as even with 51% you are likely to get time warp with 51% without orphaning as PXC is low hashrate on normal condition.
so the 30 min in future can be used to get more then 10 blocks in future and keep it on attacker control as other block would not enter.

for past i suggest you add also a max past from the any of the most recent valid block. (not just the last one)depending on ACP depth you can have to trick it a bit as to get any valid block on any chain. so orphaning block under the ACP range would not allow to place past too far. ACP at 1 makes no orphan so it would work great with only top but if 3(like FTC) you can still 51% time warp the past(would need keep a precalculate queue of block so can orphan at will as soon as they arrive). so the only way to max past time allowed is to include orphan chain.(its now decribe so now someone will try it, but FTC is possibly safe for now as long as it stay over 3Gh/s. it’s not the case of PXC)

here you will find a work in progress version. feel free to enhance it, I will continue the transactions part tomorrow probably

[url=https://docs.google.com/document/d/1pVwRTIayb6aojcU435ic6d8tgd1KrP9qG91uJf0pgEc/edit?usp=sharing]https://docs.google.com/document/d/1pVwRTIayb6aojcU435ic6d8tgd1KrP9qG91uJf0pgEc/edit?usp=sharing[/url]

2.5 minutes is the target. the time vary for each search with an average of 2.5 minutes. so each period (2016 for Bitcoin and Litecoin, 126 now for Feathercoin) an average is calculated. and applied to adjust the difficulty to get the 2.5 minutes.

Bitcoin and Litecoin And Feathercoin at start had a basic formula. that can be simplified as (1+ (delta time deviation/target) )* difficulty = new difficulty. this works when you have a steady and small change in hashrate. (the % is limited by a min and a Max on ) so 2.4 minutes would give (1+(-0.1/2.5))*difficulty= 1.04*difficulty

so if time is lower the 2.5 minutes diff will increase and if more then 2.5 diff will decrease.

actual FTC to make change a bit slower for hash rate jump for coins hoppers (delta over 126 + delta over 504)/2*0.25 *difficulty this is done every 126 blocks.

so time between 2 blocks is mostly never exactly 2.5 minutes. But it always try to get to that number. if you get the average of last 1000-1500 blocks you will find we are pretty much on it. With LTC retarget to lower diff some hours ago we will have longer time and diff will go down a bit for next day. we should be around 2.5 minutes tomorrow and stable at 145-150 diff and in 2.5 days when LTC retarget again we will probably get pretty fast to 1-1.5 minutes and back to 175-180 difficulty shortly after :(

for the one saying the diff is broken. i post yesterday that diff will go up as LTC retarget big time so they lost 13% of hashrate so we got some and 170 will probably be the diff for next 3 days unless price ratio between LTC and FTC and to a lesser extend to other coin change much. so this is mostly normal.

in another idea:

i have look at the block chain and something is pretty weird. at some place we got ~15 min between blocks, this can happen, but they occur in short period of time and around the block are pretty fast. with acp fork lower then the last checkpoint are remove from chain so it’s difficult to say if someone try to trick the system.

one thing i have seen is that most block are found very fast and then we got very long block like 10-15 min. in both case they are spread between the 6-7 usual address that found blocks and not seems to have heavy single multi-pool address in them ( many from coinotron and wemineFTC, i have not search who are the other address exactly). the probability don’t follow the “luck” distribution we should have. we find block below 2 minute or over 10 minutes and very few in middle so something is weird. it can be just a weird probability run, but seems to occur too much to be just a: it can happen. I already note that a month ago, but I have no idea what is happening still searching, but mostly no time.

so far, I also found that around those time my client receive weird message block that fail the diff check, Calerts and transactions refuse for not enough fee by the client:
[code]ERROR: CTxMemPool::accept() : not enough fees 4ba6269fa2273e1f6bb295e2fcc9c650d6ac63847443c19c68f61145b9a04cfe, 1000000 < 2000000 [/code]but the transaction is in the chain

one multi-ppol address is:
6mLMVznd9xav2DPZsrL5whSJ9hjA95i2rw

Ok, I’m late to the tread, sorry busy in my life.

the faster we adjust to hash power input the easier a 51% will be to do as more mining means less profitability so profit miner goes away so you get Loyal vs attacker. if hashrate is big enough to keep diff high enough profit miner are out of the equation until the end of the attack. so in actual condition with .00034BTC/FTC a constant 6Gh can keep the diff at ~200 and profitability in the bottom list as we are at 138 diff. so a 51% of 10000 block would be possible. so number of confirm just make it more time but 10000 confirm is just not a valid option.

so difficulty retarget changes can help a bit, but would not solve the issue :(

one note the attacker get coins for mining if that don’t destroy too much FTC and he is not too much on the unprofitable side he will get a mining revenue that is nearly fair if this mining farm is already used for mining. so the cost if the attacker has the mining farm already is FTC price- usual mining coin price and he get what he benefits from the 51%(double spend, FTC rep down, etc.)

in my opinion POS in most form I have looked at would lead to another form of possible 51%

• consume coin day: i keep a lot of coin until i need to spend a lost of coins day for my 51% attack
• simple coins own and online: someone with large money just hold a lot and make the vote, most big wallet are offline for security reason so 1% should be enough (we know that more the 1.5M FTC was involve in previous attack)
• etc.

in fact if a distributed attack resistant concensus method is found the mining as we know would be useless(can be another form of mining). but i don’t know one

paxos is a very useful distributed voting, but it lacks one big thing for coins the notions of attacker node that is one of the problem of coins.

someone can setup millions of voting nodes to say yes so win the concensus but those node are attacker node. coin own in POS is a way to minimized this and replace it by who own more coins. the actual POW is who work hard enough to find the solution.

LTC is going by where FTC have go in may, they will need to adjust the retarget and then probably need to get ACP as some big multipool would be able to 51%. so LTC the safe would not be so safe.

Multipool are bad for coins when they becomes bigger then the coins they mine. for now most of the time they play with 42 and now doge. (this explain a big part of LTC diff drop), but 42 is now less profitable and doge is going that way too. so FTC will probably get more steady hash rate soon as LTC just retarget back to ~3300 diff.

in fact Scrypt mining has a finite mining power that is just divide between coins, multi pool just switch portion of the hash power fast from one coin to another. theyare their and many miner are just mining for profit so unless they really feel the bottom line lost on profitability they will continue to use multi-pool as they just want money(they probably sell BTC for fiat just as fast as the multi-pol swith from FTC to BTC for them)

the FTC retarget is making a good job in my view. it’s not perfect but also leave many problems/attacks of very fast retarget away from the coin.

they say it’s a failure it was probably not they get all coin from 1.1k to 8k in the 4-5h prior to the “disclose pump coin name” and sold many at high price as many saw the yesterday pattern of pre pump and compete with them to buy, but was buying on already inflate price (another possibility is a whale smarter then them got all their money ). I see it this afternoon but was away at 19h so can’t attend the show. finding the coin was so obvious as it was the coins always moving on cryptsy with starcoin between 15h and 19h.

seems that the synccheckpoint was loaded from the DB in DB.cpp and initialised at load of block chain via ReadSyncCheckpoint. this code is relovatd in main.cpp in 0.8.5 but seems to not load the checkpoint so the checkpoint is not initilised and stay at 0

[quote]
Feathercoin version v0.6.4.4 (Sep 21 2013, 08:46:22)
Startup time: 11/21/13 02:33:20
Default data directory C:\Users\…\AppData\Roaming\Feathercoin
Used data directory C:\Users\…\AppData\Roaming\Feathercoin
Bound to [::]:9336
Bound to 0.0.0.0:9336
[b]Loading block index…[/b]
dbenv.open LogDir=C:\Users\…\AppData\Roaming\Feathercoin\database ErrorFile=C:\Users\…\AppData\Roaming\Feathercoin\db.log
LoadBlockIndex(): hashBestChain=c479e1f97c80d2d83a46 height=110649 date=11/09/13 02:41:38
[b]LoadBlockIndexDB(): synchronized checkpoint 42bb31183d1437566b7cedfa0f120d616975f2b4462372af681859cf77528516[/b]
Verifying last 2500 blocks at level 1[/quote]

from new main.ccp you should have one of the message

[code]// ppcoin: load hashSyncCheckpoint
if (!pblocktree->ReadSyncCheckpoint(hashSyncCheckpoint))
printf(“LoadBlockIndexDB(): synchronized checkpoint not read\n”);
else
printf(“LoadBlockIndexDB(): synchronized checkpoint %s\n”, hashSyncCheckpoint.ToString().c_str());

[/code]
my guess is that the DB upgrade have not move the syncCheckpoint to the new DB so the load fail.
if DB has no checkpoint save should we just initialise with genesis block (as it’s the only block on initial load)?

can you add me to the repository. user: groll

I will take a look but as usual my time is limited.

you are right i have not really take care to verify too much the non damped one as they are not working well and yes the 20 is broken by the formula and i was screwed as i calculate on time and you on hashrate so moving the Z column makes some row going to a different value than others as they have different formula, representing with an expected value on Z the same reality. I played a lot on A-Y especially on U-Y to see the effects before and send a working one with FTC values. but this altered futur is good to see what happen also

with 2% retarget every 20 and 100/500 sampling more damping can also work well .1 for example is fine as it’s going to retarget often so moving a bit more slowly would work great even if large change occur. as if larger then 20% occur it goes to max and if lower then it just move 1/10 of the error each time. the error is calculate on 5 and 25 sample so a 20 blocs deviation would be include several time in the calculation. it’s the reason we see some echo of the past in the curves.

I like the 20/100/500 with .1 damping as small immediate effect of change can be seen and the overall effect of 20 if completely off is minimized by both other sampling and the damping. my second choice would be 100/500 with .1 but anything in .25 or more damping (

here in attachment you will find Ghostlander simulation with a more agressive hashrate change vs diff that don’t converge. anything without damping oscillate. 100-500 or 126/504 seesm to be the good choice with .25 or possibly an even more aggressive damping

[attachment deleted by admin]