For example, assume a design scenario where the block period T is 10 minutes (600 seconds) and within 6 seconds of a block announcement (note one white paper showed the
weighted average in Bitcoin is 11.37 seconds), it will have propagated to at least 80% of all nodes. Thus the probability of having 2 or more competing chains is approximately 1/100. Before getting into the implications of that fact w.r.t. to my design, first let us note that an entity controlling 50+% of the PoW resources could choose to withhold his block solutions until another one is announced (thus making sure it propagates within the 6 seconds), while continuing to mine on his hidden solution (thus the adversary's chain will ultimately always be longer after sufficient blocks) and thus that 50+% entity will always be able to blacklist (overrule) any minority block announcements. That is the selfish mining attack and it causes the rest of the network to do wasted PoW. However, by rewarding all block solutions that are announced within the propagation window, the attacker's strategy is foiled. In 2014, I had
revealed the math proving that is a solution to the selfish mining attack. However, if we are not interested in just foiling the economic incentive of selfish mining, but we also want to foil the blacklisting incentive, I will hereby reveal another epiphany. We can require that any blocks will follow a contest between chains, must include the nominations (in my design) from both blocks (note we might not be able to, depending on the design be able to incorporate the txns from both chains because there may be double-spend conflicts, but suffice that nominations can't conflict).
Thus the only way for the 50+% adversary to blacklist minority PoW that nominates its nodes is for that adversary to win all the blocks and always announce the blocks as soon as they are found (otherwise the adversary is required to include the nominations from minority announcements if the adversary pursues the selfish strategy mentioned above which defeats the blacklisting). But if the adversary announces block solutions as soon they are found, then the adversary can't statistically win all the block announcements unless it has 100% of the PoW.
Okay the adversary must shift his strategy to fooling the payers (non-full nodes) into believing that the minority did not propagate first (or within for example 6 seconds if we choose 6 seconds as the rule), thus convincing the payers that the minority announcements were not required to be included in the longest chain. If the payers are not listening to the network, they have to trust some full nodes to tell them what happened. If the adversary violates the protocol and doesn't include the minority nominations (because the adversary can fool the payers), then the adversary can own all the nominations and thus report what ever it wants to report to the payers. The typical Bitcoin security argument is the community will call out such an adversary and take action. But I was never satisfied with that reasoning, because the masses are easy to manipulate because they are preoccupied.
So to make my design really robust, the payers need to be listening so they can enforce the protocol. Remember I am making a micro-transaction coin, so the payers will be online often. And often is good enough. Because if the payers clients blacklist the 50+% adversary's chain for violating the protocol, then the adversary could have 99% of the PoW resources, but if they constantly lose a larger and larger share of the payers, then they honest network has forked away from the adversary and filtered it out. This is what I mean by inertia. And also this inertia will become entangled (DAG-like) such that it is impossible to undo this filtering and the 50+% attacker racks up huge losses (in transaction fee revenue and uncompensated PoW). In my design the block announcements don't include any transaction nor PoW share data, so they are very lightweight to propagate.
Note I am still searching for holes in this design. So I am not assuming it is perfect yet. (There are likely issues revolving around conflicts in UTXO between competing chains, i.e. one users is wants the transaction to go on the adversary's chain which another user has observed as the fraudulent chain and is not accepting. The payer would then need to spend on both chains until the conflicting user has observed for itself that the adversary's chain is dishonest, then it would shift over the honest inertia) At the moment, I am preoccupied with getting something launched, so the peer review of the theory will need to wait.
I did take the time to write this part down, because I do have to incorporate some aspects of this design in the coding work I am doing now. So I wanted to make sure that my logic on the necessity of the payer monitoring is correct, because I am incorporating the necessary block chain records so the users of the network have the necessary state persisted for them in the block chain.
Point being that this is going to be easy as pie for a dummy to use. And personal password security should be much easier to deal with.
However, this is nominal operation, not an attack scenario. It does not follow that statistically less orphans means better security, simply because an attack is not nominal operation.
As I explained above, latency is a parameter for the holistic security design when incorporated into a holistic paradigm as I have explained. The higher the latency of propagation (the interval of indeterminism about which block announcement was first and what was the interval between announcements), the larger the block period needed to reduce the incidence of competing chains (if the selfish mining scenario has been defeated given my solutions for defeating selfish mining). The higher the expected (computed probability of) incidence of competing chains, the more often that multiple sets of nominations have to be included (per the epiphany rule I mentioned). This may be acceptable by appropriately dialing down the duration of nomination consummately, assuming that doesn't adversely impact some other important factor.
So in my design the math—for choosing the longest chain to mine on—include the calculations about what is statistically fraudulent.
Taking a guess here, I suspect you have two classes of miner? Type A is the professional miner expending a lot of energy to produce chains of work and type B is the every day user sending transactions already mined by including a POW with the transaction. So the key becomes how to make sure that you cannot impersonate type B miners to throw your new chain selection rule out of whack, since their POW difficulty must be trivially easy to solve.
The PoW from all is unified. Sending PoW with transactions is one way to incentivize users to contribute their CPU resources so the professional miners won't control near to 100% of the PoW. Another way to incentivize them is they will need to pay some PoW to nodes that propagate block announcements to them. Thus while they are online doing microtransactions, their computer will be doing some background mining (but very lightly so, preferably scaled down when CPU load is high, i.e never significant enough for the user to complain about or increase their electricity bill noticeably and on mobile phones not plugged into the charger this really has to be subdued). The user can pay instead using micro-transactions which is more economical except they can perhaps notice this (or maybe not since the entire point of micro-transactions is your don't fuss over small incremental spend decisions). We'll work out this balance over time. These are the short of maturity issues that really require a lot of contributors and people working on the source code. I can't do all of these microscopic optimizations by myself. I am just trying to first get the basic coin launched.
You'll need to prove that the type A miner (with say 1M x the hashing power), cannot have 1M x the influence over the chain selection rule (by, say, impersonating 1M type B miners), otherwise this will collapse to being equivalent to regular longest chain selection rule.
I explained above that yes the entity that controls 50+% of the PoW could monopolize the nominated confirmation nodes by lying to non-full nodes (using that monopoly on nodes) about the propagation events that occurs when the non-full node wasn't listening. But by having non-full nodes listen (only when they are online doing micro-transactions and remember most people these days are online most of the day and if micro-transactions become integrated into everything we do on the internet!), then I explained the 50% adversary can't violate the rule and monopolize.
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).
