[BSIP] Percentage-based transfer fee solution based on CER

[jakub]

Micro transactions will require network fees even lower than 1 bts.

Please bear in mind that we need to preserve a reasonable threshold to prevent spam and 1 BTS might not be enough for this purpose.
 
3 BTS is something around $0.01. I don't think anybody cares about such an amount.
In my proposal I suggested 6 BTS as minimum, which translates into $0.02.
But let's not be distracted by debating fees - this will be decided by the committee anyway.

[kenCode]

Mass adoption..
Please guys keep in mind that Smartcoins POS will allow you to buy anything from that 60 cent pack of chewing gum to a Ferrari.

[kenCode]

My thoughts:
* committee should be able to set a global lower limit, E.G. 6 BTS
* committee should be able to set a global upper limit, E.G. 300 BTS
* committee should be able to set a global percentage, E.G. 1%
* issuer (or committee for BTS and committee issued smart coins) be able to set the per-asset fee mode, E.G. flat mode or percentage mode
* since issuer doesn't get any split of fees, to avoid harm to other parties, issuer has no permission to set per-asset based parameters

More flexible settings would be:
* issuer get some fee split (discussed below)
* issuer be able to set a per-asset lower limit
* * if it's lower than the global lower limit, issuer pay the difference from fee pool to network
* * if it's higher than the global lower limit, the difference pays to the issuer
* issuer be able to set the per-asset percentage
* * if it's higher than the global percentage, the difference pays to the issuer
* * if it's lower than the global percentage, issuer pay the difference from fee pool to network (not to the referral program, to avoid referrers earn quick money from issuers by self-transferring)
* issuer be able to set a per-asset upper limit
* * if it's higher than the global upper limit, the difference pays to the issuer
* * if it's lower than the global upper limit, issuer pay the difference to network (not to the referral program, to avoid referrers earn quick money from issuers by self-transferring)

In this way issuers are motivated, referrers may loss some if issuers set low percentage and/or low upper limit (while issuers also need to pay some in this case).

Exactly. My chewing gum example and mobile wallet screenshot are great examples of this. Micro transactions will require network fees even lower than 1 bts. Example 2: http://cryptofresh.com/b/2347475

[jakub]

My thoughts:
* committee should be able to set a global lower limit, E.G. 6 BTS
* committee should be able to set a global upper limit, E.G. 300 BTS
* committee should be able to set a global percentage, E.G. 1%
* issuer (or committee for BTS and committee issued smart coins) be able to set the per-asset fee mode, E.G. flat mode or percentage mode
* since issuer doesn't get any split of fees, to avoid harm to other parties, issuer has no permission to set per-asset based parameters

This is a correct summary of the concept proposed in the BSIP.

More flexible settings would be:
* issuer get some fee split (discussed below)
* issuer be able to set a per-asset lower limit
* * if it's lower than the global lower limit, issuer pay the difference from fee pool to network
* * if it's higher than the global lower limit, the difference pays to the issuer
* issuer be able to set the per-asset percentage
* * if it's higher than the global percentage, the difference pays to the issuer
* * if it's lower than the global percentage, issuer pay the difference from fee pool to network (not to the referral program, to avoid referrers earn quick money from issuers by self-transferring)
* issuer be able to set a per-asset upper limit
* * if it's higher than the global upper limit, the difference pays to the issuer
* * if it's lower than the global upper limit, issuer pay the difference to network (not to the referral program, to avoid referrers earn quick money from issuers by self-transferring)

In this way issuers are motivated, referrers may loss some if issuers set low percentage and/or low upper limit (while issuers also need to pay some in this case).

The above enhancements make sense to me.
My only concern is that they make the whole system much more complex from the issuer's point of view.
So to preserve simplicity I'd suggest to make the default settings simple, and to hide those additional parameters behind a check-box indicating more advanced options.

[abit]

My thoughts:
* committee should be able to set a global lower limit, E.G. 6 BTS
* committee should be able to set a global upper limit, E.G. 300 BTS
* committee should be able to set a global percentage, E.G. 1%
* issuer (or committee for BTS and committee issued smart coins) be able to set the per-asset fee mode, E.G. flat mode or percentage mode
* since issuer doesn't get any split of fees, to avoid harm to other parties, issuer has no permission to set per-asset based parameters

