BitShares Forum
Main => General Discussion => Topic started by: abit on January 19, 2016, 11:01:53 am
-
[DECLARATION]
The work for this implementation is not free. In order to have it applied on the live BitShares network, it needs to be funded in some way. Suggestions on how to fund it are appreciated. I ask for 10K$, or 3M BTS. Fair negotiations are acceptable.
[MAIN]
Here is the BSIP document: https://github.com/bitshares/bsips/issues/3 https://github.com/bitshares/bsips/blob/master/bsip-0010.md
Feature briefs:
1. Added 3 global parameters which can be adjusted by the committee
* the percentage
* a per-transfer upper limit
* a per-transfer lower limit
2. For each asset, the issuer can choose between flat fee mode and percentage based fee mode
3. Changed fee split schema between network and referral program: if the asset is in percentage based fee mode, the network gets an amount equals to the lower limit, referral program gets the rest.
4. Fee calculation is based on "core_exchange_rate" of the asset:
fee = min(max(amount * CER * percentage, lower_limit), upper_limit)
Here is source code: https://github.com/abitmore/bitshares-2/tree/test-transfer-fee https://github.com/abitmore/bitshares-2/tree/dev-transfer-fee
Future developments are planned. Schedule depends on funds.
[EXAMPLES]
Here listed some sample commands:
* To set an asset to charge percentage based transfer fees:
update_asset MYASSET null {"max_supply": "1000000000000000","market_fee_percent": 0,"max_market_fee": "1000000000000000","issuer_permissions": 79,"flags": 0,"core_exchange_rate": { "base": { "amount": 100000, "asset_id": "1.3.0" }, "quote": { "amount": 10000, "asset_id": "1.3.1" }},"whitelist_authorities": [],"blacklist_authorities": [],"whitelist_markets": [],"blacklist_markets": [],"description": "","extensions": [[1,{"transfer_fee_mode":"asset_transfer_fee_mode_percentage_simple"}]] } true
* To set an asset to charge flat transfer fees:
update_asset MYASSET null {"max_supply": "1000000000000000","market_fee_percent": 0,"max_market_fee": "1000000000000000","issuer_permissions": 79,"flags": 0,"core_exchange_rate": { "base": { "amount": 100000, "asset_id": "1.3.0" }, "quote": { "amount": 10000, "asset_id": "1.3.1" }},"whitelist_authorities": [],"blacklist_authorities": [],"whitelist_markets": [],"blacklist_markets": [],"description": "","extensions": [[1,{"transfer_fee_mode":"asset_transfer_fee_mode_flat"}]] } true
* To change global percentage fee parameters:
...
,[
45,{
"flat_fee": 2000000,
"price_per_kbyte": 1000000,
"percentage_min_fee": 600000,
"percentage_max_fee": 30000000,
"percentage": 100,
"extensions": []
}
]
...
Explanation of above parameters:
* 45 is for a new operation "transfer_v2_operation". The original "transfer_operation" is incompatible
* flat_fee: 2000000 means 20 BTS of transfer fee for assets which selected flat transfer fee mode
* price_per_kbyte: no explanation
* percentage_min_fee: 600000 means 6 BTS of minimum transfer fee for assets which selected percentage fee mode
* percentage_max_fee: 3000000 means 300 BTS
* percentage: 100 means 1%
* extensions: a field for future extensions, leave it empty right now
[API CHANGES]
* added a new database API: get_operation_fee, which will simply return minimum required fee for a given operation, and won't recursively calculate if the operation is a proposal (not like get_required_fees API)
* fee_schedule::set_fee() function is no longer compatible with transfer_operation, a new function set_fee_extended() is introduced. However, the new function is not designed to be used in client applications, it's recommended to use the new get_operation_fee API to get required fee, then set the fee to the operation.
[IMPACTS TO THIRD-PARTY APPLICATIONS]
If a 3rd-party application (for example apps of exchanges, bridges and etc) is monitoring activities of an account, when a transaction which contains transfer_v2_operation(id=45) arrives, it should be treated as same as transfer_operation(id=0).
(3rd-party applications should detect/handle "transfer_v2_operation" too if they detect/handle "transfer_operation".)
[KNOWN ISSUES/LIMITATIONS]
* Unable to apply percentage base fee mode to BTS
[MISC]
Due to lack of feedback from CNX, I don't know if it's the best way to implement BSIP10.
//Update:
2016-01-21 Got in touch with CNX. No much feedback so far.
2016-01-25 Add extensions to fee parameter
2016-01-26 Made some changes on asset_update_operation: new_options can now have no CER or have an empty CER, in this case CER of asset_to_update won't change. Examples:
update_asset MYASSET null {"max_supply": "1000000000000000","market_fee_percent": 0,"max_market_fee": "1000000000000000","issuer_permissions": 79,"flags": 0,"whitelist_authorities": [],"blacklist_authorities": [],"whitelist_markets": [],"blacklist_markets": [],"description": "","extensions": [[1,{"transfer_fee_mode":"asset_transfer_fee_mode_percentage_simple"}]] } true
or
update_asset MYASSET null {"max_supply": "1000000000000000","market_fee_percent": 0,"max_market_fee": "1000000000000000","issuer_permissions": 79,"flags": 0,"core_exchange_rate":{},"whitelist_authorities": [],"blacklist_authorities": [],"whitelist_markets": [],"blacklist_markets": [],"description": "","extensions": [[1,{"transfer_fee_mode":"asset_transfer_fee_mode_percentage_simple"}]] } true
2016-02-12 Implemented a new operation, so the committee can change some options of the core asset (BTS), including:
* percentage market fee / market fee cap
* transfer fee mode
Example:
add_operation_to_builder_transaction 0 [46,{"fee":{"amount":50000000,"asset_id":"1.3.0"},"new_options":{"max_supply":"100000","market_fee_percent":10,"max_market_fee":"1000000000000000","issuer_permissions":0,"flags":0,"core_exchange_rate":{},"extensions":[[1,{"transfer_fee_mode":"asset_transfer_fee_mode_percentage_simple"}]]}}]
2016-03-01
* Code is re-branched to be based on develop branch, operation_ids changed.
* Code is deeply refactored, parameter names of fee schedule changed.
* Links in this post updated.
* Added "API changes" section in this post
* Added "impacts to 3rd-party applicaitons" section in this post
-
+5%
Since I just recently started a public Testnet, we can have it tested there if you wish ..
//edit:
instead of replacing the transfer operation, could we have a flag in each asset that let's the issuer chose which pricing model to use?
-
+5%
Since I just recently started a public Testnet, we can have it tested there if you wish ..
Thanks. But that's depends on you to whether deploy the code the test network.
//edit:
instead of replacing the transfer operation, could we have a flag in each asset that let's the issuer chose which pricing model to use?
It's included in the BSIP.
//Edit:
Due to lack of feedback from CNX, I don't know if it's the best way to implement BSIP10.
A simple modification on transfer_operation has been tried but failed, due to unable to re-index current live chain, it get blocked at a global_fee_change_operation or so. So I end up introduced a new operation transfer_v2_operation.
Maybe it's needed to modify GUI code to adapt the new operation, at least it's needed for CLI wallet (which I have done).
-
Updated OP to include some examples.
-
you will certainly need to change some code in the GUI as well .. it has an estimate_fee method somewhere ..
-
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 :)
-
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 :)
Yes... This is excellent @abit... well done!
-
Yeah.. this actually came out of discussions within the Committee regarding trading fees.
@abit is up for Vote to be on the Committee.
He has shown strong interest in getting things done and as many of you like, has the technical background as a developer.
If you haven't voted for him for committee please consider updating your votes.
He is also a Witness and currently holds the record for lowest missed blocks some how.
-
Yeah.. this actually came out of discussions within the Committee regarding trading fees.
@abit is up for Vote to be on the Committee.
He has shown strong interest in getting things done and as many of you like, has the technical background as a developer.
If you haven't voted for him for committee please consider updating your votes.
He is also a Witness and currently holds the record for lowest missed blocks some how.
Thanks.
By the way I added feature briefs to OP.
-
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.
-
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.
-
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 :)
+5% 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.
-
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! +5%
-
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!
-
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?
-
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?
-
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?
-
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.
-
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 :D
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.
-
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.
-
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!
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
The word "documentation" is unbounded. My in-code document level would be no less than what we already have right now. To be honest I'm not good at writing documents, sorry. If the one who wants to "take over and maintain or expand" the codes is willing to write a document, I'm more than glad to help.
-
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.
@cube
Actually, from the very beginning, when @abit offered to implement this BSIP, it was my intention (and part of the "deal" with abit) to make documentation an important part of the worker proposal.
As abit has already declared, he is not very keen on writing detailed descriptions so I offered to team up with him and take on this task.
My offer is based on the assumption that abit will be willing to share with me his know-how and help me with understanding all the nuances and decisions he's made when doing the coding.
So there are going to be two tiers of documentation:
(1) in-code comments by abit
(2) a detailed documentation/tutorial, written by me, explaining the whole context, i.e. some kind of guide for developers willing to follow in abit's footsteps
This is a fragment of my PM sent to abit earlier on today:
I wrote to abit:
Ideally, we could "sell" the worker proposal as a double benefit for the ecosystem:
- for the blockchain: a new functionality that opens up BitShares to tips and micro-payments
- for the whole ecosystem: a detailed description how to implement stuff without relying on CNX so that other coders & entrepreneurs can follow our example
To which he replied:
Regarding to docs, if you're going to write it, of course I will help you.
-
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.
Let me know if understand it correctly:
(1) If the committee wants to switch a given smart-coin to percentage-based fee model, it has to create a committee proposal and this proposal has to contain a certain fixed value for CER.
(2) After the committee proposal is accepted, it might happen that the committee decides to modify the actual CER and thus create a discrepancy between the value of CER embedded in the committee proposal and the current value of CER.
Is this correct?
If so, what is the reason that we need to embed the value of CER in the committee proposal and cannot use its current value when calculating a transfer fee?
-
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.
Let me know if understand it correctly:
(1) If the committee wants to switch a given smart-coin to percentage-based fee model, it has to create a committee proposal and this proposal has to contain a certain fixed value for CER.
(2) After the committee proposal is accepted, it might happen that the committee decides to modify the actual CER and thus create a discrepancy between the value of CER embedded in the committee proposal and the current value of CER.
Is this correct?
Correct.
If so, what is the reason that we need to embed the value of CER in the committee proposal and cannot use its current value when calculating a transfer fee?
According to the code, CER is a member variable of asset_update_operation, so it's required when creating such operation. For whatever reason, it has to be valid. And the asset will be updated according to the operation when the operation executes. It's current behavior/feature.
Maybe we can change the logic here:
* don't force CER to be valid when updating an asset
* if it's valid, change CER of the asset as the operation requested
* if it's invalid, don't change CER of the asset
I'll check the code to figure out whether it's possible to make it this way. Or maybe need input from CNX about why it's designed like this and whether it's proper to change the behavior.
If it's OK to change the behavior, since it's not included in BSIP10, we may need to add it. Wish it's not too complex so that I needn't to charge more for developing this feature.
-
According to the code, CER is a member variable of asset_update_operation, so it's required when creating such operation. For whatever reason, it has to be valid. And the asset will be updated according to the operation when the operation executes. It's current behavior/feature.
Maybe we can change the logic here:
* don't force CER to be valid when updating an asset
* if it's valid, change CER of the asset as the operation requested
* if it's invalid, don't change CER of the asset
I'll check the code to figure out whether it's possible to make it this way. Or maybe need input from CNX about why it's designed like this and whether it's proper to change the behavior.
If it's OK to change the behavior, since it's not included in BSIP10, we may need to add it. Wish it's not too complex so that I needn't to charge more for developing this feature.
I understand the above but still I don't see the reason why you need to store the CER value in the committee proposal instead of retrieving its current value directly from the asset whenever it's needed to calculate a transfer fee.
In other words, why the algorithm cannot work like this?
(1) A new transfer for asset X is about to be sent,
(2) Retrieve from the blockchain the current value of CER for asset X,
(3) Use this value to calculate the transfer fee,
(4) Charge the sender with this fee.
Is there some ambiguity about what the value of CER for asset X is at any given point in time?
-
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.
Actually, from the very beginning, when abit offered to implement this BSIP, it was my intention (and part of the "deal" with abit) to make documentation an important part of the worker proposal.
As abit has already declared, he is not very keen on writing detailed descriptions so I offered to team up with him and take on this task.
My offer is based on the assumption that abit will be willing to share with me his know-how and help me with understanding all the nuances and decisions he's made when doing the coding.
So there are going to be two tiers of documentation:
(1) in-code comments by abit
(2) a detailed documentation/tutorial, written by me, explaining the whole context, i.e. some kind of guide for developers willing to follow in abit's footsteps
I am really glad we are moving towards better and richer set of documentation. I appreciate your effort and drive towards this goal.
-
According to the code, CER is a member variable of asset_update_operation, so it's required when creating such operation. For whatever reason, it has to be valid. And the asset will be updated according to the operation when the operation executes. It's current behavior/feature.
Maybe we can change the logic here:
* don't force CER to be valid when updating an asset
* if it's valid, change CER of the asset as the operation requested
* if it's invalid, don't change CER of the asset
I'll check the code to figure out whether it's possible to make it this way. Or maybe need input from CNX about why it's designed like this and whether it's proper to change the behavior.
If it's OK to change the behavior, since it's not included in BSIP10, we may need to add it. Wish it's not too complex so that I needn't to charge more for developing this feature.
I understand the above but still I don't see the reason why you need to store the CER value in the committee proposal instead of retrieving its current value directly from the asset whenever it's needed to calculate a transfer fee.
In other words, why the algorithm cannot work like this?
(1) A new transfer for asset X is about to be sent,
(2) Retrieve from the blockchain the current value of CER for asset X,
(3) Use this value to calculate the transfer fee,
(4) Charge the sender with this fee.
Is there some ambiguity about what the value of CER for asset X is at any given point in time?
Well, the committee proposal is to "enable percentage based fee" for a committee-owned asset for example bitUSD. The real operation in the committee proposal is "asset_update_operation". CER is REQUIRED to be included in "asset_update_operation", which is current feature/behavior/limitation. In short, you have to manually set/change CER to enable percentage based fee. I proposed to change this behavior in last post, but I won't make this change unless it's included in BSIP.
Once percentage based fee is enabled for bitUSD, when a transfer is requested by a user, the fee would be calculated according to the algorithm you write above.
Anyway, after manually set CER with asset_update_operation, CER would be corrected maybe after one price feed, so perhaps it's not a big deal to leave the feature unchanged.
-
According to the code, CER is a member variable of asset_update_operation, so it's required when creating such operation. For whatever reason, it has to be valid. And the asset will be updated according to the operation when the operation executes. It's current behavior/feature.
Maybe we can change the logic here:
* don't force CER to be valid when updating an asset
* if it's valid, change CER of the asset as the operation requested
* if it's invalid, don't change CER of the asset
I'll check the code to figure out whether it's possible to make it this way. Or maybe need input from CNX about why it's designed like this and whether it's proper to change the behavior.
If it's OK to change the behavior, since it's not included in BSIP10, we may need to add it. Wish it's not too complex so that I needn't to charge more for developing this feature.
I understand the above but still I don't see the reason why you need to store the CER value in the committee proposal instead of retrieving its current value directly from the asset whenever it's needed to calculate a transfer fee.
In other words, why the algorithm cannot work like this?
(1) A new transfer for asset X is about to be sent,
(2) Retrieve from the blockchain the current value of CER for asset X,
(3) Use this value to calculate the transfer fee,
(4) Charge the sender with this fee.
Is there some ambiguity about what the value of CER for asset X is at any given point in time?
Well, the committee proposal is to "enable percentage based fee" for a committee-owned asset for example bitUSD. The real operation in the committee proposal is "asset_update_operation". CER is REQUIRED to be included in "asset_update_operation", which is current feature/behavior/limitation. In short, you have to manually set/change CER to enable percentage based fee. I proposed to change this behavior in last post, but I won't make this change unless it's included in BSIP.
Once percentage based fee is enabled for bitUSD, when a transfer is requested by a user, the fee would be calculated according to the algorithm you write above.
Anyway, after manually set CER with asset_update_operation, CER would be corrected maybe after one price feed, so perhaps it's not a big deal to leave the feature unchanged.
OK, I agree that it's not a big deal at this stage.
If it becomes problematic, we can address it in the future.
-
@abit ,
just to make sure: does your implementation cover all assets (including UIAs and FBAs) or just smart-coins (public & private)?
-
@abit ,
just to make sure: does your implementation cover all assets (including UIAs and FBAs) or just smart-coins (public & private)?
All assets except BTS. I have no idea about FBAs so far.
-
It is not key. The key is that we need to keep the rules stable. So people can have time to understand it.
We should not change key rules so frequency. We need more hard work and time to prove the system and the community is reliable. And that is why ETH and NEM price grow 3 times without any rule or feature change.
-
It is not key. The key is that we need to keep the rules stable. So people can have time to understand it.
We should not change key rules so frequency. We need more hard work and time to prove the system and the community is reliable. And that is why ETH and NEM price grow 3 times without any rule or feature change.
This proposal does not change the existing rules, it just an opt-in feature decided by issuers.
Those who don't like it can choose to do nothing and the current flat transfer fees will still apply.
-
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.
@svk Imo here is a list of work to be done in GUI:
* add an selection box on the "create asset" page and "update asset" page, so the issuer can set fee mode easily
* show transfer fee mode on asset details page, and maybe somewhere related
* use new operation to do all transfers (although the original operation can still be used on assets with flat mode)
* extend fee estimation to handle percent fees.
* the fee schedule page
Did I miss something?
I think Jakub will provide a document about data structure changes and API changes. Or you can dig into my code (after CNX reviewed)
Thanks for support!
-
To @xeroc, @cube and others who are testing or going to test my code:
I'm about to add an extension to the fee structure for easier future extension. After this change, something in the test chain will become incompatible. If replay doesn't work, need to reset the chain to a state before the first propose_fee_change after applied my previous change.
I will post here when the work is done.
I won't add hard fork logic for this change since it's too much work and not very useful imo.
Sorry for the inconvenience, and thanks for support!
-
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.
@svk Imo here is a list of work to be done in GUI:
* add an selection box on the "create asset" page and "update asset" page, so the issuer can set fee mode easily
* show transfer fee mode on asset details page, and maybe somewhere related
* use new operation to do all transfers (although the original operation can still be used on assets with flat mode)
* extend fee estimation to handle percent fees.
* the fee schedule page
Did I miss something?
I think Jakub will provide a document about data structure changes and API changes. Or you can dig into my code (after CNX reviewed)
Thanks for support!
OK.
How is the fee mode switched? Does it use the existing flags and permissions structure?
-
I think Jakub will provide a document about data structure changes and API changes. Or you can dig into my code (after CNX reviewed)
I'll surely do that once the worker proposal goes through.
-
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.
@svk Imo here is a list of work to be done in GUI:
* add an selection box on the "create asset" page and "update asset" page, so the issuer can set fee mode easily
* show transfer fee mode on asset details page, and maybe somewhere related
* use new operation to do all transfers (although the original operation can still be used on assets with flat mode)
* extend fee estimation to handle percent fees.
* the fee schedule page
Did I miss something?
I think Jakub will provide a document about data structure changes and API changes. Or you can dig into my code (after CNX reviewed)
Thanks for support!
OK.
How is the fee mode switched? Does it use the existing flags and permissions structure?
A new field in "extensions". Please check the examples in OP for reference (haven't been reviewed so far, so don't rely on it right now).
No permission involved so far.
Please let me know if I missed something. Thanks.
-
One scenario need to be taken into consideration:
Since CERs of smart coins change frequently, there may be race conditions when a transfer operation and a price feed operation appear at a same block.
Usually a user need some seconds to confirm her transaction, or say, after the "Please confirm the transaction" page is shown, before the user clicks 'OK', if CER changed, the transaction would probably fail due to insufficient fee provided. It will cause negative user experience.
Imo this should be included in BSIP.
I have an idea to solve this issue (sure it will make the whole thing more complicated):
* For smart coins, show a message "you need to confirm in 60 seconds" on the "please confirm" page, if the user failed to confirm in 60 seconds, disable the "OK" button.
* Maintain the "worst" CERs of every smart coins in last 3 minutes somewhere in witness_node. The fee is only required to be not lower than the lowest one.
Thoughts?
@jakub @svk
-
To @xeroc, @cube and others who are testing or going to test my code:
I'm about to add an extension to the fee structure for easier future extension. After this change, something in the test chain will become incompatible. If replay doesn't work, need to reset the chain to a state before the first propose_fee_change after applied my previous change.
I will post here when the work is done.
I won't add hard fork logic for this change since it's too much work and not very useful imo.
Sorry for the inconvenience, and thanks for support!
Done. @xeroc @cube
-
let me ask a question for the percentage fees.
suppose we have known the current rate for CNY is 0.02CNY/BTS, the min fee is 10 BTS, the high fee is 20 BTS, percentage is 0.1%
If I want to transfer 200 CNY, what fees information should package in the transaction?
is it 10 BTS or 0.2 CNY?
if this is an offline operation, such as signed from a cold wallet, or pay with a paper wallet.
when generate the operation, the rate is 0.02 CNY/BTS
after signed, you want to broadcast, the price have changed
1) if you pay fees with 10BTS, and price change to 0.019CNY/BTS, it's not enough, because now you need pay 0.2/0.019 BTS
2) if you pay fees with 0.2CNY, and price change to 0.021 CNY/BTS, it's still not enough, because now you need pay at least 10BTS*0.021CNY/BTS
-
let me ask a question for the percentage fees.
suppose we have known the current rate for CNY is 0.02CNY/BTS, the min fee is 10 BTS, the high fee is 20 BTS, percentage is 0.1%
If I want to transfer 200 CNY, what fees information should package in the transaction?
is it 10 BTS or 0.2 CNY?
if this is an offline operation, such as signed from a cold wallet, or pay with a paper wallet.
when generate the operation, the rate is 0.02 CNY/BTS
after signed, you want to broadcast, the price have changed
1) if you pay fees with 10BTS, and price change to 0.019CNY/BTS, it's not enough, because now you need pay 0.2/0.019 BTS
2) if you pay fees with 0.2CNY, and price change to 0.021 CNY/BTS, it's still not enough, because now you need pay at least 10BTS*0.021CNY/BTS
Thanks for pointing out this issue. It's what I just posted above. And a potential solution described.
Do you have better idea? If yes, please let us know, thanks!
Usually, if you are dealing with cold/offline wallets, you shouldn't be surprised if need to pay more, it's the trade off for better security. So what we need are some guidelines in "best practice of using cold/offline/paper wallets".
-
no, I am afraid that's not a solution
this kinds of complexity/uncertainty will make users felt more worse
-
no, I am afraid that's not a solution
this kinds of complexity/uncertainty will make users felt more worse
Sorry I didn't get what you said.
-
One scenario need to be taken into consideration:
Since CERs of smart coins change frequently, there may be race conditions when a transfer operation and a price feed operation appear at a same block.
Usually a user need some seconds to confirm her transaction, or say, after the "Please confirm the transaction" page is shown, before the user clicks 'OK', if CER changed, the transaction would probably fail due to insufficient fee provided. It will cause negative user experience.
Imo this should be included in BSIP.
I have an idea to solve this issue (sure it will make the whole thing more complicated):
* For smart coins, show a message "you need to confirm in 60 seconds" on the "please confirm" page, if the user failed to confirm in 60 seconds, disable the "OK" button.
* Maintain the "worst" CERs of every smart coins in last 3 minutes somewhere in witness_node. The fee is only required to be not lower than the lowest one.
Thoughts?
@jakub @svk
I think the simplest solution may be to overpay fees by 1% or so. This would give a buffer for CER movement.
The scenario you describe is a potential problem even without percentage-based fees, correct?
-
The scenario you describe is a potential problem even without percentage-based fees, correct?
Correct, when one doesn't pay fee in BTS but in other assets.
-
One scenario need to be taken into consideration:
Since CERs of smart coins change frequently, there may be race conditions when a transfer operation and a price feed operation appear at a same block.
Usually a user need some seconds to confirm her transaction, or say, after the "Please confirm the transaction" page is shown, before the user clicks 'OK', if CER changed, the transaction would probably fail due to insufficient fee provided. It will cause negative user experience.
Imo this should be included in BSIP.
I have an idea to solve this issue (sure it will make the whole thing more complicated):
* For smart coins, show a message "you need to confirm in 60 seconds" on the "please confirm" page, if the user failed to confirm in 60 seconds, disable the "OK" button.
* Maintain the "worst" CERs of every smart coins in last 3 minutes somewhere in witness_node. The fee is only required to be not lower than the lowest one.
Thoughts?
@jakub @svk
@abit @svk
Maybe there is a third option:
In case CER changes before the user has a chance to confirm the transfer, just charge the user more (or less) than the amount displayed on the confirmation screen. This way it will only fail in one situation which is quite rare: if the user does not have sufficient funds in their account to cover the unexpected increase in the transfer fee.
This is obviously not perfect (as occasionally there will be a discrepancy between the transfer fee displayed on the confirmation screen and the actual fee charged) but I think it's the best solution available from the UX perspective.
I think people are usually not bothered much about the exact value of the transfer fee as long as it is within some acceptable limits.
-
One scenario need to be taken into consideration:
Since CERs of smart coins change frequently, there may be race conditions when a transfer operation and a price feed operation appear at a same block.
Usually a user need some seconds to confirm her transaction, or say, after the "Please confirm the transaction" page is shown, before the user clicks 'OK', if CER changed, the transaction would probably fail due to insufficient fee provided. It will cause negative user experience.
Imo this should be included in BSIP.
I have an idea to solve this issue (sure it will make the whole thing more complicated):
* For smart coins, show a message "you need to confirm in 60 seconds" on the "please confirm" page, if the user failed to confirm in 60 seconds, disable the "OK" button.
* Maintain the "worst" CERs of every smart coins in last 3 minutes somewhere in witness_node. The fee is only required to be not lower than the lowest one.
Thoughts?
@jakub @svk
@abit @svk
Maybe there is a third option:
In case CER changes before the user has a chance to confirm the transfer, just charge the user more (or less) than the amount displayed on the confirmation screen. This way it will only fail in one situation which is quite rare: if the user does not have sufficient funds in their account to cover the unexpected increase in the transfer fee.
This is obviously not perfect (as occasionally there will be a discrepancy between the transfer fee displayed on the confirmation screen and the actual fee charged) but I think it's the best solution available from the UX perspective.
I think people are usually not bothered much about the exact value of the transfer fee as long as it is within some acceptable limits.
Sorry, we're unable to do it. Fee is a field in the transaction/operation which is signed by the user. We can't modify it, nor deduct even one Satoshi more than the amount in the transaction/operation.
Another option would be deduct some fee from the fee pool, if the issuer approves. But it's hard to judge why the fee provided by the user is insufficient -- due to CER change or something else (maybe attack).
-
Sorry, we're unable to do it. Fee is a field in the transaction/operation which is signed by the user. We can't modify it, nor deduct even one Satoshi more than the amount in the transaction/operation.
Another option would be deduct some fee from the fee pool, if the issuer approves. But it's hard to judge why the fee provided by the user is insufficient -- due to CER change or something else (maybe attack).
OK, I guess we'll have to live with that as it is.
If I understand it correctly, it will cause a negative UX in a very rare situation: only when there is a CER update between the moment you hit "Transfer" and the moment you hit "Confirm".
So my advice is to ignore the problem at this stage and if it becomes annoying in the future, we'll have to revise it, e.g. by introducing a 60 sec delay before the "Confirm" button gets disabled.
-
[KNOWN ISSUES/LIMITATIONS]
* Unable to apply percentage base fee mode to BTS
Please be aware of this^ limitation.
I wish we had some choice regarding this, nevertheless I think percentage-based fee mode for BTS is not crucial - there could be a flat transfer fee for BTS which is kept quite low.
EDIT: as abit rightly pointed it out, there is only one global flat transfer fee for all assets so we cannot make the flat fee low for BTS only.
The crucial things are SmartCoins (both public and private) and UIAs - these are fully covered.
As for FBAs - probably yes but we cannot say it for sure until FBAs are implemented.
-
One scenario need to be taken into consideration:
Since CERs of smart coins change frequently, there may be race conditions when a transfer operation and a price feed operation appear at a same block.
Usually a user need some seconds to confirm her transaction, or say, after the "Please confirm the transaction" page is shown, before the user clicks 'OK', if CER changed, the transaction would probably fail due to insufficient fee provided. It will cause negative user experience.
Imo this should be included in BSIP.
I have an idea to solve this issue (sure it will make the whole thing more complicated):
* For smart coins, show a message "you need to confirm in 60 seconds" on the "please confirm" page, if the user failed to confirm in 60 seconds, disable the "OK" button.
* Maintain the "worst" CERs of every smart coins in last 3 minutes somewhere in witness_node. The fee is only required to be not lower than the lowest one.
Thoughts?
@jakub @svk
@abit @svk
Maybe there is a third option:
In case CER changes before the user has a chance to confirm the transfer, just charge the user more (or less) than the amount displayed on the confirmation screen. This way it will only fail in one situation which is quite rare: if the user does not have sufficient funds in their account to cover the unexpected increase in the transfer fee.
This is obviously not perfect (as occasionally there will be a discrepancy between the transfer fee displayed on the confirmation screen and the actual fee charged) but I think it's the best solution available from the UX perspective.
I think people are usually not bothered much about the exact value of the transfer fee as long as it is within some acceptable limits.
Sorry, we're unable to do it. Fee is a field in the transaction/operation which is signed by the user. We can't modify it, nor deduct even one Satoshi more than the amount in the transaction/operation.
Another option would be deduct some fee from the fee pool, if the issuer approves. But it's hard to judge why the fee provided by the user is insufficient -- due to CER change or something else (maybe attack).
Aren't we talking about a scenario where the CER changes after the user initially submits the transaction, but BEFORE they confirm it? If so, then can't we present them with a new confirmation which includes the updated fee and a message explaining why the fee is slightly higher than expected?
-
One scenario need to be taken into consideration:
Since CERs of smart coins change frequently, there may be race conditions when a transfer operation and a price feed operation appear at a same block.
Usually a user need some seconds to confirm her transaction, or say, after the "Please confirm the transaction" page is shown, before the user clicks 'OK', if CER changed, the transaction would probably fail due to insufficient fee provided. It will cause negative user experience.
Imo this should be included in BSIP.
I have an idea to solve this issue (sure it will make the whole thing more complicated):
* For smart coins, show a message "you need to confirm in 60 seconds" on the "please confirm" page, if the user failed to confirm in 60 seconds, disable the "OK" button.
* Maintain the "worst" CERs of every smart coins in last 3 minutes somewhere in witness_node. The fee is only required to be not lower than the lowest one.
Thoughts?
@jakub @svk
@abit @svk
Maybe there is a third option:
In case CER changes before the user has a chance to confirm the transfer, just charge the user more (or less) than the amount displayed on the confirmation screen. This way it will only fail in one situation which is quite rare: if the user does not have sufficient funds in their account to cover the unexpected increase in the transfer fee.
This is obviously not perfect (as occasionally there will be a discrepancy between the transfer fee displayed on the confirmation screen and the actual fee charged) but I think it's the best solution available from the UX perspective.
I think people are usually not bothered much about the exact value of the transfer fee as long as it is within some acceptable limits.
Sorry, we're unable to do it. Fee is a field in the transaction/operation which is signed by the user. We can't modify it, nor deduct even one Satoshi more than the amount in the transaction/operation.
Another option would be deduct some fee from the fee pool, if the issuer approves. But it's hard to judge why the fee provided by the user is insufficient -- due to CER change or something else (maybe attack).
Aren't we talking about a scenario where the CER changes after the user initially submits the transaction, but BEFORE they confirm it? If so, then can't we present them with a new confirmation which includes the updated fee and a message explaining why the fee is slightly higher than expected?
Even if the UI calculate fee again, it still has chance to fail (sure chance is lower).
I think we should consider it seriously. If we can't make it reliable enough, perhaps it's acceptable for a PC GUI user to try again, but it may be terrible for 3rd party applications which transfer tokens automatically, or for a mobile user with a slow internet connection that unable to try again very soon.
In short, try to solve the problem at the witness_node level if can't solve at protocol level.
Another thing, if the committee decided to apply percentage fee to smart coins and/or BTS, we need to notify our partners (for example exchanges) in advance, so that they have time to adjust their applications if the applications aren't compatible with percentage fee.
-
According to the code, CER is a member variable of asset_update_operation, so it's required when creating such operation. For whatever reason, it has to be valid. And the asset will be updated according to the operation when the operation executes. It's current behavior/feature.
Maybe we can change the logic here:
* don't force CER to be valid when updating an asset
* if it's valid, change CER of the asset as the operation requested
* if it's invalid, don't change CER of the asset
I'll check the code to figure out whether it's possible to make it this way. Or maybe need input from CNX about why it's designed like this and whether it's proper to change the behavior.
If it's OK to change the behavior, since it's not included in BSIP10, we may need to add it. Wish it's not too complex so that I needn't to charge more for developing this feature.
I understand the above but still I don't see the reason why you need to store the CER value in the committee proposal instead of retrieving its current value directly from the asset whenever it's needed to calculate a transfer fee.
In other words, why the algorithm cannot work like this?
(1) A new transfer for asset X is about to be sent,
(2) Retrieve from the blockchain the current value of CER for asset X,
(3) Use this value to calculate the transfer fee,
(4) Charge the sender with this fee.
Is there some ambiguity about what the value of CER for asset X is at any given point in time?
Well, the committee proposal is to "enable percentage based fee" for a committee-owned asset for example bitUSD. The real operation in the committee proposal is "asset_update_operation". CER is REQUIRED to be included in "asset_update_operation", which is current feature/behavior/limitation. In short, you have to manually set/change CER to enable percentage based fee. I proposed to change this behavior in last post, but I won't make this change unless it's included in BSIP.
Once percentage based fee is enabled for bitUSD, when a transfer is requested by a user, the fee would be calculated according to the algorithm you write above.
Anyway, after manually set CER with asset_update_operation, CER would be corrected maybe after one price feed, so perhaps it's not a big deal to leave the feature unchanged.
OK, I agree that it's not a big deal at this stage.
If it becomes problematic, we can address it in the future.
I pushed a patch to the test branch of my repo, now it's possible to update an asset without changing CER.
OP updated accordingly with a new example at the end.
-
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.
@svk Imo here is a list of work to be done in GUI:
* add an selection box on the "create asset" page and "update asset" page, so the issuer can set fee mode easily
* show transfer fee mode on asset details page, and maybe somewhere related
* use new operation to do all transfers (although the original operation can still be used on assets with flat mode)
* extend fee estimation to handle percent fees.
* the fee schedule page
Did I miss something?
I think Jakub will provide a document about data structure changes and API changes. Or you can dig into my code (after CNX reviewed)
Thanks for support!
OK.
How is the fee mode switched? Does it use the existing flags and permissions structure?
A new field in "extensions". Please check the examples in OP for reference (haven't been reviewed so far, so don't rely on it right now).
No permission involved so far.
Please let me know if I missed something. Thanks.
@svk more work involved:
* since we changed fee allocation algorithm, need to adjust "Fees and cashback" section of membership page, and maybe description of "Fee Division", and maybe some related pages.
-
[KNOWN ISSUES/LIMITATIONS]
* Unable to apply percentage base fee mode to BTS
Please be aware of this^ limitation.
I wish we had some choice regarding this, nevertheless I think percentage-based fee mode for BTS is not crucial - there could be a flat transfer fee for BTS which is kept quite low.
As I said.. the simplest solution would be for the GUI to slightly overpay UIA fees.
How much you overpay can be a setting in the wallet. The default could be 1%.
It will prevent this problem 99.9% of the time.
If you want to save a few cents at the risk of rejected transactions, you could set it to 0%.
-
[KNOWN ISSUES/LIMITATIONS]
* Unable to apply percentage base fee mode to BTS
Please be aware of this^ limitation.
I wish we had some choice regarding this, nevertheless I think percentage-based fee mode for BTS is not crucial - there could be a flat transfer fee for BTS which is kept quite low.
As I said.. the simplest solution would be for the GUI to slightly overpay UIA fees.
How much you overpay can be a setting in the wallet. The default could be 1%.
It will prevent this problem 99.9% of the time.
If you want to save a few cents at the risk of rejected transactions, you could set it to 0%.
@roadscape Maybe you quoted something wrong? "Unable to apply percentage base fee mode to BTS" is because BTS's issuer is null-account, the committee is unable to change BTS's options. Unless we add a dedicated API for doing that.
-
@abit ah.. yes, sorry, wrong quote.. I'll try again:
I wanted to offer a simpler approach to the issue of CER changing mid-transaction.
The problem: if you pay fees with a UIA who's CER happens to drop before your tx is processed, then your transaction will be rejected.
To avoid rejection of transactions, we can have the GUI slightly overpay UIA fees.
How much you overpay can be a setting in the wallet. The default could be 1%.
It will prevent this problem 99.9% of the time.
If you want to save a few cents at the risk of rejected transactions, you could set it to 0%.
I like this approach because it doesn't require changes to witness_node or the protocol. (afaik)
You can already overpay in the CLI.. so I think essentially it can be used as a form of 'rejection insurance' as a GUI feature too. Wouldn't this solve it?
-
@abit ah.. yes, sorry, wrong quote.. I'll try again:
I wanted to offer a simpler approach to the issue of CER changing mid-transaction.
The problem: if you pay fees with a UIA who's CER happens to drop before your tx is processed, then your transaction will be rejected.
To avoid rejection of transactions, we can have the GUI slightly overpay UIA fees.
How much you overpay can be a setting in the wallet. The default could be 1%.
It will prevent this problem 99.9% of the time.
If you want to save a few cents at the risk of rejected transactions, you could set it to 0%.
I like this approach because it doesn't require changes to witness_node or the protocol. (afaik)
You can already overpay in the CLI.. so I think essentially it can be used as a form of 'rejection insurance' as a GUI feature too. Wouldn't this solve it?
Yes, it's a good idea, simple and effective. Thanks!
-
Will the recent issue related to an expiring order with 0-fee result in an issue with percentage based transfer fees?
-
Will the recent issue related to an expiring order with 0-fee result in an issue with percentage based transfer fees?
I have no idea.. looks irrelevant.
-
We've made an official worker proposal announcement:
https://bitsharestalk.org/index.php/topic,21230.0.html
If you think percentage-based transfer fees make sense, please support us by your shareholder votes.
The main credit goes to @abit - I'm just trying to do my best to support his skills and extract knowledge from him and make good use of it.
-
Great job @abit!
Same to you @jakub!
Good suggestion on the GUI solution @roadscape!
I like the idea. I'm strongly leaning towards percentage based fees because:
1) it will lower fees for new users who will probably test out smaller amounts in the beginning
2) might be slightly easier to explain
3) higher potential referral income for businesses and affiliates
4) it shouldn't make a noticeable difference to high risk merchants who accept payments and who subsidize fees.
Question:
-We can switch back to the original fee structure anytime right?
-What is the timeline for this to be available?
Thx!
-
Great job @abit!
Same to you @jakub!
Good suggestion on the GUI solution @roadscape!
I like the idea. I'm strongly leaning towards percentage based fees because:
1) it will lower fees for new users who will probably test out smaller amounts in the beginning
2) might be slightly easier to explain
3) higher potential referral income for businesses and affiliates
4) it shouldn't make a noticeable difference to high risk merchants who accept payments and who subsidize fees.
Question:
-We can switch back to the original fee structure anytime right?
The issuers can switch at anytime.
-What is the timeline for this to be available?
Thx!
See https://bitsharestalk.org/index.php/topic,21230.0.html .
Currently the net vote for this worker is negative, which means the stake holders don't want this feature. So it won't come anytime soon. https://cryptofresh.com/workers
-
What is the timeline for this to be available?
We've made an estimate of 12 weeks after the proposal goes through.
Might be sooner if the work goes smoothly - it's hard to predict those things.
Currently the net vote for this worker is negative, which means the stake holders don't want this feature. So it won't come anytime soon. https://cryptofresh.com/workers
I believe currently it's only bitcrab actively voting against (not neutral but against) and, as his proxy has quite a lot of power (over 80m), we are currently losing the net vote.
http://cryptofresh.com/u/bitcrab
-
Thanks @jakub and @abit for the response. I think @bitcrab is very close to being in favor.
I just wanted to confirm that we can create the following scenario with BSIP10. I understand the proposal doesn't determine fees, but I just wanted to get confirmation the modes below are possible if the committee decides:
Mode A: 1 cent per transaction to the network (no incentive for referral program or membership)
Mode B: 1% per transaction, 1 cent minimum fee (example max. $1/$10/$20), lifetime/annual members: 1 cent
Mode C: flat 20 cents per transaction, lifetime/annual members: 1 cent
In all three modes 1 cent goes to the network for each transaction so it's fair and the network doesn't care which mode anyone selects. Mode B & C adds an extra fee layer that all goes to referrals.
@abit mentioned this:
"I'd like to emphasize again that fee rates can only be set by the committee, and issuers can only choose among the fee modes.
I'm willing to implement per-asset fee rates, however it would be funded via FBA, so won't come in the soon future."
I assume issuers are dependent on the committee, but eventually issuers should have flexibility to determine fee rates. Is it too complicated to add that feature in BSIP10? Do you have a rough estimate of the cost just as an FYI? Also wouldn't it make sense as just another worker proposal instead of an FBA. I think FBAs are for income generating features.
Since it seems the committee determines the fee it would be hard to accommodate all of CNY/USD/Eur for mode B. We have to assume Mode B & C is for US/Eur Smartcoins and Mode A is for CNY Smartcoins. Privatized Smartcoins, UIA's, FBA's would get to choose any mode, but can only use the fee schedule the committee determines for now. Is that correct?
-
Also for other types of transactions such as premium names & UIA's I assume we can keep the discounts only for lifetime and annual members?
-
Thanks @jakub and @abit for the response. I think @bitcrab is very close to being in favor.
I just wanted to confirm that we can create the following scenario with BSIP10. I understand the proposal doesn't determine fees, but I just wanted to get confirmation the modes below are possible if the committee decides:
Mode A: 1 cent per transaction to the network (no incentive for referral program or membership)
Mode B: 1% per transaction, 1 cent minimum fee (example max. $1/$10/$20), lifetime/annual members: 1 cent
Mode C: flat 20 cents per transaction, lifetime/annual members: 1 cent
In all three modes 1 cent goes to the network for each transaction so it's fair and the network doesn't care which mode anyone selects. Mode B & C adds an extra fee layer that all goes to referrals.
@abit mentioned this:
"I'd like to emphasize again that fee rates can only be set by the committee, and issuers can only choose among the fee modes.
I'm willing to implement per-asset fee rates, however it would be funded via FBA, so won't come in the soon future."
I assume issuers are dependent on the committee, but eventually issuers should have flexibility to determine fee rates. Is it too complicated to add that feature in BSIP10? Do you have a rough estimate of the cost just as an FYI? Also wouldn't it make sense as just another worker proposal instead of an FBA. I think FBAs are for income generating features.
Since it seems the committee determines the fee it would be hard to accommodate all of CNY/USD/Eur for mode B. We have to assume Mode B & C is for US/Eur Smartcoins and Mode A is for CNY Smartcoins. Privatized Smartcoins, UIA's, FBA's would get to choose any mode, but can only use the fee schedule the committee determines for now. Is that correct?
What incentive is there for a selfish issuer to choose B or C , if he can just choose A to skip the referrers and make the users of his asset happy?
-
I assume issuers are dependent on the committee, but eventually issuers should have flexibility to determine fee rates. Is it too complicated to add that feature in BSIP10? Do you have a rough estimate of the cost just as an FYI? Also wouldn't it make sense as just another worker proposal instead of an FBA. I think FBAs are for income generating features.
In my opinion, while issuers have more flexibility, they'll get benefit from the system, so it's fair for them to pay a little more or share some profits to other parties e.g. network, referral program and FBA holders. The benefit could be more users, or more revenue, or lower management costs, or better user experience, etc. For example, if an issuer wants to provide zero fee service to users, it would be possible with per asset fee rate mode, but she must pay for the users in some way. Bottom line, issuers should be unable to hurt the system by setting a zero fee rate, otherwise the system will be vulnerable to spam attacks.
Since it seems the committee determines the fee it would be hard to accommodate all of CNY/USD/Eur for mode B. We have to assume Mode B & C is for US/Eur Smartcoins and Mode A is for CNY Smartcoins. Privatized Smartcoins, UIA's, FBA's would get to choose any mode, but can only use the fee schedule the committee determines for now. Is that correct?
Correct.
Also for other types of transactions such as premium names & UIA's I assume we can keep the discounts only for lifetime and annual members?
Other types of transactions won't be affected by BSIP10.
-
Thanks @jakub and @abit for the response. I think @bitcrab is very close to being in favor.
I just wanted to confirm that we can create the following scenario with BSIP10. I understand the proposal doesn't determine fees, but I just wanted to get confirmation the modes below are possible if the committee decides:
Mode A: 1 cent per transaction to the network (no incentive for referral program or membership)
Mode B: 1% per transaction, 1 cent minimum fee (example max. $1/$10/$20), lifetime/annual members: 1 cent
Mode C: flat 20 cents per transaction, lifetime/annual members: 1 cent
In all three modes 1 cent goes to the network for each transaction so it's fair and the network doesn't care which mode anyone selects. Mode B & C adds an extra fee layer that all goes to referrals.
@abit mentioned this:
"I'd like to emphasize again that fee rates can only be set by the committee, and issuers can only choose among the fee modes.
I'm willing to implement per-asset fee rates, however it would be funded via FBA, so won't come in the soon future."
I assume issuers are dependent on the committee, but eventually issuers should have flexibility to determine fee rates. Is it too complicated to add that feature in BSIP10? Do you have a rough estimate of the cost just as an FYI? Also wouldn't it make sense as just another worker proposal instead of an FBA. I think FBAs are for income generating features.
Since it seems the committee determines the fee it would be hard to accommodate all of CNY/USD/Eur for mode B. We have to assume Mode B & C is for US/Eur Smartcoins and Mode A is for CNY Smartcoins. Privatized Smartcoins, UIA's, FBA's would get to choose any mode, but can only use the fee schedule the committee determines for now. Is that correct?
What incentive is there for a selfish issuer to choose B or C , if he can just choose A to skip the referrers and make the users of his asset happy?
Imo if option A is allowed to exist, the fee should be higher than minimum fee of B or C, or the issuer pay some in other ways for example a monthly fee deducted from fee pool, so it will come to a balanced situation.
-
I assume issuers are dependent on the committee, but eventually issuers should have flexibility to determine fee rates. Is it too complicated to add that feature in BSIP10? Do you have a rough estimate of the cost just as an FYI? Also wouldn't it make sense as just another worker proposal instead of an FBA. I think FBAs are for income generating features.
In my opinion, while issuers have more flexibility, they'll get benefit from the system, so it's fair for them to pay a little more or share some profits to other parties e.g. network, referral program and FBA holders. The benefit could be more users, or more revenue, or lower management costs, or better user experience, etc. For example, if an issuer wants to provide zero fee service to users, it would be possible with per asset fee rate mode, but she must pay for the users in some way. Bottom line, issuers should be unable to hurt the system by setting a zero fee rate, otherwise the system will be vulnerable to spam attacks.
Hmmm.. From a business perspective I think it's better to use FBAs for new, niche, or advanced features that expand the network in new business segments. For broad/core features that deal with fees for all types of assets (FBAs,UIAs, Smartcoins, Privatized BitAssets) it seems inappropriate to use an FBA. Also I think the network should provide the bare minimum fees it can sustain with the limited dilution that is built in. I never thought the network needed to take any piece of referral fees, because it was mainly for marketing and the network doesn't provide recurring support for marketing. The fee structure should be based on the value it brings. It's either one-time or recurring and I think the ability to change fees is a one-time value-add feature vs a recurring one. With the referral program it's meritocratic. You get paid for each active user you bring in. Unless you're constantly improving or maintaining the technology, it should be a one-time fee. I think FBAs should work the same way and need to be continually maintained and improved or be outcompeted. I think the network portion of the referral program originally was to help subsidize lower fees based on the thinking that 20 cents would be the long-term fee. I think a 20 cent fee can work in the US, but it's better to keep the network fee the bare minimum 1 cent to obtain the broadest appeal and get network effect while allowing business that are able to charge higher fees in the US & Europe do so at the same time.
Since it seems the committee determines the fee it would be hard to accommodate all of CNY/USD/Eur for mode B. We have to assume Mode B & C is for US/Eur Smartcoins and Mode A is for CNY Smartcoins. Privatized Smartcoins, UIA's, FBA's would get to choose any mode, but can only use the fee schedule the committee determines for now. Is that correct?
Correct.
Great thx.
Also for other types of transactions such as premium names & UIA's I assume we can keep the discounts only for lifetime and annual members?
Other types of transactions won't be affected by BSIP10.
Great thx.
What incentive is there for a selfish issuer to choose B or C , if he can just choose A to skip the referrers and make the users of his asset happy?
Imo if option A is allowed to exist, the fee should be higher than minimum fee of B or C, or the issuer pay some in other ways for example a monthly fee deducted from fee pool, so it will come to a balanced situation.
@jakub @abit It's better to look at the referral program as an important, but add-on marketing feature. If the issuer wants to use the referral program and thinks a membership model is worth having despite higher basic fees they will want to use Mode B or C. I would like to use B or C for Bitcash with a privatized Smartcoin. If I was a business going after a different market maybe Mode A would work better. If I had outside capital or better marketing strategies Mode A might work better. The committee can decide what is appropriate for USD/Eur Smartcoins. Either way the network should charge the lowest fee to be sustainable and appeal to as many countries and businesses as possible and not really care which mode anyone chooses. We can evaluate the active user growth for assets that use Mode A, B, C over time... (there will be many other factors that determine growth, but at least we'll have some data to refer to.) Heck we should even have a friendly competition. :P. Either way the biggest concern for the network is active user growth and a flexible structure like this can satisfy all parties with limited compromise.
-
It's better to look at the referral program as an important, but add-on marketing feature. If the issuer wants to use the referral program and thinks a membership model is worth having despite higher basic fees they will want to use Mode B or C. I would like to use B or C for Bitcash with a privatized Smartcoin. If I was a business going after a different market maybe Mode A would work better. If I had outside capital or better marketing strategies Mode A might work better. The committee can decide what is appropriate for USD/Eur Smartcoins. Either way the network should charge the lowest fee to be sustainable and appeal to as many countries and businesses as possible and not really care which mode anyone chooses. We can evaluate the active user growth for assets that use Mode A, B, C over time... (there will be many other factors that determine growth, but at least we'll have some data to refer to.) Heck we should even have a friendly competition. :P. Either way the biggest concern for the network is active user growth and a flexible structure like this can satisfy all parties with limited compromise.
I do not quite get the logic here. users are users no matter who brought them to the system, they become user for each and every aspect of the system (like it or not) What is the fee structure of the assets of the entity that brought them here, is of little consequence as they can use other services.
I know theDEX and now you apparently are planing to limit this freedom @JoeyD , but I do hope and believe you fail in that aspect of your plans.
-
It's better to look at the referral program as an important, but add-on marketing feature. If the issuer wants to use the referral program and thinks a membership model is worth having despite higher basic fees they will want to use Mode B or C. I would like to use B or C for Bitcash with a privatized Smartcoin. If I was a business going after a different market maybe Mode A would work better. If I had outside capital or better marketing strategies Mode A might work better. The committee can decide what is appropriate for USD/Eur Smartcoins. Either way the network should charge the lowest fee to be sustainable and appeal to as many countries and businesses as possible and not really care which mode anyone chooses. We can evaluate the active user growth for assets that use Mode A, B, C over time... (there will be many other factors that determine growth, but at least we'll have some data to refer to.) Heck we should even have a friendly competition. :P. Either way the biggest concern for the network is active user growth and a flexible structure like this can satisfy all parties with limited compromise.
I do not quite get the logic here. users are users no matter who brought them to the system, they become user for each and every aspect of the system (like it or not) What is the fee structure of the assets of the entity that brought them here, is of little consequence as they can use other services.
I know theDEX and now you apparently are planing to limit this freedom @JoeyD , but I do hope and believe you fail in that aspect of your plans.
Not quite sure I follow your logic and what this has anything to do with limiting freedom. I'm saying we can measure active user growth as one data point to see if lower fees (Mode A) makes a big difference vs. higher basic fees and a membership model (Mode B & C). It seems to be the topic of debate so it's just for educational purposes and friendly competition to track that. (There are many other factors that determine growth as I stated before.)
-
It's better to look at the referral program as an important, but add-on marketing feature. If the issuer wants to use the referral program and thinks a membership model is worth having despite higher basic fees they will want to use Mode B or C. I would like to use B or C for Bitcash with a privatized Smartcoin. If I was a business going after a different market maybe Mode A would work better. If I had outside capital or better marketing strategies Mode A might work better. The committee can decide what is appropriate for USD/Eur Smartcoins. Either way the network should charge the lowest fee to be sustainable and appeal to as many countries and businesses as possible and not really care which mode anyone chooses. We can evaluate the active user growth for assets that use Mode A, B, C over time... (there will be many other factors that determine growth, but at least we'll have some data to refer to.) Heck we should even have a friendly competition. :P. Either way the biggest concern for the network is active user growth and a flexible structure like this can satisfy all parties with limited compromise.
I do not quite get the logic here. users are users no matter who brought them to the system, they become user for each and every aspect of the system (like it or not) What is the fee structure of the assets of the entity that brought them here, is of little consequence as they can use other services.
I know theDEX and now you apparently are planing to limit this freedom @JoeyD , but I do hope and believe you fail in that aspect of your plans.
I was about to make the same commentary.. a user is a user of the whole system and making decisions based on this fragmented outlooks is just operating on a faulty assumption.
If a merchant bring in 100,000 users he gets benefits, but because of the shared network, other merchants could also benefit from those users now using bitshares. So the merchant that paid nothing into the network is going to not only benefit from that merchant that brought the 100k users in, he is going to cheat him out of his % cut which he should be getting for bring that business to them.
This idea of fragmenting pieces of the network and the refer system to accommodate one crabby business is not only counter productive, but will have ongoing issues going forward. If they have no interest in shared network effect, they might as well fork.
-
I assume issuers are dependent on the committee, but eventually issuers should have flexibility to determine fee rates. Is it too complicated to add that feature in BSIP10? Do you have a rough estimate of the cost just as an FYI? Also wouldn't it make sense as just another worker proposal instead of an FBA. I think FBAs are for income generating features.
In my opinion, while issuers have more flexibility, they'll get benefit from the system, so it's fair for them to pay a little more or share some profits to other parties e.g. network, referral program and FBA holders. The benefit could be more users, or more revenue, or lower management costs, or better user experience, etc. For example, if an issuer wants to provide zero fee service to users, it would be possible with per asset fee rate mode, but she must pay for the users in some way. Bottom line, issuers should be unable to hurt the system by setting a zero fee rate, otherwise the system will be vulnerable to spam attacks.
Hmmm.. From a business perspective I think it's better to use FBAs for new, niche, or advanced features that expand the network in new business segments. For broad/core features that deal with fees for all types of assets (FBAs,UIAs, Smartcoins, Privatized BitAssets) it seems inappropriate to use an FBA. Also I think the network should provide the bare minimum fees it can sustain with the limited dilution that is built in. I never thought the network needed to take any piece of referral fees, because it was mainly for marketing and the network doesn't provide recurring support for marketing. The fee structure should be based on the value it brings. It's either one-time or recurring and I think the ability to change fees is a one-time value-add feature vs a recurring one. With the referral program it's meritocratic. You get paid for each active user you bring in. Unless you're constantly improving or maintaining the technology, it should be a one-time fee. I think FBAs should work the same way and need to be continually maintained and improved or be outcompeted. I think the network portion of the referral program originally was to help subsidize lower fees based on the thinking that 20 cents would be the long-term fee. I think a 20 cent fee can work in the US, but it's better to keep the network fee the bare minimum 1 cent to obtain the broadest appeal and get network effect while allowing business that are able to charge higher fees in the US & Europe do so at the same time.
Yes there would be continuous improvements/developments. Perhaps you've never thought how much work need to be done to support all potential features, perhaps you will only use a small part of them, but others may need other features. FBA is for special features which major stake holders don't want to dilute for.
The network need to sustain, which means in the end it's best to be able to pay witnesses and workers from income / fees, although they have to be paid from dilution in the beginning due to insufficient income.
Imo setting a low fee and not splitting to the referral program will definitely hurt the referral program. Asset issuers should have no privileges to hurt other parties.
What incentive is there for a selfish issuer to choose B or C , if he can just choose A to skip the referrers and make the users of his asset happy?
Imo if option A is allowed to exist, the fee should be higher than minimum fee of B or C, or the issuer pay some in other ways for example a monthly fee deducted from fee pool, so it will come to a balanced situation.
@jakub @abit It's better to look at the referral program as an important, but add-on marketing feature. If the issuer wants to use the referral program and thinks a membership model is worth having despite higher basic fees they will want to use Mode B or C. I would like to use B or C for Bitcash with a privatized Smartcoin. If I was a business going after a different market maybe Mode A would work better. If I had outside capital or better marketing strategies Mode A might work better. The committee can decide what is appropriate for USD/Eur Smartcoins. Either way the network should charge the lowest fee to be sustainable and appeal to as many countries and businesses as possible and not really care which mode anyone chooses. We can evaluate the active user growth for assets that use Mode A, B, C over time... (there will be many other factors that determine growth, but at least we'll have some data to refer to.) Heck we should even have a friendly competition. :P. Either way the biggest concern for the network is active user growth and a flexible structure like this can satisfy all parties with limited compromise.
By selecting mode A means the issuer will get benefit when users referred by other referrers come to use her service, in the meanwhile the referrers will be hurt, unless the issuer white-list her users. This can't satisfy all parties if fee rate not set properly.
-
It's better to look at the referral program as an important, but add-on marketing feature. If the issuer wants to use the referral program and thinks a membership model is worth having despite higher basic fees they will want to use Mode B or C. I would like to use B or C for Bitcash with a privatized Smartcoin. If I was a business going after a different market maybe Mode A would work better. If I had outside capital or better marketing strategies Mode A might work better. The committee can decide what is appropriate for USD/Eur Smartcoins. Either way the network should charge the lowest fee to be sustainable and appeal to as many countries and businesses as possible and not really care which mode anyone chooses. We can evaluate the active user growth for assets that use Mode A, B, C over time... (there will be many other factors that determine growth, but at least we'll have some data to refer to.) Heck we should even have a friendly competition. :P. Either way the biggest concern for the network is active user growth and a flexible structure like this can satisfy all parties with limited compromise.
I do not quite get the logic here. users are users no matter who brought them to the system, they become user for each and every aspect of the system (like it or not) What is the fee structure of the assets of the entity that brought them here, is of little consequence as they can use other services.
I know theDEX and now you apparently are planing to limit this freedom @JoeyD , but I do hope and believe you fail in that aspect of your plans.
I was about to make the same commentary.. a user is a user of the whole system and making decisions based on this fragmented outlooks is just operating on a faulty assumption.
If a merchant bring in 100,000 users he gets benefits, but because of the shared network, other merchants could also benefit from those users now using bitshares. So the merchant that paid nothing into the network is going to not only benefit from that merchant that brought the 100k users in, he is going to cheat him out of his % cut which he should be getting for bring that business to them.
This idea of fragmenting pieces of the network and the refer system to accommodate one crabby business is not only counter productive, but will have ongoing issues going forward. If they have no interest in shared network effect, they might as well fork.
Not sure I follow this. Either mode A, B or C may generate more users (all things being equal and eliminating many other factors.) No one knows which mode will get more active users. It can be that low fees and no referral program brings in 1,000,000 users. Then Mode A may be perceived to have brought more value. If Mode B or C brings more users (ie. 2,000,000) it may indicate the referral program works well. Without isolating other factors we may never know, but tracking active users provides one somewhat useful data point. The proposal for three modes makes it fair to the network because the network will get the same fees no matter who brings them in. Accommodating various modes and more businesses enhances network effect, it doesn't decrease it.
-
It's better to look at the referral program as an important, but add-on marketing feature. If the issuer wants to use the referral program and thinks a membership model is worth having despite higher basic fees they will want to use Mode B or C. I would like to use B or C for Bitcash with a privatized Smartcoin. If I was a business going after a different market maybe Mode A would work better. If I had outside capital or better marketing strategies Mode A might work better. The committee can decide what is appropriate for USD/Eur Smartcoins. Either way the network should charge the lowest fee to be sustainable and appeal to as many countries and businesses as possible and not really care which mode anyone chooses. We can evaluate the active user growth for assets that use Mode A, B, C over time... (there will be many other factors that determine growth, but at least we'll have some data to refer to.) Heck we should even have a friendly competition. :P. Either way the biggest concern for the network is active user growth and a flexible structure like this can satisfy all parties with limited compromise.
I do not quite get the logic here. users are users no matter who brought them to the system, they become user for each and every aspect of the system (like it or not) What is the fee structure of the assets of the entity that brought them here, is of little consequence as they can use other services.
I know theDEX and now you apparently are planing to limit this freedom @JoeyD , but I do hope and believe you fail in that aspect of your plans.
I was about to make the same commentary.. a user is a user of the whole system and making decisions based on this fragmented outlooks is just operating on a faulty assumption.
If a merchant bring in 100,000 users he gets benefits, but because of the shared network, other merchants could also benefit from those users now using bitshares. So the merchant that paid nothing into the network is going to not only benefit from that merchant that brought the 100k users in, he is going to cheat him out of his % cut which he should be getting for bring that business to them.
This idea of fragmenting pieces of the network and the refer system to accommodate one crabby business is not only counter productive, but will have ongoing issues going forward. If they have no interest in shared network effect, they might as well fork.
Not sure I follow this. Either mode A, B or C may generate more users (all things being equal and eliminating many other factors.) No one knows which mode will get more active users. It can be that low fees and no referral program brings in 1,000,000 users. Then Mode A may be perceived to have brought more value. If Mode B or C brings more users (ie. 2,000,000) it may indicate the referral program works well. Without isolating other factors we may never know, but tracking active users provides one somewhat useful data point. The proposal for three modes makes it fair to the network because the network will get the same fees no matter who brings them in. Accommodating various modes and more businesses enhances network effect, it doesn't decrease it.
There are no 3 modes on a system-wise level. There is just one - the lowest fee (A in your words). The rest is testing very uninformative alternatives - does people like paying more or less.
[edit] the only way to have the 3 modes at once is - the high fee business models trying to cut (or try to) their users out of the rest of the system. The negatives from that in all kind of aspects should be obvious.
-
Not sure I follow this. Either mode A, B or C may generate more users (all things being equal and eliminating many other factors.) No one knows which mode will get more active users. It can be that low fees and no referral program brings in 1,000,000 users. Then Mode A may be perceived to have brought more value. If Mode B or C brings more users (ie. 2,000,000) it may indicate the referral program works well. Without isolating other factors we may never know, but tracking active users provides one somewhat useful data point. The proposal for three modes makes it fair to the network because the network will get the same fees no matter who brings them in. Accommodating various modes and more businesses enhances network effect, it doesn't decrease it.
But it's unfair to who brought in users. Hence reduced incentives.
-
Yes there would be continuous improvements/developments. Perhaps you've never thought how much work need to be done to support all potential features, perhaps you will only use a small part of them, but others may need other features. FBA is for special features which major stake holders don't want to dilute for.
The network need to sustain, which means in the end it's best to be able to pay witnesses and workers from income / fees, although they have to be paid from dilution in the beginning due to insufficient income.
Imo setting a low fee and not splitting to the referral program will definitely hurt the referral program. Asset issuers should have no privileges to hurt other parties.
Well we can set a higher fee for all three modes to sustain the network if dilution doesn't cover it, but the referral program shouldn't have anything to do with this. The referral program can be an add-on layer for specific assets. I'd prefer the lowest sustainable network fee, but we can let the committee decide what the minimum network fees should be to pay the witnesses and for non-FBA software development and maintenance.
I plan to use the referral Mode B for a privatized Smartcoin so I don't feel having another asset using Mode A even in direct competition with us would be that big of a deal. There are a whole lot of other reasons a business is going to be successful besides fees.
By selecting mode A means the issuer will get benefit when users referred by other referrers come to use her service, in the meanwhile the referrers will be hurt, unless the issuer white-list her users. This can't satisfy all parties if fee rate not set properly.
What if the issuer of Mode A brings in 1,000,000,000 new users because of low fees and brings new users to pay higher fees for another asset that uses Mode B or C? The network should take just one low fee to sustain itself for maximum network effect. Issuers should have flexibility on pricing, not the committee. The committee should simply determine the network fee. Any UIA, FBA, Privatized Smartcoin issuer should be able to set fees on top of the network fee. Technically an issuer can try to add fees outside of the Bitshares system, but it's much more natural to just add that as a standard feature to the system to attract far more businesses to use the platform.
-
There are no 3 modes on a system-wise level. There is just one - the lowest fee (A in your words). The rest is testing very uninformative alternatives - does people like paying more or less.
[edit] the only way to have the 3 modes at once is - the high fee business models trying to cut (or try to) their users out of the rest of the system. The negatives from that in all kind of aspects should be obvious.
No it's testing to see if a referral/membership program with higher basic fees, but with incentives can acquire more users than one with low fees and no referral incentives. CNY assets will probably use Mode A. USD/Eur assets will probably use Mode B or C. I may be able to transfer funds with CNY more cheaply than USD, but I'll probably just use USD assets for convenience. (For members the cost will be the same.) Hence users can use any asset in the system they prefer. Also the referral/membership model will allow discounts on creating: premium names, UIAs, FBAs, as well as using any other higher fee asset so there is a shared network effect for membership.
-
By selecting mode A means the issuer will get benefit when users referred by other referrers come to use her service, in the meanwhile the referrers will be hurt, unless the issuer white-list her users. This can't satisfy all parties if fee rate not set properly.
What if the issuer of Mode A brings in 1,000,000,000 new users because of low fees and brings new users to pay higher fees for another asset that uses Mode B or C? The network should take just one low fee to sustain itself for maximum network effect. Issuers should have flexibility on pricing, not the committee. The committee should simply determine the network fee. Any UIA, FBA, Privatized Smartcoin issuer should be able to set fees on top of the network fee. Technically an issuer can try to add fees outside of the Bitshares system, but it's much more natural to just add that as a standard feature to the system to attract far more businesses to use the platform.
Issuers don't bring in users by their own alone. When they bring in users, they act as registrars or referrers. In this case, the issuer is able to reimburse the users the extra fees paid by users and split to referral program (actually to the issuer in this case), no matter what fee mode she selected for her product.
More important, if the issuer selected a fee mode which doesn't split fees to referral program, OTHER REGISTRARS/REFERRERS would be not willing to bring users FOR THE ISSUER, even worse, they may try to isolate/hurt the issuer's product since it does nothing good to them but probably get benefit from THEIR user bases. Which means the issuer has to fight alone, even against other parties. Which will do no good to the whole system.
-
By selecting mode A means the issuer will get benefit when users referred by other referrers come to use her service, in the meanwhile the referrers will be hurt, unless the issuer white-list her users. This can't satisfy all parties if fee rate not set properly.
What if the issuer of Mode A brings in 1,000,000,000 new users because of low fees and brings new users to pay higher fees for another asset that uses Mode B or C? The network should take just one low fee to sustain itself for maximum network effect. Issuers should have flexibility on pricing, not the committee. The committee should simply determine the network fee. Any UIA, FBA, Privatized Smartcoin issuer should be able to set fees on top of the network fee. Technically an issuer can try to add fees outside of the Bitshares system, but it's much more natural to just add that as a standard feature to the system to attract far more businesses to use the platform.
Issuers don't bring in users by their own alone. When they bring in users, they act as registrars or referrers. In this case, the issuer is able to reimburse the users the extra fees paid by users and split to referral program (actually to the issuer in this case), no matter what fee mode she selected for her product.
More important, if the issuer selected a fee mode which doesn't split fees to referral program, OTHER REGISTRARS/REFERRERS would be not willing to bring users FOR THE ISSUER, even worse, they may try to isolate/hurt the issuer's product since it does nothing good to them but probably get benefit from THEIR user bases. Which means the issuer has to fight alone, even against other parties. Which will do no good to the whole system.
Sure you can think of issuers of assets as a mini-platform for various businesses to use. Bitshares BTS is the broader platform. Wallet/Exchange/Referral businesses can choose any issuer/asset they want. If a wallet or exchange want lower basic fees they can choose an asset with Mode A. If a wallet or exchange wants to have a referral/membership model they can choose an asset with Mode B or C.
It seems that you are trying to save the issuers from themselves rather than give them a choice? If an issuer chooses a fee Mode A that has no referral/membership program and many registrars/referrers don't promote them they will have to find other methods to gain users with outside capital, but they will have an advantage of offering lower basic fees. Why is that a problem especially when a predominant contingent in China want Mode A?
What are your thoughts on Privatized Smartcoins? My thought is that people will naturally want to promote Public Smartcoins instead of a BitCash Privatized Smartcoin or even TCNY so we who issue Privatized Smartcoins are at a disadvantage. Do you want to save us from ourselves? Privatized Smartcoins need to find users by improving parameters, providing liquidity, acquiring different customer segments etc. The positive is that they aren't forced into using particular parameters or price feeds. In the same way they shouldn't be forced into a particular fee Mode or fee schedule especially because their business and customer demographic may be different than other businesses.
As I see it, if we have three modes it may look something like this for Smartcoins:
CNY Public Smartcoins: Mode A - 1 cent transfers
TCNY Privatized Smartcoins: Mode A - 1 cent transfers
USD /Eur Public Smartcoins: Mode B or C - 1% or 20 cent transfers, 1 cent for members
BitCash Privatized Smartcoins: Mode B or C - 1% or 20 cent transfers, 1 cent for members
Wallets/Registrars/Referral:
OpenLedger
Moonstone
Lime
Bunker
Transwiser
BitCash
Referral Businesses/Blogs/Affiliates
Can you explain to me what will go wrong in this example? What will businesses be doing to each other rather than focusing on building their own user bases for their business models and target consumer demographic?
-
By selecting mode A means the issuer will get benefit when users referred by other referrers come to use her service, in the meanwhile the referrers will be hurt, unless the issuer white-list her users. This can't satisfy all parties if fee rate not set properly.
What if the issuer of Mode A brings in 1,000,000,000 new users because of low fees and brings new users to pay higher fees for another asset that uses Mode B or C? The network should take just one low fee to sustain itself for maximum network effect. Issuers should have flexibility on pricing, not the committee. The committee should simply determine the network fee. Any UIA, FBA, Privatized Smartcoin issuer should be able to set fees on top of the network fee. Technically an issuer can try to add fees outside of the Bitshares system, but it's much more natural to just add that as a standard feature to the system to attract far more businesses to use the platform.
Issuers don't bring in users by their own alone. When they bring in users, they act as registrars or referrers. In this case, the issuer is able to reimburse the users the extra fees paid by users and split to referral program (actually to the issuer in this case), no matter what fee mode she selected for her product.
More important, if the issuer selected a fee mode which doesn't split fees to referral program, OTHER REGISTRARS/REFERRERS would be not willing to bring users FOR THE ISSUER, even worse, they may try to isolate/hurt the issuer's product since it does nothing good to them but probably get benefit from THEIR user bases. Which means the issuer has to fight alone, even against other parties. Which will do no good to the whole system.
Sure you can think of issuers of assets as a mini-platform for various businesses to use. Bitshares BTS is the broader platform. Wallet/Exchange/Referral businesses can choose any issuer/asset they want. If a wallet or exchange want lower basic fees they can choose an asset with Mode A. If a wallet or exchange wants to have a referral/membership model they can choose an asset with Mode B or C.
It seems that you are trying to save the issuers from themselves rather than give them a choice? If an issuer chooses a fee Mode A that has no referral/membership program and many registrars/referrers don't promote them they will have to find other methods to gain users with outside capital, but they will have an advantage of offering lower basic fees. Why is that a problem especially when a predominant contingent in China want Mode A?
What are your thoughts on Privatized Smartcoins? My thought is that people will naturally want to promote Public Smartcoins instead of a BitCash Privatized Smartcoin or even TCNY so we who issue Privatized Smartcoins are at a disadvantage. Do you want to save us from ourselves? Privatized Smartcoins need to find users by improving parameters, providing liquidity, acquiring different customer segments etc. The positive is that they aren't forced into using particular parameters or price feeds. In the same way they shouldn't be forced into a particular fee Mode or fee schedule especially because their business and customer demographic may be different than other businesses.
As I see it, if we have three modes it may look something like this for Smartcoins:
CNY Public Smartcoins: Mode A - 1 cent transfers
TCNY Privatized Smartcoins: Mode A - 1 cent transfers
USD /Eur Public Smartcoins: Mode B or C - 1% or 20 cent transfers, 1 cent for members
BitCash Privatized Smartcoins: Mode B or C - 1% or 20 cent transfers, 1 cent for members
Wallets/Registrars/Referral:
OpenLedger
Moonstone
Lime
Bunker
Transwiser
BitCash
Referral Businesses/Blogs/Affiliates
Can you explain to me what will go wrong in this example? What will businesses be doing to each other rather than focusing on building their own user bases for their business models and target consumer demographic?
What I've seen, and said again and again:
You keep insist that you'll provide services to "your own users", and build your user base somehow.
You don't think "your own users" will use services provided by others, which will benefit you via referral income.
You don't think users who are brought in BitShares by other referrers will use your services, and you refuse to share profit with the referrers when you gain benefit from these users.
In short, I think you're trying to rob other referrers.
If you still don't understand, sorry, I think I'm unable to reach you.
-
@abit we really need to talk about the definition of 'robbing' which is the act of taking someone elses goods.
Similar to the settlement 'robbing', the rules for businesses are clear, they can share user base or they require ther own users to be referred by your own faucet (which is just stupid IMHO). People using the service will have to pay the fee no matter what and unless they are ltm, they will pay a higher fee. Period.
-
@abit we really need to talk about the definition of 'robbing' which is the act of taking someone elses goods.
Similar to the settlement 'robbing', the rules for businesses are clear, they can share user base or they require ther own users to be referred by your own faucet (which is just stupid IMHO). People using the service will have to pay the fee no matter what and unless they are ltm, they will pay a higher fee. Period.
This is not whole. People referred by this owner can still use services provided by others, and in this case this owner will get referral income. This is unfair imo.
I don't know whether it's good for the system if every (selfish) business force their users to register a new account. At least we'll hopefully seems to have more registered accounts.
-
What's the problem? Every business is free to do as they want. In the end they must follow the protocol. Everyone starts from the same place, everyone has a chance. It's up to each business to decide what they think it's best for them.
If they want to make users register accounts to use their specific services, why not?
Let's not come up with problems where they don't exist please.
-
Its called competition. As long as everyone knows the rules at beginning, its up them to make their product more appealing to users. If lower transfer fees are the most important thing to your user, then the will use yours. You want to lock ppl into your product. Make the best product for them. You will never have all the users. Once you understand that then it becomes clear.
-
Alright, school work done! I decided that I don't have the time or will to enact this evil plan. Also, someone can kill the "lucrative" part of it, so here goes nothing...
How to Monopolize the Referral Business:
Bob wants to monopolize the referral business because he likes making money. He sets up a business that works like the rakeback business in poker [1]. Anyone that signs up under him, he gives X% of the fees back to them that he earns. It costs him very little to set this up. It mostly just costs him the time it takes to program an automated solution. Bob makes it known that if anyone competes with him, he will burn the referral business to the ground by coming over the top of whatever percentage of rakeback they offer until 100%. There is then no incentive to compete with Bob using the same business model, because if you do he will come over the top of your offer- all the way to a 100% rakeback offering. Assuming everyone acts in their own self-interest, they would register for an account with Bob as their referrer because they will save a lot of BTS on the fees. Monopolizing the referral business would not work if someone was motivated enough to kill the referral business outright (see below.)
How to Kill Referral Businesses:
Charlie wants the referral business to die because he thinks the inflated fees are bad for the future of Bitshares. He sets up a business that works like the rakeback business in poker [1]. Anyone that signs up under him, he gives 100% of the fees back to them that he earns. It costs him very little to set this up. It mostly just costs him the time it takes to program an automated solution. Assuming everyone acts in their own self-interest, they would register for an account with Charlie as their referrer because they will save a lot of BTS on the fees. No one can compete with 100% rakeback, and all referral businesses that rely on the referral program for profit would die off.
[1] https://en.wikipedia.org/wiki/Rake_(poker)#Rakeback
-
By selecting mode A means the issuer will get benefit when users referred by other referrers come to use her service, in the meanwhile the referrers will be hurt, unless the issuer white-list her users. This can't satisfy all parties if fee rate not set properly.
What if the issuer of Mode A brings in 1,000,000,000 new users because of low fees and brings new users to pay higher fees for another asset that uses Mode B or C? The network should take just one low fee to sustain itself for maximum network effect. Issuers should have flexibility on pricing, not the committee. The committee should simply determine the network fee. Any UIA, FBA, Privatized Smartcoin issuer should be able to set fees on top of the network fee. Technically an issuer can try to add fees outside of the Bitshares system, but it's much more natural to just add that as a standard feature to the system to attract far more businesses to use the platform.
Issuers don't bring in users by their own alone. When they bring in users, they act as registrars or referrers. In this case, the issuer is able to reimburse the users the extra fees paid by users and split to referral program (actually to the issuer in this case), no matter what fee mode she selected for her product.
More important, if the issuer selected a fee mode which doesn't split fees to referral program, OTHER REGISTRARS/REFERRERS would be not willing to bring users FOR THE ISSUER, even worse, they may try to isolate/hurt the issuer's product since it does nothing good to them but probably get benefit from THEIR user bases. Which means the issuer has to fight alone, even against other parties. Which will do no good to the whole system.
Sure you can think of issuers of assets as a mini-platform for various businesses to use. Bitshares BTS is the broader platform. Wallet/Exchange/Referral businesses can choose any issuer/asset they want. If a wallet or exchange want lower basic fees they can choose an asset with Mode A. If a wallet or exchange wants to have a referral/membership model they can choose an asset with Mode B or C.
It seems that you are trying to save the issuers from themselves rather than give them a choice? If an issuer chooses a fee Mode A that has no referral/membership program and many registrars/referrers don't promote them they will have to find other methods to gain users with outside capital, but they will have an advantage of offering lower basic fees. Why is that a problem especially when a predominant contingent in China want Mode A?
What are your thoughts on Privatized Smartcoins? My thought is that people will naturally want to promote Public Smartcoins instead of a BitCash Privatized Smartcoin or even TCNY so we who issue Privatized Smartcoins are at a disadvantage. Do you want to save us from ourselves? Privatized Smartcoins need to find users by improving parameters, providing liquidity, acquiring different customer segments etc. The positive is that they aren't forced into using particular parameters or price feeds. In the same way they shouldn't be forced into a particular fee Mode or fee schedule especially because their business and customer demographic may be different than other businesses.
As I see it, if we have three modes it may look something like this for Smartcoins:
CNY Public Smartcoins: Mode A - 1 cent transfers
TCNY Privatized Smartcoins: Mode A - 1 cent transfers
USD /Eur Public Smartcoins: Mode B or C - 1% or 20 cent transfers, 1 cent for members
BitCash Privatized Smartcoins: Mode B or C - 1% or 20 cent transfers, 1 cent for members
Wallets/Registrars/Referral:
OpenLedger
Moonstone
Lime
Bunker
Transwiser
BitCash
Referral Businesses/Blogs/Affiliates
Can you explain to me what will go wrong in this example? What will businesses be doing to each other rather than focusing on building their own user bases for their business models and target consumer demographic?
What I've seen, and said again and again:
You keep insist that you'll provide services to "your own users", and build your user base somehow.
You don't think "your own users" will use services provided by others, which will benefit you via referral income.
You don't think users who are brought in BitShares by other referrers will use your services, and you refuse to share profit with the referrers when you gain benefit from these users.
In short, I think you're trying to rob other referrers.
If you still don't understand, sorry, I think I'm unable to reach you.
1. You think I'm trying to rob other referrers when I'm trying to utilize the same referral program as everyone else? First off that's offensive. Secondly, it's illogical. What do you mean refuse to share profits? The referral program is by definition sharing profits.
2. The referral income goes to any registrar/referrer that brings in users for assets that use Mode B or C. It can be any business that set's up a registrar. You can do it. Anyone can do it. Otherwise you can use Openledger or any other registrar and just be a referrer. Furthermore someone who brings in a user for an asset that uses Mode A benefits the entire network. Someone who brings a new user for an asset that uses Mode B or C benefits the system. Businesses that bring the most users to the system provide arguably the most benefit. If I had a popular blogging business and wanted to earn referrals I'd write about a particular asset or application that I thought was valuable and partner with any of the registrars. Would the blog be somehow 'robbing' other asset issuers by bringing new users to a particular application/asset just because these new users might use other applications in the future? If you are building an application or FBA on Bitshares there will and should be an extra fee to use the service anyways. The Bitshares platform benefits the most from the network effect. It sets the network fees and can raise them anytime in the future.
3. The Chinese community seems to want lower basic fees so providing a Mode A seems to me a good idea.
-
I apologize if I've ever been offensive.
By saying "refuse to share", I mean if you apply plan A for your product, which obviously doesn't share anything to referral program.
-
I apologize if I've ever been offensive.
By saying "refuse to share", I mean if you apply plan A for your product, which obviously doesn't share anything to referral program.
No problem. There are a lot of nuances to these fee designs so it probably can lead to misunderstandings of motivations. The only reason why I advocate Mode A is for the Chinese community. Who knows it may lead to higher growth there.
We however plan to fully use the referral program in Mode B. We were planning for a long time to offer 100% of referral income to LTMs & affiliates in the Bitshares network for the first year and probably longer. It's not for the reasons mentioned above by Coinhoarder, but the number of users is more important to us than the referral income. As a wallet/registrar we have to pay for operating costs and maintain a good customer experience. We won't have to offer 100% because we plan to bring a better user experience, but user growth is more important at this stage so we are passing referral income along. I like the idea of supercharging the referral program. We'll earn money with our direct referrals, but anyone else can be a referrer in our network and earn 100%. I think Bitshares should operate the same way and focus on getting a network effect of users.
-
@abit we really need to talk about the definition of 'robbing' which is the act of taking someone elses goods.
Similar to the settlement 'robbing', the rules for businesses are clear, they can share user base or they require ther own users to be referred by your own faucet (which is just stupid IMHO). People using the service will have to pay the fee no matter what and unless they are ltm, they will pay a higher fee. Period.
This is not whole. People referred by this owner can still use services provided by others, and in this case this owner will get referral income. This is unfair imo.
I don't know whether it's good for the system if every (selfish) business force their users to register a new account. At least we'll hopefully seems to have more registered accounts.
a service provider can actually prevent that and only allow access by users that have the correct registrar in their account details!
-
Update:
2016-02-12 Implemented a new operation, so the committee can change some options of the core asset (BTS), including:
* percentage market fee / market fee cap
* transfer fee mode
OP updated accordingly.
If you want this feature, please vote for the worker "1.14.29 [BSIP10] Percentage-based transfer fee solution based on CER". Thanks.
-
2016-03-01 Update:
* Code is re-branched to be based on develop branch, operation_ids changed.
* Code is deeply refactored, parameter names of fee schedule changed.
* Links in OP updated.
* Added "API changes" section into OP
-
Added "impacts to 3rd-party applications" section in OP.
-
So just to confirm. With %-based fees regular users will pay up to the maximum fee for transfers and lifetime members will always pay the minimum fee correct?
Also how will the no-fee/rate-limiting feature effect this proposal? I assume Smartcoin fee structures remain the same after rate-limiting is implemented. What is the expectation for fees for bitCNY and bitUSD/bitEUR?
Also does it make sense to have more than one option for % fees that the committee can decide on (ie. higher fee & lower fee options)?
-
So just to confirm. With %-based fees regular users will pay up to the maximum fee for transfers and lifetime members will always pay the minimum fee correct?
Correct. Note that lifetime members still need to pay up to the maximum fee, but the amount above minimum fee will be returned via cash-back.
Also how will the no-fee/rate-limiting feature effect this proposal? I assume Smartcoin fee structures remain the same after rate-limiting is implemented. What is the expectation for fees for bitCNY and bitUSD/bitEUR?
I think the fee structure would change a bit after that. Anyway it would be decided by the committee (read: stake holders).
Also does it make sense to have more than one option for % fees that the committee can decide on (ie. higher fee & lower fee options)?
It's additional feature which requires more development. I'm glad if it make sense to you.