New BSIP idea: smartcoin pegged network fees

[grctest]

Hey,

I've not created a BSIP for this topic yet, just gauging interest.

The committee currently changes fees at an insufficient schedule, this causes past applied fees to enforce massive fees when the BTS price increases.

Would it not be better for the committee to agree that a fee should be $0.01 instead of 0.01 BTS (not a specific fee) so that no matter how the BTS prices change the fees will remain static?

This would reduce the workload on the committee, as they would only need to set the fees once in a blue moon.

[ryanRfox]

In the short term, I support the committee making more frequent adjustments to the fee schedules, as changes in the value of the core asset BTS may impact the usage of the platform by end users.

As a long term solution, pegging to USD is a valid option. However, I would prefer to see the required development effort put toward the elimination of fees altogether, by implementing a stake based rate limit. Working implementations of other Graphene-based decedent chains can provide guidance.

[grctest]

In the short term, I support the committee making more frequent adjustments to the fee schedules, as changes in the value of the core asset BTS may impact the usage of the platform by end users.

Can we succeed in increasing the committee fee update frequency? Last I heard they evaluated it once per month, but this was not the case over the last couple months..

As a long term solution, pegging to USD is a valid option. However, I would prefer to see the required development effort put toward the elimination of fees altogether, by implementing a stake based rate limit. Working implementations of other Graphene-based decedent chains can provide guidance.

No fees for a small quantity/frequency of trades sure, but for assets and expensive operations these fees shouldn't be removed. We do need to slowly top up the worker reserve pool over time.

[tbone-bts]

I would argue that implementing rate-limited zero-fee transactions in Bitshares actually doesn't make a lot of sense, mostly because Bitshares should attempt to be profitable, plus we need LTM fees to incentivize referrers. So not all fees can be eliminated anyway. Therefore we still need stable/pegged fees. It is especially important that fees are stabilized in order to create more certainty for businesses building on the platform or considering it.

Until fees are stabilized via pegging, I would strongly suggest lowering purely frictional fees (such as transfer fees and order cancellation fees) to spam prevention levels ASAP. These fees do not add to profitability in any meaningful way and only impede adoption by users and businesses.

[grctest]

Perhaps the only rate-limited zero-fee tx should be market transactions, however I feel that rate-limited zero fee operations are out of scope here - pegging the BTS network fees to bitUSD (or another suitable MPA) would introduce a stable constant cost to using the BTS network (Where as the network is massively overpaying for all operations right now, given the increase of marketcap recently).

[pmconrad]

The biggest problem I see with the OP is that this would mean that the fee required for an operation can (and will) change very frequently. This means it is almost impossible to predict how big the required fee for an operation will be, which will lead to many transactions failing. (This is particularly problematic for operations wrapped in a proposal.)

[tbone-bts]

The biggest problem I see with the OP is that this would mean that the fee required for an operation can (and will) change very frequently. This means it is almost impossible to predict how big the required fee for an operation will be, which will lead to many transactions failing. (This is particularly problematic for operations wrapped in a proposal.)

Don't current fees get looked up in a table before an operation is performed?

[grctest]

The biggest problem I see with the OP is that this would mean that the fee required for an operation can (and will) change very frequently.

Rather than being re-adjusted every block, it could be once per 24hrs, so it wouldn't be so high frequency that it would disrupt your ability to send tx (say the fee changes mid operation).

This means it is almost impossible to predict how big the required fee for an operation will be, which will lead to many transactions failing.

If the frequency of fee change wasn't high, then you'd know that it would always be at a stable fixed rate for a certain period of time. For proposed tx perhaps the fee could be accepted at the rate when the proposal was created? Perhaps also you could pay fees using bitUSD to avoid BTS fee fluctuations?

[bob-ggg]

This is a proposal that could reduce the volatility of the shares. The main contribution is that it avoids overpaying for transactions when the market goes up and, most important, keeps the transaction costs stable when the market goes down. the second point is most important given the impact of revenues on the valuation of the shares. Unpredictable revenues increase the fluctuations of the valuation of the shares and the cost of capital locked in BTS. I would support it.

[VictorFe]

to be able to attract new project that depends on a low margin business plan is important to be able to have fees that are predictable. i would say to do fees based on USD will be a great help to attract more project to the bitshare network.

[VictorFe]

how can we help to make this happen???

[shulthz]

Network fees and Pay-per-block of Witness=Smartcoin/BTS Price
I think this is a good idea.

[ryanRfox]

Please consider this thought exercise:

Given:

• The active Block Producer (BP or witness) knows the state of the target SmartCoin market(s) and order book(s)
• The active BP may order valid, pending market operations to their advantage only within their block
• The active BP has the information available to commit an internal market spot price for the target SmartCoin(s) within their block

