hip317

hip-0317.md

@@ -0,0 +1,136 @@
+```
+  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>`_