Proof-of-Approval: A Better Blockchain Consensus Protocol

[shunsaitakahashi]

Hello,

Looking for some feedback on a protocol that I have been working on.

Article describing it https://medium.com/@shunsai.takahashi/proof-of-approval-a-better-blockchain-consensus-protocol-b19a55dc331b

Full technical paper - https://github.com/Takanium/doc/blob/bf8f7934bac20d4ce15d8b611cc3525e18618651/research/proof-of-approval.pdf

Comparison with other protocols:


Other comparisons
1. With 2-hop chain Post#25 of this thread https://bitcointalk.org/index.php?topic=3125137.msg33082148#msg33082148
2. With Tendermint Post #35 of this thread https://bitcointalk.org/index.php?topic=3125137.msg33559358#msg33559358


Thanks,
Shunsai

[1715496777]

1715496777

[monsterer2]

Hi Shunsai,

Firstly, congratulations on producing a genuine white paper; there is a lot of rubbish that gets posted here, this is a cut above most.

I've only skimmed the paper, but a few things caught my attention:

* In your description of the ideal blockchain (from the article) you've omitted a very important attribute, 'permissionlessness' (excuse the non-word), which describes the ability of a party interested in participating in the block creation process to do so. Because your protocol is PoS, any interested party requires stake in order to participate in block production, making it permissioned.

* The consensus mechanism is based around timestamps, but there is no objective way to verify a historical timestamp. Doesn't this present a number of problems, e.g bootstrap poisoning?

* You are rewarding newly minted blocks with stake, yet to produce blocks, you require stake. How is this resolved?

* Doesn't the Pareto distribution of stake over time present centralisation concerns?

* How does your protocol deal with the keys-from-the-very-recent-past attack, whereby an attacker purchases newly emptied private keys of very large stake value, then creates a fork where he steals all the stake back for himself?

Cheers, Paul.

[Anti-Cen]

I think the gizmo term "Proof of something" gets taken too far in an effort to gain acceptance
in the crypto world but it is a good document that you have produced and forward booking space
on the block-chain will help things to scale.

You still need to distribute the block-chain and not just replicate it across hundreds of nodes
by moving in two directions instead of just left to right using a linked list as is the case with Bitcoin
but maybe it helps to think about it as a two dimensional arrays instead of one.

Ledgers can have check-sums too and can be used in the second dimension with the chain itself being
held in the top dimension so blocks contain a number of new wallet addresses and a block ledger (second dimension) is
used to represent the wallets transactions.

Each transaction could then reference where the credit came from by including the original wallet address along with the row
number of the other side of the transaction along with the signatures and of course the ledgers will need to be replicated across dozens of
nodes which is not happening in the case of lightning and happens too much (20,000 times) in Bitcoin main block-chain.

[cellard]

No such thing as "better blockchain consensus protocol" until your so called better blockchain consensus protocol has been through hell and back, namely, attacked by all angles on the technical aspect and attacked by all angles in the social engineering aspect (fork attempts by governments, social media attacks such as the twitter handle taken over by a fork, exchanges against you...) this is what Bitcoin has survived.

So far there is no PoW replacement. PoS has been proven to fail with NXT in the past, it wasn't pretty. We've seen IOTA fail big time as well, so DAG doesn't cut it. Hybrid attempts such as Decred.. no one hasn't even bothered to attack it for real yet.

I don't see realistic reasons for anyone to sell their BTC to get anywhere else.

[shunsaitakahashi]

Hello Paul,

I appreciate your kind words and your taking time to review this work. Please see rest of my comments inline.

* In your description of the ideal blockchain (from the article) you've omitted a very important attribute, 'permissionlessness' (excuse the non-word), which describes the ability of a party interested in participating in the block creation process to do so. Because your protocol is PoS, any interested party requires stake in order to participate in block production, making it permissioned.

'Permissionless' is an extremely important attribute, especially for the growth aspects of a blockchain and Proof-of-Approval is in fact permissionless. Proof-of-Approval does not require any stake to create blocks, but it does require approvals from parties holding a quorum (>50%) stake. If a party has 0 stake, it's block needs approval from others totaling a quorum stake (>50%). On the other hand, if a party has 10% stake, it's block needs approval from others totaling a quorum stake minus its own stake (>40%). PoS applies for approvals and not for block creation or winning rewards.

* The consensus mechanism is based around timestamps, but there is no objective way to verify a historical timestamp. Doesn't this present a number of problems, e.g bootstrap poisoning?

Consensus mechanism is based on signed approval messages that are stored in the blockchain to deter long-range attacks. Also note that the approving stake is at the current timeslot, not something in the past. Let's consider a couple of scenarios here.

1. An adversary attempts to create a block n blocks in the past. In order to successfully fork from n block in the past, the adversary needs signed approval, in that timestamp, from >50% stakeholders for every block since the n-blocks in past (blocks -n, -n+1, -n+2...).

2. Past >50% stakeholders (n blocks ago) sell off all their stake and turn adversarial (but current >50% stakeholders are still honest). Again, in order to successfully fork from n blocks ago, they need signed approvals for every block in the past (blocks -n, -n+1, -n+2...). While they may be able to approve some blocks when they did hold > 50% stake, as their stake goes down, they need other parties to approve their more recent blocks. In order to get the newest block approved, they would need adversarial stake > 50% in the present.

* You are rewarding newly minted blocks with stake, yet to produce blocks, you require stake. How is this resolved?

As stated above, a party with no stake requires approvals with other parties that can form a quorum. While it is harder to achieve than another party holding a large amount of stake but is definitely achievable.

* Doesn't the Pareto distribution of stake over time present centralisation concerns?

Yes, Pareto distribution does present centralization concerns just like mining pools for bitcoins. There does not seem to be a known solution for it yet.

* How does your protocol deal with the keys-from-the-very-recent-past attack, whereby an attacker purchases newly emptied private keys of very large stake value, then creates a fork where he steals all the stake back for himself?

I believe it is the same as the scenario 2 described above.

Thanks again.
Shunsai

[shunsaitakahashi]

Hello Anti-Cen,

Thank you for taking time to review this work and providing very valuable feedback and suggestions. I do see scaling to be the key challenge for blockchains and similar technologies.

My day job relates to databases and microservices. Many of the concerns of databases also apply to blockchains. In order for blockchains to be successful, they not only have to store a lot of data fast but also be able to read any stored data (like a needle in a haystack) very fast. Blockchain data structures are not naturally conducive to fast readability.

