poll for the percent based transfer fee

[abit]

OK, according to the voting, the parameters in USD can be 0.1%/$0.003/$0.06

Let's assume we go with this plan and configure percentage fees according to the results of the poll: [min: 1 BTS max: 20 BTS,  rate: 0.1%].
What would the flat transfer fee be in this case for BTS and other assets remaining on the flat scheme?

I thought we were going to start discussing the max/min values in terms of a stable currency, preferably USD since the actual network cost has been defined in terms of USD.

Also, why is it that we cannot apply the %-based fee to BTS?  If anything, shouldn't that be the easiest asset to apply %-based fee since we don't have to worry about the CER changing and causing the calculated/target minimum fee (in USD terms) to go below the actual minimum fee in BTS terms?

BTS's owner is null-account, which means there is some kind of consensus that nobody can change parameters of BTS.

[jakub]

OK, according to the voting, the parameters in USD can be 0.1%/$0.003/$0.06

Let's assume we go with this plan and configure percentage fees according to the results of the poll: [min: 1 BTS max: 20 BTS,  rate: 0.1%].
What would the flat transfer fee be in this case for BTS and other assets remaining on the flat scheme?

whatever the committee decides for ..

My point is this:
max fee = 20 BTS -> flat fee would have to be significantly below 20 BTS (as otherwise no issuer would use flat fees) -> end of LTM as nobody will have a reason to buy it.

[tbone]

OK, according to the voting, the parameters in USD can be 0.1%/$0.003/$0.06

Let's assume we go with this plan and configure percentage fees according to the results of the poll: [min: 1 BTS max: 20 BTS,  rate: 0.1%].
What would the flat transfer fee be in this case for BTS and other assets remaining on the flat scheme?

I thought we were going to start discussing the max/min values in terms of a stable currency, preferably USD since the actual network cost has been defined in terms of USD.

Also, why is it that we cannot apply the %-based fee to BTS?  If anything, shouldn't that be the easiest asset to apply %-based fee since we don't have to worry about the CER changing and causing the calculated/target minimum fee (in USD terms) to go below the actual minimum fee in BTS terms? 

[tbone]

OK, according to the voting, the parameters in USD can be 0.1%/$0.003/$0.06

Bytemaster said during the last Mumble session that the network cost we need to cover is $.005 - .01 per transaction.  If you want to go as low as possible, then the minimum fee should be $.005.   As for the maximum fee, $.06 sounds like a pretty reasonable FLAT fee.  But for a cap on a %-based fee, that seems WAY too low and likely won't increase usage but would lower the incentive for the referral program.  Personally, I think we can easily go up to the $.10-.25 range considering this is just a cap and the % is LOW.

[xeroc]

OK, according to the voting, the parameters in USD can be 0.1%/$0.003/$0.06

Let's assume we go with this plan and configure percentage fees according to the results of the poll: [min: 1 BTS max: 20 BTS,  rate: 0.1%].
What would the flat transfer fee be in this case for BTS and other assets remaining on the flat scheme?

whatever the committee decides for ..

[jakub]

OK, according to the voting, the parameters in USD can be 0.1%/$0.003/$0.06

Let's assume we go with this plan and configure percentage fees according to the results of the poll: [min: 1 BTS max: 20 BTS,  rate: 0.1%].
What would the flat transfer fee be in this case for BTS and other assets remaining on the flat scheme?

[xeroc]

I just now finish writing a a few scripts to let the committee work in USD
https://github.com/BitShares-Committee/Instructions/tree/master/usd-denominated-fees

[bitcrab]

OK, according to the voting, the parameters in USD can be 0.1%/$0.003/$0.06

[xeroc]

The discussion should be in USD (or CNY) and the committee's targets should be set in USD (or CNY).
The implementation should be in BTS (as all our fees are denominated in BTS) and the committee should make occasional adjustments to catch up with the exchange rate.

This is on my list of things to do .. I plan to write an easy to use script to
a) put a new proposal to update the fees
b) verify a proposal is within a tolerance (denominated in USD)

[jakub]

In light of that, let's provide a level of certainty.  To do so, we should simply debate and ultimately target upper and lower limits in terms of a stable currency (USD probably makes the most sense here), and then if BTS changes in value such that the limits (in terms of the stable currency) deviate from the targets by some percentage, say 10-20%, then the committee acts to update the BTS limits to reflect the stable target limits.

 
I agree with that.

The discussion should be in USD (or CNY) and the committee's targets should be set in USD (or CNY).
The implementation should be in BTS (as all our fees are denominated in BTS) and the committee should make occasional adjustments to catch up with the exchange rate.

[tbone]

Was away for a couple of days and just catching up...

