Author Topic: Proposal: Keep delegates' task simple - signing blocks.  (Read 7179 times)

0 Members and 1 Guest are viewing this topic.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
These are the things I am interested in going after once the merger is complete. Unfortunately I suspect we will all have to work on thin clients instead for the next several weeks...

Sent from my SCH-I535 using Tapatalk

Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I think taking the attitude that we will never get 51% approval on anything is defeatist.  I think it reflects an unwillingness to do the work/system design/creative problem solving needed to get there.

Agent86, just to be clear, I don't hold the view that getting over 50% approval on any given proposal is highly improbable. I do however think that it is unlikely to get over 50% voter participation on every proposal.

I think certain topics are important enough to shareholders that a sufficient number will participate to get 51% approval (assuming the majority actually do agree with the proposal). And those topics are important enough to require at least 50% approval before they are ratified. These include topics such as a hard fork that adds new features or significantly changes the behavior of existing features, or topics such as changing the dilution cap or printing a lump sum of BTS to pay for some unexpected expense.

But I think lesser issues such as adjusting a worker's pay should not require 50% approval so that the DAC can be more agile. This is why I created that "A - D >= 0.15 * (1 - A - D)" rule that I outlined in my previous post. The idea is that uncontroversial proposals should be able to pass with as small as 15% voter participation, but controversial proposals may not be capable of being ratified until there is even up to 100% voter participation. Obviously the particular numbers and formulas can be adjusted, but what are your opinions on the general principle behind that rule?

Also, I agree that we should work on increasing voter participation. Improving the UI to encourage stakeholders to vote and propagate their vote changes to the blockchain is certainly important and should be done. I also have other suggestions to improve voter participation:
  • We need to financially incentivize people to propagate their votes (votes they may have already made on their local client) to the blockchain so that those votes can actually be effective. Since it costs transaction fees to do this, I think we need to make it less profitable to stakeholders who don't do this. One way of achieving this is to have a fixed 0.5% p.a. interest rate on BTS (claimed by simply moving one's BTS stake) that is paid for by dilution. This interest would be simple linear interest, not continuously compounding interest. The simple interest would be used for both technical simplicity and also because continuous compounding would mean stakeholders (especially those with large stakes) wouldn't be motivated to update their stake (and thus their votes) more frequently than the fixed hard deadline for claiming the interest (say 3 months). With a 0.5% p.a. interest, 3 month deadline, and $0.01 transaction fee, it is profitable for a BTS balance worth as small as $10 to update their vote at least once every 3 months. Larger stake would find it optimal to update their votes more frequently. I have previously done the rough math on the optimal update frequency for different-sized stake as a function of interest and transaction fees; I will have to do it again more formally to show why it could be in the stakeholders collective interest to provide this interest mechanism to motivate stakeholders to propagate their votes to the blockchain.
  • A very rational and important reason why someone may hesitate to update their votes is because it requires bringing online the same private keys that can spend their balance. If their computer is compromised that means a hacker can steal all of their funds. We need to implement cold storage with offline transaction signing and multisig as soon as possible for security reasons. But if we design the multisig properly, it can have the side benefit of keeping the keys needed to move the funds and the keys needed to update the votes separate. This means users could use their hot client on their computer to  conveniently update their votes and collect the interest on their BTS balance, but if they want to spend their BTS balance they would have to boot into their live offline Linux environment to input their second passphrase, sign the spending transaction with the secondary cold storage key, store the signed transaction on a flash drive, boot back into the regular online OS, and finally submit the fully signed spending transaction to the network.
« Last Edit: November 06, 2014, 02:08:53 am by arhag »

sumantso

  • Guest
There seems to be some wrangling over the AGS funds. If delegates and employees are kept separated, then employees can be paid more than the max available for a delegate in the current scheme. This will rule out the necessity of paying lump sums upfront to compensate. Atleast now you can actually pay that lump upfront, what happens in future if a superstar employee turns up?

The AGS funds can also be put into as the block rewards as the employee pay, rather than diluting for now. After they are all burned up, dilution can start.

I have given Valentine, Nathan, Vikram, and Toast each 30K PTS so they have a vested (literally) interest in seeing BTS grow.

We are very much into "no contracts" and "trust based" allocation of resources.   Each of these guys has proven their loyalty to the project and the greater cause and their passion is undeniable. 

