We have intentionally not provided one because it is such a huge footgun and is almost never useful.  Use an external tool to edit the wallet. (which also helpfully makes clear the level of danger in such an operation)

FWIW, it's off now (in the overlay, in the real package when it's pulled) http://www.reddit.com/r/Bitcoin/comments/2iuf4s/lukejrs_public_apology_for_poor_gentoo_packaging/

The security argument for Bitcoin works if you set the price of mining hardware to zero-- Bitcoin is proof of work, the input to work is _energy_. The security argument is generally insensitive to price except at the extreme limit of $0 (and there... there are more things to worry about than reorgs).

You have a mutually exclusive choice for what to do with your units of energy available to you. You can attack, devaluing the Bitcoin you gain from your attacks, or you can mine honestly and protect your existing Bitcoins and the new transaction fees you receive.

The market price of Bitcoin has changed >10 fold in the past and there were no security incidents as a result.

It is already parallel, it does not use the GPU.  Using the GPU effectively will be difficult because there is not that much parallelism available unless you are verifying multiple blocks at once, and communicating with the GPU has huge latencies.  Competing with state of the art cpu code will take state of the art GPU code (my own vanitygen code on the cpu is roughly as fast as the published gpu vanitygen).

I think you should try it, a port of libsecp256k1 to the OpenCL would be pretty interesting and useful. If it were faster we'd probably be willing to do the architectural changes (making it possible to verify multiple blocks at once) to enable using it.

Similar to how one moment in the future people will stop posting half-informed hand-waving to this forum?

You can keep asserting things like this-- but you've given no justification. There is no mechanism by which the security is expected to "rapidly fall to zero" known to me.

Bitcoin core's verification is already parallel.  But there isn't as much parallelism to extract as you might guess, not without extensive architectural changes (e.g. pipelining multiple blocks and accepting partially verified ones). You should not, however, have been seeing it using only one cpu... in fact windows users have frequently complained that it must be broken because it was using all of their cores for minutes at a time.

Keep in mind these techniques don't reduce the amount of data that needs to be sent (except, at most, by a factor of two). They reduce the amount of latency critical data. Keeping up with the blockchain still requires transferring and verifying all the data.

Right. There is a decentralization trade-off at the margin.  But this isn't scaleless-- there is _some_ level, even some level of growth which presents little to no hazard even way down the margin.   The a a soft stewardship goal (not a system rule, since it can't be) the commitment should be that the system should be run so that it fits into an acceptable portion of common residential broadband, so that the system does not become dependant on centralized entities. As some have pointed out, being decenteralized is Bitcoin's major (and perhaps only) strong competitive advantage compared to traditional currencies and payment systems. How to meet that goal best is debatable in the specifics.

At the moment there are a bunch of silly low hanging fruit that make running a node more costly than it needs to be; we're even at a case where some people developing on Bitcoin core have told me they've stopped running a node at home. It's hard to reason about the wisdom of these things while the system is still being held back by some warts we've long known how to correct and are in the process of correcting.