In the interest of time, I agree it should be fine to go with a scheme where the committee must explicitly adjust the upper and lower limits as the value of BTS changes.  Although I think we do need to realize that it WILL matter to some business builders whether the min fee is .003 or .01 (more than 3X higher).  In light of that, let's provide a level of certainty.  To do so, we should simply debate and ultimately target upper and lower limits in terms of a stable currency (USD probably makes the most sense here), and then if BTS changes in value such that the limits (in terms of the stable currency) deviate from the targets by some percentage, say 10-20%, then the committee acts to update the BTS limits to reflect the stable target limits.  This may seem trivial to some, but it's not.

[kenCode]

I don't foresee this needing a lot of GUI work, a day at most (a day being 8 hours). As long as there's a flag on the asset that says what type of fee to use, and only transfers are affected, it should be trivial to add a switch to whichever transfer operation type that asset uses.

Fees need a little bit of work but not a whole lot, assuming the percent fee structure is easily available either in the asset object or in global parameters. We estimate fees using the global parameters and the operation type, so that would need to be extended to handle percent fees but that's not hard. And final operation fees are fetched from the witness node so that should not require any work on the GUI.

Great news!
 

54.8% is a large margin of agreement for a Bitshares proposal... one of the largest percentages I've seen.

Let's get moving on this. 

agreed. @abit what is the next step? get you voted in? trade your UIA?

These are the next steps:
(1) Create a worker proposal for BSIP#10 - I'll do that this coming week (something like Monday or Tuesday).
And after it is accepted:
(2) Complete the coding and perform initial testing - this area belongs to abit.
(3) Review the code - this will be done by CNX.
(4) Test the implementation on the testnet.
(5) Write the documentation - I'll try to do it with abit's help.
(6) Deploy the implementation with a planned hard-fork (unless hard-fork is not necessary, I'm not sure).

And when the above is complete, we will need to:
(a) pass a committee proposal to establish the min, max & percentage values.
(b) pass another committee proposal which will switch committee-owned smart-coins to percentage-based fee scheme.

So it's quite a long way.

Sounds like a very reasonable approach ..
One advice regarding implementation though: could it be built such that people can
a) easily choose/change the fee model for their asset
b) have an easy way of adding other fee modells as well from which issuers can choose?
c) please send a pull request to the bsip repo so that we can have it listed outside of 'issues'
d) drop me a line if you want the testnet upgraded i am looking forward zo figuring out how hard fork are actually done on a running network

[abit]

I don't foresee this needing a lot of GUI work, a day at most (a day being 8 hours). As long as there's a flag on the asset that says what type of fee to use, and only transfers are affected, it should be trivial to add a switch to whichever transfer operation type that asset uses.

Fees need a little bit of work but not a whole lot, assuming the percent fee structure is easily available either in the asset object or in global parameters. We estimate fees using the global parameters and the operation type, so that would need to be extended to handle percent fees but that's not hard. And final operation fees are fetched from the witness node so that should not require any work on the GUI.

Since it's a little off topic here, I posted a reply in my thread.

[svk]

I don't foresee this needing a lot of GUI work, a day at most (a day being 8 hours). As long as there's a flag on the asset that says what type of fee to use, and only transfers are affected, it should be trivial to add a switch to whichever transfer operation type that asset uses.

Fees need a little bit of work but not a whole lot, assuming the percent fee structure is easily available either in the asset object or in global parameters. We estimate fees using the global parameters and the operation type, so that would need to be extended to handle percent fees but that's not hard. And final operation fees are fetched from the witness node so that should not require any work on the GUI.

[abit]

These are the next steps:
(1) Create a worker proposal for BSIP#10 - I'll do that this coming week (something like Monday or Tuesday).
And after it is accepted:
(2) Complete the coding and perform initial testing - this area belongs to abit.
(3) Review the code - this will be done by CNX.
(4) Test the implementation on the testnet.
(5) Write the documentation - I'll try to do it with abit's help.
(6) Deploy the implementation with a planned hard-fork (unless hard-fork is not necessary, I'm not sure).

And when the above is complete, we will need to:
(a) pass a committee proposal to establish the min, max & percentage values.
(b) pass another committee proposal which will switch committee-owned smart-coins to percentage-based fee scheme.

So it's quite a long way.

Sounds like a very reasonable approach ..
One advice regarding implementation though: could it be built such that people can
a) easily choose/change the fee model for their asset

GUI development is not included in the steps above. Maybe svk would help? @svk do we need to add budget for GUI development into the worker proposal? If yes, how much?

b) have an easy way of adding other fee modells as well from which issuers can choose?

I assume that you mean GUI as well? More modes would need more development work at least on the witness_node level. If GUI calculates fees independently (but not by querying witness_node), we may need more development work on GUI side.

The feature "easy to extend in the future" hasn't been added into current implementation yet, I'll add it.

c) please send a pull request to the bsip repo so that we can have it listed outside of 'issues'
d) drop me a line if you want the testnet upgraded i am looking forward zo figuring out how hard fork are actually done on a running network