11:52 <bitcoin-git> [qa-assets] dergoegge merged pull request #195: Revert "Revert utxo_snapshot additions temporarily" (main...main) https://github.com/bitcoin-core/qa-assets/pull/195

11:52 <bitcoin-git> [qa-assets] dergoegge pushed 2 commits to main: https://github.com/bitcoin-core/qa-assets/compare/b68b27809741...5114c2d828d9

11:52 <bitcoin-git> qa-assets/main ffb414e MarcoFalke: Revert "Revert utxo_snapshot additions temporarily"

11:52 <bitcoin-git> qa-assets/main 5114c2d Niklas Gögge: Merge pull request #195 from maflcko/main

15:21 <bitcoin-git> [bitcoin] hebasto opened pull request #30630: doc: Update ccache website link (master...240811-ccache-docs) https://github.com/bitcoin/bitcoin/pull/30630

18:15 <portlandhodl> Hey, I work for MARA and created their Slipstream product. With that we received and mined a nonstandard transaction (maybe standard) but violated the non-mandatory-script-verify flag for OP_SUCCESSx

18:15 <portlandhodl> My question is does this have an impact on dev hooks for future softfork upgrades? Other than loss of funds and being insecure are there problems with allowing these TXs to be mined? I am asking primarily to determine if Slipstream policy needs to change.

18:15 <portlandhodl> TX in question.

18:15 <portlandhodl> https://mempool.space/tx/51bae58fa9d413b86d74da60d5366987dcdeb0586d39b93b2ca22f9e40dc83de?mode=details

18:16 <gmaxwell> portlandhodl: they shouldn't be mined, if they are actively created and mined it makes it impossible to use them for softforks without risking forking the network when the softfork activates.

18:19 <gmaxwell> portlandhodl: mining any at all also means that future softfork rules can't be retroactively enforced prior to the inclusion after after the feature is activated. Which means carrying around more conditional complexity than otherwise. If, after a feature is long since activated if there are no conflicts with it in the chain, the enforcement will just get retroactively set to the start (or to

18:19 <gmaxwell> the point some other feature activated), in order to avoid having more conditional logic. Though this point is pretty insignificant to the prior one.

18:20 <gmaxwell> And because they only have an effect of making outputs totally insecure, there shouldn't be any benefit for allowing them.

18:22 <portlandhodl> Not to sound completely ignorant, how? Does activation logic not cover TXNs from the past being marked as OP_SUCCESSx and being spendable by all?

18:22 <portlandhodl> This would mean that a portion of the network, with legacy clients would say that this TX is spendable by all, which is has been spent and validated. The activating nodes would just have a subset of those rules. Assuming this activated with consensus, the longest chain would just be a subset of the rules of the looser OP_SUCCESSx policy.

18:26 <gmaxwell> portlandhodl: If there isn't 100% hashpower enforcing the new rule and someone mines a violation of the new rule (no longer spendable by all but spendable only according to the new rules), then the network will split among the more permissive nodes that accept the violation and and a portion that don't. If there are no violations entering the chain, then even though some hashpower may not

