Percentage based transfer fee [BSIP10] implemented

[cube]

The 3M BTS I proposed is for "my work", which includes coding of "witness_node" and "cli_wallet", as well as "my" testing in one or more private networks and/or public networks.
...

Could you please include 'documentation for developer' into your proposal?  This is much needed if we need another developer to take over and maintain or expand the developed codes.

[abit]

However it's not perfect, we have to manually set core_exchange_rate in the proposal. During the proposal voting and review period, actual core_exchange_rate of proposed smart coin may have changed. When the proposal executes, core_exchange_rate in the proposal will take effect, and it's probably inaccurate.

@abit , could you expand on this?
When you say "we have to manually set core_exchange_rate in the proposal" what proposal do you mean?

To change the transfer_fee_mode of a committee-member owned asset(BitUSD and etc), we need to propose a committee proposal, and committee members vote on it. A valid core_exchange_rate is required in the proposal. That's it.

Is the committee supposed to be individually involved in every asset being under the percentage-based fees?

Yes

I'm not sure I understand the intended workflow.

[abit]

Probably I'll try to be funded this way:
* Apply one worker or more for a budget of 330M BTS
* Among it, 180M BTS will vest immediately, which will be used to borrow 1000 TUSD with 6x collateral, then be paid to CNX  through @bitcrab's gateway, for code review.
* The other 150M BTS will vest over one year.

Any idea? Thanks!

330M BTS?  Do you mean 3.3M?

Sorry man, my fault. Will update it.

[jakub]

However it's not perfect, we have to manually set core_exchange_rate in the proposal. During the proposal voting and review period, actual core_exchange_rate of proposed smart coin may have changed. When the proposal executes, core_exchange_rate in the proposal will take effect, and it's probably inaccurate.

@abit , could you expand on this?
When you say "we have to manually set core_exchange_rate in the proposal" what proposal do you mean?
Is the committee supposed to be individually involved in every asset being under the percentage-based fees?
I'm not sure I understand the intended workflow.

[tbone]

Probably I'll try to be funded this way:
* Apply one worker or more for a budget of 330M BTS
* Among it, 180M BTS will vest immediately, which will be used to borrow 1000 TUSD with 6x collateral, then be paid to CNX  through @bitcrab's gateway, for code review.
* The other 150M BTS will vest over one year.

Any idea? Thanks!

330M BTS?  Do you mean 3.3M?

[abit]

Probably I'll try to be funded this way:
* Apply one worker or more for a budget of 3.3M BTS
* Among it, 1.8M BTS will vest immediately, which will be used to borrow 1000 TUSD with 6x collateral, then be paid to CNX  through @bitcrab's gateway, for code review.
* The other 1.5M BTS will vest over one year.

Any idea? Thanks!

[abit]

To whom it may concern:
It's unable to apply percentage based fee mode to BTS with my implementation. To get this feature, perhaps we need a new API. I'll dive deeper into the code..

I confirm that percentage based fee mode can be applied to smart-coins via committee proposals. Tested.

However it's not perfect, we have to manually set core_exchange_rate in the proposal. During the proposal voting and review period, actual core_exchange_rate of proposed smart coin may have changed. When the proposal executes, core_exchange_rate in the proposal will take effect, and it's probably inaccurate.

I wonder if it's possible to set core_exchange_rate as an optional change for update_asset operation.

[abit]

Since BSIP#10 is currently a "draft", which means it hasn't been accepted by stake holders, I'd rather setup my worker later. @jakub would you like to setup a voting worker for BSIP#10 first, so that we can know whether the stake holders want this feature?

@abit , I'll be glad to add a voting worker for BSIP#10 - it will take 1-2 days because I need to educate myself how to create a worker proposal. It's good we have the testnet now so I'll have some space to practice.

Thanks for the help 

Also, those two aspects are not clear to me:

(1) Do we all agree that percentage-based fees can rely safely on CER? This is the core concept of BSIP#10 and there hasn't been much discussion about it.
The whole thing relies on the fact that issuers will not have an incentive to game the system by setting CER far below the actual market value of their assets.

Issuers can do this, and they have rights to do so. Personally I don't see anything bad from this point.

(2) You've proposed 3M BTS for the development work.
Does it include the whole thing, i.e. coding, testing , reviewing the code by CNX and UI support in the GUI?

The 3M BTS I proposed is for "my work", which includes coding of "witness_node" and "cli_wallet", as well as "my" testing in one or more private networks and/or public networks. It doesn't include (possibly needed) payment for work done by other parties. Any other parties have the rights of asking for pay for doing some additional work, including but not limited to code review,  code merge, discussion, write feature specification documents, write tutorial documents, write GUI code, setup public network, help testing, escrow and etc, which are out of my control, and currently no consensus has been reached yet. I'm definitely willing to help reach a consensus, although I'm not good at doing it.

So I'd rather like to see a poll for "features" first. After reached a consensus, we can go on and start another poll for "price" and/or "payment". Maybe I made things too complicated though.

Can we arrive at a "final" proposal for BSIP#10 before doing any kind of worker and voting stuff?

I don't think the current settings are really the best for the network. There is too much focus on referral at the expenses of the net.
IMO the net should come first as I already stated.

I also would prefer to see this:
"the minimum fee always goes to network, and if 20% of a fee exceeds lower limit, 20:80 scheme can be applied"

I don't see why if the 20% fee cut for the net is higher than lower_limit, the net should only take lower_limit and not his actual cut of 20%.

