[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.

the attacker put his own transaction to roll back the orphan chain. so he needs to control what is put in the chain. [b]This is not possible if you just mine on a pool [/b] so he is not using a regular pool (the address used has no payout also that is the regular way for pools to operate, but not required). the only way a pool can do this is that the pool operator is the attacker or the pool is hack, in addition the pool need to get the additional hash rate to do so. But as far As I can see it’s not the case. pool at 51% is a potential problem. If a pool operator use it to reverse transaction this than becomes a problem.

we will hit the retarget soon we then will see what happen as we go back to 94 difficulty, but price will still make mining profitable at this level. 94 and 2.8Gh/s should keep us near safety.

pool hash ratio should be looked at, but is probably not a big concern as the spread seems to be ok I have seen 1.7MH/s of the actual 3M in 4 pools with the highest as .747M so it’s ok.

As the attacker is probably an alien node to been able to introduce his own block pool is in fact our best defence, don’t put restriction on them unless we get hard reason to do so.

[quote name=“d2” post=“12437” timestamp=“1370875600”]
I’ve sent an email to wheretomine asking why it was removed, perhaps they will re-add it.

I’ve made a post in the CoinChoose thread on bitcointalk requesting re-add. https://bitcointalk.org/index.php?topic=152515.msg2430715#msg2430715
[/quote]

Cheers d2

[quote name=“Taxidermista” post=“12302” timestamp=“1370858330”]
[quote author=zerodrama link=topic=1463.msg12293#msg12293 date=1370857660]
[quote author=erk link=topic=1463.msg12281#msg12281 date=1370856205]
Just to make it clear, I don’t believe that the automated coin choice pools had anything to do with the attack, I believe the title of this post is misleading and provocative.
[/quote]

I said automated coin choice pools HELPED us.
[/quote]

Again, fourth try: what are those automated choice pools you keep talking about besides multipool.in???
[/quote]

He’s referring to people who use coinchoose api to automate the switching of “their” clients to different pools that are standalone coin pools.

Nope. Any solution that involves making some coins more accepted than others would spiral into massive complicated disputes or worse censorship of different groups.

We need solutions that address what we want to do, not what we are afraid of. The 51% attack can be tamed even quarantined.

This is a solution for the full scope. But need to turn it into code.

Partial scope involving small groups will follow after.

How to turn the above into code?

What if instead of tracking transactions (send and receive) separately we track them two by two. This is more work so we should perhaps reward say 500 coins. Say our work function hands out random sends (minus) and receives (plus). You get split share credits as they come. Those shares don’t count until there’s a matching plus of the same value for the minus. Say in a round the work is either plus or minus, so to get a block you have to go two rounds, and the block is split between the addresses that found them (250 each). If there are too many pluses or minuses you only get credit for the matching ones. So some attacker spamming sends, needs to then spam receives. And they can’t be sending out both in the same round. Instead of silly things like tainting or dangerous things like rollbacks, pools can delay the processing of spammed sends or receives, effectively blocking them in real time. But suppose rogue pools choose not to. Then these sends and receives have to survive multiple confirmations together. We can have a separation limit of say 10 rounds. So a -50 coin send can wait 10 rounds to be matched with +50 coin receive. Beyond that, the earlier one is discarded and the attacker has to repeat his attempt.

What I’m suggesting is not just add the nonce as proof of work, but use the nonce to create mock transactions and match them to rounds that occur after. Also we can randomize whether a round is a send round or a receive round.

If the attacker alternates send rounds and receive rounds and records them all as being the same positive or negative value, they would get credit. BUT we can improve that situation. We can deal with the maturity period (120 confirmations) differently from the transaction period (after 120). We can say that each -50 send has to match 120 +50 receives. And those +50 receives have to match 120 -50 sends.

Ill give a hand too. I have experience moderating forums.

zerodrama:

what do we learn from this - so by limiting every pool to say 50 M# could that be a way to eliminate this sort of thing happening ?

I don’t think a vote is constructive. I’m happy knowing that plenty of folk are working hard to keep this alive and healthy despite the current issues. Keep up the good work.

[quote name=“jeremiel” post=“11951” timestamp=“1370820840”]
So I want to start mining again but I don’t know WHICH pool is right?

fcpool? give-me-ftc?

or is there another?
[/quote]

It would be great if someone can compile a list of trusted nodes and distribute it to the pool owners. That way we can all make sure we’re talking to one another.

I have checked my client logs, this is the heighest block which has been reordered with a large amount of blocks.

Seems they are talking about it in here http://forum.feathercoin.com/index.php?topic=853.0 on the last couple of pages.

Just seen this myself. http://forum.feathercoin.com/index.php?topic=853.0 Last few pages seem to be the most informative.