Allow Foundation subsidy to be waived #237
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
v2 transactions have a
NewFoundationAddress
field, which, if present, updates both the primary and failsafe addresses. This PR tweaks the update logic slightly: if the new address istypes.VoidAddress
, only the primary address is updated.(State).FoundationSubsidy
also now returnsfalse
if the primary address istypes.VoidAddress
. Together, these changes allow the Foundation to effectively waive the subsidy until a new, non-void primary address is set. This is preferable to receiving and then later burning the subsidy; instead, the subsidy is simply not created in the first place.I also renamed "primary" and "failsafe" to "subsidy" and "management" to reflect the function of these addresses in v2. The "subsidy" address receives the subsidies, while the "management" address is used to update addresses. (Note that, thanks to spend policies, the old "primary" and "failsafe" can be combined into one address using a threshold policy.)
Checking for
types.VoidAddress
might seem like a bit of a hack. Alternatively, we could expand the definition ofNewFoundationAddress
. Technically, this would change the encoding ofV2Transaction
; however, AFAICT, it would not actually cause any breakage, as the field is a pointer and has never been used in the v2 testnet (hence always encoded asfalse
).