< instagibbs> gwillen, turns out it's used exactly twice, in FindAndDelete :grimace:
< gwillen> ooooof
< bitcoin-git> [bitcoin] ajtowns opened pull request #16127: Add support for thread safety annotations when using std::mutex (master...201905-locking) https://github.com/bitcoin/bitcoin/pull/16127
< phantomcircuit> instagibbs, things calling FindAndDelete right?
< phantomcircuit> instagibbs, explicit CScript(const std::vector<unsigned char>& b) { operator<<(b); }
< phantomcircuit> and operator<< pushes them as bytes
< phantomcircuit> it's pushing a byte array into the script, not copying a script directly
< phantomcircuit> and yeah it's confusing and a potential cause of bugs if you're not careful about it
< instagibbs> phantomcircuit_, oh huh I am blind, there it is
< bitcoin-git> [bitcoin] instagibbs opened pull request #16128: Delete error-prone CScript constructor only used with FindAndDelete (master...cscript_construct) https://github.com/bitcoin/bitcoin/pull/16128
< bitcoin-git> [bitcoin] practicalswift opened pull request #16129: Make reasoning about dependencies easier by not including unused dependencies (master...decouple-translation-units) https://github.com/bitcoin/bitcoin/pull/16129
< bitcoin-git> [bitcoin] stevenroose opened pull request #16130: Don't GPG sign intermediate commits with github-merge tool (master...contrib-no-sign) https://github.com/bitcoin/bitcoin/pull/16130
< stevenroose> Anyone else here has a Yubikey and .gitconfig configured to always sign commits?
< stevenroose> I use the python script a lot for Elements, I recognize that for bitcoin the subset of contributors that actually use the script is small.
< dongcarl> stevenroose: Yup, sup
< dongcarl> BTW, build system lessons with Cory happening in #bitcoin-builds right now if people wanna join
< ldz27> hi, I wanted to ask for the creation of the secp256k1_vc142 nuget-package. I see Pieter Wuille is the author of the older versions and I hope I am right here.
< sipa> i know nothing about nuget
< gwillen> ldz27: it looks like Erik Voskuil was making the -vc packages, according to https://www.nuget.org/packages?q=secp256k1
< gwillen> but it looks like he stopped in 2017
< gwillen> but I also know nothing about nuget so I'm not really sure how it works
< gwillen> it looks like there are a number of different people packaging libsecp256k1 for it under different names
< ldz27> sipa: ok, sorry for the confusion. gwillen: thank you for the information :)
< gwillen> no problem!
< jeremyrubin> Does anyone have any good documentation on how script parsing works around OP_IF and PUSHDATA
< jeremyrubin> I'm generally confused about how we handle the script: OP_IF PUSHDATA32 <OP_ELSE <30 bytes> OP_ENDIF> OP_ENDIF
< jeremyrubin> or I guess more confusingly
< jeremyrubin> OP_IF PUSHDATA32 <OP_ELSE <31 bytes>> OP_ENDIF
< jeremyrubin> Is it that we scan until the next OP_ELSE/END if OP_IF is false, but we parse pushdata along the way?
< luke-jr> OP_IF just restricts execution, not parsing
< luke-jr> indeed, an invalid opcode inside the OP_IF still causes the script to fail (IIRC)
< jeremyrubin> gotcha
< jeremyrubin> I guess my issue is that I'd like to introduce a new pushdata type opcode (for OP_COSHV related stuff). And the best way to do that seems to be to modify GetOp, but GetOp doesn't take flags, so I was wondering if it's generally safe to do inside of execution.
< jeremyrubin> But then this issue came up
< jeremyrubin> So I probably do need to end up adding flags to GetOp?
< roconnor> I know this is core-dev, but FWIW, there are other ways of dividing up the parsing and execution of opcodes in Script. For my Haskell work I match up IFs ELSEIFs and ENDIFs at parsing time, and handle invalid opcodes inside OP_IF as parsing errors. This has the operational effect that in my implementation mismatched ENDIFs fail at parse time rather than execution time. However this doesn't cause any semantic difference
< roconnor> between how Bitcoin Core interprets Script.
< roconnor> Script opcodes are self-delimiting, that is why OP_IF PUSHDATA32 <OP_ELSE <31 bytes>> OP_ENDIF doesn't cause problems. PUSHDATA32 <OP_ELSE <31 bytes>> is a single (parameterized) opcode.
< roconnor> perhaps better written as PUSHDATA32[<OP_ELSE <31 bytes>>] or PUSHDATA32(<OP_ELSE <31 bytes>>).
< phantomcircuit> roconnor, invalid opcodes only trigger an error if they're actually hit
< phantomcircuit> so it's a protocol violation to throw an exception on an invalid opcode in an OP_IF
< phantomcircuit> (i think
< roconnor> I'm refering specifically to OP_VER and friends.
< roconnor> Sorry for not being clearer before.
< roconnor> er, I mean OP_VERIF
< roconnor> Hmm, I thought there was more than just OP_VERIF and OP_VERNOTIF, but I guess that was it.
< jb55> phantomcircuit: correct https://jb55.com/s/e45a49f6af664e7a.txt
< roconnor> you are correct that other opcode must be parsed.
< jb55> so what's this idea with pushing script as pushdata? am I missing some context here
< roconnor> I think there was a question if if OP_IF were to naively scan over the bytearray representing script, it would stop when it finds the code for OP_ENDIF or OP_ELSE even within the parameter to an OP_PUSHDATA opcode.
< jb55> it wouldn't interpret it as endif it would interpret it as the length argument to pushdata if I'm understanding the question correctly
< jb55> s/endif/else
< jb55> oh he said pushdata32, nm
< jb55> so this scenario https://jb55.com/s/9bcffd1e24209b53.txt, so basically what roconnor said
< warren> Regarding the mailing list, LF had higher priorities to deal with on infra for this time and they aren't going to shut down the existing list anytime soon because of other kernel subprojects. Their DoS mitigations seem to be holding it steady for now. Reapproaching this probably in June when folks are not traveling anymore.
< warren> It sucks that their mailman server was crippled by attacks on bitcoin-dev in particular. They remain blackholed to several major mail providers like Yahoo. I think bounces are also entirely disabled now as one of the DoS mitigation measures.
< jb55> :(