18:26 <gmaxwell> enforce the risk of the consensus splitting is low (it'll only happen if someone intentionally makes an invalid block to disrupt the network).

18:26 <gmaxwell> If the new rule miners have a majority hashpower they will eventually overtake the other chain, and the older nodes will move to the less permissive chain.

18:27 <gmaxwell> but even if the enforcing parties have a large majority hashpower the fork can be pretty long. And because reorgs are relatively rare on bitcoin, that creates a big double spending oppturnity against users.

18:29 <gmaxwell> so the whole reason opcodes like OP_NOP, OP_SUCCESS etc. exist but aren't normally allowed for mining is so that the network is free of them when they go to get put to some real use, so they don't expose latent disagreements about consensus rules around that transition.

18:29 <gmaxwell> portlandhodl: Make sense?

18:31 <gmaxwell> Now you could say, "well we could stop ahead of them being used", and that's true. But (1) the comment I made about not being able to backdate the rules would still apply. (2) it's really hard to be confident that any behavior has _stopped_ vs just not being active at the moment, (3) there is always a risk that you fall over to a backup node that still has the behavior. (IIRC that actually

18:31 <gmaxwell> caused a brief fork and reorg around the activation of OP_CSV-- miner had "upgraded" but had a failover to a non-upgraded node around activation time)

18:33 <portlandhodl> Yeah, and thanks for going over this in such a concise manner. This was a part of my model as well.

18:33 <portlandhodl> So overall this particular transaction isn't a threat to fork the network because we are not activating a softfork and the risk of a reorg 100s of blocks deep isn't likely.

18:34 <gmaxwell> yeah it's not a threat to the network, only at worse a nussance after upgrading that a rule that uses that code can't be retroactively enforced past that point, to simplify the codebase and avoid a lot of "if past here do x, if past there do y".

18:35 <gmaxwell> Though continuing to do so would be pretty unfortunate, -- if you have users that actually need an OP_SUCCESS opcode for some reason (like one that will never get turned into a useful thing), then I wouldn't see any problem in specifying one for that purpose.

18:39 <portlandhodl> Thank you, revised policy will be implemented around OP_SUCCESSx. I had spent a lot of time creating logic around the ScriptPubKey and rules around hooks, but didn't enforce it in Tapscript because of BIP342.

18:39 <portlandhodl> Again thank you for this discussion and your time.

18:40 <gmaxwell> doh. No problem. The code really should be setup to make it easier to disable standardness rules that aren't important for consensus consistency.

18:41 <gmaxwell> portlandhodl: you do stil prevent ECDSA malleated signature, I hope? otherwise that opens up malleation against against non-segwit txn.

18:42 <portlandhodl> Correct! Let me get you a list of non-madatory-flags we are not enforcing.

18:47 <portlandhodl> SCRIPT_ERR_PUSH_SIZE, SCRIPT_ERR_OP_RETURN, SCRIPT_ERR_UNBALANCED_CONDITIONAL, SCRIPT_ERR_SIG_DER, SCRIPT_ERR_SIG_NULLDUMMY, SCRIPT_ERR_DISCOURAGE_OP_SUCCESS, SCRIPT_ERR_CLEANSTACK, SCRIPT_ERR_SCHNORR_SIG_SIZE

18:49 <gmaxwell> Those are the ones you're not enforcing?

18:49 <portlandhodl> Currently.

18:49 <portlandhodl> Just added SCRIPT_ERR_DISCOURAGE_OP_SUCCESS back into policy.

18:49 <gmaxwell> So several of thse are needed to prevent malleation attacks against non segwit txn.

18:50 <portlandhodl> I assume SCRIPT_ERR_SIG_DER

18:50 <gmaxwell> particular, SCRIPT_ERR_SIG_DER, SCRIPT_ERR_CLEANSTACK, SCRIPT_ERR_SIG_NULLDUMMY,

18:51 <gmaxwell> though the latter two don't apply as broadly. (like nulldummy only applies to multisig)

18:52 <gmaxwell> SCRIPT_ERR_SCHNORR_SIG_SIZE is another future upgrade thing (e.g. allow exiting checksig to be used for other key sizes) though I think not as important as the success rules.

18:52 <portlandhodl> SCRIPT_ERR_SIG_DER, this could be used to modify a TXID by encoding the same signature in a different way, keeping this TX as valid but not having the same hash?

18:53 <gmaxwell> portlandhodl: exactly.

18:53 <portlandhodl> Nobody has utilized this yet, but removing out of caution.

18:54 <gmaxwell> the cleanstack rule is because otherwise you can stuff extra pushes into signatures that don't get consumed.

18:54 <portlandhodl> SCRIPT_ERR_SIG_NULLDUMMY -> Is this becuase you could put a 1,2,3 etc as the dropped element and still have this ScriptSig be valid?

18:54 <gmaxwell> Yes.

18:55 <gmaxwell> Are you familar with BIP 62? https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki it was abandoned as a consensus rule in favor of segwit, but it's rule were implemented as standardness rules to protect pre-segwit txn.

18:56 <gmaxwell> (part of the issue was that we kept finding more and more ways to attack txn, so enumerating all of them wasn't working, which drove deploying a more general fix... though those rules are enough to protect the most common transaction types.)

18:56 <portlandhodl> SCRIPT_ERR_CLEANSTACK, would be that I add an extra element to the ScriptSig that would not be consumed keeping the TX valid, but also having a different TXID

18:56 <gmaxwell> portlandhodl: Exactly.

18:57 <gmaxwell> It also creates another kind of attack where if someone pays too much fees, you can shove your child porn into it or whatever, and they'll pay to get it mined. :(

18:57 <gmaxwell> (because you just expanded their txn without invalidating it)

18:58 <portlandhodl> Okay, because there has been 0 demand for these I will reintroduce them into mempool acceptance policy.

18:59 <portlandhodl> I had never read BIP62 due to the withdrawn status.

18:59 <portlandhodl> Not that it's a good reason to not read it. Reviewing now.

18:59 <gmaxwell> Yeah, the withdrawn status is misleading.

19:00 <portlandhodl> I can't thank you enough for your time and discussion about these topics. I don't have much support at MARA around the super deep nuances of topics like these.

19:00 <gmaxwell> It's withdrawn as a consensus rule, but it's the rational behind the standardness rules we've been discussing. Normally BIPs aren't written for standardness rules, though they probably should be for ones that aren't just subjective, e.g. ones that prevent attacks.

19:01 <gmaxwell> Well you can basically always show up here, or directly ask regular contributors. (esp people who wrote functionality you're curious about).

19:04 <gmaxwell> also the stack overflow has been a good place to get more technical answers.

19:04 <gmaxwell> (bitcoin.stackexchange.com)

19:05 <portlandhodl> I will add that into my toolkit, typically I have only looked though there for answers to questions, not ask.

19:09 <gmaxwell> Certantly any kind of "I'm thinking of changing this consensus touching thing, what consequences should I be aware of" is a welcome sort of question. Not everything is well documented.

19:11 <gmaxwell> There have also been some standardness rules in the past that were papering over non-published more serious vulnerablities. I don't believe there are any right now, but I wouldn't know. SCRIPT_ERR_SIG_DER, is one such example: a bug in openssl could have been exploited to split the network between 64 and 32 bit hosts (which there were many of both at the time). OpenSSL isn't used anymore

19:11 <gmaxwell> by any version anyone cares about running, so the issue is now gone, but for a period removing that would have exposed a consensus split.

19:13 <gmaxwell> There were a number of opcodes that had very very bad performance and could have been abused to result in blocks taking minutes to validate, but were blocked out by Satoshi's standardness rules (that blocked almost everything). ... the broad relaxation of standardness rules didn't happen until most of those were fixed.

19:13 <gmaxwell> etc. so if you do come here and ask questions you might also get warned about things like that, should any apply.

19:15 <portlandhodl> Very well aware of those per discussions around the GCC. OP_CODESEPARATOR, OP_CHECKSIG

21:03 <portlandhodl> Okay follow up, what happens to anyone who has used OP_SUCCESSx behind a hash mined into a block before a softfork. Then wants to spend that path after the softfork? Does core still apply the rules as OP_SUCCESSx or does it force the validation of the softfork rules?

21:40 <fjahr> It would be up for discussion how we handle it. The one thing that is certain is that the easiest path would be if we wouldn't have to deal with such a case at all ^^ If you are not aware of the pre-taproot taproot tx, maybe this will be an interesting read for you: https://b10c.me/blog/007-spending-p2tr-pre-activation/ and I'm not sure there is another write-up of how it was handle but there is an exception here:

21:40 <fjahr> https://github.com/bitcoin/bitcoin/blob/master/src/kernel/chainparams.cpp#L90

21:45 <portlandhodl> "The one thing that is certain is that the easiest path would be if we wouldn't have to deal with such a case at all" how would we be certain that we don't have to deal with it, that's my question. Because the script is buried in a MAST devs could not know ahead of time if an OP_SUCCESSx was used.

21:51 <fjahr> Absent of any other evidence the preferred way would be to enforce the new rules from genesis because that's the cleanest option. And if you are not spending that script hidden in a MAST there is no issue, right? And if you spend it after activation of course the new rules apply either way.

23:56 <gmaxwell> portlandhodl: the prefered way is for the current meaning to apply, -- because that results in simpler, more consistent consensus rules. (as fjahr, says it's prefered to eventually retcon rules). It is possible to scope rules to the height of the mined height of the output being spent however: thats the worst for implementation complexity, and the mined height may not be that related to the

23:56 <gmaxwell> time the scriptpubkey was authored (other than it was clearly authored by the point of time). Sometimes there has been some discussion about bug fixes that can't be deployed without potentially breaking some coins doing a height-gate (like blocking codesep). However, since there may exist unconfirmed chains that doesn't solve the prolbem.

23:57 <gmaxwell> portlandhodl: people have observed that hidden opsuccesses could be a way to use features 'in advance' but without any guarentee the *exact* rule you expected would ever be enforced it seems pretty useless.

23:58 <gmaxwell> portlandhodl: if it wasn't clear from the above, nothing about the scriptpubkey is really evaluated at creation time (except the size limit and the broken pre-segwit sigops rule)-- so it's at *spend* time that the consensus rules really matter.