I will repeat what I wrote with emphasis:


It seems your system will not converge on a single fork then. Which is the same as getting stuck.

It is impossible that you have 1 block finality and 50% quorums (in any meaningful definition of 'block'). Breaks the invariants of physics. We will find the flaw.

@anonymint replied:


In all due respect, I presume you have not understood the vulnerability I described which I will quote again for you because AFAICT you have not responded to the specifics of the vulnerability:


I think you have not yet understood that by not approving (i.e. not voting for) any candidate blocks the attacker can make the chain stuck because the honest stake will become divided-and-conquered by voting on different candidate blocks for the same slot. The vulnerability is a little bit convoluted. Do you understand now?

Thus the math of finality will relate to the relative stake of the honest and attacker and the probability of honest stake being divided on multiple block candidates.

Remember that because you slash (delete) votes for duplicate candidates with different parents, then honest stake cannot vote for all candidates. They must choose. But how can they objectively choose? They can't.

---

Okay thanks for the clarification.

AFAICT, this does not apply to the vulnerability of multiple block candidates dividing the honest vote which I already described, except perhaps to make it worse by proliferating forks.

However, open ended slots and epochs thus make finality indefinite. There is no longer finality within any time limit. So it is deceptive to compare finality by counting blocks when blocks can be indefinitely delayed.

Also how can subsequent blocks and epochs complete when blocks may arrive late at any time in the future? Does that mean many candidate parent forks?

My intuition is afraid this is going to open many attack vectors. But we'll need to analyze in detail.

You are quoting out-of-context. Please kindly review the context in which the above quote was written.
@anonymint knows that you currently have multiple block candidates per slot in PoA.
The reference to a single-block candidate per slot was because you must change to a single block candidate to try to fix the vulnerability he explained exists with the multiple block candidates.

This discussion is going become very confusing if quoting and responding out of context.

This is because addresses don't expire, not because of the intractability of another user being able to generate the same address. However, presuming each transaction designates inputs tied to specific UTXO outputs (so that other payments to the same public key address do not conflict) and not applying it to (or finding an analogous construction for) scripts, then a plausible design is to declare that any conflicting spend (seen by any witness and posted to the chain) from a specific output would always be a double-spend that burns all the outputs of all such conflicting transactions, but that incurs numerous issues some of which have been mentioned in this thread and other issues were mentioned recently in other thread. Most notably that the double-spend rule has to expire else the payee is forever held hostage.

I noticed my friend replied to that blog.

Craig Wright[1] had documented that a new block propagates within roughly 1 second to something on the order of ~98% of the hashrate. But the 1000s of nodes in the remaining ~2% of the hashrate can see significant delays. Mining nodes prioritize their connectivity to nodes which generate block solutions, because being late on mining a new block solution costs money.

Thus non-mining nodes are essentially ignored by the consensus system of Nakamoto proof-of-work. That is why user activated fork is nonsense. The only way the non-mining users can overrule the miners is to change the proof-of-work hash of the system (which is centralization because voting and politics is centralized manipulation).

Your non-mining full node can enable you to objectively validate transactions (which is not possible in ANY proof-of-stake systems), but can't have any appreciable impact on the consensus.

[1] Yeah I know he makes mistakes and is irritating, but a few of his points are correct.

Made some edits to this posts:
https://bitcointalk.org/index.php?topic=3913439.msg39309531#msg39309531

---

@anonymint wrote on Medium:

Non-sequitur. (intended in a friendly, not condescending tone)


The physical body is not just composed of local information.
It is also interwined with gravity which is a macro information phenomenon:
https://steemit.com/science/@anonymint/the-golden-knowledge-age-is-rising

AFAICT, the slashing protection is only intended to be effective against a short-term double-spend, but it's flawed anyway.
Thus AFAICT the long-range attacker who has 50%+1 can rewrite the entire chain, thus wouldn’t have any hindrance due to the epoch window even if it wasn't flawed.
The 50%+1 attacker can in theory divide-and-conquer the vested interests.
Thus the 50%+1 attacker doesn’t even have the opportunity cost that @monsterer2 is writing about.


Concur and concur.

---

Note the NaS 50%+1 attack issue is separate from the liveness and probabilistic finality issues that @anonymint has explained in my prior post.

Quantum mechanics is utterly incomplete.
Physicists are starting to come to grips with possibility of the multiverse.

Time is but an illusion of mutual circumstance.
As virtual reality becomes more realistic, what reality do you really exist in?

Isn't that what everyone (including @gmaxwell as he admitted) thought about the likelihood of someone solving the Byzantine Generals Problem in that way Bitcoin did.

