But wait, isn't that exactly the same as Paypal? Where are the benefits then? What is the difference?
One difference is that there would be dozens, if not hundreds, of bitcoin services to choose from. Consumer choice is never a bad thing. Another difference is that we all have the choice to run our own node if it means that much to us.
Furthermore, Off-chain transaction also means that these private companies will be able to change ther rules.
No it would not.
Finally, what would happen if one of those services gets hacked and all their funds stolen. What would this say about the security of Bitcoin?
That already happened, to Mybitcoin.com. Fortunes were lost, but it was an inditment against Mybitcoin.com's security model, not Bitcoin's.
Paypal uses Fiat and they can't be robbed because they are insured and whatever bank would reverse the thief's transaction. But this is not possible with Bitcoin, which would eventually mean that using a Bitcoin Payment processor is considerably more dangerous than using Fiat payment processors. And since Offchain transactions would be the norm, we would be forced to use them.
No we would not. The only reason that such wallet services would even be viable businesses is if it's generally cheaper to use such services than pay a normal network transaction fee. But there would be any number of ways to avoid such fees, not just the paypal-like bitcoin walet service model. Another that I think would be viable is a Ripple-like overlay network. Another woudl be something similar to what Electrum does with their Stratum overlay network.
I seriously don't see this proposed solution doing any good.
What alternatives do we have?
The Bitcoin community is made up of some of the most brilliant minds in the world. Are you really telling me that we can't find a solution to compress the information on the ledger enough so that a healhy amount of full-nodes always exists?
Of course we can, more than one in fact. But the economic drivers for users to favor services has less to do with the size of the blockchain, and more to do with expected future transaction costs. Currently, transaction fees are being heavily subsidized by block rewards, but future network congestion is bound to force that fee up. The developers are still working on methods of streamlining the network, but at some transaction volume in the future, fees are going to have to total $25K per block to maintain the current level of security. Ideally, we can improve the netowrk's throughput so that the costs are spread across many feee paying transactions, but Visa's average throughput is about 2K TPS, or about 1.2 Million transactions per block, which put the cost per transaction at less than 3 cents each. But if we can't get there, something is going to have to give, because users aren't going to suddenly start paying GAvin's Cost (about 3.3 millibiitcoins per kilobyte) if they can avoid it, and they can avoid it if some portion of their transactions can be done off-network.
Bitcoin is based on consensus, which also means that we can change the code on consensus and even change the way the Blockchain is stored, making it smaller and allowing for increased scalability. We could even tell the software to read / write the blockchain in one way before block X and in a different compressed way after block X.
Compression of the blockchain is impossible, but there is another solution....
1. Pruning the Blockchain
I don't know exactly how pruning works and if it will solve this problem, because I've also read that some full-full nodes would be necessary with pruning. But still, that seems to be a better option than off-chain transactions.
Completely full nodes without pruning of any kind will not be
neccessary per se, but I'd expect that some institutions would want to do it. As for bootstrapping a new client after pruning is the default state, the client could simply be programmed to download the block headers (which are persistant data tha must exist anyway) up until some known block number, and so long as that known block number has a hash that matches the hash that the node has been programmed to expect, and that the whole set of block headers have a single hash that the node has been programmed to expect, that client could treat that special block number as it's own genesis block from that point. After all, users normally create a new wallet'dat file at that point, and it would be strange to need the blocks that existed prior to that point unless you were mining.
2. Creating a Masterblock
Bitcoin works on consensus. If on consensus we can decide the size of the blockchain and the transaction fee, on consensus we could certainly also decide that Block X with hash X is to become the new Origin block.
This is similar to what I described above, but no network consensus about which block is required. That special block can be updated with each realease of a client, and be differant for each indepenantly maintained client.
We take all unspent inputs previous to a certain date and collect them in a Masterblock which is to become the new origin. Aftewards let the blockchain grow considerably longer so that the masterblock is stuck in between the regular chain and impossible to change even with an incredibly large amount of hashing power. Then, after a certain update, we decide on consensus that everything prior to the Masterblock does not need to be downloaded.
Unnecessary.