I also would prefer to see the network take no less than the lower_limit if his 20% cut is not enough. IMO it should *at least* take the lower_limit also at the expenses of the referrer if needed.
At the end of the day the network handle the transactions and "pay" for them, so it should be the first to get a cut...

If ppl do not like the fact that the net comes first, at least we should allow the net to get is 20% cut also when it is higher than the lower_limit.

The network won't loss any if parameters are finely tuned. Bottom line, if with flat mode network get 6BTS, with percentage mode network can also get 6BTS by setting the lower limit to 6BTS.
Sorry for discussing the features here.

[Bhuz]

Can we arrive at a "final" proposal for BSIP#10 before doing any kind of worker and voting stuff?

I don't think the current settings are really the best for the network. There is too much focus on referral at the expenses of the net.
IMO the net should come first as I already stated.

I also would prefer to see this:
"the minimum fee always goes to network, and if 20% of a fee exceeds lower limit, 20:80 scheme can be applied"

I don't see why if the 20% fee cut for the net is higher than lower_limit, the net should only take lower_limit and not his actual cut of 20%.

I also would prefer to see the network take no less than the lower_limit if his 20% cut is not enough. IMO it should *at least* take the lower_limit also at the expenses of the referrer if needed.
At the end of the day the network handle the transactions and "pay" for them, so it should be the first to get a cut...

If ppl do not like the fact that the net comes first, at least we should allow the net to get is 20% cut also when it is higher than the lower_limit.

[jakub]

Since BSIP#10 is currently a "draft", which means it hasn't been accepted by stake holders, I'd rather setup my worker later. @jakub would you like to setup a voting worker for BSIP#10 first, so that we can know whether the stake holders want this feature?

@abit , I'll be glad to add a voting worker for BSIP#10 - it will take 1-2 days because I need to educate myself how to create a worker proposal. It's good we have the testnet now so I'll have some space to practice.

Also, those two aspects are not clear to me:

(1) Do we all agree that percentage-based fees can rely safely on CER? This is the core concept of BSIP#10 and there hasn't been much discussion about it.
The whole thing relies on the fact that issuers will not have an incentive to game the system by setting CER far below the actual market value of their assets.

(2) You've proposed 3M BTS for the development work.
Does it include the whole thing, i.e. coding, testing , reviewing the code by CNX and UI support in the GUI?

[abit]

nice...wouldn't a worker proposal do?  Also, would this work be to hold the funds or would it be to sell them?  Would it be possible to hold at least some of them or vest some of them?

Thanks.

Worker proposal would be an option. If funding this way, for me it's acceptable to vest ~80% of them for one year or so, personally I would like to hold. Better if the vesting fund can vote, I'm not sure. However, if need to pay others, for example pay CNX for code review and/or someone for escrow, that part may need to be vested already.

Since BSIP#10 is currently a "draft", which means it hasn't been accepted by stake holders, I'd rather setup my worker later. @jakub would you like to setup a voting worker for BSIP#10 first, so that we can know whether the stake holders want this feature?

Another funding option would be FBA or something similar. For example, with each transfer, 1 BTS of fee paid to FBA holders or so.

Thoughts?

[fuzzy]

nice...wouldn't a worker proposal do?  Also, would this work be to hold the funds or would it be to sell them?  Would it be possible to hold at least some of them or vest some of them?

[abit]

Primary rules for BitShares operations include:

1. All values relevant to the display of the transaction history should be included in the operation.  Namely, the fee must be calculated in advance and explicitly included in the transaction.
2. Existing operations should not be changed if this requires adding additional fields.
3. As long as the FEE * CORE_EXCHANGE_RATE > MIN_NETWORK_FEE_IN_BTS then things should be fine.

The MIN fee is important to prevent spamming of UIAs that have no value.

Thanks for reply. If I understood correctly, my implementation obeys the rules above. @bytemaster have you got my email? More details there.

For anyone who have questions about the feature specifications but not the implementation, please discuss on Github https://github.com/bitshares/bsips/issues/3 or in the BSIP discussion thread https://bitsharestalk.org/index.php/topic,20789.0.html

And again, great thanks for all the supports in this thread!

[Bhuz]

Great job!

Everything seems good to me but the fee distribution scheme can be debatable. Why you didn't choose the existing scheme? (20% network 80% referral) Alternatively, the minimum fee always goes to network, and if 20% of a fee exceeds lower limit, 20:80 scheme can be applied, IMO.

I also would prefer to see this:
"the minimum fee always goes to network, and if 20% of a fee exceeds lower limit, 20:80 scheme can be applied"

I don't see why if the 20% fee cut for the net is higher than lower_limit, the net should only take lower_limit and not his actual cut of 20%.

I also would prefer to see the network take no less than the lower_limit if his 20% cut is not enough. IMO it should *at least* take the lower_limit also at the expenses of the referrer if needed.

At the end of the day the network handle the transactions and "pay" for them, so it should be the first to get a cut...

If ppl do not like the fact that the net comes first, at least we should allow the net to get is 20%cut also when it is higher than the lowe_limit.


Anyway, great job abit! 

[CryptoPrometheus]

This is a historical moment - it's a first attempt to implement a new feature in the Graphene code-base without CNX being directly involved.
Well done @abit

Let's hope CNX will be supportive and offer some feedback regarding the quality of abit's code.
Even if they don't find BSIP10 especially useful.

The baby is learning to walk

I agree - this is a first - and I am very happy to see it!

Furthermore, I think we should pay his asking price,  if only to send a positive signal to others who might be watching and wondering if we are a bunch of tightwads.