Reliable means of determining whether hashes are from 51% or real

[zerodrama]

We need to get accurate information from pools on the range and spread of their users’ hashrates.
We need to get a reasonable idea of when people joined pools.
We need to get a reasonable idea of when giant hashrate jumps occured.
We need to get a good idea of when blocks were generated.

[jeremiel]

[quote name=“zerodrama” post=“12260” timestamp=“1370853791”]
We need to get accurate information from pools on the range and spread of their users’ hashrates.
We need to get a reasonable idea of when people joined pools.
We need to get a reasonable idea of when giant hashrate jumps occured.
We need to get a good idea of when blocks were generated.
[/quote]

You can’t really force a pool on to a list but ask their permission(they could always block).
then the question comes down who determines a pools legitimacy?
Most pools have an api to pool from or at worst a get script to sift through the page for specific lines.

So a central webpage that pools specific general api data in a spreadsheet like format. Say every 5 minutes? Of course there will be a bit of discrepancy of hash power due to diff pools reporting at different times. what then becomes an acceptable level of variance?

where do you host this? What is the important values that need to be displayed?

Overall hashrate reported -------- totaled pulled pool hashrate for comparison
pool name — pool hash rate — # of active miners or workers ---- last block found —time since last block?

also list of primary contacts for those pools. This is just spit balling of course…

[groll]

[quote]We need to get accurate information from pools on the range and spread of their users’ hashrates.
We need to get a reasonable idea of when people joined pools.
[/quote]
miner in pool can’t make this. only the pool can do it (the pool operator or a hacker of that pool). so any info coming from the pool in that case will be irrelevant as it can be anything. since transaction need to be changed this is not possible using a legitimate pool you need to manipulate the blockchain

the info for the conterpart aka. from other pool can be useful to know what is their current status and what is our strength against an attack

[quote]We need to get a reasonable idea of when giant hashrate jumps occured.
[/quote]

the only way is time between blocks, hold and release can make this nearly impossible to notice as putting a 6 block where a 5 legitimate is and DDOS the biggest pool will make the 6 block similar to a regular 6 blocks (our attacker is more brutal but he seems to evolve slowly in his method so…).

I don’t have snapshot of the chain, but I think the first chain appear and then becomes orphan on an insert of the new fork chain probably already longer so 5-6 block are receive at the same time(note the attacker can release block that are n-1 from the first chain and just hold the rest until he really want to orphan it. so orphan chain is just one away from normal chain making it nearly legit). if you don’t account for any time modification the hash rate can be nearly the same as the real chain except in need to have 1 more block as it need to be n+1 to orphan the first chain.

timestamping the chain with the real received time of the block at this node can be a way to get to calculates the hashrate, but this will be false on legitimate fork as similar to the 51% the fork make an insert in bulk in the chain. so this should trigger alarms, but can’t block the chain.

the biggest challenge I think is a network split at the networking layer where some node are working in a chain and other on another, this should be merged and orphan one chain nearly transparently. in fact this is why 51% attack like this one can be done.

in todays network a natural 5 blocks forks should happen no more than once a year. so does not accepting to add to an orphan chain with length of 5 a possible solution. This will lead to a problem once a year that need to be address. I can look at some solutions if this seems promising if not i would not invest time to search this but I have 2-3 idea

note: the attacker can change address for every block and add some transaction in it to make it less easy to discover so those are not criteria we should use.

[quote]We need to get a good idea of when blocks were generated.[/quote]
time is a very interesting part, unfortunately the client can put anytime he want (from what I have read on bitcoin discussion) between the average of the 10 last block and now + error(not sure what this value is) so time just need to increment. no need to be consistent with the real time. in this case also timestamping reception can provide info on the block but hold and release will make them all appear in the same receiving time.

the timestamping is done locally so it can’t be used for anything in the protocol just as detection measure :( other node will not get the same timestamp, inserting this in the chain is irrelevant as the attacker can just trick the receive the same way as the actual timestamp.

forcing the use of a TSA (ANSI ASC X9.95 Standard)can prove when the block computation begins, but the overhead and having a free and reliable TSA service for the required amount of timestamps is probably not possible. especially that all miners will request it at the same time mostly for the block.