Proof-of-Approval, like many others, needs to define

1. Data structures that support fast write and read performances without sacrificing security
2. Parallelize the node tasks in order make computational and storage needs manageable
3. Achieve the above 2 and have the code be well designed for correctness and maintainability

“If you aren't in over your head, how do you know how tall you are?”
― T.S. Eliot

Thanks,
Shunsai

[Adeyemi]

I read part of the post and it lead me on a journey to reading other articles that are enlightening. There's so much knowledge hidden in your article which is not something to be rushed. I'm still relatively new in the cryptosphere but am learning at a fast pace. I should come back to make a more meaningful comment when I'm done reading your post and fully understand your protocol. Thank you for sharing and adding to my knowledge. All the best.

[Anti-Cen]

So far there is no PoW replacement. PoS has been proven to fail with NXT in the past, it wasn't pretty. We've seen IOTA fail big time as well, so DAG doesn't cut it. Hybrid attempts such as Decred.. no one hasn't even bothered to attack it for real yet.

I don't see realistic reasons for anyone to sell their BTC to get anywhere else.

From what I read DAG does cut it and IOTA has been sorted out and the facts are that Bitcoin does not scale
and that ignoring transactions that get lost or stuck.

I agree about standing up to attack so far but Lightning hubs can and will get attacked and being a single point of
failure I am sure they will be taken down without having to resort to feedback loops if the fees don't prevent these
types of attack.

"realistic reasons" could also be financial or based on people just not liking banks !

[Anti-Cen]

My day job relates to databases ..........

Yes, worked on many distributed query's myself and they could make life easier and using digits 3-6 from the public
key to sub-divide the data across clustered nodes (replication servers) to provide redundancy.

dear oh dear how did we ever write scaleable distributed network apps (DNA) without having to invent CPU-Wars
I will never know and now apparently the answer is to go "off-block" so keep doing what your doing and keep an
eye on network chatter becoming too big because that's another killer if you don't watch it.

[shunsaitakahashi]

Hello Cellard,

While "better" is just tongue-in-cheek designed to attract attention, the consensus protocol itself is serious.  

Like many others, I am a huge fan of Satoshi Nakamoto's work. But that doesn't mean it's the final word in that category. In science, it rarely is. Isaac Newton's wonderful work paved way to Albert Einstein's work and others are sure to follow.

Also totally agree that protocol's have made many claims in past, most turning out to be false. While some of it may have been ill-intentioned, I do believe that the majority has been just the scientific process - theory followed by either proof or disproof.

As you said, a protocol does need to be "through hell and back" because any success will invite attacks from all angles. My purpose here is just the first step--peer review. I am looking for flaws in the protocol that I haven't been able to think of. And I do want readers to be skeptic - it's better to find flaws sooner than later. If it does turn out that the protocol has merits, the next steps of implementation and validation will follow.

Thanks,
Shunsai

[-DEVX-]

Like many others, I am a huge fan of Satoshi Nakamoto's work. But that doesn't mean it's the final word in that category. In science, it rarely is. Isaac Newton's wonderful work paved way to Albert Einstein's work and others are sure to follow.

I really liked this one Shunsai. Checking your paper all night today. Of course i have many questions in my mind right now but I'm really impressed with it for the first 11 pages.

[shunsaitakahashi]

Devx,

Whole night! You are working harder than I did! Really appreciate it!

Shunsai

[monsterer2]

Hello Paul,

I appreciate your kind words and your taking time to review this work. Please see rest of my comments inline.

* In your description of the ideal blockchain (from the article) you've omitted a very important attribute, 'permissionlessness' (excuse the non-word), which describes the ability of a party interested in participating in the block creation process to do so. Because your protocol is PoS, any interested party requires stake in order to participate in block production, making it permissioned.

'Permissionless' is an extremely important attribute, especially for the growth aspects of a blockchain and Proof-of-Approval is in fact permissionless. Proof-of-Approval does not require any stake to create blocks, but it does require approvals from parties holding a quorum (>50%) stake. If a party has 0 stake, it's block needs approval from others totaling a quorum stake (>50%). On the other hand, if a party has 10% stake, it's block needs approval from others totaling a quorum stake minus its own stake (>40%). PoS applies for approvals and not for block creation or winning rewards.

That's a chicken and egg problem though. You cant approve any blocks if you don't have any stake... What happens at launch, when there is no stake?

Consensus mechanism is based on signed approval messages that are stored in the blockchain to deter long-range attacks. Also note that the approving stake is at the current timeslot, not something in the past. Let's consider a couple of scenarios here.

1. An adversary attempts to create a block n blocks in the past. In order to successfully fork from n block in the past, the adversary needs signed approval, in that timestamp, from >50% stakeholders for every block since the n-blocks in past (blocks -n, -n+1, -n+2...).

2. Past >50% stakeholders (n blocks ago) sell off all their stake and turn adversarial (but current >50% stakeholders are still honest). Again, in order to successfully fork from n blocks ago, they need signed approvals for every block in the past (blocks -n, -n+1, -n+2...). While they may be able to approve some blocks when they did hold > 50% stake, as their stake goes down, they need other parties to approve their more recent blocks. In order to get the newest block approved, they would need adversarial stake > 50% in the present.

In case 2, what if the forked blocks that the historical stake holders approve, steal their stake back again?

* You are rewarding newly minted blocks with stake, yet to produce blocks, you require stake. How is this resolved?

As stated above, a party with no stake requires approvals with other parties that can form a quorum. While it is harder to achieve than another party holding a large amount of stake but is definitely achievable.

I fail to see why any party with stake would sacrifice their chance to claim the minted coins by approving a non-stake holder's blocks? That's not rational behaviour; they surely would just approve their own blocks?

Cheers, Paul.

[shunsaitakahashi]

Hello Paul,

That's a chicken and egg problem though. You cant approve any blocks if you don't have any stake... What happens at launch, when there is no stake?

Yes, it does require that genesis block allocates stake to one or more parties.

In case 2, what if the forked blocks that the historical stake holders approve, steal their stake back again?

Stakes (or stake changes) in any block affect decision process in forks containing that block only, not sibling forks.

A - B0 - C0 - D0
  \ B1 - C1 

Assuming B0/C0/D0 is the "honest" fork and B1/C1 is an adversarial attempt to a long-range revision attack, any stake changes in B1 and C1 do not affect decision process on the fork B0/C0 etc. Stakes for the decision process are calculated just before each block for that specific fork. More details are in Section 3.3.1 of the paper.

