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.

Absolutely not. Those are not public functions.

secp256k1_ecdsa_pubkey_create(unsigned char *pubkey, int *pubkeylen, const unsigned char *seckey, int compressed)

Is correct... there is more information in the header that defines it.

No.

Pooling for payment? The network doesn't care, thats a matter which only impacts the miners in question. But the common way that miners are implemented using "stratum" is actively harmful to the network and the security model of the Bitcoin system.

You have completely misunderstood the pooled mining process and how its security arises. No secrecy is required or would be in any way helpful. Pooling is secure because miners send failed lower difficulty attemps ('shares') that prove that they were attempting to mine blocks meeting particular criteria. This proves their work in an unforgable way and protects the pool from the miner. (But nothing protects the miners from the pool with centeralized pools, and pools have "lost" the miners funds many times in the past)

It's just an accident of history that hardware operators commonly completely give up control over their vote, blindly selling their computation to a third party... secure mining is perfectly possible while leaving the operators in control of their vote, just by agreeing to pay the earnings according to the pool's policy. (As is implemented in P2pool, but could also be equally accomplished for centeralized pooling systems too)

Incorrect. A block cannot be 'stolen' because it is immutable once authored. Every attempted block has an independant success probablity, and changing any part of the block results in a totally different block.

Lots of things are being done about it, but they're not done yet. Wheres your contribution?

Clearly you haven't: It's very nearly hlinear with the transactions.  There just were very few transactions in the past. There is a lot of sha256, but most of the import time is spent elsewhere. (ECDSA, writing out the database, etc.). There are some changes in the pipe that make it a fair bit faster.

Off-topic, I know, but a useful tip: Switch to ssh key auth only, the brute forcing tools detect that its hopeless and give up.

It's not good news at all-- It's less than a half cent in value, you'll use about that much or more in marginal transaction fees just to include that input. The value to you is basically zero.  At the same time spending the dust will cause your wallet to interlink addresses, lowering your privacy.  Plus, on top of that, these transactions increase the size of the blockchain on disk and slow down the synchronization time-- making Bitcoin slightly less usable to everyone.

And all this to promote a ponzi scheme. Great.

If you're using bitcoin-qt you can use this to sweep away the dust in an efficient way that also helps gum up stupid 'taint' analysis by effectively coinjoining it off. https://github.com/petertodd/dust-b-gone

What you're proposing there isn't new -- it's older than "stealth adresses", but it has many limitations which the current design was constructed to avoid.

The most important is the one you've noticed, but I think it's worse than you think it is:   It prevents any delegation of scanning because you cannot scan without putting one of you spending keys at risk.  This means that it's not ony incompatible with trezor and other hardware devices,  it's also incompatible with good wallet encryption which keeps your private keys out of memory when not in use.  Keeping spending keys offline is an important security practice, and it would be really terrible to have a design which prevented it.

It also prevents you from using a third party scanning service (at the cost of some privacy), meaning you can only use it if you download the whole blockchain yourself.

It creates an assumption that you have access to the private keys on the coins you're spending. In the case of a shared wallet, vault service, escrow, or coinjoin you do not (or only have some of them). If it relaxes which keys can be used for inputs, it would at least still support the coinjoins but require N fold more ECDH work for the scanner (as it much check each input).

It also makes the user pair mapping staionary. If I pay you some coins, and then later pay you some coins recieved to the same key... it'll use the same address, and thats bad for both our privacy. This also means that I cannot forget where I've sent funds without also forgetting my spending keys.

Then, related to the assumption of private key access, there is the issue that it it creates a bad coupling beyween the spender and the recivers pubkey types. If I start using some new kind of multisig script, or perhaps a hash based signature or something else to control my own funds, then suddenly there are all these addresses which I can no longer directly send to.

I'd originally thought it might be useful to _optionally_ support doing something like this, when the stars and moon align to make it possible... but the required bad security practices and huge slowdowns from having to do lots of extra ecdh to scan made it seem much less attractive. Plus there is a risk that the one side of the optional configuration doesn't exist and you get people unable to use different pubkey types, or people losing funds that were sent to them because their software won't notice the payments.

You just have to have alice and bob prove that they know the discrete logs of their own pubkeys (e.g. they sign a message with it while setting up their exchange). Work through the algebra and you'll see why.

If you have logs for #bitcoin from last year, I walked through the somewhat different pay to contract case, which is I think mostly what you're referring to-- in that case you alwas make the contract key G*HMAC(message,pubkey) to avoid someone setting their pubkey to an alternative contract.

Only that it has linear scaling. Such a signature would be many megabytes in size and would take minutes to verify with state of the art ECC code.

People making extraordinary claims should provide extraordinary evidence.

Separately, No one has paid me for the great many ideas I contributed to Bitcoin and the cryptocurrency world— and most ideas, even good ones, are unworkable for boring engineering or user-factor reasons.

Not so. We proved there were no semantic leaks from OpenSSL in the numbers on the stack via exhaustive testing some time ago and removed all use of OpenSSL from the script code (except the calls out for signature verification, of course— so only signature verification and the accompanying signature serialization are handled by it).
Also not so, very intentionally not.

Including things which are not a function of the transaction changes the model pretty substantially though. There isn't too much that comes to mind as "would also break" but it seems like the sort of thing that may have subtle implications.

Perhaps, but there really isn't a reason that the network couldn't soft fork in more strict time checking such that similar shenanigans would only really work if a supermajority of hashpower was in on it.  An argument against it is that people will use centeralized sources of time if you ask them for second level precision, but thats not fundamental.

I do somewhat wish the nlocktime time check were on the median of 11, which would make the funny business much less attractive— actually that could be a soft-forking change, since the median is strictly less than the block time.  Basically in that case lying about your time wouldn't help you specifically mine a transaction.

You need different Qs if you want multiple signers (in the BRS style) and for them to be mutually anonymous from each other. E.g. to select a group of N out of M trusted parties, where the N don't know who each other are.