--- Day changed Wed Jul 29 2020
00:40 -!- slivera [~slivera@103.231.88.27] has quit [Remote host closed the connection]     
01:03 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 256 seconds]     
01:04 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews     
02:00 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
03:03 -!- Benjamin84Kuhic [~Benjamin8@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
03:08 -!- Benjamin84Kuhic [~Benjamin8@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 265 seconds]     
03:18 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds]     
03:36 < jonatack> taprrrooooot reviewwww club in 6 1/2 hourz
03:45 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 244 seconds]     
03:58 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews     
04:17 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving]     
04:26 -!- jonatack [~jon@194.187.251.115] has joined #bitcoin-core-pr-reviews     
05:13 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews     
05:18 -!- jonatack [~jon@194.187.251.115] has quit [Ping timeout: 246 seconds]     
05:34 < pinheadmz> I feel like we could spend a session just discussing gmaxwell's review comments from last night
05:35 < pinheadmz> "im in ur codebase 0pt1miz1ng ur lines." weirdo.
05:41 -!- slivera [~slivera@103.231.88.27] has joined #bitcoin-core-pr-reviews     
06:08 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-pr-reviews     
06:12 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
06:15 -!- slivera [~slivera@103.231.88.27] has quit [Remote host closed the connection]     
06:23 < brikk> fanquake: thanks for the opportunity yesterday unfortunately saw it too late. I quickly checked the PRs and they are quite far out of my comfort zone so would probably not have had much to say on those particular ones :)
06:30 < fanquake> brikk: no worries. They might look involved but the changes are pretty straight-forward (once you're more comfortable with the build system).
06:30 < fanquake> I'm going to be up for a while again, but currently bogged down in boring Qt things.
06:31 < fanquake> Can try and sync up soon
06:38 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews     
06:38 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
06:38 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
06:39 < shesek> pinheadmz, he's pointing to areas of the code not covered by unit tests. I found it pretty funny and in good taste :)
06:52 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 240 seconds]     
06:53 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews     
06:54 -!- gzhao408 [~textual@c-73-252-251-3.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
06:54 < pinheadmz> yeah ive heard his mantra about breaking the code to test the tests at meetups... feel a little embarassed not trying theses changes myself :-)
07:14 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
07:16 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
07:18 < Jackielove4u> pinheadmz: he's pointing to a meme (in ur (code)base: https://knowyourmeme.com/memes/in-ur-base
07:18 < Jackielove4u> He has humor
07:20 -!- phyrexian [~phyrexian@unaffiliated/phyrexian] has joined #bitcoin-core-pr-reviews     
07:21 < michaelfolkson> What's the reason for linking to a bitcoin-core-review-club fork of Core rather than sipa's fork for today's Core PR review club? https://bitcoincore.reviews/17977.html
07:55 -!- csknk_ [~csknk@unaffiliated/csknk] has joined #bitcoin-core-pr-reviews     
07:55 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-pr-reviews     
07:56 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Client Quit]     
07:57 -!- csknk_ [~csknk@unaffiliated/csknk] has quit [Client Quit]     
07:58 -!- csknk [~csknk@unaffiliated/csknk] has quit [Ping timeout: 240 seconds]     
08:08 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-pr-reviews     
08:15 < pinheadmz> Jackielove4u haha yes im familiar :-)
08:26 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews     
08:30 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
08:31 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
08:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
08:34 -!- vasild_ is now known as vasild     
08:55 -!- ThatOnePrivacyGi [965000000@2405:8100:8000:5ca1::3b5:7266] has joined #bitcoin-core-pr-reviews     
09:05 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
09:06 -!- ThatOnePrivacyGi [965000000@2405:8100:8000:5ca1::3b5:7266] has quit [Remote host closed the connection]     
09:21 -!- J9 [965000000@2405:8100:8000:5ca1::3e5:8a8] has joined #bitcoin-core-pr-reviews     
09:23 < pinheadmz> is gmaxwell not on IRC anymore? Im curious if he used a code-coverage program to find these gaps in coverage or just figured out through reading and incremental testing. seems tedious to do manually
09:23 -!- raking [~raking@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
09:24 -!- J9 is now known as J9Roem     
09:24 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving]     
09:24 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews     
09:25 -!- Platapus [63e13623@CPE105611af685f-CM105611af685d.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews     
09:26 < sipa> pinheadmz: he's just trying things by hand
09:38 -!- bitcoinomnivore [2d87bb5c@45.135.187.92] has joined #bitcoin-core-pr-reviews     
09:41 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 246 seconds]     
09:42 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews     
09:43 < Platapus> meeting in 20 mins or so, right?
09:43 < emzy> yes, right.
09:44 < michaelfolkson> pinheadmz: He came on IRC for the start of the activation discussion but seems to have disappeared back to his pen and paper again
09:47 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Read error: Connection reset by peer]     
09:47 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
09:50 < jnewbery> michaelfolkson: because the link is by the commit hash, and I didn't want it to break when sipa force-pushed changes to his branch
09:51 < michaelfolkson> Ah makes sense, thanks
09:54 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
10:00 < jnewbery> #startmeeting
10:00 < jnewbery> hi folks!
10:00 < willcl_ark> hi     
10:00 < pinheadmz> 👋
10:00 < emzy> hi     
10:00 < fjahr> hi     
10:00 < jnewbery> welcome to bitcoin core PR review club :)
10:00 < gzhao408> hola
10:00 < michaelfolkson> hi     
10:01 < nehan> hi     
10:01 < jnewbery> today we're going to be looking at a commit from the taproot implementation PR
10:01 < jnewbery> notes/questions in the normal place: https://bitcoincore.reviews/17977.html
10:01 < troygiorshev> hi     
10:01 < kanzure> hi     
10:01 -!- webby [~webby@223.130.29.228] has joined #bitcoin-core-pr-reviews     
10:01 < jnewbery> normal reminder: there are no stupid questions. We're all here to learn, so please speak up if something isn't clear to you. You'll be helping others too!
10:01 < raking> hi     
10:02 < felixweis> hi     
10:02 < webby> hi     
10:02 < jonatack> hi (afk -> sleep, will read tomorrow am)
10:02 < jnewbery> other reminder: you can ask questions at any time. You don't have to ask to ask. I'll guide the discussion with some prepared questions, but feel free to jump in at any point with your question
10:02 < jnewbery> ok, let's get started
10:02 < jnewbery> who had a chance to review the commit?
10:02 < fjahr> y     
10:03 < jnewbery> (not necessarily the full PR, just the changes to signature hashing)
10:03 < pinheadmz> y     
10:03 < willcl_ark> y     
10:03 < michaelfolkson> y     
10:03 < emzy> n     
10:03 < troygiorshev> y/n     
10:03 < nehan> n     
10:03 < webby> n     
10:03 < jnewbery> great!
10:03 < raking> n     
10:03 < felixweis> y     
10:03 < jnewbery> First question: SignatureHashSchnorr() is a templated function. Why? What types T is the template function instantiated with? Hint: look at how the existing SignatureHash() function is called.
10:04 < troygiorshev> CTransaction and CMutableTransaction, I think that's it
10:04 < pinheadmz> is it because the function can accept both mutabelTX and TX ?
10:04 < willcl_ark> so you don't have to copy MutableTransaction  into a Transaction each time?
10:04 < fjahr> Different transaction types for the spending transaction. Could be CTransaction or CMutableTransaction afaict
10:04 -!- dergigi [~kvirc@188-23-106-78.adsl.highway.telekom.at] has joined #bitcoin-core-pr-reviews     
10:04 < jnewbery> troygiorshev pinheadmz willcl_ark fjahr: correct! We can call it with either a CTransaction or CMutableTransaction, just like SignatureHash()
10:05 < jnewbery> any questions about that? Is everyone happy with templates?
10:06 < jnewbery> I'll move on, but feel free to come back and ask about a previous question if it doesn't make sense to you
10:06 < jnewbery> next
10:06 < gzhao408> in what situations are we working with a CMutableTransaction? our own txns?
10:06 < jnewbery> SignatureHashSchnorr() is passed a PrecomputedTransactionData* argument. What data is stored in this structure? Why?
10:06 < pinheadmz> gzhao408 yeah, when the wallet (for ex) is constructing a tx
10:06 < jnewbery> great question gzhao408! Anyone know?
10:06 < willcl_ark> Depends on which BIP143 (Segwit v0) or BIP341 (taproot) features the tx uses.
10:06 < pinheadmz> you can add inputs and outputs and signatures to an MTX
10:06 < pinheadmz> but a TX is what comes out of a block for verification
10:07 < jnewbery> pinheadmz: how about transactions that aren't in a block?
10:07 < pinheadmz> mempool tx are also not mutable
10:07 < sipa> (for some historic context: the distinction between tx and mtx arose from wanting to cache the txid and later wtxid inside a tx)
10:07 -!- hanhua [63687d99@99-104-125-153.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
10:07 < jnewbery> pinheadmz: yep
10:08 < jnewbery> thanks sipa!
10:08 < sipa> as a tx is immutable, it can be cached without ever needing to worry about inconsistency or locking or whatever
10:08 -!- darosior [~darosior@194.36.189.246] has joined #bitcoin-core-pr-reviews     
10:08 < sipa> it may also enable having different container structures for tx that are more efficient (e.g. no separate allocation for all the inputs, outputs, scripts, ...)
10:08 < michaelfolkson> The state switches from mutable to immutable on announcement? Should check code...
10:09 < sipa> michaelfolkson: there is no state; it's an entirely different class
10:09 < pinheadmz> michaelfolkson i thought the walletconverts to tx before broadcast
10:09 -!- tuxcanfly [~tuxcanfly@68.183.231.167] has joined #bitcoin-core-pr-reviews     
10:09 < jnewbery> willcl_ark: yes, what we cache depends on the transaction type. Can you expand?
10:09 < sipa> and yes, it's converted from mtx to tx after signing
10:09 -!- triatops [triatops@gateway/vpn/protonvpn/triatops] has joined #bitcoin-core-pr-reviews     
10:09 < willcl_ark> BIP143 tx: hashPrevouts, hashSequence, hashOutputs
10:10 < willcl_ark> BIP341 tx: as BIP143 + spentAmounts + spentScripts
10:10 -!- notmandatory [~steve@cpe-72-134-225-83.natsow.res.rr.com] has joined #bitcoin-core-pr-reviews     
10:10 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has joined #bitcoin-core-pr-reviews     
10:10 < theStack> hi     
10:10 < gzhao408> thanks this is really helpful :)
10:11 < pinheadmz> willcl_ark and some are double-sha256 and some are single-sha256!
10:11 < gzhao408> why do we double-sha256 things?
10:11 < sipa> gzhao408: because that's what BIP143 prescribes :)
10:12 < jnewbery> willcl_ark: I think those are actually all cached for all witness transactions. It's just that m_spent_amounts_hash and m_spent_scripts_hash are only used if the tx is taproot
10:12 < sipa> if your question is why did BIP143's authors chose that option: it was aiming to change as little as possible compared to pre-segwit sighashing, iirc
10:12 < jnewbery> gzhao408: it's what satoshi would have wanted
10:12 < willcl_ark> jnewbery: ah ok :) that makes sense tbh
10:12 < sipa> jnewbery: the PR was just updated, it now computes only the necessaey things
10:12 -!- bitcoinomnivore [2d87bb5c@45.135.187.92] has quit [Remote host closed the connection]     
10:13 < jnewbery> sipa: ah! I haven't looked at this week's changes
10:13 < troygiorshev> gzhao408: apparently maybe protection against length extention attacks (but don't take my word on that)
10:13 < willcl_ark> Ah i checked out the PR from bitcoin/bitcoin
10:13 < sipa> troygiorshev: length extension attacks are not relevant in this context
10:14 < troygiorshev> sipa: ok thx
10:14 < sipa> (they apply when you're using a hash as a MAC, which implies there is secret data)
10:14 < jnewbery> does anyone have questions about PrecomputedTransactionData or should we move on?
10:14 < sipa> however, that may be the (ill advised) reason why satoshi chose for double hashing
10:15 < jnewbery> oh wow. PrecomputedTransactionData::Init() has changed quite a lot
10:16 < jnewbery> this is what it looked like previously: ttps://github.com/bitcoin-core-review-club/bitcoin/commit/41d08f5d77f52bec0e31bb081d85fff2d67d0467#diff-be2905e2f5218ecdbe4e55637dac75f3R1312-R1331
10:16 < jnewbery> https://github.com/bitcoin-core-review-club/bitcoin/commit/41d08f5d77f52bec0e31bb081d85fff2d67d0467#diff-be2905e2f5218ecdbe4e55637dac75f3R1312-R1331
10:16 < jnewbery> Next question. SignatureHashSchnorr() is passed a hash_type argument. How many valid hash types are there?
10:17 < michaelfolkson> 4     
10:17 < jnewbery> any advances on 4?
10:17 < willcl_ark> 5     
10:17 < willcl_ark> and two masks
10:17 < pinheadmz> 7 total i think?
10:17 < willcl_ark> or is it 6 and one mask
10:17 < pinheadmz> well 6 + default 0x00
10:17 < willcl_ark> hmmm
10:17 < sipa> how many total combinations are there?
10:17 < willcl_ark> final answer: 7
10:17 < sipa> bingo
10:17 < michaelfolkson> Are we including default and masks in that?
10:18 < jnewbery> that's right!
10:18 < jnewbery> How many valid values are there for output_type and input_type?
10:18 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-pr-reviews     
10:18 < jnewbery> https://github.com/bitcoin-core-review-club/bitcoin/commit/41d08f5d77f52bec0e31bb081d85fff2d67d0467#diff-be2905e2f5218ecdbe4e55637dac75f3R1371-R1372
10:18 < willcl_ark> 2 output and 1 input?
10:19 < michaelfolkson> I don't know what the masks are doing. Can someone explain? :)
10:19 < raking> same
10:19 < willcl_ark> they're for a bitwise AND
10:19 < gzhao408> it's leftmost bit and 2 rightmost bits
10:19 < sipa> they extract information
10:19 -!- J9Roem [965000000@2405:8100:8000:5ca1::3e5:8a8] has quit [Remote host closed the connection]     
10:19 < jnewbery> michaelfolkson: all will become clear shortly
10:19 < michaelfolkson> Ok I'll be patient
10:19 < jnewbery> willcl_ark: it can't be 1 for input, otherwise we wouldn't need a variable to store it :)
10:20 < jnewbery> any advances on 2 and 1?
10:20 < willcl_ark> jnewbery: oh, I see what I've done
10:20 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-pr-reviews     
10:21 < theStack> next try: 3 values for output, 2 values for input
10:21 < jnewbery> ok, the sighash type dictates what parts of the transaction we hash to go into the signature
10:21 < jnewbery> theStack: yes!
10:21 < willcl_ark> so input has 8? and output 7?
10:21 < willcl_ark> oh, no ok
10:22 < jnewbery> part of the sighash type indicates which parts of the transaction's outputs go into the signature hash
10:22 < jnewbery> that can take the values SIGHASH_ALL, SIGHASH_SINGLE and SIGHASH_NONE (3 different options)
10:22 < gzhao408> i read it as output = SIGHASH_ALL, SIGHHASH_SINGLE, or SIGHASH_NONE and input = SIGHASH_ANYONECANPAY or 0?
10:23 < jnewbery> the other part of the sighash indicates which parts of the transaction's inputs go into the signature hash
10:23 < sipa> gzhao408: correct
10:23 < jnewbery> that can take the values SIGHASH_ANYONECANPAY or not (2 different options)
10:24 -!- triatops [triatops@gateway/vpn/protonvpn/triatops] has quit [Quit: Leaving]     
10:24 < troygiorshev> isn't the check on line 1501 unneccesary?
10:24 < jnewbery> those can be combined in any way so we get 3*2 = 6 different possibilities
10:24 < jnewbery> so where does the 7th come from?
10:24 < pinheadmz> huh this is a much simper way to think about sighashing
10:24 -!- J9Roem [965000000@2405:8100:8000:5ca1::3aa:3afd] has joined #bitcoin-core-pr-reviews     
10:24 < pinheadmz> i been trying to kinda memorize each type individually
10:25 < pinheadmz> jnewbery that 7th is the default - sighash all
10:25 < pinheadmz> if there is no sighash byte at the end of the sig
10:25 < willcl_ark> ok I see now
10:25 < sipa> pinheadmz: but 1 is sighash_all already
10:25 < sipa> how does 0 differ?
10:25 < pinheadmz> you can not actually add 0x00 literally, it woudl be invalid
10:25 < sipa> indeed
10:25 < pinheadmz> its the default value assigned internaly if not sighash byte is present
10:25 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews     
10:26 < pinheadmz> and in fact 0x00 is invalid if it is present
10:26 < sipa> 0 is the implicit sighash type when the byte is missing
10:26 < sipa> so why is it an implicit 0 and not an implicit 1?
10:26 -!- J9Roem [965000000@2405:8100:8000:5ca1::3aa:3afd] has quit [Remote host closed the connection]     
10:26 < pinheadmz> "because thats what is says in bip341" :-)
10:26 < willcl_ark> heh     
10:26 < fjahr> jnewbery: you mean have_annex?
10:27 < sipa> pinheadmz: technically correct is the only kind of correct
10:27 < sipa> ;)     
10:27 < troygiorshev> sipa: because the mask is on the last two bits?
10:27 < jnewbery> fjahr: I don't understand what you mean
10:27 < troygiorshev> (no that's not it)
10:27 < pinheadmz> sipa i actually don tknow - thought sighash all was only, no byte added -> implict 0x00
10:27 < sipa> troygiorshev: both 0 and 1 result in the same value after masking (ALL for outputs, 0 for inputs)
10:28 < sipa> fjahr: that's something unrelated
10:28 < sipa> it's hashed as well, but elsewhere
10:28 < jnewbery> fjahr: oh, you mean the annex is the 7th option? No, that's unrelated here. We'll get to it in a bit
10:28 < fjahr> ok     
10:29 < sipa> so 0 is different from 1, because we don't want people to be able to malleate a 64-byte sig into a 65-byte one
10:29 < sipa> if it was just an implicit 1, you'd be able to add or remove it without affecting the validity of the signatire
10:30 < theStack> ah, that makes sense
10:30 < jnewbery> great point sipa. Thanks!
10:30 < jnewbery> ok, next question
10:30 < jnewbery> Just like SignatureHash(), the new function creates a local CHashWriter object. CHashWriter is a stream-like object. Other objects can be serialized into it (using the << operator), and at the end, CHashWriter::GetHash() is called to retrieve the digest.
10:30 < jnewbery> One difference from SignatureHash() is that the CHashWriter is copy-constructed from HasherTapSighash. How is that object constructed, and what’s the difference from a regular CHashWriter object?
10:30 < pinheadmz> but adding 0x01 at the end of the sig is not valid right? if you want sighash all you just leave it as a 64 byte sig with no explciit type?
10:31 < jnewbery> Oh, I see that it's now called HASHER_TAPSIGHASH in the latest push
10:31 -!- jeremyrubin [~jr@2601:645:c200:f539:149c:f818:6125:256e] has joined #bitcoin-core-pr-reviews     
10:32 -!- Davterra [~Davterra@104.200.129.213] has quit [Ping timeout: 264 seconds]     
10:32 < willcl_ark> sipa: Can't you malleate it in the opposite direction then? from 65 bytes to 64 bytes
10:32 < sipa> pinheadmz: you can do either; have a 64-byte one with implicit sighash 0, or explicitly make a 65-byte sig with hashtype 1; their semantics are the same... but the signature will still differ because the hash commits to the actual hashtype value
10:32 < sipa> willcl_ark: no
10:32 -!- me [d10646ba@209.6.70.186] has joined #bitcoin-core-pr-reviews     
10:32 < troygiorshev> jnewbery: it starts with the double tag
10:33 < jnewbery> troygiorshev: exactly
10:33 -!- me is now known as Guest86102     
10:33 < jnewbery> ok, follow-up question: what are tagged hashes and why do we use them in taproot
10:33 -!- Guest86102 [d10646ba@209.6.70.186] has quit [Remote host closed the connection]     
10:34 < pinheadmz> jnewbery i think its to prevent hash collisions with hashing the same data for other purposes
10:34 < troygiorshev> which, if I'm reading 340 right, helps prevent a collision across different uses of the same hash function
10:34 < jnewbery> pinheadmz troygiorshev: precisely
10:35 < jnewbery> See the section on tagged hashes in https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design for full motivation
10:35 < troygiorshev> gzhao408: a new meaning of "double SHA256" :D
10:35 < sipa> troygiorshev: so why HASHER_TAPSIGHASH and not just start by writing the double tag into the stream?
10:35 < pinheadmz> sipa to cache the prefix ?
10:36 < fjahr> It's 64 bytes which is the size of a block in sha256
10:36 < felixweis> midstate caching
10:36 < sipa> yup, exactly
10:36 < sipa> it's copying the midstate after hashing the tag, so it avoids redoing that for every sighash
10:37 < troygiorshev> and it's static const so we get some sort of speedup copy constructing it?
10:37 < jnewbery> pinheadmz fjahr felixweiss: great stuff. If anyone is confused by the words 'midstate' or 'block' in this context, look up the SHA256 or merkle-damgard hash construction wikipedia pages
10:38 < jnewbery> troygiorshev: I'm not sure if the static or const make a difference there. Can you explain?
10:39 < jnewbery> next question: If the hash_type does not have the ANYONECANPAY flag, certain parts of the transaction are added to the CHashWriter. What are those elements, and how is that different from SignatureHash()?
10:40 < willcl_ark> It adds prevouts_hash, spend_amounts_hash, spent_scripts_hash and sequences_hash to the cache if its not ANYONECANPAY
10:40 < pinheadmz> a hash of all the inputs' prevouts
10:41 < willcl_ark> but SignatureHash does `SHA256Uint256(GetPrevoutHash(txTo)`
10:42 < jnewbery> willcl_ark: yes! https://github.com/bitcoin-core-review-club/bitcoin/commit/41d08f5d77f52bec0e31bb081d85fff2d67d0467#diff-be2905e2f5218ecdbe4e55637dac75f3R1380-R1385
10:43 < pinheadmz> so weitness v0 sighashing only commits to the value of the input being signed?
10:43 < troygiorshev> jnewbery: hmm I may be wrong, need to explore it a bit further
10:43 < pinheadmz> but v1 sighash we commit to value of ALL inputs? (unless ANYONECANPAY)
10:43 < pinheadmz> this is related to the recent hardware wallet fee-attack that was published i think
10:44 < felixweis> thats what cache->m_spent_amounts_hash is about
10:44 < jnewbery> pinheadmz: exactly. Can you explain a bit more about the fee-attack?
10:45 < pinheadmz> ok sure, so currently you can trick a hardware wallet into signing two separate transactions each with two inputs (say a big value and a small value input) then, create a new TX with just the two high value inputs, making the input to the tx unexpectedly large. the output value doesnt change, so the wallet loses a big fee
10:46 < sipa> troygiorshev: static just makes the variable inaccessible outside the compilation unit, and const prevents code from accidentally modifying the cached value; neither changes performance, they just prevent things we don't want to happen
10:46 < michaelfolkson> Luke did a good explanation of it https://diyhpl.us/wiki/transcripts/la-bitdevs/2020-06-18-luke-dashjr-segwit-psbt-vulnerability/
10:46 < pinheadmz> although now that im trying to explain, it seems like sighash single must be used for the attack so the bip341 updated couldnt prevent that ?
10:46 < sipa> pinheadmz: it doesn't need sighash_single
10:46 -!- yuhj [59b4b31a@89.180.179.26] has joined #bitcoin-core-pr-reviews     
10:47 < pinheadmz> ok (grokking)
10:47 < sipa> and yes, signing all inputs prevents it (in sighash_all)
10:47 < sipa> *signing all input amounts
10:47 -!- Heisenberg [1b3e6a42@27.62.106.66] has joined #bitcoin-core-pr-reviews     
10:47 < jnewbery> there's a good write-up of the segwit v0 sighash fee issue in the optech newsletter: https://bitcoinops.org/en/newsletters/2020/06/10/#fee-overpayment-attack-on-multi-input-segwit-transactions
10:47 -!- Heisenberg [1b3e6a42@27.62.106.66] has quit [Remote host closed the connection]     
10:48 < pinheadmz> oh the trick is lying about the value of an input being spent
10:48 < pinheadmz> which would normally make a tx invalid on the network
10:48 < jnewbery> it's been known about for some time, and adding a new segwit version allows us to resolve that class of issues by introducing a new sighash algorithm
10:48 < pinheadmz> but the attecker throws that input away for the final tx
10:48 < jnewbery> Next question: A spend_type byte is added the CHashWriter. What are the component parts of spend_type, and what do they indicate? Hint: refer back to BIP 341 and BIP 342.
10:49 < jnewbery> fjahr: you might be able to answer this one :)
10:49 < willcl_ark> Whether it's taproot or tapscript and with annex or not
10:49 < michaelfolkson> ext_flag and annex_present
10:49 < pinheadmz> script path vs key path
10:49 < pinheadmz> oh and a flag for has_annex
10:49 < jnewbery> willcl_ark michaelfolkson pinheadmz: exactly correct
10:50 < jnewbery> it's specified in https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message
10:50 < jnewbery> "spend_type (1): equal to (ext_flag * 2) + annex_present, where annex_present is 0 if no annex is present, or 1 otherwise (the original witness stack has two or more witness elements, and the first byte of the last element is 0x50)"
10:50 < jnewbery> Last question:
10:50 < jnewbery> If the hash_type indicates SIGHASH_SINGLE, there’s a check here:
10:50 < jnewbery> if (in_pos >= tx_to.vout.size()) return false;
10:51 < jnewbery> What is that testing, and why?
10:51 -!- Heisenberg_Hunte [1b3e6a42@27.62.106.66] has joined #bitcoin-core-pr-reviews     
10:51 < pinheadmz> heh, the sighash single bug :-)
10:51 < jnewbery> pinheadmz: go on...
10:51 < felixweis> SIGHASH_SINGLE is a mode where for every input there is 1 output
10:51 < pinheadmz> if there is an input signed with sighash single but no corresponding output...
10:52 < pinheadmz> satoshis code returns an error code of 1
10:52 < pinheadmz> which gets interpreted as 32 byte hash value!
10:52 < pinheadmz> which means you can compute a signature and store in the output of the tx being spent
10:53 < pinheadmz> and this happened on mainnet and ive heard it refered to as "the coolese transaction ever"
10:53 < pinheadmz> and AFAIK, the only legit use for OP_CODESEPARATOR ?
10:53 < willcl_ark> good knowledge !
10:54 < pinheadmz> willcl_ark https://github.com/bcoin-org/bcoin/blob/master/test/tx-test.js#L260-L264
10:54 < jnewbery> hmmm I'm not sure about the part about OP_CODESEPARATOR. I know that people have tried to use that in protocols like tumblebit to allow different signing paths
10:54 < pinheadmz> ah ok, i was hoping to get correted on that
10:54 < sipa> pinheadmz: i vaguely recall that, but i don't remember the details
10:55 -!- yuhj [59b4b31a@89.180.179.26] has quit [Ping timeout: 245 seconds]     
10:55 < jnewbery> There are some mailing list posts by roconnor about OP_CODESEPARATOR in the last few months if you're interested
10:55 < jeremyrubin> wait the tx's signature can be comitted to inside the output being spent?
10:55 < pinheadmz> sipa was it not possile to fix sighashsingle in witnessv0?
10:56 < pinheadmz> jeremyrubin yes in this case bc of sighash single bug. bc the data signed is 0x0000.....01
10:56 < jnewbery> There's a writeup of the sighash_single bug here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-November/006878.html
10:56 < pinheadmz> (not an actual digest of the spending tx)
10:56 < sipa> pinheadmz: i think we just chose not to
10:56 < sipa> (i don't think it's really a bug a such, just a major footgun)
10:56 < pinheadmz> jnewbery is excellent at finding things quickly! i knew it was a peter todd post but couldnt find it
10:57 < sipa> pinheadmz: if you run into it, you're already doing something wrong
10:57 < jnewbery> the idea behind SIGHASH_SINGLE is that only the output with the corresponding index to the input being spent is included in the hash. Obviously for that to work, there needs to be an output with the same index as the input being signed
10:57 < jnewbery> that's what the check is for
10:58 < jnewbery> ok, 3 minutes left. Any final questions?
10:58 < instagibbs> https://github.com/UnderhandedCrypto/entries/blob/master/2016/JonasNick/README-JUDGES.txt nickler did a contest submission based on the weirdness
10:58 < jnewbery> s/3/2/
10:59 < michaelfolkson> Wen moar Taproot
10:59 < willcl_ark> instagibbs: and a good writeup of the bug too
10:59 < willcl_ark> that's cleared it right up
11:00 < jnewbery> michaelfolkson: we'll do more taproot soon. Next week is multiprocess though, hosted by ryanofsky. You won't want to miss it!
11:00 < jnewbery> ok, times up. Thanks all. Great session
11:00 < jnewbery> #endmeeting
11:00 < troygiorshev> thanks jnewbery!
11:00 < willcl_ark> thanks jnewbery
11:00 < pinheadmz> good jam today! thanks everyone for being so smart and so polite! 🚀
11:00 < fjahr> thanks jnewbery
11:00 < Platapus> That was a good meeting
11:00 < nehan> thanks!
11:00 < luke-jr> (doh, off by an hour)
11:00 < willcl_ark> that was a fun one
11:00 < Platapus> Thank you
11:00 < jnewbery> off by one errors are the best errors
11:00 < felixweis> thanks everyone! jnebery for hosting
11:01 < emzy> thanks!
11:01 < michaelfolkson> Thanks jnewbery
11:01 -!- webtricks [~webby@223.130.29.228] has joined #bitcoin-core-pr-reviews     
11:02 -!- dergigi [~kvirc@188-23-106-78.adsl.highway.telekom.at] has quit [Ping timeout: 245 seconds]     
11:02 -!- Platapus [63e13623@CPE105611af685f-CM105611af685d.cpe.net.cable.rogers.com] has left #bitcoin-core-pr-reviews []     
11:03 -!- aletheia_JM [~aletheia@37.120.14.16] has joined #bitcoin-core-pr-reviews     
11:04 -!- Heisenberg_Hunte [1b3e6a42@27.62.106.66] has left #bitcoin-core-pr-reviews []     
11:05 -!- webby [~webby@223.130.29.228] has quit [Ping timeout: 256 seconds]     
11:05 -!- webby [~webby@223.130.29.228] has joined #bitcoin-core-pr-reviews     
11:07 -!- notmandatory [~steve@cpe-72-134-225-83.natsow.res.rr.com] has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]     
11:08 -!- webtricks [~webby@223.130.29.228] has quit [Ping timeout: 264 seconds]     
11:08 -!- aletheia_JM [~aletheia@37.120.14.16] has left #bitcoin-core-pr-reviews ["Leaving"]     
11:08 -!- webtricks [~webby@223.130.29.228] has joined #bitcoin-core-pr-reviews     
11:08 -!- aruk [5bb4510f@91.180.81.15] has joined #bitcoin-core-pr-reviews     
11:09 -!- rabidus [~rabidus@81-175-144-89.bb.dnainternet.fi] has joined #bitcoin-core-pr-reviews     
11:09 -!- webtricks [~webby@223.130.29.228] has left #bitcoin-core-pr-reviews []     
11:11 -!- webby [~webby@223.130.29.228] has quit [Ping timeout: 240 seconds]     
11:11 -!- notmandatory [~steve@cpe-72-134-225-83.natsow.res.rr.com] has joined #bitcoin-core-pr-reviews     
11:12 -!- gzhao408 [~textual@c-73-252-251-3.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
11:41 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]     
11:46 -!- mblackmblack [~matt@178.128.230.221] has joined #bitcoin-core-pr-reviews     
11:48 -!- phantomcircuit [~phantomci@192.241.205.97] has joined #bitcoin-core-pr-reviews     
11:55 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
12:00 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #bitcoin-core-pr-reviews     
12:20 -!- aruk [5bb4510f@91.180.81.15] has quit [Ping timeout: 245 seconds]     
12:22 -!- Davterra [~Davterra@68.235.43.142] has joined #bitcoin-core-pr-reviews     
12:30 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 256 seconds]     
12:32 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews     
12:38 -!- raking [~raking@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: raking]     
12:48 -!- hanhua [63687d99@99-104-125-153.lightspeed.sntcca.sbcglobal.net] has quit [Remote host closed the connection]     
13:35 -!- Davterra [~Davterra@68.235.43.142] has quit [Ping timeout: 260 seconds]     
13:58 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]     
14:01 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
14:22 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 240 seconds]     
14:23 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews     
14:35 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection]     
15:07 -!- slivera [~slivera@103.231.88.27] has joined #bitcoin-core-pr-reviews     
15:33 -!- Davterra [~Davterra@68.235.43.94] has joined #bitcoin-core-pr-reviews     
15:44 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 264 seconds]     
15:56 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
16:11 -!- slivera [~slivera@103.231.88.27] has quit [Ping timeout: 260 seconds]     
19:11 -!- slivera [~slivera@103.231.88.10] has joined #bitcoin-core-pr-reviews     
19:28 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]     
20:09 < jonatack> meeting log is up at https://bitcoincore.reviews/17977#meeting-log
21:28 -!- slivera [~slivera@103.231.88.10] has quit [Remote host closed the connection]     
22:50 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]     
23:01 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews