Simplify V2FileContractRenewal #238
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lukechampine
force-pushed
the
renewal-revision
branch
from
29e6bfc to
c97ff59
Compare
|
This looks like it will make rhp4 require setup transactions again for partial rollovers, definitely not worth it imo |
|
ah. right. drat |
lukechampine
force-pushed
the
renewal-revision
branch
from
c97ff59 to
cfd6d6b
Compare
lukechampine
changed the title
lukechampine
force-pushed
the
renewal-revision
branch
from
cfd6d6b to
4394f1a
Compare
lukechampine
changed the title
Unlike the FinalRevision, there is no danger of allowing the new contract to be independently valid, as it cannot be broadcast without also being funded. Note that this is already possible with any other v2 contract formation: anyone can "replay" the contract formation in a transaction of their own, but they need to supply the contract funding themselves.
Instead of a full revision, renewals now specify just the final outputs and rollover amounts. This sidesteps existing inconsistencies around whether the "final revision" should be inserted into the accumulator or not, as well as the issue of the revision being valid in a standalone transaction.
lukechampine
force-pushed
the
renewal-revision
branch
from
4394f1a to
6a67c9a
Compare
|
This PR now makes the following changes:
I believe it's possible for the rollover values to be omitted entirely: the rollover amount can be determined by subtracting the payout values from the original contract value. However, this would require changes to RHPv4, since helpers like |
n8maninger
approved these changes
Dec 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The tradeoff is that resolution transactions can't contain other outputs. That doesn't seem too restrictive to me, but maybe I'm forgetting a use case that requires it?
I also noticed that a renewal's
FinalRevisionwasn't being applied to the accumulator that way; instead, the accumulator would contain the most recent revision of the contract. Not a huge deal, just felt inconsistent.