I think you're failing to understand your responsibility in creating an alternative implementation.

As far as I can tell you're not even attempting to find the incompatibilities.   Requiring me to do unpaid auditing of every (sometimes pointless) reimplementation that shows up does not scale. Ensuring compatibility is actually _most_ of the effort required to create a Bitcoin implementation, and so effectively— though I'm sure you don't intend it— by releasing incompatible code and encouraging others to imitate it you're actually attempting to externalize most of your development costs onto me.  We need to find a better way to ensure the quality of alternative implementations.

(You aren't unique in this, MatthewLM's implementation is also incorrect. But at least at the moment I've found fewer issues with it than yours)

My complaint isn't simply that I know your implementation is incorrect— it's that it hasn't had the care and effort applied to make it correct.  At least right now I know that it's wrong, if I simply point out some issues then it will _still_ probably be wrong, since it still will not have had enough care and effort applied— but we won't be able to tell.   Right is better than it's-wrong-and-I-know-it which is better than it-might-be-wrong-and-we-have-no-idea.

Right now the best I can offer is that I'll keep checking and will tell you when you've finally created and/or used tests strong enough to detect your mistakes and have fixed the ones that I'm aware of.  So long as your implementation is still in development and no one has to use it, I believe this path will result in the best long term outcome for everyone— since the tests that find what I know will likely turn up problems that I don't know about.

The absolute maximum long term average bandwidth pulling the blockchain can take is about 13.3kbit/sec.  I'm not sure what the source of your issues is— it may be due to bandwidth used relaying blocks and transactions to other peers, but you do have enough bandwidth to stay synchronized— at least to within a couple blocks of most current.

Claims like "I am afraid that any remedy will only push out your timeline running a full node a few months or a year. "   are just factually untrue on the data that you've provided. And, if  the "business of running a full node, (...) become(s) as serious as it is now to be a mining pool operator" then bitcoin will be dead and pointless, because running a full node has no _business case_ as it can't be directly monetized and there is always an incentive to let someone else take the cost if the cost is great enough to not be inconsequential. If fairly few parties run Bitcoin, then Bitcoin would fail at its purpose of requiring less trust than the commercial banks of democratic nations, as their trust model is stronger. Fortunately, the design of the Bitcoin actually prohibits this loss of decentralization from happening— Blocks have a maximum size (and the size of blocks nodes will create is further artificially constrained by current implementations), and this bounds the cost of running a full node. This size can not be increased without a hardfork of identical technical complexity to changing the supply of coins— so to pull it off it would have to be utterly uncontroversial, and presumably people will always stand up to insist Bitcoin remain practically decenteralized.  The maximum cost is still a bit high relative to current hardware, but it won't be in a couple years with a few more cranks of the silicon and storage scaling laws.

That said, for a mobile connection— a thin or lite client is the obvious thing to use.  Ideally, you could run one behind a full node that you have absolute trust over (E.g. because you own it), and then you don't even need to worry about the potentially reduced trust model involved.

But it would still be interesting to figure out why your node isn't keeping up.

Fragmenting your coins into additional TXOUTs can actually  be very poisonous for privacy because you end up cross contaminating all your payments with linked sets of scriptpubkeys.  None of the clients I'm aware of make _any_ effort to aggregate TXOUTs at all, aggregation which intentionally duplicates common-scriptpubkey-input payments would both reduce txout set size and increase privacy.   Though a significant fraction of the current bloat has nothing to do with spending/aggregation patterns— it's mostly due to a single party using effectively-unspendably small (1e-8) txouts for "messaging".

On my own main wallet— (which does none of that crappy bloaty stuff, just regular real economic activity), I was able to reduce my unspent txout set from about 1000 in total to about 91 through taint aware aggregation while simultaneously greatly increasing the privacy of my future transactions.

On the subject of cache,

The UTXO set does not need to fit in memory to have high performance. Even without memory the current implementation should have O(log (N_UTXO))*seek_delay  scaling per txin queried, and could have ~O(1)*seek_delay if the backend db wasn't ordered.  Even if memory is not enough to fit the whole working set in ram having part of it (esp the upper tree levels in the ordered database) is quite helpful.  For future evidence of this, on many systems leveldb alone (without ultraprune) got most of the speedup of leveldb+ultraprune (as did ultraprune alone without leveldb)... much of the slowness of pre-0.8  reference clients is just due to BDB.

It is however not correct and complete, and if you imitate grau's code as it currently stands you will not be compatible with Bitcoin.

You also must start up with the detachdb argument set and shut down cleanly.

In any case, if the poster decides to delete it they should at least keep the wallet— which is small.  No one should ever delete a wallet which has ever had coins sent to it.  If nothing else, if you're _sure_ you don't want it— post it to the forum or email it to me or something.
 

I contacted several forum users who had used addresses in the list in their signatures.

I've received a couple responses:

1Pq7zKpZHLaT9yheWyHqQp8XUtvTmt7VTm - blockchain.info / iPad app
18ix3ikc51sKTwmfho5fjmfqe2miJBQR2c - blockchain.info / chrome (no code pinning/extension, I asked)

This is the prior output addresses of these transactions inputs— the owners of these addresses are the likely parties operating the software which creates these non-standard signatures is on this webpage. I moved it off the forum so you could easily see which links were already visited for you (the default forum color scheme gets in the way of that).

I also included google links so you can go searching deeper.  So far, people on IRC were able to identify TheButterZone as 1TBZYXjrGjXCEN1SprpF66Jzy5uN3GiLS.

Since people are missing it:
This link has addresses instead of txids.

I'm certain that you're wrong there. The attempts that I'm aware of that have gone even somewhat close to this have resulted in invalid blocks, so if it was widely being done the invalid blocks would probably be noticeable.

It does— the transaction will not be relayed if it doesn't pass all the free criteria: no dust outputs, small size, and priority greater than 57600000 (COIN * 144 / 250).  Priority is the sum(value*confirms)/data_size. (Otherwise someone could flood out the whole network easily)

At just >50% you probability of success is only "always 100%" after infinite time (for an arbitrarily large reorg). With <50% you can attack multiple times and be successful at least once after enough tries.  There is a tradeoff that makes different values of attacks against different amount of confirmations economically viable for different levels of hashpower, but it's easy to overstate a the significance of having a simple majority.

Someone with— say— 40% hashpower can happily create six block reorgs with enough success that they can be profitable for transaction values which are not unusually high. The practical position for someone with 50.1% is hardly any different, especially considering that additional hashpower coming on line or users adopting a checkpoint before their fork gets ahead creates considerable chance of failure even if their current rate would be a majority— so the long attacks that a majority makes _theoretical_ possible are probably much riskier than the short attacks that available to someone with a large but not majority hashpower. A seven block reorg is all you need to rob mtgox.  And why would you attack if you had all that hash power?  If you've compromised the systems controlling a significant consolation you may well decide to both attack and take all the coins you can... Doing so has a good short term payoff so long as your attack isn't great enough to instantly undermine confidence in Bitcoin with certainty.

Assuming that there is anyone using the old one— the way you'd actually do this change is that you'd write it, validate it, test it.. and then agree that it would become active as of block  now+16 years (or whatever).  Then everyone has 16 years to update, and after than new blocks are interpreted the new way.

This sort of thing could be done for changes which are clearly necessary and uncontroversial— and I'd guess a precision increase would fit that bill if bitcoin ever deflated to the point where it seemed like it would eventually be an issue—, but it's not generally viable otherwise.

People looking to run nodes on small hardware may have better luck with something like http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G135341370451

(quad 1.7ghz, 2gb ram; $89)

Sure, they are the canaries in the coalmine. 

Thanks, but…

That doesn't really answer what I was saying... The site has the secret: otherwise it couldn't use it for notifications.  Okay, so supposedly the admins don't have access to it now—  but the same could have been accomplished all along by not creating a webform specifically for people to query by address or (if they have database access) denying them access to the relevant table/column. So I'm still not seeing how the hash added something material. Perhaps better than not, but it's really unrelated to the central issue of creating a whole user interface to query by something that many people believed wasn't even queryable by the site operator.

The only way I can see to secure this mapping is with the help of a third party.  Here is how that would work: the user would encrypt their private info with a random key and give it to blockchain.info. Blockchain.info would return a random ID for that blob.  they'd take every address for each address make a message Encrypt_to_thirdpary(address,Encrypt_to_blockchain(blobID||randomkey||nonce)) and give it to blockchain.info.  Blockchain would queue up and mix a bunch of these from many users.. and pass it to the third party.. who could decrypt them.. and watch for transactions. As transactions come in, they'd send a batch of encrypted blob IDs per block to blockchain. Blockchain would decrypt, and then decrypt the addresses and send out notices.

This would: Completely hide the private info from blockchain in the event that no notice is sent, make it easy for blockchain to not keep decrypted private info around accidentally,  obsecure the connection between addresses and personal info from everyone unless blockchain and the third party cooperate. It would thoroughly hide the connection between addresses in a wallet.  But if blockchain was analyzing when certain ID's got notified could eventually map out which was which— though someone watching their outbound email could too. It would have the downside of introducing points of failure and probably isn't worth the complexity. The third party would learn which addresses are being watched by blockchain users. But it would be an improvement in a way the hash is not.

Hm. This certainly wasn't my understanding of what the claimed properties were of the wallets, though I don't know how didn't remember it if it was on the site. 

I don't see how hashed addresses helps in the slightest against this particular incident when someone would query for a particular address. You could still query by address, the query would hash the provided address and return the match.  Someone could also still enumerate all the interesting addresses from a copy of this database: they'd just hash all the addresses in the blockchain and use that to reverse the hash for every address that has been already used.

It would be most useful to have this done with 0.8 (which is not out yet) since it has much more efficient blockchain management. (e.g. far fewer writes)

Removing wallet.dat, debug.log, and database/  directory (shut down cleanly with the detatch option first), and system logs (e.g. /var/log/messages/*), and then fill the empty space on the media with zeros would remove your personal information, someone who received it from you would need to trust that you did not compromise the blockchain (or the software! for that matter).

You can create an image of the SDHC card by connecting it to a GNU/Linux system, and running dd if=/dev/sdb of=rpi-bitcoin.img   where sdb is whatever device the SDHC card showed up (see dmesg output).

I would not recommend using an rpi for mining simply because it's quite slow and might result in a higher orphan rate— if people are looking for a low power mining solution there are a number of much faster arm boards (and bitcoind will soon use multicore fairly effectively for validation) out there, and small intel x86_64 systems can be quite power efficient especially with power management enabled (w/ bitcoin a node can probably spend a lot of time in low power mode).

Note: there have been some rare crashes on arm with current code that have been reported but haven't been tracked down yet.

I believe this thread indicates that Roger Ver was able to trace the ownership of one of your anonymous addresses via administrative access on your systems.  At least based on a quick review this would appear to be conclusive proof that your claims about logging were inaccurate.  Or to be more specific, you in fact had a web query page available to staff/support/investors which allowed querying by data that you above claimed not to log. Not only was the data being logged, but it was intentionally being logged and there was an easy to use lookup tool. Can you correct my understanding?

The files distributed there are signed by a quorum of developers via the gitian deterministic build process.  The software released there is fully audtiable and anyone can download it, compare the differences to prior versions, and repeat the build process to get the exact binaries and contribute their signatures. It's not perfect— as not many users bother checking the signatures. But they can, and because there are no push updates even a small base of users checking provides a degree of protection.

Uh. This is untrue.

First, grover just gives you a sqrt() speedup.  So double the number of bits and you're done against it. It's very important, but not terribly relevant to crypto security.

Lamport signatures are intuitively QC and classically strong, and I have never heard anyone even suggest an attack class that would attack lamport signatures without breaking all other practical signature implementations (because all practical signature algorithms use a hash on the input first).   The down side is that you're looking at 16kb+ signatures, which is why we don't have them in Bitcoin today.  (AFAIK all of the other post QC signature systems have big signatures/keys/ or both... as well as the questionable classical security that you mention).

Which brings up a point that has been missed in this discussion: ECDSA is not fundamental to bitcoin's "design"— e.g. you don't see it mentioned in bitcoin.pdf.  Should ECDSA begin looking like it may be becoming practically insecure, one of the reserved nop instructions could be deployed to activate another signature scheme (Lamport, perhaps, if nothing better comes along) in a way which is backward compatible with existing software.

Moreover, when Bitcoin is used correctly— addresses only used once— the fact that we send coins to the hash of a pubkey and only disclose the pubkey on spending constitutes a kind of abbreviated Guy Fawkes signature system, so an ECDSA weakness would not be an effective attack unless it could be pulled off in the limited time between announcing a transaction and it becoming buried in the chain.

I can't imagine how the implementation of Bitcoin could be any better relative to this issue when considering the need to balance speculative security against basic viability— as I think the blockchain would already be about 1TB if it used 512bit lamport. Using ECDSA and having a flexible and upgradable script system that will allow upgrading it is really the only prudence decision. The limited pubkey exposure with proper use provides a little more security.

Dwave's products are not quantum _computers_, and there isn't any debate about that— there is some debate over if they use quantum effects at all but even if they do they're to quantum computers what a machine that can only add is to a classical computer. They aren't even claimed to be quantum turing complete, their design doesn't have any obvious path to become quantum turing complete... and right, they can't do crypto because of this.

Because not all changes are equal.

A new rule that says "No transaction will be permitted which starts with AAA" is compatible with a prior rule "No  transaction will be permitted that starts with AAAAB", because the new rule is a subset of the old one. This can be added incrementally, and enforced by a super-majority of mining participants (a strict majority is unsafe because it may make the network convergence time very long).    If instead the new and old were swapped there it would be a hardfork and all nodes would have to be replaced because it would result in transactions which violate the rules embodied in the software.

[I'm cutting carefully to refrain from getting pulled into explaining specifically why your idea is bad and won't fly, as I'm sure a dozen other people are currently wasting their time doing that in your thread]
I suspect I may have discovered the source of your difficulties with How to Win Friends and Influence People— you're not actually reading anything are you?  ... because I just explained above that the system enforces its rules autonomously, with no reference to a majority... it doesn't matter how many nodes think that it's fine for a block to take other people's coin or summon a million extra Bitcoin in existence... Your node will never believe it. The rules a node enforces are not set by a majority, a supermajority, or whatever. The rules are hardcoded and embody the system's unbreakable software contract.  You can replace the software on your own computers but that doesn't change anything in the behavior of other people's computers.

It's been discussed many times before. It is very unlikely this idea will gain significant traction for all the reasons you're no doubt being told in your thread. This kind of proposal would simply be a lot more interesting in the altcoin forum simply because it wouldn't have the scythe of never-going-to-happen hanging over its neck, wouldn't have the specter of people being afraid of the contract being broken biasing the arguments, and would have a receptive audience of people looking for novel technical and economic solutions. Even in existing altcoins there should be increased receptiveness to this kind of idea, simply because they need to do something to be interesting and worthwhile compared to Bitcoin, and people have far less invested in them. (Though even there, I'm not quite sure exactly how welcome it would be simply because it is repetitive).
 
In Bitcoin I'm doubtful that anything below "this must happen" can ever be a hardforking change... and I think that highly speculative 100 year out stuff doesn't really belong in the technical forum either.