This already exists.  In your profile set "Use quick reply on topic display" (under Look and Layout Preferences) to "Shown, On by default".

The normal quote button does exactly that (you can click it on more than one post).

Yes I don't think a full P2P stack is a useful requirement at least not at this point.  A federated network of servers and an open protocol is all that is needed (i.e. a way for a third party to add a server to the network quickly and easily).  There is minimal security risk as the provider can't spoof data it can only fail to provide a lookup when requested (either because it is malicious or because the stored value has been lost).

The storage costs are relatively low.  Redeem scripts are limited to a max of 520 bytes.  Storing them in a key-value database would mean 520+20 bytes per record plus a small amount of database overhead.  That means greater than a million script records per GB of storage.  Storage costs would be reduced by using a DHT but for the forseable future I think that would just be needless complication.  I think the simplest way to handle spam would just be to either not accept a script submission until the scripthash appears in an output in the blockchain or to temporarily accept them but delete them after some reasonable amount of time if they don't appear in the blockchain.

You are probably ahead of your time but it is an interesting project.  I am not sure if leveldb (or any other open source key-value store) handles remote synchronization but it would seem a lightweight protocol could be developed.    Honestly this is probably something which makes sense to eventually be part of the Bitcoin protocol and stored by full nodes but in the interim a federated network sounds like a good idea.  This all assumes the network is created and run for altruistic reasons (or relying on donations). If you are talking about how to commercialize such a service well that is a little trickier, I agree with the previous poster than you probably a years ahead of any commercial demand.

As an alternative you could use the existing Bitcoin network by performing a sequential spend from the P2SH address back to itself.  For the cost of one transaction (which may be free if it is high priority) you have now stored the script in the blockchain permanently.

Well there is the accounting definition and then there is the common usage definition.  Most people saying 'cash' don't mean checking accounts or money market accounts either.  If you go out to lunch and ask your friend if he has enough 'cash' to cover the meal I am pretty sure you don't mean is the balance of his money market accounts greater than the bill presented.  You and he would both assume you are talking about physical slips of paper with dead people on them.

Well since the subsidy will not go to zero for another 120-130 years most discussions about costs, energy, and sustainability deal with the period from now until ~2140.   Even after the next couple halvings the subsidy will play a major impact in the cost of the network.

Terminology is important.  A orphaned valid block never becomes invalid.  Any client will see it as valid and that is not going change (one exception would be if another longer chain double spends the txn in the orphaned block).

However a valid block isn't all that matters.  For a confirmation to have any weight it must be not just in a valid block but in a valid block which is part of the longest chain.

True a chain which is 90K blocks behind the main chain is probably irrelevant but it isn't invalid.  Invalid has a specific meaning in the Bitcoin network.


Once again terminology matters.  A non-main-chain block is never going to make it into the longest chain (unless the inferior chain becomes longer and thus becomes the longest chain via a reorg) I assume what you mean is that "it is very possible that transactions in the orphaned block may not have made it into the main (longest) chain".

I believe it wasn't known to him or he didn't understand it enough to trust it.  PubKey recovery was certainly known prior to 2009.  There are a number of other "nuts and bolts" decisions (oversights?) which make me believe Satoshi's background was not cryptography.  He probably had exposure to and experience working with cryptography but wasn't a cryptographer.

In addition to PubKey recovery here are just a few other "quirks":
* Transaction Malleability (Bitcoin Specific). It is cumbersome to fix to fix today but with a different txn structure it would be impossible.
* Signature Malleability (ECDSA).  ECDSA can have multiple signatures for the same digest the solution is to either not make the signature part of the txn hash or limit Bitcoin to a single form.
* DER encoding serves no purpose.  Even if OpenSSL was used the DER bits could be striped.
* Lack of Compressed Keys.  Optimally the only valid key would be a compressed key and thus not only is key size reduced but there is only one format to consider.
* Unusual choice of double hashing.  Normally done to prevent length extension attacks which don't exist in Bitcoin.

This isn't to say Satoshi wasn't a genius, the magic in Bitcoin isn't the cryptographic primitives used.  It is in the way he elegantly used existing systems (digital signatures & hashing algorithms) to create a timestamp and consensus finding system that is very simple and yet very difficult to attack.

You could use timelock encryption to protect your private key (or better the seed for an HD wallet).

https://news.ycombinator.com/item?id=7847687
The example involves public release but it could be used privately as well.  If you have a large number of cores you can compute a large number of chains in parallel but to recreate the chain you can only work sequentially.

I don't remember Satoshi ever saying that the purpose of Bitcoin was to enable tax evasion.  I could be wrong lets check.


https://bitcoin.org/bitcoin.pdf

I wonder how many people have not read Satoshi's paper?  I mean honestly it is only 9 pages long.  It is high level concepts and thus approachable to even non-programmers (except maybe the last section "calculations").  Taxes predate modern fiat currencies by thousands of years.  The Romans and Egyptians had taxes and they used precious metals.  So the system of taxation doesn't rely upon the system of fiat currencies.

For non OP_RETURN outputs there are probably no good uses but the original client supported it so to remove it now would require a hard fork.   Short of that the network makes it difficult to use as most nodes will neither relay them or include them in a block but they are still valid.