You want independent developers making decisions and I have selected these guys as an independent team that I want to have financial independence.

They will be taking paid delegate positions, but I am limiting it to one delegate each which at 30K/year is only 20% of what they could be making and takes nothing into consideration for the extra risks in this industry.   

In other words, giving them the funds makes things more secure and further decentralizes the process.

30K PTS does not seem much, aka enough.

I hope you are also giving them (as toast hinted in his post) something extra from the BTC portion of the AGS fund (be it already or soon enough  converted into BTSX/BTS)?

[edit] new posts, while typing, make my post largely irrelevant, but I will keep it for the 1st sentence.

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile

Bytemaster, you still haven't explained why the "delegate proposal ratified by shareholder vote" proposal I made doesn't scale (or if it does scale, then what the other reasons are for why you are still against it). I discussed the important technical parts here, here, and here. The implementation I described only adds 5 bytes to each transaction (which is not a big deal, especially considering more than that amount of space will be freed thanks to removing the memo field with the new lightweight client mail system), and I am fairly confident it doesn't need to add much in transaction processing time. If I am wrong I would appreciate an explanation of why.

On the other hand, if you are against this proposal for other reasons (philisophical, you think it is socially a bad way to manage a DAC, etc.), then I would like to hear a clear reason behind your opinions. The main difference that I see is that it forces the stakeholders as a collective to come to a consensus before any change in worker payments gets implemented (so it is an atomic action). In the delegate system, the approval of a single delegate candidate can gradually rise until it crosses the threshold into the top 101 and the delegate starts getting paid. In my system, enough stakeholders would need to agree before a new worker could be hired, fired, or have their salary changed. Obviously requiring 51% approval for this would be a bit too much and would result in gridlock.

My suggestion around this gridlock is to use the following rule for decisions that involve changing workers and their pay (other more important DAC decisions could have stricter rules). The fraction of total stake in approval of a proposal is define as A. The fraction of total stake in disapproval of that proposal is defined as D. The remaining fraction of stake, N = 1 - A - D, has to be neutral on that proposal. For these worker-related proposals to become ratified and thus activated the following conditions need to be true as of the latest block:
  • The proposal needs to be older than 24 hours (to give some time for stakeholders to even see there is a new proposal).
  • At least 15% of stake needs to be voting on the proposal, or V = A + D >= 0.15.
  • The net approval, A - D, must be sufficiently large, which is define precisely as A - D >= 0.15 * (1 - A - D).
Working out the math, one can find that the ratio between approval and disapproval, A/D, needs to satisfy the inequality A/D >= 2/(1 - 0.15*(1/V - 1)) - 1 for the third requirement to be satisfied. I plotted the right hand side of that inequality over the domain [0.15, 1] over which it is valid due to the second requirement. This plots the minimum ratio between approval and disapproval needed for the worker-related proposal to be ratified as a function of voter participation. At the minimum participation level of 15%, there needs to be at least 12.4 yeas to every nay, which is unlikely to happen unless the proposal is very uncontroversial. For a proposal to be ratified with only a 2:1 ratio between yea:nay, the DAC would require at least 31% of stake to participate in the vote. And clearly if everyone participates in the vote, the proposal can be passed if there is even just a tiny extra bit of stake in approval of the proposal compared to the stake in disapproval of the proposal.

I think taking the attitude that we will never get 51% approval on anything is defeatist.  I think it reflects an unwillingness to do the work/system design/creative problem solving needed to get there.

My view is if your system can't reach 51% consensus on anything it is one of two problems:

   1) The system design, user interface, or incentives are flawed.
   2) You may need to reconsider the group of people you have chosen as your fellow shareholders
   
Of course you don't write off people as lazy until you have very carefully examined everything in point #1.  #2 might seem harsh but I think of these systems like businesses and if you can't agree on anything with your co-owners or they have "checked out"  you may be forced to consider parting ways… (maybe this possibility will be part of their motivation).

Offline Riverhead

I think it'll evolve to that. I'll run my IT delegate at 3% while I can and when that's too much work/expense I'll join forces with a business/marketing delegate for the combined fee under a new name.

Sent from my SM-G900T using Tapatalk


Offline bytemaster

