4.4 KiB
HIP: 317
Title: Proportional Transfer Fee Mechanism
Owners: fekt, duke
Credits:
Status: Proposed
Category:
Obsoletes:
Created: 2023-06-07
License: GPLv3
Terminology
The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119. [#RFC2119]_
The term "conventional transaction fee" in this document is in reference to the value of a transaction fee that is conventionally used by wallets, and that a user can reasonably expect miners on the Hush network to accept for including a transaction in a block.
Abstract
The goal of this HIP is to change the conventional fees for transactions by making them dependent on the number of inputs and outputs in a transaction.
Motivation
In light of recent spam attacks on various networks it is time to change the default transaction fee.
The objective of the new fee policy, once it is enforced, is for fees paid by transactions to fairly reflect the processing costs that their inputs and outputs impose on the network. This will discourage denial of service and spam attacks while still allowing low fees for the average user of Hush and Hush Smart Chains.
Requirements
- The conventional fee formula should discriminate against average transactions made by the average user.
- The fee for a transaction should scale linearly with the sum of inputs and outputs.
- Users should not be penalized for sending transactions constructed with padding of inputs and outputs to reduce information leakage.
- Users should be able to spend a small number of UTXOs or zUTXOS with value below the marginal fee per input.
Specification
Wallets implementing this specification SHOULD use a conventional fee calculated in puposhis per the following formula:
TBD
nSpendsSapling number the number of Sapling spends
nOutputsSapling number the number of Sapling outputs
It is not a consensus requirement that fees follow this formula; however, wallets SHOULD create transactions that pay this fee, in order to reduce information leakage, unless overridden by the user.
Marginal Fee
...
Transaction relaying
Hush and Hush Smart Chain full nodes implement fee-based restrictions on relaying of mempool transactions. Nodes that normally relay transactions are expected to do so for transactions that pay at least the conventional fee as specified in this HIP, unless there are other reasons not to do so for robustness or denial-of-service mitigation.
Block production
Miners, mining pools, and other block producers, select transactions for
inclusion in blocks using a variety of criteria. The algorithm in the
following section is planned to be implemented by hushd .
Recommended algorithm for block template construction
...
Rationale for block template construction algorithm
...
Miners have an incentive to make this change because:
- it will tend to increase the fees they are due;
- fees will act as a damping factor on the time needed to process blocks, and therefore on orphan rate.
Denial of Service
A transaction-rate-based denial of service attack occurs when an attacker generates enough transactions over a window of time to prevent legitimate transactions from being mined, or to hinder syncing blocks for full nodes or miners.
There are two primary protections to this kind of attack in Hush: the block size limit, and transaction fees. The block size limit ensures that full nodes and miners can keep up with the blockchain even if blocks are completely full. However, users sending legitimate transactions may not have their transactions confirmed in a timely manner.
This proposal does not alter how fees are paid from transactions to miners.
Deployment
Wallets SHOULD deploy these changes immediately.
Nodes supporting block template construction SHOULD deploy the new
Recommended algorithm for block template construction_ immediately,
and miners SHOULD use nodes that have been upgraded to this algorithm.
Node developers SHOULD coordinate on schedules for deploying restrictions to their policies for transaction mempool acceptance and peer-to-peer relaying. These policy changes SHOULD NOT be deployed before the changes to block template construction for miners described in the preceding paragraph.
Deployment in hushd
TBD
References
.. [#RFC2119] RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>_