More flexible settings would be:
* issuer get some fee split (discussed below)
* issuer be able to set a per-asset lower limit
* * if it's lower than the global lower limit, issuer pay the difference from fee pool to network
* * if it's higher than the global lower limit, the difference pays to the issuer
* issuer be able to set the per-asset percentage
* * if it's higher than the global percentage, the difference pays to the issuer
* * if it's lower than the global percentage, issuer pay the difference from fee pool to network (not to the referral program, to avoid referrers earn quick money from issuers by self-transferring)
* issuer be able to set a per-asset upper limit
* * if it's higher than the global upper limit, the difference pays to the issuer
* * if it's lower than the global upper limit, issuer pay the difference to network (not to the referral program, to avoid referrers earn quick money from issuers by self-transferring)

In this way issuers are motivated, referrers may loss some if issuers set low percentage and/or low upper limit (while issuers also need to pay some in this case).

[jakub]

the whole structure is OK, the point is the value, I must keep sensitive to not allow the fee go up, if it cannot go down.
not only TCNY and TUSD are relevant to me, BTS and main BitAssets are all relevant to me.

As I stated before, personally I'd be fine with keeping BTS transfers flat and very low (e.g. 5 BTS) while having bit-assets on percentage-based fees.
I'm sure that gradually we can find some middle ground. I don't want to fight, I want to get things done and I guess you want that too.

Let's work together on percentage-based fees and once we have them, we can bring the discussion about the values to the committee as it belongs there.
This is just a politically neutral worker proposal aimed to give us more flexibility.

[bitcrab]

Anyway, before we declare 1% and 300 BTS as "really scary" we should do a basic statistical analysis (i.e. find out the mean value and its deviation) and thus estimate the economic impact of those values across different segments of our users.

maybe needed for another value, but not needed for 1% and 300 BTS, just as if someone sell IPhone 6 Plus to me with the price of 60K CNY, I can tell it scary without thinking.

But please do not drag this proposal into yet another transfer fee battle.
The whole point of this proposal is to make transfers below $5 viable while preserving the economic foundation of the referral program.
If you don't like it, you will be able to keep TCNY and TUSD out of it - this whole thing is optional for the issuer.

the whole structure is OK, the point is the value, I must keep sensitive to not allow the fee go up, if it cannot go down.
not only TCNY and TUSD are relevant to me, BTS and main BitAssets are all relevant to me.

[jakub]

You saying "definitely not acceptable" at this stage is definitely not helpful.

sorry for saying that, but 1% and 300 BTS is really scary, and it is not mentioned in the BSIP that the value is just an example.

It's clearly stated in the Assumptions section:

Values used in the description are just an initial proposal, the actual values will be determined be the committee.

Anyway, before we declare 1% and 300 BTS as "really scary" we should do a basic statistical analysis (i.e. find out the mean value and its deviation) and thus estimate the economic impact of those values across different segments of our users.

But please do not drag this proposal into yet another transfer fee battle.
The whole point of this proposal is to make transfers below $5 viable while preserving the economic foundation of the referral program.
If you don't like it, you will be able to keep TCNY and TUSD out of it - this whole thing is optional for the issuer.

[bitcrab]

You saying "definitely not acceptable" at this stage is definitely not helpful.

sorry for saying that, but 1% and 300 BTS is really scary, and it is not mentioned in the BSIP that the value is just an example.

[jakub]

if I am correct, the proposal can be summarized like this:

charge 1% of the transferred value. 6 BTS as minimum. 300 BTS as maximum.

From the user perspective, that's correct.

for a lot of users, this is raising their burden. definitely not acceptable.

my proposal:

charge 0.3% of the transferred value, at least 3 BTS, at most 30 BTS.
and the 3 parameters can be adjusted while necessary.

Let's separate the idea of this proposal from actual values applied in it.
Setting the exact values is a sensitive issue and it belongs to the committee.

Personally,  I don't treat this proposal as a way to lower the transfer fees. I think on average they should be more or less the same. My only intention is to restructure them.
You saying "definitely not acceptable" at this stage is definitely not helpful.

[bitcrab]

if I am correct, the proposal can be summarized like this:

charge 1% of the transfered value. 6 BTS as minimum. 300 BTS as maximum.

for a lot of users, this is raising their burden. definitely not acceptable.

my proposal:

