From 8b8ddeef89d494092f868d4290610b3b10a053f2 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Sun, 6 Sep 2020 23:19:51 +0200 Subject: [PATCH 01/17] initial version of fees RFC --- text/0000-fix-fees.md | 100 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 text/0000-fix-fees.md diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md new file mode 100644 index 00000000..bbebd4c0 --- /dev/null +++ b/text/0000-fix-fees.md @@ -0,0 +1,100 @@ +- Title: fix-fees +- Authors: [John Tromp](mailto:john.tromp@gmail.com) +- Start date: August 23, 2020 +- RFC PR: Edit if merged: [mimblewimble/grin-rfcs#0000](https://github.com/mimblewimble/grin-rfcs/pull/0000) +- Tracking issue: [Edit if merged with link to tracking github issue] + +--- + +# Summary +[summary]: #summary + +Change Grin's minimum relay fees to be weight proportional and make output creation cost about a Grin-cent. + +# Motivation +[motivation]: #motivation + +The current fee requirements suffer from being somewhat arbitrary, and not miner incentive compatible. +They are not even linear; the fees required for the aggregate of two transactions is not necessarily equal to the sum +of required fees. +The current (and foreseeable) low price of Grin makes spamming the UTXO set rather cheaper than desired. + +# Community-level explanation +[community-level-explanation]: #community-level-explanation + +Grin constrains the size of blocks by a maximum block weight, which is a linear combination of the number of inputs, outputs, and kernels. +When blocks fill up, miners are incentivized to pick transactions in decreasing order of fees per weight. +Ideally then, a transaction that is more preferred by miners, is also more likely to be relayed. +If a transaction A doesn't satisfy the minimum relay fees, while another transaction B does, but miners would rather include A, +then A's publisher will have to transmit it directly to miners, which is undesirable. +We therefore let the minimum relay fee be proportional to the weight of the transaction, minimizing arbitrariness. +We can calibrate the fee system by stipulating that creating one output should cost at least one Grin-cent (formerly 0.4 Grin-cent). +Linearity is another desirable property, which for instance allows the two parties in a payjoin to each pay their own input and output fees, +while splitting the kernel fee. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +The minimum relay fee of a transaction shall be proportional to Transaction::weight\_as\_block, +which uses weights of BLOCK\_INPUT\_WEIGHT = 1, BLOCK\_OUTPUT\_WEIGHT = 21, and BLOCK\_KERNEL\_WEIGHT = 3, +which correspond to the nearest multiple of 32 bytes that it takes to serialize. +Formerly, we used Transaction::weight\_as\_block, +which uses arbitrary weights of -1, 4, and 1 respectively, but also non-linearly rounds negative results up to 0 +(as happens when the number of inputs exceeds the number of kernels plus 4 times the number of outputs). +The Transaction::weight\_as\_block shall be multiplied by a base fee. +This will not be hardcoded, but configurable in grin-server.log. +The already present accept\_fee\_base parameter appears suitable for this, as +there as no reason to use different fees for relay and mempool acceptance. Its +value shall default to GRIN\_BASE / 100 / 20 = 500000, which make each output +incur just over 1 Grin-cent in fees. + +# Drawbacks +[drawbacks]: #drawbacks + +I think there is only a perceived drawback, which is what led to the former fee rules.` +A negative weight on inputs is supposed to encourage spending many outputs, and lead to a reduction in UTXO size. +A positive weight on inputs is not really a drawback however, as long as creation of outputs is more strongly discouraged. +Most wallets, especially those relying on payjoins, do about equal amounts of output creation and spending, +the difference being just the wallet's UTXO set. +Mining pools are the major exception. While they obviously don't incur any fees in coinbase creation, they need not +spend fees on spending them either, as they can mine these payout transactions directly. + +# Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +There are no good alternative to economically significant fees. Any blockchain lacking them is an open invitation to abuse. +For chains with a maximum blocksize, fees are also necessary to allow prioritization of transactions. + + +# Prior art +Several chains have suffered spam attacks. In early days, bitcoin was swamped with feeless wagers on Satoshi Dice [1]. +At least those served some purpose. + +Nano was under a deluge of meaningless 0-value back and forth transfers for weeks, +that added dozens of GB of redundant bloat to its chain data [2]. Although nano requires client PoW as a substitute for fees, +these attacks showed that the PoW was poorly calibrated and not an effective deterrant. + + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + +# Future possibilities +[future-possibilities]: #future-possibilities + +While the input and kernel weights are pretty fixed, the output weight is subject to improvements in range proof technology. +If Grin implements BP+, the weight should go down from 21 to 18. That would make outputs incur slightly less than a Grin-cent in fees, +which is not worth bothering with. If range proofs were to halve in size though, then we might want to double the base fee to compensate. + +In Grin ever becomes worth many dollars, then a lowering of fees is desirable. +This can then be achieved by getting the majority of running nodes to reconfigure their base fee to a lower value, +after which wallets can have their fee computation adjusted. +In the converse case, where Grin becomes worth only a few cents, then an increase in fees might be needed to avoid spam. +Both cases will be much easier to deal with if they coincide with a hard fork, but those may not be on the horizon. + + +# References +[references]: #references + +[1] https://en.bitcoin.it/wiki/Satoshi\_Dice + +[2] https://github.com/nanocurrency/nano-node/issues/1883 From be6c03024d3de9615e9199b423b6ed5f450d2a41 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Sun, 6 Sep 2020 23:52:22 +0200 Subject: [PATCH 02/17] fix typos --- text/0000-fix-fees.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index bbebd4c0..31a1a7f0 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -42,16 +42,16 @@ Formerly, we used Transaction::weight\_as\_block, which uses arbitrary weights of -1, 4, and 1 respectively, but also non-linearly rounds negative results up to 0 (as happens when the number of inputs exceeds the number of kernels plus 4 times the number of outputs). The Transaction::weight\_as\_block shall be multiplied by a base fee. -This will not be hardcoded, but configurable in grin-server.log. +This will not be hardcoded, but configurable in grin-server.toml. The already present accept\_fee\_base parameter appears suitable for this, as -there as no reason to use different fees for relay and mempool acceptance. Its +there is no reason to use different fees for relay and mempool acceptance. Its value shall default to GRIN\_BASE / 100 / 20 = 500000, which make each output incur just over 1 Grin-cent in fees. # Drawbacks [drawbacks]: #drawbacks -I think there is only a perceived drawback, which is what led to the former fee rules.` +I think there is only a perceived drawback, which is what led to the former fee rules. A negative weight on inputs is supposed to encourage spending many outputs, and lead to a reduction in UTXO size. A positive weight on inputs is not really a drawback however, as long as creation of outputs is more strongly discouraged. Most wallets, especially those relying on payjoins, do about equal amounts of output creation and spending, From 7dd921d37a46f258fef33ae26e76e5bbc8547310 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Mon, 7 Sep 2020 00:00:29 +0200 Subject: [PATCH 03/17] fix more typos --- text/0000-fix-fees.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index 31a1a7f0..c9b61f3b 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -85,7 +85,7 @@ While the input and kernel weights are pretty fixed, the output weight is subjec If Grin implements BP+, the weight should go down from 21 to 18. That would make outputs incur slightly less than a Grin-cent in fees, which is not worth bothering with. If range proofs were to halve in size though, then we might want to double the base fee to compensate. -In Grin ever becomes worth many dollars, then a lowering of fees is desirable. +If Grin ever becomes worth many dollars, then a lowering of fees is desirable. This can then be achieved by getting the majority of running nodes to reconfigure their base fee to a lower value, after which wallets can have their fee computation adjusted. In the converse case, where Grin becomes worth only a few cents, then an increase in fees might be needed to avoid spam. @@ -95,6 +95,6 @@ Both cases will be much easier to deal with if they coincide with a hard fork, b # References [references]: #references -[1] https://en.bitcoin.it/wiki/Satoshi\_Dice +[1] [Satoshi Dice](https://en.bitcoin.it/wiki/Satoshi_Dice) -[2] https://github.com/nanocurrency/nano-node/issues/1883 +[2] [Nano github](https://github.com/nanocurrency/nano-node/issues/1883) From b42982a433aa84ad6e971ae9597139cbd69b36b3 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Mon, 7 Sep 2020 11:48:35 +0200 Subject: [PATCH 04/17] fix function name --- text/0000-fix-fees.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index c9b61f3b..9a1bd20a 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -38,7 +38,7 @@ while splitting the kernel fee. The minimum relay fee of a transaction shall be proportional to Transaction::weight\_as\_block, which uses weights of BLOCK\_INPUT\_WEIGHT = 1, BLOCK\_OUTPUT\_WEIGHT = 21, and BLOCK\_KERNEL\_WEIGHT = 3, which correspond to the nearest multiple of 32 bytes that it takes to serialize. -Formerly, we used Transaction::weight\_as\_block, +Formerly, we used Transaction::weight, which uses arbitrary weights of -1, 4, and 1 respectively, but also non-linearly rounds negative results up to 0 (as happens when the number of inputs exceeds the number of kernels plus 4 times the number of outputs). The Transaction::weight\_as\_block shall be multiplied by a base fee. From 174b899822178cdb277ef6b78ce95180bf09a075 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Wed, 9 Sep 2020 11:09:53 +0200 Subject: [PATCH 05/17] add activation heights --- text/0000-fix-fees.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index 9a1bd20a..e58ffab4 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -27,7 +27,7 @@ When blocks fill up, miners are incentivized to pick transactions in decreasing Ideally then, a transaction that is more preferred by miners, is also more likely to be relayed. If a transaction A doesn't satisfy the minimum relay fees, while another transaction B does, but miners would rather include A, then A's publisher will have to transmit it directly to miners, which is undesirable. -We therefore let the minimum relay fee be proportional to the weight of the transaction, minimizing arbitrariness. +We therefore want the minimum relay fee be proportional to the weight of the transaction, minimizing arbitrariness. We can calibrate the fee system by stipulating that creating one output should cost at least one Grin-cent (formerly 0.4 Grin-cent). Linearity is another desirable property, which for instance allows the two parties in a payjoin to each pay their own input and output fees, while splitting the kernel fee. @@ -47,6 +47,7 @@ The already present accept\_fee\_base parameter appears suitable for this, as there is no reason to use different fees for relay and mempool acceptance. Its value shall default to GRIN\_BASE / 100 / 20 = 500000, which make each output incur just over 1 Grin-cent in fees. +The new tx relay rules and new fee computation in wallets shall take effect at the HF4 block height of 1048320 (but see below about alternatives for 3rd party wallets). # Drawbacks [drawbacks]: #drawbacks @@ -65,6 +66,7 @@ spend fees on spending them either, as they can mine these payout transactions d There are no good alternative to economically significant fees. Any blockchain lacking them is an open invitation to abuse. For chains with a maximum blocksize, fees are also necessary to allow prioritization of transactions. +There is a small window prior to HF4 where transactions constructed using the former lower won't be finalized before HF4 and will thus fail to be relayed. Third party wallets are free to switch fee computation some arbitrary time before HF4 to minimize this risk. # Prior art Several chains have suffered spam attacks. In early days, bitcoin was swamped with feeless wagers on Satoshi Dice [1]. From 5f2f0cd3fe49068bc0d01ac2da824d149dd79162 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Tue, 15 Sep 2020 22:23:41 +0200 Subject: [PATCH 06/17] add fee priority protection --- text/0000-fix-fees.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index e58ffab4..ad769c3b 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -10,6 +10,7 @@ [summary]: #summary Change Grin's minimum relay fees to be weight proportional and make output creation cost about a Grin-cent. +Use least significant bits in fee to specify desired tx priority. # Motivation [motivation]: #motivation @@ -18,6 +19,7 @@ The current fee requirements suffer from being somewhat arbitrary, and not miner They are not even linear; the fees required for the aggregate of two transactions is not necessarily equal to the sum of required fees. The current (and foreseeable) low price of Grin makes spamming the UTXO set rather cheaper than desired. +Fee overpaying for higher priority to be included in full blocks fails when aggregated with minimal fee transactions. # Community-level explanation [community-level-explanation]: #community-level-explanation @@ -31,6 +33,7 @@ We therefore want the minimum relay fee be proportional to the weight of the tra We can calibrate the fee system by stipulating that creating one output should cost at least one Grin-cent (formerly 0.4 Grin-cent). Linearity is another desirable property, which for instance allows the two parties in a payjoin to each pay their own input and output fees, while splitting the kernel fee. +The least significant bits will specify a minimum fee overpayment factor, preventing aggregation with lesser overpaying transactions. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -47,6 +50,11 @@ The already present accept\_fee\_base parameter appears suitable for this, as there is no reason to use different fees for relay and mempool acceptance. Its value shall default to GRIN\_BASE / 100 / 20 = 500000, which make each output incur just over 1 Grin-cent in fees. +We fix some parameter FEE\_FACTOR\_BITS, possibly configured through +grin-server.toml. If the least significant FEE\_FACTOR\_BITS of a fee have +value f, then the total fees of the transaction containining this kernel must +exceed the required minimum by a factor f+1, inclusive. +We recommend a default value of FEE\_FACTOR\_BITS = 10. The new tx relay rules and new fee computation in wallets shall take effect at the HF4 block height of 1048320 (but see below about alternatives for 3rd party wallets). # Drawbacks @@ -68,6 +76,9 @@ For chains with a maximum blocksize, fees are also necessary to allow prioritiza There is a small window prior to HF4 where transactions constructed using the former lower won't be finalized before HF4 and will thus fail to be relayed. Third party wallets are free to switch fee computation some arbitrary time before HF4 to minimize this risk. +The fee factor could have been specified in a new fee field, but that requires a consensus change and takes up more space. + + # Prior art Several chains have suffered spam attacks. In early days, bitcoin was swamped with feeless wagers on Satoshi Dice [1]. At least those served some purpose. From 58121a073c0195f54212509631a9e94e8bb2eabd Mon Sep 17 00:00:00 2001 From: John Tromp Date: Thu, 24 Sep 2020 16:18:37 +0200 Subject: [PATCH 07/17] new template and more on consensus change option --- text/0000-fix-fees.md | 61 ++++++++++++++++++++++++++----------------- 1 file changed, 37 insertions(+), 24 deletions(-) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index ad769c3b..6560430e 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -1,18 +1,18 @@ - Title: fix-fees - Authors: [John Tromp](mailto:john.tromp@gmail.com) - Start date: August 23, 2020 -- RFC PR: Edit if merged: [mimblewimble/grin-rfcs#0000](https://github.com/mimblewimble/grin-rfcs/pull/0000) +- RFC PR: Edit if merged: [mimblewimble/grin-rfcs#0000](https://github.com/mimblewimble/grin-rfcs/pull/0000) - Tracking issue: [Edit if merged with link to tracking github issue] --- -# Summary +## Summary [summary]: #summary Change Grin's minimum relay fees to be weight proportional and make output creation cost about a Grin-cent. Use least significant bits in fee to specify desired tx priority. -# Motivation +## Motivation [motivation]: #motivation The current fee requirements suffer from being somewhat arbitrary, and not miner incentive compatible. @@ -21,7 +21,7 @@ of required fees. The current (and foreseeable) low price of Grin makes spamming the UTXO set rather cheaper than desired. Fee overpaying for higher priority to be included in full blocks fails when aggregated with minimal fee transactions. -# Community-level explanation +## Community-level explanation [community-level-explanation]: #community-level-explanation Grin constrains the size of blocks by a maximum block weight, which is a linear combination of the number of inputs, outputs, and kernels. @@ -35,40 +35,46 @@ Linearity is another desirable property, which for instance allows the two parti while splitting the kernel fee. The least significant bits will specify a minimum fee overpayment factor, preventing aggregation with lesser overpaying transactions. -# Reference-level explanation +## Reference-level explanation [reference-level-explanation]: #reference-level-explanation -The minimum relay fee of a transaction shall be proportional to Transaction::weight\_as\_block, -which uses weights of BLOCK\_INPUT\_WEIGHT = 1, BLOCK\_OUTPUT\_WEIGHT = 21, and BLOCK\_KERNEL\_WEIGHT = 3, +The minimum relay fee of a transaction shall be proportional to `Transaction::weight_as_block`, +which uses weights of `BLOCK_INPUT_WEIGHT` = 1, `BLOCK_OUTPUT_WEIGHT` = 21, and `BLOCK_KERNEL_WEIGHT` = 3, which correspond to the nearest multiple of 32 bytes that it takes to serialize. Formerly, we used Transaction::weight, which uses arbitrary weights of -1, 4, and 1 respectively, but also non-linearly rounds negative results up to 0 (as happens when the number of inputs exceeds the number of kernels plus 4 times the number of outputs). -The Transaction::weight\_as\_block shall be multiplied by a base fee. + +The `Transaction::weight_as_block` shall be multiplied by a base fee. This will not be hardcoded, but configurable in grin-server.toml. -The already present accept\_fee\_base parameter appears suitable for this, as +The already present `accept_fee_base` parameter appears suitable for this, as there is no reason to use different fees for relay and mempool acceptance. Its -value shall default to GRIN\_BASE / 100 / 20 = 500000, which make each output +value shall default to `GRIN_BASE` / 100 / 20 = 500000, which make each output incur just over 1 Grin-cent in fees. -We fix some parameter FEE\_FACTOR\_BITS, possibly configured through -grin-server.toml. If the least significant FEE\_FACTOR\_BITS of a fee have + +We fix some parameter `FEE_FACTOR_BITS`, possibly configured through +grin-server.toml. If the least significant `FEE_FACTOR_BITS` of a fee have value f, then the total fees of the transaction containining this kernel must exceed the required minimum by a factor f+1, inclusive. -We recommend a default value of FEE\_FACTOR\_BITS = 10. -The new tx relay rules and new fee computation in wallets shall take effect at the HF4 block height of 1048320 (but see below about alternatives for 3rd party wallets). +We recommend a default value of `FEE_FACTOR_BITS` = 8. +By linearity, aggregating transactions with the same specified fee factor will preserve + +The new tx relay rules and new fee computation in wallets shall take effect at +the HF4 block height of 1048320 (but see below about alternatives for 3rd party +wallets). -# Drawbacks +## Drawbacks [drawbacks]: #drawbacks -I think there is only a perceived drawback, which is what led to the former fee rules. -A negative weight on inputs is supposed to encourage spending many outputs, and lead to a reduction in UTXO size. +At the time of writing, only a single perceived drawback could be identified, which is what motivated the former fee rules. +A negative weight on inputs was supposed to encourage spending many outputs, and lead to a reduction in UTXO size. A positive weight on inputs is not really a drawback however, as long as creation of outputs is more strongly discouraged. Most wallets, especially those relying on payjoins, do about equal amounts of output creation and spending, the difference being just the wallet's UTXO set. Mining pools are the major exception. While they obviously don't incur any fees in coinbase creation, they need not spend fees on spending them either, as they can mine these payout transactions directly. -# Rationale and alternatives +## Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives There are no good alternative to economically significant fees. Any blockchain lacking them is an open invitation to abuse. @@ -76,10 +82,14 @@ For chains with a maximum blocksize, fees are also necessary to allow prioritiza There is a small window prior to HF4 where transactions constructed using the former lower won't be finalized before HF4 and will thus fail to be relayed. Third party wallets are free to switch fee computation some arbitrary time before HF4 to minimize this risk. -The fee factor could have been specified in a new fee field, but that requires a consensus change and takes up more space. +The fee factor could be specified separately from the fee, but that requires a consensus change, namely masking the fee +to only the least significant 64 - `FEE_FACTOR_BITS`, allowing the +up most significant bits to be used for specifying the fee factor. +The advantage of this separation is that even with higher fee factors, fees can remain a milligrin multiple, +and thus the amounts that users deal with don't need too many digits for fractional grins. +This can be considered a plus for wallet UX. - -# Prior art +## Prior art Several chains have suffered spam attacks. In early days, bitcoin was swamped with feeless wagers on Satoshi Dice [1]. At least those served some purpose. @@ -88,10 +98,10 @@ that added dozens of GB of redundant bloat to its chain data [2]. Although nano these attacks showed that the PoW was poorly calibrated and not an effective deterrant. -# Unresolved questions +## Unresolved questions [unresolved-questions]: #unresolved-questions -# Future possibilities +## Future possibilities [future-possibilities]: #future-possibilities While the input and kernel weights are pretty fixed, the output weight is subject to improvements in range proof technology. @@ -104,8 +114,11 @@ after which wallets can have their fee computation adjusted. In the converse case, where Grin becomes worth only a few cents, then an increase in fees might be needed to avoid spam. Both cases will be much easier to deal with if they coincide with a hard fork, but those may not be on the horizon. +If we go with the alternative of a consensus changing fee mask, then this sets a precedent for stealing most significant fee bits as a sort of soft-forking mechanism. As long as the next available bits remain inconceivably large for use in fees, we can further reduce the fee mask in future and use the freed up bits for new restrictions. These restrictions can be either within the consensus model, or outside of it in the mempool and relay conventions, such as with this fee factor proposal. +While any fee mask reduction is in principle a hard fork, and the code implementing it may have to be height dependent if enough Grin has been emitted to exceed the mask, as long as no-one is willing to pay such a high fee, the height dependency can be removed later. + -# References +## References [references]: #references [1] [Satoshi Dice](https://en.bitcoin.it/wiki/Satoshi_Dice) From c72f66b828a2c43b5529ec0705d78261f4207946 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Thu, 24 Sep 2020 16:40:48 +0200 Subject: [PATCH 08/17] fix typo --- text/0000-fix-fees.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index 6560430e..3a383ed9 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -84,7 +84,7 @@ There is a small window prior to HF4 where transactions constructed using the fo The fee factor could be specified separately from the fee, but that requires a consensus change, namely masking the fee to only the least significant 64 - `FEE_FACTOR_BITS`, allowing the -up most significant bits to be used for specifying the fee factor. +freed up most significant bits to be used for specifying the fee factor. The advantage of this separation is that even with higher fee factors, fees can remain a milligrin multiple, and thus the amounts that users deal with don't need too many digits for fractional grins. This can be considered a plus for wallet UX. From 0e31499b03026e31c06c769b96777e6559a6f83d Mon Sep 17 00:00:00 2001 From: John Tromp Date: Thu, 24 Sep 2020 16:49:53 +0200 Subject: [PATCH 09/17] fix another typo --- text/0000-fix-fees.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index 3a383ed9..df4a40f6 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -57,7 +57,7 @@ grin-server.toml. If the least significant `FEE_FACTOR_BITS` of a fee have value f, then the total fees of the transaction containining this kernel must exceed the required minimum by a factor f+1, inclusive. We recommend a default value of `FEE_FACTOR_BITS` = 8. -By linearity, aggregating transactions with the same specified fee factor will preserve +By linearity, aggregating transactions with the same specified fee factor will preserve their relay validity. The new tx relay rules and new fee computation in wallets shall take effect at the HF4 block height of 1048320 (but see below about alternatives for 3rd party From 198dbeece8f9594fc31124787652421825ea3dbb Mon Sep 17 00:00:00 2001 From: John Tromp Date: Fri, 25 Sep 2020 00:15:53 +0200 Subject: [PATCH 10/17] rewrite soft-forking paragraph --- text/0000-fix-fees.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index df4a40f6..80552738 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -114,8 +114,15 @@ after which wallets can have their fee computation adjusted. In the converse case, where Grin becomes worth only a few cents, then an increase in fees might be needed to avoid spam. Both cases will be much easier to deal with if they coincide with a hard fork, but those may not be on the horizon. -If we go with the alternative of a consensus changing fee mask, then this sets a precedent for stealing most significant fee bits as a sort of soft-forking mechanism. As long as the next available bits remain inconceivably large for use in fees, we can further reduce the fee mask in future and use the freed up bits for new restrictions. These restrictions can be either within the consensus model, or outside of it in the mempool and relay conventions, such as with this fee factor proposal. -While any fee mask reduction is in principle a hard fork, and the code implementing it may have to be height dependent if enough Grin has been emitted to exceed the mask, as long as no-one is willing to pay such a high fee, the height dependency can be removed later. +If we go with the alternative of a consensus changing fee mask, then this sets +a precedent for stealing other masked out fee bits as a possible soft-forking +mechanism. Suppose we limit fees to 40 bits, giving a maximum possible fee of +2^40 - 1 nanogrin, or approximately 1099.5 grin. (As a side effect, this limits +the damage of fat fingering a manually entered fee amount.) This gives us 64-40 += 24 bits, of which we use `FEE_FACTOR_BITS` bits for fee factor, and leave the +remainder available for future use. +We can imagine a future soft-fork further constraining the validity of kernels, depending on the value of some of these bits. +These restrictions can be either within the consensus model, or outside of it in the mempool and relay conventions, such as with the fee factors in this proposal. ## References From 5f564df5a2d13c1871076512f690a77e5a0b2149 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Sun, 4 Oct 2020 15:03:06 +0200 Subject: [PATCH 11/17] adopt hard-fork option; change fee factor to fee shift --- text/0000-fix-fees.md | 137 ++++++++++++++++++++++++++++-------------- 1 file changed, 92 insertions(+), 45 deletions(-) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index 80552738..cbdac9ee 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -10,30 +10,56 @@ [summary]: #summary Change Grin's minimum relay fees to be weight proportional and make output creation cost about a Grin-cent. -Use least significant bits in fee to specify desired tx priority. +Restrict fees to 40 bits, using 4 of the freed up 24 bits to specify the desired tx priority, +and leaving the remaining 20 bits for future use. +NOTE: this is a hard-forking change. ## Motivation [motivation]: #motivation The current fee requirements suffer from being somewhat arbitrary, and not miner incentive compatible. -They are not even linear; the fees required for the aggregate of two transactions is not necessarily equal to the sum -of required fees. +They are not even linear; to avoid a negative minimum fee, they are rounded up to zero. +As a consequence, the minimum fees for the aggregate of two +transactions is not necessarily equal to the sum of the individual ones. +Worse, a miner has no incentive to include a transaction that pays 0 fees, while they take resources to relay. The current (and foreseeable) low price of Grin makes spamming the UTXO set rather cheaper than desired. -Fee overpaying for higher priority to be included in full blocks fails when aggregated with minimal fee transactions. +Fee overpaying, for higher priority to be included in full blocks. fails when aggregated with minimal fee transactions. ## Community-level explanation [community-level-explanation]: #community-level-explanation -Grin constrains the size of blocks by a maximum block weight, which is a linear combination of the number of inputs, outputs, and kernels. -When blocks fill up, miners are incentivized to pick transactions in decreasing order of fees per weight. -Ideally then, a transaction that is more preferred by miners, is also more likely to be relayed. -If a transaction A doesn't satisfy the minimum relay fees, while another transaction B does, but miners would rather include A, -then A's publisher will have to transmit it directly to miners, which is undesirable. -We therefore want the minimum relay fee be proportional to the weight of the transaction, minimizing arbitrariness. -We can calibrate the fee system by stipulating that creating one output should cost at least one Grin-cent (formerly 0.4 Grin-cent). -Linearity is another desirable property, which for instance allows the two parties in a payjoin to each pay their own input and output fees, -while splitting the kernel fee. -The least significant bits will specify a minimum fee overpayment factor, preventing aggregation with lesser overpaying transactions. +For clarity, let's adopt define the following definitions. Let the `feerate' of +a transaction be the fees paid by the transaction divided by the transaction +weight with regards to block inclusion (`Transaction::weight_as_block`). +Let the `minfee' of a transaction be the amount of fees required for relay and mempool inclusion. +A transaction paying at least `minfee' in fees is said to be relayable. + +Grin constrains the size of blocks by a maximum block weight, which is a linear +combination of the number of inputs, outputs, and kernels. When blocks fill +up, miners are incentivized to pick transactions in decreasing order of feerate. +Ideally then, higher feerate transactions are more relayable than lower feerate ones. +Having a lower feerate transaction be relayable while a higher feerate transaction is not +is very much undesirable and a recipe for problems in a congested network. + +The only way to avoid this mismatch between relay and block inclusion incentives +is to make the minimum relay fee be proportional to the block weight of the +transaction. This leaves only the constant of proportionality to be decided. +We can calibrate the fee system by stipulating that creating one output should +cost at least one Grin-cent (formerly 0.4 Grin-cent). + +We want minfee to be linear to make splitting and combining of fees well-behaved. +For instance, two parties in a payjoin may each want pay their own input and output fees, +while splitting the kernel fee, without overpaying for the whole transaction. + +Only the leat significant 40 bits will be used to specify a fee, while +some of the remaining bits will specify a minimum fee overpayment factor, +preventing aggregation with lesser overpaying transactions, and earlier inclusion into full blocks. + +The largest possible 40-bit fee is 2^40 - 1 nanogrin, or approximately 1099.5 grin, +which should be more than enough to guarantee inclusion in the next available block. +Technically speaking, transactions can pay higher fees by having multiple kernels, +but we still want to avoid that kind of friction. +As a side effect, this limits the damage of fat fingering a manually entered fee amount. ## Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -46,29 +72,52 @@ which uses arbitrary weights of -1, 4, and 1 respectively, but also non-linearly (as happens when the number of inputs exceeds the number of kernels plus 4 times the number of outputs). The `Transaction::weight_as_block` shall be multiplied by a base fee. -This will not be hardcoded, but configurable in grin-server.toml. -The already present `accept_fee_base` parameter appears suitable for this, as -there is no reason to use different fees for relay and mempool acceptance. Its -value shall default to `GRIN_BASE` / 100 / 20 = 500000, which make each output +This will not be hardcoded, but configurable in grin-server.toml, +using the already present `accept_fee_base` parameter. +There is no reason to use different fees for relay and mempool acceptance. +Its value shall default to `GRIN_BASE` / 100 / 20 = 500000, which makes each output incur just over 1 Grin-cent in fees. -We fix some parameter `FEE_FACTOR_BITS`, possibly configured through -grin-server.toml. If the least significant `FEE_FACTOR_BITS` of a fee have -value f, then the total fees of the transaction containining this kernel must -exceed the required minimum by a factor f+1, inclusive. -We recommend a default value of `FEE_FACTOR_BITS` = 8. -By linearity, aggregating transactions with the same specified fee factor will preserve their relay validity. +The 64-bit fee field in kernel types Plain and HeightLocked shall be renamed to `fee_bits' and be composed of bitfields +{ `future_use': 20, `fee_shift': 4, fee: 40 }. All former uses of the fee will use `fee_bits' & `FEE_MASK', +where `FEE_MASK' = 0xffffffffff. + +A nonzero fee shift places an additional restriction on transaction relay and mempool inclusion. +Namely, a transaction containining a kernel with `fee_shift' = s must pay a total fee +of at least 2^s times the minfee (the minfee shifted left by `fee_shift'). + +Aggregation of two relayable transactions should only happen when the result remains relayable. +By linearity, this is always the case for two transactions with identical fee shift. +Transactions with differing fee shift can be aggregated only if either one pays more +than required by their fee shift. + +For instance, suppose two transactions have the same minfee. If one pays 3 times the minfee with a fee shift of 1, +while the other pays exactly minfee with a zero fee shift, +then both can be aggregated into one that pays twice the joint minfee (which is double the old one). + +While a transaction can choose an arbitrarily high feerate to incentivize early inclusion into full blocks, +the fee shift provides for 16 different levels of protection against feerate dilution (through transaction aggregation). The new tx relay rules and new fee computation in wallets shall take effect at -the HF4 block height of 1048320 (but see below about alternatives for 3rd party -wallets). +the HF4 block height of 1048320 (but see below about alternatives for 3rd party wallets). + +The 20 bits of `future_use bits' provide a possible soft-forking mechanism. +We can imagine a future soft-fork further constraining the validity of kernels, +or the relayability of transactions containing them, depending on the value of some of these bits. ## Drawbacks [drawbacks]: #drawbacks -At the time of writing, only a single perceived drawback could be identified, which is what motivated the former fee rules. +Leaving 20 bits of `future_use' increases the amount of zero cost zero friction +spam that can be added to the chain. However, we already have a similar amount +of spammable bits in the lock height of HeightLocked kernels, where any lock +height under the current height of around a million has no effect. +So this appears to be an acceptable increase. + +At the time of writing, only one other perceived drawback could be identified, which is what motivated the former fee rules. A negative weight on inputs was supposed to encourage spending many outputs, and lead to a reduction in UTXO size. -A positive weight on inputs is not really a drawback however, as long as creation of outputs is more strongly discouraged. +But this aligned poorly with miner incentives, as for instance they have no economic reason to include zero fee transactions. +A positive weight on inputs is no serious drawback, as long as creation of outputs is more strongly discouraged. Most wallets, especially those relying on payjoins, do about equal amounts of output creation and spending, the difference being just the wallet's UTXO set. Mining pools are the major exception. While they obviously don't incur any fees in coinbase creation, they need not @@ -82,12 +131,21 @@ For chains with a maximum blocksize, fees are also necessary to allow prioritiza There is a small window prior to HF4 where transactions constructed using the former lower won't be finalized before HF4 and will thus fail to be relayed. Third party wallets are free to switch fee computation some arbitrary time before HF4 to minimize this risk. -The fee factor could be specified separately from the fee, but that requires a consensus change, namely masking the fee -to only the least significant 64 - `FEE_FACTOR_BITS`, allowing the -freed up most significant bits to be used for specifying the fee factor. -The advantage of this separation is that even with higher fee factors, fees can remain a milligrin multiple, -and thus the amounts that users deal with don't need too many digits for fractional grins. -This can be considered a plus for wallet UX. +Instead of a fee shift, one could specify a fee factor. +So then a transaction containing a kernel with the `fee_factor' bitfield having value f would require total fees +of at least f+1 times minfee (preserving old behaviour for a 0 bitfield). +A reasonable overpayment range would then require 8 bits instead of the 4 used for fee +shift, and would create 256 levels of priority. It does seem +wasteful though, to allow a distinction between, say, overpaying by 128 times, +or by 129 times. +Worse still, that many priority levels will severely reduce the potential for aggregation when blocks fill up. +To maximize aggregation opportunities then, forcing priority levels to be a factor of 2 apart seems quite reasonable. + +We can avoid a consensus change by keeping the fee at the full 64 bits, +instead using its least significant 4 bits to specify a fee shift. +This only makes sense if we never plan to make any use of the top 24 bits, which would always be forced to 0 +unless someone pays a monstrous fee, most likely by accident. +It would also lead to balances that are no longer a multiple of a milligrin, making for slightly worse UX. ## Prior art Several chains have suffered spam attacks. In early days, bitcoin was swamped with feeless wagers on Satoshi Dice [1]. @@ -114,17 +172,6 @@ after which wallets can have their fee computation adjusted. In the converse case, where Grin becomes worth only a few cents, then an increase in fees might be needed to avoid spam. Both cases will be much easier to deal with if they coincide with a hard fork, but those may not be on the horizon. -If we go with the alternative of a consensus changing fee mask, then this sets -a precedent for stealing other masked out fee bits as a possible soft-forking -mechanism. Suppose we limit fees to 40 bits, giving a maximum possible fee of -2^40 - 1 nanogrin, or approximately 1099.5 grin. (As a side effect, this limits -the damage of fat fingering a manually entered fee amount.) This gives us 64-40 -= 24 bits, of which we use `FEE_FACTOR_BITS` bits for fee factor, and leave the -remainder available for future use. -We can imagine a future soft-fork further constraining the validity of kernels, depending on the value of some of these bits. -These restrictions can be either within the consensus model, or outside of it in the mempool and relay conventions, such as with the fee factors in this proposal. - - ## References [references]: #references From 3ff789122e08523a9c7bd1e72c1bc570b637b7a3 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Sun, 4 Oct 2020 15:20:48 +0200 Subject: [PATCH 12/17] rewrite as if adopted --- text/0000-fix-fees.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index cbdac9ee..ed48bf2a 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -17,11 +17,11 @@ NOTE: this is a hard-forking change. ## Motivation [motivation]: #motivation -The current fee requirements suffer from being somewhat arbitrary, and not miner incentive compatible. +The former fee requirements suffer from being somewhat arbitrary, and not miner incentive compatible. They are not even linear; to avoid a negative minimum fee, they are rounded up to zero. As a consequence, the minimum fees for the aggregate of two -transactions is not necessarily equal to the sum of the individual ones. -Worse, a miner has no incentive to include a transaction that pays 0 fees, while they take resources to relay. +transactions was not necessarily equal to the sum of the individual ones. +Worse, a miner had no incentive to include a transaction that pays 0 fees, while they take resources to relay. The current (and foreseeable) low price of Grin makes spamming the UTXO set rather cheaper than desired. Fee overpaying, for higher priority to be included in full blocks. fails when aggregated with minimal fee transactions. From 7835470e61f6c2c12f16b261ad368ef52f655831 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Sun, 4 Oct 2020 15:28:33 +0200 Subject: [PATCH 13/17] fix single quotes --- text/0000-fix-fees.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index ed48bf2a..fd877565 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -28,11 +28,11 @@ Fee overpaying, for higher priority to be included in full blocks. fails when ag ## Community-level explanation [community-level-explanation]: #community-level-explanation -For clarity, let's adopt define the following definitions. Let the `feerate' of +For clarity, let's adopt define the following definitions. Let the feerate of a transaction be the fees paid by the transaction divided by the transaction weight with regards to block inclusion (`Transaction::weight_as_block`). -Let the `minfee' of a transaction be the amount of fees required for relay and mempool inclusion. -A transaction paying at least `minfee' in fees is said to be relayable. +Let the `minfee` of a transaction be the amount of fees required for relay and mempool inclusion. +A transaction paying at least `minfee` in fees is said to be relayable. Grin constrains the size of blocks by a maximum block weight, which is a linear combination of the number of inputs, outputs, and kernels. When blocks fill @@ -78,13 +78,13 @@ There is no reason to use different fees for relay and mempool acceptance. Its value shall default to `GRIN_BASE` / 100 / 20 = 500000, which makes each output incur just over 1 Grin-cent in fees. -The 64-bit fee field in kernel types Plain and HeightLocked shall be renamed to `fee_bits' and be composed of bitfields -{ `future_use': 20, `fee_shift': 4, fee: 40 }. All former uses of the fee will use `fee_bits' & `FEE_MASK', -where `FEE_MASK' = 0xffffffffff. +The 64-bit fee field in kernel types Plain and HeightLocked shall be renamed to `fee_bits` and be composed of bitfields +{ `future_use`: 20, `fee_shift`: 4, fee: 40 }. All former uses of the fee will use `fee_bits` & `FEE_MASK`, +where `FEE_MASK` = 0xffffffffff. A nonzero fee shift places an additional restriction on transaction relay and mempool inclusion. -Namely, a transaction containining a kernel with `fee_shift' = s must pay a total fee -of at least 2^s times the minfee (the minfee shifted left by `fee_shift'). +Namely, a transaction containining a kernel with `fee_shift` = s must pay a total fee +of at least 2^s times the minfee (the minfee shifted left by `fee_shift`). Aggregation of two relayable transactions should only happen when the result remains relayable. By linearity, this is always the case for two transactions with identical fee shift. @@ -101,14 +101,14 @@ the fee shift provides for 16 different levels of protection against feerate dil The new tx relay rules and new fee computation in wallets shall take effect at the HF4 block height of 1048320 (but see below about alternatives for 3rd party wallets). -The 20 bits of `future_use bits' provide a possible soft-forking mechanism. +The 20 bits of `future_use bits` provide a possible soft-forking mechanism. We can imagine a future soft-fork further constraining the validity of kernels, or the relayability of transactions containing them, depending on the value of some of these bits. ## Drawbacks [drawbacks]: #drawbacks -Leaving 20 bits of `future_use' increases the amount of zero cost zero friction +Leaving 20 bits of `future_use` increases the amount of zero cost zero friction spam that can be added to the chain. However, we already have a similar amount of spammable bits in the lock height of HeightLocked kernels, where any lock height under the current height of around a million has no effect. @@ -132,7 +132,7 @@ For chains with a maximum blocksize, fees are also necessary to allow prioritiza There is a small window prior to HF4 where transactions constructed using the former lower won't be finalized before HF4 and will thus fail to be relayed. Third party wallets are free to switch fee computation some arbitrary time before HF4 to minimize this risk. Instead of a fee shift, one could specify a fee factor. -So then a transaction containing a kernel with the `fee_factor' bitfield having value f would require total fees +So then a transaction containing a kernel with the `fee_factor` bitfield having value f would require total fees of at least f+1 times minfee (preserving old behaviour for a 0 bitfield). A reasonable overpayment range would then require 8 bits instead of the 4 used for fee shift, and would create 256 levels of priority. It does seem From 9e067e7df3b6ee9cf4cfa891d78af2b3e8507c19 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Tue, 13 Oct 2020 23:23:12 +0200 Subject: [PATCH 14/17] small fixes pointed out in review --- text/0000-fix-fees.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index fd877565..fe5ec3a6 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -18,17 +18,17 @@ NOTE: this is a hard-forking change. [motivation]: #motivation The former fee requirements suffer from being somewhat arbitrary, and not miner incentive compatible. -They are not even linear; to avoid a negative minimum fee, they are rounded up to zero. +They are not even linear; to avoid a negative minimum fee, they are rounded up to `BASE_FEE`. As a consequence, the minimum fees for the aggregate of two transactions was not necessarily equal to the sum of the individual ones. Worse, a miner had no incentive to include a transaction that pays 0 fees, while they take resources to relay. The current (and foreseeable) low price of Grin makes spamming the UTXO set rather cheaper than desired. -Fee overpaying, for higher priority to be included in full blocks. fails when aggregated with minimal fee transactions. +Fee overpaying, for higher priority to be included in full blocks, fails when aggregated with minimal fee transactions. ## Community-level explanation [community-level-explanation]: #community-level-explanation -For clarity, let's adopt define the following definitions. Let the feerate of +For clarity, let's adopt the following definitions. Let the feerate of a transaction be the fees paid by the transaction divided by the transaction weight with regards to block inclusion (`Transaction::weight_as_block`). Let the `minfee` of a transaction be the amount of fees required for relay and mempool inclusion. @@ -51,8 +51,8 @@ We want minfee to be linear to make splitting and combining of fees well-behaved For instance, two parties in a payjoin may each want pay their own input and output fees, while splitting the kernel fee, without overpaying for the whole transaction. -Only the leat significant 40 bits will be used to specify a fee, while -some of the remaining bits will specify a minimum fee overpayment factor, +Only the least significant 40 bits will be used to specify a fee, while +some of the remaining bits will specify a minimum fee overpayment factor as a power-of-2, preventing aggregation with lesser overpaying transactions, and earlier inclusion into full blocks. The largest possible 40-bit fee is 2^40 - 1 nanogrin, or approximately 1099.5 grin, @@ -68,7 +68,7 @@ The minimum relay fee of a transaction shall be proportional to `Transaction::we which uses weights of `BLOCK_INPUT_WEIGHT` = 1, `BLOCK_OUTPUT_WEIGHT` = 21, and `BLOCK_KERNEL_WEIGHT` = 3, which correspond to the nearest multiple of 32 bytes that it takes to serialize. Formerly, we used Transaction::weight, -which uses arbitrary weights of -1, 4, and 1 respectively, but also non-linearly rounds negative results up to 0 +which uses arbitrary weights of -1, 4, and 1 respectively, but also non-linearly rounds negative results up to 1 (as happens when the number of inputs exceeds the number of kernels plus 4 times the number of outputs). The `Transaction::weight_as_block` shall be multiplied by a base fee. From 8f7da70d93ea7e4a5a98c637cea88c3884562d07 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Thu, 15 Oct 2020 14:38:58 +0200 Subject: [PATCH 15/17] fix typos courtesy of lehnberg review --- text/0000-fix-fees.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0000-fix-fees.md b/text/0000-fix-fees.md index fe5ec3a6..ee6e2e89 100644 --- a/text/0000-fix-fees.md +++ b/text/0000-fix-fees.md @@ -67,7 +67,7 @@ As a side effect, this limits the damage of fat fingering a manually entered fee The minimum relay fee of a transaction shall be proportional to `Transaction::weight_as_block`, which uses weights of `BLOCK_INPUT_WEIGHT` = 1, `BLOCK_OUTPUT_WEIGHT` = 21, and `BLOCK_KERNEL_WEIGHT` = 3, which correspond to the nearest multiple of 32 bytes that it takes to serialize. -Formerly, we used Transaction::weight, +Formerly, we used `Transaction::weight`, which uses arbitrary weights of -1, 4, and 1 respectively, but also non-linearly rounds negative results up to 1 (as happens when the number of inputs exceeds the number of kernels plus 4 times the number of outputs). @@ -78,12 +78,12 @@ There is no reason to use different fees for relay and mempool acceptance. Its value shall default to `GRIN_BASE` / 100 / 20 = 500000, which makes each output incur just over 1 Grin-cent in fees. -The 64-bit fee field in kernel types Plain and HeightLocked shall be renamed to `fee_bits` and be composed of bitfields +The 64-bit fee field in kernel types `Plain` and `HeightLocked` shall be renamed to `fee_bits` and be composed of bitfields { `future_use`: 20, `fee_shift`: 4, fee: 40 }. All former uses of the fee will use `fee_bits` & `FEE_MASK`, -where `FEE_MASK` = 0xffffffffff. +where `FEE_MASK = 0xffffffffff`. A nonzero fee shift places an additional restriction on transaction relay and mempool inclusion. -Namely, a transaction containining a kernel with `fee_shift` = s must pay a total fee +Namely, a transaction containining a kernel with `fee_shift = s` must pay a total fee of at least 2^s times the minfee (the minfee shifted left by `fee_shift`). Aggregation of two relayable transactions should only happen when the result remains relayable. From 4aed24cef78301a2aabe2914fa251119f9d6c2f4 Mon Sep 17 00:00:00 2001 From: Daniel Lehnberg Date: Mon, 26 Oct 2020 17:07:54 +0000 Subject: [PATCH 16/17] RFC#0017 --- text/{0000-fix-fees.md => 0017-fix-fees.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename text/{0000-fix-fees.md => 0017-fix-fees.md} (98%) diff --git a/text/0000-fix-fees.md b/text/0017-fix-fees.md similarity index 98% rename from text/0000-fix-fees.md rename to text/0017-fix-fees.md index ee6e2e89..d327ebfa 100644 --- a/text/0000-fix-fees.md +++ b/text/0017-fix-fees.md @@ -1,8 +1,8 @@ - Title: fix-fees - Authors: [John Tromp](mailto:john.tromp@gmail.com) - Start date: August 23, 2020 -- RFC PR: Edit if merged: [mimblewimble/grin-rfcs#0000](https://github.com/mimblewimble/grin-rfcs/pull/0000) -- Tracking issue: [Edit if merged with link to tracking github issue] +- RFC PR: [mimblewimble/grin-rfcs#63](https://github.com/mimblewimble/grin-rfcs/pull/63) +- Tracking issue: [mimblewimble/grin/issues/3459](https://github.com/mimblewimble/grin/issues/3459) --- From 2c39f3c2a3236eb066b93065795423eae9d81eb2 Mon Sep 17 00:00:00 2001 From: Daniel Lehnberg Date: Mon, 26 Oct 2020 17:09:23 +0000 Subject: [PATCH 17/17] Update README --- README.md | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index 6b733fc4..1bd386c3 100644 --- a/README.md +++ b/README.md @@ -10,23 +10,25 @@ To begin writing your own RFC or to find out more about the process and the gene ## List of accepted RFCs -|Title|Tl;dr| -|:---|:---| -| [0001-rfc-process](text/0001-rfc-process.md) | Introduce RFC process | -| [0002-grin-governance](text/0002-grin-governance.md) | Articulate community values, define core and sub-teams | -| [0003-security-process](text/0003-security-process.md) | Define community standards for ethical disclosure behaviour | -| [0004-full-wallet-lifecycle](text/0004-full-wallet-lifecycle.md) | Define API standard for sensitive wallet operations | -| [0005-variable-size-kernels](text/0005-variable-size-kernels.md) | Introduce kernel variants that can be of different sizes | -| [0006-payment-proofs](text/0006-payment-proofs.md) | Support generating and validating payment proofs for sender-initiated (i.e. non-invoice) transactions | -| [0007-node-api-v2](text/0007-node-api-v2.md) | Create a v2 JSON-RPC API for the Node API | -| [0008-wallet-state-management](text/0008-wallet-state-management.md) | Improve wallet state management | -| [0009-enable-faster-sync](text/0009-enable-faster-sync.md) | Enable faster txhashset sync by changing output MMR commitment | -| [0010-online-transacting-via-tor](text/0010-online-transacting-via-tor.md) | Define standard for transacting via Tor | -| [0011-security-team](text/0011-security-team.md) | Establish Grin Security team | -| [0012-compact-slates](text/0012-compact-slates.md) | Introduce new compact slate format (Slate V4) | -| [0013-nrd-kernels](text/0013-nrd-kernels.md) | Introduce relative timelocks through "No Recent Duplicate" transaction kernels | -| [0014-general-fund-guidelines](text/0014-general-fund-guidelines.md) | Define general fund spending guidelines | -| [0015-slatepack](text/0015-slatepack.md) | Universal transaction standard for Grin | +|Title|Status|Tl;dr| +|:---|---|:---| +| [0001-rfc-process](text/0001-rfc-process.md) | ACTIVE | Introduce RFC process | +| [0002-grin-governance](text/0002-grin-governance.md) | RETIRED | ~~Articulate community values, define core and sub-teams~~ Replaced by RFC#6. | +| [0003-security-process](text/0003-security-process.md) | ACTIVE | Define community standards for ethical disclosure behaviour | +| [0004-full-wallet-lifecycle](text/0004-full-wallet-lifecycle.md) | ACTIVE | Define API standard for sensitive wallet operations | +| [0005-variable-size-kernels](text/0005-variable-size-kernels.md) | ACTIVE | Introduce kernel variants that can be of different sizes | +| [0006-payment-proofs](text/0006-payment-proofs.md) | ACTIVE | Support generating and validating payment proofs for sender-initiated (i.e. non-invoice) transactions | +| [0007-node-api-v2](text/0007-node-api-v2.md) | ACTIVE | Create a v2 JSON-RPC API for the Node API | +| [0008-wallet-state-management](text/0008-wallet-state-management.md) | ACTIVE | Improve wallet state management | +| [0009-enable-faster-sync](text/0009-enable-faster-sync.md) | ACTIVE | Enable faster txhashset sync by changing output MMR commitment | +| [0010-online-transacting-via-tor](text/0010-online-transacting-via-tor.md) | RETIRED | ~~Define standard for transacting via Tor~~ Replaced by RFC#0015. | +| [0011-security-team](text/0011-security-team.md) | ACTIVE | Establish Grin Security team | +| [0012-compact-slates](text/0012-compact-slates.md)| ACTIVE | Introduce new compact slate format (Slate V4) | +| [0013-nrd-kernels](text/0013-nrd-kernels.md) | ACTIVE | Introduce relative timelocks through "No Recent Duplicate" transaction kernels | +| [0014-general-fund-guidelines](text/0014-general-fund-guidelines.md) | ACTIVE | Define general fund spending guidelines | +| [0015-slatepack](text/0015-slatepack.md) | ACTIVE | Universal transaction standard for Grin. Replaces RFC#0010. | +| [0016-simplify-governance](text/0016-simplify-governance.md) | ACTIVE | Simplify Grin governance model. Replaces RFC#0002. | +| [0017-fix-fees](text/0017-fix-fees.md) | ACTIVE | Change minimum relay fees to be weight proportional, make output creation cost 0.01 Grin. | ## License