[Worker Proposal] Percentage-based transfer fees

[alt]

@alt , is there any particular reason your proxy (baozi) is actively voting against this proposal?

I don't know why we need this function,
it  make system more complex and uncertainty.
and we don't have enough money to pay for these unemergency works
and I against all dilution workers before we have a strict rule and budget plan

I believe when we dilution 1 USD value BTS, the share holders will lose more than 10 USD.

How so?

Do you think the committee would use their accumulated fee income to pay for workers instead?
I welcome your approach and am willing to be payed by other means as long as can fill my fridge

from the experience of a  common stock trade market, there are about 5%  shares active in the trade,
so if there are 1m USD available in the market trade for BTS, there are about 20m USD market cap for BTS.

for most workers, they sold  all BTS got from the payment at current price, and take away these money from market.
if they sold 10k USD, the market cap reduce 10k*20 = 200K USD
and these will caused more desperate money leave BTS at such a low price.

If I am the owner of a componey which stock is very low,
I should try to buy back as more stock as I can, not sold out, not dilution
If I don't have any money to buy back, at least I don't dilution
If I really need dilution some stock to pay for development, I only pay for the development I have to do.
If I  dilution any stock to pay for any development as I like, I guess other share holders want to killing me, more and more people will leave.

[jakub]

@alt , is there any particular reason your proxy (baozi) is actively voting against this proposal?

[kenCode]

@tbone , following your suggestion, I've made a pull request for the BSIP to include the fiat-stability issue that you've raised.
https://github.com/bitshares/bsips/pull/10
Thank you for the feedback.

Indeed!

[jakub]

Considering that your proposal includes a section entitled "rationale", one would think you'd discuss what limits you'd be targeting and how.  But you did not even touch the subject.  Even your post that introduced and linked the proposal said nothing of targeting stable limits.  I appreciate all of your efforts, but I'm sure you can see why I was so surprised.

Stable limits are simply not subject of this proposal. We just took on the task of introducing the percentage-based fees mechanism itself.
If I understand you correctly, you imply that this proposal is incomplete without the mechanism to keep the limits stable.

As far as I know, @xeroc is actively working on just that: an automated way to keep all fees synced to fiat-defined targets.
So if we combine our proposal with xeroc's project, we should end up with a complete, fiat-stable solution.

My problem is not that the mechanism was not included in the proposal.  I was just surprised you didn't mention in the proposal itself (or in your post introducing it) that the idea is to combine the proposal with some external mechanism intended to target stable fee limits.  Anyway, I'm glad to hear this is something that is being taken seriously.

@tbone , following your suggestion, I've made a pull request for the BSIP to include the fiat-stability issue that you've raised.
https://github.com/bitshares/bsips/pull/10

Thank you for the feedback.

[tbone]

Considering that your proposal includes a section entitled "rationale", one would think you'd discuss what limits you'd be targeting and how.  But you did not even touch the subject.  Even your post that introduced and linked the proposal said nothing of targeting stable limits.  I appreciate all of your efforts, but I'm sure you can see why I was so surprised.

Stable limits are simply not subject of this proposal. We just took on the task of introducing the percentage-based fees mechanism itself.
If I understand you correctly, you imply that this proposal is incomplete without the mechanism to keep the limits stable.

As far as I know, @xeroc is actively working on just that: an automated way to keep all fees synced to fiat-defined targets.
So if we combine our proposal with xeroc's project, we should end up with a complete, fiat-stable solution.

My problem is not that the mechanism was not included in the proposal.  I was just surprised you didn't mention in the proposal itself (or in your post introducing it) that the idea is to combine the proposal with some external mechanism intended to target stable fee limits.  Anyway, I'm glad to hear this is something that is being taken seriously. 

[kuro112]

this is the first proposals that i agree with the idea, cost, and method of implementation,

other people looking to do proposals should use this as a guideline to a realistic cost/benefit ratio.

hope it all works out, you have my vote.

 

[xeroc]

As far as I know, @xeroc is actively working on just that: an automated way to keep all fees synced to fiat-defined targets.
So if we combine our proposal with xeroc's project, we should end up with a complete, fiat-stable solution.

Those scripts do already exists and the committee is trying to figure out which fees to actually set.
A "complete" fiat peg may not be as easy but may have slight variance due to the facts that
a) BTS is volatile against USD
b) the committee proposal have a review period of currently 1h (and hopefully LONGER eventually to show some stability)

[jakub]

Considering that your proposal includes a section entitled "rationale", one would think you'd discuss what limits you'd be targeting and how.  But you did not even touch the subject.  Even your post that introduced and linked the proposal said nothing of targeting stable limits.  I appreciate all of your efforts, but I'm sure you can see why I was so surprised.

Stable limits are simply not subject of this proposal. We just took on the task of introducing the percentage-based fees mechanism itself.
If I understand you correctly, you imply that this proposal is incomplete without the mechanism to keep the limits stable.

As far as I know, @xeroc is actively working on just that: an automated way to keep all fees synced to fiat-defined targets.
So if we combine our proposal with xeroc's project, we should end up with a complete, fiat-stable solution.

[xeroc]

Considering that your proposal includes a section entitled "rationale", one would think you'd discuss what limits you'd be targeting and how.  But you did not even touch the subject.  Even your post that introduced and linked the proposal said nothing of targeting stable limits.  I appreciate all of your efforts, but I'm sure you can see why I was so surprised.

He made very clear in the bsip that they will solely provide the infrastructure to make those decisions and that the committee will have to decide on those numbers.

[tbone]

