--- Log opened Tue May 17 00:00:26 2022 00:07 -!- charger [~jrwr@125.163.41.2] has quit [Ping timeout: 272 seconds] 00:55 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review 06:37 -!- jamesob [~jamesob@pool-108-31-54-223.washdc.fios.verizon.net] has joined ##ctv-bip-review 07:26 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Quit: No Ping reply in 180 seconds.] 07:52 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined ##ctv-bip-review 08:41 -!- FelixWeis_ [sid154231@id-154231.hampstead.irccloud.com] has joined ##ctv-bip-review 08:42 -!- schmidty_ [sid297174@id-297174.lymington.irccloud.com] has joined ##ctv-bip-review 08:45 -!- _aj__ [aj@azure.erisian.com.au] has joined ##ctv-bip-review 08:45 -!- _aj__ [aj@azure.erisian.com.au] has quit [Changing host] 08:45 -!- _aj__ [aj@user/aj/x-5857768] has joined ##ctv-bip-review 08:45 -!- kanzure_ [~kanzure@user/kanzure] has joined ##ctv-bip-review 08:50 -!- Netsplit *.net <-> *.split quits: kanzure, FelixWeis, schmidty, _aj_ 08:50 -!- schmidty_ is now known as schmidty 08:50 -!- FelixWeis_ is now known as FelixWeis 09:22 -!- bucko [~bucko@136.49.133.36] has joined ##ctv-bip-review 09:25 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Remote host closed the connection] 09:25 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined ##ctv-bip-review 09:51 -!- bucko [~bucko@136.49.133.36] has quit [Remote host closed the connection] 09:53 -!- bucko [~bucko@136.49.133.36] has joined ##ctv-bip-review 09:57 -!- bucko [~bucko@136.49.133.36] has quit [Ping timeout: 256 seconds] 10:02 -!- _aj__ is now known as _aj_ 10:07 -!- bucko [~bucko@136.49.133.36] has joined ##ctv-bip-review 10:15 -!- kanzure_ is now known as kanzure 10:38 -!- TechMiX [~techtux@188.126.217.46] has joined ##ctv-bip-review 10:38 -!- TechMiX [~techtux@188.126.217.46] has quit [Client Quit] 10:38 -!- TechMiX [~techtux@188.126.217.46] has joined ##ctv-bip-review 11:20 -!- bucko [~bucko@136.49.133.36] has quit [Remote host closed the connection] 11:30 -!- bucko [~bucko@136.49.133.36] has joined ##ctv-bip-review 12:00 <@jeremyrubin> Hello! 12:00 <@jeremyrubin> #startmeeting 12:00 < harding> Hi! 12:00 <@jeremyrubin> Welcome to the meeting everyone 12:00 <@jeremyrubin> We'll give a few minutes for people to join 12:01 <@jeremyrubin> Feel free to propose topics for discussion 12:03 < TechMiX> Hi 12:04 <@jeremyrubin> so for today, i have three topics i'd like to discuss 12:04 <@jeremyrubin> #proposedmeetingtopic - Rusty's OP_TX 12:04 <@jeremyrubin> #proposedmeetingtopic - Adding OP_CAT / CSFS 12:04 <@jeremyrubin> #proposedmeetingtopic rethinking script interpreter flags 12:05 <@jeremyrubin> anyone else have anything they'd like to put up? 12:06 <@jeremyrubin> ok, then without further ado 12:06 <@jeremyrubin> #topic OP_TX 12:06 <@jeremyrubin> who has had a chance to look at / read OP_TX? 12:06 < harding> I have 12:06 < TechMiX> me too 12:06 < bucko> skimmed it 12:06 <@jeremyrubin> 🙏 12:06 <@jeremyrubin> awesome 12:07 <@jeremyrubin> does anyone have any prima facie opinions? 12:08 < bucko> Nice to see general interest and discussion of diff approaches to covenants 12:08 <@jeremyrubin> bucko can i cold-call you to quickly summarize OP_TX? 12:09 < harding> I was wondering how hard it would be for it to accidentally blow up to the 10kB stack size limit. 12:09 < harding> I.e., it might be better to use OP_TXHASH always. 12:09 < _aj_> o/ 12:09 < bucko> Eh, don't feel confident enough and multi-tasking w/ the day job 12:09 <@jeremyrubin> fair :) 12:10 < bucko> I'm not clear on what precisely the advantages of it are over CTV. superficially it seems like it's trying to be more extensible, but CTV also has a versioning system. So maybe one thing to discuss would be the differences and pros/cons of the two approaches to extensibility 12:10 < _aj_> harding: set some bits and it acts like txhash? 12:10 <@jeremyrubin> harding: "Since OP_SUCCESSx precedes size check of initial stack and push opcodes, an OP_SUCCESSx-derived opcode requiring stack elements bigger than 520 bytes may uplift the limit in a softfork." 12:10 < _aj_> jeremyrubin: rusty didn't want to do that, though 12:11 <@jeremyrubin> i asked rusty some clarification qs off list but he's yet to respond 12:12 <@jeremyrubin> so just to summarize *my understanding* of OP_TX, it is a new multi-byte opcode that looks like this: OP_TX<4 bytes>, the 4 byte literal being something that follows the OP_TX in script. 12:12 <@jeremyrubin> CTV would have some defined flags (e.g. 0xdeadbeef) 12:12 < harding> _aj_: yeah, but I was thinking in the context of the proposed initial v0 implemantion which would push to the stack everything CTV would check, whether it'd be possible to accidentally blow up the stack, since (as I understand it) the v0 implementation would require you to use the specific set of flags Rusty specified (which doesn't have OP_TX hash anything, I think). 12:12 <@jeremyrubin> and then scripts would look like this: 12:13 <@jeremyrubin> OP_TX0xdeadbeef OP_SHA256 EQUAL{VERIFY} 12:13 < _aj_> harding: ah, i didn't pay much attention to the initial bits; i think more functionality initially is better than less 12:13 < harding> Oh, hmm. I read it as OP_TX taking a parmeter, e.g. 0xdeadbeef OP_TX 12:13 <@jeremyrubin> future flags would be undefined, but, for example, 0xcafebabe would be a new op_success 12:14 <@jeremyrubin> harding: this is not correct AFAICT (rusty is yet to clarify) 12:14 <@jeremyrubin> If you do 0xdeadbeef OP_TX, then you cannot treat it as a OP_SUCCESS for undefined flags 12:14 < TechMiX> jeremyrubin: couldn't we just use 1 byte instead of 4 bytes? 12:14 <@jeremyrubin> TechMiX: you could in theory use a VarInt 12:15 <@jeremyrubin> but as proposed it seems fixed width 4 byte 12:15 < _aj_> TechMiX: he has about 20 bits in mind; and having a variable number of bits rather than a fixed 32 is more complicated and potentially wasteful too 12:15 < _aj_> jeremyrubin: (i talked to him about some of these things before he posted fwiw) 12:15 <@jeremyrubin> harding: also if you read the langauge closely, "OP_TX, when inside v1 tapscript, is followed by 4 bytes of flags." 12:15 < harding> jeremyrubin: oh, really? I think I saw that discussed in the previous thread but I guess I didn't understand it. I'll have to review that discussion. 12:16 <@jeremyrubin> harding: I asked him privately about these details a few days ago, but am awaiting clarification 12:16 <@jeremyrubin> _aj_ perhaps you know? 12:16 < _aj_> jeremyrubin: what you say matches my understanding of rusty's intent 12:17 <@jeremyrubin> so the question sort of becomes what is the difference between OP_TX and OP_CTV with additional flags in the future 12:18 <@jeremyrubin> to me it seems that OP_TX doesn't allow any dynamism in what it does, since you have to literally define the template hash flags 12:18 <@jeremyrubin> so, for example, OP_TX + CSFS is much less powerful than OP_CTV w/ sighash flags + CSFS? 12:19 < _aj_> huh? 12:19 < _aj_> OP_CTV is OP_TX[xxxx] SHA256 VERIFY 12:20 <@jeremyrubin> so if you had a future CTV v2 (e.g., 36 bytes, 32 byte hash + 4 bytes flags), then your CSFS could pick what flags you wanted 12:20 < harding> If OP_TX is OP_TX, then you can't choose via the witness data, right? (Since witness data fields can only be data, not opcodes.) I can't immediately think of a case where you'd want the user to choose but that seems limiting. 12:20 <@jeremyrubin> whereas with OP_TX, the flags are precomitted in the script 12:20 < harding> s/user/spender/ 12:20 <@jeremyrubin> harding: yeah that's what i'm saying 12:20 <@jeremyrubin> it's something you might want any time you want e.g. to have sighash flags dynamically today 12:21 < harding> Yep, I was having the parallel though, I'm just slower at typing. :-) 12:21 < _aj_> you can't let the witness choose the flags for CTV, because some of the flags make CTV an OP_NOP ? 12:21 <@jeremyrubin> _aj_ in the universe where CSFS is a thing 12:22 < _aj_> can't do it with TX because OP_SUCCESS is way worse than an OP_NOP 12:22 <@jeremyrubin> e.g., OP_CSFS OP_CTV 12:22 <@jeremyrubin> well you can do it with OP_TX too 12:23 <@jeremyrubin> OP_CSFS OP_TX 12:23 < _aj_> if you trigger OP_SUCCESS behaviour form OP_TX then the CSFS doesn't get evaluated? 12:23 <@jeremyrubin> nope, it *statically* can't trigger OP_SUCCESS because the flags are comitted 12:23 <@jeremyrubin> whereas with CTV, that script is fine, as long as the signer only signs with 32 byte things 12:24 <@jeremyrubin> and if 36 bytes gets defined later, then that would also be OK 12:25 <@jeremyrubin> or you have to do something like: OP_CSFS OP_SIZE <32> EQUALVERIFY OP_CTV 12:26 <@jeremyrubin> depending on how CTV flags get added (dynamic # of stack elements for flags / op_cat) then you can also commit to the flags in script. 12:26 <@jeremyrubin> but in OP_TX, since it's a multibyte opcode, you cannot have dynamic flags at all 12:27 < _aj_> so what i was talking about with roconnor's OP_TXHASH (iirc) was having two params -- one hardcoded into the opcode that gives OP_SUCCESS behaviour, and the rest of it that could be witness data that lets you choose flags; i think that's best of both worlds for this scenario 12:27 <@jeremyrubin> Do you have a link? 12:27 < _aj_> ie, you can choose which bits based from the witness if you can authenticate that somehow (or annex), and get push/success behaviour 12:28 < harding> So OP_TX ? 12:28 < harding> OP_TXHASH 12:28 <@jeremyrubin> hmmm 12:28 < _aj_> it was [flag] OP_TX[multibyte] 12:29 <@jeremyrubin> why not just use another OP_SUCCESS as OP_SEMANTICVERSION? 12:29 < harding> _aj_: cool, thanks. 12:29 <@jeremyrubin> OP_SEMANTICVERSION<4 bytes> and then you can completely change the script interpretation following it w/o burning a tapleaf? 12:29 < _aj_> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019819.html 12:30 < _aj_> jeremyrubin: seems overkill if we only want different variations of one opcode, but sure 12:31 <@jeremyrubin> What the benefit of this v.s. just doing a new opcode every time we come up with a new thing, and when we run out of opcodes-1, then doing OP_SEMANTICVERSION? 12:31 -!- TechMiX [~techtux@188.126.217.46] has quit [Quit: Leaving.] 12:32 < _aj_> you don't interfere with other opcodes, just other variations of txhash 12:32 -!- TechMiX [~techtux@188.126.217.46] has joined ##ctv-bip-review 12:32 <@jeremyrubin> i see 12:32 <@jeremyrubin> how many variations of txhash do you think we might be adding over time? 12:33 < _aj_> you could also define opcode 0xFF to be a multibyte opcode, and keep introducing new opcodes that way without the OP_SEMANTICVERSION global bump 12:33 < _aj_> i was aligning that with new-unknown-pubkey-types 12:36 <@jeremyrubin> i see 12:36 <@jeremyrubin> does anyone have a framework for evaluating the benefits of either approach or tradeoffs? 12:37 < _aj_> number of interesting applications that are immediately possible if it's activated? 12:37 <@jeremyrubin> wouldn't they be exactly equal in this case? 12:37 < _aj_> (which for me says it's not terribly interesting if only the ctv equivalent flags are able) 12:37 < _aj_> yeah 12:37 <@jeremyrubin> actually not quite 12:37 <@jeremyrubin> harding points out the stack limits 12:38 <@jeremyrubin> " Note that pushing more than 1000 12:38 <@jeremyrubin> elements on the stack or an element more than 512 bytes will hit the 12:38 <@jeremyrubin> BIP-342 resource limits and fail." 12:38 <@jeremyrubin> so without a change to that semantic as well, you'd be limited to using OP_TX for 512 byte or smaller txns 12:39 < harding> I thought OP_TX pushed each element to the stack as a separate item? 12:39 <@jeremyrubin> which is what? 11 ish outputs 1 input? 12:39 < _aj_> SELECT_OUTPUT_AMOUNT and OUTPUT_SCRIPTPUBKEY could be interesting on there own; i don't see why you wouldn't have the implicit-sha256 part be available immediately 12:40 < harding> e.g. . Otherwise, you'd really nead to have OP_CAT to build stuff for comparisons from templates? 12:40 < _aj_> harding: that's OPTX_SEPARATELY which is also unstarred like OPTX_UNHASHED 12:40 < harding> Hmm. 12:40 < _aj_> oh, _UN_HASHED, so yeah, it hashes by default unless we enable some flag to allow it not to be 12:40 < _aj_> so you can't do math on the amounts that way 12:41 <@jeremyrubin> "All other flag combinations result in OP_SUCCESS." 12:41 <@jeremyrubin> the only defined pattern is OP_CTV 12:41 <@jeremyrubin> so you can't decompose it 12:41 < _aj_> depends what we implement 12:42 < _aj_> like i said, i don't think it's interesting if it just does CTV from the start, but adding SEPARATELY and UNHASHED and maybe things to do APO equivalent behaviours might be interesting 12:42 <@jeremyrubin> sure, just reading the proposal as written 12:43 < _aj_> (going off script; i'd be interested in knowing what people think of generalised covenants these days; i'm at this point pretty positively convinced that there's no reason to limit them beyond what's easy to implement, and that fears about them are misplaced) 12:43 <@jeremyrubin> _aj_: that's the next topic, we can switch to that in a sec 12:43 < _aj_> oh yay! 12:44 <@jeremyrubin> personally i think that w.r.t. OP_TX, if people feel like it's a better upgrade path I'd be very happy to shift focus their 12:44 <@jeremyrubin> i'd just like to see a better / more thorough evaluation of CTV / NOP upgradability v.s. the multibyte op-success 12:44 < _aj_> i think it's worth exploring more before deciding, i guess 12:45 < _aj_> it feels ugly to me, but doing more is better, and might be worth some ugliness 12:45 < harding> IMO, OP_TX==OP_CTV is only a tiny bit more interesting than just OP_CTV owing to providing a very clear upgrade path. Like _aj_, I'd be a lot more interested if it came with a few more initial features. 12:45 <@jeremyrubin> i mildly see the very clear upgrade path as downside 12:45 < _aj_> y? 12:45 < harding> I do worry that we'd spend forever debating exactly what that initial feature set would be. 12:45 <@jeremyrubin> because it is more constrained 12:46 <@jeremyrubin> whereas a more open ended OP_NOP can do whatever we want it to do 12:46 < _aj_> (err, i'm afk for a bit, hopefully back rsn) 12:46 < TechMiX> what are the drawbacks/benefits of OP_TX being on tapscript? 12:46 <@jeremyrubin> eep we need you _aj_ for the next two :p 12:46 <@jeremyrubin> Coffee break anyone :D 12:47 < harding> I think we can talk without _aj_ and he can comment on scrollback when he returns. 12:47 <@jeremyrubin> it let's you have push v.s. verify semantic 12:47 < harding> In practical terms, it saves bytes for some applications. I think that's it for practical stuff, though, right? 12:47 <@jeremyrubin> push semantic is better in some senses, but ultimately they are functionally equivalent. verify is sometimes more efficient 12:48 <@jeremyrubin> harding: yeah it's split; sometimes push is better, sometimes worse 12:49 <@jeremyrubin> also another interesting 'downside' of OP_TX is that we need to split our script interpreter/parser semantic IMO 12:49 <@jeremyrubin> since they no longer parse the same -- it can be handled with flags and stuff, but you can no longer parse tapscripts with old parsers 12:52 < harding> I guess you could just make OP_TX[multibyte] OP_TX[pushdata_4][multibyte] to fix that? 12:52 < harding> I guess you could just make OP_TX[multibyte] into OP_TX[pushdata_4][multibyte] to fix that? 12:52 <@jeremyrubin> trivial example is OP_TX, where an old parser will run out of script to parse but taproot would be OK, and something like (needs padding): OP_TX OP_PUSHDATA 4 where old script would parse it OK but new script would end up getting the big pushdata 12:53 <@jeremyrubin> harding: this was part of what I asked rusty, but im not sure if it's desirable. I suspect it *is*, but it's not a big downside, just a bit of technical complexity. I think i've previously said if we need to rewrite the parsing logic we should do sub-byte opcode encoding 12:53 <@jeremyrubin> because we can save a good amount of space with huffman encoding in theory 12:54 <@jeremyrubin> ok let's go to the next topic 12:54 < harding> Yeah. I think I can agree that it's a minor downside of OP_TX vs OP_CTV. 12:54 <@jeremyrubin> #topic OP_CAT / OP_CSFS / GP Covenants 12:54 < harding> Yay! 12:54 < _aj_> gp = grand prix? 12:54 <@jeremyrubin> General Partnership 12:55 <@jeremyrubin> so i think _aj_ and harding have some feelings on this would y'all like to restate? 12:55 < harding> General Products, the Pupetter manufacturing firm of the Known Space series of stories by Larry Niven? 12:55 < _aj_> (going off script; i'd be interested in knowing what people think of generalised covenants these days; i'm at this point pretty positively convinced that there's no reason to limit them beyond what's easy to implement, and that fears about them are misplaced) 12:57 < harding> I've previously argued on list that I don't think fears about them are justified. I would like to dig further into one of ZmnSCPxj's criticisms about them making scripts harder to analyze, but that's the only outstanding criticism I'm personally concerned about in any way. 12:58 <@jeremyrubin> harding: covenants enable the roentgen standard 13:00 <@jeremyrubin> can we list out what concerns people have heard? 13:00 <@jeremyrubin> - scripts harder to analyze 13:00 <@jeremyrubin> - fungibility reduced (not wl/bl, but "appcoin" v.s. fungible privacy bitcoin as cash) 13:00 <@jeremyrubin> - MEV & consensus stability 13:00 <@jeremyrubin> - WL/BL stuff 13:01 < harding> Without regard to the generalized covenants concern, I think CAT+CSFS add the smallest amount of consensus complexity to enable the greatest amount of experimentation with covenants and other features (like signature delegation), which can provide significant data about real-world usage for informing future soft fork designs. There'd still be lots of question marks, plus chances for abuse (e.g. the sort of tx spamming we saw during the block 13:01 < harding> size debates), but I think it's worth giving devs the tools to experiment onchain (with only their and their supporters' money) and allowing economic full node operators to evualuate actual use before agreeing to enforce future soft forks whose code will need to be maintained in perpetuitity. 13:02 < harding> Consensus stability is a reference to, for example, being able to implement something like drivechains on top of CAT+CSFS? 13:03 <@jeremyrubin> i think it means > 1 thing... that is a part of it, but I also see a thing where the block selection algorithm becomes worth more energy than mining 13:03 <@jeremyrubin> and then it is snipable 13:03 < _aj_> jeremyrubin: the one i've heard more is "covenants can be imposed on my, without my consent" or at least "everyone else will accept covenants and won't be able to pay me unless i accept them too" 13:04 < _aj_> imposed on /me/ 13:04 <@jeremyrubin> right 13:04 < TechMiX> yup, heard that a lot. Here in Iranian community, people are afraid that a generalized form of the covenants would enable some kind of censorship in bitcoin. 13:04 <@jeremyrubin> also another one is that transaction graphs should be 'monotonic', e.g. always valid under reorgs. possibly, some form of covenant can break that 13:05 < harding> jeremyrubin: I don't understand what you're describing by "block selection algo becomes worth more energy than mining". 13:05 <@jeremyrubin> so look at flashbots 13:05 <@jeremyrubin> in Ethereum 13:06 <@jeremyrubin> it might, at some scale, make more money to invest in supercomputers to compute reorderings of txns than to invest in mining hardware 13:06 < _aj_> i don't think sniping value is as big a deal in a utxo/fixed-fee model vs an account/fees-are-whatever-miners-choose model 13:06 <@jeremyrubin> _aj_: disagree, look at bitmatrix for example 13:06 < harding> Ah. I think I understand. But isn't that also a concern with things like Taro? 13:06 < _aj_> presuming that's what you're referring to 13:06 <@jeremyrubin> the covenants are "self executing" and can be e.g. sandwiched 13:07 <@jeremyrubin> so given that bitmatrix is sandwich attackable, you'd see similar types of MEV as Eth sees 13:07 <@jeremyrubin> v.s. the MEV of e.g. lightning channels 13:08 < _aj_> aiui; they can be sandwiched, but it doesn't change the fees you pay, or the trade you make -- it's moving fee income from miners to whoever does thesandwiching 13:08 < _aj_> you being someone using bitmatrix for its intended purpose 13:08 <@jeremyrubin> presumably the miner is doing the sandwiching :) 13:09 < _aj_> i don't think a miner needs to sandwich, just claim any excess profit that would otherwise go to the smart contract when finalising the tx into the block 13:10 <@jeremyrubin> anyhow, i think for this meeting it's sufficient to have the claim stand that there might be a lot of energy put into MEV, depending on what gets built? 13:10 <@jeremyrubin> maybe bitmatrix is somehow uniquely MEV proof, i didn't recall that tho 13:11 < _aj_> with accounts you can say "i'll buy X at a price of up to Y" and sandwiching allows you to buy at K bitmatrix has that functionality 13:11 <@jeremyrubin> IIRC 13:12 < _aj_> maybe i should look into the details more then 13:14 <@jeremyrubin> https://www.youtube.com/watch?v=wxtGDmM7uJU 13:14 <@jeremyrubin> this is really well made explainer 13:14 < _aj_> i guess i'd rather not have that sort of MEV available, because then it makes complicated MEV extraction profitable, which then makes "smart" miners more profitable than "Dumb" ones, which is maybe centralising 13:14 <@jeremyrubin> my concern is less about centralizing in a sense, and more stability 13:14 < _aj_> but i'm not sure that's really about covenants, so much as "make better AMMs" 13:15 <@jeremyrubin> e..g, at the extreme, if 99% of value is coming from MEV, then maybe 100x more energy spent on MEV v.s. POW 13:16 <@jeremyrubin> so then if that happens, sniping becomes much more real 13:16 < _aj_> sure, and i guess my add-on is that it's easier to keep MEV a trade secret than POW techniques, which then makes it centralising too 13:17 <@jeremyrubin> yep -- it's 'snipable' but no one else might re-generate the block given inputs 13:17 <@jeremyrubin> the interesting thing to me is that this MEV is already doable in bitcoin today 13:17 <@jeremyrubin> but, it doesn't arise 'naturally' 13:18 < _aj_> sniping high fee blocks? 13:18 <@jeremyrubin> you just need to present some sort of weird computational problem which is answered by mining a tx graph rationally 13:18 < _aj_> oh theoretically? 13:18 <@jeremyrubin> _aj_: no, not fee sniping, but also running a supercomputer to select txns 13:19 <@jeremyrubin> like if you can map some computational problem onto mining transactions optimally, you could present miners with something weird/hard to optimize. in theory knapsack is good enough, but it permits epsilon good approximaters I think so it would be something else 13:20 <@jeremyrubin> but the difference is that in this case the "attacker" would be trying explicitly to set up one of these problems, and it's hard to put any external utility from the computation happening "on chain" 13:20 <@jeremyrubin> whereas with e.g. DeFI MEV, it just arises out of normal user behavior 13:21 < _aj_> harding: to restate your thoughts: you're not afraid of covenants so much as code complexity of optimised implementations of specific approaches that might end up unused? so want a general thing first, demonstrated use, then optimise later? or are there other nuances 13:22 <@jeremyrubin> to augment that: we recently found a big soundness issue in Miniscript's type system, I feel inconfident we can actually produce correct tools for more complex stuff e.g. OP_CAT/CSFS covenants. 13:22 < harding> _aj_: yeah, exactly: minimal code, max flexibility leading to demonstrated use leading to maximially efficient. 13:23 <@jeremyrubin> ah, I'm augmenting "ZmnSCPxj's criticisms about them making scripts harder to analyze" 13:24 < _aj_> that feels backwards to me; you want to make it easy to write correct scripts, not necessarily easy to analyse arbitrary scripts someone else wrote 13:25 <@jeremyrubin> well it's harding's paraphrasing of zmn's critique 13:25 <@jeremyrubin> i think zmn means analyzing the correctness of construction 13:25 < harding> jeremyrubin: doesn't the same problem exist writing consensus code in C++? 13:25 <@jeremyrubin> harding Hah! 13:25 < _aj_> jeremyrubin: it's my augmenting of your augmenting of zmn's criticism of harding's preference? :) 13:26 <@jeremyrubin> _aj_: the soundness bug in miniscript was not in the analyzing other's script, it was in the emitted code for Thresholds 13:26 * jeremyrubin bullish for just OP_NAND 13:27 < _aj_> jeremyrubin: yes, it's already hard to write script; and seems likely to be hard to write safe code using cat/csfs for more than really simple things 13:27 <@jeremyrubin> https://bitcoindevkit.org/blog/miniscript-vulnerability/ << reference 13:28 <@jeremyrubin> _aj_: yep, i agree, that's sort of what I'm saying... maybe we can make a really good "gadget" for CTV with CSFS/CAT, and use that, but it might *also* be incorrect because of random crap 13:28 <@jeremyrubin> E.g., 512 byte stack size limit 13:30 < _aj_> i think from the perspective harding suggests, it doesn't matter too much if the opcode is hard to use correctly -- if you think that, then just don't use it -- but that it's easy to validate it if it is used, and to maintain that code idefinitely 13:31 <@jeremyrubin> i'd say that is a big deal if it is hard to use correctly, because it's less likely to be used. 13:31 < _aj_> otoh, if _everyone_ thinks it's unusable (like gets()) then that would be dumb no matter how easy it is to maintain 13:31 <@jeremyrubin> E.g., would i put funds in a CTV vault v.s. in a cat/csfs vault 13:31 <@jeremyrubin> personally I think cat/csfs is not a good tradeoff space 13:31 <@jeremyrubin> it's too hard to use 13:31 < _aj_> depends on if the CTV vault was written by someone who can't calculate CTV hashes correctly :) 13:31 <@jeremyrubin> i'd sooner just add all the tx inspection opcodes 13:32 < _aj_> cat/csfs seems pretty usable for oracle authorisations 13:32 < _aj_> i'm also not convinced about it for anything much else though 13:33 <@jeremyrubin> oracle authorizations? 13:33 <@jeremyrubin> like "i allow this key" 13:33 < _aj_> "an oracle signed off on X=420" 13:33 <@jeremyrubin> ah 13:33 < _aj_> "X=420 means I can collect 420*55 sats" or whatever 13:33 <@jeremyrubin> i think you just need CSFS for that 13:34 < _aj_> okay, just about tim efor me to away again, want to wrap up? 13:34 <@jeremyrubin> sure... 13:34 <@jeremyrubin> #topic flags for script stuff 13:34 < harding> I (noncomittally) think that, if you're going to add a full-featured OP_TX, you might as well at OP_CAT as well. TX covers everything you expect you need, CAT covers anything you might not expect. 13:35 <@jeremyrubin> context https://github.com/bitcoin/bitcoin/issues/22865?notification_referrer_id=MDE4Ok5vdGlmaWNhdGlvblRocmVhZDIzNjk1ODkzNzM6ODg2NTIz¬ifications_query=reason%3Aparticipating#issuecomment-1126559608 13:36 <@jeremyrubin> i dont feel *super* strongly about this, but it's worth having more people think a bit about 13:36 <@jeremyrubin> it turns out 'doing forks the right way' (for any proposal) is kinda annoying 13:37 <@jeremyrubin> i think _aj_ your approach seems right, but i'm till not sure (not with a counterexample, just hurts brain) 13:37 <@jeremyrubin> right == correct, maybe not preferred 13:37 <@jeremyrubin> i generally like pushing complex logic to tests v.s. consensus 13:38 < _aj_> hmm, not sure i agree there; better to have simple tests so you know they're testing what you think they're testing? 13:38 < _aj_> much better to have both be simple ofc 13:38 <@jeremyrubin> do you think there might be a magic bullet both simple answer? 13:39 <@jeremyrubin> ideally to me it's just... one new flag 13:39 <@jeremyrubin> maybe also splitting out consensus v.s. non consensus flags is a good idea 13:39 -!- bucko [~bucko@136.49.133.36] has quit [Remote host closed the connection] 13:40 <@jeremyrubin> but we have some cases where it depends on output type 13:40 < _aj_> yeah, having the script interpreter do both consensus and policy decisions kind of goes against the consensus should be as simple as possible philosophy 13:41 < _aj_> output type = segwit version/p2sh/p2pkh? 13:41 <@jeremyrubin> yeah 13:42 <@jeremyrubin> some of the flags go from policy to consensus 13:42 <@jeremyrubin> which is also confusing 13:42 < _aj_> not sure what you mean? 13:43 <@jeremyrubin> uhh like all the "great consensus cleanup" stuff i think is making policy things consensus? 13:43 < _aj_> some of the policy-ish flags aren't terribly clear either https://github.com/bitcoin/bitcoin/pull/23536#discussion_r823409659 13:43 <@jeremyrubin> like cleanstack 13:43 < _aj_> oh, promoting policy rules to consensus rules? 13:43 <@jeremyrubin> well yeah, in taproot cleanstack is consensus right? 13:44 < _aj_> it's just part of taproot, it's not the cleanstack flag 13:44 <@jeremyrubin> https://github.com/bitcoin/bitcoin/blob/269dcad16e3d69f22c7a669c624beeb405111bbe/src/script/interpreter.h#L92 13:44 <@jeremyrubin> ah 13:44 <@jeremyrubin> SCRIPT_VERIFY_MINIMALDATA? 13:45 < _aj_> i think it's just minimalif for taproot, not minimaldata? 13:46 <@jeremyrubin> right 13:47 < _aj_> maybe it would be good to document exactly what rules the flags are meant to enforce (and what bips they come from)? 13:47 <@jeremyrubin> the code is kinda weird 13:47 <@jeremyrubin> https://github.com/bitcoin/bitcoin/blob/d492dc1cdaabdc52b0766bf4cba4bd73178325d0/src/script/interpreter.cpp#L621 13:48 < _aj_> so "cleanstack" would be "policy rule: enforce only one element left on the stack for [...]. note cleanstack for taproot per bip341 is part of VERIFY_TAPROOT" 13:48 < _aj_> bip342 tapscript not taproot i guess 13:48 <@jeremyrubin> it sorta looks like when the flag becomes consensus, we no longer require it to be passed because we detect it other ways 13:49 <@jeremyrubin> but we also don't require it to be set or unset in e.g. taproot, just enforced always 13:49 <@jeremyrubin> which makes sense 13:49 <@jeremyrubin> but the code ends up being weird that the flag is sorta 'optional' 13:49 <@jeremyrubin> because it also means we may not cache script executions properly 13:49 < _aj_> we never enforced cleanstack for witness v1 until taproot was defined, and still don't enforce it now; we enforce a different rule we also describe as cleanstack, but call VERIFY_TAPROOT? 13:50 <@jeremyrubin> Yeah something like that 13:50 <@jeremyrubin> but also adding the flag VERIFY_CLEANSTACK during taproot execution leads to what? 13:51 < _aj_> or alternatively we always rejected non-cleanstack and taproot payments in general due to VERIFY_DISCOURAGE_UPGRADABLE_WITNESS_PROGRAM 13:51 <@jeremyrubin> yes 13:51 < _aj_> whose comment says we still discourage v1 witnesses? (well, i guess we discourage non-32B v1 outputs) 13:52 <@jeremyrubin> not sure? 13:52 <@jeremyrubin> just to wrap the meeting, is this an OK summary: 13:53 -!- bucko [~bucko@136.49.133.36] has joined ##ctv-bip-review 13:54 <@jeremyrubin> The test flags infrastructure relies on some particular features of validity/invalidity and flagging, which has previously been avoided surfacing because upgrades were at the output type level. The way the flagging works is a not quite the right thing for testability and simple consensus code, it's worth re-evaluating? 13:55 < _aj_> we changed how "things are done" with taproot, and need to re-evaluate how we do script enforcement in light of wanting to keep doing things that way? 13:56 < _aj_> we don't really have to do things the way we did for taproot, but i thought it was kind-of nice, i guess 13:56 <@jeremyrubin> Well taproot just sidestepped the issue because it was an outputtype 13:56 < _aj_> taproot had it easy because it was an outputtype 13:57 <@jeremyrubin> yes 13:57 < _aj_> okay gtg, good talk 13:58 <@jeremyrubin> any other last words? 13:58 <@jeremyrubin> thanks _aj_! 13:59 <@jeremyrubin> ok, thanks everyone, harding TechMiX bucko! 13:59 < bucko> :wave: 13:59 <@jeremyrubin> #endmeeting 13:59 -!- TechMiX [~techtux@188.126.217.46] has left ##ctv-bip-review [] 14:24 -!- bucko [~bucko@136.49.133.36] has quit [Quit: Leaving...] 18:47 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Remote host closed the connection] 19:19 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review 19:52 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 272 seconds] 22:05 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review 22:38 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 272 seconds] 22:50 -!- redeems [~klaxa@fixed-187-190-220-54.totalplay.net] has joined ##ctv-bip-review 23:01 -!- b10c [~quassel@user/b10c] has quit [Ping timeout: 246 seconds] 23:01 -!- waxwing_ [~waxwing@193.29.57.116] has joined ##ctv-bip-review 23:01 -!- waxwing [~waxwing@193.29.57.116] has quit [Ping timeout: 246 seconds] 23:01 -!- b10c [~quassel@static.33.106.217.95.clients.your-server.de] has joined ##ctv-bip-review 23:01 -!- b10c [~quassel@static.33.106.217.95.clients.your-server.de] has quit [Changing host] 23:01 -!- b10c [~quassel@user/b10c] has joined ##ctv-bip-review --- Log closed Wed May 18 00:00:26 2022