monsterer, I was observing whether you would find the weakness in my design, but I don't fault you for not seeing it so early in your exposure to this new conceptual design and lacking all the details. I have been afforded months to think about it with full access to all the details.
I was feigning an incorrect (more accurately "an incomplete") design because I was thinking about keeping the following secret for while longer (and also to see if anyone would find the flaw), but I am also thinking some very astute readers (e.g. Bitcoin core devs if they happen to read this) might silently think I am foolish if I don't complete the description of the design.
So now I will elaborate on the fundamental Achilles heel and trade-off compared to Satoshi's design.
That is if users disagree on the objectivity, then the block chain is forked. The users could disagree if they could be fooled about which blocks propagated within the allotted (e.g. 6 seconds) window. Once they disagreed, they might never agree again (but read on for a solution to that). Since users rely on other nodes to relay to them, the objectivity is under the influence of those relay nodes. Well I already stated most of that in my prior post, but I didn't emphasize that the bad outcome is a fork:
---8<---
Realize also that once a listening peer has saved (on the block chain!) that he requires the hash of a given block to be included in any chain he accepts, this is a form of distributed checking pointing too. And also that node doesn't have to be online in the intervening period in to detect that a future chain has or has not incorporated that hash earlier in the chain. Thus the honest inertia aggregates over time, and is not diluted by being off line. It is a form of automated community policing by algorithm.
Note also this is not the same as nodes just checkpointing which ever chain they want to. That would cause chaos and divergence. Instead there is a clear rule about consensus which is defined by PoW in such a way that the only way to monopolize it to control what propagation the users observe (which means global control and thus I shift the security from 50% control to nearly 100% control required). Afaics, the only way to have divergence is for nodes to be lied to about propagation. Here is where the community needs to play a role and maintain a list of honest relay servers and easy-as-pie ways for users to access these automatically configured into clients. I am leading the way on this ease-of-use lesson with my initial coin launch example web-based client. It will be easier than Coinbase and Paypal, yet the user controls his own coins (and private key).
Whereas, Satoshi's design forces acceptance of the longest chain of PoW thus eliminating the risk of a fork due to disagreeing perspectives on propagation, but at the cost of incurring double-spend risk, 49+% attacks, selfish mining attacks (and for faster 1-confirmations of Bitcoin-NG incurring DDoS attacks).
Besides the problem of objective relaying,
any window of time results in disagreement due to minute differences in propagation near to the end of the window! Ouch!
Both problems can be fixed by changing my protocol rule from
honest chain's next block must include the nominations from any that occurred in the 6 second window to
honest chain must include the nominations from all block solutions that occurred (with the same difficulty). Thus the difficulty has to be calculated counting all block solutions.
Thus chains can't diverge, except if they disagree about the difficulty. The objectivity about difficulty is a combination of using very long periods for the calculation so that difficulty is the same in calculations that differ only in small changes in the blocks included can't result in half or double the difficulty (since difficulty increments are a factor of 2 since they are the leading bits of the PoW with a 0 value), and the rule that the correct difficulty is the one that counts the most difficulty in the numerator.
That entirely fixes the fork risk. It also virtually eliminates the trust issues around the relay nodes. The community only needs to verify they relay, not that they relay within very dubious small windows of time, e.g. 6 seconds.
And the inspiration for that conceptually comes from the same way I fixed the selfish mining problem mathematically in 2014 by rewarding all PoW in the orphaned chains. That ends up being one of the most important discoveries I've made, yet it was unceremoniously ignored:
Note that rule could not be grafted onto Satoshi's design for an additional reason to those I enumerated in a prior post on this page. That is it essentially removes the requirement to mine at the end of the chain, because there is no objectivity about when a block's computation had to begin. But this isn't a problem in my design, because my design doesn't depend on blocks to confirm the 1 second transactions and thus it doesn't matter if some percentage of the PoW resources are not applied to updating the checkpoints of the confirmation nodes. In short, everything is additive except for double-spends. However this does raise an issue for double-spends documented below.
Note there are other issues that revolve around how checkpoints of the confirmation nodes are recorded in the PoW block chain. Normally these are accumulative (same as for nominations) and can't mathematically be a conflicting double-spend (according to a quorum mechanism that is similar to the one employed in Dash's Evolution except the quorums don't change on every block as that introduces a double-spend risk on time windows on the order of the block period which would otherwise defeat the point of 1 second confirmations,
which btw is a critical flaw in Dash's Evolution especially because it is based on Satoshi's design which allows chains to be orphaned). My design also requires a fallback mechanism where the payer is having difficulty finding a cooperative quorum due to the 49 - 99% attacker having a majority of the confirmation nodes. In that case the transactions have to be confirmed by the block chain. For this case, the payees need to wait until all confirmation nodes confirm all confirmation nodes in some number of block confirmations (just like in Satoshi's design) before it is more probable that the merging of all block chains can't have a conflicting double-spend. Double-spends within that interval are invalid upon merge. The objectivity is counting block confirmations (of the same difficulty) regardless which chain they are on. Again my conceptual fix to the selfish mining attack continues to be the solution to objectivity in every place where objectivity would fail otherwise. The potential subjectivity is due to a block solution built off a historic block that attempts to introduce a double-spend. The objectivity is that the block chain will reject this block because it attempts to mine too far into the past (again by counting the number of blocks). So the attack this enables is that the 49 - 99% attacker could build a longer chain has double-spends compared to the honest chain and which starts from far back in history, so then it is not objective as to which chain is honest, because neither chain can merge with the other. Here the objectivity is longer-term propagation (not 6 second windows but counted blocks) trumps and so any chain that was hidden and suddenly revealed from many blocks back in history is the dishonest chain. So what we end up with, is that there is no incentive to mine at the end of the chain if you aren't producing double-spends. However, the problem of subjectivity around the end of the window still applies to counting blocks. When receive more than one block within the propagation window, then if differing arrangements of the order of those block produce different answers as to whether a spend was double-spent or was already confirmed before the double-spend arrived, there is no objectivity. So to fix this we must abandon the feature of having a fallback mechanism to have a transaction confirmation by the block chain. Instead we can have a designated node that can supplant the quorum and this node also changes (but not every block) in the same mechanism as for the quorum (basing on the entropy of the historical block chain). Thus eventually the payer will be able to get confirmation on a node that is not the adversary, except that the adversary can precompute the entropy and try to game theory his nominations changes to prevent that eventuality (but the success of which may be foiled by making the period of confirmation node nomination longer than the number of confirmation nodes, so that all nodes are cycled through before a change can be made to the confirmation nodes). Anonymous transactions (Zerocash style where the IP address can't be correlated across transactions) would be another solution so the adversary can't easily determine which transactions to censor. Realize a vote wouldn't work (adversary controls most of the confirmation nodes) to provide permissionless guarantee, which is one of the critical flaws in the Railblocks design.
And that seems to cover all the scenarios. Whew.