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.
 

There are many virtues to decentralization,  but reducing operating costs and improving performance (assuming equal costs) are not really among them.  Some things appear to do so, but only because they are externalizing costs (e.g. shifting costs onto the most expensive last mile ISP paths, which is only 'cheaper' due to unsustainable all you can eat pricing, resulting in blocking/rate limiting, or hosting things on stolen resources).

Wikipedia costs a fair amount to operate, but only because it's so widely used. It comes down to something less than $0.05/yr per monthly visitor (actually more like, 0.02 but wikimedia is spending more than strictly necessary in order to develop new software and increase Wikipedia's usage around the world). The challenge for Wikimedia is that most of their visitors don't donate at all, and payment processing overheads would make operating on 400 million 5 cent payments still insufficient.

I use to argue that decentralizing Wikipedia (while retaining the property of having a single coherent website people could browse, rather than e.g. a forest of never updated forks, preserving user privacy, etc) was actually impossible, but the bitcoin distributed algorithm disproves that.  That said, many people complain about the time it takes to sync a full bitcoin node, it would be far worse with 400 gigabytes of article history and 12 TB of image data. So even ignoring the fact that it would cost more in total to operate it's not easy, and the required technology simply hasn't been built.

Of course, you can go to download.wikimedia.org, and pull a static dump and serve it up via a CGI and people do, but that isn't the same as decentralizing the sites— it's not getting the hundreds of updates per second, it's not providing a single, coherent, usable, and reliable view of the site. The prior attempts (for which there have been many) have all been laughable.

I'm sure if some bitcoiner wanted to build the technology to enable this they could find many patrons in the bitcoin and Wikipedia communities to sponsor their work. Sadly, it seems that on this subject most people are all talk.

(as someone who was involved in WP fundraising a long time back, I guess I can comment)

There never really was such a time. Wikipedia has long had a razor focus on operating efficiently as possible, made extensive use of volunteer resources (even for sysadmin stuff, legal stuff, etc). At its inception Jimmy funded it out of pocket with the help of friends, but it wasn't very costly to operate when there was no traffic.

Six years ago Wikimedia had ~2 actual full-time employees (and they weren't paid much, at that— as they were just ex-volunteers). As the site has grown, costs have increased tremendously, but not linearly— but as Wikipedia has grown fundraising potential has grown too (though also not linearly).

Even way back in the old days Wikimedia would turn away 'support' that appeared to have compromising strings attached, people wanting feeds of private user data, etc. It's been very fortunate that it's never had to make the hard decisions.  Though back then there used to be a lot of speculation about what would happen if the money ran short— would we run ads to stay afloat?   Now adays, that prospect seems so unlikely that people in the organization can say things like "if our funding were to vanish, it means we are failing our mission. Public funding is an important check on our performance.".  (Easy to say when you're sure it won't happen!).

I think Wikimedia would accept Bitcoin today, except there is at least one important staff member who's fallen _hard_ for the "bitcoin is a ponzi scheme meme" (google erik moller bitcoin)— and there isn't any great justification for bitcoin for them enough to overcome that bias... after all, looking at what the EFF, FSF, and Internet archive have received... we're probably only talking about a couple thousand dollars in support from bitcoin compared to the costs of dealing with the logistics, a small risk of negative PR. It would really only be majorly worth doing for the sake of supporting something new and innovative.

I think that as time goes on, and bitcoin proves itself to be a painless and worthwhile fundraising source for other orgs that wikimedia listens to (E.g. the FSF and Internet Archive) then they'll probably come around.

So you're using that snazzy wallet encryption stuff to keep an online wallet locked up when you don't intend to send anything... but problem: You're a CLI user and you're ending up with the walletpassphrase in your shell history.

Don't worry: Bash has you covered (this is also possible in some other shells, but you're on your own there).

Just set HISTIGNORE='*walletpassphrase*' and the shell history will not remember any line with the string walletpassphrase in it.
This list is colon-separated if you want to add more patterns.

