Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CHIP-0003: Minimum Transaction Fee #13

Closed
wants to merge 6 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
167 changes: 167 additions & 0 deletions CHIPs/chip-0003.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,167 @@
CHIP Number | 0003
:-------------|:----
Title | Minimum Transaction Fee
Description | A method to add a minimum fee to Chia's full nodes
Author | [Dan Perry](https://github.com/danieljperry)
Comments-URI | [https://github.com/Chia-Network/chips/pull/13](https://github.com/Chia-Network/chips/pull/13)
Status | Stagnant
Category | Process
Sub-Category | Environment
Created | 2022-05-11
Requires | None
Replaces | None
Superseded-By | none

## Abstract
This CHIP will add a minimum, adjustable fee to the design of Chia's full node. The full nodes that choose to implement this feature will ignore any transactions in the mempool which do not meet a minimum fee threshold.

## Motivation
Some background:

When a user submits a transaction on Chia's blockchain, the transaction gets propagated across the network and added to the [mempool](https://docs.chia.net/docs/06mempool/mempool "Chia's mempool documentation") of each full node that receives it. When a farmer finds a winning proof for a transaction block, the farmer's full node chooses which transactions to add to the new block. Priority is given to the transactions with the highest fees (measured in mojos per [CLVM cost](https://chialisp.com/docs/ref/clvm#costs "Explanation of CLVM costs")).

A few notes on the full node's current implementation:

* There is no minimum fee to use Chia's blockchain, so farmers will automatically accept all incoming transactions, as long as their mempool isn't full
* The mempool's maximum capacity is ten full blocks, or around `20 000` [vanilla transactions](https://chialisp.com/docs/standard_transaction "The standard transaction in Chia")
* If a farmer's mempool is full, then that farmer's full node has two options for how to treat incoming transactions:
1. If the incoming transaction's fee is higher than that of the lowest priority transaction currently in the mempool, then the new transaction will be added to the mempool, prioritized by mojos per cost. This transaction will also be propagated to each of the node's peers. The lowest priority transaction(s) will be removed from the mempool
2. If the incoming transaction's fee is not higher than that of the lowest priority transaction currently in the mempool, then the new transaction will be ignored

### Challenge
This CHIP is an attempt to solve a limitation with the full node's current design. The fact that there is no minimum fee makes Chia's blockchain susceptible to dust storms, where a user spends many coins worth as little as one mojo (often referred to as "dust"). This is not considered an attack on Chia's network because the "dust stormer" is using the network within the bounds of its design. However, this _is_ an attack on individual users:

Several users' wallets have become filled with thousands of dust coins. These coins have almost no value -- even a million mojos is worth significantly less than one US cent. Such wallets have long transaction histories, which slows syncing and makes record-keeping cumbersome

### Solution
This CHIP will solve these problems by adding an adjustable fee to the full node's default config. This fee's default value will be `1 818 182` mojos per million cost. This will be the minimum amount required for the full node to route transactions to the mempool.

The resulting fee will be around 10 million mojos for a one-input, one-output transaction. This specific amount was chosen to make it costly to spam the network with dust transactions, while still being cheap enough to support pools and faucets. It will also prepare the network for a future with significantly more non-dust usage.

### Benefits
* Dust stormers will need to pay a fee to use the network. Transactions of a single mojo will still be allowed, but it will now cost around 10 million mojos for the privilege
* Farmers will receive increased revenue due to a minimum fee being added to transactions

### Drawbacks and Rebuttals
1. **New Users and Faucets**
* **Drawback**: One mojo is required to create a singleton for pooling. New users can acquire _some_ mojos from faucets, but they might not receive a sufficient amount to pay a transaction fee for pool participation
Copy link

@Hadamcik Hadamcik Jun 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great if this minimum fee change also supported X zero-fee transactions per sender address every Y blocks and whitelisting sender address.

  • X per Y would allow people to set up/change DIDs, plotnfts, etc. for free and still prevent dust storms (I'm not sure about performance)
  • whitelisting would allow farmers to support specific senders (like faucets) in their activity without paying a fee

* **Rebuttal**: The minimum fee is sufficiently small to allow faucets to continue operating, even after they increase their payouts to provide a fee for new users. As explained in the [Rationale](#rationale) section, a faucet funded with 1 XCH (currently $39) will be able to make `25 000` payouts to customers. These payouts include the fee required to create a singleton

2. **Pool Operators**
* **Drawback**: Large pools typically send frequent payments to their farmers. If they need to add a fee to each of these payments, they might not be able to justify making them as frequently
* **Rebuttal**: We intentionally set the minimum fee to be quite low. It will cost around 10 million mojos per payment, which equates to $0.00039 at the current exchange rate of $39 per XCH. This should be sufficiently cheap for pools to make regular payments to their customers, even those with small farms

3. **Wallet Developers**
* **Drawback**: Wallet developers will be recommended to update their implementations to take the new minimum fees into account. If this CHIP is accepted and wallets choose not to enforce minimum fees, then users' transactions might not make it into the mempool, leading to end-user frustration
* **Rebuttal**: Transactions that do not include a sufficiently large fee will be rejected immediately. This should limit end-user frustration with wallets that do not enforce a minimum fee. Additionally, even if this CHIP were not implemented, a fee market is expected to emerge on Chia's blockchain in the medium term. Wallets will need to add logic to calculate a minimum fee regardless of the status of this CHIP

4. **Farmers**
* **Drawback**: This CHIP will require a voluntary upgrade on the part of Chia's farmers. Before the upgrade reaches a critical mass of full nodes, zero-fee dust transactions will still get propagated and added to Chia's blockchain, albeit at a slower rate
* **Rebuttal**: It is likely that most farmers will accept the upgrade because it will benefit them financially. Additionally, even before most farmers have upgraded, this CHIP will benefit the network. For example, when farmers with 10% of the netspace have upgraded, 10% of new transaction blocks will no longer contain dust

5. **Developers**
* **Drawback**: Mainnet smart coin development will become more expensive for developers who wish to create thousands of transactions as part of their testing cycle.
* **Rebuttal**: At the current price of $39 per XCH, developers will be able to send over `1200` vanilla transactions for $1. Additionally, developers will still be able to use the testnet for free

6. **Dust Stormers**
* **Drawback**: As this CHIP is optional for each node, dust stormers will still be able to add zero-fee transactions
* **Rebuttal**: After this CHIP gains widespread adoption, dust stormers will only be able to dust blocks that they, themselves farm. This will increase their barrier to entry and decrease their impact. For example, a farmer would require 1% of the netspace in order to dust 1% of the blocks

7. **End Users**
* **Drawback**: If the minimum fee is configurable at the full-node level, then some farmers may intentionally set the fee to be higher than the recommended level. The reasons they might do this include:
* Greed -- farmers may see an opportunity to make more money by requiring higher fees. This is especially true when the block rewards are significantly smaller than they are now, and/or if the mempool becomes congested frequently. This would effectively lead to a "bribe or be censored" mentality from farmers
* Caution -- some farmers running minimum-spec hardware might want to minimize their chances of falling out of sync, and consequently only accept transactions with very high fees
* **Rebuttal**: When farmers are able to set higher fees, it's a sign of free-market price discovery in action. Farmers will be able to decide how much their effort is worth. If they set a minimum fee that nobody is willing to pay, they'll lose out on the rewards. This will result in the emergence of a natural fee market

### Feasibility
This CHIP will require changes to the full node and wallet implementations, with varying amounts of work required for each:

* **Full Node:**
1. Full nodes that implement this CHIP will calculate the required minimum fee by multiplying the CLVM cost of each transaction by a constant
2. If the included fee is greater than or equal to the minimum fee, then the full node will attempt to add the transaction to the mempool and propagate the transaction to its peers
3. If the included fee is less than the minimum fee, then the full node will ignore the transaction

* **Wallet:**
1. Wallets that choose to implement this CHIP will calculate the minimum fee using the same algorithm used by the full nodes. Wallets will use this information to block users from creating transactions that do not meet this threshold

* **RPCs:** New RPCs will be required for wallets to calculate the exact fee required for each transaction


## Backwards Compatibility
As this CHIP will be optional for farmers and wallets to implement, it will not introduce any backward-incompatible changes. However, end users and farmers who do not upgrade will need to take a few things into consideration:

* **End Users:** For those who choose to run older versions of Chia's wallet, they will need to manually add a sufficiently large fee to their transactions in order for them to be added to the mempool

* **Farmers:** Those who do not upgrade their full nodes will continue to accept the same transactions as they currently do. Before this CHIP gains widespread adoption, zero-fee transactions will be added to their mempools. This bloat could negatively affect the performance of their systems, as they would need to process more transactions to create a block. Additionally, farmers who do not upgrade could create blocks full of zero-fee transactions that would not have been added to the blockchain otherwise. A critical mass of farmers will need to upgrade in order for this CHIP to have the desired effect

### Alternative proposals
The first alternative proposal we considered was to add an adjustable fee, with a default value of `0`, to the full node's default config. Not only did we accept this proposal, but for several reasons, we decided to add it _prior_ to implementing this CHIP:
* This change is non-controversial because of the default fee of `0`. If users do not change this setting, their full node's functionality will not be affected
* This change will allow farmers to control the minimum transaction fee they are willing to accept for blocks that they farm
* This change will be a stepping stone toward developing a fee market for Chia's ecosystem

We also considered -- and rejected -- several alternative methods to mitigate the problems laid out at the beginning of this CHIP:

1. Do nothing. This would maintain the status quo and avoid the aforementioned drawbacks, but we feel the benefits of this CHIP still make it worth implementing

2. Censor the dust stormer. This proposal was a non-starter. Censorship is technically infeasible for two reasons: Chia's blockchain is decentralized, and its users are pseudonymous. Even if censorship were feasible, it would be anathema to the ethos of Chia's blockchain. Additionally, it would break the Sybil-resistance guarantees of Chia's protocols

3. Reduce the block size until the network gains more usage. The benefit of doing this would have been to force fee pressure quicker than it would have happened with the network's current block size. However, this would have come with the significant drawback of slower TPS for the whole network. Therefore, this idea was rejected outright

We also considered implementing a simplified version of the proposals laid out in this CHIP:

4. Do not make any changes to the full node's config. Instead, design a wallet to reject fees below a hard-coded number. The UX for this idea would have been bad. The wallet would not know the exact fee needed, so the hard-coded number would have been set artificially high. In addition, if there were significant fee pressure, the hard-coded fee would have been too small, resulting in the transaction being ignored altogether


## Rationale
We have chosen our design in order to maximize on user transparency and control. This CHIP, as proposed, will allow users to:
* Ascertain the minimum fee based on the CLVM cost of their specific transaction
* Minimize the chances that their transactions are ignored or rejected by full nodes
* Minimize the chances of their wallet getting dusted

We chose a fee of `1 818 182` mojos per million cost so that the average fee of a vanilla transaction with one input and one output would be 10 million mojos ($0.00039 at the current exchange rate of $39 per XCH). Chia's documentation has more info on [CLVM cost](https://chialisp.com/docs/ref/clvm#costs).

This price applies to many different types of transaction, including pool payouts. This is because pool payouts are batched, so they only contain one output per user. We feel that this price should be sufficiently low to allow pools to continue operating as they have in the past.

Here is the logic used to calculate this fee:

* Number of seconds in a day = 24 hours * 60 minutes * 60 seconds = `86 400`
* Time between transaction blocks on Chia's blockchain = [52 seconds](https://docs.chia.net/docs/03consensus/foliage#transaction-block-time)
* Number of transaction blocks per day = `86 400 / 52` = `1661` (rounded)
* Maximum number of 1-input, 1-output vanilla transactions in a full block = `2000`
* Maximum number of vanilla transactions per day = `1661 * 2000` = `3 322 000`
* Mojos required to dust the network per day = `3 322 000` tx * `10 000 000` mojos fee per tx = `33 220 000 000 000`
* Mojos per XCH = 1 trillion (`1 000 000 000 000`)
* XCH required to dust the network per day = `33.22` ($1295.58 at the current exchange rate of $39 per XCH). This assumes the duster already has a sufficient supply of dust coins, so there would be no need to break apart any large coins

We feel that this would be a sufficiently high price to discourage dust. The minimum fee, in mojos per million cost, is then calculated as follows:
* Maximum CLVM cost per block = `11 000 000 000`
* Typical CLVM cost per 1-input, 1-output vanilla transaction = `11 000 000 000 / 2000` = `5 500 000`
* Mojos per million cost required to achieve a `10 000 000` mojo minimum fee = `(10 000 000 / 5 500 000) * 1 000 000` = `1 818 182`

Finally, we can estimate the number of payouts a faucet would be capable of delivering. We'll assume the faucet will pay a minimum fee to send money. It will also need to pay out enough money for another fee, for example to create a plotnft. This would require around 40 million mojos per payout

If the faucet is funded with 1 XCH, then it could make `1 000 000 000 000 / 40 000 000` = `25 000` payouts. We feel that the fee should be a sufficiently small to allow faucets to continue to operate.

## Specification

config.yaml will include a min_fee parameter with a default value of `1 818 182` mojos per million CLVM cost. This will be configurable by farmers. The default value will result in a minimum fee of around 10 million mojos per vanilla transaction with one input and one output.

config.yaml will also include a minimum fee bump, so that transactions cannot enter a full mempool unless the fee is at least <fee bump> higher than the transactions they are replacing.

[Additional details will need to be added later]

## Test Cases
[todo]

## Reference Implementation
[todo]

## Security
[todo]

## Additional Assets
[todo]

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
7 changes: 1 addition & 6 deletions chip-template.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,15 +12,10 @@ Requires | <CHIP number(s), (optional)>
Replaces | <CHIP number, (optional)>
Superseded-By | <CHIP number (only allowed for Obsolete CHIPs)>

This is the template for all CHIPs to use. Please fill it out according to the guidelines laid out in [chip001](/CHIPs/chip-0001.md). The preamble section above must conform to [RFC 822](https://www.ietf.org/rfc/rfc822.txt) standards. All media associated with this CHIP should be added to the `assets/chip-<CHIP>` folder, which you may create after you receive your CHIP number.
This is the template for all CHIPs to use. Please fill it out according to the guidelines laid out in [chip001](/CHIPs/chip-0001.md). All media associated with this CHIP should be added to the `assets/chip-<CHIP>` folder, which you may create after you receive your CHIP number.

Copy and rename the template file to `chip-<your name>-<your proposal>`, then submit it as a pull request.

Do not modify the following section (IETF RFC Specification), and be sure to follow the standards it lays out.

## IETF RFC Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [IETF RFC 2119](https://www.rfc-archive.org/getrfc?rfc=2119 "Permanent link to RFC 2119").

## Abstract
Give a single-paragraph description of your proposal. The abstract should stand on its own -- someone who reads it should be able to understand the gist of your proposal without reading anything else.

Expand Down