I fail to see why any party with stake would sacrifice their chance to claim the minted coins by approving a non-stake holder's blocks? That's not rational behaviour; they surely would just approve their own blocks?

By "approval" I meant "approval-message" (Section 2.2.14) where stakeholders rank valid blocks in order of their own preference. Each stakeholder always ranks his/her own block on the top. The question then boils down to whether each stakeholder would approve only his/her block and no other block (approval-message contains a single block header). In that scenario (assuming no single stakeholder has a quorum stake), the blockchain fails resulting in a negative impact on the stakeholders.

In another scenario, some stakeholders may only approve their own blocks in an attempt to tilt the winning chances in their own favor. This is a real possibility. A possible mechanism to deter such an "attack" is to simply "blacklist" such stakeholders temporarily. An honest stakeholder can tell within a few blocks with certainty if another stakeholder is not approving his/her valid blocks. Blacklisting them temporarily for 2x the blocks they failed to approve may work. But they should not be blacklisted permanently since this is likely to result in all stakeholders being blacklisted permanently by other stakeholders.

This deterrence algorithm along with "approval scoring function" (2.2.15) need to be defined for a blockchain implementation.

Regards,
Shunsai

[CarltonWyatt]

I think we agree proof of work is extremely energy inefficient if secured through mining so a new proof will eventually probably over take proof of the work I think. Only as the industry develops though but this is yet another good new idea that I look forward to seeing it progress

[monsterer2]

Stakes (or stake changes) in any block affect decision process in forks containing that block only, not sibling forks.

A - B0 - C0 - D0
  \ B1 - C1 

Assuming B0/C0/D0 is the "honest" fork and B1/C1 is an adversarial attempt to a long-range revision attack, any stake changes in B1 and C1 do not affect decision process on the fork B0/C0 etc. Stakes for the decision process are calculated just before each block for that specific fork. More details are in Section 3.3.1 of the paper.

Hi Shunsai,

In the following example, say I had a majority of stake at block A. Then at B0, C0 all the way up to head block H0, I sell off my majority of stake, understanding that there is an upper limit on stake transfer.

Code:

A - B0 - C0 - D0 - H0
  \ B1 - C1 - D1 - H1

Then, I create a double spend of my stake using the historical private keys, which I still own, thus sending it to myself in a fork continuing fork B1 - C1 - D1 that I create and approve myself (majority stakeholder).

This is not a 50% attack, because I don't own the value held in the private keys anymore, the cost for doing this is nothing.

Why doesn't the network just accept this fork as canon, given that its the same length (or longer if I chose) than the genuine fork?
  

In another scenario, some stakeholders may only approve their own blocks in an attempt to tilt the winning chances in their own favor. This is a real possibility. A possible mechanism to deter such an "attack" is to simply "blacklist" such stakeholders temporarily. An honest stakeholder can tell within a few blocks with certainty if another stakeholder is not approving his/her valid blocks.

My question is, what does the stakeholder have to gain by approving anyone's blocks but his own? If he has an edge by not doing this, there is a very real problem.

[fresheneesz]

Am I right that the goals of this protocol are primarily to reduce the finality time in comparison to Bitcoin as well as reduce the cost of running the system?

The image of how blocks are set up (https://cdn-images-1.medium.com/max/1000/1*fPsB4-t6J_1u1UpF37dYHw.png) reminds me strongly of the way blocks are chained in the "two-hop blockchain" (https://eprint.iacr.org/2016/716.pdf). I would like to see more in-depth comparisons to other consensus protocols, especially DPoS which seems particularly close in mechanism to Proof-of-Approval.

Your comparison table claims Proof-of-Approval is fully finalized after a single block,  however, you also talk about how there may be multiple top-level blocks where the "preferred" chain is unresolved. Doesn't this imply that your transaction being inside a valid block doesn't mean its been fully finalized? How do you reconcile that?

Since any node can produce a candidate block, this seems like it would potentially cause unbounded network traffic with everyone and their mother suggesting blocks to vote on. How is this resolved in the case of, say, an adversarial ddos attack? But I have the same question as monsterer2, why would anyone with stake approve the block of anyone without stake? In fact, why would anyone with stake approve *anyone* else's blocks? It seems there's no incentive to mine on top of someone else's blocks. This could manifest in more subtle attacks where you have stakeholders who refuse to mint on top of a competitor. It could also manifest in deadlock as nodes try to maximize their probability of winning the minted block.

I have a hard time seeing the purpose of having nodes pay attention to timestamps and comparing them to their receive-time. At its core, the mechanism is just voting, right? I don't see why the protocol doesn't just let nodes vote for whatever blocks they want. I see the appeal of a simple stake-voting process for block creation (similar to DPoS), but the Proof of Approval method seems like rational profit-seeking minters would make things devolve into the top 50% stakeholders passing around permission to mine the blocks, completely excluding the other 50%.

Also, could you provide a glossary of variables you use in this paper? Its hard for me to keep track of which variables mean what and find their definition in the prose when I need to refer to what they mean later.

@monsterer2 Are you suggesting that greater permissionlessness is desriable? Also, I've come to the conclusion that bootstrap poisoning can be entirely solved by blockchain checkpoints hardcoded into whatever software you use - since the software should be audited, and malicious software can make your client choose whatever chain it wants, hardcoded checkpoints don't reduce security in any meaningful way and yet completely remove the possibility of long range attacks including bootstrap poisoning.

Also @monsterer2 I would actually call your most recent proposed attack a 51% attack, since you *did* own a majority stake, and are using that fact to attack the network. I'd say its just an interesting twist on a 51% attack.

[aliashraf]

Just read the article, nice work but, as one of the guys have mentioned earlier, the 'proof of something' discourse is exhaustively saturated and it is hard to attract enough attention from the community these days for a new one.

I'm not satisfied yet with the protocol itself as it seems not to be secure against the bootstrap poisoning attack and I have not found strong enough game theory and incentive analysis (why people should approve  each other's blocks) and I do not like the idea of zero cost block generation (we have enough trouble with transaction malleability and DDoS attack already) ... BUT

But first of all I have not read the technical paper yet and, more importantly, I don't think  the consensus problem has a solution at all. I mean other than being ignored!

The way I see the situation in crypto world, we will be stuck in wasting resources and jeopardizing performance and scalability  as long as we are seeking a solution for this problem: consensus.