I think I prefer delegates get elected to hire workers by combining funds. 

Delegates can then avoid most of the direct work and will only fund projects/workers that people want or burn the funds.

I think a proposal system is good for hard forks and the like.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
A block signer can be appointed and paid by a delegate and can be fired/reassigned at any time by a delegate. 

Thats just unnecessary distraction for the delegate, who may not be the best in choosing the correct block signer. If the delegate has a skill set which would be useful, let him just do that, no need to make him seek out an able block signer and outsource.

Another advantage for separation would be that there won't be a limit of the pay or the number of employees, giving better flexibility. It also will allow for short bounty style payments, which would case quite a upheaval in the  current model as a delegate comes and leaves for a short period.

What part of we cannot have shares vote for more than 101 *THINGS* because it does not scale.  So saying that there won't be a limit on employees or pay is wrong.  We need to limit pay to prevent unbounded dilution and we need to limit funded positions because of transaction processing time and size.

Bytemaster, you still haven't explained why the "delegate proposal ratified by shareholder vote" proposal I made doesn't scale (or if it does scale, then what the other reasons are for why you are still against it). I discussed the important technical parts here, here, and here. The implementation I described only adds 5 bytes to each transaction (which is not a big deal, especially considering more than that amount of space will be freed thanks to removing the memo field with the new lightweight client mail system), and I am fairly confident it doesn't need to add much in transaction processing time. If I am wrong I would appreciate an explanation of why.

On the other hand, if you are against this proposal for other reasons (philisophical, you think it is socially a bad way to manage a DAC, etc.), then I would like to hear a clear reason behind your opinions. The main difference that I see is that it forces the stakeholders as a collective to come to a consensus before any change in worker payments gets implemented (so it is an atomic action). In the delegate system, the approval of a single delegate candidate can gradually rise until it crosses the threshold into the top 101 and the delegate starts getting paid. In my system, enough stakeholders would need to agree before a new worker could be hired, fired, or have their salary changed. Obviously requiring 51% approval for this would be a bit too much and would result in gridlock.

My suggestion around this gridlock is to use the following rule for decisions that involve changing workers and their pay (other more important DAC decisions could have stricter rules). The fraction of total stake in approval of a proposal is define as A. The fraction of total stake in disapproval of that proposal is defined as D. The remaining fraction of stake, N = 1 - A - D, has to be neutral on that proposal. For these worker-related proposals to become ratified and thus activated the following conditions need to be true as of the latest block:
  • The proposal needs to be older than 24 hours (to give some time for stakeholders to even see there is a new proposal).
  • At least 15% of stake needs to be voting on the proposal, or V = A + D >= 0.15.
  • The net approval, A - D, must be sufficiently large, which is define precisely as A - D >= 0.15 * (1 - A - D).
Working out the math, one can find that the ratio between approval and disapproval, A/D, needs to satisfy the inequality A/D >= 2/(1 - 0.15*(1/V - 1)) - 1 for the third requirement to be satisfied. I plotted the right hand side of that inequality over the domain [0.15, 1] over which it is valid due to the second requirement. This plots the minimum ratio between approval and disapproval needed for the worker-related proposal to be ratified as a function of voter participation. At the minimum participation level of 15%, there needs to be at least 12.4 yeas to every nay, which is unlikely to happen unless the proposal is very uncontroversial. For a proposal to be ratified with only a 2:1 ratio between yea:nay, the DAC would require at least 31% of stake to participate in the vote. And clearly if everyone participates in the vote, the proposal can be passed if there is even just a tiny extra bit of stake in approval of the proposal compared to the stake in disapproval of the proposal.
« Last Edit: November 04, 2014, 11:31:21 pm by arhag »

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
I really like how this works, actually. If Delegates don't make sure they've got block production taken care of, they don't get paid. That's genius incentive structure.

Offline starspirit

  • Hero Member
  • *****
  • Posts: 948
  • Financial markets pro over 20 years
    • View Profile
  • BitShares: starspirit
Quote
Only issue I can see is voter apathy.

I don't think it's really fair to blame it all on voter apathy. The infrastructure is quite immature as posters in this thread have pointed out. If it were easier to understand and use you would get more voting.

