This is what I'm talking about in my last message.

This is exactly the kind of relationship which Wikimedia is likely to perceive as seedy and unaligned with its values, and it's a position that plays squarely into any argument made that Bitcoin is a pump-and-dump scam.  Wikimedia has the luxury to turn down selfish "donations" like this, or anything that looks even remotely like them, and it does.

This approach will not be successful. And, in fact, I believe the existence of this thread with points like this might undermine any differently motivated (e.g. people with unrealized Bitcoin gains who already want to donate and believe they would be better off donating it than converting it to USD paying taxes on it) efforts, which I think is sad. If something happens here it will be in spite of people who hope for some publicity and a rise in Bitcoin value, not because of them.

An alternative interpretation of a bunch of stored up conditional-coins is that you are attempting to buy some easy publicity fodder to pump up your Bitcoin, and you want to use Wikimedia's name to lend credibility to your effort.

Wikimedia has a lot of past experience with this, they'd enter into some limited agreement with some startup or another to work on some minor thing or that and then all of a sudden there is some flood of paid-press "WIKIPEDIA PARTNERS WITH ANSWERS.COM" (and in the subtext, written between the lines: buy buy buy answers.com stock! they've monetized wikipedia!) ... even when it's only some minor thing, or some trial effort, mentioned on some lost orphan page.

I'm not saying thats what anyone here is trying to accomplish (uh, well, okay its actually not entirely clear to me that the ask here is entirely orthogonal with that kind of outcome—  I can promise that _someone_ is going to run some "OMG BITCOIN WORLD DOMINATION, EVEN WIKIPEDIA ACCEPTS" story on the basis of anything done here) but past outcomes have seriously soured people to certain kinds of relationships (enough that as a result Wikimedia generally no longer does partnerships with commercial entities),  and plenty of companies stumble in wanting to make a "donation" when really what they're trying to do is buy their name in lights on a top 10 website.

A lot of people have ideologies, and think they can buy their way into making them Wikimedia's ideology too.  Wikimedia has the luxury of being able to be offended by these offers.  Success here would instead be finding out how your ideology and Wikimedia's are actually complementary and overlap, not in creating a bounty that might be perceived as selling out to benefit some private interest unrelated to Wikimedia's ideology.

Careful communication is required to avoid stepping on Wikimedia specific and Bitcoin specific rakes in this kind of discussion.

That wasn't just some link I googled up cold.  You appear to be ignoring that I am telling you that your actions are politically inadvisable, and that they are at risk of playing into the reservations you supposedly hope to address.

I don't think this is a great idea.

The outgoing Wikimedia chairman is my partner for the last decade, and I have a long personal involvement in Wikimedia.  In light of my experience, I have to say that I'm amused by this thread.

Soliciting funds on behalf of Wikimedia from random forum members in order to hold a fundrasing "ransom" is not likely to help convince senior wikimedia executive staff (Or some of its well known and outspoken community members) who steadfastly believe Bitcoin is inherently a scam and Bitcoin users are a mixture of rubes and scammers.

(And, as an aside, as a matter of current policy— Wikimedia doesn't generally take funds with strings attached, and has never— to the best of my knowledge— accepted donations which required promoting the donor on the site's pages (beyond the pages that list donors, of course), even ones much larger than the Bitcoin community is likely to offer. Wikimedia also does not generally accept gifts in kind. I can only imagine that a promotion-encumbered "donation" offer would only improve the credibility of people arguing that Bitcoin is a pump-and-dump scam.)

If we were to make a real effort at getting Wikimedia accepting Bitcoin, we'd do better to broker a conversation between kindred parties at say the FSF or EFF (Or the internet archive, which partially pays their staff in Bitcoin) that already accept Bitcoin with the appropriate people at Wikimedia, along with offers of advice from Bitcoin experienced people.

But even if successful, I'm unsure of what value this effort would have for the Bitcoin community.  Wikimedia receiving coins to immediately turn them into USD doesn't contribute to the Bitcoin economy beyond perhaps helping out some payment processor or exchange.  Better to just do it yourself— perhaps even retain the potential of taking a logistically simple tax write-off on the donation. ... Or save your donations for places which will pay their staff in Bitcoin, which helps bring more people into the Bitcoin economy, like the Internet Archive or to projects which our community is more likely to understand the value of than the general public.

It also may be worth mentioning that the NYC wikimedia chapter accepts bitcoin (and presumably some of the other regional chapters would if asked).

You use testnet for this. Start bitcoin(d/qt) with -testnet=1.

