--- Day changed Wed Oct 14 2020 00:00 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews 00:00 -!- musdom [~Thunderbi@202.186.37.216] has joined #bitcoin-core-pr-reviews 00:04 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 00:05 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 00:07 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 00:09 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 260 seconds] 00:10 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 00:15 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 256 seconds] 00:37 -!- jonatack [~jon@213.152.161.69] has quit [Ping timeout: 272 seconds] 00:53 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 246 seconds] 01:08 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 01:10 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 01:12 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 258 seconds] 01:14 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 246 seconds] 01:16 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 01:20 -!- jonatack [~jon@37.170.11.107] has joined #bitcoin-core-pr-reviews 01:24 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-pr-reviews 01:27 -!- jonatack [~jon@37.170.11.107] has quit [Ping timeout: 272 seconds] 01:28 -!- jonatack [~jon@213.152.162.94] has joined #bitcoin-core-pr-reviews 01:29 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 272 seconds] 01:30 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 01:33 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 01:36 -!- mol_ [~mol@unaffiliated/molly] has quit [Remote host closed the connection] 01:38 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 01:46 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 01:49 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 01:59 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-pr-reviews 02:09 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has joined #bitcoin-core-pr-reviews 02:16 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 260 seconds] 02:29 -!- musdom [~Thunderbi@202.186.37.216] has quit [Quit: musdom] 02:54 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 02:55 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 02:55 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 02:57 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 02:59 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 03:01 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 03:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 03:10 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 03:14 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 03:17 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 03:24 -!- jonatack [~jon@213.152.162.94] has quit [Ping timeout: 258 seconds] 04:07 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has joined #bitcoin-core-pr-reviews 04:12 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-pr-reviews 04:15 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-pr-reviews 04:16 -!- setpill [~setpill@unaffiliated/setpill] has quit [Client Quit] 04:19 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 260 seconds] 04:35 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection] 04:36 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 04:40 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 272 seconds] 04:43 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 04:46 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 04:49 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 04:54 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 260 seconds] 05:05 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 05:05 -!- shaunsun__ [~shaunsun@c-76-26-29-34.hsd1.fl.comcast.net] has joined #bitcoin-core-pr-reviews 05:07 -!- shaunsun_ [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews 05:10 -!- shaunsun__ [~shaunsun@c-76-26-29-34.hsd1.fl.comcast.net] has quit [Ping timeout: 272 seconds] 05:30 -!- gleb [~gleb@178.150.137.228] has quit [Quit: Ping timeout (120 seconds)] 05:36 -!- gleb [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews 05:53 -!- devinbileck [~devin@node-1w7jr9qj08cu2b654cds8v40c.ipv6.telus.net] has joined #bitcoin-core-pr-reviews 05:54 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 05:58 -!- devinbileck [~devin@node-1w7jr9qj08cu2b654cds8v40c.ipv6.telus.net] has quit [Client Quit] 06:03 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-hlnzquefznidhiso] has quit [Quit: Connection closed for inactivity] 06:04 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 260 seconds] 06:15 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-pr-reviews 06:20 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 260 seconds] 06:27 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 06:31 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 06:52 -!- Sound [a0272ec7@dyn-160-39-46-199.dyn.columbia.edu] has joined #bitcoin-core-pr-reviews 07:19 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 07:20 -!- Sound [a0272ec7@dyn-160-39-46-199.dyn.columbia.edu] has quit [Remote host closed the connection] 07:21 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:24 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection] 08:16 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-pr-reviews 08:19 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 08:21 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.5 - https://znc.in] 08:22 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 272 seconds] 08:24 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 08:33 -!- nate59 [62a0fba3@ip98-160-251-163.lv.lv.cox.net] has joined #bitcoin-core-pr-reviews 08:39 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews 08:43 -!- nate59 [62a0fba3@ip98-160-251-163.lv.lv.cox.net] has quit [Ping timeout: 245 seconds] 08:56 -!- epson121 [d59533d2@213.149.51.210] has joined #bitcoin-core-pr-reviews 08:57 -!- buzz08 [~buzz@2401:4900:234d:9c81:24dd:e572:ae6e:c262] has joined #bitcoin-core-pr-reviews 09:00 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has joined #bitcoin-core-pr-reviews 09:00 -!- nate34k [62a0fba3@ip98-160-251-163.lv.lv.cox.net] has joined #bitcoin-core-pr-reviews 09:01 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews 09:07 -!- face [~face@207.154.206.50] has joined #bitcoin-core-pr-reviews 09:07 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 09:07 -!- nate34k68 [62a0fba3@ip98-160-251-163.lv.lv.cox.net] has joined #bitcoin-core-pr-reviews 09:07 -!- elle [~ellemouto@155.93.252.70] has joined #bitcoin-core-pr-reviews 09:08 -!- nate34k68 [62a0fba3@ip98-160-251-163.lv.lv.cox.net] has quit [Remote host closed the connection] 09:14 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 09:15 -!- gleb [~gleb@178.150.137.228] has quit [Ping timeout: 264 seconds] 09:17 -!- gleb [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews 09:24 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 09:28 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds] 09:30 -!- jonatack [~jon@109.202.107.147] has joined #bitcoin-core-pr-reviews 09:32 -!- nate34k [62a0fba3@ip98-160-251-163.lv.lv.cox.net] has quit [Remote host closed the connection] 09:37 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 09:40 -!- rjected [~dan@pool-151-203-65-159.bstnma.fios.verizon.net] has joined #bitcoin-core-pr-reviews 09:41 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has joined #bitcoin-core-pr-reviews 09:43 -!- vaguely [~vaguely@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 09:45 -!- nir [40bba0b7@64.187.160.183] has joined #bitcoin-core-pr-reviews 09:48 <@jnewbery> we'll get started in 12 minutes. Time to make a cup of tea/pour yourself a gin and tonic/do whatever your pre-review club routine is. 09:49 < buzz08> eagerly waiting 09:50 < sipa> excellent idea 09:52 < pinheadmz> pre-review club routine: review PR 😬 09:53 <@jnewbery> yeah, if you haven't reviewed the pr yet, now's probably a good time 09:54 < pinheadmz> good questions this week! I actually did prepare a bit last night its been a while since i looked at tapscript 09:57 < emzy> I'm missing the tonic... 09:57 * pinheadmz pours gin + taproot... sip "ahhhhh!" 09:59 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-pr-reviews 10:00 <@jnewbery> #startmeeting 10:00 <@jnewbery> Hi folks! Welcome to Bitcoin Core PR Review Club. Feel free to say 'hi' to let everyone know you're here. 10:00 < pinheadmz> hi 10:00 < emzy> hi 10:00 < jonatack> bonsoir! 10:00 < robot-dreams> hi 10:00 < elle> hi 10:00 < vaguely> hi 10:00 < jesseposner> hi 10:00 <@jnewbery> Is it anyone's first time at review club? 10:00 < stacie> hi 10:01 < b10c> Would anyone be interested in an auto-generated .ics calendar file for the PR review club with proper title and so on? I need something in my calendar otherwise I miss the meeting every other week. 10:01 < sipa> hi 10:01 < b10c> hi 10:01 < michaelfolkson> hi 10:01 < nir> hi! first time here 10:01 <@jnewbery> b10c: I think wumpus made a calendar with all of the Bitcoin Core meetings, including review club 10:01 < buzz08> hi, this is my first time too :-) 10:01 -!- Sound [a0272ec7@dyn-160-39-46-199.dyn.columbia.edu] has joined #bitcoin-core-pr-reviews 10:01 <@jnewbery> Yay! Welcome. We love new participants 10:01 < vaguely> welcome to the PR review party, nir buzz08 10:01 < felixweis> hi! 10:02 <@jnewbery> Before we begin, a reminder that I'm always looking for hosts for review club and suggestions of what PRs to cover. Feel free to message me anytime if you think you might want to host at some point. 10:02 < Sound> Hello! 10:02 -!- Paul52 [adf60e57@173-246-14-87.qc.cable.ebox.net] has joined #bitcoin-core-pr-reviews 10:02 <@jnewbery> You don't need to be the world's foremost authority on something to host. Just commit to spending some time writing notes and questions (I'll help!), and then show up and guide other people through what you've learned and what's interesting about the PR. 10:02 < nir> vaguely thank you! 10:02 < b10c> jnewbery: thanks! will have a look at that 10:02 <@jnewbery> Ok, onto this week's PR. Today we'll be talking about ... 10:02 <@jnewbery> 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 🚰 10:02 -!- benthecarman [~benthecar@194.99.104.13] has joined #bitcoin-core-pr-reviews 10:02 <@jnewbery> _________ _______ _______ _______ _______ _______ _________ _______ _________ 10:02 <@jnewbery> \__ __/( ___ )( ____ )( ____ \( ____ \( ____ )\__ __/( ____ )\__ __/ 10:02 <@jnewbery> ) ( | ( ) || ( )|| ( \/| ( \/| ( )| ) ( | ( )| ) ( 10:02 <@jnewbery> | | | (___) || (____)|| (_____ | | | (____)| | | | (____)| | | 10:02 <@jnewbery> | | | ___ || _____)(_____ )| | | __) | | | _____) | | 10:02 -!- dome [~e-mod@c-73-46-0-211.hsd1.fl.comcast.net] has joined #bitcoin-core-pr-reviews 10:02 <@jnewbery> | | | ( ) || ( ) || | | (\ ( | | | ( | | 10:02 <@jnewbery> | | | ) ( || ) /\____) || (____/\| ) \ \_____) (___| ) | | 10:03 <@jnewbery> )_( |/ \||/ \_______)(_______/|/ \__/\_______/|/ )_( 10:03 <@jnewbery> 10:03 <@jnewbery> πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ πŸ“œ 10:03 <@jnewbery> Notes and questions are in the normal place: https://bitcoincore.reviews/19953 10:03 < pinheadmz> OH YES DUDE +1,000,000 10:03 <@jnewbery> This is our sixth session on the schnorr/taproot implementation. You can see notes/questions/logs from all the previous meetings here: https://bitcoincore.reviews/meetings-components/#taproot 10:03 < felixweis> amazing! 10:03 < jonatack> πŸ‘ 10:03 <@jnewbery> pinheadmz: thanks, you're an inspiration 10:03 <@jnewbery> First things first. Who's had a chance to review the commit (y/n). Absolutely no problem if you didn't have time this week. We'll walk though the changes together. 10:03 < pinheadmz> y 10:03 < felixweis> y 10:03 < emzy> n 10:04 < b10c> n 10:04 < robot-dreams> ish 10:04 < Paul52> n 10:04 < jesseposner> n 10:04 < stacie> n 10:04 < dome> n 10:04 < benthecarman> y 10:04 < sipa> y 10:04 < nir> y 10:04 < elle> y-ish 10:04 < jonatack> y 10:04 < michaelfolkson> y 10:04 <@jnewbery> that's great. Lots of review 10:04 <@jnewbery> alright, let's get to it 10:04 <@jnewbery> 1. What additional data does the signature hash commit to, compared to P2WPKH and P2WSH signatures? Hint: you’ll need to look at the SigMsg() and tapleaf hash definitions in BIP 341. You may also want to review the review club notes from the session on taproot signature hashing. 10:05 <@jnewbery> BIP: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki 10:05 < Murch> n 10:05 < pinheadmz> for one i believe it commits to all the input values for the entire tx 10:05 < robot-dreams> Input amounts (so you can be confident of the fee when signing) 10:05 < benthecarman> input amounts and spks 10:05 < sipa> robot-dreams: which input amounts? 10:06 < pinheadmz> and i think we commit to the scriptPubKey which segwit v0 didnt ? 10:06 <@jnewbery> oops that was the taproot bip. tapscript is here: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki (you'll need both) 10:06 < pinheadmz> sipa all input amounts! unless SIGHASH_ANYONECANPAY is set 10:06 < sipa> pinheadmz: indeed! 10:07 < sipa> the sighash scheme is mostly in BIP341, with some additions in BIP342 10:07 < michaelfolkson> And the leaf version. Obviously that didn't exist for SegWit v0 10:07 < sipa> pinheadmz: and indeed, bip143 (the segwit v0 sighash scheme) didn't commit to the scriptPubKey 10:07 <@jnewbery> can anyone give me a link/reference for where the sighash is defined? 10:07 < sipa> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message 10:07 -!- Paul52 [adf60e57@173-246-14-87.qc.cable.ebox.net] has quit [Remote host closed the connection] 10:08 <@jnewbery> that's it sipa! 10:08 < robot-dreams> sipa: previous output spent by a particular input, as well as serialization of all spent output amounts in the transaction? 10:08 -!- paul49 [adf60e57@173-246-14-87.qc.cable.ebox.net] has joined #bitcoin-core-pr-reviews 10:08 < felixweis> thats quite the commitment! 10:08 < michaelfolkson> Does SegWit v0 commit to the size of the script? 10:08 * michaelfolkson checks 10:08 < pinheadmz> oh yeah for bip342 theres also the leaf version and key version which is always 0x00 for now 10:08 < sipa> michaelfolkson: which script? :) 10:09 <@jnewbery> we covered the taproot signature hash in a previous review club (https://bitcoincore.reviews/17977). There are also some other things that go into the hash when we're doing a script path spend. Can anyone find the reference for that? 10:09 < sipa> robot-dreams: right; bip143 already committed to the input amount being spent; bip341 changes that to cover _all_ input amounts of the transaction, in every input 10:09 < michaelfolkson> Trick question sipa? The Tapscript output script? 10:10 < robot-dreams> Thanks, that was not clear before 10:10 < sipa> michaelfolkson: the one being spent? 10:10 < sipa> michaelfolkson: or the one(s) being created? 10:10 < sipa> robot-dreams: and not just the amounts, all _all_ scriptpubkeys of the outputs being spent 10:11 <@jnewbery> it's here: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#signature-validation. You can see that the signature hash is also committing to the tapleaf_hash, key_version and codesep_pos 10:12 <@jnewbery> ok, next question. 2. Why are OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY disabled in tapscript? How can you implement a multisig scheme in segwit v1? 10:12 < jonatack> https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_ref-3-0 10:12 < pinheadmz> the BIP author (ahem) says those op codes are inefficeint 10:12 < nir> because they're inefficient 10:12 < benthecarman> they are replaced with OP_CHECKSIGADD 10:12 < pinheadmz> i suppose its because you dont know until you get to the end of the script if youve reached the threshold? 10:13 < jesseposner> https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#design 10:13 < pinheadmz> checksigadd does one at a time and drops a counter back on the stack 10:13 < pinheadmz> er, increments a counter 10:13 < sipa> why are they inefficient? 10:13 <@jnewbery> great. Yes, lots of good answers. checkmultisig is inefficient. It also makes batch validation difficult or impossible I believe 10:13 < pinheadmz> i was wondering if it also has something to do with batch verification 10:13 < jonatack> ugh, clicked on the wrong link, apologies https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-2 10:14 < pinheadmz> yeah but with op_CMS you still have an array of signatures on the input 10:14 < sipa> indeed, they're inherently incompatible with batch validation 10:14 -!- vindard_ [~vindard@200.7.90.152] has joined #bitcoin-core-pr-reviews 10:14 < pinheadmz> sipa is it because op_checksig/multisig use a different transaction digest? 10:15 < sipa> in batch validation you need to know ahead of time which (msg,pubkey,sig) triplets are going to have to be valid, and which won't 10:15 < pinheadmz> and re: batch - im unclear what actually changes to make the new scheme more cmpatible 10:15 < pinheadmz> ah 10:15 < sipa> OP_CMS can't do that, as the same signature is tried against multiple pubkeys 10:15 < pinheadmz> AHHHHhhhhhh πŸ’‘ 10:15 < sipa> so it would require a combinatorial explosion 10:15 < michaelfolkson> sipa: The one being spent 10:16 < pinheadmz> i didnt realize that - so for CMS the order of pubkeys/signatures is not enforced? 10:16 < sipa> michaelfolkson: clearly segwitv0 does not commit to the taproot output being spent ;) 10:16 <@jnewbery> Anyone got an answer for: How can you implement a multisig scheme in segwit v1? 10:16 < sipa> pinheadmz: the order is enforced, but the combination isn't 10:16 -!- gimballock [84932b84@d-132-147-43-132.fl.cpe.atlanticbb.net] has joined #bitcoin-core-pr-reviews 10:16 < elle> i think the order is enforced but there is a placeholder for the missing ones? 10:16 < pinheadmz> oh right thanks elle / sipa 10:16 < sipa> elle: no placeholder, that's the problem! 10:17 < sipa> if there was a placeholder we'd be golden for batch validation 10:17 < nir> using Using a single OP_CHECKSIGADD-based script is an alternative 10:17 < robot-dreams> jnewbery: Do you have to use something like musig along CHECKSIGAD to get multisig in v1? 10:17 < b10c> jnewbery: MuSig? 10:17 < sipa> pinheadmz: if you have 2-of-3 with pubkeys [pA, pB, pC], you can spend it with sigs [sA, aB], [sA, sC], or [sB, sC] 10:17 < felixweis> in case you can't combine with MuSig? 10:17 <@jnewbery> nir: yes, we can create a tapscript with OP_CHECKSIGADD and all the pubkeys 10:17 < sipa> OP_CMS just tries all combinations 10:17 < michaelfolkson> No robot-dreams. You don't have to 10:17 < jesseposner> MuSig requires Schnorr 10:17 < pinheadmz> with musig you wnd up with one single signature, so that is actually different than checksigadd 10:17 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 256 seconds] 10:18 < pinheadmz> if you are using musig you might not even need tapscript! (key path could suffice) 10:18 <@jnewbery> robot-dreams b10c: yes! an aggregation scheme like MuSig is another way to create a multisig scheme 10:18 < sipa> jesseposner: thankfully, BIP342 disables all ECDSA check opcodes and replaces them with Schnorr ones 10:18 < sipa> jnewbery: i suggest reading rationale 5 in BIP342 10:19 < elle> sipa: i meant op_checksig add. doesnt it have a placeholder? 10:19 < sipa> elle: ah, yes! 10:19 < sipa> sorry, i thought you were talking about OP_CMS 10:19 < elle> sipa: ok cool :) 10:19 <@jnewbery> so that's two ways of having a multisig scheme. Any others? 10:19 < nir> Native Schnorr threshold signatures? 10:20 <@jnewbery> nir: that's what I meant above by a aggregation scheme. 10:20 < b10c> jnewbery: I suppose you could do e.g. a 1-of-2 by having two branches with a single key spend each? 10:20 < sipa> jnewbery: i think there is an important distinction 10:20 < nir> ah, got it 10:20 < felixweis> only these 2 10:20 < michaelfolkson> MuSig-DN 10:20 < michaelfolkson> MuSig2 10:20 < sipa> michaelfolkson: doesn't change the script 10:21 < sipa> that's just signing protocol differences 10:21 <@jnewbery> b10c: yes, you can break down the different key combinations into different scripts in the tree 10:21 * michaelfolkson checking what question we're answering again 10:21 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection] 10:21 < sipa> you could have a merkle tree where every leaf is a K-of-K MuSig aggregate, or you can use a threshold scheme and just have the key path be the key for the K-of-N entirely (which arguably doesn't involve tapscript at all) 10:22 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews 10:22 < robot-dreams> Sorry, I'm a little lost and I have a basic question. Unlike CHECKSIG, the new CHECKSIGADD involves an additional CScriptNum value. What's the context for this? 10:22 < willcl_ark> Hi! Sorry to miss the beginning of the review; going to try and read the backlog and catch up... 10:23 <@jnewbery> sipa: right. Which is why the question was framed as 'multisig scheme in segwit v1'. You can use a single tapscript, a tree of tapscripts, or just the keypath spend (no tapscripts at all) 10:23 < sipa> robot-dreams: OP_CHECKSIGADD is literally just a shorthand for OP_ROT OP_SWAP OP_CHECKSIG OP_ADD 10:23 <@jnewbery> as sipa pointed out, there's a good summary here: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-5 10:23 < sipa> robot-dreams: because that's an expected common pattern that people would use to replace OP_CHECKMULTISIG 10:23 < pinheadmz> and amazingly, OP_ROT rotates exactly three elements, which is perfect for this use case. 10:23 <@jnewbery> and I think Murch might also have written something about implementing multisignature schemes in taproot 10:24 < jonatack> https://medium.com/@murchandamus/2-of-3-multisig-inputs-using-pay-to-taproot-d5faf2312ba3 10:24 <@jnewbery> 3. What is the purpose of the new OP_SUCCESS opcodes? How does their functionality differ from OP_NOP in pre-segwit and P2WSH script? 10:24 <@jnewbery> thanks jonatack! 10:24 < glozow> Script upgradeability! 10:24 < pinheadmz> robot-dreams in english: every successful sig verification increments this counter by 1, then the number is returned to the stack 10:24 < pinheadmz> its like a small Katamari ball rolling over your signatures 10:24 < michaelfolkson> NOP was ignored. SUCCESS results in success instantly 10:25 < sipa> robot-dreams: so you can write a 4-of-5 multisig as "pA CS pkB CSA pkC CSA pkD CSA pkE CSA 4 EQUAL" 10:25 < vaguely> pinheadmz nice analogy 10:25 < robot-dreams> OH!! I didn't realize you would typically use it multiple times. That's why I thought you could ONLY use something like musig. 10:25 < sipa> robot-dreams: tapscript is, after, still a script 10:25 <@jnewbery> michaelfolkson: yes, exactly 10:25 < robot-dreams> That means CSA doesn't add any fancy Schnorr stuff, you could have also just used CS 10:25 < robot-dreams> if you wanted to use musig? 10:26 < robot-dreams> OK I was very confused but I think I'm good now, thanks 10:26 <@jnewbery> why would we want OP_SUCCESS instead of OP_NOP? 10:26 < pinheadmz> robot-dreams all sigs in taproot/tapscrtpt still use schnorr 10:26 < robot-dreams> OP_SUCCESS makes the entire script succeed just by its presence 10:26 < robot-dreams> That is much nicer for soft fork upgrades in the future 10:26 < michaelfolkson> I think glozow answered that jnewbery 10:26 < jesseposner> OP_NOP only has read access to the stack, OP_SUCCESS also has write access (https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_ref-1-0) 10:26 < sipa> robot-dreams: yes, ideally you have just one signature check in a script, and it's a musig aggregate or native threshold 10:26 < felixweis> OP_SUCCESS instead of NOP allows for more versatile future softforking 10:26 < pinheadmz> jesseposner nice detail! 10:26 <@jnewbery> ah yes! Thanks glozow. Can you expand? Why is it better for upgradeability? 10:27 < sipa> robot-dreams: but musig adds complication for signers, and thresholds even more... so people may want to use individual checksigs/checksigadds instead 10:27 -!- vindard_ [~vindard@200.7.90.152] has quit [Ping timeout: 240 seconds] 10:27 <@jnewbery> jesseposner: good answer! 10:27 < glozow> er, upgrades = restrict spending rules. If we have an automatic success now, it allows lots of flexibility for upgrades? 10:28 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews 10:28 < glozow> I think i read something about being able to write to the stack with OP_SUCCESS whereas for the NOPS, you can only (1) fail or (2) continue without changing the stack? 10:28 <@jnewbery> OP_NOP is rather limited in the semantics it can be repurposed for. It must leave the stack unchanged. OP_SUCCESS can be repurposed to any semantic 10:28 -!- nate34k [62a0fba3@ip98-160-251-163.lv.lv.cox.net] has joined #bitcoin-core-pr-reviews 10:28 < glozow> sorry I didn't prep very well for today :'( 10:28 < sipa> glozow: that's exactly it 10:28 <@jnewbery> glozow: exactly! 10:28 < sipa> NOPs cannot be redefined to do anything, except failing' 10:28 < felixweis> for instance future opcodes could read/consume/write 1 or more different stack elements 10:29 < sipa> they can't make any observable state changes, because that could result in non-softfork behavior 10:29 <@jnewbery> Last question on the spec, then we can move onto the implementation. 10:29 <@jnewbery> 4. Why is MINIMALIF a consensus rule in tapscript? 10:29 < pinheadmz> malleability! 10:29 < michaelfolkson> It was a consensus rule for SegWIt v0 too though right? 10:30 -!- epson121 [d59533d2@213.149.51.210] has quit [Remote host closed the connection] 10:30 <@jnewbery> pinheadmz: I applaud your enthusiasm for malleability, but your answer could use a bit more detail 10:30 < pinheadmz> sorry had to get the door lol 10:30 < pinheadmz> ok 10:30 < pinheadmz> becsuse lots of vsalues can be "true: 10:30 < pinheadmz> so a script that computes IF (9999999) will be the same result as IF(1) 10:30 <@jnewbery> michaelfolkson: no, it was added as a standardness rule for segwit v0, but is not consensus 10:31 < michaelfolkson> Introduced in 2016: https://github.com/bitcoin/bitcoin/pull/8526 10:31 < jonatack> "Why make MINIMALIF consensus? This makes it considerably easier to write non-malleable scripts that take branch information from the stack." https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-3 10:31 < pinheadmz> minimalif is, i believe already a mempool policy rule 10:31 -!- paul49 [adf60e57@173-246-14-87.qc.cable.ebox.net] has quit [Remote host closed the connection] 10:31 < sipa> yeah, that was something we learned when working on miniscript 10:31 < robot-dreams> Without MINIMALIF, would you be able to change the stack values in this way without invalidating any signatures? 10:31 < glozow> pinheadmz yup it is 10:31 < sipa> it's virtually impossible to write nontrivial malleability-resistant scripts without huge hacks 10:32 <@jnewbery> cool. Seems like you've all done a very close reading of the spec. That's great because now we can check that it was implemented properly 10:32 < willcl_ark> Otherwise people can replace the top stack element with another True or False value 10:32 <@jnewbery> any final questions on the spec before we move on to implementation? 10:32 < sipa> willcl_ark: in some cases at least, yes 10:32 < pinheadmz> bc input scripts (which contain signatures) can not be signed, and therefore are not invalidated if they are changed in flight, like a man-in-the-middle-attack 10:32 <@jnewbery> 1. EvalChecksig() (and the functions it calls) have both a return value and a success out parameter. What are those two values used for? Under what circumstances can a signature validation fail, but script execution succeed? 10:33 -!- pescador [~pescador@unaffiliated/pescador] has joined #bitcoin-core-pr-reviews 10:33 < pinheadmz> i think we covered this in a previous meeting 10:34 < pinheadmz> it can actually be ok for a sig to fail 10:34 < elle> i think sig validation can fail during checksigadd when we process the placeholder signatures 10:34 <@jnewbery> We're looking at this function and friends: https://github.com/bitcoin-core-review-club/bitcoin/commit/805a79abea841f8da6c219f7e649f7084c8b6386#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R416 10:34 < pinheadmz> maybe the script requires a checksig to return false 10:34 <@jnewbery> elle: exactly right 10:34 < sipa> elle: define "fail" :) 10:35 < michaelfolkson> Requires pinheadmz?! 10:35 < michaelfolkson> When requires? 10:36 < pinheadmz> so maybe key/msg/sig do not match, thats opchecksig -> false 10:36 < sipa> michaelfolkson: e.g. a 2-of-3 policy using CSA will require one signature check to return false 10:36 < pinheadmz> maybe then theres an IF branch that follows som logic if false 10:36 < pinheadmz> but if your pubkey is 100 bytes for example, thats not just a checksig->false, thats an error 10:36 < sipa> pinheadmz: almost 10:36 < robot-dreams> I think one example where signature validation fails but script execution can succeed (according to `bool success` and return value) is when the signature is empty 10:36 < sipa> CS/CSA have a tri-state result: good signature, bad signature, abort script 10:37 < elle> sipa: hmmm will have to think about that one. But i mean 'result in checksigadd adding 0' 10:37 < sipa> elle: exactly 10:37 < pinheadmz> sipa what am i missing ? 10:37 < sipa> there is only one way to get that: the signature has to be empty 10:38 <@jnewbery> robot-dreams: right - an empty signature is used in cases where we want the signature check to fail, and script execution to continue 10:38 < pinheadmz> aha 10:38 < sipa> pinheadmz: an actually non-empty invalid signature will abort the script 10:38 <@jnewbery> 2. Why does the MAX_SCRIPT_SIZE limit not apply to tapscript? 10:38 < michaelfolkson> I thought CSA was still minimum of 2 in 2-of-3. Not exactly 2 10:38 < sipa> it has to, anything else is not compatible with batching 10:38 < sipa> michaelfolkson: it is whatever you want it to be 10:38 < sipa> michaelfolkson: it's a script, you write it yourself 10:38 < felixweis> oh! now i see. i was thiking in sipas example before it was a typo but yeah now it makes sense. CS vs CSA 10:39 < sipa> michaelfolkson: e.g. A CS B CSA C CSA D CSA 4 EQUAL 10:39 < elle> Because we never need to reveal the entire script. Only its TaggedHash and merkle proof. So script size no longer matters. 10:39 <@jnewbery> https://github.com/bitcoin-core-review-club/bitcoin/commit/805a79abea841f8da6c219f7e649f7084c8b6386#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R452 10:39 < sipa> elle: eh no, the full script gets revealed 10:39 < sipa> but only the executed one 10:39 < robot-dreams> BIP 342 says "Since there is noΒ scriptCodeΒ directly included in the signature hash (only indirectly through a precomputable tapleaf hash), the CPU time spent on a signature check is no longer proportional to the size of the script being executed." 10:39 -!- nate34k [62a0fba3@ip98-160-251-163.lv.lv.cox.net] has quit [Ping timeout: 245 seconds] 10:39 < sipa> if the merkle tree contains multiple scripts, you only reveal the one you actually use 10:39 < robot-dreams> However, I'm not sure how / when you could do such precomputation 10:39 < elle> sipa: oh right! sorry 10:40 < sipa> robot-dreams: once per script 10:40 < sipa> it's already implemented 10:41 < pinheadmz> jnewbery i have a guess about max script size - because we have this other concept of a scriptop budget now 10:41 < pinheadmz> and the max block size / weight is still obviously a hard rule 10:41 < michaelfolkson> You'd never want to do that though right... haha. I demand one of my signatures fail. Otherwise fail the script. 10:41 < pinheadmz> but since this feels like a relaxation of a size rule im scratching my head over the soft-forkedness of it 10:42 < sipa> michaelfolkson: i don't see why not 10:42 <@jnewbery> robot-dreams pinheadmz: yes, you're right. Rationale is here: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-9 10:42 < pinheadmz> i guess because for old nodes it just looks like a witness item, not necessarily s script 10:42 < sipa> michaelfolkson: there is no point in allowing more than 2 sigs for a 2-of-3 multisig... that's just adding cost and malleability 10:42 < robot-dreams> sipa: Are you referring to the precomputation in `VerifyTaprootCommitment`? 10:43 < sipa> robot-dreams: yes, and it being passed through to the script execution using ScriptExecutionData::m_tapleaf_hash 10:43 < Murch> pinheadmz: Since either only a signature is revealed for the key path and exactly one tap branch and one script in a leaf for a script path spend, why do you think maxscriptsize is hard? 10:44 < Murch> I'm not sure what you are thinking about 10:44 < sipa> pinheadmz: max script size is enforced (for witness v0) at script execution time 10:45 <@jnewbery> We're down to 15 minutes, so I'm going to keep moving through the questions. You're always welcome to ask questions about what we've been talking about before. 10:45 < sipa> for other witness versions, no script is executed, so no limit applies 10:45 <@jnewbery> 3. Why is the script interpreter loop changed from a while loop to a for loop? What is the variable opcode_pos used for? 10:45 <@jnewbery> https://github.com/bitcoin-core-review-club/bitcoin/commit/805a79abea841f8da6c219f7e649f7084c8b6386#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R463 10:45 < robot-dreams> One more thing I don't understand, previously, what was the expensive operation we were trying to avoid with a script size limit? 10:46 < pinheadmz> jnewbery i believe this is because the positon of the last OP_CODESEPARATOR is commited to by the signature 10:46 < michaelfolkson> Because now we know how many times we want to loop. No reason to switch otherwise 10:46 < sipa> robot-dreams: well, you'll need to ask satoshi i'm afraid 10:46 <@jnewbery> pinheadmz: yep 10:46 < sipa> there are justifications for it, but the exact rule and its design goals were never documented 10:47 < sipa> michaelfolkson: no 10:47 < michaelfolkson> Hmm do tell 10:47 <@jnewbery> we need to know what position we're in, so when we hit an OP_CODESEPARATOR we can save the position 10:47 <@jnewbery> because that's committed to in the signature hash 10:47 < pinheadmz> Murch i confused myself in thinking that a V1 script would be subject to same rules as V0 script. but its not, because on the blockchain its all just witness stack items. the v0 rules decide something is a script and impose a max limit. 10:48 < Murch> pinheadmz: I see 10:48 < jonatack> the opcode position is described here: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#signature-validation 10:48 <@jnewbery> 4. Is nOpCount used during tapscript evaluation? Why/why not? 10:48 < jonatack> under "codesep_pos" i believe 10:48 < robot-dreams> Regarding the note "the CPU time spent on a signature check is no longer proportional to the size of the script being executed" from BIP 342, where was the previous signature check that was proportional to the size of the script being executed? 10:49 < jonatack> jnewbery: didn't prep but seems no 10:49 < jonatack> from quick look at the code 10:49 <@jnewbery> jonatack: you answered the easy question correctly :) 10:50 <@jnewbery> Why isn't nOpCount used for tapscript? 10:50 < robot-dreams> I believe the note about nOpCount is here: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-10 10:50 < jonatack> it's used in OP_CHECKMULTISIGVERIFY 10:50 < jonatack> which is disabled in per bip342 10:51 < sipa> robot-dreams: BIP143 includes the scriptCode in its hash, which means that every sigcheck needs to hash the entire script being hashed 10:51 <@jnewbery> robot-dreams: yes! "An opcode limit only helps to the extent that it can prevent data structures from growing unboundedly during execution (both because of memory usage, and because of time that may grow in proportion to the size of those structures). The size of stack and altstack is already independently limited. By using O(1) logic for OP_IF, OP_NOTIF, OP_ELSE, and OP_ENDIF as 10:51 <@jnewbery> suggested here and implemented here, the only other instance can be avoided as well." 10:51 < sipa> robot-dreams: so you could create a script whose execution time is proportional to its length (in witness v0) 10:52 < sipa> robot-dreams: another example is that until some time ago, OP_IF/OP_ELSE behavior was O(n) in the depth of nested IFs 10:52 < robot-dreams> sipa: Aren't you still doing this after BIP 341, since the tapleaf hash involves the entire script being executed? 10:52 < jonatack> that case appears to be line 476 after (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) 10:52 < sipa> robot-dreams: no, because it's precomputed 10:52 < jonatack> if (opcode > OP_16 && ++nOpCount > MAX_OPS_PER_SCRIPT) 10:52 < sipa> that script hashing is done once per script, not per signature 10:52 <@jnewbery> jonatack: nOpCount is incremented for _every_ opcode encountered during script execution 10:53 <@jnewbery> (for pre-tapscript) 10:53 <@jnewbery> 5. What happens if a tapscript contains an OP_CHECKSIG, OP_CHECKSIGVERIFY or OP_CHECKSIGADD with a public key that isn’t a 32 byte array? Where is that behaviour specified in the BIPs? Where is it implemented in the code? 10:53 < jonatack> yes, pre-tapscript 10:54 < robot-dreams> If the public key is empty, then the script fails and terminates immediately; if it's any other size besides 0 or 32 bytes, signature validation is assumed to be successful unless the SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_PUBKEYTYPE flag is set 10:54 <@jnewbery> robot-dreams: yes. And when is that flag set/unset? 10:54 < pinheadmz> another upgrade path 10:54 < pinheadmz> i think james prestwich wrote something enumerating all the taproot/script upgrade paths 10:54 <@jnewbery> pinheadmz: Yet Another Upgrade Mechanism 10:55 < willcl_ark> so it lets you add new sighashes? 10:55 < pinheadmz> willcl_ark signature schemese 10:55 < willcl_ark> ah ok 10:55 < michaelfolkson> https://bitcoin.stackexchange.com/questions/96951/what-are-the-different-upgradeability-features-in-the-bip-taproot-bip-341-prop 10:55 <@jnewbery> willcl_ark: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-6 10:55 < pinheadmz> so without changing anything else, if you have a signature scheme that requires a 45-byte public key that can be soft forked in just using the pubkey size as the flag 10:55 < emzy> nice 10:56 < pinheadmz> p.s. sipa any vague ideas or examples of how this could be used? (other schemese?) 10:56 <@jnewbery> 6. What happens if a tapscript contains an OP_CHECKSIG, OP_CHECKSIGVERIFY or OP_CHECKSIGADD with an empty signature? Where is that behaviour specified in the BIPs? Where is it implemented in the code? 10:56 < sipa> pinheadmz: ANYPREVOUT 10:56 < willcl_ark> jnewbery: does this mean that tagging has been accepted for oSIGHASH_NOINPUT? I seem to recall some debate around that... 10:56 < sipa> for example uses it think 10:56 < willcl_ark> wait, I'm confusing with ANYPREVOUT. 10:56 <@jnewbery> willcl_ark: I 10:57 < robot-dreams> pinheadmz: jnewbery: I don't understand the question, isn't SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_PUBKEYTYPE "policy" so nodes can set that flag however they want? 10:57 < pinheadmz> sipa hm, because bip341/2 commit to too much speicifc data from the prevout ? 10:57 < michaelfolkson> ANYPREVOUT is NOINPUT updated willcl_ark 10:57 <@jnewbery> 'm afraid I don't know the latest on SIGHASH_ANYPREVOUT 10:57 < pinheadmz> robot-dreams that is correct 10:57 < willcl_ark> :lightbulb.gif 10:57 < pinheadmz> robot-dreams so a 45 byte pubkey would be allowed in a block 10:57 < sipa> pinheadmz: you can't change sighashing for existing keys 10:57 < pinheadmz> but we dont really want nodes accepting to mempool or relaying without really understanding whats going on 10:58 <@jnewbery> robot-dreams: exactly. We set that flag as policy, so unconfirmed transactions with non 32-byte pubkeys would fail, but would be accepted if included in a block 10:58 < sipa> pinheadmz: so you either add new opcodes for the new sighash script, or you introduce them using a new pubkey type 10:58 < pinheadmz> sipa so anyprevout could still use bip340-2 all exactly the same but just toss an extra byte on the end of the pubkey? 10:58 < stacie> for the q on where the code is for when a tapscript contains a pubkey that isn't a 32 byte array, I believe it's in the EvalChecksigTapscript() function https://github.com/bitcoin-core-review-club/bitcoin/commit/805a79abea841f8da6c219f7e649f7084c8b6386#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R395 10:58 < sipa> pinheadmz: yes 10:58 < pinheadmz> nice im up to three πŸ’‘ 's today 10:59 < robot-dreams> stacie: Agreed, makes sense to me! 10:59 <@jnewbery> stacie: that's it! 10:59 < sipa> stacie: a few lines below your link, but indeed 10:59 <@jnewbery> ok, that's about time. The last question is left as an exercise for the reader 11:00 < jonatack> i wish ya'll would post filenames and linenos instead of links (GitHub loadly veerrryyy slowly for me) 11:00 <@jnewbery> oops, yes it's the else branch below that 11:00 <@jnewbery> jonatack: sorry, all the links are in interpreter.cpp today, the line number is the last few characters of the URL 11:00 < stacie> ah! that's correct :) 11:00 < pinheadmz> good jam everyone! thanks as always 🧠 jnewbery sipa 11:01 < vaguely> ty! 11:01 <@jnewbery> thanks all. Let's call it there 11:01 < Sound> Thanks! :jnewbery 11:01 <@jnewbery> #endmeeting 11:01 < robot-dreams> Thanks! 11:01 < jesseposner> thanks! 11:01 < glozow> thanks jnewbery! 11:01 < sipa> thanks for hosting, jnewbery! 11:01 < b10c> Thanks! 11:01 < felixweis> thanks! 11:01 < willcl_ark> thanks all! 11:01 < michaelfolkson> Thanks jnewbery for doing aaaalll 6 Taproot sessions. Sad we can't do another 6! 11:01 < stacie> thanks jnewbery! 11:01 < emzy> Thanks all! 11:01 < jonatack> thanks! 11:01 < elle> that was great! thanks! 11:01 < buzz08> Thanks everybody. It was great to get to know so much stuff for the first time. 11:01 <@jnewbery> thanks for coming sipa! 11:01 < michaelfolkson> And thanks sipa for providing content for 6 PR review club sessions! 11:02 < willcl_ark> it'll be merged this week so we can do the next session on activation ;) 11:02 < nir> thanks everyone! 11:02 < michaelfolkson> The best way to get rid of sipa is to move onto activation 11:02 < buzz08> :-D 11:02 < sipa> michaelfolkson: i do hope there are not another 120 taproot sessions 11:03 < michaelfolkson> 120 Taproot activation sessions 11:03 * sipa explodes 11:03 < michaelfolkson> Haha 11:03 -!- elle [~ellemouto@155.93.252.70] has left #bitcoin-core-pr-reviews [] 11:03 < jonatack> jnewbery: yes, i should have been parsing those github links rather than waiting a minute for the page to load 11:04 < willcl_ark> can't get the filename from them so easliy though 11:04 <@jnewbery> jonatack: it's annoying that the file name doesn't show up in them, but we were only in one file today 11:07 < robot-dreams> Can I follow up about MAX_SCRIPT_SIZE / precomputation? I think I'm still missing a lot of context about that. 11:07 < sipa> robot-dreams: happy to discuss 11:07 < robot-dreams> Thanks! So I think the basic pieces are, "when do we do signature checks" and "when do we call VerifyTaprootCommitment to precompute the tapleaf hash". 11:08 < robot-dreams> One guess is that we do signature checks much more often than calling VerifyTaprootCommitment, and that would resolve my confusion 11:08 -!- buzz08 [~buzz@2401:4900:234d:9c81:24dd:e572:ae6e:c262] has quit [Quit: Leaving] 11:11 < sipa> robot-dreams: yes, of course 11:12 < sipa> robot-dreams: VerifyTaprootCommitment is called once per script 11:12 < sipa> a script can contain many CS/CSA/CSV opcodes 11:14 < robot-dreams> Oh!! So we're trying to defend against the case where someone is like CS CS CS CS CS CS CS CS 11:15 -!- nir [40bba0b7@64.187.160.183] has quit [Remote host closed the connection] 11:15 < felixweis> there was a CS CS CS CS CS ... in the past 11:15 < robot-dreams> Am I understanding correctly that we could've made this precomputing optimization even without Taproot, but Taproot is a nice opportunity to make this change anyway? 11:15 < wumpus> jnewbery: b10c: fwiw my google calender link for all meetings: https://calendar.google.com/calendar/u/0?cid=MTFwcXZkZ3BkOTlubGliZjliYTg2MXZ1OHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ 11:16 < emzy> sadly you need a google account for it. 11:16 < wumpus> yes, i'm not trying to promote google or anything, you don't *need* to use it at all, was just fyi 11:17 < sipa> robot-dreams: no 11:17 < sipa> robot-dreams: because the bip143 sighash script inserts the full scriptCode in every sighash 11:18 <@jnewbery> thanks wumpus! 11:22 < sipa> MuSig2: https://eprint.iacr.org/2020/1261 11:24 -!- gimballock [84932b84@d-132-147-43-132.fl.cpe.atlanticbb.net] has quit [Remote host closed the connection] 11:26 < robot-dreams> sipa: OK, I'm looking at `SignatureHash` vs `SignatureHashSchnorr` now. In both cases you have to include the script in what you're signing. In `SignatureHash` you include the entire script. In `SignatureHashSchnorr` you include the tapleaf hash. 11:26 < sipa> bingo 11:26 < sipa> and the tapleaf has is constant size 11:26 < robot-dreams> so for a script that's like CS CS CS CS CS, in the `SignatureHash` case it's you're doing O(n^2) work in the number of CS that you have but in the `SignatureHashSchorr` case it's O(n) 11:27 < robot-dreams> Before Taproot you couldn't make such an optimization without changing consensus 11:28 < robot-dreams> Thanks so much sipa, this is very helpful 11:29 < sipa> right 11:30 < wumpus> emzy: i could export it as an 'ical' file, dunno if that's more useful but at least it's plain text and doesn't need an account: https://0bin.net/paste/QGG9KrhE#qsJLS50Vd7bESlySDugTKh72h9CE45jR5EnvtBACtqa 11:31 < emzy> see DM 11:37 -!- vaguely [~vaguely@195.181.160.175.adsl.inet-telecom.org] has left #bitcoin-core-pr-reviews [] 11:41 < wumpus> apparently there's an auto-generated one here... https://calendar.google.com/calendar/ical/11pqvdgpd99nlibf9ba861vu8s%40group.calendar.google.com/public/basic.ics 11:44 < jonatack> sipa: thanks for the paper 12:05 -!- pescador [~pescador@unaffiliated/pescador] has quit [Remote host closed the connection] 12:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 12:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 12:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds] 12:22 -!- belcher_ is now known as belcher 12:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 12:28 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:38 -!- musdom [~Thunderbi@2001:f40:904:bb14:e1a7:624e:2e60:d878] has joined #bitcoin-core-pr-reviews 12:49 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has quit [Quit: stacie] 12:55 -!- Sound [a0272ec7@dyn-160-39-46-199.dyn.columbia.edu] has quit [Remote host closed the connection] 13:07 -!- musdom [~Thunderbi@2001:f40:904:bb14:e1a7:624e:2e60:d878] has quit [Ping timeout: 240 seconds] 13:10 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 13:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 13:20 -!- benthecarman [~benthecar@194.99.104.13] has quit [Quit: Leaving] 13:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 13:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 13:41 -!- shaunsun_ [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Quit: Leaving] 13:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds] 13:53 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.5 - https://znc.in] 13:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 14:01 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection] 14:04 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 14:13 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 14:18 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 14:30 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 14:41 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 15:05 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-anszanoxiedqhnvw] has quit [Ping timeout: 272 seconds] 15:06 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-kgbadmxzqqlezakb] has joined #bitcoin-core-pr-reviews 15:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 15:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 15:15 -!- ethzero_ [sid396973@gateway/web/irccloud.com/x-otqhzrlhjruqmdmq] has quit [Ping timeout: 272 seconds] 15:15 -!- ethzero_ [sid396973@gateway/web/irccloud.com/x-unkktgtpzmkzunkt] has joined #bitcoin-core-pr-reviews 15:17 -!- drbrule [sid395654@gateway/web/irccloud.com/x-gvmrwhzqddqcyzbg] has quit [Ping timeout: 272 seconds] 15:19 -!- drbrule [sid395654@gateway/web/irccloud.com/x-xwxitsjzvaryowda] has joined #bitcoin-core-pr-reviews 16:00 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 258 seconds] 16:31 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Ping timeout: 258 seconds] 16:32 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 16:39 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 16:40 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 16:41 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews 16:42 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 16:45 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 17:39 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 17:39 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 17:41 -!- gleb [~gleb@178.150.137.228] has quit [Quit: Ping timeout (120 seconds)] 17:43 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 240 seconds] 17:44 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Read error: Connection reset by peer] 17:44 -!- gleb [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews 17:53 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 18:07 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 18:11 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 18:15 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 18:19 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 265 seconds] 18:23 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 18:41 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 19:37 -!- glozow [uid453516@gateway/web/irccloud.com/x-qkzbxqxrksojtzvz] has quit [Quit: Connection closed for inactivity] 19:41 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 19:45 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has quit [Ping timeout: 256 seconds] 19:46 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has joined #bitcoin-core-pr-reviews 19:50 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has joined #bitcoin-core-pr-reviews 19:55 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has quit [Ping timeout: 260 seconds] 20:22 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 20:29 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 21:01 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 21:38 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 21:42 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds] 21:47 -!- musdom [~Thunderbi@2001:f40:904:bb14:3436:d38:17b0:8452] has joined #bitcoin-core-pr-reviews 22:13 -!- musdom [~Thunderbi@2001:f40:904:bb14:3436:d38:17b0:8452] has quit [Remote host closed the connection] 22:14 -!- musdom [~Thunderbi@2001:f40:904:bb14:e1a7:624e:2e60:d878] has joined #bitcoin-core-pr-reviews 22:21 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 22:22 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 258 seconds] 22:56 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection] 22:57 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 23:02 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 246 seconds]