Proposed Implementation

• BP(1) calculates and publishes an internal spot market price for target SmartCoin(s) based on the market state after committing all valid market operations for this block
• BP(2) performs existing consensus validation of all operations, then calculates BP(1)'s resulting spot price
• BP2 will build upon BP(1)'s block if in agreement with all existing consensus validation plus the published spot price
• During the maintenance interval BP(n) will:
  • Identify the market spot price from the Last Irreversible Block
  • Calculate and update the applicable fees

Sticky Bits:

• Does the proposed implementation address the requirements of OP?
• Can the calculations be made deterministicly and become part of consensus?
• How much extra data storage required within each block to store the spot price(s)?
• When do new fees take effect?
• How many blocks does the network need to flush the pending transactions containing the legacy fee values before it enforces the new fees?

[tbone-bts]

In order to limit the possibility of manipulation, I think it would make sense to update the fee schedule based on perhaps a 7-day moving average of BTS:USD price (for argument's sake, I'm assuming bitUSD would be the smartcoin of choice).

Also, by requiring a certain minimum % (e.g. 5% or 10%) change in moving average of price before fees will need to be adjusted, the frequency of change can be limited while still ensuring fees never get too out of line with the price.

[TheTaconator]

This is a valuable feature for discussion. This is a valuable feature for discussion. I think that two ideas should be explicitly stated to clarify discussions.

(a) A distinction should be made between (a) in which asset is the fee priced ("pricing asset") (currently BTS in and is proposed to be in bitUSD), versus (b) in which asset will the fee be paid ("paying asset") (e.g. BTS, bitUSD, or another asset called OTHER).

(b) If a fee is paid in the pricing asset (bitUSD), is the fee converted into the core token (BTS) as is currently done when paying a fee in not the core token? Or might the fee remain in bitUSD and thereby avoid conversion into the core token? (If the fee remains in the pricing asset, much complication can be avoided.)

Because there are potentially two challenges: (1) converting between the paying asset (e.g. OTHER) to the pricing asset (e.g. bitUSD), and (2) optionally converting between the pricing asset (e.g. bitUSD) and core asset (BTS).

Side note: Conversion between OTHER and bitUSD
Almost all assets do not have a direct exchange rate between the paying asset (e.g. OTHER) and the pricing asset (e.g. bitUSD). However, an indirect exchange rate (involving two or more exchanges between assets) should always be available by the following two steps: (1) convert OTHER to BTS via the core exchange rate for OTHER, and then (2) convert BTS to bitUSD by whatever approach is ultimately selected for this new feature.

Option A
I have inferred that the current discussion assumes conversion of the paying asset (e.g. OTHER or bitUSD) into the core asset (BTS). This involves tricky timing considerations about how much of the paying asset is required to cover the required fee in terms of the pricing asset.

Pros

• Little (perhaps no) intervention required by asset issuers

Cons

• Tricky to implement correctly and deterministically
• Tricky to keep track of the snapshot of the exchange rate between the paying asset and the pricing asset
• Might involve some computation and data searching to determine the exchange rate

Side note: Current System Behavior
Contrast this with the current system: when someone wishes to pay a BTS fee in, for example, bitUSD, blockchain code uses the Core Exchange Rate (CER) for the paying asset which, in this example, is the bitUSD. This CER is fairly static, can be deterministically determined, and can be quickly used to calculate the amount required in the paying asset.

As possible alternatives to what has currently been discussed, the following options might be helpful for discussion because they might be simpler. All options below can encompass two variants: one in which the paying asset (e.g. OTHER) is ultimately converted into the core asset (BTS), and another in which the paying asset (e.g. OTHER) is converted into the pricing asset (e.g. bitUSD).

Option B
All discussions would be greatly simplified if the paying asset were required to be the same as the pricing asset. For example, if fees are priced in bitUSD, then bitUSD would be required to pay the fee. The logic and timing considerations would be greatly simplified.

Pros

• Simple (except perhaps for the transition to this alternate approach)
• Increase demand for bitUSD which will also drive demand for BTS

Cons

• Less flexible than existing system
• Users of the blockchain would need to hold the pricing asset to complete operations
• Some users will object to using bitUSD for paying fees

Option C
If switching the pricing asset away from the core token, perhaps force all asset issuers to replace the CER with a new " pricing asset exchange rate" (PAER) which, rather than priced against the core token (BTS), is priced against the pricing asset (bitUSD).

Asset issuers would be required to maintain an alternative fee pool that is supplied with the pricing asset (bitUSD) rather than the core asset (BTS).

