This was pointed out to be missing from the BIP by @petertodd.
CTV is, as implemented in the PR, safe. This is not by accident, CTV was designed to not have these problems. But it's important to make these DoS issues and CTV's design w.r.t. clear, especially since the adding of the example checker logic did make the BIP's spec dos-able (though not any reference implementation).
New section 'Denial of Service and Validation Costs' added in BIP should be helpful.
169 | @@ -170,21 +170,25 @@ specification for the semantics of OP_CHECKTEMPLATEVERIFY. 170 | Where 171 | 172 | bool CheckDefaultCheckTemplateVerifyHash(const std::vector<unsigned char>& hash) { 173 | + // note: for anti-DoS, a real implementation *must* cache parts of this computation 174 | + // to avoid quadratic hashing DoS, including
That sentence looks incomplete
// to avoid quadratic hashing DoS all variable length computations must be precomputed
// including hashes of the scriptsigs, sequences, and outputs. See the section
// "Denial of Service and Validation Costs" below.
woops :)
Co-authored-by: flack <flack@contentcontrol-berlin.de>
I don't think these little notes are sufficient to act as a specification. They're sufficient for an explanatory note. But not for a specification.
Can you show me an example of a section in a previous BIP which has a sufficient explanation of DoS concerns?
I scanned all the BIPs you are a co-author of, figuring that would be a good source for how to cover this topic, and did not really find any treatment of denial of service or resource exhaustion risks.
This isn't a boilerplate requirement. Your proposal has a unique DoS attack risk that has to be handled carefully. The specification thus needs to be comprehensive enough to specify the exact way that risk is mitigated. You haven't done that.
My one consensus critical BIP - CheckLocktimeVerify - both didn't have any special DoS risks, and precisely defined exactly how it behaved with code.
On April 28, 2022 5:57:24 PM GMT+02:00, Jeremy Rubin @.***> wrote:
I scanned all the BIPs you are a co-author of, figuring that would be a good source for how to cover this topic, and did not really find any treatment of denial of service or resource exhaustion risks.
-- Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bips/pull/1272#issuecomment-1112380254 You are receiving this because you were mentioned.
Message ID: @.***>
Ok -- can you show me where this is discussed in BIP-341,342, which share a similar risk? I do not see a relevant section there.
edit: note i'm not looking to excuse myself from addressing the feedback, I'm just looking for a template I can follow to address this type of concern to the level required and expected.
Quoting yourself:
I think 340 is a bit higher quality since it's a cryptographic spec, but the BIP can't be implemented AFAICT from the other BIPs since they lack a lot of little details that are still consensus critical.
BIP-340,342, and 342 are obviously not specification BIPs as they're missing the detail required to actually specify behavior. They outline intentions: the actual specification is, as always, the code. You're trying to do a specification BIP and failing because you're leaving out details.
FWIW I'd say Taproot's BIPs are sloppy in that regard and don't do a good job in explaining intentions - they need diagrams for that. But it doesn't matter that much now that they've been deployed.
I am not sure what the feedback is you're trying to give me and how to actionably respond to it.
Would it be good enough if the BIP were more similar to 34x and made it 'obviously not specification BIPs'?
Is there a magic phrase like 'look at the code' that is required?
note: when i say that higher quality, I'm referring to relative to 341 or 342.