Then there's the "what makes a good delegate" side of the equation. As I said above it's nothing personal but I didn't vote for you nor would I for anyone that hasn't demonstrated a deeper understanding of the nuts & bolts of running a delegate node.

As I posted, I think more refinement and perfecting of the DPoS system is required to truly have a solid, robust system that can withstand attack.
+5%

Its not apathy. Its time. Its complication. Its not having the knowledge or skill to make a proper judgement on some issues. Its prioritisation of where you do have skills. etc etc.
No system should have to rely on everybody making an informed vote. Every new vote forced into the system because of an ideology that more people must vote is actually a vote with far less value and information attached to it. The decision structure should be robust enough to avoid power-centralisation even if people selectively vote.
One method that could be explored to deal with this, alluded to in another thread, is to allow people to delegate their votes to somebody aligned on their key issues and principles. This would form blocs that people could switch at any time if they felt their interests were not being met, but individuals would not need to understand the workings of every delegate. This and other approaches should be explored so make it easier for people and still an effective control.

Offline teenagecheese

  • Full Member
  • ***
  • Posts: 134
    • View Profile
A block signer can be appointed and paid by a delegate and can be fired/reassigned at any time by a delegate. 

Thats just unnecessary distraction for the delegate, who may not be the best in choosing the correct block signer. If the delegate has a skill set which would be useful, let him just do that, no need to make him seek out an able block signer and outsource.

Another advantage for separation would be that there won't be a limit of the pay or the number of employees, giving better flexibility. It also will allow for short bounty style payments, which would case quite a upheaval in the  current model as a delegate comes and leaves for a short period.

What part of we cannot have shares vote for more than 101 *THINGS* because it does not scale.  So saying that there won't be a limit on employees or pay is wrong.  We need to limit pay to prevent unbounded dilution and we need to limit funded positions because of transaction processing time and size.

Basically if we go with what you are proposing we will end up with 101 small companies formed around delegates. So someone has to join one of these companies or start their own (which will be really hard once the others are established) to work for BitShares. A marketer or whoever should be allowed to focus only on their task and be able to do it independently because that will allow for the most people to contribute. That's also the most decentralized.

The issues you bring up about transaction time and size can easily be solved as well. Still have 101 regular delegates, where things happen every 5-10 seconds, but then have your unlimited number of employee delegates who are maybe checked by the network once a day for voting and performance and such. They don't have to be in every block because they're not signing transactions.

Also, do you really think this will make a problem with max dilution? No, it won't, only people that are needed will be paid and if it is too much pay they won't be elected, maybe we'll only have ~10 employees to start. The voters decide max dilution and how many people are employed and at what rate. In addition, dilution shouldn't even be present most of the time because this is a company and it should be able to earn enough profit (from transaction fees or whatever other income we can think of) to sustain itself.

Before I finish, the only issues I can see with what I'm saying is that this would be a lot of people for users to vote for and keep track of. for that reason, SOME, of the employee delegates would need to be formed in companies (like the marketing group 1,2,3). Still individual employee delegate should be able to exist and no employee delegate, alone or in a group, should have to work with a network delegate. There's just no point. Its unnecessary complication. Make this thing EFFICIENT AND LOGICAL.

Offline bytemaster

Running a delegate node is relatively easy and worst case they don't produce blocks and thus don't get paid.  Not producing a block every now and then isn't the end of the world while we are growing.

By the time we get big enough for it to matter then delegates will be paid more than enough to have a full staff.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Thom

Quote
Only issue I can see is voter apathy.

I don't think it's really fair to blame it all on voter apathy. The infrastructure is quite immature as posters in this thread have pointed out. If it were easier to understand and use you would get more voting.

Then there's the "what makes a good delegate" side of the equation. As I said above it's nothing personal but I didn't vote for you nor would I for anyone that hasn't demonstrated a deeper understanding of the nuts & bolts of running a delegate node.

As I posted, I think more refinement and perfecting of the DPoS system is required to truly have a solid, robust system that can withstand attack.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline Method-X

  • Hero Member
  • *****
  • Posts: 1131
  • VIRAL
    • View Profile
    • Learn to code
  • BitShares: methodx
I've been wondering about this ever since I heard MeTHoDx should be a delegate. Don't get me wrong, I really like the guy, but does he have the technical chops to run a delegate node with the level of reliability that competes with 100 other delegates?