Pros

• This way logic, deterministic behavior, and speed that is similar to Option A can be re-used.

Cons

• Forcing every single asset to switch to a different "CER" is impractical and undesirable.
• Asset issuers would need to consider an alternative fee pool that is filled with the pricing asset

Option D
If switching the pricing asset away from the core token, enable the option for all asset issuers to define a supplemental "pricing asset exchange rate" (PAER) for the pricing asset which, rather than priced against the core token (BTS), is priced against the pricing asset (bitUSD). Then, the asset issuer can optionally maintain two fee pools.

Pros

• CER remain intact
• The new PAER and asset fee pool avoids the whole trickiness that has been discussed so far
• Logic, deterministic behavior, and speed that is similar to Option A can be re-used

Cons

• Most asset issuers will not define this supplemental exchange rate
• Asset issuers would need to consider an alternative fee pool that is filled with the pricing asset
• If asset issuers fill this supplemental fee pool, the asset issuer now has a burden of updating the PAER to a reasonable value (similar to how they must consider updating the CER)

[bob-ggg]

Among the interesting options listed here, I prefer option B for a few reasons:

1. it provides to businesses a simple and clear way to analyze the transaction costs; for this reason, offering a transaction fee in the currency of the business is a valuable proposition.

2. it increases the demand of bitAssets. This is a positive result for the system.

3. It creates a "peg" in terms of cash flow between the bitshares environment and the external world. As an usual company, these are revenues that are likely to be more stable than those paid in BTS and easier to analyze in terms of discounted cash flow to determine the long-term value of each BTS.

[tbone-bts]

@TheTaconator I really don't think this proposal is to enable paying of fees in bitUSD or anything other than BTS. In fact it's already possible to pay fees in other currencies as long as their fee pools are not empty, right? Either way, that is an entirely separate matter.

The way I understand, this proposal (and what I personally support wholeheartedly), is to very simply peg the BTS fees to some stable and familiar unit of account (I've been using USD as an example).

If I am not mistaken, there is already a working fee schedule that stores fees, set by the committee, denominated in BTS. It seems we simply need an additional "pegged fee schedule" (denominated in a pegging currency, say USD). So the committee would specify all the fees in terms of USD. That USD pegged fee schedule would then be used to periodically update the working BTS fee schedule that already exists....by simply converting the USD fees into BTS fees based on the BTS:USD conversion rate.

[TheTaconator]

@tbone-bts , thanks for that clarification. After thinking through your comments, I think that I now understand how this could work. It could still leave most of the existing fee-calculation process intact, and merely affect the first step in the process where the fee for an operation is initially determined.

This change might get tricky for a proposed operation/transaction where the proposal might take time for it to be signed by all required participants. During that time the BTS-equivalent price might have changed so then there is a question about the price for the operation. However, this might simply be a matter of clearly defining what the fee should be for those situations. (I suggest to use the latest/current BTS-equivalent price at the time that the last required signature is validated.)

[grctest]

@TheTaconator So say a committee RFC proposal is created with a week's duration, and the price fluctuates massively in that time the estimated fee in the proposal could be inaccurate?

Perhaps the fee rate could be locked from the start rate & if the fees were to have decreased you get that reimbursed somehow? Or perhaps using several BTS to cover fees, and getting the excess BTS fees back in vesting?

Paying the fee using bitUSD would evade this issue.

[abitmore]

Although the feature proposed in this ticket is maybe useful, I don't think serious businesses care much about it. At least, I don't know any established business in the ecosystem seriously complained, I didn't know any one turned away simply due to this. IMHO it's better to focus our limited resources on more important things.

[tbone-bts]

@abitmore Unstable fees can break a business model and discourage business development to begin with. There have been many complaints about this. Businesses need stable fees.

[ghost]

No fees actually seem to kill adoption, as was my experience with the Steem internal market. That model used locked up stake which is a MUCH bigger barrier to entry than just getting 1 BTS and using that for fees. The inflation model is also wierd because then the supply will target infinity

[ghost]

If you make the fees denominated in USD/CNY you are essentially "surrendering your sovereignty" as a currency

[grctest]

@arminnaderi I don't agree that pegging fees to a USD/CNY price is 'surrendering sovereignty' as you'd still be paying fees in BTS, they'd just reflect the current price of BTS instead of being offset until manually updated by the committee. If anything, businesses would have a more stable fee reference to go by rather than expecting to sometimes over/under paying fees (when compared to FIAT) given BTS price volatility.

[ghost]

@grctest Maybe I misunderstood you, I thought you meant to say that in the UI the fees will show up as $0.01 for example