Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Can We Change the Unit of Account to BitUSD  (Read 563 times)

0 Members and 1 Guest are viewing this topic.

clout

  • Guest
Can We Change the Unit of Account to BitUSD
« on: November 04, 2014, 01:31:03 AM »

Considering that BTS is not a stable currency shouldn't we use an alternative unit of account for revenue and expenses. Obviously this is not a traditional company but the fact the fees and delegate pay are functions of the BTS price it makes it extremely hard to do valuation such as P/E. If the price increases so does the earnings. If I vote in a delegate at a given % pay rate that pay fluctuates with the price of BTS.

I don't know about the logistical constraints, but it's much easier to come to consensus on how much an employee is worth in USD than it is to come to a consensus on how much an employee is worth in terms of dilution.

The problem with the model of bitcoin is not necessarily that there is dilution. The problem stems from the fact that the dilution is not commensurate with value of the work being done.

I don't know about other people, but I really hate thinking in terms of BTS. As recent events have shown, it really doesn't have an easily identifiable value.

Offline Fox

Re: Can We Change the Unit of Account to BitUSD
« Reply #1 on: November 04, 2014, 02:36:08 AM »
The idea of using a 'stable' BitAsset as the unit of account does have merit. 

Let's consider a possible implementation:  The Delegate Pay Rate is published as quantity X bitUSD (or any BitAsset, why limit it?).  Each time the Delegate produces a block, the network protocol purchases the requisite bitUSD as the DAC from the BitAsset market using up to 50 BTS (current proposed Maximum Dilution Rate) as the amount it may spend, then transfers those bitUSD to the Delegate as payment for supporting the DAC.  If the protocol must short to create the bitUSD, it must have the collateral to do so.  This may limit the maximum amount of bitUSD the Delegate will receive, or force the DAC to dilute beyond the Maximum Dilution Rate to issue the proper amount of bitUSD. 

Is my logic and/or understanding of the mechanics flawed?
Witness: fox

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: Can We Change the Unit of Account to BitUSD
« Reply #2 on: November 04, 2014, 06:22:42 AM »
clout, I agree.

Fox, I had a similar proposal to buy the BitUSD from the market using newly created BTSX in order to pay delegates (and other workers). Actually it was one part of many different proposals in this post including other less elegant but easier to implement solutions.

An even less elegant but even easier to implement solution I described in more detail recently (here and here) is one in which the delegates still get paid in BTS but use the one hour average price from the BTS/BitUSD market to convert their salary denominated in BitUSD into the BTS the delegates get paid per block. Bytemaster seems to still prefer to not bother implementing that and instead rather rely on trusting delegates to overcharge the pay rate and just burn the necessary excess BTS to maintain the BitUSD value of their salary that stakeholders think is fair. I think that just puts unnecessary extra burden on stakeholders to check up on yet another thing that the delegates are entrusted to do correctly.

I should note that I discovered a change that is likely to be beneficial for the proposal I laid out here and here. The change wouldn't be necessary if there was a proper worker pay system and prioritization list decided through delegate proposals ratified by enough shareholder votes as I have previously described and would ideally prefer. But since the worker pay system is shoehorned into the delegate system for implementation simplicity, this change to my proposal which I will describe shortly becomes very beneficial since it is so easy currently for a delegate to get into the top 101 with little approval. This means that with my original October 31st proposal, an attacker with enough stake to get his delegate into rank 101 with a requested salary that is orders of magnitude bigger than everyone else's requested salary could essentially saturate the dilution rate to its maximum cap and take nearly all of it for himself to the detriment of all other delegates. Although this would ideally inspire stakeholders to vote for other good delegates to raise 101 good delegates to an approval rating above that of the attacker, there is a risk that voter apathy could keep that evil delegate in the top 101 for a little bit too long causing undesirable dilution to stakeholders and financially hurting the good delegates.