You're absolutely right. It was pretty hard for me to set up a delegate mainly because I don't use command line often. So that was a really big barrier. Riverhead helped me get set up and he's going to make sure everything is running smoothly tonight when the hard fork happens. That said, I've been learning a lot and command line isn't actually that hard when you've got experience with other tech related things (JavaScript, HTML5, PHP, etc). So I'm not totally going at it blind. I imagine a marketer/tech combo will be quite common going forward from here.

I jumped into crytocurrencies directly with BitShares, so I would love to hear a comparative analysis from someone like BM or Andreaus Antonopolis to see whether our learning curve is faster, slower or about the same as it was for early PoW.

Only issue I can see is voter apathy. So many possible attack vectors (that I won't go on about) can be completely avoided if voting was more common. Currently, bytemaster can vote delegates in and out at will. This is obviously very beneficial for the time being but has to change for DPoS to be taken seriously as a decentralized solution. That said, as long as we stay true to the company metaphor, I think we'll be alright.

Offline Thom

We are in favor of separating block signers from delegate accounts.

A block signer can be appointed and paid by a delegate and can be fired/reassigned at any time by a delegate. 

We cannot have more than 101 elected positions, it simply doesn't scale.

so marketer delegates don't have to know about server/vps...etc and still can be paid by a network ? That would be nice ...

I've been wondering about this ever since I heard MeTHoDx should be a delegate. Don't get me wrong, I really like the guy, but does he have the technical chops to run a delegate node with the level of reliability that competes with 100 other delegates?

This is yet another thread (and I now have the strong impression they are numerous) where rather important issues related to DPoS are not yet settled. BitShares is an experiment after all, and these discussions promote evolutionary refinements, and that's a good thing.

PoW has been around for a very long time compared to DPoS, so I am wondering for those of you who are PoW veterans how the DPoS state of the art compares with where Bitcoin was after it was in the wild and had a $25M - $70M marketcap.

I jumped into crytocurrencies directly with BitShares, so I would love to hear a comparative analysis from someone like BM or Andreaus Antonopolis to see whether our learning curve is faster, slower or about the same as it was for early PoW.

That is also an important question to help with our marketing, as well as it is for people deciding whether to get involved with BitShares. Sometimes I have a hard time thinking of our marketing as being directed to early adopters, tho that is the reality of where we're at currently.

It seems to me we still have some important questions to figure out about the practicalities of DPoS operation. I kindof wonder if BM in retrospect thinks having an earlier focus on building infrastructure to support choosing and maintaining delegates might have been a wise investment of developer time, infrastructure such as a reputation system and voting options.

And that brings to mind how difficult finding info is here on this forum. It has already been suggested we need a new forum structure, to separate major areas of concern such as core development, principles and philosophy, marketing, new users, investors, legal and regulatory. 

When I look at the forum hierarchy it isn't that bad, but most of the discussions take place here in the general category rather than under more appropriate sections. It would probably take a lot of dedicated effort to monitor the discussions and move posts / threads around to keep things organized. I host a SMF forum for a very small community so I'm familiar with the database structure it uses. I would say a day or two of writing SQL queries would be adequate to create some tools to make moving things around pretty quick and easy. It still would require a human to make the judgment of how posts should be moved, so keeping the forum organized would require regular monitoring and moderation.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

sumantso

  • Guest
A block signer can be appointed and paid by a delegate and can be fired/reassigned at any time by a delegate. 

Thats just unnecessary distraction for the delegate, who may not be the best in choosing the correct block signer. If the delegate has a skill set which would be useful, let him just do that, no need to make him seek out an able block signer and outsource.

Another advantage for separation would be that there won't be a limit of the pay or the number of employees, giving better flexibility. It also will allow for short bounty style payments, which would case quite a upheaval in the  current model as a delegate comes and leaves for a short period.

What part of we cannot have shares vote for more than 101 *THINGS* because it does not scale.  So saying that there won't be a limit on employees or pay is wrong.  We need to limit pay to prevent unbounded dilution and we need to limit funded positions because of transaction processing time and size.

I meant the limit per delegate as determined by 100% pay rate. Of course the overall cap will remain, and they will be paid as a percentage of that. This is to ensure that if a truly great contributor comes along he is suitably rewarded to work for us.