I am thinking we really don't need the miners to process transactions. We only need them to create new coins and to keep a copy of the transactions that occurred independently of the P2P database.
You do realize exactly what the miners do, right? They are not just out there playing the lotto. They are performing vital duties with respect to verifying and validating the block chain. That is what we are paying them for.
Yes of course. I am just thinking whether we can minimize what we need them for. I will need to think more deeply first, and then write it down more technically. I am not sure if what I wrote in the prior post will work. It was just off the top of my head.
My thought == we really only need the SINGLE block chain for the creation of coins. After that, the BILLIONS of private key chains are sufficient independently. Tada! I will explain more once I have thought it out more to make sure my initial intuition is correct.
Think of it like this, the creation of coins has to be agreed by everyone. The transfer of money only has to be agreed between payer and recipient. Just need a localized method of preventing double-spend instead of globalized, which I already offered.
The issue with this revolves around global time. I need to think about this more.
Okay I solved the key technical problem of
consistent global time. This is simply a hash of each block in the chain. Each hash is a marker of relative global time. Really it doesn't need to be a hash, since the blocks will no longer contain transactions. It could just be any deterministic forward infinite series of numbers. Recursive hashes as a choice, adds a cost to targeting too far in the future.
(Side note, global hash time will be known before it happens, i.e. hash of prior hash is deterministically known a priori, so payers can send transactions that occur at known times in the future
)
So thus we don't need the mining peers to bundle the transactions into a block, in order to get collective agreement on when a transaction occurred. Instead, the payer need only include such a global hash in the payment sent, and then peers can
independently save these, thus all peers agree on the "global hash time" the payment was sent.
If the payer sends a double-spend, the peers which have saved the prior conflicting spend will detect this, and we can choose our design whether to either ignore the double-spend or penalize it by confiscating the funds into the ether (lost forever). As I wrote earlier, we can have options for recipients to declare reserves so that payer has incentive not to attempt double-spend, as the reserve would be confiscated to the ether forever.
A double-spend can be achieved by getting peers to disagree about which transaction was sent first (due to network propagation order), if they are both marked with the same "global hash time". But I propose to penalize peers which refuse to mirror all transactions (exact mechanism described later), thus all peers will know there was double-spend. Again I propose the recipient can choose between waiting for sufficient time to be sure a double-spend is nearly impossible, or to attach a forfeitable reserve to insure the recipient will honor the transaction instantly.
The recipient will need to judge for himself (this will be a technology added on by third parties) what the risk factors are, e.g. if recipient can poll a significant proportion of the network for double-spend, then more probabilistic certainty sooner that the double-spend was not sent to any peer. The alternative is the forfeitable reserve optionally set by the recipient, which is unlocked from escrow back to the payer by the peers after the prescribed "global hash time" has been reached.
So therefor the block chain is no longer a block of transactions, but rather the collective agreement of the forward movement of time, and for doing this the mining peers are awarded new coins.
Thus the 51% attack does not exist (or say it isn't a hard line in the sand between functioning and non-functioning system). And cartelization of the mining peers gains nothing except most of the new coins, which is only say 2.5% of per year of the money supply. Note the cartel could still make mining unprofitable by putting enough resources to bear that other miners did not get sufficient ROI for their contributed resources. Restoring debasement does not entirely eliminate the threat of monopolizing mining; rather only diminishes it (requires the cartel to need many more multiples of subsidy than otherwise).
Even if they have 99% the miners, they won't be able to block transactions entirely, and with the penalty for not mirroring transactions, the good peers will be evident to us. We can easily see who is doing mischief and route our transactions through peers we trust. In other words, the community has voting power over which peers to sort of ignore in real-time, without needing a fork. The most the bastards can do is get 2.5% per year.
Possibly we won't be keeping a history of transactions any more (although a peer could record this history), only the latest state of which public key owns which coins. I think we need the history to prevent rewriting history of who owns the money.
In theory, I've posit that I fixed the design of everything major that is wrong with Bitcoin (note my prior posts about improving anonymity).
P.S. The key flaw in my proposed hard-disk-space Proof-of-Work is how do we control the rate at which "block time" progresses? Even if all peers see that block time is going too fast, there is no mechanism to slow it down, since peers act selfishly to send their claim on the next block asap. So I may have to revert to CPU Proof-of-Work. Still thinking on this. Possibly we can require hard-disk work along with scrypt CPU work. Another solution is that if peers see block time is running too fast (outside the latency of network propagation), they can just refuse to accept new block time transmissions for a while. This would not stop transactions from processing. I think this might work.
Satoshi get off my lawn!