Decentralization of Power

[bytemaster]

I thing the average Joe is happy if he gets security wise a 2FA option and he gives a shit if it's more or less centralized...
So whatever is your last decision about the number of witnesses make sure we have the 2FA future ready ASAP on all clients!
It will be crucial for mass adoption. Don't delay it to long! Is it possible to have it on launch ready?

https://github.com/cryptonomex/graphene/wiki/Wallet%202-Factor%20Authentication%20Protocol

I agree completely, that for 99% of people concerned with losing their funds have to worry about the following:

1. Forgetting their password
2. Losing their wallet file
3. Their computer getting hacked
4. Getting Attacked by a Shark
5. Losing money as a result of only having 17 witnesses

In other words the network can be made far more secure by focusing on password recovery and wallet backup, then two-factor, and lastly having more witnesses.

[xeroc]

I thing the average Joe is happy if he gets security wise a 2FA option and he gives a shit if it's more or less centralized...
So whatever is your last decision about the number of witnesses make sure we have the 2FA future ready ASAP on all clients!
It will be crucial for mass adoption. Don't delay it to long! Is it possible to have it on launch ready?

https://github.com/cryptonomex/graphene/wiki/Wallet%202-Factor%20Authentication%20Protocol

There will not be 2FA authentication ... but something WAY BETTER ... corporate accounts and proposed transactions.

Essentially you can split spending rights for your funds among arbitrarily many entities and flexibly define the conditions that have to be met in order to spend funds ..
If your money is in one of those secured accounts .. you can propose a transfer (or trade) and send a "halve-valid" transaction into the network (blockchain) ... then you ask your partners to verify (e.g. via mail, sms, 2fa, face recognition, fart smell,...) and sign the (proposed) transaction .. of the conditions are met, the transaction will be validated by the network automatically ..

[liondani]

I thing the average Joe is happy if he gets security wise a 2FA option and he gives a shit if it's more or less centralized...
So whatever is your last decision about the number of witnesses make sure we have the 2FA future ready ASAP on all clients!
It will be crucial for mass adoption. Don't delay it to long! Is it possible to have it on launch ready?

https://github.com/cryptonomex/graphene/wiki/Wallet%202-Factor%20Authentication%20Protocol

[monsterer]

The system you describe is what Nxt effectively uses... those with stake get to produce blocks.

Very unreliable and ultimately far less security than by voting.

I'd like to hear your reasoning here.

[Helikopterben]

I agree that too much decentralization is wasteful and can erode performance.  The question I would like to ask is:  What is the goal of security through decentralization?  As BM stated, there are many variables that factor into security and security means different things to different people, but IMO the most important part of this aspect of security is simple:  protect user assets from being stolen.  Whether through direct theft of assets, inflation of the native asset (bts), manipulation of price feeds, ect.  Most all attack vectors revolve around stealing user assets or making their assets worthless.  I would argue that much of this has been solved through cryptography and giving witnesses as little privileges as possible and giving delegates delayed privileges to give users a chance to vote out bad delegates. 

It would be nice to see, if possible, what percentage of votes cast are via unique proxy (slate) to determine true decentralization of the network.  If, for example, >50% of votes are cast via 17 unique proxies, then It may not be advantageous to have more than 17 geographically distributed witnesses at current adoption levels.  As long as the network is sufficiently decentralized to protect user assets, then it works, and perception should not be a concern for something that works just as efficiently or more efficiently than its competitors.

[mike623317]

Surely we can find 25 people willing to run witnesses. Although I'm not very technical at the moment, I feel if i can learn exactly what to do I would be willing to run a witness to validate blocks for either free or near free.

In my opinion we need 25 heroes to help get off the ground before it takes on a life of its own. I'll set up if needs be.

Let's roll.

[r0ach]

For starters I am not a fan of voting in general.

I just haven't found anything that has fewer downsides.

If you want to keep voting in, why do you think the system I originally described isn't better than how Bitshares currently functions?  If you had 100% voter apathy, the top 101 collateral bids are automatically elected delegates.  If you didn't have massive voter apathy, the system would function identically to the way it does now.  There has to be a fallback mechanism for voter apathy, don't you understand that point?  None exists right now.  There is no logical fallback metric besides collateral either.

All the system would do is come with a checkbox that says, "automatic voting based on collateral on/off".  It would be on by default.  If you turn it off, then you go manually vote.  It's basically just pre-sorting the vote list to make it easy for apathy voters.  If collateral bids do not auto-renew, it also solves the problem of having zombie delegates you need to vote out.