No, I believe the 6BTS floor is the mandatory minimum that must be paid to the network, anything above that would be split between the network and referrers.  I hope I'm missing something, otherwise this is just idiotic and will put me right near my wit's end with all of this.

6 go to the network .. everything above 6 goes to referral program

Yes, that's exactly what I said already -- the minimum to the network is 6BTS.  But the point is, what does 6BTS mean to users or to a business?  Today it means about $.02.  In a few months it could mean $.20.  How can a business build around that?  One of the rationales of this proposal is to preserve the referral program.  Yet the referrers now have much more uncertainty.  In fact, based on today's BTS value in USD, if this proposal goes through, a $200 transfer with a .1% fee would generate the equivalent of a $.20 fee, or about 60BTS.  The network would keep 6BTS plus 20% of the remaining 14BTS, leaving the other 80% of the 14BTS for the referrer. 

Now let's say, just as an example, the value of BTS goes up 10X in the coming months.  Now that same transaction fee of .20 would be the equivalent of 6BTS, so the network would take 100% and the referrer would get nothing.  So much for protecting the referral program. 

Not to mention, if the value of BTS goes up any further than that, the actual rate to the user would go up.  Or for a business built atop Bitshares, their costs would be higher due to the increased fees, potentially making their model non-viable.   

Again, unless I'm missing something, I have to say WTF are we doing here?!

@tbone
Please note that the values used in the BSIP are just an example. So those values are not really part of the proposal. I needed them just to illustrate how the mechanism would work. Maybe I could have used symbolic letters instead of numbers to avoid this confusion.

We only create a tool, it's the committee who sets the values for the parameters.

But I guess your main point is that the values are expressed in BTS, not fiat. Well, that's a problem that refers to all fees, not just those related to our proposal.

If I remember correctly, in the blockchain settings we have a tool that addresses this - I think it's called multiplier or something similar.
It enables the committee to automatically adjust all fees by a given factor and this way keep the fees in sync with BTS value.

Considering that your proposal includes a section entitled "rationale", one would think you'd discuss what limits you'd be targeting and how.  But you did not even touch the subject.  Even your post that introduced and linked the proposal said nothing of targeting stable limits.  I appreciate all of your efforts, but I'm sure you can see why I was so surprised.

[jakub]

Our total budget is 4.4m BTS, with the following split:

We appreciate your votes for 1.14.29!

Excellent work!

Minor nit: the proposal is for 50k per day for 90 days which is 4.5m BTS not 4.4m?

Thank you, pc.

You're right. There is a slight mismatch in this respect. It was not intended.

However, we will not take more payment than declared (the multi-sig account controlled by the committee will not allow us to) and any excess (including any excess from the testing budget) will be burned or returned to the pool - whatever the committee decides.

[pc]

Our total budget is 4.4m BTS, with the following split:

We appreciate your votes for 1.14.29!

Excellent work!

Minor nit: the proposal is for 50k per day for 90 days which is 4.5m BTS not 4.4m?

[abit]

If I remember correctly, in the blockchain settings we have a tool that addresses this - I think it's called multiplier or something similar.
It enables the committee to automatically adjust all fees by a given factor and this way keep the fees in sync with BTS value.

It's called "scale", which is currently set to "1x".
There was a bug related to it.
I may need to check my code again to ensure I handled it properly.

[jakub]

No, I believe the 6BTS floor is the mandatory minimum that must be paid to the network, anything above that would be split between the network and referrers.  I hope I'm missing something, otherwise this is just idiotic and will put me right near my wit's end with all of this.

6 go to the network .. everything above 6 goes to referral program

Yes, that's exactly what I said already -- the minimum to the network is 6BTS.  But the point is, what does 6BTS mean to users or to a business?  Today it means about $.02.  In a few months it could mean $.20.  How can a business build around that?  One of the rationales of this proposal is to preserve the referral program.  Yet the referrers now have much more uncertainty.  In fact, based on today's BTS value in USD, if this proposal goes through, a $200 transfer with a .1% fee would generate the equivalent of a $.20 fee, or about 60BTS.  The network would keep 6BTS plus 20% of the remaining 14BTS, leaving the other 80% of the 14BTS for the referrer. 

Now let's say, just as an example, the value of BTS goes up 10X in the coming months.  Now that same transaction fee of .20 would be the equivalent of 6BTS, so the network would take 100% and the referrer would get nothing.  So much for protecting the referral program. 

Not to mention, if the value of BTS goes up any further than that, the actual rate to the user would go up.  Or for a business built atop Bitshares, their costs would be higher due to the increased fees, potentially making their model non-viable.   

Again, unless I'm missing something, I have to say WTF are we doing here?!

@tbone
Please note that the values used in the BSIP are just an example. So those values are not really part of the proposal. I needed them just to illustrate how the mechanism would work. Maybe I could have used symbolic letters instead of numbers to avoid this confusion.

We only create a tool, it's the committee who sets the values for the parameters.

But I guess your main point is that the values are expressed in BTS, not fiat. Well, that's a problem that refers to all fees, not just those related to our proposal.

If I remember correctly, in the blockchain settings we have a tool that addresses this - I think it's called multiplier or something similar.
It enables the committee to automatically adjust all fees by a given factor and this way keep the fees in sync with BTS value.

[abit]

Can the the flat/percentage be dynamic? What I mean is the system checks to see which fee is cheapest in terms of a default reference fiat (USD,CNY,EUR).  So in addition to setting the flat fee and percent, the issue er can also set a parameter like "if flat fee) > X in fiat terms then use percentage fee. Maybe even charge the issue er a fee for extra resources to compute the fee if they choose this option.

Good idea. Thanks.
Perhaps this would be an option in the future, but won't be in this proposal.