Use Dynamic Fee for More than Just attach (?)

[adamkrellenstein]

When Counterparty was first created, the XCP fees for various transactions were hard-coded to low, constant values (e.g. 0.5 XCP for issuing a named asset). This system was chosen for its simplicity, but it creates significant friction when onboarding users to the Counterparty ecosystem (esp. since it is so hard to acquire XCP) and yet the fees are so low that they have little economic significance for market participants. It doesn't create meaningful demand for XCP; it's just a PITA.

A proper XCP fee system should be proportional to network traffic and transaction complexity while reducing unnecessary barriers to entry into the network. When transaction volumes are low, the fee should be exactly zero; when they're high, they should go up quickly. This should simultaneously reduce the barriers to entry into Counterparty and increase long-term demand for XCP.

We've already implemented such a system for attach transactions—it's described here: https://docs.counterparty.io/docs/advanced/specifications/gas-system/ This issue is a proposal to use the above gas system not just for attach transactions but also for named asset issuances, etc.

[droplister]

Has the gas system for attach risen to a level that has trigged the gas system? I would like to see it work in action there first. But I like the idea of transitioning XCP from a sort of registration fee for assets to a gas for transactions.

Is the long term goal to put a dynamic gas fee on all transactions? I think that would be preferrable to having a mixture of flat fees (asset issuance), "per row" fees (dividends, sweeps), and dynamic fees (attach).

In that case, you could have a single gas fee endpoint and you could introduce to the gas system a complexity factor that's like 1 for basic actions like sends, attach, and 10 or something for dividends and sweeps (if you wanted to make dividends and sweeps cost calculations simpler while still being higher than basic actions.) There's merit to continuing to use the # of holders or # of assets in those calculations still, just an idea.

[adamkrellenstein]

No, it's not at that level. But we have tested the algorithm extensively, and we can test it more. This is not that big of a change. It's still a "registration fee" in the case of asset issuances—it's just dynamic.

The issue is that the current fee system is a major barrier to entry into the Counterparty ecosystem right now, while simultaneously being too low for it to be economically meaningful. A dynamic system is probably better for most existing Counterparty transactions. And the implementation is already parameterized so that different transactions can have different base fees, different scaling rates, etc. etc. to map to "complexity".

[droplister]

Sounds based.