[ZIP 235] Burn 60% Transaction Fees #915
Conversation
zips/zip-0235.md
Outdated
| In transaction versions without the `burnAmount` field, the total output value | ||
| of the coinbase transaction MUST be the value of the block subsidy, plus | ||
| `ceil(transactionFees * 4 / 10)`. |
There was a problem hiding this comment.
This no longer works given ZIP 236, which will activate with NU6. ZIP 236 requires blocks to balance exactly, and therefore requires coinbase transactions to claim the maximum amount available. The simplest way to fix it would be to require coinbase transactions to be a new version that has the burnAmount field.
There was a problem hiding this comment.
ZIP 236 requires [...] coinbase transactions to claim the maximum amount available.
The intention here is to redefine "maximum amount available". I think we can do this and still require that everything balances exactly, right?
There was a problem hiding this comment.
I've modified this paragraph to read:
Previous transaction versions are not supported for coinbase transactions, due to there being no explicit mechanism to burn the required funds.
giddie
force-pushed
the
zip-235-nsm-tx-fees
branch
from
92fa29b to
e43a8af
Compare
|
After discussion in the Arborist call, we recommend that this be tried out as a transaction construction rule that is available (and potentially turned on by default) to miners, but that it should not be enforced at the protocol level initially. |
| # Deployment | ||
|
|
||
| The implementation of this ZIP MUST be deployed at the same time or after | ||
| ZIP-233 ("NSM: Burning"), and ZIP-234 ("NSM: Issuance Smoothing"). |
There was a problem hiding this comment.
Is it intended that this be dependent on ZIP-234, or is that incidental?
There was a problem hiding this comment.
Also, if that is intended, does it mean at the same time or after NU7 activation, or at the same time or after the smoothing takes effect (which may be later)?
There was a problem hiding this comment.
This can be resolved during the editorial period.
There was a problem hiding this comment.
Yes, if possible please let's discuss this during the editorial period. However, ZIP 235 isn't intended to be dependent on ZIP 234; it can exist independent of ZIP 234, but benefits from the voluntary burning mechanism in ZIP 233. Also, it's worth noting here that at the last Arborist call, we talked about this not being a consensus-level change and instead being a node default behavior (or opt-in). We should discuss that further during the editorial period.
nuttycom
force-pushed
the
zip-235-nsm-tx-fees
branch
from
e43a8af to
0917899
Compare
No description provided.