Hello Eli_lyd1,

Just started the development process.
1. It's called Takanium - agree it's a bit cheesy but will go with it for now https://github.com/Takanium
2. One super dev on board Looking for many many more.
3. Core would likely use Golang. Performance of C++, developer productivity of Python.
4. Smart contract white paper in process.
5. Smart contract would likely use NodeJS VM. It seems to be the best option at this time.
6. We believe in tested code. Code coverage is expected to be >90%.

Any advise you can give us is very much appreciated.

Regards,
Shunsai

Long timespan scenario - some epochs are not common to forks

Note that there are 2 separate thresholds in play here.

1. >50% threshold for a block to be valid. If the attacker presents less stake than that, there not even an attack fork, the blocks are simply invalid.

2. When the attacker presents attack fork with valid blocks (each block having >50% approval), then the fork selection procedure comes into play. Now that procedure must choose between the real chain vs the attack fork.

3. Fork selection procedure chooses based on signatory stake. The signatory stake in the real chain would be >99% for long timespan history attacks. In order to win, the  attacker must present stake greater than signatory stake in the real chain.

Short timespan scenario - epochs are common to forks

If there are no epochs contained in the attack fork, the fork with maximum approval state at the top wins. By approving a block, parties are also approving the ancestry of that block. So, the block containing the maximum stake on top wins.

Hope this explains it.

I was attempting for a serious and thoughtful discussion . Not sure if we are still having that.


Here are some additional details on the developer checkpoint you provided - https://bitcoin.stackexchange.com/questions/1797/what-are-checkpoints/70824#70824

"It is a long term goal of removing the checkpoints entirely, because they are a source of confusion over the security model and power the developers have. But currently the role they serve is to prevent low difficulty header flooding attacks, and there has been no alternative solution proposed yet (that I know of)."

