Yes, the superblocks will have higher difficulty and the record holder would have the highest, however if more than one of them share the same top difficulty you'll have to decide by comparing the value of the hash of the block's header (in the bit order that is used to generate the base prime), or just compare the base prime for those.

But weird thing is, that my wallet didn't sync any further and the blockexplorers too.
Let's hope it doesn't happen again

Anyone know anything about the difficulty dip to 1280 (and the rebound to 1409)?

Ypool's pool speed doubled without much of a worker increase...  Just curious.

Regards,

--
bsunau7

MintPal wallet still holds at least 166k RIC

https://chainz.cryptoid.info/ric/wallet.dws?14521.htm

Withdraw while you still can if you have not already!

I'm running gatra's v14 XPT miner, with my own server side for solo mining.

Please let me know what kind of miner you are using, this seems quite unrealistic for solo or pool mining in 24 hours / in fact I don't believe it.

As for 9.2 client sticking, I have to admit I have a version of it installed but am still working mostly off the older 8.7 build and only used 9.2 a few times.

I know this is against Gatra's advice but honestly I am more comfortable with the older codebase and since I am not solomining it has no impact on my performance.  I find the 8.7 client after firiing up takes a little while to connect to some nodes but if you are patient it has never failed me yet and always gets many connections and synchs up to the network after a short while.   

with an i7 3770K "solo mining", how much i can get in 24 hours?

thanks

http://gavintech.blogspot.com/2012/05/neutralizing-51-attack.html?m=1

Gavin: "The code already has a notion of (bitcoin priority) that it uses to prevent transaction spam (sending gazillions of tiny transactions to yourself, just to make everybody else do the work of validating and storing them); extending that to influence the chain-fork-selection code wouldn't be hard....something like....ignore a longer chain orphaning the current best chain if the sum(priorities of transactions included in new chain) is much less than sum(priorities of transactions in the part of the current best chain that would be orphaned)” would mean a 51% attacker would have to have both lots of hashing power AND lots of old, high-priority bitcoins to keep up a transaction-denial-of-service attack. And they’d pretty quickly run out of old, high-priority bitcoins and would be forced to either include other people’s transactions or have their chain rejected".

In Andresen’s post, he notes that such a solution would be “Not To Be Used Except In Case of Emergency”.

It's the most idiotic statement I never read on the internet... astonishing, could you please elaborate on what are the alternatives (I guess centralized) and what do you understand by the term "cost of supporting decentralized technology" vs "cost of supporting alternatives"? And if it's not to much what does cost mean for you ($ term I guess)?

Thx a lot.

Thanks a lot vancsj.

Complexity is the hallmark of an unfinished idea, which this one certainly is. Hope, a discussion will allow me to spot the elements that can be taken away.

Thanks Bitsalame, you could be correct. It is only by being wrong that I have a hope of eventually being right.

It would be good to have a concrete analysis from you, especially since the proposal does away with a Clearing House for securities trading. There is a difference between Settlement and Clearing House.

I am talking about decentralized vs centralized systems.
The cost for immutable transactions in any crypto-currencies is too high.
And we can not decrease it.
When the hashrate will stop growing it will be easy to collect old switched off asics, turn them on for an hour and gain 51%
Sorry. No way.

动不动就说比特币几万的大话，留点德吧，搞得像传销一样。比特币值几万用什么支撑呀？洗小白吧！