--- Log opened Wed May 18 00:00:26 2022 00:06 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Ping timeout: 272 seconds] 00:19 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has joined #bitcoin-core-pr-reviews 00:23 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Ping timeout: 240 seconds] 00:32 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has joined #bitcoin-core-pr-reviews 00:34 -!- orionwl is now known as laanwj 00:36 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has quit [Ping timeout: 248 seconds] 00:50 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has joined #bitcoin-core-pr-reviews 01:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has joined #bitcoin-core-pr-reviews 01:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has quit [Ping timeout: 260 seconds] 01:27 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews 01:30 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 250 seconds] 01:52 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has quit [Ping timeout: 240 seconds] 01:55 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has joined #bitcoin-core-pr-reviews 02:00 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has quit [Ping timeout: 272 seconds] 02:11 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has joined #bitcoin-core-pr-reviews 02:16 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Ping timeout: 272 seconds] 02:31 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has joined #bitcoin-core-pr-reviews 02:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has joined #bitcoin-core-pr-reviews 02:37 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has quit [Remote host closed the connection] 02:52 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 02:57 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 244 seconds] 03:18 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews 03:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has joined #bitcoin-core-pr-reviews 03:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has quit [Ping timeout: 248 seconds] 03:30 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds] 03:31 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Ping timeout: 240 seconds] 03:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has joined #bitcoin-core-pr-reviews 03:45 -!- theStack [~theStack@95.179.145.232] has joined #bitcoin-core-pr-reviews 03:47 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has joined #bitcoin-core-pr-reviews 03:53 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Ping timeout: 272 seconds] 04:24 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:3c67:f8b:edb7:5828] has joined #bitcoin-core-pr-reviews 04:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has quit [Ping timeout: 240 seconds] 05:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has joined #bitcoin-core-pr-reviews 05:18 < michaelfolkson> So this concept of a tree and a root in Miniscript... Formally we are talking about a DAG (directed acyclic graph) rather than a "tree" right? 05:19 < sipa> No, a tree. 05:19 < michaelfolkson> Like a Merkle tree? 05:19 < sipa> That's also a kind of tree. 05:20 < sipa> A tree is an acyclic graph where every element can have at most one parent. 05:21 < michaelfolkson> Ok a DAG is a tree. And Miniscript can be broken down and represented as a DAG? 05:21 < sipa> No, a DAG is not a tree. 05:22 < sipa> Every tree is a DAG but not the other way around. 05:24 < sipa> I don't know why you're dragging DAGs into this. Miniscript expressions are just trees. Trees are much easier to reason about. 05:26 < michaelfolkson> A tree is defined as having a root? Some/many DAGs wouldn't have a root. The root of a Miniscript tree would be at the bottom of the stack and satisfied last in the script execution? 05:26 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:3c67:f8b:edb7:5828] has quit [Ping timeout: 248 seconds] 05:27 < sipa> I really don't know where to start on addressing your misunderstandings here. 05:27 < michaelfolkson> I'm dragging DAGs into it because it isn't a Merkle tree or other tree data structure I'm familiar with. So I mistakenly thought we were in the realm of DAGs 05:28 < sipa> They're just expression trees. 05:28 < sipa> The root is the whole expression. 05:28 < sipa> Every subexpression is a node in the tree. 05:28 < sipa> The leaves are the expressions which don't have subexpressions, like pk() or older(). 05:29 < sipa> They're not Merkle trees because there are no hashes associated with every element. 05:29 < sipa> Miniscript is a way to represent Bitcoin script, but the tree form only exists on the Miniscript side. It's hard to identify the tree structure in Bitcoin script. 05:30 < michaelfolkson> The root is the whole expression.... ok thanks 05:31 < sipa> E.g. and_b(a:pk(A),or_b(a:pk(B),a:pk(C)))... that a tree where the root is and_b, and it has two children namely a:pk(A) and or_b. The or_b again has two child nodes namely a:pk(B) and a:pk(C). 05:35 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has joined #bitcoin-core-pr-reviews 05:49 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews 05:51 -!- brunoerg_ [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 05:52 < michaelfolkson> I was visualizing a Miniscript as displayed on miniscript.fun and thought that was the "tree" structure. But yeah I can see a tree of ANDs and ORs as being a simple binary tree 05:52 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 256 seconds] 05:53 < sipa> lt's not a binary tree. Some nodes can have more than 2 subexpressions (like thresh). Some have 1 subexpression (like the wrappers a: and d: and l: etc). 05:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:ad2f:65db:12a3:24d0] has quit [Ping timeout: 260 seconds] 06:06 < michaelfolkson> Taproot'd Miniscript can easily deal with ORs, just split across multiple Tapleafs and drop the ORs. With ANDs and thresholds at the highest level (the root in Miniscript terminology not Taproot terminology) they can't *ever* be split into multiple Tapleafs right? 06:07 < michaelfolkson> An AND or threshold at the root (in Miniscript terminology) would mean that it needs to all be encoded into a single leaf of a Taproot tree 06:08 < michaelfolkson> Or are there (perhaps rare) examples with a threshold that it could be rearranged to be able to split it into multiple Tapleafs 06:08 < michaelfolkson> I guess there would be 06:09 < michaelfolkson> An AND would all need to be in a single Tapleaf 06:09 < sipa> Miniscript is about representing scripts in an analysable way. In the case of taproot there is a tree of scripts, each of which may or may not be representable as miniscript. 06:10 < sipa> At a policy level you can reason about the overall picture of course. 06:11 < sipa> For example a 2-of-3 thresh policy could in theory be converted to a taproot tree with 3 scripts, each of which represents a 2-of-2 policy for one of the 3 combinations a 2-of-3 can be split into. 06:13 < michaelfolkson> Right, like Murch's blog post with threshold sig. It could be a threshold of policies rather than a threshold of signatures, neat https://murchandamus.medium.com/2-of-3-multisig-inputs-using-pay-to-taproot-d5faf2312ba3 06:14 < sipa> And if the root of the policy is an AND, there may still be ways, if there are disjunctions below it. E.g. and(or(A,B),C) is equivalent to or(and(A,C),and(B,C)). 06:24 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews 06:28 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 244 seconds] 06:40 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Ping timeout: 244 seconds] 06:54 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews 07:12 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has joined #bitcoin-core-pr-reviews 07:18 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has quit [Ping timeout: 260 seconds] 07:20 < pinheadmz_> bip158 question - have there been any ideas for addiitonal filter types besides "basic" ? 07:50 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has joined #bitcoin-core-pr-reviews 08:30 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection] 08:30 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews 08:52 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Ping timeout: 248 seconds] 08:55 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds] 08:59 -!- __gotcha [~Thunderbi@79.132.236.169] has joined #bitcoin-core-pr-reviews 09:02 -!- paul_c [~paul_c@pool-72-66-70-127.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews 09:02 < paul_c> hey guys 09:03 < __gotcha> Another hour if I am not wrong. 09:11 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 09:14 -!- TheRec [~toto@user/therec] has quit [Ping timeout: 252 seconds] 09:17 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has joined #bitcoin-core-pr-reviews 09:23 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 240 seconds] 09:38 -!- xyephy [~xyephy@105.161.216.202] has joined #bitcoin-core-pr-reviews 09:40 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews 09:53 -!- darosior [~darosior@194.36.189.246] has joined #bitcoin-core-pr-reviews 09:54 -!- Franko [~Franko@186.84.22.224] has joined #bitcoin-core-pr-reviews 09:56 -!- OliverOffing [~OliverOff@187.85.169.199] has joined #bitcoin-core-pr-reviews 09:59 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has joined #bitcoin-core-pr-reviews 09:59 -!- Bayer [~Bayer@pop.92-184-117-40.mobile.abo.orange.fr] has joined #bitcoin-core-pr-reviews 09:59 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews 10:00 < stickies-v> #startmeeting 10:00 < svav> Hi 10:00 < OliverOffing> Hi 10:00 < theStack> hi! 10:00 < b10c> hi 10:00 < kouloumos> hi 10:00 < darosior> hi 10:00 < Franko> hi 10:00 < michaelfolkson> hi 10:00 < __gotcha> hi 10:00 < Bayer> Hey everyone 10:01 < xyephy> hi 10:01 < stickies-v> welcome everyone! This and next week we're looking at #24148 (https://bitcoincore.reviews/24148) which introduces Miniscript support for Output Descriptors. Today we're focusing on general Miniscript concepts, and some of the changes introduced in #24148. 10:01 < stickies-v> but first, do we have any first timers joining us today? 10:01 < __gotcha> Yup 10:01 < paul_c> hey guys, first timer here! 10:02 < svav> Where did the newcomers find out about this meeting please? 10:02 < stickies-v> hey __gotcha , paul_c , so glad you can join us today! 10:02 < paul_c> I was at BTC 2022 and attended an Open Source Stage session Gloria was a part of. I learned a lot from that panel and just wanted to reach out to say hi. 10:02 < stickies-v> feel free to just ask when you have questions, no need to ask for permission or anything 10:02 < __gotcha> @josibake_ mentioned review club during chaincode seminar 10:02 < larryruane> Hi 10:03 < stickies-v> a big thank you to the expert & PR author darosior for being here, I appreciate your help in guiding this conversation, because: 10:03 < svav> Ok thanks newcomers and welcome! 10:03 < stickies-v> disclaimer: I picked tis PR just because I'm excited about the potential Miniscript brings, but I'm still relatively new to this codebase - so please keep me honest and I welcome all of your input/corrections :-) 10:03 < stickies-v> that said, who got the chance to review the PR or read the notes? 10:04 < svav> I read the notes 10:04 < __gotcha> read part of the notes 10:04 < paul_c> Skimmed the notes and just finished watching the linked Andrew Poelstra video 10:04 < OliverOffing> I read the notes and reviewed ~4 of the commits 10:04 < theStack> read the notes, didn't review code changes in detail 10:04 < __gotcha> and part of the linked documentation 10:04 < brunoerg_> hi 10:05 < brunoerg_> read the notes 10:05 < kouloumos> read the notes, didn't review code 10:05 -!- Azor [~Azor@200.109.50.144] has joined #bitcoin-core-pr-reviews 10:05 < svav> An intro to Output Descriptors https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md 10:06 < __gotcha> read that one 10:06 < stickies-v> alright not too much code review so good to start with a few general concept questions first then, it's important to understand what miniscript is about 10:06 < stickies-v> (svav great to have read up on that already - next week we'll dive into output descriptors) 10:06 < Azor> Hi 10:07 < stickies-v> starting off with the first question to get creatie about use cases: which type of analysis enabled by Miniscript would be helpful for which use case or application? 10:08 -!- xyephy [~xyephy@105.161.216.202] has quit [Remote host closed the connection] 10:08 < OliverOffing> Finding smaller scripts that are equivalent in behavior 10:08 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews 10:08 < stickies-v> (or more general, if you just have a cool use case for Miniscript but don't know which type of analysis it relates to - shoot!) 10:08 < darosior> For instance, the analysis of the maximum witness size is helpful for "second layer" protocols to assign fee bumping reserves, since they can then estimate the worst case size of the transaction (if not signed with exotic sighash types). 10:09 < theStack> OliverOffing: +1, also thought about that (i think smaller is pretty much always better, in order to save fees, independently of the conrete usecase) 10:09 < stickies-v> OliverOffing: yeah absolutely, one of the (hand-crafted) transaction templates used on LN (I believe it's the commitment tx?) was found to be slightly suboptimal thanks to Miniscript analysis 10:10 -!- knock [~knock@97.115.141.21] has joined #bitcoin-core-pr-reviews 10:10 < darosior> OliverOffing: in general, since Miniscript is only a subset of Script some policies tend to be more optimizable "by hand". But then you lose all the guarantees given by Miniscript for just a few witness units. :) 10:11 < __gotcha> dariosor: which guarantees are you referring to ? 10:11 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 244 seconds] 10:11 < darosior> But it did happen that the policy compiler found more optimal Script (for instance IIRC in the anchor output proposal for Lightning one of the Scripts was found using the policy compiler) 10:11 < stickies-v> personally I think composition is really interesting, where multiple parties (e.g. in an advanced kind of multi-sig) can provide complex subexpressions without everyone having to understand the other party's spending conditions 10:11 < darosior> __gotcha: soundness and correctness mainly, but also malleability prevention 10:12 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 10:12 < __gotcha> darosior: what is soundness in this context ? 10:13 < darosior> __gotcha: to expand, Script may sometimes have surprising behaviour and a Script that look to do something might actually not behave this way in all cases 10:13 < darosior> __gotcha: soundness in this context means basically "you can't bypass the conditions" 10:13 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 10:13 < michaelfolkson> I like the "make sure it can only be spent with me signing" (on all possible paths) 10:14 < michaelfolkson> CEO always has to sign for example 10:14 < __gotcha> iow proper combination of "and" and "or". 10:14 < darosior> __gotcha: from the website, "consensus sound: It is not possible to construct a witness that is consensus valid for a Script unless the spending conditions are met. Since standardness rules permit only a subset of consensus-valid satisfactions (by definition), this property also implies standardness soundness. " 10:14 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Client Quit] 10:14 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 10:15 < darosior> __gotcha: then to not lock yourself out of your funds you also want completeness "consensus and standardness complete: Assuming the resource limits listed in the previous section are not violated and there is no timelock mixing, for every set of met conditions that are permitted by the semantics, a witness can be constructed that passes Bitcoin's 10:15 < darosior> consensus rules and common standardness rules." 10:16 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 10:16 < __gotcha> darosior: thx 10:16 < stickies-v> lots of ideas here, nice! let's move on 10:16 < stickies-v> what would be a valid Miniscript for a spending policy that unconditionally locks the UTXO for 21 blocks, and then requires a 2-of-3 multisig from Alice, Bob, or Carol? (See https://bitcoin.sipa.be/miniscript or https://min.sc/) 10:17 < theStack> playing around with the min.sc tool resulted in this (i've replaced the hex-strings of the keys replaced by "key_{a,b,c}"): 10:17 < theStack> wsh(and_v(v:multi(2, key_a, key_b, key_c), older(21))) 10:17 < michaelfolkson> I got and(thresh(3,pk(alice),pk(bob),pk(carol)),older(21)) 10:17 < michaelfolkson> Oops policy 10:17 < michaelfolkson> and_v(and_v(v:pk(alice),and_v(v:pk(bob),v:pk(carol))),older(21)) 10:19 < __gotcha> I was closer to theStack proposal 10:19 < stickies-v> michaelfolkson: it was (intentionally) a bit of a trick question, but that's *policy* you posted instead of Miniscript. We use both in the discussion here, but just wanted to highlight that there is a difference. Does everyone understand the difference? 10:19 < OliverOffing> I don't sorry 10:20 < __gotcha> policy compiles to miniscript which compiles to Script ? 10:20 < darosior> michaelfolkson: the Miniscript you posted is a 3-of-3 or i'm missing something? 10:20 < stickies-v> theStack: that seems correct, except I believe the `wsh()` wrapper is specifically for Output Descriptors, and not part of Miniscript 10:20 < sipa> Well, the distinction is fuzzy. 10:21 < michaelfolkson> Oops again 10:21 < sipa> I think of Miniscript's "language" mostly a project to extend the descriptor language. 10:21 < michaelfolkson> and_v(v:multi(2,alice,bob,carol),older(21)) 10:21 < sipa> When all of this is done, nobody should care about the distinction anymore. 10:21 < michaelfolkson> Yeah theStack was right unsurprisingly :) 10:22 < stickies-v> sipa: that would certainly help avoid confusion! (and thank you for joining us) 10:22 < __gotcha> sipa: not sure I understand your last statement 10:22 < darosior> __gotcha: just to be clear Miniscript doesn't "compile" to Script (maybe the word works but it can lead to confusion), each Miniscript fragment maps to a specific Script 10:22 < ls55> Is Policy the Miniscript's language ? 10:22 < sipa> There will just be "the descriptor language". 10:22 < sipa> And "the policy language". 10:22 < __gotcha> darosior: better wording thanks 10:23 < __gotcha> ok so policy and descriptor(miniscript) will remain separated 10:23 < sipa> Miniscript is a project to deal with vaguely generic, composable, script. 10:23 < OliverOffing> is thresh(2,pk(a),pk(b),pk(c)) == multi(2,pk(a),pk(b))? 10:23 < sipa> Rather than just a few simple templates we have now in descriptors (pkh, multi, ...) 10:24 < darosior> OliverOffing: well no since in the latter there is no 'c' 10:24 < OliverOffing> *forgot to add  pk(c) on the right-hand side 10:24 < darosior> Ah 10:24 < darosior> OliverOffing: then yes 10:24 < __gotcha> ls55: afaik, no 10:24 < darosior> But using multi() in this case is more efficient 10:25 < __gotcha> darosior: is "thresh" from miniscript or policy ? 10:25 < OliverOffing> darosior: thanks. the compiler should be able to find the most efficient implementation though right? 10:25 < darosior> __gotcha: both :) 10:25 < sipa> @__gotcha Both 10:25 < darosior> OliverOffing: yes 10:25 < michaelfolkson> This is the policy you feed into the compiler: and(thresh(2,pk(alice),pk(bob),pk(carol)),older(21)) 10:25 < michaelfolkson> And the compiler spits out the Miniscript with multi in it 10:26 < OliverOffing> yes, verified over there too 10:26 < stickies-v> moving on to the next question (but always feel free to continue on previous points) 10:26 < stickies-v> what does it mean when a node is "sane" or "valid"? Do they mean the same thing? 10:27 < theStack> michaelfolkson: which compiler did you use? i found it interesting that your 3-of-3 multisig condition was transformed into two and_v operations 10:27 < darosior> theStack: it was wrong, the correct one is identical to yours 10:28 < OliverOffing> what's the definition of node? is it one atom of a miniscript expression? 10:28 < michaelfolkson> theStack: Been playing around with both listed in the notes. But that was using https://bitcoin.sipa.be/miniscript/ 10:28 < michaelfolkson> theStack: They should both give the same result 10:28 < darosior> OliverOffing: a fragment, eg 'and_v', 'thresh', 'multi', etc.. 10:28 < darosior> OliverOffing: too many nodes in Bitcoin land :) 10:28 < stickies-v> OliverOffing: a Miniscript expression is essentially a tree (see https://miniscript.fun for a visual). Each fragment in the tree is a node 10:28 < theStack> darosior: yes i'm aware. still find it interesting that this optimization happened :) 10:29 < darosior> theStack: oh sorry i misread 10:30 -!- Bayer [~Bayer@pop.92-184-117-40.mobile.abo.orange.fr] has quit [Quit: Connection closed] 10:30 < OliverOffing> i'd guess that sane means that the arguments passed to the fragment match what the fragment type expects (in terms of number of args and types) 10:31 < darosior> theStack: the relevant lines in the Rust compiler https://github.com/rust-bitcoin/rust-miniscript/blob/104eb55f13ce39c4043f24637f83411529a460ea/src/policy/compiler.rs#L993-L1002, i'm less familiar with the C++ one but it does have the same behaviour 10:31 < sipa> @OliverOffing No, that's validity. 10:32 < stickies-v> so we've established the second part of the question that they are indeed not the same :-D 10:33 < OliverOffing> Found this on StackExchange: "We use the term valid for any correctly typed Miniscript. And we use the term safe for any sane Miniscript, ie one whose satisfaction isn't malleable, which requires a key for any spending path, etc." 10:33 < __gotcha> where are those definitions to be found ? 10:33 < ls55> darosior: Does the Rust version use any bindings to the C++ version or is it an entirely different implementation? 10:33 < sipa> It's an entirely separate implementation. 10:33 < ls55> sipa: thanks 10:34 < sipa> There is a preliminary (but abandoned, I think) Python one too. 10:34 < stickies-v> __gotcha: that's a very fair question, the code (especially header files) is always a good place to look for definitions and documentation etc 10:34 < stickies-v> https://github.com/darosior/bitcoin/blob/ec72f351134bed229baaefc8ffaa1f72688c5435/src/script/miniscript.h#L852 10:34 < theStack> darosior: thanks! obviously min.sc is not using the latest version of rust-miniscript; at least it doesn't transform n-of-n thresholds into and_v operations 10:35 < michaelfolkson> https://min.sc/ uses Rust implementation and https://bitcoin.sipa.be/miniscript/ uses C++ implementation. So if they were to give different results that would be worth flagging :) 10:35 < darosior> Hint for the question about sanity: what about this miniscript thresh(101,pk(pk_1),pk(pk_2),...pk(pk_101)) 10:35 < __gotcha> what is the goal of the rust implementation ? as a reference for the C++ ? 10:35 < darosior> Is it valid? 10:35 < OliverOffing> Yes, valid, is it passes a "type-check" 10:35 < sipa> michaelfolkson: There are known differences between the two compilers; they don't attempt to produce identical results. 10:35 < stickies-v> The `Node::IsSane()` method has the docstring "Whether the apparent policy of this node matches its script semantics." 10:35 < darosior> OliverOffing: exactly! Yet is it easily spendable? 10:36 < sipa> __gotcha: The rust implementation was written by people who wanted a rust implementation. The C++ implementation was written by people who wanted a C++ implementation. 10:36 < __gotcha> Does that mean that sane is more restricted than valid ? 10:36 < OliverOffing> darosior: I guess, if you have the 101 PKs...? 10:36 < sipa> Neither is any more a reference than the other. 10:36 < stickies-v> __gotcha: yes it does 10:36 < michaelfolkson> sipa: Ohh in the cases where they can't be separated? Surely if one Miniscript is superior that is a (minor) flaw of one of the compilers? 10:36 < darosior> OliverOffing: there is a catch, see "Resource limitations" at https://bitcoin.sipa.be/miniscript/ :) 10:37 < sipa> michaelfolkson: Neither compiler is perfect. 10:37 < sipa> (nor do we expect them to be) 10:37 < michaelfolkson> So if you really, really cared about most efficient you should run both compilers? 10:37 < darosior> __gotcha: yes, also for a place about the definition see the OP of the original Miniscript PR 10:37 < sipa> Or write it by hand :D 10:38 < OliverOffing> darosior: I understand most resource limitation points there, but what is this one? "Anything but pk(key) (P2PK), pkh(key) (P2PKH), and multi(k,...) up to n=3 is invalid by standardness (bare)." 10:39 < darosior> OliverOffing: it's larger than 3600 bytes 10:39 < darosior> So it's not standard 10:39 < sipa> Note that the C++ miniscript implementation only targets P2WSH (for now). 10:39 < OliverOffing> darosior: oh, I missed the "(bare)" :+1: thanks 10:40 < theStack> is there any plan to implement the equivalent of an "inline assembler" expression, e.g. something like "bare_script(OP_FOO OP_BAR...)"? (not that i can think of a good use-case, just a random thought :D) 10:40 < stickies-v> I guess to summarize sanity, it needs to be valid, consensus and standardness-compliant (e.g. number of operations and script size), have non-malleable solutions, not mix different timelock units (block/time), and not have duplicate keys 10:40 < sipa> theStack: That already exists; `pkh(A)` is a valid descriptor, for example. It's a bare P2PKH. 10:41 < stickies-v> Di(I hope I got that right?) 10:41 < sipa> theStack: Also `raw(HEX)` or `addr(ADDR)` are valid descriptors. 10:41 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 10:41 < darosior> stickies-v: yep 10:41 < sipa> There isn't one that does script assembly... could be added, but I doubt that's very useful. Being able to do fancy things through miniscript is much more usable. 10:41 < michaelfolkson> [18:35:05] Hint for the question about sanity: what about this miniscript thresh(101,pk(pk_1),pk(pk_2),...pk(pk_101)) 10:42 < michaelfolkson> I'm not seeing why this is (in)sane 10:42 < sipa> michaelfolkson: darosior already answered it above. 10:42 < __gotcha> Too big ? 10:42 < theStack> sipa: agree that the script assembly one wouldn't be of much use 10:42 < sipa> Yeah, it's too big. 10:42 < michaelfolkson> sipa: Oh ta 10:43 < stickies-v> alright time for the next question, we've already spoken about malleability a bit. What does it mean for an expression to be non-malleably satisfiable? After SegWit, why do we still need to worry about malleability? 10:43 -!- Bayer [~Bayer@pop.92-184-117-40.mobile.abo.orange.fr] has joined #bitcoin-core-pr-reviews 10:43 < sipa> Good question! 10:44 * stickies-v blushes 10:44 < theStack> my naive answer to the second questions would be: pre-segwit spending conditions are still valid (and very likely will always be), so we can't just ignore them? 10:44 < __gotcha> does malleability introduce fuzziness regarding fees via transaction size ? 10:44 < sipa> theStack: In miniscript we definitely have to option to just not support certain things. 10:44 < darosior> theStack: it's only defined under wsh() for now 10:44 < sipa> Because miniscript is specifically only able to encode a subset of script. 10:45 < theStack> sipa, darosior: oh, good to know! 10:45 < sipa> And indeed, we're already talking about p2wsh only. 10:45 < darosior> __gotcha: hehe great question, yes. It's one of the reason 10:45 < stickies-v> from the website: "For now, Miniscript is really only designed for P2WSH and P2SH-P2WSH embedded scripts." 10:45 < michaelfolkson> SegWit didn't resolve all forms of malleability. Just signature malleability. If there are different possible witnesses with a complex script malleability is still possible 10:46 < sipa> Segwit also didn't remove malleability. It only made it harmless for the purpose of not breaking unbroadcast transactions. 10:46 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 10:46 < sipa> But malleability has other effects, which are far less severe, but still existant. 10:47 < stickies-v> michaelfolkson: you're right, but what's the problem with having that malleability then? why should we care? 10:47 < sipa> Segwit transactions are no less malleable than other ones. 10:47 < sipa> __gotcha was close. 10:47 < darosior> __gotcha: can you think of other inconveniences of third-party malleability? 10:48 < __gotcha> not right now 10:48 < michaelfolkson> stickies-v: Why should we care? Hmm if a second layer protocol relied on knowing wtxid? Auditability for how Bitcoin were spent from a complex script? 10:49 < stickies-v> oh I missed __gotcha 's answer, yes exactly having a different witness can affect transaction size, and since the absolute fee amount is fixed (that part is not malleable), that would afffect the tx's fee rate - and thus it's ability to get propagated and priority to get mined into a block, which can be problematic 10:49 < michaelfolkson> There's a OR(A,B,C). You think it was spent using A but actually it goes on the blockchain with a spend using B 10:49 < michaelfolkson> Yeah size and fees is the better one 10:50 < __gotcha> stickies-v: thanks for being much more precise :-) 10:50 < sipa> That's not malleability. Third parties can't invent a valid signature by B. 10:50 < michaelfolkson> sipa: A,B,C are (overlapping) policies :) 10:51 < sipa> Ah, sure, in that case. 10:51 < darosior> What if a transaction spends a Miniscript which contains a hash using another path? It needs to "dissatisfy" this hash. Once this transaction is broadcast, what can a node on the network do if they want to be a pain? 10:52 < __gotcha> darosior: what is "containing a hash" ? 10:52 < darosior> __gotcha: say for instance a sha256() fragment is part of the Miniscript, but not in the branch used to spend 10:53 < darosior> Replacing the hash dissatisfaction by any 32 bytes string will not invalidate the witness 10:53 < __gotcha> ok 10:53 < darosior> And then for instance the first node i'm broadcasting it to can just take my transaction and send a different version to all nodes on the network 10:54 < __gotcha> what would be the goal in that case ? 10:54 < OliverOffing> does "non-malleably satisfiable" perhaps mean that there's no way to use a same witness data to construct a dissatisfaction of one of the fragments? 10:54 < __gotcha> if the witness is longer, it gets less priority 10:54 < stickies-v> to make it specific, I think an example of a policy of which the Miniscript does not have a satisfaction that's guaranteed to be non-malleable is `or(and(older(21), pk(A)), thresh(2, pk(A), pk(B)))` 10:55 < darosior> This will increase the bandwidth usage of compact relay for everyone, since the miner will mine a transaction that is not exactly the same as every node has in its mempool 10:55 < __gotcha> darosior: but not in the case you just described, right ? 10:55 < __gotcha> ok, as an attack against the network as a whole iiuc 10:55 < darosior> OliverOffing: See "Malleability" at https://bitcoin.sipa.be/miniscript/ for a definition of a non-malleable satisfaction 10:56 < darosior> __gotcha: yeah, as a "nuisance" more than an attack let's say 10:56 < stickies-v> okay only a few minutes left, let's do a quick question on the code just so we can say we've covered it! 10:56 < stickies-v> in `Node::CheckTimeLocksMix()`, what is the type of `"k"_mst`? In your own words, what does the `<<` operator do here? 10:57 < __gotcha> stickies-v: which line ? 10:57 < stickies-v> (link: https://github.com/darosior/bitcoin/blob/ec72f351134bed229baaefc8ffaa1f72688c5435/src/script/miniscript.h#L846) 10:58 < theStack> the type of `"k"_mst` is `Type`, which seems to be just a uint32_t with some helper methods on top 10:59 < stickies-v> theStack: yes correct! 10:59 < OliverOffing> `<<` looks like a bitwise mask/operation to me 10:59 < sipa> @OliverOffing That's correct, but I'd say that's an implementation detail. What does it *mean* for the types involved? 10:59 < stickies-v> `"k"_mst` is converted into a `Type` instance through the user-defined literal (https://en.cppreference.com/w/cpp/language/user_literal) `operator"" _mst` (https://github.com/darosior/bitcoin/blob/ec72f351134bed229baaefc8ffaa1f72688c5435/src/script/miniscript.h#L129) 10:59 < OliverOffing> left shift probably 10:59 < __gotcha> naive cpp newbie question, is that operator overloading ? 11:00 < sipa> @OliverOffing No. 11:00 < theStack> (maybe people will hate me but my personal opinion is that overloading shift operators is a terrible practice) 11:00 < sipa> @__gotcha Yes. 11:00 < __gotcha> theStack: totally agree 11:00 < ls55> theStack:+1 11:00 < stickies-v> `<<` checks that every type property that the right hand has, the left hand also has 11:00 < sipa> @theStack Fair enough... do you have a better suggestion? :) 11:01 < stickies-v> or to quote the docstring: "Check whether the left hand's properties are superset of the right's (= left is a subtype of right)." 11:02 < stickies-v> thank you all for bringing your A game today. Unfortunately we're out of time for this session, but there's more Miniscript joy next week. Same place, same time! Thank you again to darosior and sipa for guiding us all through this. 11:02 < stickies-v> #endmeeting 11:02 < __gotcha> First dive in cpp since more than 20 years, would not pretend to find sthing better 11:02 < svav> Thanks all 11:02 < theStack> sipa: not really, maybe something like `IsSupersetOf`? but i guess being short was important ^^ 11:02 < __gotcha> stickies-v: thx for organising it 11:02 < darosior> Thanks stickies-v for hosting 11:03 < Bayer> Thanks stickies-v 11:03 < theStack> thanks for hosting stickies-v! looking forward to part 2 11:03 < __gotcha> thanks darosior and sipa for support 11:03 < darosior> For those interested, make sure to give https://bitcoin.sipa.be/miniscript/ a read and feel free to ask questions 11:03 < larryruane> thanks! 11:03 < sipa> @theStack Right, sure. But if you look at the type checking code, and the compiler code even more, there are an enormous amount of such checks. 11:03 < OliverOffing> Thanks everyone so much!! 11:04 -!- OliverOffing [~OliverOff@187.85.169.199] has quit [Quit: Connection closed] 11:04 < stickies-v> hope it was helpful - I know it's a lot of concepts, documentation and code to go through. It's just too exciting of a project (both Miniscript and Output Descriptors, and its eventual convergence) not to give this some more attention! 11:04 < paul_c> Thanks, looking forward to next week 11:04 < michaelfolkson> Thanks stickies-v! Looking forward to next week's follow up 11:04 -!- paul_c [~paul_c@pool-72-66-70-127.washdc.fios.verizon.net] has left #bitcoin-core-pr-reviews [] 11:06 < __gotcha> sipa: I see bitcoin.sipa.be Are you located in Belgium ? (Is it bad practice to ask ?) 11:06 < sipa> When I created that website, yes. But that was over 10 years ago. I'm in de US now 11:06 < __gotcha> stickies-v: it was helpful ! thx ! 11:06 < theStack> sipa: i see. if it was a c library, how would you have named it? 11:07 < theStack> (w.r.t. to the operator<<, not the library itself :D) 11:07 -!- Franko [~Franko@186.84.22.224] has quit [Quit: Connection closed] 11:07 < sipa> @theStack "subtype_of" or so? 11:08 < sipa> But of course, if you feel like it doesn't deserve having an operator, there is little I can argue with. 11:08 < michaelfolkson> So not best practice but as it is a check (and there are lots of these checks) it makes sense? 11:08 < __gotcha> coming from Python, for me explicit is better than implicit ;-) 11:08 < theStack> sipa: sounds good. but of course i understand the argument that one wants to have a very short way to do those checks 11:09 < sipa> Specifically, see this function: https://github.com/sipa/miniscript/blob/master/bitcoin/script/miniscript.cpp#L36 11:09 < __gotcha> well, imo, writing stuff like policy or miniscript goes in the direction of making stuff more readable 11:10 < __gotcha> not using operator overloading is in the same vein 11:10 -!- Azor [~Azor@200.109.50.144] has quit [Ping timeout: 240 seconds] 11:13 < __gotcha> sipa: is there a cpp style guide for Bitcoin core ? 11:13 < sipa> yes, see the developer notes in doc/ 11:14 < __gotcha> thx 11:20 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Ping timeout: 244 seconds] 11:20 < theStack> sipa: overloading '|' for union and '&' for intersection is very tempting and reasonable, so i totally see that it would be inconsistent to not also use operator overloading for a 'subtype_of' method 11:22 < theStack> i was just always wondering why one would in general overload operators to a completely different meaning (like done also with streams in c++; i personally don't know a single person who thinks this was a good idea :D) 11:22 < sipa> I wish C++ had custom operators like Haskell, so you don't have to overload ones with a common meaning already. 11:23 < sipa> I think overloading << and >> for streams was a reasonable choice, given the restriction that the only options were the existing set of overloadable operators. Like... which other operator would you choose instead? 11:24 < theStack> don't know Haskell, but the idea of custom operators sounds nice 11:24 < sipa> In Haskell you can just define new operators... like, you want to define "<<==!==>>", no problem! 11:25 < sipa> Just have to consist of symbols from some set. 11:27 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 11:27 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host] 11:27 -!- TheRec [~toto@user/therec] has joined #bitcoin-core-pr-reviews 11:27 -!- __gotcha [~Thunderbi@79.132.236.169] has quit [Ping timeout: 260 seconds] 11:29 < theStack> i don't understand why one would want to overload operators for streams in the first place. is just using a named methods like (Read(),Write()) instead really that worse in terms of readability? 11:29 < sipa> I'd say so. What would something like `"std::cout << "My name is " << name << " and I am " << age << " years old on " << today;` become? 11:30 < sipa> (things like this probably inspired those operators) 11:32 < theStack> well for that case, i'd just go for good old format strings (something like fmtlib, or std::format if c++20 is available). but of course, that's not real streams then anymore i guess 11:33 < theStack> std::cout.Out("My name is ").Out(name).Out(" and I am ").Out(age).Out(" years old on ").Out(today); 11:33 < theStack> yeah that looks strange, i agree 11:33 < sipa> Yeah, I think I agree that from a more modern perspective there is much less need for streams to be all that convenient anymore. 11:37 < theStack> imho one strong drawback of operator overloading (or even overloading in general) is the fact that it's way harder to find instances where this overloaded function is called. no simple grep-ing possible 11:37 < sipa> Indeed. 11:44 < theStack> otoh the same could be said about RAII (implicit dtor calls), but there it seems more often obvious to me that the advantages outweigh this drawback 11:44 < theStack> there was a nice quote from some famous c++ person (was it herb sutter?) saying that his favourite c++ feature is the closing curly brace :) 11:44 < sipa> Haha. 11:48 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed] 11:57 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews 11:59 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has joined #bitcoin-core-pr-reviews 12:06 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:16 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has quit [Remote host closed the connection] 12:17 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has joined #bitcoin-core-pr-reviews 12:22 < luke-jr> sipa: C++'s addition of custom literals seems like a step in the right direction toward custom operators 12:43 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Remote host closed the connection] 12:44 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:3c67:f8b:edb7:5828] has joined #bitcoin-core-pr-reviews 12:51 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:3c67:f8b:edb7:5828] has quit [Ping timeout: 272 seconds] 13:01 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has joined #bitcoin-core-pr-reviews 13:04 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 244 seconds] 13:22 -!- __gotcha [~Thunderbi@79.132.236.169] has joined #bitcoin-core-pr-reviews 13:29 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Remote host closed the connection] 13:31 -!- Bayer [~Bayer@pop.92-184-117-40.mobile.abo.orange.fr] has quit [Quit: Connection closed] 13:32 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:3c67:f8b:edb7:5828] has joined #bitcoin-core-pr-reviews 13:37 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:3c67:f8b:edb7:5828] has quit [Ping timeout: 250 seconds] 13:55 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has joined #bitcoin-core-pr-reviews 14:00 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Ping timeout: 248 seconds] 14:02 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has joined #bitcoin-core-pr-reviews 14:28 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has quit [Quit: Connection closed for inactivity] 14:30 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews 14:34 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 250 seconds] 14:48 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: Connection closed] 15:05 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Ping timeout: 240 seconds] 15:13 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has joined #bitcoin-core-pr-reviews 15:20 -!- __gotcha1 [~Thunderbi@79.132.236.169] has joined #bitcoin-core-pr-reviews 15:20 -!- __gotcha [~Thunderbi@79.132.236.169] has quit [Read error: Connection reset by peer] 15:20 -!- __gotcha1 is now known as __gotcha 15:21 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Ping timeout: 260 seconds] 15:21 -!- knock [~knock@97.115.141.21] has quit [Ping timeout: 240 seconds] 15:33 < david-bakin> I am working on a PR for unit tests where I use `operator||()` as concatenation for byte vectors. Makes some of my tests convenient to write _and to read_. It's a true shame that in C++ we can't define our own operator symbols like in Haskell. The major problems with overloading them - that have led to them being considered bad style for all these years - are that 1) there 15:33 < david-bakin> are too few allowed in the language so you must use the same ones over and over and that leads to confusion, and 2) that you're stuck with the C++ operator precedence which may not be what you want for your use case. 15:35 < david-bakin> That same PR also has custom literals. I'm moving both those little features, useful for unit tests, into a file or two in src/test/util so they can be used in tests. They can be experimented with there and maybe sometime if they prove useful to readability/maintainability things like that can be moved to the production code. 15:37 < david-bakin> It is true you can't grep for operator overloads easily, but I was surprised to learn that VSCode - and probably other IDEs too - now does the reasonable and correct thing when you hover over them or select them and hit "go to definition". That wasn't the case not so long ago. 15:41 < sipa> If need be, you can always add a "= delete;" to an operator definition and compile... the error locations will tell you where it's used. 15:41 -!- __gotcha [~Thunderbi@79.132.236.169] has quit [Ping timeout: 240 seconds] 15:42 < sipa> That's not nearly as convenient as an IDE telling you of course, but honestly, the times I've needed something like that I can probably count on one hand. 15:46 < david-bakin> yes, make the compiler work _for you_! 15:47 < david-bakin> i'll tell you one thing I don't like about operator overloads though - the stream operators have A LOT OF THEM. Goof up and try to stream something that DOESN'T have one defined and you get about 50 lines of error messages telling you all the overloads that DIDN'T WORK. 15:48 < david-bakin> Shut up already, I get it! 15:49 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has joined #bitcoin-core-pr-reviews 16:05 -!- brunoerg_ [~brunoerg@187.183.43.40] has quit [Remote host closed the connection] 16:10 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 16:15 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 260 seconds] 16:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 16:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 260 seconds] 16:47 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews 16:51 -!- theStack [~theStack@95.179.145.232] has quit [Quit: theStack] 16:51 -!- theStack [~theStack@95.179.145.232] has joined #bitcoin-core-pr-reviews 16:57 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:1523:3230:ccb1:c50b] has quit [Ping timeout: 272 seconds] 17:00 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 17:05 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 272 seconds] 17:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 17:10 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 260 seconds] 17:13 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has joined #bitcoin-core-pr-reviews 17:18 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds] 17:18 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has quit [Ping timeout: 272 seconds] 17:19 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has joined #bitcoin-core-pr-reviews 17:23 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has quit [Ping timeout: 240 seconds] 17:32 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has joined #bitcoin-core-pr-reviews 17:39 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 17:43 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 248 seconds] 17:45 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 17:50 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 276 seconds] 17:55 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 18:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 260 seconds] 18:02 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 18:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 240 seconds] 18:08 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 18:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 272 seconds] 18:18 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 18:23 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 260 seconds] 18:25 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 18:29 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 256 seconds] 18:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 18:36 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has quit [Ping timeout: 260 seconds] 18:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 248 seconds] 18:41 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 18:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 248 seconds] 18:53 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews 18:53 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has joined #bitcoin-core-pr-reviews 18:57 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 244 seconds] 18:59 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has quit [Ping timeout: 244 seconds] 19:06 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has joined #bitcoin-core-pr-reviews 19:14 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 19:19 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 244 seconds] 19:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 19:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 240 seconds] 19:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 19:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 244 seconds] 19:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 19:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 248 seconds] 20:13 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has quit [Ping timeout: 250 seconds] 20:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 20:20 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 260 seconds] 20:23 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews 20:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 20:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 244 seconds] 20:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 20:40 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has joined #bitcoin-core-pr-reviews 20:43 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 272 seconds] 20:44 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 20:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 260 seconds] 21:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 21:10 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 260 seconds] 21:25 -!- hashfunc1204 [~user@2601:5c0:c280:7090:6cc7:34d7:ac5c:899e] has joined #bitcoin-core-pr-reviews 21:33 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 21:38 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 256 seconds] 21:41 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has quit [Ping timeout: 244 seconds] 21:55 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has joined #bitcoin-core-pr-reviews 21:59 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has quit [Ping timeout: 240 seconds] 22:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 22:12 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 260 seconds] 22:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 22:30 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection] 22:30 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:3c67:f8b:edb7:5828] has joined #bitcoin-core-pr-reviews 22:32 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews 22:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 244 seconds] 22:35 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Client Quit] 22:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 22:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 272 seconds] 22:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 22:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 244 seconds] 23:01 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews 23:04 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 244 seconds] 23:08 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 23:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 260 seconds] 23:31 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 23:35 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 246 seconds] 23:38 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:3c67:f8b:edb7:5828] has quit [Ping timeout: 244 seconds] 23:42 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 23:46 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 240 seconds] 23:52 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:cdb3:455a:6919:b836] has joined #bitcoin-core-pr-reviews 23:52 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews 23:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has quit [Ping timeout: 260 seconds] 23:58 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:253d:46d1:6253:dc0c] has joined #bitcoin-core-pr-reviews --- Log closed Thu May 19 00:00:27 2022