[bytemaster]

For starters I am not a fan of voting in general.

I just haven't found anything that has fewer downsides.   The system you describe is what Nxt effectively uses... those with stake get to produce blocks.

Very unreliable and ultimately far less security than by voting.  They even have leased forging which is like proxy voting.

[monsterer]

Due to voter apathy, the system would most likely always run solely by collateral bids.  At that point you have to think, why leave voting in at all? 

I feel Bytemaster is too attached to voting so I had to make the suggestion the way I did as a compromise solution.  I would personally probably remove manual voting.

Either way, the cost is still a constant. You post collateral X to become a delegate, then users vote with stake Y. Total cost X+Y, which is a constant... In fairness, you have introduced a game theoretical cost to become an evil delegate which did not exist before, which is an overall positive.

[Method-X]

As I understand your proposal, this only makes a difference in terms of the visibility of delegates to vote for, rather than eligibility thereof?

Given that, I can't see how attack cost is exponential, or even linear - it seems to be just a plain old constant

My original proposal was that the system would be automated to vote for highest collateral bids by default setting.  It would only revert to the current system if users exercised the ability to manually vote.  If you wanted that increased cost of attack, you would have to remove the ability to manually vote.  I made the proposal the way I did because I'm not sure of everyone's consensus on removing manual voting, even though manual voting is probably a negative to leave in.  Due to voter apathy, the system would most likely always run solely by collateral bids.  At that point you have to think, why leave voting in at all? 

I feel Bytemaster is too attached to voting so I had to make the suggestion the way I did as a compromise solution.  I would personally probably remove manual voting.

Manual voting has a psychological impact. It's like how our current "democracy" is mostly illusory but people will support and spread it because of the "democracy is good" meme.

[r0ach]

As I understand your proposal, this only makes a difference in terms of the visibility of delegates to vote for, rather than eligibility thereof?

Given that, I can't see how attack cost is exponential, or even linear - it seems to be just a plain old constant

My original proposal was that the system would be automated to vote for highest collateral bids by default setting.  It would only revert to the current system if users exercised the ability to manually vote.  If you wanted that increased cost of attack, you would have to remove the ability to manually vote.  I made the proposal the way I did because I'm not sure of everyone's consensus on removing manual voting, even though manual voting is probably a negative to leave in.  Due to voter apathy, the system would most likely always run solely by collateral bids.  At that point you have to think, why leave voting in at all? 

I feel Bytemaster is too attached to voting so I had to make the suggestion the way I did as a compromise solution.  I would personally probably remove manual voting.

[monsterer]

You still have a deterministic number of delegates.  A flat rate collateral system only puts an upper limit on number of sybil nodes, while a bid system vastly increases the potential cost.  If there were 101 delegates, I would need to perform a sybil and impersonate 51 units then outbid everyone else with all of them.  Cost to attack becomes somewhat exponential instead of linear.  If scaled to 500 delegates, even more so.  My capital is also locked while running as a delegate, unusable for voting, so that locked capital can't be used to vote for each other either.

As I understand your proposal, this only makes a difference in terms of the visibility of delegates to vote for, rather than eligibility thereof?

Given that, I can't see how attack cost is exponential, or even linear - it seems to be just a plain old constant, like any other POS system. Even if you made delegates eligible via this system, the attack cost is still a constant proportional to stake, isn't it?

[r0ach]

I think the collateral bid system I suggested is far superior than the current system for dealing with that:

https://bitsharestalk.org/index.php/topic,18584.0.html

What makes your proposal any different from standard POS from an attack perspective?

I knew that question was going to come up.

You still have a deterministic number of delegates.  A flat rate collateral system only puts an upper limit on number of sybil nodes, while a bid system vastly increases the potential cost.  If there were 101 delegates, I would need to perform a sybil and impersonate 51 units then outbid everyone else with all of them.  Cost to attack becomes somewhat exponential instead of linear.  If scaled to 500 delegates, even more so.  My capital is also locked while running as a delegate, unusable for voting, so that locked capital can't be used to vote for each other either.

[monsterer]

I think the collateral bid system I suggested is far superior than the current system for dealing with that:

https://bitsharestalk.org/index.php/topic,18584.0.html

What makes your proposal any different from standard POS from an attack perspective?

[r0ach]

I think we need to strike the right balance between these two:
(1) our ability to prevent an attack
(2) our ability to recover once the attack happens

I think the collateral bid system I suggested is far superior than the current system for dealing with that:

https://bitsharestalk.org/index.php/topic,18584.0.html