These checkpoints are clearly not needed for the protocol (otherwise the goal of removing them wouldn't make sense). They seem to be there because of some old software (which is being planned for update), not for protocol reasons. In other words, Bitcoin protocol doesn't need developer checkpoints and will not have any in future.

This relates to 2.2.25 of the paper that describes the fork selection procedure. The attacker would fork from a block such that after that block there would be two possible successor blocks, one of whom is "real" and the other is the attack block.

The fork selection procedure declares winner by determining which of the forks have a higher amount of signatory stake. The real chain would have near 100% stake (assuming the block is months in past) and the attack chain will have all stake of the private keys the attacker owns. Attacker cannot copy transactions from the real chain to the attack chain since they include hash of a recent block.

Each fork must have >50% in order for blocks to be valid - that condition has to be met. But even with >50% stake, the attacker needs to exceed signatory stake that exists in the real chain. Note that signatory stake is stake of all stakeholders in a fork who have
(a) created any block, or
(b) approved any block, or
(c) approved any epoch, or
(d) signed any transaction (transferred or spent their stake) - transactions are context sensitive and contain a recent block hash

For history attack through spent keys item (d) would ensure that the signatories of the real chain hold a very high % of stake.

"Weak subjectivity is the idea that subjectivity is unacceptable for short timespans, but acceptable for long timespans." https://ethereum.stackexchange.com/questions/15659/what-is-weak-subjectivity

Every stake based system that I know of (including Steem, Tezos, EOS, Cardano, Difinity) has the so called "maximum rollback slot count." That means that algorithm is unable to determine the correct fork by itself forcing rejection of a fork that otherwise would win. This results in different honest parties having different views of the chain depending upon how long they have been online. They would have to find someone "trustworthy" among supposedly "untrustworthy" parties. This is Weak Subjectivity and is highly undesirable. If one thinks that Weak Subjectivity is actually desirable, let's start another thread for that discussion.

Proof-of-Approval doesn't need Weak Subjectivity - subjectivity should never be acceptable in short timespan or long.


Can you point me to PoW system that does use developer checkpoint? They shouldn't need it because the external resource consumption of PoW makes it physically impossible to build chains at a faster rate than their resources would permit. With selfish mining, one can stash away mined blocks for use in attack at a later time but they would be giving up earnings now for mounting a future attack.


My quote above was in the context of a party running the node in the cloud. They do not sleep or turn off. They cost $5/month. If the benefit of additional earnings is significantly more than $5/month, a rational party would move their node to cloud.


The design in for 2018 (where cloud connectivity is at 10gbps), not for 2009 with 100mbps connectivity assumption. One can design for 100mbps connectivity but the solution would be trading off something valuable.

Regarding money distribution, I agree with Dan Larimer (https://steemit.com/cardamon/@dan/peer-review-of-cardano-s-ouroboros) that not designing for Pareto is a mistake not the other way around.

Proof-of-Approval does not require the distribution to be Pareto, but it does require the distribution to be not uniform in large group (each party holds small amount of equal stake). No cryptocurrency today has uniform distribution of stake. Proof-of-Approval is highly scalable with stake distribution of any cryptocurrency in existence today.

Not sure how does incentivizing nodes to achieve certain behavior, which is the very basis of the blockchains, can be considered only as the "best-case scenario."

If parties are willing to forego a large income, significantly more than the cost, they are simply not rational. Proof-of-Approval, just like every single blockchain protocol, does assume that the parties are rational. If parties are not rational, what would be motivating them to join the network and buy stake in the first place?

If two competing forks (with epochs) have absolutely equal stake (even to the billionth fraction) at the first separating block, that may result in forking the chain itself. I can't think of a solution for such a situation other than forking the chain.


Nope. The strength of anything is determined by its weakest link. The weakest link is the short timespan consensus. The protocol can handle just under 50% (49.5% from example settings https://medium.com/@shunsai.takahashi/proof-of-approval-a-better-blockchain-consensus-protocol-b19a55dc331b). There is no protocol in existence today that can handle >=50% adversarial power.

The weakest link for a typical stake based protocol, however, is the long timespan history attack scenario. Which is the reason why all stake based protocols rely on Weak Subjectivity (https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/). Proof-of-Approval does not need Weak Subjectivity!

Note that Dan Larimer himself believes that the stake distribution is Pareto. https://steemit.com/cardamon/@dan/peer-review-of-cardano-s-ouroboros.

Bitcoin wealth distribution seems to be Pareto as well. https://medium.com/bambouclub/are-you-in-the-bitcoin-1-a-new-model-of-the-distribution-of-bitcoin-wealth-6adb0d4a6a95. Most researchers seem to agree that Pareto distribution is the correct distribution for wealth. Building a protocol designed for another distribution of wealth would simply be a poor design.


True but no one has been able to achieve it including in cryptocurrency world.


It is a self-selection process incentivized by block approvals. Let's say someone owns s% stake. They can earn epoch approvals by using their home computer or mobile device easily. But for ~$5/month (using a cloud server), they can double their earnings by participating in block approvals. If the increase in earnings is larger than the cost of cloud server, they are likely to choose cloud server. A cloud server is likely to have a very high uptime >99.99%.


I have looked deep into DPOS. In my opinion, all of them (Bitshares, Steem, EOS) they are extremely weak. My first article has some details on them https://medium.com/@shunsai.takahashi/proof-of-approval-a-better-blockchain-consensus-protocol-b19a55dc331b (but note that post is not updated for protocol version 2).

Just to make sure it's the right version of the protocol - https://github.com/Takanium/doc/blob/master/research/proof-of-approval.pdf.

Here are the assumptions.
1. About 10-50 stakeholders get to create a block in any slot. This number can be tweaked using coin roll selection predicate.
2. Stake distribution is Pareto. The protocol is optimized for Pareto distribution.
3. I expect a quorum to be achieved typically by around ~50 large stakeholders. It is slightly more distributed than bitcoin mining pools where just 2-3 form a majority.

Hello D5000, I incorporated epoch approval limits in the latest version of the paper. https://github.com/Takanium/doc/blob/master/research/proof-of-approval.pdf

Hello Ix,

Perhaps we are thinking from slightly different points of view. Individual items that we differ on are likely outcome of the same difference. My point of view follows and I am open to adopting your point of view should I find deficiencies in my thinking.

1. PoW has provided the most robust consensus to date. Bitcoin has withstood assaults from all sides and survived.
2. All PoS systems and their derivatives are not fully trusted by investors. It is reflected in the prices of those tokens. The most valuable tokens are still PoW.
3. PoW burns power. So much power that miners are unprofitable if Bitcoin is below $8,050.
4. The normal supply curve (https://en.wikipedia.org/wiki/Supply_and_demand) does not apply for cryptocurrencies. Bitcoin being below $8,050 doesn't just make some miners unprofitable, it probably makes all miners unprofitable.
5. The normal demand curve also doesn't apply to cryptocurrencies. If the mining permanently stops, all current coins become worthless (because no future transactions will be added to the chain). In similar scenarios, value of other goods drops but not so dramatically.
6. A stake based system, has a break-even price near $0 (compared to Bitcoin's $8,050).
7. If a robust stake based system can be implemented and if it were to be so robust that it can survive all attacks then the investors would trust it and bring it in the same category as Bitcoin and Eth. Or maybe Eth would adopt that stake based system finally (they haven't so far because no system has proven to be robust enough).

That's why I am so focused on robustness. Regarding scaling, I have modeled Proof-of-Approval and counted the bytes transferred and stored. While it does store more than a typical blockchain, and transfers more data, it can easily run at 1sec slot period at today's technology.

Regards,
Shunsai

Hello Paul,


This is in context of long timespan History attack where an attacker acquires private keys of accounts that no longer have stake. The owners of those keys may not have much incentive to keep them private since they themselves have nothing to lose. Therefore, an attacker can acquire them relatively inexpensively. In most stake based systems, these keys must form a majority stake at some point in time. Since creating blocks for PoS doesn't require large computation, the attacker can create a large number of blocks in his favor very quickly and overtake the "real" chain.

Note that this scenario depends upon how frequently the stakes are changing in the network (churn rate). For a typical network, change of 100% network stake from one group of parties to another group is likely to take over several months if not years.

Proof-of-Approval incorporates several features that make the attacker's task difficult.

1. The chain length is counted as the number of slots spanned, not the number of blocks in it. A "real" chain is a lot more likely to have missing blocks than the attack chain. With this rule, the real chain is not penalized.

2. Epoch approvals incentivize even the smallest stakeholder (say a single coin) to participate in epoch approval. Although no claims can be made for the participation rate of epochs, it is highly likely that over a period of month or so, almost all stakeholder would have approved at least one epoch. Over a period of several months or years, it would be even larger.

3. For fork selection with epochs, stakes of all signatories (block creator, block approver, epoch approver, stake transferer) are considered. This is likely to be very close to 100% over a period of months or years.

4. If a 100% churn did occur in the period, all original stakeholders have become signatories for the real chain (100% stake!).

An attack chain can only win by exceeding signatory stake in the "real" chain. If an honest "hodler" is holding .1% stake, it isn't possible for the attacker to acquire the private keys representing the needed stake.

Regards,
Shunsai

Hello Ix,

Done. Moved to https://github.com/Takanium/doc/blob/master/research/proof-of-approval.pdf


By cost of attack, I mean something similar to this https://www.reddit.com/r/ethereum/comments/8m3lpo/an_ethereum_classic_51_attack_would_only_cost_55/. It is the total money an attacker would have to spend for a successful attack. If only a small percentage of stake is wagered (say 5-10%), the cost of a successful attack on that network is likely to be about 5-10% of the total value of the network. For Proof-of-Approval, this is approximately 50%.


That is a very strong statement. There is no protocol in existence today that tolerates adversarial power >=50%. I would love to read the proof if one is available.


The persistence and finality for blockchains are defined (by the research community) from point of view of nodes that are online and honest. For all honest online nodes, the Proof-of-Approval chain will have at most the top block different (finality of 1 block). Is this property for DCA 10 or less?


Proof-of-Approval is designed for a mathematical proof of the stated properties. I could not achieve a mathematical proof with less approvals. If you can, I would love to read the proof.


That is a rule, just like sports or organizations have rules e.g. http://www.gssasoccer.com/Default.aspx?tabid=169249. An action is valid or invalid purely because the rules of that sport/activity/organization say so.


In the very next block. Please see proof of the common prefix property in the paper.


It may be of interest to see what causes nothing-at-stake in the first place. Nothing-at-stake is caused by incorrect incentive system of some early PoS systems that benefited rule violators. Proof-of-Approval removes that incentive, rule violators are punished and violators are incentivized to follow the rules. Is this punishment strong enough? It is if prevents the problem from happening. It is similar to real life - is fine/jail for a crime is sufficient or does it need to be harsher.


I believe this is the correct approach.

Regards,
Shunsai

Hello Ix,


Yes, while some parts are similar, there are large differences between DCA and Proof-of-Approval.
1. DCA's security is based on wagered stake which has opportunity cost. Proof-of-Approval doesn't require a stakeholder losing any opportunity cost.
2. Cost of attack on DCA is limited by wagered amount that is not likely to be a large percentage of total stake due to opportunity cost. Cost of attack on Proof-of-Approval is likely to be much larger.
3. If I understand correctly, all "Voices" in DCA are assumed to be honest. That assumption is probably not valid.
4. Persistence model indicates 10 blocks deposited for finality but it's unclear how "final" that is. Proof-of-Approval achieves finality after 1 block.

Regards,
Shunsai

Hello Yj1190590,


Note that approvers are stakeholders who have most to lose if there is even a possibility of a network compromise. If the network can be compromised, their coin holdings may not change, but value of their coins would. Assuming network stakeholders are rational, why would they do anything to harm themselves? The evidence of wrongdoing is present on the network, just not stored in the chain since it's used in the short timespans not long timespans.



Note that stake distribution is Pareto distribution. Assuming there are approximately 10K nodes on the network, >50% of stake may be held by only ~20-50 nodes. These large stakeholders, wanting to maximize their earnings in the network, would simply operate a cloud instance. These can be as cheap as $5/month! Some of the new ICO offerings call these supernodes, but here, it's simply a self selection process incentivized by more awards (for block-approval and block-creation).



PBFT may sound like a better protocol due to finality but in practice it isn't. PBFT generates consensus on transactions, which are smaller than blocks. For a large number of nodes, it is more difficult to achieve consensus on tiny transactions than larger blocks. Casper (https://arxiv.org/abs/1710.09437) does not improve short timespan finality, i.e. >6 block, its benefit is only for long timespans.

A protocol can make any number of claims but what matters is what it can deliver. For that reason, only 8% of the ICOs reach exchanges (https://news.bitcoin.com/80-of-icos-are-scams-only-8-reach-an-exchange/), other 92% claiming all sort of superiority die even before that. My intent is to have a protocol that can withstand the well known attacks as well as new ones. One cannot build another Bitcoin or Ethereum on false promises.

Regards,
Shunsai

Hello Paul,


Although I have no data on hand, I don't expect a full stake churn to be in less than a month period, more likely in years time period. In such a long period, the "real" chain would have probably accumulated at least one epoch approval from 100% of the stakeholders. So, the attack chain can't win by supermajority (2/3 or 3/4 of stake), it needs 100% of the stake!

Also note that a single honest stakeholder (hodler ) holding a relatively small stake (~.1%) will make such a history attack impossible.



You are correct that epochs cause edge issues (just like any other nonlinearity). Let's do some back of the napkin calculation:
1. Slot 3 sec
2. Number of slots per epoch 1200
3. Epoch period 60 min
Assuming each epoch limits max stake transfer to say <25% of total stake, the full stake transfer can only be done in 4 epochs or 4 hours. In this case, there would be at least 2 epochs without any edge issues. I'd expect >80% stake to be approving at least one of those edge issue free epochs. In other words, while there may be edge issues with epochs, they can be managed without affecting security.



1. What's the common prefix property in that case? I expect k >> 1. This property is more important for commerce than most people realize.
2. How does it defend against history attacks? Stored candidate blocks or uncle references won't defend against history attacks.



1. What desirable property or defense against attacks do these stored candidate blocks provide? I can't think of any.
2. Same for uncle references - what desirable property or defense do they provide? Again, I can't think of any.



This is a good idea. This may help with edge condition of correct fork selection. I would definitely look more into it.

While I may be disagreeing with you on some issues, I absolutely appreciate the thoughtful questions and suggestions you are providing.

Regards,
Shunsai

Not yet :-) I wanted to have at least a level of comfort with the protocol before launching. But the protocol is only one part. Another part that must be defined is the smart contract system. I am currently working on a white paper for that.

Thanks,
Shunsai

Hello Yj1190590,

Block approvers own >50% of the stake. If they approve blocks containing conflicting approvals, that will invite many forking related attacks on the chain including double spend. Approvers can approve another block containing all valid approvals, so they don't benefit by violating the rule. Would a rational stakeholder approve a block that may lead the devaluation of their asset without providing them any benefit? I think not. (This has the same basis as PoS.)


In absence of >50% approvals, no new blocks will be created in those slots. It may not sound that good at first but this is the best policy. It's preferable to not process any transactions than to risk the entire blockchain. Once the connectivity is restored, the stakeholders will approve (or reapprove) the set of blocks offered on top of the previously approved block.


All block based chains like Proof-of-Approval including Bitcoin and Ethereum, have the so called probabilistic finality. The newest 'n' blocks in the chains are not considered stable. For Bitcoin, users want that 'n' to be 6 blocks or more. For Proof-of-Approval, it is just 1 block. 

Regards,
Shunsai

Absolutely! In addition to the size of data, nodes on slow/intermittent connections may not be able to send their approvals for each block.