Quote from: shunsaitakahashi on March 28, 2018, 03:42:00 PM

Hello Paul,

Quote from: monsterer2 on March 28, 2018, 07:28:30 AM

Quote from: shunsaitakahashi on March 22, 2018, 04:17:56 PM

Quote from: monsterer2 on March 20, 2018, 10:01:37 AM

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.