That isn't a hash function. It's a signature system (sadly one based on the authors team's own Blake and chacha for performance reasons, instead of more standardized functions).

Its focus is on stateless reusable signatures. The cost is that the signatures are huge by our standards... 41,000 bytes (plus a kilobyte pubkey).  In Bitcoin we shouldn't generally have long lived keys and so a 'few times signature' scheme or a small tree of one time signatures (plus state, which the blockchain can provide) are often better and can be done with dramatically smaller sizes.

Certainly thats something I'd use for software releases, however!

The requirement is that if there is fraud it must be detectable by some user under some path and that they have the ability to create a transferable proof of their detection. You can't achieve stronger than that (e.g. that if there is fraud all users can detect it) under this approach.  The criteria is met if you show the unsummed values (as listed on iwilcox page) or just show the one step deep off-path preimage.

No, more certification weaknesses (around 2^256 work) on reduced round versions.

Handling the non-1:1 case when the 1:1 case is solved is trivial, more challenging is figuring out actual applications where users would opt-into it.  There are silly ones, e.g. "ponzi chain"— I guess one metric for an approach being general and supporting of freedom is that it can accommodate things that sound really ill advised too. .. but I've not really found many idea in the non-1:1 space that I'd realistically expect many to play along with.

One argument might be that it's potentially desirable to have a system where lost coins eventually go to support the system somehow... but that very easily runs into issues with bad incentives as miners can censor transactions to make coins seem lost when they're not.

Depending on what validation rules you choose you can get whatever security "umbrella" you desire. E.g. the sidechain can have consensus rule that their work must also commit to the best valid Bitcoin chain (effectively importing bitcoin validity into the secondary system).  This degrades the tidy isolation that you normally get with no linkage, but it gives full security, complete with incentives (because if you misbehave in the Bitcoin blocks you also lose your blocks in the other system). This is good news, but potentially not a cure all— in the you may still be failing to meet your decentalization objectives even though the hashrate security (ignoring centralization degree) is good (e.g. because the scaling requirements and/or goals of the more profitable secondary system are less decentralization compatible).

The next major version will be v 0.10

We don't generally use BIPs for random UI things.

As far as the idea goes— perhaps. Though I'd recommend adjusting your business plans such that the average of the fees in total is what you worry about; rather than the fees on any particular transaction. Otherwise you're just going to get jammed up and unable to transact when someone has sent you a number of dust inputs and the only way to eliminate them is to pay a somewhat high fee... all your low value transactions will end up failing until you up that limit.

If you know what you are doing and still think you should use a "brainwallet", you don't actually know what you're doing.

Double spending is absolutely and completely precluded in a blockchain. Everyone always checks for double spending already, it's one of the rules.  I suspect you've missed this.

(I'd really recommend some quiet time trying to understand the system instead of so many posts.)

You misunderstand the sense in which I'm using 'server' there. In the sense I'm using it there is always a server (the counterparty to the client).

Anonymint spouts mostly a meaningless mishmash of technical terms; every once in a while a chance mixture may seem to make some sense technically, but I suspect the insight rests entirely in the reader in those cases. If you're listing both myself and he— your listmaker functionality may be in need of calibration.

I haven't stated that I've analyzed the system and believe it sound— it takes significant effort to stand behind such a claim, I haven't had the time, and this is also why I've not released any other software using it. (It's not that it's that hard, but it's a question of priorities. That its already in production, for better or worse, lowers it on my list: If it does turn out to be broken people are already screwed). The underlying RS scheme appears solid, but the exact application in Bytecoin has had less review.  But that I can't currently say I'm completely convinced it's solid doesn't at all prevent me from saying that claims otherwise so far presented sound suspect.

Not just that, though thats true too... it's only harmful to the miners themselves, it's foolish to mine with a centralized pool who could be stealing from you via skimming (or via 'hacking' incidents) but it only harms the miner who chooses to do it.

Stratum continues and cements a historical inertia of conflating pooling for payment (which encourages more small participants by reducing variance) with "selling your vote" on the valid state of the network, creating real centralization which is antithetical to the security model.

There is no technical reason why you can't form your blocks locally, according to your own preference and policy, but pay out the coinbase according to a pool's spec and get credited for that work.

This means that pools create a large centralization risk when there is no need for it to be so to get their benefit.  Indeed, it's arguable that miners can move so they're less of a risk than, say, cloud mining— but in practice miners do not move even when a pool is caught ripping people off (and certantly not quickly).

I'm used to unsophicated people using "encryption" to mean cryptography. As you note there is no encryption in the protocol _at all_, (not just arguably, but unambiguously).  But no need to hang up on a pretty obvious claim over some pedantic word mincing— the meaning was clear enough to me.  If I misread— I'm sure BCX can comment.

A theft bug that cannot be fixed without breaking the system's privacy must be a cryptographic one. Thats a pretty strong claim which deserves some strong evidence. Other systems are using related cryptosystems, and would benefit greatly from knowing it was broken. BCX should publish his discovery.

This is in direct contradiction to your original claim that it cannot be fixed without giving up on anonymity. I call bullshit.