Curious. Do you have any analysis to share or is that just your personal opinion? Just asking.

I am repeating here verbatium what I received from @anonymint in chat, because I don't claim sufficient expertise to judge whether the following is correct or not...

---

I (@anonymint) quickly read most of the Proof-of-Approval paper. And I’m nearly certain I found the specific flaw.

_{In a sane world @Traxo wouldn’t have to relay this and make a disclaimer, but this can be (in other threads) at times a very special forum.}


AFAICT, the probabilistic nature of your design is hidden in an attack on the liveness. Also there’s a synchronization (network synchrony assumption) flaw in the expiration of the slots and epochs.

The flaws in consensus systems can be very subtle. It gets quite tricky to analyze them. It seems to help in the analysis process to have a holistic conceptualization of the two major variations of Byzantine fault tolerance (BFT) which I will also explain below.


The comparison to Ouroboros follows in this post. I think you will see that your design shares the analogous probabilistic finality of Ouroboros. Perhaps when you quantify mathematically the flaw I have described below then you will arrive at analogous equations for your design. Although I haven’t actually dug into the nitty-gritty specifics of Ouroboros because AFAICT I don’t need to. I believe I already understand its strengths and weakness from the conceptual level, as I claim you will see below.


One of the drawbacks of hosting PDF files on Github the PDF can’t be objectively archived with archive.org. Thus there’s no way to capture snapshots in case the github is deleted or the edit history reverted.

I wish someone could get Github to fix that flaw. In the meantime, I wish PDFs would be alternatively hosted at a url which can be archived.

---

Section 1.1.1 History or Costless Simulation Attack downplays the plausibility of this quorum busting attack which AFAICT also applies to Proof-of-Approval. AFAICT, your design doesn’t eliminate this attack (c.f. near the end of this post).

I suggest that your paper should acknowledge that the attackers could have been the owners of those private keys from inception of the chain, such as for example how ICO issuers surreptiously buy the ICO from themselves awarding themselves 80+% of the token supply so they can manipulate the exchanges. That is the norm, not the exception. Or bought up at 50 satoshis per token during a cryptowinter. However, in that case you could argue that quorum busting attack is always possible at any time, and I would reply that’s true yet I think the whale oligarchs want to extract maximum rents from the system with more subtly parasitic schemes such as the following.

So selling all for BTC as they pump up the price buying from themselves on exchanges, taking leveraged short positions on exchanges, then attacking to double-spend the tokens back to themselves again which can crater the price driving up the value of their short positions. Then repeat the long-range attack as the price rises anew. Wash-rinse-repeat over and over. Nice corrupt world we live in. (Oh and don’t forget to hire some trolls to pick fights and bribe some mods to chase away those who want to write about the fraud)

Note the percentage of the stake required to attack the quorum depends on the variant of BFT employed. And for the DPoS permissioned variant then that degenerates to the quorum percentage required for electing the set of validators. Thus a DPoS system which requires only 50%+1 of majority to elect the witnesses (aka validators) degenerates from ⅔ quorums required for permissioned validation (without slashing, c.f. below). The ⅔ quorums are required for permissioned validation because alternative blocks are competing with each other due to the lack of slashing of conflicting duplicate votes (again c.f. below for the explanation of slashing). Thus a 50%+1 attack on DPoS elections can double-spent. Actually the DPoS elections are even more vulnerable than that as I explained in the EOS section of Part 1 of my latest blog.

---

Section 1.1.3 Nothing at Stake Attack states:


In a consensus system with a permissionless validator set (i.e. BFT 2f + 1) and thus probabilistic finality, even if they were online at the time of the attack, users have no triangulated objectivity about which fork is the 50%+1 attacker or the “honest” fork. It’s ambiguous. Thus users they have no way to disincentivize fork attacks. A liveness attack is only by censoring blocks and/or transactions, yet the chain always moves forward if there’s at least one functioning validator. Censorship also can’t be objectively proven. Finality of a fork is measured only probabilistically. This is because it can’t be objectively proven at what time the validator set was entirely counted, because time is relative in blockchains and not absolute (i.e. not objectively triangulated) and permissionless means the validator set is not know a priori before the consensus round.

In a consensus systems with a permissioned validator set (i.e. BFT 3f + 1) and thus 100% probability of finality if the BFT ⅓-1 liveness and ⅔ safety thresholds are not exceeded, users have objectivity about forks but no objectivity about an attack on liveness. If the ⅔ safety threshold is exceeded then there's also no objectivity about forks. Censorship also can’t be objectively proven when the ⅔ safety threshold is exceeded (although it can be proven in some designs below that threshold). Finality is 100% absolute if less then ⅓ of the validator set is dishonest. If the liveness threshold is exceeded and the chain is stuck, it can’t be objectively proven if the validators are intentionally not responding.