I know, I know it looks kinda weird or ridiculous, speaking about public blockchain or public ledger while one is denying the importance of the holly consensus , it is kinda blasphemy, isn't it?

Common sense tells us to remain a believer but I don't give a sh*t to common sense, actually I love questioning the most obvious predicates issued by common sense, and it is one of them: to have a secure, public, permissionless blockchain you should have a protocol for the participants to reach an agreement upon the state of the blockchain, a consensus protocol, got it you crazy fool?

And I'm like

Thank you sir for the enlightening, but NO! I don't get it, you know why? Because it costs too much and hell it is not scalable and I can't imagine a crypto dominated globe with millions of machines all agreed upon every single transaction.


If I was such a reasonable person to bend knees to common sense I wouldn't participate in the crazy saga for a decentralized paradigm in the heights of capitalism fully controlled by corporates and banks.


Yes, I'm crazy enough to don't pay attention to anything other than game theory and pure mathematics and to this point, I have not found a proof for the necessity of consensus, actually there even exists  no unproven theorem about it. It is just an 'obvious' assumption, something like 'The earth is the center of the cosmos and the sun along with other stars are rotating around us', nothing more.

So, my advice, just forget about consensus protocols, they either do not exist or they are bad protocols.

[shunsaitakahashi]

Hello Monsterer2,

In the following example, say I had a majority of stake at block A. Then at B0, C0 all the way up to head block H0, I sell off my majority of stake, understanding that there is an upper limit on stake transfer.

Code:

A - B0 - C0 - D0 - H0
  \ B1 - C1 - D1 - H1

Then, I create a double spend of my stake using the historical private keys, which I still own, thus sending it to myself in a fork continuing fork B1 - C1 - D1 that I create and approve myself (majority stakeholder).

This is not a 50% attack, because I don't own the value held in the private keys anymore, the cost for doing this is nothing.

Why doesn't the network just accept this fork as canon, given that its the same length (or longer if I chose) than the genuine fork?

Any single person owning (or colluding with) a quorum (majority) stake is a problem because that person (or colluders) can rewrite the chain as they choose. This situation is essentially the same as an adversary owning a quorum stake which is the limit of the protocol.

In another scenario, some stakeholders may only approve their own blocks in an attempt to tilt the winning chances in their own favor. This is a real possibility. A possible mechanism to deter such an "attack" is to simply "blacklist" such stakeholders temporarily. An honest stakeholder can tell within a few blocks with certainty if another stakeholder is not approving his/her valid blocks.

My question is, what does the stakeholder have to gain by approving anyone's blocks but his own? If he has an edge by not doing this, there is a very real problem.

My assumption, which could be wrong, is
1. Stakeholders will approve (through approval message) more than one blocks or risk blockchain failure or being blacklisted by other node members.
2. Stakeholders will try to rank more candidate blocks created by other higher stakeholders lower in order to gain advantage in block creation.

Of course, these are just assumptions and need to be proven in real life. Perhaps some coins should be given for approving a winning block in order of their ranking of the block. I am open to suggestions here. In the meantime I will analyze the if incentivizing block approval does have the desired effect.

Thanks for pointing it out - this is exactly what I am looking for from this forum.
Shunsai

[fresheneesz]

Stakeholders will approve (through approval message) more than one blocks or risk .. being blacklisted by other node members.

How would other nodes detect that they're intentionally not approving blocks in order to blacklist them? Isn't anyone allowed to not approve blocks if they don't want to?

Stakeholders will try to rank more candidate blocks created by other higher stakeholders lower in order to gain advantage in block creation.

But isn't only including your block as the only approved block the best way of gaining an advantage? This is known as the "bullet-voting" problem in approval voting, ranked voting, and range voting circles. https://en.wikipedia.org/wiki/Bullet_voting . While in normal voting, this shouldn't usually be much of a problem, it seems like in Proof-of-Approval there is a big incentive to bullet vote.

[shunsaitakahashi]

Hello Fresheneesz,

Am I right that the goals of this protocol are primarily to reduce the finality time in comparison to Bitcoin as well as reduce the cost of running the system?

Yes, the goals are to
1. Improve security by achieving near 50% adversarial stake tolerance. Near 50% tolerance would offer deterrence even more than the corresponding mining power. Only Cardano achieves that (not counting TON because I have no knowledge of their protocol).
2. Improve finality. The fact that Ethereum is trying to get Casper FFG shows how important finality is (although Casper FFG only improves tolerance to long-range attacks). Cardano's finality degrades continuously with rising adversarial stake.
3. Reduce cost. AFAIK, Bitcoin's breakeven (cost of mining vs its price) is around $8050. That's a lot of expense for the node owners.

