Without commenting on the rest, the logic doesn't follow here.  It is not necessary that not doing soda pop buys directly in the Bitcoin blockchain means that Bitcoin hasn't provided people with decenteralized electronic cash.

The Bitcoin blockchain is a very different system from the visa payment work which makes very different trade-offs. It will always be the case that in some respects the bitcoin blockchain doesn't match visa, just as much as visa fails to match Bitcoin.  If you insist your floor wax be a tasty desert topping you may get something which is the worst of all worlds instead.

The UTXO set is not kept in ram, just caches. Block headers are, however... and there are various overheads related to peers and such. Beyond block headers the mempool is probably one of the biggest memory users.

More ram will likely help (actually, I'm somewhat surprised that you're able to compile it with 1GB ram, I assume you have swap too).  Yes, it will benefit from -j2 if your VM has multiple cores.  Also make sure you have ccache installed... that will speed up subsequent compilations.

Don't confuse the "green address" stuff discussed in 2011 with the green address instant confirmation (a feature of the green address multisig wallet service), they're different.

The original green address stuff discussed in 2011 is a horrible systemic risk that was generally rejected by the community— thank god, otherwise MTGOX's implosion this year would have resulted in tens of millions of dollars to businesses spread all around the ecosystem.

It's infrequent that engineering finds a strictly superior solution, — even Bitcoin itself sacrifices many things compared to centeralized payment systems. Usually engineering is about navigating the frontier of best possible tradeoffs.  Within the Bitcoin ecosystem we can hit multiple points on that surface, as the OP notes... but asking to explain them all here is a bit too much.

For a taste of whats possible,  look up micropayment channels,  also look up green address instant transaction confirmation, look up sidechains / two-way-peg (as a more far out and general tool)...  

7400 to 7200 is measurement noise. This isn't to say that we don't need more reachable full nodes run by diverse parties... but this particular datapoint isn't especially interesting. Lowering the cost of running full nodes is certantly something that is actively being worked on.

They're already included since day one. Many of them have long been standard transactions, but for those who are not they don't need to be standard transactions to use them, develop tools for them, or experiment with them. Since a month ago in Master, practically any script encoded as P2SH IsStandard in any case.

Sadly there seems to be fairly little true interest in doing anything advanced or at least in building tools to make things usable to laymen.

There is no need to create a BIP for features that already part of the protocol, though if some transaction form becomes common and people might want to make interoperable implementations and at that point writing up a specification to help front end implementations interop might make sense, but it wouldn't be a bitcoin protocol thing.

A good user interface is no less serious work than a robust protocol— doing it well, and not just pretty, but one that is pretty and easy without losing power or misleading users, is a serious challenge for serious talent... it's an area where more people with skills could step up and help, it's not an area where the existing active contributors are strongest.

If and only if their locktime hasn't passed, I realize you know this, but your message was a bit confusing.

Is anyone selling the 10% off S3 coupons anywhere?

Ah, didn't realize thats what the question was. It's the multibit format.

Yep.  Bitcoin completely prevents a double spend within the context of a single blockchain, no amount of lying nodes or miners can break that. ... but a blockchain is at best only eventually consistent, if you depend on transactions staying put before they're adequately confirmed (or when a lot of hashpower is controlled by a single entity) all bets are off— since the 'eventual blockchain' may not include the transactions you're looking at right now.

The documentation is the integrated online help. use the help rpc on any rpc.

What you sound like you're looking for here is fundamentally impossible. As a rule all nodes impose the constraint that a coin can only be spent once in the chain, if you find a blockchain that has two spends in it it isn't a bitcoin blockchain and your node software will just ignore it as though it were never there.

An actual double-spend that can exist involves getting someone to take an irreversible action based on one spend, while a different spend is what ends up in the long term history— and this has happened many times, primarily against websites (esp gambling sites) that take irreversible actions with 0/1 confirmations.

There is, sipa wrote it but has kind of disowned it after seeing the really non-scalable things it encourages.  Bitcoin core will likely support such a thing some day, but probably only after pruning is in production so that the true costs of operating this way (>30GB disk space currently, and growing) is more obvious.

Storage in the (not so far distant future) will not be free. Talk about "programmed destruction" yikes. What the bytecoin stuff does reduces all the generated coin, including subsidy— what you're suggesting really is a duplicate of it, but less completely considered, please check out the bytecoin whitepaper. I suppose that leaving _out_ the fees at least avoids the bad incentive trap. It's still broken, none the less, and you really can't wave your hands and ignore the fact that subsidy will be pretty small in only a few years... esp with the same approach being apparently ineffective in bytecoin and monero when their subsidy is currently quite large.

This is the approach we were talking about with Bytecoin above.  The income is reduced by a multiple determined as function of size^2. This, sadly, does not work in the long run once subsidy is not an overwhelming portion of miner income, because transactions will just pay miners directly (e.g. just author N different transactions, one for each miner you know of, each including an output for that miner. Eligius started supporting being paid fees in this way in 2011).

A version that wasn't a multiple but instead was an absolute number of coins to destroy might work, since you couldn't escape it by moving fees to outputs— but then you have a free parameter of not knowing the value of a bitcoin to its users— and as we've seen with fees, constants that depend on how much a bitcoin is worth easily get out of wack. Any magical thoughts there?

This doesn't seem to have anything to do with smart contracts though, perhaps you should be using another word here.

The general idea of smart contracts is that the contract itself is a kind of (very-)narrow artificial intelligence which takes care of its own enforcement.

The quadratic disincentive Bytecoin&forks does is very bad, there is no upside to it. It doesn't achieve the advertised end, it encourages people to pay miners directly instead of fees, thus improving the position of large well known miners. (If you just mean using a median-controlled limit— sure, but thats a old proposal in these threads that has nothing to do with bytecoin. I would point out that an explicit desired size is better than an actual size in that calculation, to avoid miners needing to pad their blocks or omit transactions they could have included just to express a desire for another limit).

Sadly there is still no proposal that I've seen which really closes the loop between user capabilities (esp bandwidth handling, as bandwidth appears to be the 'slowest' of the technology to improve), at best I've seen applying some additional local exponential cap based on historical bandwidth numbers, which seems very shaky since small parameter changes can make the difference between too constrained and completely unconstrained easily.  The best proxy I've seen for user choice is protocol rule limits, but those are overly brittle and hard to change.

Petertodd and jdillion previously had a POS-ish voting proposal that might be interesting... but any of that family seemed complex to implement. The notion there was that signers in recent transactions, selected by non-interactive cut and choose using the block hashes weighed by coins days destroyed, could reveal signatures of block-hashes after their transactions in order register approval for increasing the block size.  Since miners can always decrease the blocksize unilatterly and would usually be in favor of increases, and they can censor users— so if the users consent is one sided and needed for increases, and the protocol is constructed so that users can't be forced to give consent in advance except by giving up their private keys— this actually has a fighting chance of keeping the users in the decision.  But there are a lot of free parameters in how it could work... and giving a majority of coin holders a voice is actually a pretty poor proxy for doing something smarter:  Democracy is still an oppressive system which forces the will of some onto others, and those holding the most coins might be large corporations or goverments who benefit from centralization, still better than just handing the decision unilateral to miners.

Please see the fifth post in the thread.