@anonymint explained and discussed this in more detail with @Ix recently.

These are the inviolable ground rules. Any claim which doesn’t obey those rules is presumably incorrect (unless they’ve somehow derived and proven some new mathematical finding in BFT which is probably less likely than being struck by lightning).

---

Section 2.1 Summary states:


Without clock synchronization this is the analogous flaw that I explained is in Ethereum Casper's slashing conceptualization. The conflicting approval can arrive at any time in the future. There’s no objectivity about the end of a slot or epoch unless there’s a consensus that makes the epoch final. And 100% finality requires a permissioned validator set and ⅔ quorums. Time is relative in blockchains.

The math of safety requires that (in the absence of a synchronized clock with slashing then) for a slot to be final then the quorum size must be ⅔ of the stake. @monsterer2 would be correct about the lack of safety margin in Proof-of-Approval— if not for the slashing aspect explained below. Without ⅔ quorums, the math is that there’s no safety because the overlap of dishonest validators in two elections is greater than the quorum percentage of 50%+1 and thus the finality is only probabilistic. With ⅔ quorums then the dishonest validators are at most less than ⅓ + ⅓ in any two elections which is less than the quorum size of ⅔. Again I refer readers to go read the derivation of the math which was linked already in this discussion thread already.

If you instead have assumed synchronization with an external clock (which is also a security weakness), then you can slash (delete) stake votes that vote for conflicting forks, but this converts your system to a permissioned validator set (the entire stake) and creates a liveness threshold. The 50%+1 of honest stakeholders are divided to vote on two or more block candidates such that no block attains 50%+1 because the 50%-1 attacker can choose not to vote thus making the chain stuck. If you instead only allow one block proposal per slot, the attacker can try to attack the randomization with stake grinding to always win the block election roll process. If that is proven to be intractable for the attacker (as is apparently the case in Ouroboros and Algorand), the attacker will still cause to 50%-1 of the slots to be empty. Proof-of-Approval thus does not achieve 100% finality within 1 block. So please correct your Medium post which makes that claim in comparison to Ouroboros. And the attacker can attempt to DDoS attack or bribe the roll designated block proposer for each single block for each slot. IOW, single block proposals per slot are a semi-centralized design.

Additionally the presumption of an expiration time for slots and epochs is fundamentally flawed. I (@anonymint under my other usernames such as @iamnotback or @TPTB_need_war) had discussed in 2016 why this is flawed. That discussion took place in either the decentralization thread or a thread I had created to brainstorm names for the altcoin I was developing. AFAIR, @monsterer (who is now @monsterer2) and/or @smooth had participated in that discussion. I do not have time to go digging through those long threads to find the specific posts, but from memory I recall that I had explained that there’s no way to triangulate when the end of the slot or epoch exactly occurred. Each node may have a different record of which events in the network were just before and after the expiration. There’s no possible solution, not even increasing the size of the error window that straddles the expiration tie.

Thus the slashing of votes by stake assumed by Proof-of-Approval is fundamentally flawed because it will be ambiguous which were slashed around the time of expiration. I had of course contemplated the design of Proof-of-Approval in 2015 or 2016, but discarded it as being too flawed. This is why I get frustrated w.r.t. the impact on my time (which I need for working on my project) to analyze all these various attempts to fix proof-of-stake, because they always come back to the same flaws that we had already enumerated in 2016. This is why for the past 2–3 years I have said that Vitalik et al are hyping vaporware for Ethereum scaling that can never happen. And why I have said that the DPoS that powers EOS, STEEM, CARDANO, etc can only function as an oligarchy of the stake that (often in obfuscated schemes) extracts maximum rents from the users.

Section 2.2.5 Slot states:


This means only users that are live can know which network messages arrived within a slot and it presumes that clock synchronization can’t be attacked. It also presumes that a quorum of users observe roughly the same network synchrony and were live. Those are already notable security weaknesses (potential failure modes) which I think your design shares with Ouroboros.

Section 2.1 Summary states:


Thus your consensus system has probabilistic finality analogous to Ouroboros. And unless your design has the cryptographically secure randomization that Ouroboros employs, then your design is not provably secure and is prone to the typical attacks on proof-of-stake such as stake grinding.


I don’t see the cryptographic proof that this is sufficient randomization to avoid all proof-of-stake attacks, especially the stake-grinding attack which causes a proof-of-stake to degenerate into proof-of-work unless an oligarchy of stake is in control. Ouroboros apparently has a formal proof that their cryptographic randomization is complete and secure.


