I can't digest the proposal, because it is missing so many critical details, such as how the next SH for next TB is selected. If you have millions of SH, this is critical as your turn may from a practical stand point never come in time, thus is another vector that can be attacked.
I have mentioned how this works in a post or two in this thread. The hash of the SH signatures signing the CB is used to generate the next random number. At this point there is a slight weakness where the very last person to sign the CB has two options in determining this random number: sign the CB and come what may, or don't sign the CB and lose 3k DCR. The CB will only be signed in the order of SHs, so an attacker will not be able to determine which of his sockpuppets could use this best to his advantage. And in a sufficiently large network, there will probably always be a few stragglers who missed their TB, so the attacker will have to play a dangerous game just to potentially choose one of two outcomes of how CNPs are paid, for example.
There are so many details that you are skipping over here.
Assuming you mean that every SH has to sign to each CB (the one that comes every days and should be a compilation of all intervening TBs), are you assuming that is random because of new SHs entering the SH pool since the prior CB? And so are you saying that each SH chooses a hash for itself when it joins, then it can't game this because it can't know a priori which SHs will enter the SH pool before the deadline of the next CB?
If my assumptions above are correct, then it means new SHs can't be selected to sign a TB until after the next CB.
But I am confused because it seems you may be referring to a hash of signatures of SHs which signed the TBs that in the CB? Because why is signing the CB relevant?
You need to explain your system much more eloquently and tersely. It is very difficult to grasp the fundamental design in as few words as possible.
In all my thought experiments, consensus fails because no one can differentiate between the rogues and the accurate baseline. The only way to get consensus is to give absolute power to a peer to decide for each TB. The author needs to clearly address this fundamental point first. Perhaps if he clearly addresses this, it will become clear to him that I am correct in my assertion.
Perhaps you should wait for my reply before asserting your correctness. You claim no one can differentiate rogue and honest peers, I claim you are biased with a bitcoin view of security. In bitcoin, it is not easy to determine which chain might be an attacking one, or even that there is an attack occurring because of the nature of anonymous proof-of-work. With proof-of-consensus, TBs are tied to individual shareholders who can't be drowned out by someone with a bigger piece of hardware. An attacker wanting to "51% attack" the network is going to accomplish nothing better than causing two distinct chains: one that has (100 - attacker's shares)% consensus with (attacker's share)% of consensus provably shown to be working on a different (and incorrect) CB, whereas the attacking network must ignore the honest chain.
How do we prove which is the attack chain and which is the honest chain? Please try to be clearer in your writing. Write with the perspective of the reader who has no idea what is in your mind.
A smarter attacker might instead keep his TBs lying in wait in an attempt to make it look like the honest network is the evil network and dropping valid TBs, but there is an easy first line of defense to this: the CNPs. Honest CNPs will not transmit data that is obviously out of order, so not only must an attacker control a large portion of the consensus, but he must also control a large portion of the network itself, akin to controlling the entire internet in a sufficiently large system. Since CNPs are paid for their work, a very large constituency of the honest decrits-using population will be incentivized to be monitoring the network at all times, and this same constituency is providing the view of the network. However, it is, in theory, possible that the attacker does also control a significant portion of the CNPs (at this point this guy somehow controls between 0.25-1% of all the decrits in existence in a system where currency production is unbound and distributed randomly), so there is also the second line of defense.
We pay the bankers to enslave us. Don't use capital as a defense, because socialism always gives more capital to the those who will promise everything to the masses.
I have no idea what makes a CNP different than a SH. Because your proposal is so complex, it sounds like handwaving.
Please try to reduce it to simplified first concepts. So we can see what you are actually proposing which is unique and do thought experiments on failure modes.
I am genuinely hoping you have something good here, but you should be able to explain the essential aspect in a simple way please.
The second line of defense is that SHs, while generally anonymous in the sense that they can't be easily tied to an identity, are not anonymous in the sense of proof-of-work--this is the flawed view of consensus that the bitcoin proof-of-work security bias engenders. An attacking group of SHs can *not* hide that they are attacking the network because even if they control almost all of the CNPs, everyone still knows that there is a large percentage of the consensus missing because signatures are missing--you can never infer missing proof-of-work. Even the newbiest of newbie nodes can recognize this.
Okay I like this fundamental conceptual point. Missing signatures apparently is a key aspect of your design. But no where in your original explanation do you start by explaining this. And I still don't understand how technically that can be enforced on a fork.
Now, the kicker comes in to play with the fact that no one is forced to accept anyone's view of the network. There is no concept of "there can be only one block chain" because this is a massive vulnerability. An attacker has no choice but to split the network into two groups, honest and dishonest SHs, with each side eventually destroying the shares of the other. At this point, nodes who have not been paying attention to the network will have a tough time deciding which is the real network (but not *that* tough because unless the attacker has been part of the network since its inception and has grown along with it, it will look obvious based on the consensus history which network is the one attacking).
How is that technically identified and please explain it in simple language?
However, this is remedied in the easiest of ways: honest merchants and people are all going to claim they are on the honest side, while EvilCorp's massive collusion of SHs will not have many or any everyday merchants or people claiming it is the correct network. Even without this, the attacking network can't do *anything* nefarious because everyone is watching. They could only hope that everyone decides to use their network, *then* pull something nefarious. In the mean time, both networks have to operate fairly identically, or all nodes will be able to identify which one is doing bad things and use the good one.
Capital can buy many peers. How to identify which ones are the good ones? Especially if the bad ones are only dropping transactions from those not playing by the rules of their cartel which by that time includes most of the popular merchants?
In the end, sure it may cause some confusion. But to obtain this type of power over the network, nothing can be done in secret. Decrits will have to be purchased in massive quantities, empowering the network and causing more coins to be created and spread out. Once the attack commences and completes, the evil network will lose all of its shares in the honest network and whatever fiat power was used to cause this attack is destroyed and its value is now possessed by the users of Decrits. The attacker cannot simply reconfigure his hashing power attack to stay ahead of developer patches, his attacking power is now completely spent, impossible to use again. He has in fact done the opposite of what he likely intended: caused the power of fiat to weaken versus the power of the Decrits system.
I have no idea how this system works. You are speaking about features which I have no idea how it works technically.
You are talking about all things in your mind which the reader has no clue about.
And if the rogues sign TBs but don't put all transactions in them, then control a large % of network, they effectively make undesired transactions incredibly slow (if not forever depending on the ability to game the next SH selection algorithm).
"Incredibly slow" is a matter of opinion. Because TBs are 10 second windows,
The internet can't propagate reliably in 10 seconds. I guess you assume these have to propagate by the next CB?
So how can we avoid duplicated transactions in the TBs? Or are duplicates okay and somehow they get merged for the CB?
But if there is no consensus until the CB, how does anyone trust a TB until it is in a CB after days?
an attacker must control every TB in a row for which it wants to delay a transaction. Whenever an honest node is in the mix, it will add all transactions that were missed. Even with 50% control, delaying transactions for more than 20 or 30 seconds will be difficult and only random opportunity. Important transactions (such as coin blocks or shareholder joins) can't be delayed or CNPs will start dropping malicious TBs. In the future when/if there are more than 100k SHs (if the CB period is 10 CDs, there are 87.6k SHs required for a 1-1 SH->TB ratio per CB), multiple SHs will create TBs for the same time window with one having priority and future TBs acknowledging all of them, with the priority only being in regards to conflicting txes that would cause a negative account balance if both were allowed to be processed. Otherwise all transactions from all TBs for the same time window will be accepted as part of the consensus (or you try denying ones you don't like and causing a network split and back to the same scenario as before). This doesn't even require much duplication of data, being efficient has always been a key priority of mine--see
this post.
Could you unpack that into english please?
Realize that without peer review, you can't be sure that there are not holes in your design. But if we can't understand what you are saying, we can't review it.
