You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
137 lines
4.4 KiB
137 lines
4.4 KiB
11 months ago
|
```
|
||
|
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>`_
|