Duke
11 months ago
1 changed files with 136 additions and 0 deletions
@ -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>`_ |
Loading…
Reference in new issue