The change only applies to the case where the total requested BitUSD salary for all delegates in a round is above the current BitUSD price of the 5050 BTS limit and thus some scaling is required. The block reward for each of the 101 active delegate in a given round would be determined as follows:
  • Calculate the appropriate one-hour average price, P, from the BTS/BitUSD market, where P is in units of BTS/BitUSD.
  • Calculate the budget in BTS for the round, BUDGET. This is usually just a fixed number like 5050, but it can in addition include any BTS that was allocated to be received by the delegates in the previous but was not because the delegate missed the block.
  • Determine the basic pay, in BitUSD, for each delegate for just signing blocks (call it BASIC_SALARY). This is likely just a fixed number like 0.03 BitUSD (which works out to $937 per year per delegate).
  • Calculate BASIC_BUDGET = sum of P*min(REQUESTED_SALARY_{D}, BASIC_SALARY) for all D in the set of the top 101 delegates.
  • If BASIC_BUDGET >= BUDGET, then calculate R = BUDGET/BASIC_BUDGET, otherwise R = 1.
  • Set active delegate D's block reward to BLOCK_REWARD_{D} = R*P*min(REQUESTED_SALARY_{D}, BASIC_SALARY) for all D in the set of the top 101 delegates.
  • If BASIC_BUDGET < BUDGET, calculate REMAINING_BUDGET = BUDGET - BASIC_BUDGET, and then iterate through the sequence of the top 101 delegates in descending approval rating order:
    • If REQUESTED_SALARY_{D} <= BASIC_SALARY, continue to the next delegate in the loop or exit the loop if D was the 101th delegate.
    • If REMAINING_BUDGET <= P*(REQUESTED_SALARY_{D} - BASIC_SALARY), set BLOCK_REWARD_{D} = BLOCK_REWARD_{D} + REMAINING_BUDGET and exit loop.
    • If REMAINING_BUDGET > P*(REQUESTED_SALARY_{D} - BASIC_SALARY), set BLOCK_REWARD_{D} = BLOCK_REWARD_{D} + P*(REQUESTED_SALARY_{D} - BASIC_SALARY), set REMAINING_BUDGET = REMAINING_BUDGET -  P*(REQUESTED_SALARY_{D} - BASIC_SALARY), and continue to the next delegate in the loop or exit the loop if D was the 101th delegate.

The above solves the problem of an attacker delegate stealing the pay of other delegates by saturating the dilution cap with a huge requested salary. However, if total requested salary of good delegates is much less than the dilution limit, the attacker could still take over the entire difference if he can get himself into rank 101, which still causes stakeholders unnecessary dilution (although thankfully no longer to the financial detriment of other good delegates). Ideally the stakeholders would fix this by replacing the bad delegate with better delegates by voting with more of their stake, but to further improve on this we might have another limit on the requested salary that is a function of the approval rating. For example if the approval rating of a delegate is less than the median approval rating, the X = DELEGATE_APPROVAL_RATING/MEDIAN_APPROVAL_RATING ratio could be used to determine a salary limit of max(BASIC_SALARY, SALARY_LIMIT*f(X)), where f(x) is a monotonically increasing function over the domain [0,1] with f(0) = 0 and f(1) = 1, and SALARY_LIMIT is some sensible limit such as the median requested salary of the top 50 delegates. Other limits can of course be considered, but the idea is that if you cannot get enough approval to get above the median approval rating, you should not be able to just get any salary you want but you are at least guaranteed to be able to get the BASIC_SALARY.
« Last Edit: November 04, 2014, 06:35:45 AM by arhag »

Offline liondani

Re: Can We Change the Unit of Account to BitUSD
« Reply #3 on: November 04, 2014, 07:54:49 AM »
Each delegate should have the option choose in which bitAsset he wants to be paid...

The most: bitUSD
The Europeans: bitEUR
Chinese: bitCNY
etc...
  https://bitshares.OPENLEDGER.info/?r=GREECE  | You are in Control | BUY | SELL | SHORT | SWAP | LOAN | TRADE |  

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: Can We Change the Unit of Account to BitUSD
« Reply #4 on: November 11, 2014, 04:02:59 PM »
An even less elegant but even easier to implement solution I described in more detail recently (here and here) is one in which the delegates still get paid in BTS but use the one hour average price from the BTS/BitUSD market to convert their salary denominated in BitUSD into the BTS the delegates get paid per block. Bytemaster seems to still prefer to not bother implementing that and instead rather rely on trusting delegates to overcharge the pay rate and just burn the necessary excess BTS to maintain the BitUSD value of their salary that stakeholders think is fair. I think that just puts unnecessary extra burden on stakeholders to check up on yet another thing that the delegates are entrusted to do correctly.

