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
Implement BIP-119 Validation (CheckTemplateVerify) #21702
Implement BIP-119 Validation (CheckTemplateVerify) #21702
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. Coverage
Updated at: 2021-07-15T07:47:36.255429. |
f52318d
to
3b07e2f
Compare
src/script/interpreter.cpp
Outdated
} else { | ||
// otherwise we still have *most* of the hash cached, | ||
// so just re-compute the correct one and compare | ||
assert(txTo != nullptr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this assert just be moved to the start of the function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These asserts can technically just be deleted looking at the surrounded code, txTo will already be able to deref nullptr from many other functions.
I put them close to where the deref's actually occur as I think that's best practice, but yes they could go at the start.
I'd actually be more excited about changing the representation internally to a reference as follow up work so we get rid of all these unchecked derefs...
I think CTV is interesting and will likely be a candidate for a future soft fork whether that be a standalone CTV soft fork or a soft fork with a bundle of features. But at least for me I feel it is premature to even look at this with Taproot not yet activated and zero discussion (mere speculation) on the form of the next soft fork after Taproot has (hopefully) activated. I guess there is no harm in opening this but personally I feel it is extremely early. I look forward to those discussions on the next soft fork and digging into this at some point in the future though. |
You're free to review or not review any PR you like whenever you like. No one is "in charge" of the roadmap for Bitcoin development. All changes -- soft forks or not -- proceed when they have rough consensus and the code is ready. This PR is for code review of BIP-119 OP_CTV's implementation. If you wish to discuss Bitcoin Project management please take it to an appropriate venue such as the mailing list. |
On this we are definitely in strong disagreement. A soft fork (or hard fork) requires overwhelming consensus not only in this repo but in the wider community. Taproot reached that bar (there was one NACK from a long term contributor due to quantum concerns I believe in this repo and overwhelming community support) and I expect the next soft fork, whatever it contains, to also reach that bar. To the extent that it appears you disagree with that worries me immensely. But indeed when Taproot has (hopefully) activated I will continue on the mailing list. This has a hard Concept NACK from me until then. All long term contributors to this repository should have the chance to review this and there should be overwhelming consensus within this repo and in the wider community that this should be included in the next soft fork as is. In my opinion we are a long, long way away from that. And this is from someone who finds CTV extremely interesting and is looking forward (once Taproot has activated) to examining in greater detail the use cases of it (ie CTV and ANYPREVOUT's use in vaults). |
Please, again, take the metaphysics to the mailing list. This is a PR for people who want to review BIP-119 CTV. |
aa00f64
to
39b0a50
Compare
Apologies for the line noise -- I hit an issue with GH tracking the tip of my branch and had to use isaacs/github#361 (comment) workaround. |
🕵️ @sipa has been requested to review this pull request as specified in the REVIEWERS file. |
concept ACK. Covenants would open up lots of exciting new use cases. |
CR-ACK 491804c besides the nit on spacing Still need to look through tests |
…n and disabling the exhaustive failure test
…t: [A,B,C] then_unset: [D]
…eep patchset diff for CTV minimized for 0.23
[TESTS] modify script_tests.json to enable OP_NOP4 as OP_CHECKTEMPLATEVERIFY
…ase of bisecting should downstream software expect to parse NOP4 this now fails)
…ly init BIP-119 hash data
…ency injecting sync primitives for laziness This is required given that the script interpreter translation unit cannot link pthread.
…tdeploymentinfo test
d4af88d
to
ee7dda5
Compare
Rebased against v24.0 tag so that this branch remains mergeable/testable against a recent release, closing with up for grabs label if someone is motivated to work on keeping this compatible with future changes to the software. |
This is an implementation of BIP-119 OP_CHECKTEMPLATEVERIFY. It has been rebased on top of Taproot / ST. The specification has been otherwise unrevised since publication nearly a year and half ago.
Minus tests and deployment, it's about 180 LOC.
This branch activates against regtest so you can test on your local node.
This PR includes standardness rules for a bare single CTV Hash script, which has applications for congestion control. Other than that there is limited support for bare scripts using CTV, although the patches to #16766 lay the groundwork for better wallet support with proper IsTrusted parents scanning, which can be amended later to handle chains of irrefutable transactions.
You can learn more about the design of BIP-119 at https://utxos.org/. In particular I recommend the workshop transcript and slides https://utxos.org/workshops/ for a thorough review of how CTV works.
You can stress test CTV for complex examples by trying out the Sapio compiler: learn.sapio-lang.org. There is also some support for CTV in miniscript via the Sapio Rust Miniscript Fork.
Discussion welcome at ##ctv-bip-review in Libera.
If you would like to connect to a signet, I operate one you can connect to with the parameters below.
You may also wish to have the below parameters for things to work nicely: