-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add revision ordering test #196
Conversation
good find. I'm not really sure how to handle this case. There are a few options:
I'm leaning towards 2; I like that it forces the transaction creator to acknowledge the prior revision. And there's some precedent: It's similar to the check we have for ephemeral siacoin outputs (which are also not in the accumulator). Thoughts? |
I think option one would be okay. If a renter and host both broadcast different versions of a contract, the higher one should always be the only one applied to the state. I can't think of a use case where we would need more than one revision per block. The tpool would need to be modified to eject lower revisions when a higher one is broadcast though. Option three would be my preference over two. Having to check the tpool for an ephemeral parent is an extra step for broadcasting that feels unnecessary and adds additional friction since two parties can broadcast the revision.
I might be misunderstanding this comment, but it looks like the lower revision is getting applied to the consensus state. If the second lower revision was ignored, I think we could safely mark this as wontfix. As it stands, you can overwrite a higher revision with a lower one as long it's in the same block. |
Yeah, I think I agree. Although option 1 is probably ok in practice, it feels unnecessarily restrictive; of the others, option 3 is the most convenient, and it doesn't have any practical drawbacks, only conceptual ones. |
6abc3e0
to
3dcc8ac
Compare
No description provided.