Add CIP for giving a fee change to a reward address - #36
Conversation
| a transaction may end up being processed | ||
| at a lower effective fee than originally stated. For example, this may happen because network demand | ||
| at the time of inclusion was lower than anticipated, or because the transaction's | ||
| specified expected delay period was exceeded before it was entered into a block. |
There was a problem hiding this comment.
There's quite a lot of context (of tiered pricing I mean) loaded in this. I'm not necessarily objecting to that, but it could be a source of questions.
| No additional signing requirements are imposed, as it is not mandatory for a | ||
| user to output fee change into an address they own. | ||
|
|
||
| (1) We changes the *produced* calculation are : |
There was a problem hiding this comment.
Should be "The changes to the..." I'm guessing?
| and does not need to be reflected in a transaction output. Making the change | ||
| address optional allows for backwards compatibility. | ||
|
|
||
| ### Ledger rule changes |
There was a problem hiding this comment.
You might have mentioned it, but I can't see where we state what happens if no fee change address is supplied.
| No changes to `TxInfo` are required. The reason for this is that all Plutus scripts | ||
| should be blind to the fee change provided. This value is not fixed at the time of | ||
| transaction construction and therefore cannot be used to predict the outcome of | ||
| script validation at the time of construction. Note here that this change may |
There was a problem hiding this comment.
I wonder if it'd make sense to draw more attention to this point. Maybe a separate paragraph and "Note: ", something like that?
|
|
||
| ### Acceptance criteria | ||
|
|
||
| - [ ] The tiered-pricing CIP (or equivalent) is published and specifies a concrete |
There was a problem hiding this comment.
We don't necessarily need to declare these dependencies here, do we? A node could choose to refund an arbitrary portion of any fee for an internal reason, right? We don't need to couple this to the method of calculating the refund amount.
2 participants
No description provided.