From e69ee79d9a6f21447a42ccdb8414b8e380db24c6 Mon Sep 17 00:00:00 2001 From: Duke Date: Wed, 7 Jun 2023 22:45:21 -0400 Subject: [PATCH] hip317 --- hip-0317.md | 136 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 hip-0317.md diff --git a/hip-0317.md b/hip-0317.md new file mode 100644 index 0000000..321d1cf --- /dev/null +++ b/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 `_