charge 0.3% of the transfered value, at least 3 BTS, at most 30 BTS.
and the 3 parameters can be adjusted while necessary.


 

[CoinHoarder]

I thought percentage-based transfer fees were not possible because of stealth transfers?

But if we cannot do it for stealth, should this fact prevent us from having percentage-based fees on normal transfers?

This is what I was referring to. I thought that Stealth transfers prevented all other transfer fees from being percentage based, but maybe I am misunderstanding something. From your other thread..

In the last Mumble @bytemaster mentioned that percentage-based transfer fees are a complex subject, mainly because of these two reasons:
- it's hard to reliably determine the exact BTS value of an asset at any given point of time
- for stealth transfers the amount is not available

[jakub]

I thought percentage-based transfer fees were not possible because of stealth transfers?

Stealth transfers are indeed excluded, they need to remain on flat fees.
But if we cannot do it for stealth, should this fact prevent us from having percentage-based fees on normal transfers?

Also, percentage-based fees make the most sense for small amounts. And people doing stealth are not dealing with small amounts anyway.
So these are two different use-cases.

[onceuponatime]

I thought percentage-based transfer fees were not possible because of stealth transfers?

I expect that a very small percentage of transactions will be stealth.

[CoinHoarder]

I thought percentage-based transfer fees were not possible because of stealth transfers?

[fav]

did not have the time to read all of it yet but

hey will need to forgo the referral income on transfers below the equivalent of $2 but will substantially increase their income on transfers above the equivalent of $10. In the range between $2 and $10 they will get on average half of the income they have now. Nevertheless, the main benefit will be indirect: it's much easier to sell a reasonably priced product.

sounds okay to me, and more rational than any other attempt I read.

Go for it.

Note: https://bitsharestalk.org/index.php/topic,20653.0.html is my recap on the first 100 refs

edit: make it worth to upgrade to premium and the referral system will work regardless.

[abit]

Imo this feature need a bit more work than the "market fees of bit assets to referral program" proposal which BM proposed, so I estimate the price would be $10000-15000 (based on current feature requirement). If we need a 2-tier structure or spliting fees to asset issuers and/or FBA holders it would cost more.

[jakub]

Cooperate with CNX to figure out a fair price and if shareholders agree to fund the feature, you simply take the money and pay CNX through a contract similar to what onceuponatime did, just without all the FBA stuff ..

The thing is, we have not received any comment from CNX yet.
I look forward to that, not because I expect them to actually do the implementation but at the very least we need an estimate how complex this task is from the technical perspective.

[xeroc]

Looks like there are not many people have interest in this topic (to provide constructive comments), which is sad. But it's not too important, all we need are:
* fund (maybe from @jakub or @kenCode, we need this first to attract CNX or other developers)
* developer (maybe CNX, if not, maybe kenCode or Freebie people but better reviewed by CNX)
* set up a worker proposal (not hard to be done)
* votes for the worker proposal (if CNX agrees to develop, this is not a problem, otherwise this would be harder)
* votes for the witnesses who are willing to install the hard-fork once implemented (same to last one)

I still have these concerns:
* Need more incentives for people who want to fund this feature
* Need more incentives for issuers to discuss/enable this feature
* Need more flexibility for issuers to adjust the asset-based parameters
* Need more incentives for developers to implement
* Need more incentives for proxies/stake-holders to vote

How about you estimate the costs to implement and test this feature properly, add a 30% margin and ask the shareholders to fund the proposal through a worker.
Cooperate with CNX to figure out a fair price and if shareholders agree to fund the feature, you simply take the money and pay CNX through a contract similar to what onceuponatime did, just without all the FBA stuff ..
Sure, it involves trust, since you could easily run with the money asked for through a worker proposal .. maybe have it vested over 6 months or split it into milestones to reduce the risk for shareholders. I would definitely support the development of this feature as long as it is opt-in for asset-issuers

[kenCode]

Looks like there are not many people have interest in this topic (to provide constructive comments), which is sad. But it's not too important, all we need are:
* fund (maybe from @jakub or @kenCode, we need this first to attract CNX or other developers)
* developer (maybe CNX, if not, maybe kenCode or Freebie people but better reviewed by CNX)
* set up a worker proposal (not hard to be done)
* votes for the worker proposal (if CNX agrees to develop, this is not a problem, otherwise this would be harder)
* votes for the witnesses who are willing to install the hard-fork once implemented (same to last one)

