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=“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.

The attacker inserted chains are now part of the primary chain. I believe we have enough network hash rate now to avoid this happening again any time soon.
If you are unaware, there is a new Feathercoin client out with checkpoints added in the block chain to make sure everyone is on the correct chain: http://forum.feathercoin.com/index.php?topic=1536.0

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.

[quote name=“digitalindustry” post=“12323” timestamp=“1370861618”]
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 ?
[/quote]
Limiting pools is not the answer. The only time a pool should limit itself is when it is gaining in popularity enough to seem likely that pool will get close to 50% of the network. p2pool is an exception to this as long the hashrate is spread across enough individually operated nodes.
The only way to prevent this sort of attack is to keep our legitimate network hash rate higher than the people who wish to attack us.

[quote name=“Radacoin” post=“11585” timestamp=“1370787339”]
"What I think is happening with FTC is that the automated pool hopping is corrupting the block chain.
Yesterday FTC net rate was plodding along at about 170MH/s then multipool suddenly threw another 85MH/s at it taking it to 265MH/s and about half an hour later there was another sudden jump up to over 500MH/s I presume as a result of people using profitability sites like Coinchoose/CoinWarz to target their mining focus.
[b]Because FTC has a long confirmation delay, it was about 15min when this happened, a little bit of luck with the new miners and they can find a couple of blocks in this time and have a longer block chain.[/b] Kind of like a 51% attack. Some people think there was a deliberate attack on the FTC chain yesterday, but I haven’t read a plausible explanation of how this would be done. You would need several hundred MH/s and that’s a lot of GPU’s to control."
https://bitcointalk.org/index.php?topic=167635.540
[/quote]
I wrote that post you were quoting, and I was looking at alternative explanations before the evidence of the fast dump of fake blocks came out some hours later, which sure looks like an attack, not necessarily a 51% attack you don’t need 51% to corrupt a block chain. See here http://we.lovebitco.in/bitcoin-paper/#ch11
When the time between blocks gets high, you give attackers time to move between confirmations, which is not a good thing.

You don’t fork a chain without a really good reason, ie. You have made some considerable improvement to the code and the blocks it produces are no longer compatible with the old chain.
I don’t see a list of these considerable improvements.
However you can rest assured that a rollback would destroy more blocks than the hacker did.

[quote name=“Vigil” post=“11848” timestamp=“1370810106”]
I’m not receiving any block rewards from give-me-ftc although I keep getting shares.[/quote]
Me neither. I give up, I can’t mine and I can’t send or receive FTC. I coming back to LTC until this madness is cleared up.