The image of how blocks are set up (https://cdn-images-1.medium.com/max/1000/1*fPsB4-t6J_1u1UpF37dYHw.png) reminds me strongly of the way blocks are chained in the "two-hop blockchain" (https://eprint.iacr.org/2016/716.pdf). I would like to see more in-depth comparisons to other consensus protocols, especially DPoS which seems particularly close in mechanism to Proof-of-Approval.

Thanks for pointing it out - I had not seen that before. I will definitely offer comparison even if they are simply superior

Your comparison table claims Proof-of-Approval is fully finalized after a single block,  however, you also talk about how there may be multiple top-level blocks where the "preferred" chain is unresolved. Doesn't this imply that your transaction being inside a valid block doesn't mean its been fully finalized? How do you reconcile that?

In order to be fully robust, the fork selection has to work on all conditions that may be produce in normal operation. It is not a detriment that the fork selection actually works even beyond those conditions. It's just a good design practice to design for more than needed (within cost constraints of course).

Since any node can produce a candidate block, this seems like it would potentially cause unbounded network traffic with everyone and their mother suggesting blocks to vote on. How is this resolved in the case of, say, an adversarial ddos attack?

Traffic can be a problem but only the headers (which are few hundred bytes) are being transmitted. Still, a node would need to validate the blocks of headers it receives (after downloading full blocks). Having a smaller time-slot (as opposed to larger) will reduce the number of headers received by a node (assuming the software's low level code simply drops headers received in mismatched time-slots). An adversarial ddos attack may look like network fragmentation and may prevent blocks from being added to chain temporarily.

But I have the same question as monsterer2, why would anyone with stake approve the block of anyone without stake? In fact, why would anyone with stake approve *anyone* else's blocks? It seems there's no incentive to mine on top of someone else's blocks. This could manifest in more subtle attacks where you have stakeholders who refuse to mint on top of a competitor. It could also manifest in deadlock as nodes try to maximize their probability of winning the minted block.

Yes, and there may be a need to reward block approvals. I will work on adding block approval rewards. They can be added to approval-block since the content-block has already been created.

I have a hard time seeing the purpose of having nodes pay attention to timestamps and comparing them to their receive-time. At its core, the mechanism is just voting, right? I don't see why the protocol doesn't just let nodes vote for whatever blocks they want. I see the appeal of a simple stake-voting process for block creation (similar to DPoS), but the Proof of Approval method seems like rational profit-seeking minters would make things devolve into the top 50% stakeholders passing around permission to mine the blocks, completely excluding the other 50%.

Nodes are allowed to rank in any order they choose. The time is just the default order built into the software.

Also, could you provide a glossary of variables you use in this paper? Its hard for me to keep track of which variables mean what and find their definition in the prose when I need to refer to what they mean later.

Good point, I will add glossary.

Thanks,
Shunsai

[shunsaitakahashi]

Hello Aliashraf,

Just read the article, nice work but, as one of the guys have mentioned earlier, the 'proof of something' discourse is exhaustively saturated and it is hard to attract enough attention from the community these days for a new one.

I choose Proof-of-Approval name simply because it implies to have something to do with approvals. I could have chosen "Takahashi Protocol" name (similar to Ripple Protocol or Ouroborous) but that name wouldn't have told the reader anything other than the creator is named Takahashi.

I'm not satisfied yet with the protocol itself as it seems not to be secure against the bootstrap poisoning attack...

Protocols that use "older" stakes (stakes from many blocks ago) are susceptible to bootstrap poisoning attack. In this protocol, since the stake used is at the current block, I have not been able to come up with a successful bootstrap poisoning attack scenario.

...I have not found strong enough game theory and incentive analysis (why people should approve  each other's blocks) and I do not like the idea of zero cost block generation..

Multiple people have mentioned it and I am analyzing giving rewards for approvals.

The way I see the situation in crypto world, we will be stuck in wasting resources and jeopardizing performance and scalability  as long as we are seeking a solution for this problem: consensus.

The reason the crypto world is focused on consensus is because in absence of a good protocol, all other blockchain properties are compromised. Bitcoin is said to have breakeven of $8050 due to its resource consumption requirement just to achieve consensus. Therefore, blockchains need to be solve consensus to actually achieve that we all know they can.

Yes, I'm crazy enough to don't pay attention to anything other than game theory and pure mathematics and to this point...

Game theory and pure mathematics - just the way I like it

So, my advice, just forget about consensus protocols, they either do not exist or they are bad protocols.

Here I'd differ from you a bit - I do feel that a good consensus protocol (that works and doesn't consume resources) is needed for blockchain success - not just as price of token but their actual impact on the world.

Thanks for your comments,
Shunsai

[shunsaitakahashi]

Hello fresheneesz,

How would other nodes detect that they're intentionally not approving blocks in order to blacklist them? Isn't anyone allowed to not approve blocks if they don't want to?

Node A is allowed to not approve another node's (say B's) blocks. That also means that B is allowed to not approve A's blocks. It works both ways. To detect if it is intentional or just network, point-to-point ping and bandwidth can be measured to guess number of blocks that should have reached within the time-slot.

But isn't only including your block as the only approved block the best way of gaining an advantage? This is known as the "bullet-voting" problem in approval voting, ranked voting, and range voting circles. https://en.wikipedia.org/wiki/Bullet_voting . While in normal voting, this shouldn't usually be much of a problem, it seems like in Proof-of-Approval there is a big incentive to bullet vote.

Yes, block approval should be incentivized. I am working on it.

Thanks,
Shunsai

[aliashraf]

Node A is allowed to not approve another node's (say B's) blocks. That also means that B is allowed to not approve A's blocks. It works both ways. To detect if it is intentional or just network, point-to-point ping and bandwidth can be measured to guess number of blocks that should have reached within the time-slot.

Very weak strategy to detect a node's intentional avoidance of approving peer's blocks. Nodes can simply stop supporting ICMP or manipulate it to delay response packets a few milliseconds.

Yes, block approval should be incentivized. I am working on it.

Block generation has zero cost and starting a node is very cheap, a typical player can run thousands of nodes that their trivially generated blocks will be approved by a masternode which in turn will be rewarded the bonus for its fake cooperative gesture.

I don't see this 'approval rewarding' strategy a good one and I have not an alternative in hand to suggest, in this moment.

[shunsaitakahashi]

Hello Fresheneesz,