How so? Where's the security proof?

Regarding Theorem 3.6 your paper states:


The long-range attack is a quorum bust (e.g. 50%+1) attack. Thus they can re-sign the epochs they need to. Thus this proof is incorrect.


Earlier in this post I provided two scenarios where the majority of the stake could be obtained for free or nearly free in the past. So why do you necessarily assume the attacker has to obtain them in the present. Proof-of-stake are oligarchy systems. The oligarchy takes ownership and then maximizes the rents extracted.


I didn’t intend to give you a bad day. Hopefully this helps you in some way not to waste time and effort. We can discuss further on Medium if you like where I am not banned. I will probably reply to one of your Medium, so you can respond to me there if you wish. Cheers also. Hopefully we’ll find a good solution for secure, decentralized, scalable consensus systems but physics may force us to pick any two of those three attributes.

Again after consulting with @anonymint in chat...

Ditto.

When you hurl ad hominems it is "mild" in your opinion, but when @anonymint responds in kind to teach you how disruptive it is for you to hurl them in the first place, he in your opinion is somehow overreacting.
You have very strange sense of fairness.
I bet you've observed in your life that you do not get along very well with others (other than perhaps your grandma and her perfect omniscient objectivity of ambiguous asynchronous partial orders).

You're moving the goalposts because you were defeated on the prior points. Now you're constructing strawmen.
Nobody cares what you think, they care what you formally prove as for the safety and security of your proposed Decrits consensus system.

When you have formal proofs in your whitepaper, then we can talk. Until then, you're becoming a waste of time again same as 2013.

You're writing a load of incomprehensible handwaving nonsense to confuse n00bs.
There's 2f + 1 and 3f + 1 BFT. Learn the attributes that apply to each.
Your designs must fit into one of those mathematical models. Period.

Not necessarily.
Refer to Part 2 of @anonymint's recent blog. Byteball and Hashgraph are 100% asynchronous.
You simply do not have a very coherent conceptualization of BFT.

This is the last reply you will receive to your nonsense. You go ahead building strawmen and such in your replies.

If ever you have a formalisation of your design, then we can do peer review of it.

---

Update:@Ix and @anonymint shared some amicable discussion in private messaging.

Disagree.

Neither does anybody else, certainly not Vitalik nor any other so called "crypto experts".

Seriously nobody knows how to make ledgers decentralized.
That is the reality.

I just asked him in private chat. Here's what was conveyed to me.

Please refer to the links in his most recent blog about the illness that slowed him down so much.

He has been seeing a very slight and gradual improvement in his gut health in 2018.
Remember it was in 2017 that he did the 6 months of very liver toxic antibiotics for curing the Tuberculosis.
He is 53 this June, so it's a difficult recovery for him considering that his gut was already messed up (perforated acute ulcer that burned his internal organs with stomach acid in 2012) and numerous tropical infections he accumulated such as Dengue, etc..
He was also prescribed 24 days of fluoroquinolones in 2012 which are known to cause long-term side-effects.
He has problems with his Achilles tendons now which is one of the known long-term auto-immunity impacts.
Those antibiotics basically destroy athletes.
Probably why we are seeing so many ruptured Achilles tendons in the NBA now and can be due to the dye they use when doing MRIs routinely which accumulates in the brain.

Anyway, his health was in a mess, yet he is still athletic even for his age and trying his damndest to fight and recover.
He just started taking baking soda (see this: https://medicalxpress.com/news/2018-04-soda-inexpensive-safe-combat-autoimmune.html), to try to mute the autoimmunity cascade (that will then cause sudden pimples on his face and chronic fatigue) he gets after every meal. For example, he mentioned the baking soda and gut health in recent discussion on Github.
He has cysts all over his spleen and liver and these cause episodes of chronic fatigue and brain fog that make it impossible to think and work.
As I said, his condition appears to be improving and he is gaining more and more consistent hours where he feels alert and can work.
And he recently completed 16 consecutive days of running and gym workouts (boxing, barbell, etc).
He got his 40 yard dash time back up to the low 5 second range which isn't too bad for his age and health condition.

So presuming his health continues to stabilize and especially with the baking soda treatment which he thinks is having a positive effect so far, then a 2018 launch is within the realm of possibility.
But if his health continues to slow him down as much as it still is even now, then not likely a 2018 launch.

He is sparing no minute or ounce of energy trying to willpower his body and also to try to find more suitable people to delegate to.
But it is very difficult to find experts to delegate to because most people would rather work on their own projects because everybody wants to sell their own ICO.
The ICO bubble is killing any sort of rationality on the part of programmers and engineers.
The rational ones are staying in their existing careers and not shifting to blockchain work.


I will update you as the situation and prognosis changes.



When @anonymint remarked in chat that I would be able to brag that I am crypto expert (because of the knowledge of his I relayed recently), I joked to @anonymint, that I would pretend to be him, launch an ICO and then disappear to Kiribati. Lol.
For the record, @anonymint says there will not be an ICO. Instead there will be a decentralized onboarding which will enable speculators to obtain CRED tokens in the free market.

I discussed this with @anonymint in private chat and here's basically what was conveyed to me (he is in the Philippines and myself in Europe and I'm not using a VPN):


