CHIP-0003: Minimum Transaction Fee

CHIPs/chip-0003.md

@@ -0,0 +1,174 @@
+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
+Status        | Draft
+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 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
+
+### Challenges
+This CHIP is an attempt to solve two limitations with the full node's current design:
+
+* **Challenge 1:** 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
+  * Users who wish to send non-dust transactions often don't know how big of a fee to include. If they don't add a fee, their transaction might require an hour or more to be accepted. If they include a large fee, their transaction will be accepted quickly, but the fee might have been orders of magnitude higher than it needed to be
+
+* **Challenge 2:** In the medium term, as Chia's network grows in popularity, transaction fee pressure is expected to mount. This will naturally result in a minimum fee to use the network. If this CHIP has not been implemented by that point, then zero-fee transactions could get stuck in the mempool indefinitely
+
+### 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 `181 818` 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 1 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 1 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
+    * **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 `250 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 2 million mojos per payment, which equates to $0.000078 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**: 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
+
+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 `12 000` 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 pseudonyomous. 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 `181 818` mojos per million cost so that the average fee of a vanilla transaction with one input and one output would be 1 million mojos ($0.000039 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).
+
+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 * `1 000 000` mojos fee per tx = `3 322 000 000 000`
+* Mojos per XCH = 1 trillion (`1 000 000 000 000`)
+* XCH required to dust the network per day = `3.322` ($129.56 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 `1 000 000` mojo minimum fee = `(1 000 000 / 5 500 000) * 1 000 000` = `181 818`
+
+We can also estimate the fees required for pools to pay their customers. The transactions would likely require two outputs (one coin for the receiver and one for "change"), so the CLVM cost would be higher than what was calculated above. We can use a conservative estimate of 1000 transactions per block.
+
+* CLVM cost per transaction (conservative) = `11 000 000 000 / 1000` = `11 000 000`
+* Transaction fee, in mojos = `(11 000 000 * 181 818) / 1 000 000` = `1 999 998` or around 2 million mojos. This equates to $0.000078 at the current exchange rate of $39 per XCH. We feel that this price should be sufficiently low to allow pools to continue operating as they have in the past
+
+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 4 million mojos per payout
+
+If the faucet is funded with 1 XCH, then it could make `1 000 000 000 000 / 4 000 000` = `250 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 `181 818` mojos per million CLVM cost. This will be configurable by farmers. The default value will result in a minimum fee of around 1 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/).

chip-template.md

@@ -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.