I should note that I discovered a change that is likely to be beneficial for the proposal I laid out here and here. The change wouldn't be necessary if there was a proper worker pay system and prioritization list decided through delegate proposals ratified by enough shareholder votes as I have previously described and would ideally prefer. But since the worker pay system is shoehorned into the delegate system for implementation simplicity, this change to my proposal which I will describe shortly becomes very beneficial since it is so easy currently for a delegate to get into the top 101 with little approval. This means that with my original October 31st proposal, an attacker with enough stake to get his delegate into rank 101 with a requested salary that is orders of magnitude bigger than everyone else's requested salary could essentially saturate the dilution rate to its maximum cap and take nearly all of it for himself to the detriment of all other delegates. Although this would ideally inspire stakeholders to vote for other good delegates to raise 101 good delegates to an approval rating above that of the attacker, there is a risk that voter apathy could keep that evil delegate in the top 101 for a little bit too long causing undesirable dilution to stakeholders and financially hurting the good delegates.

The change only applies to the case where the total requested BitUSD salary for all delegates in a round is above the current BitUSD price of the 5050 BTS limit and thus some scaling is required. The block reward for each of the 101 active delegate in a given round would be determined as follows:
  • Calculate the appropriate one-hour average price, P, from the BTS/BitUSD market, where P is in units of BTS/BitUSD.
  • Calculate the budget in BTS for the round, BUDGET. This is usually just a fixed number like 5050, but it can in addition include any BTS that was allocated to be received by the delegates in the previous but was not because the delegate missed the block.
  • Determine the basic pay, in BitUSD, for each delegate for just signing blocks (call it BASIC_SALARY). This is likely just a fixed number like 0.03 BitUSD (which works out to $937 per year per delegate).
  • Calculate BASIC_BUDGET = sum of P*min(REQUESTED_SALARY_{D}, BASIC_SALARY) for all D in the set of the top 101 delegates.
  • If BASIC_BUDGET >= BUDGET, then calculate R = BUDGET/BASIC_BUDGET, otherwise R = 1.
  • Set active delegate D's block reward to BLOCK_REWARD_{D} = R*P*min(REQUESTED_SALARY_{D}, BASIC_SALARY) for all D in the set of the top 101 delegates.
  • If BASIC_BUDGET < BUDGET, calculate REMAINING_BUDGET = BUDGET - BASIC_BUDGET, and then iterate through the sequence of the top 101 delegates in descending approval rating order:
    • If REQUESTED_SALARY_{D} <= BASIC_SALARY, continue to the next delegate in the loop or exit the loop if D was the 101th delegate.
    • If REMAINING_BUDGET <= P*(REQUESTED_SALARY_{D} - BASIC_SALARY), set BLOCK_REWARD_{D} = BLOCK_REWARD_{D} + REMAINING_BUDGET and exit loop.
    • If REMAINING_BUDGET > P*(REQUESTED_SALARY_{D} - BASIC_SALARY), set BLOCK_REWARD_{D} = BLOCK_REWARD_{D} + P*(REQUESTED_SALARY_{D} - BASIC_SALARY), set REMAINING_BUDGET = REMAINING_BUDGET -  P*(REQUESTED_SALARY_{D} - BASIC_SALARY), and continue to the next delegate in the loop or exit the loop if D was the 101th delegate.

The above solves the problem of an attacker delegate stealing the pay of other delegates by saturating the dilution cap with a huge requested salary. However, if total requested salary of good delegates is much less than the dilution limit, the attacker could still take over the entire difference if he can get himself into rank 101, which still causes stakeholders unnecessary dilution (although thankfully no longer to the financial detriment of other good delegates). Ideally the stakeholders would fix this by replacing the bad delegate with better delegates by voting with more of their stake, but to further improve on this we might have another limit on the requested salary that is a function of the approval rating. For example if the approval rating of a delegate is less than the median approval rating, the X = DELEGATE_APPROVAL_RATING/MEDIAN_APPROVAL_RATING ratio could be used to determine a salary limit of max(BASIC_SALARY, SALARY_LIMIT*f(X)), where f(x) is a monotonically increasing function over the domain [0,1] with f(0) = 0 and f(1) = 1, and SALARY_LIMIT is some sensible limit such as the median requested salary of the top 50 delegates. Other limits can of course be considered, but the idea is that if you cannot get enough approval to get above the median approval rating, you should not be able to just get any salary you want but you are at least guaranteed to be able to get the BASIC_SALARY.

