Topic: Possible 51% Attack on fairbrix (fbx) - page 2. (Read 5189 times)

Didn't think of that, if the avg hashrate fits it'd be a "duh" case. Also "decently cheap" to pull off. *and* it would explain why he scaled down after block 2016 and completely stopped after 4032.

Like 4~5 EC2 quad-cpu cluster nodes...

Enough relaunches.
The chain is doing ok now and the attacker has got a vested interest in playing it easy if he doesn't want to loose the benefit of his loot. I would even expect that he keeps mining with enough power to protect the chain so as to make sure that his coins make it to the next stage.
It's like if this chain started with 30k coins premined. Irritating but not overly so. That is still way under the 7M+ in Tenebrix.

Contemplating this some more... the "pure fork" part had ~4.2s/block, average nonce was ~235k, unless I'm missing something and assuming cpuminers algo for nonce generation, average hashrate/box should be simply avg nonce / avg time ... that'd come out to about 55kH/s/box...  need to do a test to see if this assumptions holds, if yes it looks closer to 4-5 high end quad-cpu boxes. At least that'd be a lot less "weird" than a single cpuminer instance running on like 80 cores.

edit: nope, stock cpuminer, tbx-miner and my cpuminer fork keep one workitem *per worker thread*, so those nonce values would mean someone was running 4-5 *threads* at about 55kH/s each... very odd.
Hmmm, or using a patch that does the "split single workitem into chunks of nonces to hand off to miner threads" thing, pretty sure there's already a fork of stock cpuminer doing just that and merging that with tbx-miner should be trivial.
So with that scenario... our attacker has access to at least few beefy servers, some understanding of bitcoin, can apply patches and recompile. (iirc there's like a 3-line patch to bitcoin to implement a stupid "fork existing chain after block X" floating about on the forum somewhere...). Sounds like your run of the mill BOFH. *ducks*

Well, relying on block timestamps seems somewhat pointless, there's no reason the attacker couldn't fake the timestamps in his forkblocks to be "close enough" to the real chain to leave no obvious gaps.
So... how do you figure out which chain was "first"... if your node is live at the time it's pretty easy, but what if it was off for a while and when it gets back there's now 2 similar-length chains? Solving the 51% problem in the general case without creating single points of failure or new vectors to mislead nodes is ... hard.

Would some sort of automatic timestamp trigger work?
A sudden 5h gap in block times after block times best measured in seconds is blindingly obvious to a human, seems like it could work.  It'd depend on the miners getting a standardized time somewhere though.

Well, the most recent 100 fbx blocks took ~63 sec average at diff 0.00390625, that's about 266kH/s. so someone with a bit more hashrate than our forker could pull pretty much the same stunt even now.
Any relaunch would start with way less miners on it, so it could potentially be fucked with the same way by the same guy(s), unless it's *started* with well > 250kH/s, or block acceptance rules are changed to make orphaning a existing decently-length chain a lot harder (did anyone ever do this? it'd make giving a fresh node a "fake" chain a lot easier, as in that case the main chain has to be the one with a lot more work than the fake one. But it'd also mean a rogue miner would need to have several times (3? 4?) the network hashrate to pull off a "fork the chain".
I'm imagining something simple along the lines of "only accept a new block as the best if it's a direct descendant of the current best block, or if it's total work since the last common ancestor with the current "best" chain is 2 (3? 4?) times higher than the work done in the current best since that common ancestor." *could* work.
It'd also mean network efficency would drop, as miners happening to mine a orphan would get stuck mining completely pointless children of it until the main  chain got ahead at least 4 blocks... and if they're > 25% of total network hashrate, their client won't *ever* notice as their fork keeps growing fast enough so the main chain work-since-fork would never hits the 4-times reorg trigger limit.

Most likely answer.

Thank you for looking into this.  From what you're saying, it doesn't look like different build conflicting with each other, but rather an intentional fork.

Do you believe that another relaunch, this time with proper announcements and builds for everyone, would crack the nut against potential attackers?  Or is this proof that new chains are so subject to attack that it just isn't worth it?

Well, back on topic then, picking apart my local fbx nodes blk0001, ... doesn't look very accidental.
I have a 1327 block chain that was orphaned starting at block 58.
There's a ~4h24m gap from block 57 to what now is the current block 58, and block timestamps after that look "reasonable enough" without huge gaps or long runs of minimum-time-increment blocks, so I'm guessing the attacker didn't fake block timestamps.
By block timestamps, the orphaned chain was mined over 5h57m, the new chain spans 1h33m over the same block #s.
taking hashes/time... the oprhaned original chain was mined at about 65kH/s, the same blocks in the new chain 250kH/s.
And there's something decidedly odd about the block nonces in the new chain, they're ... too high.
Orig chain had nonces averaging out to ~4000 (which is hinting at how many hashes one cpuminer instance is roughly doing between getworks...)
New chain nonces average... about 235000
so either a single cpuminer instance was doing ~60 times what your average cpu does, or they had something like a custom getwork proxy splitting workitems into noncranges and handing the same work with different starting nonces out to a whole bunch of machines (possibly to reduce getwork load?)
but at "only" 250kH/s, why bother with that? pushpool can handle a few 100 mining boxes just fine.
hrrrm... "single cpuminer instance doing 60 times your average hashrate" ... massive NUMA system? single system image cluster? My phenomII X6 @ 3.6GHz does ~3.25kH/s/core and new xeons are probably getting into similar ranges... 64-core server?
Of course this is all pure speculation as I'm only assuming block timestamps weren't faked. If they were, there's no telling how much hashrate it really was.
After that the "odd-noncey" blocks are still appearing for quite a while, noticeably drop off in count after 2016 and nearly completely stop after 4032, there's only 9 blocks with nonce > 100k but not obviously byteswapped after 4032.
Thats another oddity, there's at least one other miner creating "weird" nonces, they're obviously doing em byteswapped (but appears slow-ish, only 32 of those byteswapped nonces in ~600 blocks since 4032).
So overall... yeah, looks like someone with ~250kH/s deliberately orphaned blocks from 57 on to about 1400, then switched to mining legit and got about half of the remaining blocks up to 2016, slowed down for the next 2016 (looks like he went down to about 1-in-5 blocks) and completely stopped after block 4032.
Wild-ass guess... someone had access to a pretty damn massive box or 2, was late to the party and decided to "get all them easy early coins"
Or he might have noticed the weird nonces his setup generates and fixed it somehow.
But my money is on "asshat with access to a large NUMA box (at work?)"

Chain analysis should reveal whether they were stolen (lend evidence against "some kinda accident" hypothesis) and, methinks, how they are distributed in terms of keys.


Identifying the attacker "to IP" is unlikely to be possible, especially if IRC chan logs are not available.

Rollback is highly problematic.

If there is indeed a thief, it is quite likely that he is still connected to FBX and that a significant (if not outright dominant) portion of the net hashrate is actually him (that would also be consistent with how few blocks my core2duo lappie has been able to find since the attack).

It seems to me that whether the attacker is still "in charge" might become more or less apparent through block chain inspection if he didn't take precautions

At first I was happy to see that so many responses were posted.

Please stay on topic. If you read back a few posts I'm sure everyone will notice that the conversation has drifted far from the original subject matter. If you gentlemen would like to talk to each other I suggest using personal messages or starting a new thread. Possibly in the off topic sub forum, here is a link to it https://bitcointalk.org/index.php?board=9.0

So it seems clear to me that the blocks that were invalidated were stolen in a purposeful way (no accident). Is it possible to gain clues from the chain about who did this? Or could there be some way to undo the damage? I don't think there is a way to identify people from the chain or to roll it back to the beginning.

What now? Should people keep on mining? I have heard some anecdotal opinions that the hash rate is increasing. That would make it harder for a second attack. The big question in my mind is how much power does the thief have now? The thief had 51% or greater (probably much more than 51% because a whole new chain was created) hash power than the entire network. So presumably our thief is still hashing away with his CPU farm AND on top of that has the 40,000 coins that were involved with the theft.

Fairbirx was created because some people felt they shouldn't have to trust Lolcust to do only good things with the premined coins. Now here with fairbrix we have the situation where WE KNOW that an unscrupulous person has a majority of the coins in existence and will most likely do others harm with the power they wield.

I'll say that again. A known thief has most of the FBX in existence and most of the hashing power too. That is plenty to control markets (if one is ever created for FBX) and mess with the network. If these new coins were created because Lolcust might do something wrong, how can we support them when we KNOW that something worse has already happened?

Thank you for reading. I appreciate your responses but I ask you to please KEEP IT ON TOPIC. Thank you.

[ ] I realize that "simple CWC" on wikipedia *is* CMWC4096.

Aww how cute artforz. Actually try wikipedia for a simple CWC, it's amazing how bad your google searching skills are, shouldn't be a surprise given you poor programming/copying skills though?

I seriously do not understand what some of you personally seem to have against the guy. He is damn funny as well LOL made my day.

You? Have an idea?  Please, you take copying to a whole new level. You ruined the comedy act when you started it with "I have an idea". And for what it's worth, when you and your playground chums don't manage to inflict any damage on SC2.0 what then? Going to crawl back into your little house built with failbrix? It's going to be hilarious.

Look, he is not promising to do all this. Let us just give him a chance to prove what he is saying then we can troll him.

Yes, and I have an idea for a chain that will be completely fair, immune to all known attacks, any possible unknown attack and even impossible unknown attacks! Mining it will also produce more power than it consumes. So not only will it revolutionize the global financial economy, it'll also fix the energy crisis, cure cancer and shit rainbows! And it'll be done Real Soon Now(tm).

Here I must concede.

The idea to manufacture abstract quasi-value constructs for yourself on the hardware of other people using other people's electricity is indeed pure genius.