No, no easy way to do that.  Plus the software to actually help you do that would be more complicated than the software required to make super-sure that this can't happen.  (e.g. select the nonce as sha256(message||privkey||random value) — though if your RNG is bad you also need to worry about weak keys))

And for bitcoin-qt:

From the top level bitcoin source directory,

qmake-qt4 USE_UPNP=- BDB_LIB_PATH='/usr/lib64/libdb4/' BDB_INCLUDE_PATH='/usr/include/libdb4' BOOST_LIB_SUFFIX='-mt'
make -j4

Of course, if these applications didn't constantly reuse addresses the exposure here— whatever the root cause ultimately turns out to be— would be a lot smaller.

Lavabit was a web-based email service which kept all email encrypted a key protected by the user's password to how mywallet works. Today lavabit shut down without any advance notice. Details are scarce, but they are claiming that they were being ordered by the us government to do things which they considered wrong. Many believe they were ordered to intercept users (such as Edward Snowden) passwords, or send specific users zero-day exploit code, and chose to shut down rather than comply with the order.

Many other services would and have just simply captured the passwords and gone on with life,  many many more are not designed in such a way that they could even resist such an order. The operators of lavabit appear to have taken a remarkably principled position.

Eventually it seems likely to be that hosted wallet services like blockchain.info's my wallet will encounter a similar interaction with the relevant authorities intent on seizing some funds.

It's possible that they could just comply completely, perhaps they could shutdown like lavabit rather than attempt to betray their user's trust, or maybe there is some other possibility.

What would be a best case outcome there?


Edit:And now silentmail has preemptively shut down rather than be placed in the same position.

A pedantic aside: That is not the raw data, it's a pretty printed form in human/machine readable json. The actual block data is a compact binary serialization.  No disagreement with your comments on SHA256, though.

Please keep BFL (other other unrelated vendor stuff) out of this thread.  As a reminder: the initial post in a thread sets the topic, the other posts should be related to the topic.

I'm suggesting a per-user secret nonce which would provide immunity to partial second preimages too (and, in fact, complete second preimage immunity even if the attacker isn't computationally bounded). This is applicable to some applications and should be used for them...

He's referring to the potential backdooring of Dual_EC_DRBG, an ECC based RNG with a magic point constant which, if you knew the discrete log of it you could use to derive the rng state from a few of its outputs.

If you're using them just for the purpose of comparing it can be better to first apply a pseudorandom permutation so that a third party couldn't pick values which you will easily mistake.

That SXC answer isn't really great.

This has been covered a number of times times in this forum, I suggest finding one of my posts. E.g. https://bitcointalk.org/index.php?topic=194078.msg2014204#msg2014204

In the reference client checkpoints will play less of a role in the future as better (but more complicated) solutions to the issues mention in that post are deployed.

This should probably be made a topic on the Bitcoin wiki.  I don't think we should sticky this thread, since people are concerned about a conflict of interest with respect to maintenance.

Also, Any such list should point out that anyone can run their own P2Pool node directly as this is the preferred (secure and lower stales) way to run p2pool.

Outside of a few very simply or highly abstract subjects when someone says "optimum" without defining it it usually means they have adopted a confused or very narrow minded view of what they are talking about.

There are many properties we need in Bitcoin which SHA256 is good for.  Foremost being a _very_ trustworthy and well studied cryptographic structure as a primary concern is that it be free of trapdoors.  Matching a cryptographic hash algorithm to the size has little value except for performance, and we already use double-sha256— performance is not a primary consideration (in fact, in the search its intentionally _slow_ and thats the basis of its usefulness as a computational proof of work), and on the validation side sha256 is already enormously fast especially considering that in steady state we only need to process one per ten minutes. Likewise, structure respecting hashes are only relevant when there is a lot of fixed structure, but our headers do not have a lot of fixed structure, they are generally pretty efficiently encoded.

So please, feel free to elaborate on your thoughts but take care to actually define "optimum" and concretely relate how that definition applies to the Bitcoin system in a manner which would improve its trustworthyness or scale in a meaningful way.

Isn't altchains getting exploited when doing this not enough to dissuade this kind of perennial proposal? (IIRC, TRC did this and got owned and had to change rules again)

Moreover, what you're suggesting would make it _much_ easier to exploit a node whos network you've isolated... deny it the honest chain for a while to drive the acceptable difficulty down, then start mining a low difficulty fork to let it count up confirmations and accept your phantom payments.

You've heard incorrectly.
This suggests a pretty substantial misunderstanding of what a quantum computer does. In any case, your conclusion doesn't make any sense.