Zero value outputs are valid (although they are non-standard unless output type is OP_RETURN). 

Remove all transaction validation as well.  ECDSA signature validation is especially CPU heavy. 

However I wonder if this is an xy problem.  If this is just for an initial sync (i.e. one time) then it is far easier to transfer the blockchain as Pieter pointed out and run the stock client.  However if you intend to remain connected to the trusted node(s) (and no other untrusted nodes) then you might as well be running an SPV client/codebase to reduce the resource requirements on the target machine continually.  In essence the bitcoind on the remote computer is asking as an border router for your custom application/code.

Maybe there is a market for a breathalizer activated hard wallet.

To the OP.  Bitcoin is like cash.  It would be like going into a store planning on buying a $1 TV and you bought a $10K TV in cash.  There is no way to "reverse" cash.  Your only solution is to talk to the company you sent the funds to.  If they agree to send the funds back and cancel/modify the order then you are fine (no different than cash).  If they don't well that is a problem (once again no different than cash).

Your right so we should restore the original unbroken 33,554,432 byte limit on messages (to include blocks) from the original client.

By the same logic we should reduce the block limit down to 125KB right?  The "1MB limit" was simply a round number chosen for crude anti dos type attacks in the early network when mining was very easy.  It was a hack and code solution to the reality that a single malicious user could bloat the blockchain by TBs with essentially no cost and hamper or kill adoption overnight.  

For the record the original client had no 1MB limit on blocks.  It only had a 33,554,432 byte limit on messages and thus no txn or block could be larger than that (because they wouldn't be a valid message).  But they a 25MB txn in a 33.5MB block would have been valid for the first 18 months of the network. Even there it is unknown if that was some design choice or rather just a sanity value (i.e. to prevent an developer error which leads to a number of accidental giant blocks or txns and thus increase the early blockchain by 10000% in a few seconds).  

Also I hope this doesn't kill the cult of the divine megabyte but the commit which added the "1MB limit" wasn't even authored by Satoshi (at least not according to git) and was lumped in casually with a number of other fixes title "fix openssl linkage problems, disable minimize to tray on Linux because it has too many problems including a CPU peg bug"
https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349

Also this "limit" wasn't much of a limit as it only prevented the client from making >1MB blocks.  A modified client could have created larger blocks and the network would have accepted them as valid.  The network didn't start checking the size of blocks until a couple months later:
https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730

Today no but properly done a hard fork is a 6-9 month process.  Hell it almost took that long for P2SH.   We are roughly 35% to 40% of max capacity and txn volume over the last year (in a major bitcoin decline) still doubled.  Over a longer period of time it has grown more like 3x to 5x per year.  Waiting till 100% of blocks are 1MB and there is a 50,000 txn backlog is probably the wrong time to start discussing the issue.

How hard is it to jump out of a plane?  Not hard at all.  Just open the door and jump.  Surviving the jump is the hard part.

With Bitcoin the absolute worst case scenario would be large portion of the network supports both versions after the fork.  It would be catastrophic for everyone involved.  Also miners alone can't do anything.   They need to support from users, merchants, exchanges, and developers.    Imagine for a second if 80% of miners upgraded their software so that they gave themselves 500 BTC per block instead of 25 BTC.  What would happen?  Well the network would fork.  80% of miners would be mining inflata-bitcoin and 20% would be mining standard-bitcoin.  There would be two simultaneous mutually incompatible networks.  Now the reality is 99.9% of non miners will reject the idea of boosting the block reward so they will never upgrade and the miners who switched just ended up mining some worthless altcoins.

The same thing applies to raising the block limit.  Everyone (or technically just a super majority but more is better) needs to switch. Until that happens there would be two simultaneous mutually incompatible networks.    The hard part isn't the technical code change.  The hard part is to build consensus so that when the switch occurs it will be painless.   Based on the outcome of the last hard fork (P2SH) it is a 6 month process.  This is done to ensure that when the switch occurs everyone is already "pre-upgraded".  Miners can indicate support by marking blocks with a tag.  Clients can be created which support larger blocks after some future bockheight.  Alert messages will be used to continually warn non-compliant users that they risk being forked off the majority of the network.

So like jumping out of a plane the switch itself is both easy and quick.  The hard part is the prep to ensure nobody gets hurt in the process.  If done right when the first >1MB is created almost all of the network has long since upgraded and it is anti climactic.

Good point.  The average txn is ~560 bytes so it involves 9 blocks to complete the SHA256 hash.   The output is then 32 bytes which requires only 1 more block to perform the second hash.  So 10 vs 9 blocks on the average txn.  However this is offset by the fact that each txn will be hashed again in the merkle tree which would require 2 blocks for SHA256 (due to padding and length value the last block in SHA256 can't hold full 64 bytes) or 3 blocks for SHA256d.  So it is more like 11 blocks vs 13 blocks but that is only ~20% more not 100% more.

No a very old (can't remember which one you can check all the github commits and release notes) version of the client always made the change address last but it hasn't been that way for a very long time.

Any merchant accepting zero confirm txns would be smart to have a large number of listening nodes which detect the second txn and then halt the purchase.