Here is an example of a design thought process I went through and exemplifies how the CAP theorem flaw in a design can be elusive.
Start with the insight that if the greatest realistic concern with a 51% attack is that it could censor transactions, then if a minority PoW chain could prove that that majority chain is censoring then the minority chain could fork (automatically due to protocol without any politics) without any ability of the majority PoW to attack the fork (in terms of censoring transactions). Problem is there is no way to prove the majority chain has seen a transaction since it refuses to acknowledge it. The minority chain could include the censored transaction, but the majority chain could include more new transactions. There is ambiguity over which chain is the truth and so the Longest Chain Rule (LCR) kicks in and the majority PoW chain is the winner.
I did think of having the majority chain include a hash of the transaction, then later reveal the transaction data, but this doesn't solve the problem (just think it out).
The minority chain needs some way to prove that it included the censored transaction a long time before the last block of the majority chain. The problem is the Second Law of Thermodynamics in that we can't prove that a digital signature/hash occurred before some event in the future. The minority chain can refer to a historic event (e.g. block of the majority chain) when it hashes a block, thus proving a block occurred later than some block on the majority chain, but that doesn't prove that the minority chain wasn't just constructed before any event (i.e. it could have been constructed just now). Thus there is no way for the minority chain to construct the necessary proof. Even employing a timestamp server in various clever formulations won't solve the dilemma of trying to violate the Second Law of Thermodynamics. This is what I mean when I state that the CAP theorem is inviolable.
Thus my idea for permissionless improvement is to make mining unprofitable by limiting the debasement rate yet requiring each transaction to include a level of PoW difficulty. The goal is to keep the PoW power in the hands of the users so their client software can (perhaps automatically?) redirect to delegate full nodes which are not censoring transactions or otherwise maliciously modifying the protocol (e.g. censoring transactions that don't sign a KYC/666 id number).
As I stated in the previous post that
if mining is unprofitable then requiring some PoW with each transaction solves the "
unbounded transactions spam versus centralized oligarchy mining control tradeoff" pointed out by ArticMine which in Satoshi's design requires contention over the block size choice which thus reduces Satoshi's design to a centralized politics because there is no block size which is ideal.
There are at least three design challenges introduced:
- The PoW only has to be recomputed if the prior block on which the PoW share was computed is orphaned.
- The delegates could provide the PoW (compute it more efficiently employing an ASIC) in exchange for a fee.
- The difficulty has to be adjusted so that the block period remains constant.
If the PoW share difficulty is constant and chosen such that it requires at most only a millisecond to compute on most client computers, then the 100s of milliseconds round trip latency cost of paying a delegate server to compute the PoW is more costly to the user than just computing the PoW share locally on his client. The user doesn't care about the increased electricity cost for computing the PoW on less efficient hardware because the cost is miniscule compared to the value of the transaction.
The difficulty can be adjusted as it always is in Satoshi's design as this is orthogonal to the amount of difficulty required for each PoW share.
Thus so far my idea has passed the initial process of searching for a flaw. This is promising. Note this was not my only idea for significant improvement to Satoshi's design, as I explained (but did not yet reveal all details on) up thread.