[quote name=“zerodrama” post=“12576” timestamp=“1370899844”]
[quote author=ASDASDASD link=topic=1556.msg12495#msg12495 date=1370881509]
[b]FTC is in trouble still[/b]
[list]
[*]Difficulty was supposed to go up to 94 but rather went down to 47
[*]give-me-ftc had over 50 blocks found and orphaned. Those blocks now are found by ‘unknown’ and are 100% confirmed after previously being orphaned.
[*]Coinwarz was stating current difficulty at 94
[*]Forum has been DDOSed 4x or more times
[*]Coinotron DDOSed
[*]give-me-ftc DDOSed
[/list]
Just a few things in the last hour…
[/quote]
It was not supposed to be 94. That was based on 60 blocks. 47 is based on 504 blocks and it was correct because that was the 2.5 minute block target.
Coinwarz based it on the 60 block prediction.
DDoS is desperation.
Also I keep telling these wankers not to try trolling a troll. Clearly, they’re not paying attention. Time to advance the schedule.
[/quote]
From what I saw the blocks were coming in fast at less than two minutes. Even if the diff did go down it should not have gone down so much. The blocks after the diff change were over written by the attackers with blocks dated a day before. It effectively doubled the amount of time it was supposed to take so the diff went down to the maximum amount. If we can dig up the details on the orphaned difficulty change block we can figure out exactly what the difficulty was supposed to be.
[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.
[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=“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.
[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.