The image of how blocks are set up (https://cdn-images-1.medium.com/max/1000/1*fPsB4-t6J_1u1UpF37dYHw.png) reminds me strongly of the way blocks are chained in the "two-hop blockchain" (https://eprint.iacr.org/2016/716.pdf). I would like to see more in-depth comparisons to other consensus protocols, especially DPoS which seems particularly close in mechanism to Proof-of-Approval.

Comparing Proof-of-Approval with 2-hop Blockchain (2-hop)
1. 2-hop uses PoW consuming resources (in addition to PoS), Proof-of-Approval has no PoW.
2. 2-hop's alternate blocks are different, one is from PoW and the next is from PoS. All Proof-of-Approval blocks are the same (but each block has 2 parts to it).
3. In 2-hop, during PoS round, the network choose one stakeholder for PoS block. In Proof-of-Approval any (or all) stakeholders approve blocks.
4. In 2-hop, fork selection is based on the longest PoW chain. In Proof-of-Approval fork selection is based on a better approval score.
5. Proof-of-Approval has 1 block finality. 2-hop's finality properties seem to be similar to PoW chains. The analysis here is more difficult since neither PoS nor PoW can be analyzed independent of each other. The PoS part of the analysis matches Cardano's Ouroboros (https://eprint.iacr.org/2016/889.pdf) static case. Since the static case isn't a reality (stakes will change during chain's lifetime), it is unclear if the PoS does add any additional security to the chain.

Hope this comparison helps.
Regards,
Shunsai

[monsterer2]

Hello Monsterer2,

In the following example, say I had a majority of stake at block A. Then at B0, C0 all the way up to head block H0, I sell off my majority of stake, understanding that there is an upper limit on stake transfer.

Code:

A - B0 - C0 - D0 - H0
  \ B1 - C1 - D1 - H1

Then, I create a double spend of my stake using the historical private keys, which I still own, thus sending it to myself in a fork continuing fork B1 - C1 - D1 that I create and approve myself (majority stakeholder).

This is not a 50% attack, because I don't own the value held in the private keys anymore, the cost for doing this is nothing.

Why doesn't the network just accept this fork as canon, given that its the same length (or longer if I chose) than the genuine fork?

Any single person owning (or colluding with) a quorum (majority) stake is a problem because that person (or colluders) can rewrite the chain as they choose. This situation is essentially the same as an adversary owning a quorum stake which is the limit of the protocol.

Hello Shunsai,

This is not how I would categorise the presented scenario. This is the NaS problem in it's essence. The attacker, as a historical majority stakeholder, can still take over the blockchain at any point in the future after he has sold his stake. So, at the current block height, said attacker owns 0 stake, yet he can still rewrite the entire chain due to this NaS problem.

Cheers, Paul.

[Bonzenboss]

Hey shunsia,
I read your technical paper and from what I understood it seems to be quite a good idea but of course as all protocols it first needs to be tested in action to see how good it actually works.

Could you maybe explain what permission, adversary and adversary tolerance means in the comparison chart? (I’m not a native English speaker as you can tell and translator Programm give me weird results so..)

Thanks in advance

-Bonzenboss

[shunsaitakahashi]

Hello Paul,

In the following example, say I had a majority of stake at block A. Then at B0, C0 all the way up to head block H0, I sell off my majority of stake, understanding that there is an upper limit on stake transfer.

Code:

A - B0 - C0 - D0 - H0
  \ B1 - C1 - D1 - H1

Then, I create a double spend of my stake using the historical private keys, which I still own, thus sending it to myself in a fork continuing fork B1 - C1 - D1 that I create and approve myself (majority stakeholder).

This is not a 50% attack, because I don't own the value held in the private keys anymore, the cost for doing this is nothing.

Why doesn't the network just accept this fork as canon, given that its the same length (or longer if I chose) than the genuine fork?

Any single person owning (or colluding with) a quorum (majority) stake is a problem because that person (or colluders) can rewrite the chain as they choose. This situation is essentially the same as an adversary owning a quorum stake which is the limit of the protocol.

This is not how I would categorise the presented scenario. This is the NaS problem in it's essence. The attacker, as a historical majority stakeholder, can still take over the blockchain at any point in the future after he has sold his stake. So, at the current block height, said attacker owns 0 stake, yet he can still rewrite the entire chain due to this NaS problem.

You are correct in pointing out an issue here which must be solved. I'd describe the issue slightly differently even without any single party holding a quorum stake.

An adversary buys empty private keys (with zero current stake) that once upon a time did hold a quorum stake in the blockchain. That adversary can start rewriting blocks from the time the keys did hold the quorum stake to the present - completely rewriting all the transactions.

I do need to think about this problem. Thanks for pointing it out.

Regards,
Shunsai

[shunsaitakahashi]

Hello Bonzenboss,

I read your technical paper and from what I understood it seems to be quite a good idea but of course as all protocols it first needs to be tested in action to see how good it actually works.

You are 100% correct that the testing with implementation is required. It turns out that even that isn't sufficient since an adversary will keep his/her attack vectors hidden till the blockchain actually succeeds when the attacks can earn him/her maximum profit. I think a peer review (what's being conducted here) can bring out many issues that a testing without serious adversarial attacks may not find.

Could you maybe explain what permission, adversary and adversary tolerance means in the comparison chart?

Permission - A party (node) needs some kind of authorization before it can join the protocol execution. In permissionless environment (e.g. Bitcoin), any party can download code and start a computer to join the protocol execution.

Adversary - A party or a group of parties that are trying to take unfair advantage of the blockchain e.g. spending the same coins multiple times. Such adversarial actions are called "attacks" and blockchains should be able to deter them.

Adversary tolerance -  Power of the adversary's attacks increases as he/she accumulates more and more of the resource critical to the blockchain. For Bitcoin, this resource is mining power. For Proof-of-Approval, this resource is the stake in the network. Adversary tolerance is the maximum amount of adversarial power a blockchain can deter.

Regards,
Shunsai

[kohi]

No such thing as "better blockchain consensus protocol" until your so called better blockchain consensus protocol has been through hell and back, namely, attacked by all angles on the technical aspect and attacked by all angles in the social engineering aspect (fork attempts by governments, social media attacks such as the twitter handle taken over by a fork, exchanges against you...) this is what Bitcoin has survived.

So far there is no PoW replacement. PoS has been proven to fail with NXT in the past, it wasn't pretty. We've seen IOTA fail big time as well, so DAG doesn't cut it. Hybrid attempts such as Decred.. no one hasn't even bothered to attack it for real yet.

I don't see realistic reasons for anyone to sell their BTC to get anywhere else.

PoW was also attacked and actually hacked in the early days of Bitcoin.

There's no reason these new consensus algorithms can't become as secure as PoW over time.

So far, the PoS and DPOS algorithm have been operating just fine for years now with no recent hacks. I don't doubt all the blockchains using these consensus algorithms are being attacked at all angles.

[monsterer2]

You are correct in pointing out an issue here which must be solved. I'd describe the issue slightly differently even without any single party holding a quorum stake.

An adversary buys empty private keys (with zero current stake) that once upon a time did hold a quorum stake in the blockchain. That adversary can start rewriting blocks from the time the keys did hold the quorum stake to the present - completely rewriting all the transactions.

I do need to think about this problem. Thanks for pointing it out.

Regards,
Shunsai

Hi Shunsai,

The standard response that most PoS developers have given in the past is that only bootstrapping nodes would be vulnerable to such an attack because all online nodes would reject the fork because they have knowledge and timestamps for the canon chain.

However, this concession is a loss of objectivity compared to PoW, and a loss of security because of that. I see no real way to avoid Nothing at Stake in a system with no PoW - you could try something like punishment of locked up funds (ala Etherum), but that's a real mess to analyse and may be less efficient overall than PoW as well as being inelegant.

Cheers, Paul.

[Slava79]

Hi Shunsai,

Very interesting article.

Did you read Tendermint white paper ? I scanned article and the core of it looks quite similar to Tendermint's PBFT consensus. Could you please provide a comparison ?

 

[aliashraf]

Hello Paul,

In the following example, say I had a majority of stake at block A. Then at B0, C0 all the way up to head block H0, I sell off my majority of stake, understanding that there is an upper limit on stake transfer.

Code:

A - B0 - C0 - D0 - H0
  \ B1 - C1 - D1 - H1

Then, I create a double spend of my stake using the historical private keys, which I still own, thus sending it to myself in a fork continuing fork B1 - C1 - D1 that I create and approve myself (majority stakeholder).

This is not a 50% attack, because I don't own the value held in the private keys anymore, the cost for doing this is nothing.

Why doesn't the network just accept this fork as canon, given that its the same length (or longer if I chose) than the genuine fork?

Any single person owning (or colluding with) a quorum (majority) stake is a problem because that person (or colluders) can rewrite the chain as they choose. This situation is essentially the same as an adversary owning a quorum stake which is the limit of the protocol.

This is not how I would categorise the presented scenario. This is the NaS problem in it's essence. The attacker, as a historical majority stakeholder, can still take over the blockchain at any point in the future after he has sold his stake. So, at the current block height, said attacker owns 0 stake, yet he can still rewrite the entire chain due to this NaS problem.

You are correct in pointing out an issue here which must be solved. I'd describe the issue slightly differently even without any single party holding a quorum stake.

An adversary buys empty private keys (with zero current stake) that once upon a time did hold a quorum stake in the blockchain. That adversary can start rewriting blocks from the time the keys did hold the quorum stake to the present - completely rewriting all the transactions.

I do need to think about this problem. Thanks for pointing it out.

Regards,
Shunsai

Shunsai,

I appreciate your hard work and feel deep sympathy with you, a person who knows something is wrong and current situation with crypto is not good enough because of the classical paradox between security and decentralization on one side and scalability on the other side.

The thing is POS, even your 2nd phase commit version, is not proved to be an answer because of problems like Nothing at Stake mentioned by Paul here and a lot more. It is not just a simple 'issue' to 'think about' it has been discussed over and over and no answer available yet, other than complicating everything to make it harder for both adversaries and innocent participants and/or leading to a sophisticated protocol vulnerable to implementation bugs and a series of other limitations. Just ugly, far from elegant solutions too complicated, too fragile.

I have gone through this before and have chosen another approach: forgetting about the answers and re-thinking questions.

For instance, let's take a look at your 'permissionless' index (whether participating in a protocol needs permission from an authority or not): What if one needs permission but not from a centralized authority but a decentralized entity like a curated list which is maintained in a classic PoW base blockchain tp participate in another protocol that carries the much burden of the transaction load, being secured by a trivial, low cost algorithm ?

See? A lot of possibilities out there and nothing is 'obvious' and, as I'm used to say, you shouldn't stick with common sense.

[Slava79]

In the following example, say I had a majority of stake at block A. Then at B0, C0 all the way up to head block H0, I sell off my majority of stake, understanding that there is an upper limit on stake transfer.

Code:

A - B0 - C0 - D0 - H0
  \ B1 - C1 - D1 - H1

Then, I create a double spend of my stake using the historical private keys, which I still own, thus sending it to myself in a fork continuing fork B1 - C1 - D1 that I create and approve myself (majority stakeholder).

Indeed, interesting, very valid point. I suppose you mean the security rule named "validator's bond" or "security deposit", so that after "depositing" (required to become a validator) some amount of tokens, it is not possible to "withdraw" immediately.  It is not mentioned in the document, but should be easy to add in order to address the issue you mentioned.

[shunsaitakahashi]

Hello Slava79,

Did you read Tendermint white paper ? I scanned article and the core of it looks quite similar to Tendermint's PBFT consensus. Could you please provide a comparison ?

Comparing Proof-of-Approval with Tendermint

1. Tendermint is a PBFT (http://pmg.csail.mit.edu/papers/osdi99.pdf) like algorithm where all nodes together agree on transactions and their order that would be put in a block. Therefore, all nodes together come up with a single block to be inserted in the blockchain. In Proof-of-Approval, just like Bitcoin, individual nodes bundle transactions on their own and the network chooses one of those bundles.

2. The "validators" in Tendermint volunteer to put some of their money as collateral that will earn them rewards but could also be confiscated. Validators are similar to those in Casper the Finality Gadget of Ethereum (https://arxiv.org/pdf/1710.09437.pdf). This article compares the two https://blog.cosmos.network/consensus-compare-casper-vs-tendermint-6df154ad56ae.

3. Tendermint a single "proposer" who proposes the blocks. The proposer is selected by some process from the validators in round robin.

4. Tendermint transactions achieve instant finality while Proof-of-Approval takes 1 block to finality.

5. Tendermint is likely to have less "liveness" than a block creating protocol like Bitcoin or Proof-of-Approval.

6. The amount need to takeover Tendermint is 1/3 of the collateral amount while the amount to takeover Proof-of-Approval blockchain would be almost half (just under half) of the value of the blockchain.

Regards,
Shunsai

[DevilOper]

Thank you sir for the enlightening, but NO! I don't get it, you know why? Because it costs too much and hell it is not scalable and I can't imagine a crypto dominated globe with millions of machines all agreed upon every single transaction.

Well, I would say more: any or almost any idea of decentralisation based on the Proof-of-Anything is vulnerable at the level of it's concept.
Because it strongly tends to concentration (i.e. centralisation) of abovementioned Anything, and thus all the consensus might be overriden; in fact, all the history might be overwritten by one who takes a control over majority of that Anything.

[shunsaitakahashi]

Hello Aliashraf,

I believe I have a good solution to this History attack (aka Costless Simulation attack) issue. While most PoS systems are relying on the so called "Weak Subjectivity" solution, this solution is purely objective. I am writing it up now and will post it here soon for everyone's review. I can't overstate the value of the feedback provided in this forum. Thanks everyone!

Regards,
Shunsai

Hello Paul,

In the following example, say I had a majority of stake at block A. Then at B0, C0 all the way up to head block H0, I sell off my majority of stake, understanding that there is an upper limit on stake transfer.

Code:

A - B0 - C0 - D0 - H0
  \ B1 - C1 - D1 - H1

Then, I create a double spend of my stake using the historical private keys, which I still own, thus sending it to myself in a fork continuing fork B1 - C1 - D1 that I create and approve myself (majority stakeholder).

This is not a 50% attack, because I don't own the value held in the private keys anymore, the cost for doing this is nothing.

Why doesn't the network just accept this fork as canon, given that its the same length (or longer if I chose) than the genuine fork?

Any single person owning (or colluding with) a quorum (majority) stake is a problem because that person (or colluders) can rewrite the chain as they choose. This situation is essentially the same as an adversary owning a quorum stake which is the limit of the protocol.

This is not how I would categorise the presented scenario. This is the NaS problem in it's essence. The attacker, as a historical majority stakeholder, can still take over the blockchain at any point in the future after he has sold his stake. So, at the current block height, said attacker owns 0 stake, yet he can still rewrite the entire chain due to this NaS problem.

You are correct in pointing out an issue here which must be solved. I'd describe the issue slightly differently even without any single party holding a quorum stake.

An adversary buys empty private keys (with zero current stake) that once upon a time did hold a quorum stake in the blockchain. That adversary can start rewriting blocks from the time the keys did hold the quorum stake to the present - completely rewriting all the transactions.

I do need to think about this problem. Thanks for pointing it out.

Regards,
Shunsai

Shunsai,

I appreciate your hard work and feel deep sympathy with you, a person who knows something is wrong and current situation with crypto is not good enough because of the classical paradox between security and decentralization on one side and scalability on the other side.

The thing is POS, even your 2nd phase commit version, is not proved to be an answer because of problems like Nothing at Stake mentioned by Paul here and a lot more. It is not just a simple 'issue' to 'think about' it has been discussed over and over and no answer available yet, other than complicating everything to make it harder for both adversaries and innocent participants and/or leading to a sophisticated protocol vulnerable to implementation bugs and a series of other limitations. Just ugly, far from elegant solutions too complicated, too fragile.

I have gone through this before and have chosen another approach: forgetting about the answers and re-thinking questions.

For instance, let's take a look at your 'permissionless' index (whether participating in a protocol needs permission from an authority or not): What if one needs permission but not from a centralized authority but a decentralized entity like a curated list which is maintained in a classic PoW base blockchain tp participate in another protocol that carries the much burden of the transaction load, being secured by a trivial, low cost algorithm ?

See? A lot of possibilities out there and nothing is 'obvious' and, as I'm used to say, you shouldn't stick with common sense.

[monsterer2]

Hello Aliashraf,

I believe I have a good solution to this History attack (aka Costless Simulation attack) issue. While most PoS systems are relying on the so called "Weak Subjectivity" solution, this solution is purely objective. I am writing it up now and will post it here soon for everyone's review. I can't overstate the value of the feedback provided in this forum. Thanks everyone!

Regards,
Shunsai

I believe this to be impossible, so I await your update with the utmost enthusiasm!

[shunsaitakahashi]

Created new thread for the updated paper since it may fix some previous problems but may have created some new ones.
Thread https://bitcointalk.org/index.php?topic=3913439.0

Regards,
Shunsai

[d5000]

Interesting proposal with some nice properties, although I mostly agree with monsterer that the long-range attack problem isn't fully solved. I'll look into the updated paper this week to comment on it.

Only a little observation (and that's why I comment here in the old thread): The attack monsterer described (old majority stakeholder(s) taking over the chain with a double spend) is essentially the same attack than a profitable 50+% PoS attack. In a profitable 50+% attack, you will wait for a few blocks selling your stake first (most likely in an altcoin exchange as they confirm the "reception" of the coins relatively fast) and only then try to "take over" the new chain with a prepared attack chain. Otherwise, very likely your stake would decrease in value. So, also in this attack, in the moment you take over, you don't own stake anymore (or at least, you aren't forced to own any stake).

The difference between "long-range attack" and "profitable 50+% attack" be the time between the actual double spend and the "takeover" (when the attack chain replaces the "honest" chain) but the attack mechanism is the same. But monsterer is absolutely right and this is the reason why PoS protocols are to be considered - until this is solved - weaker than PoW protocols. I consider this attack unpractical in a chain with many stakeholders and reorg limits or "rolling checkpoints", and it's likely to be very expensive, but it may be considerably cheaper than a PoW 50+% attack.

[shunsaitakahashi]

Hello D5000,

Only a little observation (and that's why I comment here in the old thread): The attack monsterer described (old majority stakeholder(s) taking over the chain with a double spend) is essentially the same attack than a profitable 50+% PoS attack. In a profitable 50+% attack, you will wait for a few blocks selling your stake first (most likely in an altcoin exchange as they confirm the "reception" of the coins relatively fast) and only then try to "take over" the new chain with a prepared attack chain. Otherwise, very likely your stake would decrease in value. So, also in this attack, in the moment you take over, you don't own stake anymore (or at least, you aren't forced to own any stake).

The difference between "long-range attack" and "profitable 50+% attack" be the time between the actual double spend and the "takeover" (when the attack chain replaces the "honest" chain) but the attack mechanism is the same. But monsterer is absolutely right and this is the reason why PoS protocols are to be considered - until this is solved - weaker than PoW protocols. I consider this attack unpractical in a chain with many stakeholders and reorg limits or "rolling checkpoints", and it's likely to be very expensive, but it may be considerably cheaper than a PoW 50+% attack.

It is an interesting attack scenario, not sure if there is an official name for it, but let's continue calling it, profitable 50+% attack. Stake based and derivative chains are more susceptible to it because, unlike PoW, a large number of blocks can be built in a short time.

The attacker must wait for a certain degree of finality (after his stake transfer transaction is placed in the chain) before launching this attack. The more uncertain a chain's finality is, the harder it is for the attacker since they have to wait longer.

Proof-of-Approval's (v2) features that may help or hurt against this attack are

- (hurt) Near instant finality - the attacker can launch the attack quickly after transferring

- Max stake transfer is limited per block so that entire 50+% stake cannot be transferred in 1 block. If the limit is set to 0.5%of total network stake, it would take the attacker 100 or more blocks to transfer.

- If the attack fork is larger than an epoch (epoch length vs stake transfer amounts are not yet finalized), then epoch approvals in the "real" chain would be larger than that in the attack chain and the real chain wins.

- If the attack fork is smaller than an epoch, the fork determination procedure as currently specified in v2, chooses higher stored approval in the topmost block. This makes such an attack possible.

A limit that has been considered and perhaps should be included in Proof-of-Approval is the max stake transfer per epoch. If that limit is set to something like 25% of stake, then this attack cannot succeed because of epoch approvals.

So, I plan to add stake transfer limit per epoch.
Shunsai

[shunsaitakahashi]

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