Note: walletpassphrase above is literally the string "walletpassphrase". Do not substitute your actual passphrase there! (thanks to the comments below for pointing out this potential confusion.

For example, my ~/.bashrc might look like:

HISTCONTROL=ignoreboth makes the history ignore duplicate commands and commands which are prefixed with spaces, so you can keep other cruft out of your history on the fly, and HISTSIZE=50000 greatly expands the maximum history, histappend makes it append to instead of overwriting the stored history, allowing your history to go back a long way. None of these are required for thie HISTIGNORE but you might find them useful too.

After putting it in your bashrc, restart your shell.

You can instantly tell if its working, e.g.

Of course, best security practices would be to not keep wallets that matter online, but with a little care you can increase you security for what you do keep online.

Cheers,

Right, well, it was at full rate at the excitement of the initial announcement but soon fell far below one block an hour and stayed there for pretty much all of 2009.

The area under the red line is less than one block per hour, and this is a log scale graph:  http://bitcoin.sipa.be/speed-ever.png

Yes, but there is no one useful definition of entropy— you don't know the prior.  

E.g.  http://openwall.info/wiki/john/markov  assumes one kind of prior (that your password is the realization of a markov random walk with some measured transition probabilities— something that was shown to be a pretty good model of real passwords in the literature). You can even use it to sort pre-existing wordlists.

There is of course the zero information prior— e.g. the uniform one, where you'd conclude that "password" and "jxiesotm" are equally good passwords. But it's not very useful.


Perhaps your alterations are sufficient, I can't say— but you're making a fundamental error here by assuming an entropy measurement tool can tell you anything useful.  All tools can really do reliably is give you upper bounds on the entropy (e.g. saying that 'password' and "jxiesotm" each could have as much as 49.3 bits of entropy (assuming a 72ch charset)).

You can try to guess a tighter bound than that, but you'll be wildly off depending on if you got the model right.

If choosing 16 word phrases verbatim from books were something people did often enough for an attacker to adopt that prior than your password would only have (assuming my really armwavy numbers of 80k books of 80k words) about 32.5 bits of entropy in that model.  You can insist that some tool says that 16 words magically gives you 500 bits of entropy, but it simply isn't so if you picked those words out of a book. Even without ever having the actual book I can make much stronger predictions just by knowing that the words are comprehensible english.

[9, 9, 9, 9]  < do these numbers have very low entropy?  You can't say from just looking at them. What matters is how they were generated.   How about [140, 166, 77, 233, 193, 177, 35, 167]? (It seems like it has high entropy but it's just a DES encryption of zeros with a key of zeros).


Ideally, what you want to do is to make the zero information prior the correct prior by choosing uniformly. This is removes the risk of the attacker beating the odds with better predictions of password choices because there is no way to beat the uniform prior if you're actually using the uniform prior and it's not easy for you to confuse yourself about how much entropy you actually have.

The power of reputation is easily overstated.  We often think of reputation as valuable because identity is costly. If you make identity cheap you make reputation cheap.  Anonymity requires that identity be cheap, so reputation loses power as a tool.

To state this more concretely:  Say I offer some kind of service that requires concealing my identity and requires I be trusted.  For example, some kind of mixing service. People pay funds to me anonymously and then later I pay out, concealing the connections.  If my identity was not hidden people could use force to coerce me to compromise the mixes' privacy.

Because I am anonymous, however, I can also run off with the mixes funds with impunity. You say "not so, you lose reputation" but this isn't really true.  I don't just run one mix, I run many— a series of mixes which look independent made possible by the cheapness of anonymous identity.   When my second mix is starting to get a good reputation, the first experiences 'catastrophic data loss', 'a hack', or otherwise just vanishes.

Given some reputation ramp rate there is an optimal point for a anonymous operator to cut and run in order to maximize income. There is no reasonable set of system parameters which doesn't make this the case, only identity which is difficult/impossible to replace can serve this purpose.

The best thing to do is to go read the software.  It's the true specification: It's in a (mostly) precise, meaningful, mathematical language— and should it differ from any prose description then it's the one that wins.

Skill in code reading varies, but I think the bitcoin 'official client' code is fairly clear.