--- Log opened Tue Jan 11 00:00:27 2022 02:00 -!- bucko [~bucko@136.49.111.169] has joined ##ctv-bip-review 02:05 -!- bucko [~bucko@136.49.111.169] has quit [Ping timeout: 256 seconds] 02:27 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review 04:20 -!- bucko [~bucko@136.49.111.169] has joined ##ctv-bip-review 04:26 -!- bucko [~bucko@136.49.111.169] has quit [Ping timeout: 240 seconds] 05:21 -!- bucko [~bucko@136.49.111.169] has joined ##ctv-bip-review 05:28 -!- bucko [~bucko@136.49.111.169] has quit [Ping timeout: 256 seconds] 07:09 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...] 07:38 -!- bucko [~bucko@136.49.111.169] has joined ##ctv-bip-review 07:42 -!- bucko [~bucko@136.49.111.169] has quit [Ping timeout: 256 seconds] 08:29 -!- pete_rizzo_33 [~pete_rizz@69.206.19.61] has joined ##ctv-bip-review 08:29 < pete_rizzo_33> 👋 i made it 08:59 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##ctv-bip-review 09:26 -!- bucko [~bucko@136.49.111.169] has joined ##ctv-bip-review 09:57 -!- iamzensored [~iamzensor@185.102.218.105.adsl.inet-telecom.org] has joined ##ctv-bip-review 10:01 -!- iamzensored [~iamzensor@185.102.218.105.adsl.inet-telecom.org] has quit [Changing host] 10:01 -!- iamzensored [~iamzensor@user/iamzensored] has joined ##ctv-bip-review 10:02 -!- prayank [~andr0irc@2402:8100:206a:19c8:6dfc:8b43:5ec0:ab23] has joined ##ctv-bip-review 10:06 < jeremyrubin> howdy pete_rizzo_33 10:14 -!- iamzensored [~iamzensor@user/iamzensored] has quit [Ping timeout: 256 seconds] 10:18 -!- Guest80 [~Guest80@2001:a61:2b30:e901:790e:3570:5e1f:3b75] has joined ##ctv-bip-review 10:26 -!- proofofkeags_ [~proofofke@205.209.24.233] has joined ##ctv-bip-review 10:26 < proofofkeags_> yo 10:26 -!- proofofkeags_ [~proofofke@205.209.24.233] has quit [Client Quit] 10:27 -!- iamzensored [~iamzensor@185.102.218.105.adsl.inet-telecom.org] has joined ##ctv-bip-review 10:27 -!- proofofkeags [~proofofke@205.209.24.233] has joined ##ctv-bip-review 10:27 < rocket_fuel__> hi all 10:27 -!- iamzensored [~iamzensor@185.102.218.105.adsl.inet-telecom.org] has quit [Changing host] 10:27 -!- iamzensored [~iamzensor@user/iamzensored] has joined ##ctv-bip-review 10:27 < iamzensored> hello everyone 10:28 < prayank> hi 10:31 -!- iamzensored [~iamzensor@user/iamzensored] has quit [Client Quit] 10:31 -!- iamzensored [~iamzensor@user/iamzensored] has joined ##ctv-bip-review 10:35 < jeremyrubin> hi 10:37 < iamzensored> i mixed up my timezones, this starts in 1.5 hours right? 10:37 < jeremyrubin> correct 10:38 < jeremyrubin> approximately 10:38 < iamzensored> great 10:42 -!- prayank [~andr0irc@2402:8100:206a:19c8:6dfc:8b43:5ec0:ab23] has quit [Quit: irc thread exit] 10:44 -!- andytoshi [~apoelstra@user/andytoshi] has joined ##ctv-bip-review 10:47 < _0x0ff> \o/ 10:49 -!- Ting_Jun [~Ting_Jun@2603-7000-a701-2362-ff60-c48f-046f-f2e6.res6.spectrum.com] has joined ##ctv-bip-review 11:01 -!- bry [~bry@104.129.205.134] has joined ##ctv-bip-review 11:05 -!- AlexL [~AlexL@165.225.57.174] has joined ##ctv-bip-review 11:08 -!- AlexL [~AlexL@165.225.57.174] has quit [Client Quit] 11:08 -!- AlexL [~AlexL@165.225.57.174] has joined ##ctv-bip-review 11:08 -!- AlexL [~AlexL@165.225.57.174] has quit [Client Quit] 11:09 -!- bry [~bry@104.129.205.134] has quit [Quit: Client closed] 11:09 -!- matthewjablack [~matthewja@ip-45-41-170-185.fibre.fibrestream.ca] has joined ##ctv-bip-review 11:34 -!- mode/##ctv-bip-review [+o jeremyrubin] by ChanServ 11:35 -!- jeremyrubin changed the topic of ##ctv-bip-review to: review for BIP-119 Check Template Verify, see https://utxos.org. Channel logged at https://gnusha.org/ctv-bip-review. Recurring meeting 12:00 PT every other Tuesday (starting January 11th). 11:38 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has joined ##ctv-bip-review 11:44 -!- jeremyrubin changed the topic of ##ctv-bip-review to: review for BIP-119 Check Template Verify, see https://utxos.org. Channel logged at https://gnusha.org/ctv-bip-review. Recurring meeting 12:00 PT every other Tuesday (starting January 11th). If you joined this meeting after the start time, please check the logs first :) 11:50 -!- criptoluis [~criptolui@186.32.73.228] has joined ##ctv-bip-review 11:58 <@jeremyrubin> starting very soon :) 11:59 -!- OP_NOP [~OP_NOP@89.45.90.229] has joined ##ctv-bip-review 11:59 < iamzensored> woo! 11:59 -!- FelixWeis [sid154231@id-154231.hampstead.irccloud.com] has joined ##ctv-bip-review 11:59 -!- kanzure [~kanzure@user/kanzure] has joined ##ctv-bip-review 12:00 <@jeremyrubin> #startmeeting 12:00 < harding> Hi. 12:00 <@jeremyrubin> #topic Welcome & Motivations (2 Minutes) 12:00 <@jeremyrubin> Hi everyone, thanks for attending the BIP-119 review meeting. There are a lot of ways you could have spent your time, and I appreciate you choosing to be here. 12:00 <@jeremyrubin> The purpose of this meeting is to improve Bitcoin. We will do that by reviewing BIP-119 CTV and considering it's eligibility and pathways for making it available to the Bitcoin network. Regardless of outcome, participating in these discussions improves Bitcoin. 12:00 <@jeremyrubin> This meeting will be moderated. I am the moderator. I will do my best to be impartial. There are a few different things I might tell you as moderator, like "this is off-topic for this meeting", "this will be on-topic in a topic coming up", or "you have made your point [and it will be in the notes]". If I am making a comment as a moderator of the 12:00 <@jeremyrubin> meeting, I'll differentiate by prefixing with "mod:". Generally, moderation is intended to ensure that everyone's time is utilized effectively and efficiently and not to censor or alter the discourse. Please be kind – if you are behaving unprofessionally or disrespectfully you will have potentially no warnings before I kick you from the meeting. 12:00 <@jeremyrubin> If you disagree with a moderation decision, you can either note it (e.g. "this is on topic now because") or you can DM me privately. I promise you I will do my best. 12:00 <@jeremyrubin> This meeting is logged at https://gnusha.org/ctv-bip-review/. I will make a summary of the discussion of this meeting and post it to the mailing list. You can reply to that summary with corrections to any inaccuracies in my summarization. 12:00 < OP_NOP> hi 12:00 <@jeremyrubin> The agenda for today can be found at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019737.html 12:00 <@jeremyrubin> Are there any questions before we begin? Feel free to say "hi" if you want your attendance marked in the logs. 12:00 < _0x0ff> hi 12:00 -!- jamesob [~jamesob@pool-108-31-54-223.washdc.fios.verizon.net] has joined ##ctv-bip-review 12:01 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Remote host closed the connection] 12:01 < kanzure> hi 12:01 < bucko> hello hello 12:02 < jamesob> hi everyone 12:02 <@jeremyrubin> #topic Overview of BIP & Q&A (40 Mins) 12:02 <@jeremyrubin> #subtopic what does CTV do? (5 minutes) 12:02 <@jeremyrubin> CTV is a OP_NOP upgrade which allows a script to 'pre-commit' to a specific transaction the coin being spent might take part in. It is implemented as essentially a signature hash digest that can be committed to directly, without a signature. CTV has applications for Vaults, Congestion Control, Payment Pools, Non-Interactive Channels, and more. 12:02 <@jeremyrubin> in the 5 minutes allocated, feel free to chat about whatever use cases are important to you / general questions :) 12:03 <@jeremyrubin> as you'll notice I have a little pre-text for each topic to make the meeting efficient, but feel free to jump in with questions. 12:03 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:c93f:fd60:20bc:86f3] has joined ##ctv-bip-review 12:03 < iamzensored> hi 12:03 -!- josedrobles [~jdrobpar@32.red-88-3-64.dynamicip.rima-tde.net] has joined ##ctv-bip-review 12:03 < jamesob> I'm really interested in vaults. Even single-hop (obviously non-recursive) vaults would be a huge improvement for custody over what we have today. Right now, in order to do similar patterns you have to generate ephemeral keys and retain presigned transactions which is problematic for a variety of reasons (e.g. fee projection, compliance) 12:04 < criptoluis> Hello everyone 12:04 < josedrobles> hi everyone 12:04 < criptoluis> I think the concrete use cases is what interests the most to the community, but first things first 12:04 -!- bryan28 [~bryan@104.129.205.134] has joined ##ctv-bip-review 12:05 <@jeremyrubin> vaults are definitely a high value use case for me :)note that fee projection/cpfp remains a challenge for CTV users 12:05 < bucko> +1 on vaults. Nice topic in particular since it'll likely be the fastest "to market" after an activation so quickest way to see community pay off. 12:05 < _0x0ff> Non-interactive channels seem like a really great addition to LN. Have you received any feedback from there? If yes, what were their thoughts - are they keen on using CTV for non-interactive channel or do they favor a different OP code? 12:05 <@jeremyrubin> bucko: good point -- vaults aren't "networked" so individual adoption 12:06 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has joined ##ctv-bip-review 12:06 < iamzensored> I'm also most interested in vaults. To jamesob's point a lot of the solutions/robust vaults today require either presigned commitments or trusted intermediaries assuming far too much control. There's also little room for error and contingency planning. 12:06 <@jeremyrubin> mod: 1 minute remaining on this topic 12:06 < harding> I have some concerns that the BIP rationale seems to focus heavily on congestion control but I'm not personally convinced that will ever be used. We'd first need to see more high-frequency spenders using payment batching (which we are, a little bit) and then we'd need receiver wallets to support receiving payment information out of band, and then we'd need to deal with the problems related to spinning out the congestion control UTXOs into their 12:06 < harding> individual UTXOs. So I'm a little dubious that's a strong use case, and I wonder if there would be a better design for the other use cases if it seemed to be less optimized for congestion control. 12:06 < OP_NOP> I'm most interested in protocol additions that improve privacy, which sounds like what Payment Pools could do 12:06 < ryanthegentry> _0x0ff: I'd recommend these tweets from Muun Wallet who has signaled in favor of CTV. Very practical use case https://twitter.com/MuunWallet/status/1478159869001625601?s=20 12:07 < ryanthegentry> (and well-explained IMO) 12:07 < iamzensored> I'm also partial to the improvement that will come when settling/closing Lightning channels 12:07 <@jeremyrubin> harding: i thinkl ryanthegentry's answer also covers real use 12:07 < jamesob> harding: for what it's worth congestion control doesn't really interest me either (not to say it couldn't be useful someday). I think CTV's marketing has been hurt somewhat by that emphasis 12:07 -!- rgrant [~rgrant@user/rgrant] has joined ##ctv-bip-review 12:07 <@jeremyrubin> ok buckle up this is a fast meeting :) 12:07 <@jeremyrubin> #subtopic which fields are in the digest? (5 minutes) 12:07 <@jeremyrubin> CTV commits to nVersion, nLockTime, a hash of all scriptSigs (or nothing if none), the input count, a sequence hash, the output count, a hash of all outputs, and the input index when it is being spent. CTV does not commit to (directly) any witness data nor does it commit to any specific previous output. All variable length field hashes are 12:07 <@jeremyrubin> pre-computed to avoid denial-of-service through quadratic hashing. 12:07 <@jeremyrubin> does anyone have questions on what is comitted to and why? 12:08 < bucko> Maybe just a quick explanation of why quadratic was a concern since I know that was brought up recently on the mailing list 12:08 <@jeremyrubin> Sure 12:08 <@jeremyrubin> The quad hashing issue arrises when a script like CTV..... CTV CTV is used 12:08 < harding> jeremyrubin, ryanthegentry: I'm making a note to look more into why CTV is needed for that. I thought LN dual funding would allow addressing third-party funding without consensus changes required. 12:09 <@jeremyrubin> if each evaluation of CTV requires N computational work, and there are M CTVs, the total cost is O(M*N) 12:09 < rgrant> i'm interested in whether it's potentially feasible to use additional witness data. presumably it's not being signed right now because that would be additional complication to define/code/test. 12:09 <@jeremyrubin> particularly because CTV commits to variable length fields this issue can occur. 12:09 <@jeremyrubin> But because they are cached, this is not an issue during validation. 12:10 <@jeremyrubin> rgrant: witnesses are uncomitted by CTV, otherwise things like signatures would create a hash cycle 12:10 <@jeremyrubin> and then it would be impossible to spend 12:10 < iamzensored> For quad hashing it's just whoever is constructing the transaction that needs to perform it right? A node validating a new CTV transaction would only compute what was relevant for the next output but not any further? 12:10 <@jeremyrubin> so because we want CTV + Signatures, witnesses are out 12:10 < ryanthegentry> harding: this is particularly useful for users that don't have any funds yet (so couldn't contribute to a dual-funded channel). Happy to discuss offline, don't want to hijack the meeting 12:11 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Remote host closed the connection] 12:11 <@jeremyrubin> iamzensored: incorrect, this is an issue during validation 12:11 < rgrant> okay, i wondered if defining additional data that isn't signatures would be possible. 12:11 <@jeremyrubin> it has existed previously as an issue for CHECKSIG 12:11 < jamesob> jeremyrubin: is there any concern of the CTV hash cache being overwhelmed or filled up during validation? I assume the cache only needs to exist for the lifetime a single txn validation, is that right? 12:11 <@jeremyrubin> rgrant: maybe it can be in OP_RETURN? that is covered by CTV 12:11 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has joined ##ctv-bip-review 12:11 <@jeremyrubin> mod: 1 minute 12:11 < rgrant> thx 12:11 <@jeremyrubin> jamesob: nope, it's similar to the existing precomputed data cache 12:12 <@jeremyrubin> IIRC it only adds ~32 byes per tx of new cache entries 12:12 <@jeremyrubin> #subtopic the order / structure of fields in the digest? (5 minutes) 12:12 <@jeremyrubin> The order of the fields is set up such that the fields most "likely to change" come later in the digest so as to make future script upgrades (e.g., OP_SHASTREAM) more efficient at constructing templates on the stack. This is a 'best educated guess' at an order, as any order has tradeoffs. If there is no scriptSigs, as might be common, the field is 12:12 <@jeremyrubin> not committed to directly. 12:13 <@jeremyrubin> Does anyone have any questions about the structure of the hash? 12:14 <@jeremyrubin> jamesob: on prior topic, these are created and stored in a vector for the lifetime of block validation and then erased. They're cheap to compute, O(N) simple hashes over transaction. They could be erased earlier individually, but then you'd have some allocation overheads 12:14 < jamesob> yup, makes sense 12:14 -!- _tnull [~tnull@user/tnull/x-8645464] has joined ##ctv-bip-review 12:15 < jamesob> as long as there isn't anything that outlives an individual block validation, that sounds fine 12:15 -!- llfourn [sid528290@id-528290.lymington.irccloud.com] has joined ##ctv-bip-review 12:15 <@jeremyrubin> jamesob yup, similar to (and using) existing caches for signature checking 12:16 <@jeremyrubin> jamesob: the only "new" cache line is the scriptSigs hash 12:16 < jamesob> for anyone following along, here's some relevant code in the PR: https://github.com/bitcoin/bitcoin/pull/21702/files#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R1460-R1488 12:16 <@jeremyrubin> mod: 1 minute left on the order-of-fields topic. 12:17 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Remote host closed the connection] 12:17 <@jeremyrubin> it's not the most exciting thing, and definitely something worth being aware of and mulling over after the meeting :) 12:17 < OP_NOP> Makes sense 12:17 <@jeremyrubin> #subtopic the half-spend problem/solution? (5 minutes) 12:17 <@jeremyrubin> Imagine a covenant C without a commitment to input index expresses that it has 2 inputs and creates an output with 1 Bitcoin. If you instantiate said covenant in two instances, X and Y with 1 Bitcoin each, you can form a single transaction that spends 1 Bitcoin as fees and creates only 1 output. Thus, CTV commits to the input index that it is being 12:17 <@jeremyrubin> spent at which makes multiple instances of the same CTV clause not 'half-spendable'. Half spend-ability can be opted into by providing alternative CTV hashes for each index. 12:18 -!- Guest [~Guest@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##ctv-bip-review 12:18 <@jeremyrubin> Does anyone have any questions about half spends, why they are bad, and how to opt out of it / into it? 12:18 -!- Cubicearth3 [~Cubiceart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##ctv-bip-review 12:18 < Cubicearth3> Hi 12:19 < OP_NOP> Is there tooling to detect such cases and warn the user? 12:19 <@jeremyrubin> it's not possible with basic use of CTV 12:19 < jamesob> OP_NOP: as I understand it, you can't _not_ commit to the input index being spent, based on the definition of the hash 12:19 < jamesob> in the code linked above 12:19 <@jeremyrubin> Sapio also always generates spends at index 0, so sapio won't have the issue on any of it's outputs 12:19 < _0x0ff> why would one opt-in to it? 12:20 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined ##ctv-bip-review 12:20 < iamzensored> To clarify "not possible with basic use of CTV" you mean not possible to accidentally half spend? 12:20 <@jeremyrubin> iamzensored: correct 12:20 <@jeremyrubin> _0x0ff: you might opt-in if you wanted to make a transaction where you were happy to be at any input index to combine with another unknown output that might be more restricted 12:20 < _0x0ff> gotcha, thanks 12:21 <@jeremyrubin> opting in would be, e.g., CTV OR. CTV 12:21 <@jeremyrubin> so you have to commit to the indexes you could appear at, so it remains analyzable 12:21 <@jeremyrubin> (or, in the future, OP_CAT) 12:21 < iamzensored> So does this break the general assumption that a UTXO is either spent or not spent? 12:22 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has joined ##ctv-bip-review 12:22 < iamzensored> *TX 12:22 <@jeremyrubin> iamzensored: nope; it just means that utxos with the same address (assuming it's just CTV) can';t be in the same tx, provably 12:22 <@jeremyrubin> mod: < 1 min on this remaining 12:22 < jamesob> jeremyrubin: did you write a cool bot to do those? :p 12:22 -!- Guest [~Guest@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 256 seconds] 12:22 <@jeremyrubin> jamesob: it me, bot 12:23 < jamesob> naturally 12:23 <@jeremyrubin> #subtopic using a NOP v.s. successX / legacy script types? (5 minutes) 12:23 <@jeremyrubin> CTV takes over a NOP opcode rather than a successX in tapscript. This is for two main reasons: 1) we want CTV available in bare script for certain efficiency driven use cases, 2) a suite of generic OP_PUSHTXDATA opcodes enable much more powerful covenant types. 12:23 <@jeremyrubin> This is possibly controversial. It would be possible to e.g. only do Taproot Script for now and add legacy later if we thought we wanted it. 12:24 < iamzensored> How many NOP opcodes remain? 12:24 <@jeremyrubin> I felt the simplest and best is to add it for all and let the market decide, but this is definitely something narrowable. 12:24 < jamesob> "only do Taproot Script for now" strikes me as too much deployment complexity; 2 soft-fork processes vs. 1 12:24 < bucko> narrowable meaning open for debate about where to enable it? 12:24 <@jeremyrubin> iamzensored: good question, I'm not sure how many can be reinterpreted in legacy script 12:24 < ryanthegentry> what benefits would be traded off if legacy was not added? I assume congestion control stuff? 12:24 <@jeremyrubin> bucko: correct. 12:25 <@jeremyrubin> ryanthegentry: correct. certain congestion control "proofs" rely on byte counting assuming legacy script. those are narrow margins to show that CTV doesn't use more bytes overall 12:25 < iamzensored> https://en.bitcoin.it/wiki/Script might help answer that and give an idea of how expensive this is 12:25 < harding> Using taproot would also provide benefits, though, right? Such as being able to put CTV in a branch that never gets used. 12:26 < harding> tapscript* 12:26 < jamesob> harding: IIUC, the implementation as written is usable with Tapscript 12:26 <@jeremyrubin> iamzensored: I guess 6 remaining? 12:26 < rgrant> jamesob: +1 12:26 -!- Guest33 [~Guest33@2a01:799:18e0:4800:a925:1125:f395:683b] has joined ##ctv-bip-review 12:26 <@jeremyrubin> yes, currently it is "available in all contexts" 12:27 <@jeremyrubin> except (kinda) p2sh there's a hash cycle 12:27 < harding> I think we basically have unlimited OP_NOPxs if we don't mind pushing an extra byte or two on the stack with OP_NOP10 to determine context. 12:27 <@jeremyrubin> harding: +1 12:27 <@jeremyrubin> mod: 1 min... 12:27 < bucko> what's the argument for doing it in tapscript only for now? 12:27 <@jeremyrubin> bucko: don't encourage legacy use? don't define new standard bare CTV type? 12:28 <@jeremyrubin> sanket1729 I think had some thoughts on this 12:28 <@jeremyrubin> #subtopic using sha256 v.s. Ripemd160 (5 minutes) 12:28 <@jeremyrubin> CTV uses the sha256 digest (32 bytes) rather than ripemd160 (20 bytes). It would be possible to permit both, if desired, or only one. While RIPEMD160 should be secure, 32 bytes is a more conservative choice. 12:28 < harding> Even if all your codepaths are CTV, you still get privacy until spending from using P2TR. 12:28 <@jeremyrubin> Does anyone actually want to discuss this? happy to reallocate the time to general disucssion 12:28 < bucko> oh as in we don't want people using non-taproot in the future so only define there 12:28 < iamzensored> Not a very technical argument but anyone using CTV is likely well aware of legacy tradeoffs and at the option of what fits for their use case 12:29 <@jeremyrubin> mod: 30 seconds to just say "i want to discuss" otherwise next. 12:29 < harding> +1 for SHA256. 12:29 -!- Cubicearth3 [~Cubiceart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 12:29 -!- Cubicearth3 [~Cubiceart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##ctv-bip-review 12:29 <@jeremyrubin> ok cool 12:29 -!- Cubicearth3 [~Cubiceart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 12:29 <@jeremyrubin> #subtopic general q&a (14 Minutes) 12:29 <@jeremyrubin> Are there any questions we didn't get to that you would like to either discuss now or make note of for future meetings? 12:29 < jamesob> harding: curious for your rationale - just general conservatism? 12:30 < OP_NOP> Do the bare CTV outputs create a new address type? 12:30 <@jeremyrubin> ok now we can circle back or discuss more generally / bio break. 12:30 <@jeremyrubin> OP_NOP: they could, but not for the time being 12:31 <@jeremyrubin> I don't think end users would use it, but more could be used inside of a software stack. New addr could be bech32m I think if needed? 12:31 -!- Cubucearth2 [~Cubuceart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##ctv-bip-review 12:31 <@jeremyrubin> We also didn't really discuss PUSHTXDATA v.s. NOP if anyone has questiuons there 12:31 < harding> jamesob: basically. RIPEMD is nowhere near as well studied as SHA2. At least with RIPEMD(SHA256()), we *might* get some protection in the case of a break in RIPEMD, but going with just RIPEMD seems bad. Doing both is also kinda meh to me now that we're moving everyone over to 32-byte commitments in P2TR anyway. 12:34 < harding> ryanthegentry: back to third-party funding, maybe see https://bitcoin.stackexchange.com/questions/107786/will-ln-liquidity-advertisements-and-dual-funding-allow-for-third-party-purchase/108175#108175 ; in general, I think third-party funding just requires the channel opener to have an out-of-band connection with the channel co-owner and for the opener to use the owner's keys in the protocol. I don't think consensus changes are required for that 12:34 < harding> purpose. 12:34 -!- Cubucearth2 [~Cubuceart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 12:34 < jamesob> harding: yep, makes sense 12:34 <@jeremyrubin> if anyone is curious, https://utxos.org/analysis/batching_sim/ shows the byte counting for why legacy might be relevant. If you care about "doesn't CTV use more block space with congestion control" the answer is "sometimes it saves a little space and congestion control is free" 12:34 < harding> (But the idea of CTV for third-party channel funding is new to me, so I need to understand why that's being proposed better.) 12:35 <@jeremyrubin> harding: the non interactivity flow kinda works as follows: receive instructions to open, aggregate instructions from N users, create open for N users at once 12:35 <@jeremyrubin> that you have to have some sort of ID / request for the user matters, but it's that the actual opening part no longer has them in the loop that is relevant 12:35 <@jeremyrubin> otherwise the protocol can't scale as a single user can DoS it 12:36 < iamzensored> CTV would eliminate the need for an out-of-band connection no? 12:36 <@jeremyrubin> iamzensored: it depends on the protocol, it makes the connection fully asynchronous? 12:36 <@jeremyrubin> you still need to relay information, just non-blockingly so 12:36 -!- Cubucearth2 [~Cubuceart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##ctv-bip-review 12:36 < iamzensored> Got it 12:37 -!- Cubucearth2 [~Cubuceart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 12:37 <@jeremyrubin> that ends up being a big deal, if you are trying to e.g. aggregate channel openings for 1000 people 12:37 < harding> jeremyrubin: ah, that makes sense. I don't find that sort of reasoning super-compelling---I'd like to see an interactive protocol deployed and widely used before we change consensus to make the non-interactive version possible. After all, things like Coinjoins now have dozens, sometimes hundreds, of simultaneous participants, so simple DoSing isn't necessarily a deal killer. 12:37 <@jeremyrubin> i dont think the interactive version is possible 12:38 <@jeremyrubin> so no one will spend a single eng cycle on it :) 12:38 <@jeremyrubin> the DoS issue isn't even out of negligence, it's just like "had a bad connection" 12:38 < harding> Sure, but again people do large coinjoins now, which have the same problem. 12:39 <@jeremyrubin> harding: coinjoins at least permit a single circle sign 12:39 < iamzensored> Worth noting that interactive communication protocols often end up not interoperable with each other. A non-interactive option might improve this since no one needs to run the infra 12:39 <@jeremyrubin> this requires active back and forth not just "post to bulletin once" 12:39 <@jeremyrubin> but point taken overall harding 12:40 < ryanthegentry> we should try to get Dario from Muun in one of these to explain those tweets better 12:40 <@jeremyrubin> mod: 2 minutes or so left 12:40 < bucko> +1 12:40 < ryanthegentry> they do some funky non-standard stuff that I only 3/4 grok 12:41 <@jeremyrubin> part of the nice thing is the proofs for CTV batch open are fully non-networked software and simple. Then you just need to say "OK channel is open" (unconf channels use the same logic on that). 12:41 <@jeremyrubin> Whereas an interactive software to create them requires "non fungible proofs" 12:41 < ryanthegentry> harding: it's possible that they have the interactive protocol that you're looking for deployed, but just haven't spec'd it out 12:41 -!- Guest33 [~Guest33@2a01:799:18e0:4800:a925:1125:f395:683b] has quit [Quit: Client closed] 12:41 < harding> Just to be clear, it's great if we get something like batched LN third-party opens for free from an already-planned consensus change. I just don't count something like that as a strong motivator for the consensus change by itself in the absense of known problems in an existing implementation. That's especially the case since I *think* without checking the math, that 90% of the benefit from a batched open is going to come from the first ~10 12:41 < harding> participants. Scaling up to 1000 participants only increases your efficiency marginally more. 12:42 <@jeremyrubin> harding: that's a good point. 90% is 90% :) 12:43 <@jeremyrubin> #topic Overview of Implementation & Testing (30 Minutes) 12:43 <@jeremyrubin> #subtopic implementation walkthrough (15 minutes) 12:43 <@jeremyrubin> The PR for the BIP can be found at https://github.com/bitcoin/bitcoin/pull/21702. In this subtopic we'll do a quick walkthrough of the "main commits" for CTV. 12:43 <@jeremyrubin> #subsubtopic Add StandardTemplateHash definition https://github.com/bitcoin/bitcoin/pull/21702/commits/51f0bdd36328f1c9334ad455a56f7cb47d76abda 12:43 <@jeremyrubin> In this commit we define what the hash digests are to make the CTV Template Hash. 12:44 <@jeremyrubin> mod: this is going to be pretty fast, just a few minutes per commit. not a thorough review :) 12:45 <@jeremyrubin> Any question here? 12:45 <@jeremyrubin> mod: 1 minute 12:46 <@jeremyrubin> feel free to leave comments on GH btw 12:46 <@jeremyrubin> #subsubtopic Add SignatureChecker method for checking DefaultCheckTemplateVerifyHash. https://github.com/bitcoin/bitcoin/pull/21702/commits/479b0c9c164437701d1a70e4026fc19902d56e14 12:46 <@jeremyrubin> In this commit we define a SignatureChecker functionality for checking the CTV Template Hash. Checker is used to pass transaction context to script execution. 12:47 <@jeremyrubin> Does anyone have any questions about adding the checker? 12:47 <@jeremyrubin> mod: 1 min 12:48 -!- groot69 [~groot69@188-143-109-228.pool.digikabel.hu] has joined ##ctv-bip-review 12:48 < bucko> how was the attempt at expanding coverage there going? 12:48 <@jeremyrubin> bucko: I think there's pretty much only 1 line uncovered, and it's a line that's for stuff that's in tx signing logic not validation 12:48 <@jeremyrubin> bucko: hence hard to cover without a lot of extra work 12:48 < bucko> The comment above it looks like maybe it's already being checked basically? 12:49 <@jeremyrubin> I think so? 12:49 <@jeremyrubin> #subsubtopic Add OP_CHECKTEMPLATEVERIFY Opcode as OP_NOP4 https://github.com/bitcoin/bitcoin/pull/21702/commits/0543f61365b65218ba9a9a1406702e3ecd4fd726 12:49 <@jeremyrubin> In this commit we define the logic for the opcode of checktemplateverify. We only define behavior for 32 byte arguments. 12:49 <@jeremyrubin> does anyone have any questions abou the opcode definition? 12:50 <@jeremyrubin> mod: 1 min 12:51 <@jeremyrubin> 1 non obvious thing is how much we discourage the opcode. 12:51 < bucko> Meaning? 12:51 <@jeremyrubin> previously opcode soft forks have been more tolerant of spends before activation, but here we are very strict to discourage until active 12:51 <@jeremyrubin> #subsubtopic Precompute the DefaultCheckTemplateVerifyHash 12:51 <@jeremyrubin> https://github.com/bitcoin/bitcoin/pull/21702/commits/b6d2ba82fd55ce83aac1f8d910781a3166abb9b9 12:51 <@jeremyrubin> In this commit we define the logic for verifying checktemplateverify from caches, solving validation resource exhaustion issues. 12:51 < bucko> i.e. this: > // if flags not enabled; treat as a NOP4 12:52 <@jeremyrubin> bucko: right 12:52 <@jeremyrubin> bucko: and not just treat, but discourage for policy. previously it was just "this is a nop" 12:52 < bucko> any particular reason to do it differently other than optics? (or was there a reason not ot care as much before) 12:52 <@jeremyrubin> bucko: it was a bug to have done it the other way previously IMO 12:53 <@jeremyrubin> This is an important topic here :) 12:53 <@jeremyrubin> using the cache solves for DoS issues. 12:53 <@jeremyrubin> without caching, an evil tx can have CTV .... CTV and use N^2 time 12:53 <@jeremyrubin> mod: 1 min 12:53 <@jeremyrubin> Caching means all computation is fixed 12:54 < bucko> this mod is a real slave driver 12:54 <@jeremyrubin> Note that caches are *required* during consensus, the alternative path is for signing logic which.... 12:54 <@jeremyrubin> #subsubtopic Use HandleMissingData for unexpected missing precomputed data 12:54 <@jeremyrubin> https://github.com/bitcoin/bitcoin/pull/21702/commits/4c823859fc2e46606d13eef8d21ce7aa1fe3edea 12:55 <@jeremyrubin> Cleanups to the signing logic code paths make the "handlemissingdata" (i.e., no cache) more explicit. 12:55 <@jeremyrubin> This is the line that's hard to get coverage for bucko 12:55 < bucko> for the previous one, what's the status of the TODO? "// TODO: Improve this heuristic" which sounds like became a thing after taproot 12:55 <@jeremyrubin> but it does remove the potentially N^2 computation from the interpreter logic 12:56 <@jeremyrubin> bucko: taproot made the cache heuristics more agressive than they were previously, CTV undoes this a little bit to cache more data. 12:56 < bucko> is that still a TODO though? 12:56 <@jeremyrubin> mod: 30s 12:56 < iamzensored> Is there a performance impact to changing these heuristics? 12:57 <@jeremyrubin> bucko: good question. i meant it more as a "someone could work on this" than "must be done" 12:57 < bucko> ah 12:57 -!- _tnull [~tnull@user/tnull/x-8645464] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 12:58 <@jeremyrubin> iamzensored: worth considering further -- i have some thoughts to share on it after meeting (i don't think it matters as it's not much worse than it was before, the cache optimizations were added late stage on taproot and I would have NACKd if I thought it'd interfere with CTV) 12:58 <@jeremyrubin> #subsubtopic Make Bare OP_CHECKTEMPLATEVERIFY basic transactions standard 12:58 <@jeremyrubin> https://github.com/bitcoin/bitcoin/pull/21702/commits/b08fd3717d2751389f599fa89de626465e4da110 12:58 <@jeremyrubin> In this commit we define a standard bare script for CTV that is quick to verify. 12:59 <@jeremyrubin> Here we define a bare ` CTV` as a relayable script with no scriptSigs and one input 12:59 <@jeremyrubin> This can be used for e.g. congestion control 12:59 < ryanthegentry> so this specific part could be controversial given that it incentivizes using legacy addresses right? 12:59 <@jeremyrubin> it is also bikesheddable, could be done later, but it does make testing harder to do. 12:59 <@jeremyrubin> ryanthegentry: correct 12:59 < ryanthegentry> and is the part referred to earlier that could be done later, yeah 13:00 <@jeremyrubin> ryanthegentry: no 13:00 < ryanthegentry> oh no 13:00 <@jeremyrubin> both can be done later, this is the *policy* and is a p2p upgrade 13:00 <@jeremyrubin> legacy *at all* is consensus 13:00 <@jeremyrubin> mod: 1 min 13:00 <@jeremyrubin> so it could be {legacy consensus + legacy policy, legacy consensus no policy, no consensus no policy} 13:01 <@jeremyrubin> #subtopic vectors: tx_valid.json + tx_invalid.json + transaction hashes checking (2 minutes) 13:01 <@jeremyrubin> https://github.com/bitcoin/bitcoin/blob/3109df5616796282786706738994a5b97b8a5a38/src/test/data/ctvhash.json 13:01 <@jeremyrubin> https://github.com/bitcoin/bitcoin/blob/3109df5616796282786706738994a5b97b8a5a38/src/test/data/tx_invalid.json 13:01 <@jeremyrubin> https://github.com/bitcoin/bitcoin/blob/3109df5616796282786706738994a5b97b8a5a38/src/test/data/tx_valid.json 13:01 <@jeremyrubin> There's not a whole lot to discuss here. 13:01 <@jeremyrubin> Test vectors exist, you can use them as you please 13:02 -!- Cubic1 [~Cubic1@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##ctv-bip-review 13:02 <@jeremyrubin> DISCOURAGE_UPGRADABLE_NOPS is kinda broken as a flag a little (this is "understood" by some devs) and requires some special new test vector code because of the thing I discussed earlier. 13:02 <@jeremyrubin> (making NOP restrictive till active) 13:03 <@jeremyrubin> there are valid txn, invalid txn, and hash computation vectors that should aid verification of alt impls. 13:03 < iamzensored> Where's the code that generated these tests? I assume you didn't manually type out the bytes :) 13:03 <@jeremyrubin> mod: 30s 13:03 <@jeremyrubin> iamzensored: i basically did... i generated them from the python tests 13:03 <@jeremyrubin> iamzensored: spent an afternoon doing it 13:03 < iamzensored> I guess my question is what assurance is there that the tests match their description here? 13:04 <@jeremyrubin> iamzensored: decoderawtransaction? 13:04 <@jeremyrubin> it's a good point, but I don't think documentation can help 13:04 <@jeremyrubin> REQUEST FOR CODE: please convert the hex txns to jsons? 13:04 <@jeremyrubin> that could be a high value automated PR 13:04 <@jeremyrubin> #subtopic functional test walkthrough (8 minutes) 13:04 <@jeremyrubin> Comprehensive functional tests are available here: 13:04 <@jeremyrubin> https://github.com/bitcoin/bitcoin/blob/3109df5616796282786706738994a5b97b8a5a38/test/functional/feature_checktemplateverify.py 13:05 < iamzensored> That would make manual inspection of the tests easier 13:05 <@jeremyrubin> iamzensored: yeah, would require changes across core but I think would be great to do 13:06 <@jeremyrubin> The way the tests are set up we basically create a bunch of scripts, then fund outputs for them, and try/fail/succeed at spending them in different ways 13:06 <@jeremyrubin> There's pretty wide coverage of scenarios 13:06 <@jeremyrubin> iamzensored: if you note my hash mutation tests are more human readable :) 13:07 <@jeremyrubin> iamzensored: but tx hex as json would make the files big but maybe worth it. will review if anyone PRs it 13:07 <@jeremyrubin> Does anyone have any questions or comments about the python tests? 13:08 -!- Guest80 [~Guest80@2001:a61:2b30:e901:790e:3570:5e1f:3b75] has quit [Quit: Client closed] 13:08 <@jeremyrubin> obviously hard to fully review in this context, but more as a starting point for review 13:08 < iamzensored> Is there overlap between these tests and the others? 13:09 <@jeremyrubin> iamzensored: yes I think all covered here should have a corresponding test vector 13:09 <@jeremyrubin> in theory we could make this just check the test vectors, but this is sort of the "proof the txs correspond to what i say" 13:09 <@jeremyrubin> since these are made programmatically 13:09 -!- Guest51 [~Guest51@pool-70-104-203-222.nrflva.fios.verizon.net] has joined ##ctv-bip-review 13:10 <@jeremyrubin> but these use entropy so it will differ every time 13:10 -!- Cubic1 [~Cubic1@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 13:10 < iamzensored> Got it, thanks for clarifying 13:10 -!- Cubic1 [~Cubic1@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##ctv-bip-review 13:11 <@jeremyrubin> mod: 2 mins 13:11 -!- Cubic1 [~Cubic1@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 13:11 -!- Cubic1 [~Cubic1@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##ctv-bip-review 13:12 <@jeremyrubin> the standard type for bare is kinda clear here -- it's hard to test CTV in bare script without a type that allows it 13:12 <@jeremyrubin> if we were to want to remove it, I'd probably remove it by adding a conf option to enable it and have it off by default 13:12 <@jeremyrubin> otherwise testing CTV in bare is :( 13:13 <@jeremyrubin> ok 13:13 -!- Cubic1 [~Cubic1@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 13:13 <@jeremyrubin> #topic Feedback on how to Structure Bounty Program (10 minutes) 13:13 <@jeremyrubin> The bounty program began as a personal offer for $10,000 if someone were to find a 'showstopping' bug in the CTV BIP or Implementation. This was originally sufficient, but since then > 5BTC has shown interest in supporting bounties for CTV. How best should we administer this to drive CTV forward? Who should judge the severity of an issue? Should 13:13 <@jeremyrubin> non-showstopping issues get bounties? Should we award detailed reviews writeups with no bugs found? 13:13 <@jeremyrubin> I also have a note from someone who couldn't attend this meeting 13:13 <@jeremyrubin> Note from Ariel if not present: Lincoln Network is a non-profit dedicated to promoting liberty through digital innovation. We’ve helped sponsor the plebFi events, and are actively looking for other ways to contribute to the btc ecosystem. We like to offer to proxy CTV bounties through Lincoln in order to make them tax deductible, and further 13:13 <@jeremyrubin> incentivize more funds allocated to vetting CTV. This can be facilitated through a multi sig wallet, with community key holders being independent judges of whether a bounties conditions are met or not. If successful, we’d seek to make this system more generally applicable to any other BIPs as well. 13:14 -!- Cubic1 [~Cubic1@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##ctv-bip-review 13:14 <@jeremyrubin> Does anyone have any thoughts on how to best leverage community availble funds for review here? 13:14 -!- Cubic1 [~Cubic1@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 13:14 < rgrant> i think leaving some aside for maintenance mode will increase confidence that this code won't be technical debt for someone else to clean up. 13:14 -!- Cubic1 [~Cubic1@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##ctv-bip-review 13:15 < bucko> I definitely think splitting up and including support for non-showstopping could be good as well. 13:15 < rgrant> +1 to non-showstopping. 13:15 < iamzensored> I'd think besides the details the > 5 BTC commitment should be escrowed somewhere where someone working on bugs/improvements is reasonably assured that those offering the rewards will pay up 13:15 < ryanthegentry> help fund a covenant-specific conference where people can have time to prepare and present more thought-out ideas a la Scaling Bitcoin 2016? 13:15 < ryanthegentry> this doesn't really fit the aggressive timeline tho 13:16 <@jeremyrubin> iamzensored: the issue is that for me personally at least, I planned to not have to pay anything for it at all so didn't want to move funds if unneeded (i.e., skin in the game there is no bug) 13:16 < harding> I always liked Greg Maxwell's idea for funding bug finding in libsecp256k1---bounties for anyone who is able to create a patch that introduces a bug that the tests don't catch. 13:16 <@jeremyrubin> I think having lincoln help helps with that, since it's now a 501c3 donation 13:16 < _0x0ff> +1 bucko and iamzensored 13:17 <@jeremyrubin> but will circle up with sponsors (who I think are absolutely good for the money) if they are OK comitting funds even if no bug found 13:17 < ryanthegentry> (to be clear: using Jeremy's term of "maximally aggressive" from the advent calendar, I don't think it's aggressive) 13:17 < bucko> The way HRF and Strike structured some of their bounties could be good for pushing CTV forward (or even the broader goals that CTV seeks to achieve), e.g. displaying actionable usecases. But it's hard b/c we don't know for sure what the dedicated funders wanted to sign up for. Maybe it was just showstopping bug 13:17 < bucko> +1 to harding proposal 13:17 < OP_NOP> +1 harding 13:18 <@jeremyrubin> let's assume I can talk to them and get them on board with whatever helps get CTV into bitcoin or rejected 13:18 < iamzensored> Virtual hackathons aren't too pricey, mostly just rewards, just need topics and people willing to hack 13:18 < iamzensored> re: ryanthegentry's point 13:18 <@jeremyrubin> harding: idk how that would work though? 13:18 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Remote host closed the connection] 13:18 <@jeremyrubin> it is pretty easy to do this it would take me 5 minutes 13:18 <@jeremyrubin> Just add a new flag and put a bug behind that flag 13:19 <@jeremyrubin> or just make "this specific hash does something else" 13:19 < iamzensored> +1 to harding as well 13:19 -!- Cubic1 [~Cubic1@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 256 seconds] 13:19 < rgrant> pull requests from here would be closely scrutinized. are we talking about after it goes live? 13:20 <@jeremyrubin> I'll note to look into that more, if it's technically possible? seems like the validity would have to be very narrow for if such a patch exposes a gap in tests. 13:20 < OP_NOP> The straightforward way is to sequentially comment out each line of code in the implementation and see if the tests fail 13:20 < harding> jeremyrubin: yeah, I think the idea is that libsecp256k1 has a *really* narrow focus and a whole lot of tests, so it works well in that context. In a broader context and with less exhaustive tests, I can see how it would be harder. But basically, you'd have to define the bounty to something that violates BIP119 or previous consensus rules (and network policy). 13:20 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has joined ##ctv-bip-review 13:20 <@jeremyrubin> What type of testing in this regard was done for e.g. taproot? 13:20 < OP_NOP> If a line of implementation is missing and the tests still pass, that means your coverage is inadequate 13:20 <@jeremyrubin> (just to follow by example) 13:21 <@jeremyrubin> OP_NOP: well for example I don't test for non-DoS quadratic hashing. 13:21 <@jeremyrubin> Would having a test that adversarial txns can be validated in O(1) help? 13:21 < _0x0ff> in case funds are collected it might be good to have a plan B for the pot in case CTV gets rejected. For example funds could go towards another Bitcoin improvement iniciative (covenant related?) 13:21 <@jeremyrubin> E.g., running the tests on a faster computer might change if the test passes 13:22 < OP_NOP> jeremyrubin: Perhaps? Would that be a show-stopper bug worth the bounty? 13:22 <@jeremyrubin> OP_NOP: yes, but not if you claim it by deleting the code to defend it? 13:22 < OP_NOP> Stick the bounty funds in a coventant... 13:22 <@jeremyrubin> _0x0ff: have to figure out if the funders would want that or not... 13:22 <@jeremyrubin> mod: 1 min 13:22 <@jeremyrubin> does anyone have any thoughts on judging? 13:23 <@jeremyrubin> like is it OK if I just decide? or do you think it needs a multisig of auditors? 13:23 < OP_NOP> jeremyrubin: Ah, right. A think a valid bug would need to trigger quadratic hashing through opcodes only 13:23 < _0x0ff> @jeremyrubin yes, but it's a question they might as you also 13:23 < _0x0ff> ask* 13:23 <@jeremyrubin> OP_NOP: certainly a showstopper 13:24 <@jeremyrubin> ok -- we can discuss this more later too 13:24 <@jeremyrubin> will be writing something up on it and seek feedback 13:24 <@jeremyrubin> #topic Proposed Timeline Feasibility (not advisibility) (10 minutes) 13:24 <@jeremyrubin> In https://rubin.io/bitcoin/2021/12/24/advent-27/, I proposed a concrete timeline upon which CTV review could be completed and a client released. The schedule is reproduced below for the meeting notes. The purpose of this section is to discuss the feasibility or issues with pursuing the presented timeline, less so the advisability of CTV itself (to 13:24 <@jeremyrubin> the extent that's a separate topic). 13:24 <@jeremyrubin> On March 15th developers reach agreement on merging BIP-119’s implementation. On April 15th, agreement is reached on release parameters for signaling from ~ June 1st to ~September 1st. The activation height would be November 10th. A client is prepared, and tested, and released. No issues are found. The miners signal at some point in the 3 month 13:24 <@jeremyrubin> window above the threshold. CTV locks-in. Developers can prep wallet software for deeper integration. CTV activates before Thanksgiving, avoiding the “dire straits” of thanksgiving-hanukkah-christmas-chinese-new-year-valentines-day season. 13:24 <@jeremyrubin> The next major release is scheduled for 2022-04-01. Soft forks are usually released as a minor patch on top of a few recent major releases. So CTV could be: 13:24 <@jeremyrubin> Code included in 23.0 for CTV, no activation parameters 13:24 <@jeremyrubin> Activation parameters in 23.1, and backported to 22.x, 21.x, and (really this is up to maintainers how far to backport!). 13:24 <@jeremyrubin> 23.1 released before June 1st, 2022. 13:24 <@jeremyrubin> Two issues that I'm aware of: Feature Freeze is currently set for 2-15 and not 3-15, this would mean merging earlier or delaying 0.23 1 month; the timeline presupposes a Taproot ST-like activation attempt. We will have a discussion on activation mechanisms after the meeting. 13:26 <@jeremyrubin> #subtopic: Feature Freeze 13:26 <@jeremyrubin> Does it make sense to merge (un-deployed as is tradition) for 0.23? That gives still 1 month for bug fix. 13:26 < iamzensored> Without thinking about specific dates the timeline itself (in terms of period between steps) sounds very adequate given how small of a change CTV is 13:26 <@jeremyrubin> This is just a "tradition" to get undeployed code changes in a release before 13:27 <@jeremyrubin> and bug fix for CTV/review can continue after merge and until april 13:27 <@jeremyrubin> and deployment would be a separate conversation 13:27 < iamzensored> I think Feature Freeze and the like is up to the maintainers :) 13:27 <@jeremyrubin> well, asking maintainers to move feature freeze to march is a big ask 13:28 <@jeremyrubin> Is that something that seems worth asking for? 13:28 <@jeremyrubin> Is that worth delaying an major release for all the other benefits it would bring users? 13:29 <@jeremyrubin> To me seems changing feature freeze is the greater harm than merging logic (which is mostly to make backports easier) earlier. 13:29 < iamzensored> Why not give maintainers both options, and what's the third option if neither is adequate? 13:30 <@jeremyrubin> mod: we'll do another 5 minutes here, and then post meeting we will discuss more general next steps with open floor 15 mins and then 15 mins activation mechanism if anyone wishes to not be present for that 13:30 <@jeremyrubin> iamzensored: 3rd option is -- at least from my view -- pushing CTV back +1 year 13:30 < bucko> I do think that from a "political" point of view, minimizing the asks to maintainers is ideal 13:31 -!- _tnull [~tnull@user/tnull/x-8645464] has joined ##ctv-bip-review 13:31 <@jeremyrubin> iamzensored: i'm happy for feedback on it, in https://rubin.io/bitcoin/2021/12/24/advent-27/ it sort of makes the case that the timelines point to this yearly striation being like "launch windows" to mars 13:31 < josedrobles> jeremyrubin: it's not possible a later merge on Q3 or Q4 this year? 13:31 < iamzensored> And just to clarify the merge is just merging in CTV code that is deactivated so there won't be any need to backport the full thing? 13:32 < OP_NOP> Spring is soft for season in Bitcoin Land 13:32 <@jeremyrubin> iamzensored: correct 13:32 < OP_NOP> fork* 13:32 <@jeremyrubin> the issue with alternative release schedules for soft forks is avoiding the magic winter holidays 13:32 < josedrobles> ok 13:32 <@jeremyrubin> doing a spring ST with early novemeber active misses all the major holiday things 13:33 <@jeremyrubin> merge in Q3/Q4 means signalling over holidays 13:33 < OP_NOP> Block height based activation parameters pls? 13:33 <@jeremyrubin> which for mining has historically been bad as e.g. all of china goes offline for like a month 13:33 <@jeremyrubin> OP_NOP: post meeting topic 13:33 < josedrobles> i understand. so is in february/marz or 2023 13:33 < rgrant> iamzensored: +1 to strong preference for spring ST 13:34 < OP_NOP> +1 for Spring 13:34 <@jeremyrubin> so that's why I kinda thing that we might permanently be on a "non emergency forks are signalled in spring summer and activated early november" 13:34 <@jeremyrubin> so if that's 22 or 23 thats sort of the question 13:34 <@jeremyrubin> unless we do a non-ST-y thing, but that's a after-meeting question 13:35 <@jeremyrubin> > sort of the question 13:35 <@jeremyrubin> I mean the question is am I wrong and are there other schedulings that make sense 13:35 < josedrobles> +1 for Spring 13:35 < rgrant> +1 for Spring 13:36 <@jeremyrubin> (this scheduling being universally quantified over any fork... i just don't see how with the params we used for taproot another calendar cycle makes more sense give constraints described around releases and such) 13:36 <@jeremyrubin> ok 13:36 <@jeremyrubin> last word? 13:36 < iamzensored> I guess from the perspective of maintainers is backporting a huge deal such that other timelines become possible or not? 13:36 < iamzensored> *backporting a full feature 13:37 <@jeremyrubin> iamzensored: it's definitely a "this would be more convenient to do if the changes are minimal" 13:37 < iamzensored> No argument there 13:37 <@jeremyrubin> i want to close by thanking everyone for their time in coming today 13:37 <@jeremyrubin> #endmeeting 13:37 <@jeremyrubin> Ok, now we have two topics 13:38 < rgrant> thanks for running it 13:38 <@jeremyrubin> #post-meeting 13:38 <@jeremyrubin> #topic What's required to get consensus / next steps? (30 minutes) 13:38 <@jeremyrubin> #subtopic Open Floor (15 minutes) 13:38 <@jeremyrubin> this is just an open floor for whatever. 13:38 <@jeremyrubin> you can talk more big picture, little picture, ask questions, suggestions for next meeting, etc. 13:38 <@jeremyrubin> only thing you can't do is talk activation mechanisms, which will be in 15 13:39 < rgrant> well, how many tested acks are there so far? 13:39 <@jeremyrubin> josedrobles seems to have tack'd 13:40 < iamzensored> I think it'd be useful to try to get maintainers into the next one to have the discussion around when to merge a non-active CTV 13:40 < jamesob> The implementation is fairly clear-cut to me; obviously want to ensure there aren't any validation slowdowns (might amount to running a -reindex benchmark with CTV active) or DoS vectors. But from there I'd just like to familiarize myself with some of the vault implementations (specifically kanzure's) before I Concept ACK 13:40 < josedrobles> sorry tack'd? 13:40 <@jeremyrubin> tested ack 13:40 < josedrobles> ah haha yeah 13:41 <@jeremyrubin> i think kanzure has certainly tested independently with python-vaults, soft-signalled, but not ack'd the impl/reviewed it 13:41 < josedrobles> btw, do you ask me to review this too: https://github.com/bitcoin/bitcoin/pull/22876 and https://github.com/bitcoin/bitcoin/pull/22954, i will have time this week i think 13:41 <@jeremyrubin> ben carman has tested, soft signalled, but not ackd 13:42 <@jeremyrubin> jonatack is some testing + code review + concept ack (impl, not clear on BIP) 13:42 < jamesob> Can't speak for him obviously but last I talked to Carman he wanted wait awhile to see what other covenant proposals look like 13:43 <@jeremyrubin> jaybny has tested ack 13:43 <@jeremyrubin> I think that's the current tally 13:43 <@jeremyrubin> of course, some of these are stale from e.g. rebases and whatnot 13:43 <@jeremyrubin> so would need re-acks 13:44 <@jeremyrubin> rgrant: does that answer your question a little bit? 13:44 < rgrant> yes, thanks 13:44 < OP_NOP> Any other covenant proposals no already listed on https://utxos.org/alternatives/? 13:44 <@jeremyrubin> i guess obviously i am also a tested ack 13:44 < kanzure> oh did i make an OP_CTV implementation of python-vaults? 13:44 <@jeremyrubin> kanzure: afaict yes 13:45 <@jeremyrubin> https://github.com/kanzure/python-vaults 13:45 < kanzure> https://github.com/kanzure/python-vaults/blob/master/vaults/bip119_ctv.py 13:45 < kanzure> huh, that's cool. 13:45 < ryanthegentry> lol 13:45 <@jeremyrubin> kanzure: something something developer momentum it was 2 years ago 13:45 <@jeremyrubin> but no spec changes, so if it worked then it works now 13:46 < jamesob> kanzure: LOL 13:46 -!- _tnull [~tnull@user/tnull/x-8645464] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 13:46 -!- Guest51 [~Guest51@pool-70-104-203-222.nrflva.fios.verizon.net] has quit [Quit: Client closed] 13:46 <@jeremyrubin> gmax did say an issue with going too slow is people can't even remember what they reviewed 13:46 < kanzure> i think it was something i worked on to prep for https://diyhpl.us/wiki/transcripts/ctv-bip-review-workshop/ 13:46 <@jeremyrubin> (that was about delaying taproot though) 13:47 <@jeremyrubin> OP_NO: yes, I think TLUV could be up there and IIDs and maybe OP_CONSTRAINDESTINATION 13:47 <@jeremyrubin> but there's nothing with an implementation / path to inclusion in core 13:47 <@jeremyrubin> you might also like https://rubin.io/bitcoin/2021/12/24/advent-27/ and https://rubin.io/blog/2021/07/02/covenants/ and https://rubin.io/bitcoin/2021/12/05/advent-8/ 13:48 <@jeremyrubin> oops OP_NOP ^^ 13:49 < OP_NOP> Some sort of nice table comparing various proposals would go a long way to calming some concerns out there that CTV is not the best move right now 13:49 <@jeremyrubin> oh 13:50 <@jeremyrubin> i think theres' also some covenants site idk who made it though 13:50 <@jeremyrubin> there's also https://arxiv.org/abs/2006.16714 13:51 < OP_NOP> Also, the SEO juiced https://bitcoincovenants.com/ 13:51 <@jeremyrubin> ah 13:51 <@jeremyrubin> yes that's what i wanted 13:51 <@jeremyrubin> and https://github.com/corollari/bitcoin-covenants 13:51 <@jeremyrubin> for the git minded 13:52 <@jeremyrubin> ok 13:52 <@jeremyrubin> why don't we, at 1:55, take a 5 minute break and then whoever wants to talk about activation mechanisms can do so? 13:53 <@jeremyrubin> (5 minutes to take a couple shots or an *redacted* to kick in or whatever it takes to make you want to discuss that) 13:53 <@jeremyrubin> Any other closing general questions or things you want in the meeting logs? 13:54 < iamzensored> Just wanted to share https://zensored.substack.com/p/what-does-op-ctv-mean-for-me for anyone who wants a less technical look at CTV 13:54 < iamzensored> (and more practical application-focused look) 13:54 <@jeremyrubin> iamzensored: +1 13:55 <@jeremyrubin> in future meetings we can get more into applications and stuff if people want to go deep 13:55 <@jeremyrubin> but i felt this detailed review was good to first have a concrete understanding of what CTV is doing 13:55 <@jeremyrubin> #topic break (5 mins) 13:56 <@jeremyrubin> pheeeeew that was a fast paced meeting huh 😓 13:56 * rgrant has to say goodbye 13:57 -!- rgrant [~rgrant@user/rgrant] has quit [Quit: Leaving...] 13:58 < iamzensored> lol 13:58 < iamzensored> Future meetings could be a tad slower 13:58 < jamesob> thanks for doing this Jeremy, this is great 13:59 < iamzensored> Very much enjoyed it though! 14:00 <@jeremyrubin> #subtopic Discussion of activation mechanisms (15 minutes) 14:00 <@jeremyrubin> the current BIP text supposes a ST, and it has been discussed above. 14:01 < jamesob> (took me awhile to figure out that ST = "speedy trial") 14:01 <@jeremyrubin> However, i proposed to amend the bip to clarify that really it's ambiguous if that should be used or what would take it's place 14:01 <@jeremyrubin> https://github.com/bitcoin/bips/pull/1257 14:01 <@jeremyrubin> jamesob: good point: Speedy Trial was an activation mechanism that was released by the Bitcoin Core Maintainers for Taproot. An alternative ("UASF" = User Activated Soft Fork) client was released independently. 14:02 < iamzensored> ST is a great mechanism IMO. I think the UASF side is beneficial though too. ST is the happy nice cooperative path, UASF is the nuke that works as a deterrent but luckily hasn't needed to be used (neither in Taproot nor Segwit) 14:02 <@jeremyrubin> there *was* consensus among core developers for ST (vacuous proof -- it's what core released) but that consensus was not unanimous and thus an alternative client was realesed 14:03 <@jeremyrubin> that consensus existed in the past does not imply that it exists for the future 14:03 < iamzensored> This is also a change that doesn't really necessitate UASF at this stage because miners aren't actively opposing it 14:03 < OP_NOP> Taproot was a way for everyone to dip a toe back in the water after the SegWit battle, and it seems to have turned out alright 14:04 <@jeremyrubin> My personal view is that https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018833.html captures a possible flow for a "all possibilities captured" activation timeline 14:04 < OP_NOP> Not seeing any reasoned opposition to CTV makes it seem like activation should not be contentious 14:04 <@jeremyrubin> I think that ST can be tried, and if failed, followed up with a UASF 14:04 <@jeremyrubin> I personally don't see the value in UASF by default 14:05 <@jeremyrubin> OP_NOP: there is some opposition that is reasoned, agree or disagree with the validity of the reasons 14:05 < OP_NOP> Miners seem to have been a bit complacent with Taproot (false signal), so some backdrop of user-enforced security should be considered 14:05 <@jeremyrubin> OP_NOP: yep, users should absolutely upgrade their nodes to enforce the new rule 14:06 <@jeremyrubin> the issue I have with UASF is that epistemically you can't really know what people are running 14:06 <@jeremyrubin> if there were an honest signal, that would be better 14:06 < iamzensored> Yeah UASF is useful when miners won't go with the will of the network, there's very few soft forks where this would ever be the case 14:06 < OP_NOP> Yeah, the only thing that ties the real world to the Bitcoin world is a hash with a ton of leading zeros 14:06 <@jeremyrubin> i wrote about this here a while back https://blog.bitmex.com/taproot-you-betcha/ 14:07 <@jeremyrubin> with CTV, funny enough, it's easier to prove these kinda bets 14:07 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Remote host closed the connection] 14:07 <@jeremyrubin> is there anyone here who can make an impassioned argument in favor of a UASF as the prime deployment path for CTV? 14:07 <@jeremyrubin> luke-jr? 14:08 <@jeremyrubin> otherwise it sounds like, in our small tent of people here, there's rough consensus on ST being OK as a next-step and then big guns in reserve... 14:09 < iamzensored> Probably, might also be a good ask at the start of the next meeting since people may have signed off 14:10 <@jeremyrubin> that's intentional 14:10 < iamzensored> lol 14:10 < iamzensored> I can understand why 14:10 < OP_NOP> Only thing I really want to see is block heights only, rather than median times or mixed 14:11 <@jeremyrubin> personally my view is that activation mechanisms are short lived and don't set permanent precedant which makes them more annoying but also IMO not as important as people make it out to be 14:11 <@jeremyrubin> "we didn't die and taproot works now" good nuff for me to an extent 14:11 <@jeremyrubin> long term centralization risks are a factor... 14:11 < OP_NOP> tend to agree 14:12 <@jeremyrubin> I was also unhappy that Taproot software was not totally ready to go despite the 6 mo lockin to active window 14:12 <@jeremyrubin> however, for CTV a lot of the integrations (e.g., rust-miniscript) are designed already 14:13 <@jeremyrubin> and sapio exists... 14:13 <@jeremyrubin> also it's not a new address type 14:13 <@jeremyrubin> so it can go in TR addrs 14:13 <@jeremyrubin> not requiring e.g. coinbase to accept bech32m 14:14 <@jeremyrubin> so i think for ctv in particular i don't see there being a lack of software ready on activation 14:14 <@jeremyrubin> any closing thoughts? 14:15 < OP_NOP> Appreciate the meeting, thanks 14:15 <@jeremyrubin> thanks all for coming. meeting notes coming soon™. 14:15 <@jeremyrubin> #endpostmeeting 14:15 < josedrobles> thanks 14:16 <@jeremyrubin> josedrobles: yeah I noticed btw I think you ack'd the wrong commit hash 14:16 <@jeremyrubin> you ack'd the first commit, not the last :D 14:16 <@jeremyrubin> w.r.t. the review of the other PRs, those are both inside the main CTV pr and are just the changes to the testing harness 14:16 <@jeremyrubin> so it's just a matter of checking it matches and then acking and i can drop those commits from the CTV PR, which is nice 14:17 <@jeremyrubin> really appreciate your reviewing :) 14:17 < josedrobles> ok i didn't open the two, only copy paste for not forgetting 14:17 < josedrobles> ok, i will review this 14:17 < iamzensored> Thanks everyone for your contributions! This was a great discussion and really looking forward to the next one! 14:17 -!- iamzensored [~iamzensor@user/iamzensored] has quit [Quit: Leaving] 14:19 -!- OP_NOP [~OP_NOP@89.45.90.229] has quit [Ping timeout: 240 seconds] 14:24 < pete_rizzo_33> Thanks for the discussion. I am still a bit behind on CTV and still playing catch up. Will aim to attend more of these sessions 14:26 -!- pete_rizzo_33 [~pete_rizz@69.206.19.61] has quit [Quit: Client closed] 14:29 -!- groot69 [~groot69@188-143-109-228.pool.digikabel.hu] has left ##ctv-bip-review [] 14:32 -!- josedrobles [~jdrobpar@32.red-88-3-64.dynamicip.rima-tde.net] has quit [Ping timeout: 256 seconds] 14:52 < luke-jr> jeremyrubin: BIP 8 isn't a UASF until the MASF fails 14:52 < luke-jr> jeremyrubin: ie, it keeps "the big guns in reserve" 14:55 -!- criptoluis [~criptolui@186.32.73.228] has quit [Quit: Client closed] 14:57 -!- IshiKawa [~IshiKawa@201.247.43.160] has joined ##ctv-bip-review 14:57 -!- bryan28 [~bryan@104.129.205.134] has quit [Quit: Client closed] 15:03 <@jeremyrubin> luke-jr: dont want to get into a protracted debate, but I'd disagree thoroughly since it's a hard fork after you decide to run BIP8 LOT=true to downgrade to LOT=false. Maybe UASF is the wrong term since miners can activate earlier, I'm talking about UESF "user ensured soft fork" 15:04 <@jeremyrubin> personally (and I think it's not too uncommon a view) if miners fail to signal, it's at least worth giving some consideration before node operators commit to ensuri ng the fork 15:05 <@jeremyrubin> I am very ok with UASFs in general, but I think a first release as a UESF sounds unideal 15:05 <@jeremyrubin> especially since as a soft fork later releases can become UESFs, but walking it back requires hard fork 15:16 -!- lightlike [sid521075@user/lightlike] has joined ##ctv-bip-review 15:23 -!- IshiKawa [~IshiKawa@201.247.43.160] has quit [Read error: Connection reset by peer] 15:23 -!- IshiKawa [~IshiKawa@179.51.59.114] has joined ##ctv-bip-review 15:26 -!- IshiKawa [~IshiKawa@179.51.59.114] has quit [Read error: Connection reset by peer] 15:29 -!- IshiKawa [~IshiKawa@179.51.59.114] has joined ##ctv-bip-review 15:36 -!- IshiKawa [~IshiKawa@179.51.59.114] has quit [Ping timeout: 240 seconds] 15:38 -!- IshiKawa [~IshiKawa@179.51.59.114] has joined ##ctv-bip-review 15:45 < luke-jr> jeremyrubin: it's a hardfork to use LOT=False or ST at all 16:22 -!- IshiKawa [~IshiKawa@179.51.59.114] has quit [Read error: Connection reset by peer] 16:23 -!- IshiKawa [~IshiKawa@179.51.59.114] has joined ##ctv-bip-review 16:26 -!- OP_NOP [~OP_NOP@static-198-54-130-136.cust.tzulo.com] has joined ##ctv-bip-review 16:26 -!- OP_NOP [~OP_NOP@static-198-54-130-136.cust.tzulo.com] has quit [Client Quit] 16:41 -!- proofofkeags [~proofofke@205.209.24.233] has quit [Ping timeout: 256 seconds] 18:19 -!- deusexbeer [~hedeo@37-146-236-2.broadband.corbina.ru] has joined ##ctv-bip-review 18:54 -!- matthewjablack [~matthewja@ip-45-41-170-185.fibre.fibrestream.ca] has quit [Quit: Client closed] 19:14 -!- IshiKawa [~IshiKawa@179.51.59.114] has quit [Remote host closed the connection] 19:15 -!- IshiKawa [~IshiKawa@179.51.59.114] has joined ##ctv-bip-review 19:15 -!- IshiKawa [~IshiKawa@179.51.59.114] has quit [Client Quit] 21:29 -!- andytosh1 [~apoelstra@user/andytoshi] has joined ##ctv-bip-review 21:35 -!- Netsplit *.net <-> *.split quits: andytoshi, jamesob 21:38 -!- andytosh1 [~apoelstra@user/andytoshi] has quit [Ping timeout: 256 seconds] 21:40 -!- Netsplit over, joins: jamesob 21:40 -!- Netsplit over, joins: andytoshi 22:52 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has joined ##ctv-bip-review 22:57 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Ping timeout: 256 seconds] 23:41 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has joined ##ctv-bip-review 23:46 -!- suntsu007 [~suntsu007@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Ping timeout: 256 seconds] --- Log closed Wed Jan 12 00:00:28 2022