I still have these concerns:
* Need more incentives for people who want to fund this feature
* Need more incentives for issuers to discuss/enable this feature
* Need more flexibility for issuers to adjust the asset-based parameters
* Need more incentives for developers to implement
* Need more incentives for proxies/stake-holders to vote

 
@bytemaster Our fees for micro transactions NEED to be % based ASAP PLEEEEZE. For example, the voluntary 2BTS donation in the mobile wallets ends up charging you DOUBLE network fees. 32BTS to send the money to someone and another 32BTS to send us the 2BTS donation. We NEED those donations to further the wallet development, provide customer support in the forum and app stores and provide regular updates, etc. The fee on a 2BTS send should only be like 0.002 BTS.
 
What if my daughter wants to buy just a pack of gum at the POS? She would have to pay the 60 cents for the gum PLUS another 20 cents for the fee PLUS another 20 cents if she wanted to donate 2BTS to the developers here? That's some expensive gum!!! see the checkbox:
 

[abit]

Looks like there are not many people have interest in this topic (to provide constructive comments), which is sad. But it's not too important, all we need are:
* fund (maybe from @jakub or @kenCode, we need this first to attract CNX or other developers)
* developer (maybe CNX, if not, maybe kenCode or Freebie people but better reviewed by CNX)
* set up a worker proposal (not hard to be done)
* votes for the worker proposal (if CNX agrees to develop, this is not a problem, otherwise this would be harder)
* votes for the witnesses who are willing to install the hard-fork once implemented (same to last one)

I still have these concerns:
* Need more incentives for people who want to fund this feature
* Need more incentives for issuers to discuss/enable this feature
* Need more flexibility for issuers to adjust the asset-based parameters
* Need more incentives for developers to implement
* Need more incentives for proxies/stake-holders to vote

[fuzzy]

Agreed. This is badly needed.
If I want to send someone a 2 BTS donation or tip, I have to pay like 32BTS or so in fees just to send it. That must be fixed ASAP.
 
@jakub - GREAT proposal thank you!
@xeroc - Thank you for your work on the draft and docs
@fuzzy - Can we please bring this up in the mumble today with BM?
@EstefanTT - I will definitely vote for this too

definitely anning on covering this. 

[jakub]

Agreed. This is badly needed.
If I want to send someone a 2 BTS donation or tip, I have to pay like 32BTS or so in fees just to send it. That must be fixed ASAP.
 
@jakub - GREAT proposal thank you!
@xeroc - Thank you for your work on the draft and docs
@fuzzy - Can we please bring this up in the mumble today with BM?
@EstefanTT - I will definitely vote for this too

And still waiting for feedback from @ccedk and @fav - these are our most efficient referrers and this proposal affect mostly referrers.

[kenCode]

Agreed. This is badly needed.
If I want to send someone a 2 BTS donation or tip, I have to pay like 32BTS or so in fees just to send it. That must be fixed ASAP.
 
@jakub - GREAT proposal thank you!
@xeroc - Thank you for your work on the draft and docs
@fuzzy - Can we please bring this up in the mumble today with BM?
@EstefanTT - I will definitely vote for this too

[EstefanTT]

That's an interesting solution, I would definitely vote for it.

This thread needs more attention!

[xeroc]

Running for a BSIP is much appreciated. i'll review it and publish the draft asap

[jakub]

As a referral business myself, I find percentage-based transfer fees very valuable.

People who are new to BitShares are not going to trust it with any significant amounts of money.
Initially they will want to play with it by putting a couple of euros or dollars into the system.
And this is exactly the range where we utterly fail in terms of transfer fees.
I cannot think of any other existing payment system that asks you to pay a 10% fee for a $1 payment.

[jakub]

Following an initial discussion in this thread, I'd like to propose a percentage-based transfer fee solution, in which the BTS value of a transfer is derived from Core Exchange Rate (CER).

The main goal is to make BitShares competitive for transfers below the equivalent of $5 while keeping the referral program unharmed (or even strengthened).

For more details, please refer to my initial draft for a BSIP:
https://github.com/bitshares/bsips/issues/3

Being voluntary for issuers, the above proposal is actually targeted to the referral businesses: do they perceive it as a beneficial change for the ecosystem and a fair deal for them?