You say this, I can't tell. My orphan rate was high enough that you could have been excluding other blocks— though I trust that you weren't and that it was normal performance problems plus the fact that there was high latency between my nodes and yours (and that if you where there was _nothing_ I could do about it).  The point I was attempting to make was that a pile of orphaned blocks is perfectly expected in a natural supermajority case, especially when the blocks are being solved very fast. (appears like we were talking 10seconds).

Where are your helpful corrections for the people claiming that he's 'attacking' i0 and ix too or the claims that he was breaking the bitparking pool? (as far as I can tell these are outrageous lies)  [Edit: I included a barb here that doublec didn't deserve]

I misread that as "con" and thought it was a surprisingly honest post.

The vitriol should go down a notch here. As far as I can tell no actual transactions have been reversed. Just orphaning (er, which is what you should expect with blocks coming every 10 seconds, unfriendly funnybusiness or not .  And even still, not orphaning deep enough to have invalidated any spendable coins— which is what the maturity limit is for after all.

You're getting orphaned. Standard bitcoin chain decision code won't switch off your own chain and onto something else unless the something else is _longer_, being tied isn't enough.  If someone outpaces the reset of the network by enough of a factor it's unlikely anyone else will get any blocks in even without any modification to ignore third party blocks.

DoubleC's pool benefited from supermajority induced orphaning during big pre-MM NMC boom when it was >>50%, and I had a great many orphans in my solo mining. This was on a 10 minute chain which is less subject to orphaning, and on a chain that was worth non-trivial money at the time. ::shrugs::

So we should instill false and unjustified faith in random cryptocoin ponzi schemes?    Since you won't provide the link as facts are an antidote for FUD: https://bitcointalk.org/index.php?topic=56675.0


So— You're mad that your 'friend' only got to mine seven blocks before someone with a lot more hash-power dominated the chain? Sounds kinda petty.

Yes, the zero after free was kept.  And it still mlocks the private key data (which is slow because its still doing it for every allocation but it only adversely impacts key pool filling, this will be fixed later as it provides less benefit and needs a more complicated fix to maintain a pool of mlocked memory for that purpose).

He mined a bunch of blocks drove the difficulty into the stratosphere and didn't process transactions, etc. In other words, behavior like some bitcoin miners— except in bitcoin they're not >>>>50% of the total hash power, etc. 

You'll note the lack of links to the relevant thread (https://bitcointalk.org/index.php?topic=56675.0), presumably because the accusations sound much better without the factual information behind them, or the posts pointing out the extreme scammyness  of a bitcoin-clone opening  with exchange support on day 0, and the touting of unfinished pre-release features from the reference bitcoin client as major innovations.

I'm all for interesting altchains that serve real purposes, like namecoin— but so far the currency like ones mostly seem to be ponzi schemes which risk hurting bitcoin's credibility if they have any effect at all.   At least we can learn from their security challenges even if we don't learn anything from their absent innovation.

By using the chain as designed but simply electing to not process any transactions?

On a cryptocurrency that had only existed for a couple hours, which no one legitimately depended on, and which no one could demonstrate any real loss from? Good luck with a civil claim there.

When someone with a lot of hash power mines a cryptocurrency are they prohibited from turning off and leaving the difficulty sky high?

It would have perhaps been more interesting if Luke didn't disclose his identity here or that he was blowing things up. I wonder how long it would have even taken people to notice.

Part of the role that just born altchains serve is helping us learn about the risks, limitations, strengths, and weaknesses of these blockchain cryptocoin systems.

And it now sounds like we have a great chance here how to figure out how to combat a >50% attacker who is denying transactions—  but fortunately before there where many suckers^wpeople who sunk a lot of hard earned money into it.

I'm pretty sympathetic to the scam charge.  Exchange support and trading on day zero? Really??

Touting features that had been introduced to mainline bitcoin, developed and QAed entirely by other people, but just not made it through QA into release yet as big advances?  Really??

I think most of the altchains are really failing our collective community— they're contributing almost no innovation. The biggest contribution from most of them (NMC excluded, and maybe one (or half of one) more) is the little bit of learning we can achieve from their corpses.

In any case, if this were an image board I'd have one of those epic popcorn eating images. You've got to admit that this is pretty interesting.

It was merged about an hour ago, and will ship in the next release of the client.

Or may be just at 9000 btc bounty for a system to force people to read prior messages in a thread?

I thought people would be excited to hear that I finally got around to really investigating why the initial chain sync-up was so slow (at least for some users) and that I found an easily fixed problem.  

It's well known that the reference software does a lot of unneeded synchronous disk IO during syncup (in addition to the large amount of needed async IO), so syncup is expected to be slow right now on systems without fast disks... but even on systems with super fast disks and CPUs, the syncup is still quite slow. People frequently make all kinds of wild network related suggestions that they think will help syncup which I've been discounting: https://bitcointalk.org/index.php?topic=53389.msg640824#msg640824, but I hadn't had a chance to sit down and work on any of the actual causes of slowness.

Well, it turns out that when the wallet encryption was introduced some usage of mlock() was added to keep private key data out of swap. This is a good thing, but the mlock is used naively which is bad because it's slow (results in a TLB flush). That wouldn't matter too much, except a side effect of the change was to mlock all the memory used by a very common data type used all through bitcoin. This is pointless because most of the usage doesn't contain private data. (and may have even adversely impacted security of the encrypted wallets on systems with limited mlockable memory)

This was somewhat hard to track down— it doesn't show up in the oprofile cycle counter (it would have shown up in TLB flushes, but thats only obvious in retrospect) and didn't show up in some other performance tools like valgrind/callgrind (which is too simplistic an emulation to know mlock is slow). I eventually caught it in ltrace output.

There is still some ongoing discussion about the best path to fix this, but the performance improvement at least on some nodes is quite significant. YMMV, if you're not on a super fast SSD this improvement will be much smaller (at least until the excessive fsync usage is resolved), and my AMD AMD Phenom(tm) II X6 1055T  with kernel 2.6.35.14-106.fc14.x86_64 might mlock slower than some others.

This should also speed up the client generally, though its especially obvious for the chain syncup.

Enough talk, How about some pictures:

The blue and red lines are variants of this fix, green is the stock client.


There is more discussion on the pull request (https://github.com/bitcoin/bitcoin/pull/740)

That hashrate is computed from the submitted shares over a ~three week period.  I don't trust the miner figures either: I've certainly seen cases where turning the overclock up lowered the share rate while raising the hashrate without showing any errors.

To be fair, I had some stability problems while I was running 2x950 PSU which went away when I switched to 950+1200 and switched to 240v (I didn't both at the same time so I don't know which to credit— the PSUs I tested _do_ manage to handle more load at 240v).  I've also noticed reduced performance from more GPUs but I found this was addressed by increasing the intensity and worksize.

(and without increasing stale rate in any meaningful way— .... now I'm mining using p2pool, which has a 10s merged blockchain for payout agreement, and my stale rate on it is much lower than typical)

This is already how mining works, (barring surprising weakness in SHA256) the searched keyspace has uniform prior probability... the parts that have known acceptable values are already fixed.

Er. It's described clearly enough for anyone who should be writing this sort of software!

I tried early statistical early rejection using about a  giga-hash-second-month of shares data (or so) from real miners and wasn't able to find anything useful given intermediate state bits or state bit pairs. Perhaps with your graph techniques you'll find something more complicated which is useful...

but I'm doubtful— we have something like 3x the number of rounds of the best attack and the complete construction gets complete diffusion many times over and the later your early out distinguisher has to run the better it has to be in order to be worthwhile.

Thanks, prof.

But I'm using PCI-E 16x extenders, and I'm (crazily enough) within pci power specs.

I am also completely stable, with 1950MH/s (on 5830s), 60 days uptime (since last power outage)  on quite a few systems.

At forestv's suggestion I decided to give p2pool another try—  Wow. It's really matured a lot.

I've had about 8GH/s on it for a couple of hours with no issues.  It was a cinch to setup, even with merged mining.

I think P2Pool makes mining fun again.

I run 6x on the -70. Of course one the 65 you're going to need to split-molex the pci power.  But since I'm able to run 6x on the 70 without doing so, I'm going to guess you'll have no power related problems on the 65 with split pcie power.

On the plus side, if you go that route the result should be more stable— small changes won't cause the darn thing to fail or to achieve drastically worse timing in unrelated areas.