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.

There are lots of non-profits that have a chapters model something like this.  The first that pops into my mind is the ACLU.  Though... I'm not an expert on that. Certainly it would be a useful tactic to use elsewhere.

The decisions of the chapters are up to the chapters.  They may each have their own personnel issues (e.g. lack of an available trusted party to handle the digital donations), interpretations of local laws, hunger for funding, etc.

The list of chapters is here: https://meta.wikimedia.org/wiki/Wikimedia_chapters.

It's worth noting that not all chapters are equal.  Some are large and active, some are new, inexperienced, and some are mostly idle.   Some are not actively soliciting donations because they don't have the organizational maturity to handle them (and just get grants from Wikimedia to run projects that cost money), etc.

Off the top of my head: Some of the larger and more active chapters are Germany, Netherlands, France, Israel, Australia, Italy, UK, and Argentina.

My gut impression is that Germany won't care much (they are by far the largest chapter, and have a lot of income already) and that UK will blow you off with bitcoin-is-bad+wacko-law-interpretations.  Best bet is contacting a chapter near you or ones associated with languages that you speak.   Since chapters have a regional (and often language specific) focus, people closer to the chapter are in a better position to interact with and evaluate them.

Wikimedia (washington) DC is a new, smaller chapter that was just recently formed. It has a lot of cultural overlap with the NY chapter so it might be receptive too.

I feel kinda silly for not suggesting trying to get the chapters to take bitcoin before... in general its a pretty good fit: as smaller organizations the chapters can be a little more agile... and if one or another is infected with the bitcoin-is-bad meme there are others to try.  The ones who will accept it get the benefit.  And it will build up a base of experience with accepting bitcoin donations within the Wikimedia family.

One is the older Wikimedia New York City chapter page page on Wikimedia meta wiki— it's a wiki setup for all the wikimedia sausage making stuff (thus 'meta').

Nyc.wikimedia.org is a separate wiki setup for the chapter earlier this year.  They're apparently migrating stuff from one to the other slowly over time. The front page there points this out (and the page at meta.wikimedia.org also links to nyc.wikimedia.org).

Good news, on this front.

Wikimedia NYC, a non-profit regional support organization for Wikipedia/Wikimedia has started accepting bitcoin donations: https://nyc.wikimedia.org/wiki/Donate

Wikimedia has chapters all over the world that serve to organize regional efforts. In some countries there are tax advantages vs donating to Wikimedia itself (though, obviously not for a US chapter), but chapters primarily serve to organize the offline efforts of Wikimedians to reach out to the greater world around them— collaborating with schools, libraries, and museums.   

Wikimedia NYC is one of the larger and more productive chapters, especially considering that it's one of the younger ones. More info at: https://meta.wikimedia.org/wiki/Wikimedia_New_York_City

WM NYC runs workshops to teach people to edit wikipedia, they run an annual wikipedia conference in NY which is open to the public, and have run big highly productive initiatives to improve Wikipedia's coverage (both in articles and in illustrations). Their outreach both increases the depth of Wikipedia coverage, and breadth by helping people who aren't computer geeks to contribute.  Donations to Wikimedia NYC directly support these efforts.