I created a simple little interactive calculator that models delegate pay according to the system I described in the quote above (using f(x) = 1 - (1-x)^2). I do have improvements to the above system in mind, but I thought it would be worth sharing this calculator for the system as it currently is before further complicating it.

I created this to show people that we are better off with this model for delegate pay rather than the current plan of restricting each delegates pay to a maximum of 50 BTS. We should not require developers who we wish to pay a high salary to run multiple delegates and thus reduce the decentralization of DPOS. We should not have to keep track of whether the delegates have burned the necessary amount of BTS (due to the volatility of BTS) so that they only collect the appropriate salary measured in USD. A delegate candidate should be able to request any salary they want (specified in USD/round) and it should be shown in the client in whatever units are convenient for the user, such as USD/round, USD/week, EUR/week, CNY/year, etc. The actual salary that the delegate can collect in a given round is dependent on many factors and described in more detail in my above post.

Feel free to play around with the delegate salary calculator. You can click on any of the values in the requested salary column and change the requested USD/round salary for that delegate. After the focus is removed from that textbox (you can press Tab, Esc, or just click somewhere else), it will trigger an update of all of the actual salaries delegates will receive. You can also adjust the basic salary (which is the minimum salary every active delegate should be allowed to receive just for producing blocks, assuming the overall dilution budget allows) and the maximum inflation per round (by default set to current hard cap of 5050 BTS per round) which will affect the per-round budget available to pay the delegate salaries.

Edit: Updated JSFiddle script to use the new port that bitsharesblocks.com uses for the API.
« Last Edit: November 14, 2014, 11:48:11 PM by arhag »

Offline bytemaster

Re: Can We Change the Unit of Account to BitUSD
« Reply #5 on: November 11, 2014, 05:20:55 PM »
Delegates should campaign on a dollar valuation and commit to burn everything above that dollar valuation once per week.

This is all provable and gives us all a chance to test their integrity.   A delegate who cannot be trusted to burn what he promised to burn is someone we don't want as a delegate.

The complexity of implementing this in the code is likely not worth it.
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 xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12280
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: Can We Change the Unit of Account to BitUSD
« Reply #6 on: November 11, 2014, 05:23:13 PM »
* xeroc wants to have a dapp to do that .. preferably the dapp takes bts exchanges some into usd and burns the rest automatically
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: Can We Change the Unit of Account to BitUSD
« Reply #7 on: November 11, 2014, 06:28:11 PM »
Delegates should campaign on a dollar valuation and commit to burn everything above that dollar valuation once per week.

This is all provable and gives us all a chance to test their integrity.   A delegate who cannot be trusted to burn what he promised to burn is someone we don't want as a delegate.

The complexity of implementing this in the code is likely not worth it.

The approach I have outlined goes beyond the volatility issue (although that is a very important issue as well in my opinion). Using the current market price of BTS, it could allow us to pay 83 delegates a basic salary of $2000/year to just run the servers and pay another 18 delegates a salary of $150,000/year. If we wanted 18 workers to each get paid $150,000/year in the current system, each worker would need to run 5 delegates each (for a total of 90 delegates controlled by 18 people). You could then have another 11 delegates getting paid a basic salary. This means there would only be 29 unique individuals running the DPOS consensus system. An alternative strategy would be to elect 101 fully paid unique delegates who are then trusted to allocate portions of their rewards to the actual workers we want the funds to go to. In that case you maintain the decentralization but you end up requiring even more trust in the delegates and thus a higher burden on the voters to verify that the delegates are doing what they promised.


* xeroc wants to have a dapp to do that .. preferably the dapp takes bts exchanges some into usd and burns the rest automatically

You could have a smart contract which is designated to receive the delegate pay on behalf of the block signing delegate. The smart contract could then try to sell just enough BTS to get the amount of BitUSD hard-coded in the smart contract and burn the rest. That would solve the volatility issue, but it still doesn't solve the decentralization issue that arises when stakeholders want to have extremely skewed distribution of delegate salaries that I described in my previous paragraph. Fixing those issues requires actually fundamentally changing the way the delegate rewards are calculated, which as far as I am aware could not be tweaked even with Turing complete scripts added on to the blockchain.

Of course, what I really want is for delegates to be paid the same BitUSD amount and for workers' salaries to be managed through delegate proposals ratified by shareholder vote. But the system I have described in this thread is a simpler solution that can be applied to the current delegate system without too many changes, yet still partially captures some of the benefits of the system that I really want.


 

Google+