Incorrect.
Firstly, there's no zero sum game in the wealth effect of share markets (float versus marketcap, liquidity versus confidence, externalities of shorting, etc).
There’s tremendous elasticity due to speculative bubbles overshoot and then corrective crashes.
Your misunderstanding belies a correct understanding of markets and game theory as well.

There's far too many moving parts and degrees-of-freedom for there to be some sort tightly constrained mathematical relationship between minute changes in the economic weight and the attacker's loss or profit.
The Medium post that was cited explains some of the scenarios where your presumption fails.
And there are an unbounded many such scenarios.
The entropy even just on earth is not so tightly constrained as you seem to presume.


Did you see @anonymint's face while participating in discussions with him in 2013? What shade of blue was it? Purplish, lavenderish, cerulean, or cobalt?

There you go again with your curmudgeon demeanor injecting ad hominem personalization of what should be a factual exchange of ideas.

@anonymint can play that ad homimen game too if you prefer to continue slandering him, "that @Ix would even contemplate such an INANE and NAIVE concept shows that he's the one who everyone should be skeptical about. Sorry but frankly."

Please kindly refer to the discussion and links to the “math of liveness and safety” in @anonymint's latest blog and past writings.

I'm sorry but you'll need to understand the rigor of Byzantine fault tolerance and stop handwaving with ad hoc descriptions.
Point to the mathematical proof of your system, otherwise you're just trolling.

<meta>You're ostensibly pissed off at @anonymint for ad hoc discussions in 2013 about your Decrits consensus system, where you had not even published a whitepaper and he kept asking you for a more formal description of your system.</meta>


Mild punishment is still a game theory error.
And the point is since you can't punish non-responding validators, then you can't have both 100% finality and assured liveness.
And without 100% finality then there's no absolute objectivity by which all of the live users who were online at the time of the attack can accurately distinguish which fork they should choose.
Thus for this reason and the numerous degrees-of-freedom in the ways an attacker can profit, there's no actual disincentive for the attacker as you presume.

Sorry. As I said, the reality can be a bit depressing.
But blaming the reality on @anonymint is not sane. As if he has control over the reality.

Because you apparently don't understand the formalism of Byzantine fault tolerant systems.


Your incorrect presumption has been refuted above.

Multiple partial orders are ambiguous due to network asynchrony.
That is fundamental INVIOLABLE finding of the FLP theorem from the 1980s That's the entire reason a total ordering is required in these consensus system.


You seem to not comprehend the formalism of Byzantine fault tolerance and the ambiguity thereof when relying on network synchrony.



You're conflating connectivity with synchrony. Too different concepts.
It's like conflating gas stations and gasoline. Exemplifies that you have no fscking clue of the subject matter.

Btw, @anonymint explained that mesh networks are fantasy that will never happen due to economics and liveness. I would have to dig up the link to that Steemit post and also I think he posted about it on the Corbett Report recently.

@anonymint says that is impossible.
You would be defying the inviolable mathematics of BFT systems.
He says there's a flaw somewhere in your conceptualization of your design.
But he does not have time to help find it.
But that math is inviolable.

He is going to add this link to footnote 7 on that Part 2 of the blog:  fork*-consistency

See also this exchange between @Fuserleer and @Come-from-Beyond.

@tromp and @anonymint analyzed this over the past years.
It's not just the latency of memory access, but the power cost.
Memory can be optimized for the access patterns and power cost profile can be optimized.
The ASIC will always be at least an order-of-magnitude more efficient than the general purpose hardware:

https://gist.github.com/shelby3/67d990230e2dc9eb8be9e43e0b0b77a7

Some new discussion from the killer.
and here and here and here

Is there any live DEX with significant liquidity?
AFAIK huge liquidity can only be on centralized exchanges because they can offer margin trading.
Just because you don't like some exchange doesn't mean it's bad to get coin listed there.
Polo is not the only one with problems.
For example, Bittrex gets complains as well.


Better than any DEX I think.
Is there any source with information about volumes on various DEXs so we can confirm?