I'm not personally a part of WM NYC, but I've worked with them on some of their projects in the past and sometimes visit to their meetings (or at least if you go through their meeting archives you can find pictures of me, though I live down in DC so I don't make it there too often).  So I can say with a least a bit of direct experience, but without personal bias, that they're an organization worth funding.  Moreover,  success with their bitcoin donations may encourage other chapters and Wikimedia itself to accept donations in bitcoin.

Cheers.

I welcome "fixes", but they really aren't possible.  Bitcoin is a decentralized system— but it's not decentralized anymore if you put control of it up for grabs in real-time by the highest bidder.  This is true for _any_ decentralized system.

Some of the security of bitcoin comes from the fact that it's economically more sensible to cooperate than to defect— that doing nasty things to the system will _lose_ money for the people who have the ability to do it (e.g. blockchain bloating attacks, and transaction prohibition attacks).  But a key element in that is educating people about whatever is in their best interests.  As a miner, it's not in your interest to cause increased centralization or enable attacks.  

There are many techniques which can be applied to resist centralization. Bitcoin is more than a piece of software. More than a protocol. It's an ecosystem, an economy. And education is part of our defenses.

Here is a more scary and concrete example.

Lets imagine that meta-pool services with open mining policies became very popular and together represented >50% of the hash power.    I, the evil attacker, setup a copy of bitcoin to perform the timewarp attack:  I will lie about the timestamps in my blocks in such a way to drive down the difficulty to 1 while massively cranking up the block rate.    I then go to the mining loan services and purchase all the hash power they have available offering 0.0001 BTC/share.  This astronomical rate will get me all the hash power I need, and I'll easily be able to pay for it because I'll be making 0.02 BTC/share once I get the difficulty down to 1.

Normally we're resistant to the timewarp attack because anyone who controlled >50% of the hash power would find it not in their best interest to blow up bitcoin. But in this case, my investment would only be the funds I needed to front to start the attack. The miners themselves wouldn't get a chance to disagree with this policy because I will have bought their mining on the open market, and carried out my attack before they even noticed— perhaps I could even manage to cash out some of the spoils of the attack before bitcoin collapsed completely, making it all quite profitable for me... and leaving miners with a bunch of worthless gpus.

(which is also why the fact that I could go out and buy lots of hash power isn't a problem)

All this is also an argument why any consolidation is bad— but in the case of pools they see substantial continued income by sitting back and not being evil compared to being evil and potentially getting a lot of money quickly but then being out of the game.. The incentives are not the same for market purchases. There is no harm in trying a little evil, even if you're not sure you'll be successful... because you'll only lose the small premium you had to pay to try.

Of course, if the service is more conservative about where the hash power can go— then thats a big improvement. And I'd withdraw most of my objections there. (though not all— the service is itself more consolidation that we don't really need)

I don't think I did.  I've put the whole log up for anyone who cares to read it.  http://pastebin.com/Uhsz1S3D


When people purchase long term mining contracts from people they are using it as a potentially more efficient way of purchasing bitcoins.   Using bitcoin to buy hashing power doesn't have the same applications.   It makes no economic sense to pay X bitcoins for a less than sure chance to get less than X bitcoins. To do so is to throw money away.

There is no need to purchase all the hashing power to attack bitcoin. You can make modest attacks, e.g. finny attacks and fake chains for isolated nodes, without anything like a majority of the hash power, and this "service" would enable anyone who wants to pay a small premium to get all that they need.

I am very concerned that this service serves NO legitimate purpose except enabling people to purchase attacks against bitcoin.

Asking on IRC about it on I'm told:
< pirateat40> gmaxwell, you can't blame someone for building a way to do it.

Pools have to build up trust in order to get enough hash power to be viable, but some guy who pushes "buy hash power now" has no trust at all.

I sure hope like hell a significant majority of the bitcoin hash power isn't stupid enough to fall for this... otherwise bitcoin is done.

(edit: to be clear, the monitoring stuff is probably perfectly useful to people, though it would better and more reliably be accomplished with local software rather than a DOS vulnerable central service, the ability to redirect hash power is what is that existential risk to bitcoin)

Hm— well, different models are possible here.   I'd like a separated GUI and backend because I can run a single trusted backend and not deal with the computationally expensive zero trust stuff on all the other clients I need.   I wouldn't want to use some node just because I heard about it via zeroconf/avahi.

If you're going to discover nodes via zeroconf then you need to be able to operate in a way where you don't trust them. Thats significantly more expensive than being able to trust them.

I see your user icon has changed.

I for one welcome our new S6-LX150 300MH/s overlord.

Your beliefs are nice— but where is the evidence?

Litecoin has been a little inventive responding to various flooding attacks, but nothing I could call genuine innovation.

SC has been a nice demonstration that you can break the centralization of the system completely and abuse central authority substantially while keeping a solid base of believers— a fair warning for bitcoin itself: you can't count on loss of confidence from the believers as evidence that you're doing it wrong.  But nothing really innovative there.

Namecoin brought us a real implementation of merged mining... an innovation which should not be downplayed. But what has it done for us lately?   (namecoin would be a good target for a lot of other improvements, like flipped chains— but there doesn't seem to be much interest in taking it further at the moment)

As for the rest— mostly they've just failed ... sometimes due to technical attacks from their minor changes to the bitcoin algorithim. They now stand as monuments to the general wisdom of the particular magic values bitcoin was started with.

At the moment the satoshi client is the primary basis of innovation in the decentralized cryptotoken field. This is sad considering how hard it is to innovate.

So, yea, speculate that the advancement will come from elsewhere if you want... but it's just speculation without some evidence to back it up.

You've defined the requirements too weakly.   Take bitcoin, add a requirement that a valid block must be signed by both bob and I (hard code the keys).  Make the difficulty zero.  Change nothing else. (If you also totally screw up a bunch of extra things, you could call the result 'solidcoin').

This meets your criteria because there is no central server. There are distributed servers. The system is secure so long as you trust that bob and I won't conspire to screw everyone.

You can pay to the address in my sig, thanks!

Type-2 deterministic wallets: https://bitcointalk.org/index.php?topic=19137.0

Good point. It's a perfectly reasonable mistake, especially if you're not a frequent CLI encryptedwallet user already. I've added a note, hopefully it is more clear now.

Having an asker interface in bitcoind would obviously be nice— but the shell exclusion is a pretty nice general mechanism, especially with the initial space ignoring that it's a good tool to have in your toolbox regardless of what goes into bitcoin.