--- Log opened Sun Aug 11 00:00:19 2024
00:41 -!- willcl-ark [~willcl-ar@user/willcl-ark] has quit [Quit: left]
00:43 -!- willcl-ark [~willcl-ar@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has joined #bitcoin-core-dev
00:43 -!- willcl-ark [~willcl-ar@user/willcl-ark] has changed host
00:51 -!- willcl-ark [~willcl-ar@user/willcl-ark] has quit [Quit: left]
00:53 -!- willcl-ark [~willcl-ar@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has joined #bitcoin-core-dev
00:53 -!- willcl-ark [~willcl-ar@user/willcl-ark] has changed host
00:56 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
03:25 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
03:28 -!- SpellChecker [~SpellChec@user/SpellChecker] has quit [Ping timeout: 260 seconds]
03:31 -!- adil [~Thunderbi@2402:d000:8134:b7fc:2d7a:b35f:be26:3304] has joined #bitcoin-core-dev
03:43 -!- aleggg [~aleggg@177.132.197.44] has quit [Ping timeout: 258 seconds]
03:43 -!- aleggg [~aleggg@189.114.151.115.dynamic.adsl.gvt.net.br] has joined #bitcoin-core-dev
04:01 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:49c2:3d57:df43:7cc4] has joined #bitcoin-core-dev
04:06 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:49c2:3d57:df43:7cc4] has quit [Ping timeout: 272 seconds]
04:43 -!- gribble [~gribble@bitcoin/bot/gribble] has quit [Remote host closed the connection]
04: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
04:52 < bitcoin-git> [qa-assets] dergoegge pushed 2 commits to main: https://github.com/bitcoin-core/qa-assets/compare/b68b27809741...5114c2d828d9
04:52 < bitcoin-git> qa-assets/main ffb414e MarcoFalke: Revert "Revert utxo_snapshot additions temporarily"
04:52 < bitcoin-git> qa-assets/main 5114c2d Niklas Gögge: Merge pull request #195 from maflcko/main
04:52 -!- gribble [~gribble@bitcoin/bot/gribble] has joined #bitcoin-core-dev
04:52 -!- mode/#bitcoin-core-dev [+o gribble] by ChanServ
05:01 -!- adil [~Thunderbi@2402:d000:8134:b7fc:2d7a:b35f:be26:3304] has quit [Quit: adil]
05:18 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
05:25 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
06:02 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:b15b:236f:e73b:2cfd] has joined #bitcoin-core-dev
06:07 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:b15b:236f:e73b:2cfd] has quit [Ping timeout: 258 seconds]
06:07 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:9c79:6e8e:ba3:3022] has joined #bitcoin-core-dev
06:38 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
07:03 -!- gribble [~gribble@bitcoin/bot/gribble] has quit [Remote host closed the connection]
07:06 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:9c79:6e8e:ba3:3022] has quit [Ping timeout: 248 seconds]
07:07 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 260 seconds]
07:09 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
07:09 -!- gribble [~gribble@bitcoin/bot/gribble] has joined #bitcoin-core-dev
07:09 -!- mode/#bitcoin-core-dev [+o gribble] by ChanServ
07:13 -!- _flood [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 245 seconds]
07:23 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
07:29 -!- SpellChecker [~SpellChec@user/SpellChecker] has joined #bitcoin-core-dev
08:04 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:ad05:c142:f971:3195] has joined #bitcoin-core-dev
08:08 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:ad05:c142:f971:3195] has quit [Ping timeout: 252 seconds]
08:08 -!- mailman123 [~mailman12@103.166.150.118] has joined #bitcoin-core-dev
08:08 -!- mailman123 [~mailman12@103.166.150.118] has quit [K-Lined]
08:11 -!- kiwiirc [~kiwiirc@51.75.171.51] has joined #bitcoin-core-dev
08:14 -!- kiwiirc [~kiwiirc@51.75.171.51] has quit [Client Quit]
08:14 -!- kiwiirc [~kiwiirc@51.75.171.51] has joined #bitcoin-core-dev
08:20 -!- kiwiirc [~kiwiirc@51.75.171.51] has quit [Quit: Client closed]
08:21 -!- kiwiirc [~kiwiirc@51.75.171.51] has joined #bitcoin-core-dev
08: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
08:23 -!- kiwiirc [~kiwiirc@51.75.171.51] has quit [Client Quit]
08:24 -!- kiwiirc [~kiwiirc@51.75.171.51] has joined #bitcoin-core-dev
08:26 -!- kiwiirc [~kiwiirc@51.75.171.51] has quit [Client Quit]
08:38 -!- furszy [~furszy@user/furszy] has changed host
09:06 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
09:16 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:29cb:e77f:ef9c:da0e] has joined #bitcoin-core-dev
09:27 -!- kiwiirc [~kiwiirc@51.75.171.51] has joined #bitcoin-core-dev
09:36 -!- kiwiirc [~kiwiirc@51.75.171.51] has quit [Quit: Client closed]
09:39 -!- kiwiirc [~kiwiirc@51.75.171.51] has joined #bitcoin-core-dev
09:42 -!- kiwiirc [~kiwiirc@51.75.171.51] has quit [Client Quit]
09:44 -!- kiwiirc [~kiwiirc@51.75.171.51] has joined #bitcoin-core-dev
10:17 -!- kiwiirc [~kiwiirc@51.75.171.51] has quit [Ping timeout: 256 seconds]
10:32 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:51 -!- portlandhodl [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-dev
10:56 -!- portlandhodl [~Thunderbi@securemail.qrsnap.io] has quit [Quit: portlandhodl]
11:01 -!- achow101 [~achow101@user/achow101] has quit [Remote host closed the connection]
11:11 -!- portlandhodl [~Thunderbi@user/portlandhodl] has joined #bitcoin-core-dev
11: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
11: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.
11:15 < portlandhodl> TX in question.
11:15 < portlandhodl> https://mempool.space/tx/51bae58fa9d413b86d74da60d5366987dcdeb0586d39b93b2ca22f9e40dc83de?mode=details
11: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.
11: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 
11: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.
11:20 < gmaxwell> And because they only have an effect of making outputs totally insecure, there shouldn't be any benefit for allowing them.
11: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? 
11: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.
11: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 
11: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).
11: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.  
11: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.
11: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.
11:29 < gmaxwell> portlandhodl: Make sense?
11: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 
11: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)
11:33 < portlandhodl> Yeah, and thanks for going over this in such a concise manner. This was a part of my model as well.
11: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. 
11: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".
11: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.
11: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.
11:39 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
11:39 < portlandhodl> Again thank you for this discussion and your time.
11: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.
11:41 < gmaxwell> portlandhodl: you do stil prevent ECDSA malleated signature, I hope? otherwise that opens up malleation against against non-segwit txn.
11:41  * gmaxwell looks up the flag name.
11:42 < portlandhodl> Correct! Let me get you a list of non-madatory-flags we are not enforcing.
11: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 
11:49 < gmaxwell> Those are the ones you're not enforcing?
11:49 < portlandhodl> Currently. 
11:49 < portlandhodl> Just added SCRIPT_ERR_DISCOURAGE_OP_SUCCESS back into policy.
11:49 < gmaxwell> So several of thse are needed to prevent malleation attacks against non segwit txn.
11:50 < portlandhodl> I assume SCRIPT_ERR_SIG_DER
11:50 < gmaxwell> particular, SCRIPT_ERR_SIG_DER, SCRIPT_ERR_CLEANSTACK, SCRIPT_ERR_SIG_NULLDUMMY,
11:51 < gmaxwell> though the latter two don't apply as broadly. (like nulldummy only applies to multisig)
11:51 -!- kiwiirc [~kiwiirc@198.244.148.174] has joined #bitcoin-core-dev
11: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.
11: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? 
11:53 < gmaxwell> portlandhodl: exactly.
11:53 -!- kiwiirc [~kiwiirc@198.244.148.174] has quit [Killed (ozone (No Spam))]
11:53 < portlandhodl> Nobody has utilized this yet, but removing out of caution.
11:54 < gmaxwell> the cleanstack rule is because otherwise you can stuff extra pushes into signatures that don't get consumed.
11: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?
11:54 < gmaxwell> Yes.
11: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.
11:56 -!- kiwiirc [~kiwiirc@116.71.166.78] has joined #bitcoin-core-dev
11: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.)
11: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
11:56 < gmaxwell> portlandhodl: Exactly.
11: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. :(
11:57 < gmaxwell> (because you just expanded their txn without invalidating it)
11:58 < portlandhodl> Okay, because there has been 0 demand for these I will reintroduce them into mempool acceptance policy.
11:59 < portlandhodl> I had never read BIP62 due to the withdrawn status.
11:59 < portlandhodl> Not that it's a good reason  to not read it. Reviewing now. 
11:59 < gmaxwell> Yeah, the withdrawn status is misleading.
12: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.
12: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.
12:01 < gmaxwell> Well you can basically always show up here, or directly ask regular contributors. (esp people who wrote functionality you're curious about).
12:04 < gmaxwell> also the stack overflow has been a good place to get more technical answers.
12:04 < gmaxwell> (bitcoin.stackexchange.com)
12:05 < portlandhodl> I will add that into my toolkit, typically I have only looked though there for answers to questions, not ask. 
12: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.
12: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 
12:12 < 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.
12:13 -!- kiwiirc [~kiwiirc@116.71.166.78] has quit [Quit: Client closed]
12: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.
12:13 < gmaxwell> etc. so if you do come here and ask questions you might also get warned about things like that, should any apply.
12:15 < portlandhodl> Very well aware of those per discussions around the GCC. OP_CODESEPARATOR, OP_CHECKSIG 
12:15 -!- kiwiirc [~kiwiirc@116.71.166.78] has joined #bitcoin-core-dev
12:26 -!- kiwiirc [~kiwiirc@116.71.166.78] has quit [Killed (ozone (No Spam))]
12:28 -!- kiwiirc [~kiwiirc@103.166.150.118] has joined #bitcoin-core-dev
12:31 -!- kiwiirc15 [~kiwiirc@103.166.150.118] has joined #bitcoin-core-dev
12:38 -!- kiwiirc [~kiwiirc@103.166.150.118] has quit [Quit: Client closed]
12:40 -!- kiwiirc15 [~kiwiirc@103.166.150.118] has quit [K-Lined]
12:52 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:29cb:e77f:ef9c:da0e] has quit [Remote host closed the connection]
12:54 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
13:09 -!- Moonstruck [~Moonstruc@2601:900:8200:7f95:7097:7651:3133:6e8c] has joined #bitcoin-core-dev
13:20 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:29cb:e77f:ef9c:da0e] has joined #bitcoin-core-dev
13:27 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:29cb:e77f:ef9c:da0e] has quit [Ping timeout: 272 seconds]
13:37 -!- Talkless [~Talkless@mail.dargis.net] has quit [Remote host closed the connection]
13:47 -!- Moonstruck [~Moonstruc@2601:900:8200:7f95:7097:7651:3133:6e8c] has quit [Quit: Client closed]
13:52 -!- Moonstruck [~Moonstruc@2601:900:8200:7f95:7097:7651:3133:6e8c] has joined #bitcoin-core-dev
14: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?
14:08 -!- Moonstruck [~Moonstruc@2601:900:8200:7f95:7097:7651:3133:6e8c] has quit [Quit: Client closed]
14:13 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:29cb:e77f:ef9c:da0e] has joined #bitcoin-core-dev
14:17 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
14:23 -!- Moonstruck [~Moonstruc@2601:900:8200:7f95:7097:7651:3133:6e8c] has joined #bitcoin-core-dev
14:23 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:29cb:e77f:ef9c:da0e] has quit [Ping timeout: 248 seconds]
14:26 -!- noonien808310429 [~noonien@86.125.147.232] has joined #bitcoin-core-dev
14:33 -!- Moonstruck [~Moonstruc@2601:900:8200:7f95:7097:7651:3133:6e8c] has quit [Quit: Client closed]
14:34 -!- Moonstruck [~Moonstruc@2601:900:8200:7f95:7097:7651:3133:6e8c] has joined #bitcoin-core-dev
14:37 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:29cb:e77f:ef9c:da0e] has joined #bitcoin-core-dev
14: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: 
14:40 < fjahr> https://github.com/bitcoin/bitcoin/blob/master/src/kernel/chainparams.cpp#L90
14:43 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:29cb:e77f:ef9c:da0e] has quit [Ping timeout: 252 seconds]
14: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.
14: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.
15:00 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:29cb:e77f:ef9c:da0e] has joined #bitcoin-core-dev
15:05 -!- kevkevin [~kevkevin@2600:1700:b30:47c0:29cb:e77f:ef9c:da0e] has quit [Ping timeout: 272 seconds]
15:18 -!- portlandhodl1 [~Thunderbi@user/portlandhodl] has joined #bitcoin-core-dev
15:20 -!- portlandhodl [~Thunderbi@user/portlandhodl] has quit [Ping timeout: 248 seconds]
15:20 -!- portlandhodl1 is now known as portlandhodl
16:02 -!- Guest35 [~Guest4@134.195.196.178] has joined #bitcoin-core-dev
16:03 -!- Guest35 [~Guest4@134.195.196.178] has quit [Client Quit]
16:09 -!- Moonstruck [~Moonstruc@2601:900:8200:7f95:7097:7651:3133:6e8c] has quit [Quit: Client closed]
16:33 -!- Guest86 [~Guest53@bras-base-bmtnon1352w-grc-14-74-12-90-9.dsl.bell.ca] has joined #bitcoin-core-dev
16:33 -!- Guest86 [~Guest53@bras-base-bmtnon1352w-grc-14-74-12-90-9.dsl.bell.ca] has quit [Client Quit]
16:37 -!- kevkevin [~kevkevin@98.226.206.182] has joined #bitcoin-core-dev
16: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 
16: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.
16: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.
16: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.
17:00 < gmaxwell> so like if you were confident some new opcode would be activated (e.g. because it has locked in but not activated yet) you could totally start putting it in your hidden scripts in advance.  At least assuming that the consensus rule doesn't try to avoid activating on old outputs or other special handling.
17:08 < gmaxwell> Aside, there is two other, more academic reason that the community has generally preferred to retcon consensus rules as far back as possible beyond implementation simplicity:   Sometimes people ask "oh but what if there is some huge reorg that undoes the activation, and the attacker replays transactions with their rules no longer enforced and steals the coins".   This is not a very interesting 
17:08 < gmaxwell> hypothetical because if the network can be reorgs so substantially it's basically dead, but the entire debate is eliminated by retconning the rules.   Related to that, and perhaps more interesting, is what happens if an eclipse attacker isolates a syncing node-- it could put a node in an alternative reality that had that kind of attack in it,  and perhaps trick it into automatically making some 
17:08 < gmaxwell> transactions that are against its interests.  It's also not very realistic because it requires a lot to go wrong and very specific behavior, and is probably largely blocked by things like the minimum chainwork .... but it's a class of attack that is also closed off with retconning.  (at least to the extent that it involves deactivating a consensus rule).
17:12 < gmaxwell> portlandhodl: another point, part of the idea about any of the 'upgradable opcode'  -- like OP_SUCCES or OP_NOPx, if you use them before they're activated and later your usage is broken by consensus rules? tough luck for you. you shot your own foot off.
17:14 < gmaxwell> vs other functionality, there is incredible hesitance in doing anything that might destroy people's coins by surprise.  (keep in mind there could be a chain of nlocktimed presigned transactions-- so not only does p2sh/p2wsh/taproot hide scripts, even with plain old outputs we can't tell what opcodes people are counting on working -- so the only way for *any* upgrade to be safe is to have 
17:14 < gmaxwell> op_codes that you know you don't get to count on)
19:06 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 248 seconds]
19:36 -!- achow101 [~achow101@user/achow101] has joined #bitcoin-core-dev
20:39 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
21:01 -!- cmirror [~cmirror@4.53.92.114] has quit [Remote host closed the connection]
21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
21:33 -!- achow101 [~achow101@user/achow101] has quit [Ping timeout: 248 seconds]
21:39 -!- achow101 [~achow101@user/achow101] has joined #bitcoin-core-dev
21:48 -!- kevkevin [~kevkevin@98.226.206.182] has quit [Remote host closed the connection]
22:01 -!- mcey [~emcy@148.252.144.109] has quit [Remote host closed the connection]
22:01 -!- mcey [~emcy@148.252.144.109] has joined #bitcoin-core-dev
22:10 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
22:12 < bitcoin-git> [bitcoin] kirthana4323 opened pull request #30631: Main (master...main) https://github.com/bitcoin/bitcoin/pull/30631
22:17 < bitcoin-git> [bitcoin] achow101 closed pull request #30631: Main (master...main) https://github.com/bitcoin/bitcoin/pull/30631
22:18 -!- kevkevin [~kevkevin@2601:241:8703:7b30:e9ef:e54:b440:687] has joined #bitcoin-core-dev
22:23 -!- kevkevin [~kevkevin@2601:241:8703:7b30:e9ef:e54:b440:687] has quit [Ping timeout: 258 seconds]
22:52 -!- _aj_ [aj@user/aj/x-5857768] has quit [Ping timeout: 260 seconds]
22:52 -!- _aj_ [aj@azure.erisian.com.au] has joined #bitcoin-core-dev
22:52 -!- _aj_ [aj@user/aj/x-5857768] has changed host
22:55 -!- kevkevin [~kevkevin@2601:241:8703:7b30:e9ef:e54:b440:687] has joined #bitcoin-core-dev
23:00 -!- kevkevin [~kevkevin@2601:241:8703:7b30:e9ef:e54:b440:687] has quit [Ping timeout: 260 seconds]
23:09 -!- BrandonOdiwuor [~BrandonOd@105.163.157.219] has joined #bitcoin-core-dev
23:16 -!- kevkevin [~kevkevin@2601:241:8703:7b30:e9ef:e54:b440:687] has joined #bitcoin-core-dev
23:16 -!- achow101 [~achow101@user/achow101] has quit [Remote host closed the connection]
23:17 -!- achow101 [~achow101@user/achow101] has joined #bitcoin-core-dev
23:20 < darosior> portlandhodl: thanks for showing up here and asking those questions.
23:21 -!- kevkevin [~kevkevin@2601:241:8703:7b30:e9ef:e54:b440:687] has quit [Ping timeout: 264 seconds]
23:35 -!- kevkevin [~kevkevin@2601:241:8703:7b30:e9ef:e54:b440:687] has joined #bitcoin-core-dev
23:40 -!- kevkevin [~kevkevin@2601:241:8703:7b30:e9ef:e54:b440:687] has quit [Ping timeout: 260 seconds]
23:55 -!- kevkevin [~kevkevin@98.226.206.182] has joined #bitcoin-core-dev
23:56 -!- jqq_ [sid628190@id-628190.uxbridge.irccloud.com] has quit [Ping timeout: 260 seconds]
23:56 -!- real_or_random [sid554204@user/real-or-random/x-4440763] has quit [Ping timeout: 260 seconds]
23:57 -!- real_or_random [sid554204@user/real-or-random/x-4440763] has joined #bitcoin-core-dev
23:57 -!- RubenSomsen [sid301948@user/rubensomsen] has quit [Ping timeout: 260 seconds]
23:58 -!- sr_gi[m]1 [~srgimatri@2620:6e:a000:ce11::2a] has quit [Ping timeout: 260 seconds]
23:58 -!- mullick [~mullick@user/mullick] has quit [Ping timeout: 260 seconds]
23:58 -!- hugohn____ [sid304114@id-304114.lymington.irccloud.com] has quit [Ping timeout: 260 seconds]
23:58 -!- kinlo [~peter@user/kinlo] has quit [Ping timeout: 260 seconds]
23:58 -!- baakeydow [~baake@2001:41d0:203:b12c::] has quit [Ping timeout: 260 seconds]
23:58 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has quit [Ping timeout: 260 seconds]
23:58 -!- hugohn____ [sid304114@id-304114.lymington.irccloud.com] has joined #bitcoin-core-dev
23:59 -!- sr_gi[m]1 [~srgimatri@2620:6e:a000:ce11::2a] has joined #bitcoin-core-dev
--- Log closed Mon Aug 12 00:00:00 2024