--- Day changed Wed Aug 12 2020
00:05 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-pr-reviews     
00:05 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]     
00:50 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has joined #bitcoin-core-pr-reviews     
01:08 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds]     
01:11 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #bitcoin-core-pr-reviews     
01:45 -!- b10c [~b10c@2001:16b8:2e50:e600:885a:5088:eb3:4c5d] has joined #bitcoin-core-pr-reviews     
02:05 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-toywuawfkiqcrduy] has quit [Quit: killed]     
02:05 -!- felixfoertsch [felixfoert@gateway/shell/matrix.org/x-kbztddgxnbvmftkh] has quit [Quit: killed]     
02:05 -!- mikerah[m] [mikerahmat@gateway/shell/matrix.org/x-hdppuzlxglyufmie] has quit [Quit: killed]     
02:11 -!- mikerah[m] [mikerahmat@gateway/shell/matrix.org/x-yazqymzgqnjjevma] has joined #bitcoin-core-pr-reviews     
02:18 -!- b10c_ [~b10c@2001:16b8:2e50:e600:885a:5088:eb3:4c5d] has joined #bitcoin-core-pr-reviews     
02:29 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-xpkyziydjunbcssq] has joined #bitcoin-core-pr-reviews     
02:29 -!- felixfoertsch [felixfoert@gateway/shell/matrix.org/x-twineiuqqettrhrg] has joined #bitcoin-core-pr-reviews     
02:49 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
02:53 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]     
03:19 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews     
03:55 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
03:58 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
03:58 -!- vasild_ is now known as vasild     
04:02 -!- Ona78Frami [~Ona78Fram@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
04:08 -!- Ona78Frami [~Ona78Fram@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 260 seconds]     
04:11 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has quit [Ping timeout: 260 seconds]     
05:23 -!- wullon58 [~wullon@241.243.86.88.rdns.comcable.net] has joined #bitcoin-core-pr-reviews     
05:23 -!- wullon5 [~wullon@241.243.86.88.rdns.comcable.net] has quit [Ping timeout: 256 seconds]     
05:27 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has joined #bitcoin-core-pr-reviews     
07:15 -!- b10c__ [~b10c@2001:16b8:2e50:e600:885a:5088:eb3:4c5d] has joined #bitcoin-core-pr-reviews     
07:15 -!- b10c__ [~b10c@2001:16b8:2e50:e600:885a:5088:eb3:4c5d] has quit [Client Quit]     
07:17 -!- b10c_ [~b10c@2001:16b8:2e50:e600:885a:5088:eb3:4c5d] has quit [Quit: Leaving]     
07:28 -!- b10c [~b10c@2001:16b8:2e50:e600:885a:5088:eb3:4c5d] has quit [Quit: Leaving]     
07:31 -!- jonatack [~jon@37.164.92.255] has joined #bitcoin-core-pr-reviews     
07:36 -!- jonatack [~jon@37.164.92.255] has quit [Ping timeout: 256 seconds]     
07:40 -!- jonatack [~jon@213.152.161.211] has joined #bitcoin-core-pr-reviews     
08:14 -!- Matsi [~Android@2001:464f:94d5:0:adf9:1e37:82f1:694c] has joined #bitcoin-core-pr-reviews     
08:15 -!- jonatack [~jon@213.152.161.211] has quit [Ping timeout: 256 seconds]     
08:15 -!- PaulTroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews     
08:16 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 260 seconds]     
08:17 -!- Davterra [~Davterra@89.46.114.243] has quit [Ping timeout: 256 seconds]     
08:18 -!- PaulTro__ [~paultroon@193.32.127.234] has quit [Ping timeout: 240 seconds]     
08:20 -!- Davterra [~Davterra@89.45.90.22] has joined #bitcoin-core-pr-reviews     
08:30 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]     
08:30 -!- Davterra [~Davterra@89.45.90.22] has quit [Quit: Leaving]     
08:40 -!- Matsi [~Android@2001:464f:94d5:0:adf9:1e37:82f1:694c] has quit [Remote host closed the connection]     
08:41 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
08:53 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
09:01 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has quit [Quit: Lost terminal]     
09:10 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
09:12 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has joined #bitcoin-core-pr-reviews     
09:49 < jnewbery> we'll get started in 10 minutes
09:52 -!- gzhao408 [~textual@c-73-252-251-3.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
09:59 -!- figs [68c88135@104.200.129.53] has joined #bitcoin-core-pr-reviews     
10:00 < jnewbery> #startmeeting
10:00 < jnewbery> hi folks!
10:00 -!- pinheadmz_ [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
10:00 < emzy> Hi     
10:00 < willcl_ark> hi     
10:00 < troygiorshev> hi     
10:00 < pinheadmz_> Hi! On mobile. This'll be weird
10:00 < michaelfolkson> hi     
10:01 < fjahr> hi     
10:01 < jnewbery> welcome to Bitcoin Core PR Review Club
10:01 -!- lightlike [~lightlike@p200300c7ef127d0098aa4f7ef52ed5b3.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
10:01 -!- graveyard [~graveyard@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
10:01 < jnewbery> This week we're talking about .....
10:01 -!- evanlinjin [~evanlinji@2404:4408:43ff:bb00:9cc5:84c2:8641:8dd1] has joined #bitcoin-core-pr-reviews     
10:01 < jnewbery> ... TAPROOT
10:01 < jnewbery> (again)
10:01 < fjahr> Taprrrrrrrrrroot
10:01 < troygiorshev> woot!
10:01  * graveyard party hat
10:01 < evanlinjin> Hello everyone!
10:01 < jnewbery> notes and questions are where you'd expect them: https://bitcoincore.reviews/17977-2
10:01 < evanlinjin> This is my first time :)
10:01 < graveyard> hi evanlinjin
10:01 < nehan> hi     
10:01 -!- runcrypto [5f956f1d@95.149.111.29] has joined #bitcoin-core-pr-reviews     
10:02 < willcl_ark> hi evanlinjin
10:02 -!- Guest2020 [d106dbf8@209.6.219.248] has joined #bitcoin-core-pr-reviews     
10:02 -!- runcrypto [5f956f1d@95.149.111.29] has left #bitcoin-core-pr-reviews []     
10:02 < jnewbery> hi evanlinjin. Welcome. We love new participants :)
10:02 -!- runcrypto [5f956f1d@95.149.111.29] has joined #bitcoin-core-pr-reviews     
10:02 < evanlinjin> Hello, thank you for the welcome!
10:02 < jnewbery> who had a chance to review this week's commit?
10:02 < jonatack> taproooooooo oooo ooooot (hi)
10:02 < jnewbery> y/n (no worries if you didn't have time)
10:02 < sipa> hi     
10:02 < evanlinjin> Sorry, not me
10:02 < pinheadmz_> Y     
10:02 < troygiorshev> n     
10:02 < michaelfolkson> y     
10:02 -!- s_am [uid458593@gateway/web/irccloud.com/x-hbkjecnvuwocvnvb] has joined #bitcoin-core-pr-reviews     
10:02 < sipa> i've looked at it once or twice
10:02 < fjahr> y     
10:02 < emzy> n     
10:02 < michaelfolkson> Have you reviewed this week's commit sipa?
10:02 < fjahr> sipa: probably when you wrote it :D
10:03 < jnewbery> sipa: that's good to know
10:03 < jonatack> i've looked at it less than sipa has
10:03 < jnewbery> ok, lots of notes this week. Not so many questions, but that means there's more time for _your_ questions
10:03 < jnewbery> q1: Why does BIP 340 use 32 byte public keys? How do we get away with not including the y-coordinate in the public key?
10:04 < michaelfolkson> BIP 340 laid out three options and plumped for the third
10:04 < pinheadmz_> Every x has 2 y. We just require the y to be odd (or square) or negative. Or whichever it ended up being. ;/)
10:04 < fjahr> The "Implicit Y coordinates" section in BIP340 explains it: Every X coordinate has 2 two Y coordinates. There are different options on how to determine which Y to use but the Y which is a quadratic residue was chosen.
10:04 < graveyard> since it's mirrored we can set the zone we want to look at and it's inferred
10:04 < jnewbery> michaelfolkson pinheadmz_ fjahr graveyard: exactly correct!
10:05 < pinheadmz_> And pubkey Y isn't the same as R value Y right?
10:05 < pinheadmz_> It's quad reissue for one and positive ness for the other ?
10:05 < nehan> n     
10:05 < pinheadmz_> *quadratic residue
10:06 < jnewbery> a public key in elliptic curve cryptography is a point, but because the curve is mirrored in the x-axis, as long as we all agree a scheme to determine which of the 2 possible y values to choose, then we don't actually need to explicitly state which y value we're using
10:06 < fjahr> pinheadmz_: i think they both use quad residue but had different explainations why
10:07 < nehan> deterministic symmetry breaking to choose the y
10:07 < sipa> i guess this is as good a time to mention this as any: i believe our original reasoning for picking quadratic residue for R was flawed, and we should consider making both use even
10:07 < sipa> i'm about to send a mail to list about that, today
10:07  * michaelfolkson looking up the original reasoning
10:07 < pinheadmz_> sipa interesting. I thought there were performance reasons why R should be one or the other
10:08 < emzy> lol     
10:08 < sipa> the reasoning was "it's faster for single verification" - turns out it isn't, and in fact it's probably slower in practice
10:08 < fjahr> I'm wrong. P uses even.
10:08 < jnewbery> sipa: so the final final final version of BIP 340 will have both using implicit even y?
10:08 < sipa> jnewbery: well, we could decide not to change things at this point anymore
10:08 < graveyard> should be an interesting read
10:08 < pinheadmz_> jnewbery: using the "F" word
10:08 < sipa> but i owe an explanation, since our justification was based on incorrect assumptions
10:09 < jnewbery> pinheadmz_: i didn't say "final final final final"
10:09 < pinheadmz_> Ha     
10:09 < felixweis> now i learned what a quadratic residue is for no reason :(
10:09 < felixweis> jk     
10:09 < michaelfolkson> How does one conclude it is faster and then realize it isn't? Yeah looking forward to the read too
10:09 < jnewbery> ok, next question: What other derived classes use the BaseSignatureChecker as their base class?
10:09 < nehan> michaelfolkson: +1
10:10 < jnewbery> (apart from GenericTransactionSignatureChecker)
10:10 < sipa> michaelfolkson: i'm happy to elaborate, but i think probably not during this meeting
10:10 < michaelfolkson> Yeah no problem, thanks
10:10 < fjahr> I found DummySignatureChecker and SignatureExtractorChecker
10:10 < willcl_ark> SignatureExtractorChecker
10:11 < jnewbery> sipa: thanks. Let's focus on Bitcoin Core's use of the signature verification in this meeting, and maybe circle back to the cryptography at the end if we have time
10:11 < sipa> jnewbery: sgtm
10:12 < jnewbery> fjahr willcl_ark: yep. Did you look into what those are doing?
10:12 < graveyard> evalscript?
10:13 < jnewbery> I also found one other class that inherits from BaseSignatureChecker
10:13 < fjahr> Dummy is a what is it's name says and just accept all signatures
10:13 < michaelfolkson> TransactionSignatureChecker, MutableTransacstionSignatureChecker, CacheTransactionSignatureChecker too.... were they derived from Base? (just checking)
10:14 < jnewbery> michaelfolkson: yes, see this week's notes from "The XOnlyPubKey object is used within a hierarchy of signature checker classes..."
10:14 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
10:15 < jnewbery> The other derived class I found is called FuzzedSignatureChecker
10:15 -!- SlimCogn1to [~SlimCogn1@c-66-30-46-132.hsd1.ma.comcast.net] has joined #bitcoin-core-pr-reviews     
10:15 < jnewbery> (used in fuzz testing)
10:16 < thomasb06> what number is 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F ?
10:16 < pinheadmz_> thomasb06: is that the curve order?
10:16 < jnewbery> ok, we have this hierarchy of classes for signature checking. Let's look into how it's actually doing that verification.
10:17 < thomasb06> pinheadmz_: yes
10:17 < jnewbery> what does this code do: https://github.com/bitcoin-core-review-club/bitcoin/blob/125318b6/src/script/interpreter.cpp#L1558-L1564 ?
10:17 < pinheadmz_> Checks the sighash
10:17 < thomasb06> pinheadmz_: han... Thanks
10:17 < michaelfolkson> Checks if the signature is 64 bytes or not
10:18 < felixweis> if its 65 bytes but still SIGHASH?DEFAULT its illegal bc its implicit
10:18 < fjahr> 65 bytes includes a different sighash type (not SIGHASH_DEFAULT) in the last byte. It gets stripped and the 64 bytes are used to check sig. If its 64 bytes the default is used automatically. 65 bytes with SIGHASH_DEFAULT is not allowed to protect against malleability.
10:18 < gzhao408> u can't have a 65B sig if it's hashtype == SIGHASH_DEFAULT?
10:18 < michaelfolkson> And then if it isn't checks that it isn't SIGHASH_DEFAULT as that is only defined for Taproot
10:18 < felixweis> to mitigate malleability
10:19 < pinheadmz_> gzhao408: you can
10:19 < pinheadmz_> gzhao408: but if you leave off sighash byte it it implicitly sighash all
10:19 < gzhao408> o     
10:19 < pinheadmz_> You can optionally have 0x01 as well for explicit ALL
10:19 < pinheadmz_> I think
10:20 < sipa> indeed
10:20 < pinheadmz_> Or perhaps for backwards compatibility ? sipa?
10:20 < pinheadmz_> Why allow both options
10:20 < willcl_ark> we covered this in a previous meeting but I don't quite recall now
10:20 < sipa> some things may rely on a predictable signature size, and account for 65 byte anyway
10:21 < jnewbery> willcl_ark: indeed, we talked about this a couple of weeks ago
10:21 < jnewbery> https://bitcoincore.reviews/17977#l-86
10:22 < willcl_ark> <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:22 < pinheadmz_> Lol is that from the last meeting?
10:22 < jnewbery> if there's no sighash byte (and the sig is therefore 64 bytes), then the sighash is SIGHASH_DEFAULT, which hashes the same transaction data as SIGHASH_ALL
10:22 < michaelfolkson> 2 weeks ago
10:23 < pinheadmz_> But the question of design... sounds like for interop or backwards compat
10:23 < jnewbery> so gzhao408 is right to say you can't have a 65B if it's hashtype == SIGHASH_DEFAULT
10:24 < jnewbery> you can have SIGHASH_ALL, which is the same transaction data (but the hash also includes the sighash to avoid malleability between SIGHASH_DEFAULT and SIGHASH_ALL)
10:24 -!- PaulTroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection]     
10:24 < thomasb06> p = 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1 = 115792089237316195423570985008687907853269984665640564039457584007908834671663
10:24 < jnewbery> If any of this is confusing or unclear, then I recommend rereading the notes and logs from two weeks ago
10:25 < jnewbery> Next question: Why do we have a signature cache? How does it help performance?
10:26 < fjahr> tx sigs can be evaluated multiple times by a node for example at entry of mempool and when included in a block. with the cache it doesn't have to which si saving computation resources.
10:26 < pinheadmz_> I had a few Qs a about this
10:26 < gzhao408> bc signature verification takes SOOOO LONG and u usually have to do it at least twice, atmp and in block
10:26 < michaelfolkson> Performance optimization and DoS protection
10:26 < pinheadmz_> Ok yeah I thought mempool/Block. But also don't understand the purpose of the salt
10:27 < gzhao408> le salt is DoS protection
10:27 < sipa> more defense in depth
10:28 < sipa> if there somehow is a collision in the cache's hashing, it would be on an isolated machine, rather than consistently on every node in the network
10:29 -!- pinheadmz__ [~pinheadmz@2600:380:5a14:d5ae:d86:2ca2:fdfc:eaec] has joined #bitcoin-core-pr-reviews     
10:29 < willcl_ark> that's pretty smart!
10:29 < sipa> note that there is also a full validation cache in validation.cpp
10:30 < sipa> since the introduction of that, the sigcache's role is primarily dos resistance
10:31 < jnewbery> where 'full validation cache' means caching the result of validating a single script with specified flags
10:31 < sipa> exactly
10:31 < jnewbery> I wrote a bit about that a few years ago if you want to read a bit more: https://johnnewbery.com/post/whats-new-in-bitcoin-core-v0.15-pt5/
10:31 < sipa> rather than individual signature validations
10:32 < michaelfolkson> Apparently you had a discussion on this in 2012 with Jeff Garzik sipa ;) https://bitslog.com/2013/01/23/fixed-bitcoin-vulnerability-explanation-why-the-signature-cache-is-a-dos-protection/
10:33 < jnewbery> the script cache is here: https://github.com/bitcoin/bitcoin/blob/bd00d3b1f2036893419d1e8c514a8af2c4e4b1fb/src/validation.cpp#L1472
10:33 -!- pinheadmz_ [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 256 seconds]     
10:33 < jnewbery> pinheadmz_: did you have any other questions about signature cache?
10:33 < michaelfolkson> That jnewbery blog post is very good, I remember that
10:33 < pinheadmz__> Jsut about why salt and not key by the entire sig
10:34 < sipa> pinheadmz__: it is
10:34 < sipa> Entries are SHA256(nonce || signature hash || public key || signature)
10:34 < pinheadmz__> And that won't be collision resistant without nonce?
10:34 < sipa> sure it would be
10:34 < sipa> there is no technical reason why the nonce is needed
10:34 < sipa> but it also comes at 0 cost
10:35 < pinheadmz__> Ah     
10:35 < sipa> (the midstate of "SHA256(nonce ||" is precomputed)
10:35 < pinheadmz__> Ok that is a cool design feature
10:36 < gzhao408> jnewbery: when you check against the script cache, do you go by exact verify flags or any superset is fine?
10:36 < jnewbery> gotta love them midstate precomputations
10:37 < jnewbery> gzhao408: I think it's by the exact verify flags, but I'm not 100% sure
10:38 < jnewbery> yes, the exact flags: https://github.com/bitcoin/bitcoin/blob/13c4635a3ecfbc6759301fb3c94bd5293c49388c/src/validation.cpp#L1518-L1525
10:38 < jnewbery> ok, final question. Why is the change here necessary: https://github.com/bitcoin-core-review-club/bitcoin/commit/125318b68a#diff-8a3cc5f1d2678a348e95e4884d1827f1R38-R45
10:40 < fjahr> We want nonce of ecdsa and schnorr to be different, to prevent collisions as well I assume? This also has zero cost I guess...
10:42 < sipa> exactly
10:42 < jnewbery> fjahr: exactly, we don't want ecdsa and schnorr signatures in the cache to collide (slight correction: s/nonce/key)
10:42 -!- pinheadmz [~pinheadmz@2600:380:5959:7a76:ec38:e8f0:9f23:f515] has joined #bitcoin-core-pr-reviews     
10:43 < sipa> there *should* be no need for that either, as the sighashes should never collide
10:43 < jnewbery> ok, those were the only questions I had prepared for this. What did you all think of that commit? Pretty easy to follow? Any questions?
10:44 < michaelfolkson> Sorry I don't quite get this last part. A 64 byte signature collision?
10:45 -!- pinheadmz__ [~pinheadmz@2600:380:5a14:d5ae:d86:2ca2:fdfc:eaec] has quit [Ping timeout: 260 seconds]     
10:45 < jnewbery> michaelfolkson: take a look at the signature cache. The structure is a cuckoocache, which has a key and a value
10:46 < michaelfolkson> Ok     
10:46 -!- figs [68c88135@104.200.129.53] has quit [Ping timeout: 245 seconds]     
10:46 < jnewbery> the key we use is a hash of various things, and we don't want those keys to collide
10:46 < sipa> it's really a set
10:46 -!- pinheadmz [~pinheadmz@2600:380:5959:7a76:ec38:e8f0:9f23:f515] has quit [Ping timeout: 244 seconds]     
10:47 < jnewbery> sipa: right, thanks
10:47 < michaelfolkson> Any questions evanlinjin? You still there?
10:47 < evanlinjin> I'm still here!
10:48 < evanlinjin> No questions so far. Learning a lot
10:48 < evanlinjin> I should probably look into the PR beforehand for next time though
10:48 < michaelfolkson> Otherwise can we ask about sipa about the u turn?
10:49 < gzhao408> i have question about script cache, not related to this though
10:49 < jnewbery> sure, if sipa's around and wants to talk about quadratic residues
10:49 -!- platesondeck [63e13623@CPE105611af685f-CM105611af685d.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews     
10:49 < jnewbery> gzhao408: go ahead!
10:50 < sipa> actually let me just share the mail i'm planning to send: https://0bin.net/paste/TYkaOevuGeiiMdhv#7qExtowsogSYGHGUOSFQ+gVA5Nl9Ss78lpNx-LQPyBc
10:50 < sipa> if anyone feels like reading and pointing things out that aren't clear or so, go ahead
10:51 < michaelfolkson> evanlinjin: Cool feel free to reach out or post on this channel during the week if you have general questions
10:51 -!- SlimCogn1to [~SlimCogn1@c-66-30-46-132.hsd1.ma.comcast.net] has quit [Ping timeout: 260 seconds]     
10:52 < evanlinjin> michaelfolkson: Thank you!
10:53 < thomasb06> for real numbers, the equivalent of quadratic residue is "is the number positive, or negative". If the number is positive, it has a square root. If it's negative, it hasn't. In F_p, half numbers are square roots and half are not. The Legendre symbole says if it does or not.
10:53 < felixweis> how does ed25519 get away with 32 bytes pubkeys?
10:53 < gzhao408> jnewbery: well, the reason i asked if the script cache uses exact verify flags is according to https://github.com/bitcoin/bitcoin/blob/e16718a8b3db8bf9c9715f28f4dc6080bf609776/src/script/interpreter.h#L31 they are meant to be soft forks, i.e. if a script passes for a set of flags A, then it would definitely pass for any subset of A right? hopefully i don't have that backwards. and usually if we were to verify
10:53 < gzhao408>  script in atmp, we use more flags (e.g. standardness) than when we are validating a block. but what i mean to say is... i feel like it doesn't need to be the exact verify flags?
10:53 < michaelfolkson> "The benchmark was repeatedly testing the same constant input, which apparently was around 2.5x faster than the average speed. It is a variable-time algorithm, so a good variation of inputs matters."
10:53 -!- pinheadmz [~pinheadmz@2600:380:bc33:1d92:98de:55ce:8bcf:cc00] has joined #bitcoin-core-pr-reviews     
10:54 < jnewbery> sipa: lots to digest there. My very rudimentary understanding was that to lift an x co-ordinate onto a point, the last step was squaring, so you'd always end with a quadratic residue. Is that relevant here?
10:54 < sipa> jnewbery: that's correct, but not relevant i think
10:54 < sipa> it matters for batch validation where the R.x coordinate is lifted explicitly to a point
10:55 < sipa> but batch validation is not impacted by this (as it needs a sqrt anyway)
10:55 < sipa> invididual validation does not need a sqrt, it recomputes R, and then verifies it against the signature
10:55 < jnewbery> sipa: ok, I'll go away and read the post. Thanks for writing it up!
10:55 < michaelfolkson> For what it is worth I don't think an improvement like this shouldn't be made because it is late in the day. It doesn't have knock on impacts right?
10:56 < sipa> i need to run now, but i'll read messages later here if anyone has comments
10:56 -!- pinheadmz [~pinheadmz@2600:380:bc33:1d92:98de:55ce:8bcf:cc00] has quit [Client Quit]     
10:57 < jnewbery> gzhao408: the flags used for validating are hashed into the cache entry, so it'd be quite a big redesign to make the change you're suggesting
10:58 < jnewbery> if you're interested in this subject, take a look at where we call CheckInputScripts() multiple times in ATMP to explicitly fill the cache
10:58 -!- pinheadmz [~pinheadmz@2600:380:bc33:1d92:98de:55ce:8bcf:cc00] has joined #bitcoin-core-pr-reviews     
10:58 < jnewbery> I also need to run now. Thanks everyone. Great discussion today!
10:58 -!- pinheadmz [~pinheadmz@2600:380:bc33:1d92:98de:55ce:8bcf:cc00] has quit [Client Quit]     
10:59 < thomasb06> thanks
10:59 < fjahr> jnewbery: Thanks for hosting!
10:59 < troygiorshev> yeah thanks jnewbery!
10:59 < michaelfolkson> Thanks jnewbery
11:00 -!- runcrypto [5f956f1d@95.149.111.29] has quit [Remote host closed the connection]     
11:00 < evanlinjin> Thank you jnewbery!
11:02 < willcl_ark> thanks jnewbery. sorry to miss the last 15 mins, had a spooky banging sound in the house and was tasked with investigating :s
11:02 < emzy> Thanks everybody!
11:04 < emzy> willcl_ark: Now that you mentioned it. What was it?
11:04 -!- Matsi [~Android@2001:464f:94d5:0:adf9:1e37:82f1:694c] has joined #bitcoin-core-pr-reviews     
11:05 < michaelfolkson> And that was the last time we heard from willcl_ark
11:06 < emzy> michaelfolkson: l just was thinking that.
11:06 < emzy> We will never know...
11:06 -!- gzhao408 [~textual@c-73-252-251-3.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
11:09 < michaelfolkson> "It is a relatively simple  change to address this, but that has be weighed against the impact of changing the standard at this stage."
11:10 < michaelfolkson> Surely this isn't a major concern. The PR isn't even merged into libsecp yet.
11:10 -!- Guest2020 [d106dbf8@209.6.219.248] has quit [Remote host closed the connection]     
11:12 < willcl_ark> emzy: was a weird banging sound which wife and kids thought was an intruder in the roof. After must water system troubleshooting (knocking pipes etc.) it seems it like it was a powered on (but not active) subwoofer that was building up static (in our heatwave?) and discharging it with loud thumping!
11:12 -!- Landryl3 [~Landryl@ns528256.ip-192-99-10.net] has joined #bitcoin-core-pr-reviews     
11:13 -!- GoldmanSats_ [sid428607@gateway/web/irccloud.com/x-jsdnoqgcxqwxudlx] has joined #bitcoin-core-pr-reviews     
11:13 < willcl_ark> sounds farfetched, but it was difficult to detect which direction it was originating from, being a very low freq thump. even standing in the same room as the sub, i still thought it sounded like the attic above, but all seems to be well now
11:13 -!- jkczyz_ [sid419941@gateway/web/irccloud.com/x-rebgtlkvrvslbhur] has joined #bitcoin-core-pr-reviews     
11:13 -!- ajonas_ [sid385278@gateway/web/irccloud.com/x-rymtsmerpmdkptpu] has joined #bitcoin-core-pr-reviews     
11:13 -!- platesondeck [63e13623@CPE105611af685f-CM105611af685d.cpe.net.cable.rogers.com] has quit [Remote host closed the connection]     
11:13 < emzy> how about powering it of?
11:13 < emzy> *off
11:17 < willcl_ark> it's now done ;)
11:18 < michaelfolkson> Moral of the story: Fuzz your benchmarks?
11:19 < michaelfolkson> Anyway glad you're alive willcl_ark. Off to watch some snooker
11:19 < willcl_ark> enjoy michaelfolkson!
11:20 -!- meshcoll- [meshcollid@gateway/shell/ircnow/x-qdhdkfhknqtjboec] has joined #bitcoin-core-pr-reviews     
11:20 -!- Netsplit *.net <-> *.split quits: jkczyz, meshcollider, Landryl, ajonas, GoldmanSats
11:20 -!- Landryl3 is now known as Landryl     
11:20 -!- jkczyz_ is now known as jkczyz     
11:21 -!- mikerah[m] [mikerahmat@gateway/shell/matrix.org/x-yazqymzgqnjjevma] has quit [Remote host closed the connection]     
11:21 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-xpkyziydjunbcssq] has quit [Remote host closed the connection]     
11:21 -!- felixfoertsch [felixfoert@gateway/shell/matrix.org/x-twineiuqqettrhrg] has quit [Read error: Connection reset by peer]     
11:23 -!- graveyard [~graveyard@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 251 seconds]     
11:26 -!- mikerah[m] [mikerahmat@gateway/shell/matrix.org/x-yrlteuvrtgqyfbqa] has joined #bitcoin-core-pr-reviews     
11:31 -!- pinheadmz [~pinheadmz@2600:380:bc4a:ee96:b00c:a440:1640:cfcf] has joined #bitcoin-core-pr-reviews     
11:38 -!- PaulTroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews     
11:42 -!- Davterra [~Davterra@89.45.90.22] has joined #bitcoin-core-pr-reviews     
11:43 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-eqhxcimgttyalrtz] has joined #bitcoin-core-pr-reviews     
11:43 -!- felixfoertsch [felixfoert@gateway/shell/matrix.org/x-jphldckuszpshfjc] has joined #bitcoin-core-pr-reviews     
11:55 -!- Matsi [~Android@2001:464f:94d5:0:adf9:1e37:82f1:694c] has quit [Read error: Connection reset by peer]     
11:59 -!- PaulTro__ [~paultroon@86.106.121.169] has joined #bitcoin-core-pr-reviews     
12:03 -!- PaulTroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 246 seconds]     
12:34 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]     
12:37 -!- pinheadmz [~pinheadmz@2600:380:bc4a:ee96:b00c:a440:1640:cfcf] has quit [Ping timeout: 244 seconds]     
12:38 -!- T3 [~T3@173.231.109.130] has joined #bitcoin-core-pr-reviews     
13:17 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
13:21 -!- jeken [~john@205.178.111.134] has joined #bitcoin-core-pr-reviews     
13:21 -!- meshcoll- [meshcollid@gateway/shell/ircnow/x-qdhdkfhknqtjboec] has quit [Quit: ZNC 1.7.5 - https://znc.in]     
13:22 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-zojudcrfkwmoipwe] has joined #bitcoin-core-pr-reviews     
13:25 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds]     
13:26 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
13:30 -!- jeken [~john@205.178.111.134] has quit [Quit: Lost terminal]     
13:37 -!- dergoegge [uid453889@gateway/web/irccloud.com/x-mzknfnwlewxltcow] has joined #bitcoin-core-pr-reviews     
13:42 -!- PaulTro__ [~paultroon@86.106.121.169] has quit [Remote host closed the connection]     
13:42 -!- Davterra [~Davterra@89.45.90.22] has quit [Remote host closed the connection]     
13:42 -!- Davterra [~Davterra@89.45.90.22] has joined #bitcoin-core-pr-reviews     
14:04 -!- Jacinthe32Purdy [~Jacinthe3@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
14:08 -!- evanlinjin [~evanlinji@2404:4408:43ff:bb00:9cc5:84c2:8641:8dd1] has quit [Read error: Connection reset by peer]     
14:09 -!- Jacinthe32Purdy [~Jacinthe3@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds]     
14:09 -!- evanlinjin [~evanlinji@2404:4408:43ff:bb00:9cc5:84c2:8641:8dd1] has joined #bitcoin-core-pr-reviews     
14:28 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection]     
14:38 -!- fox2p [~fox2p@ec2-3-211-34-208.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds]     
14:39 -!- fox2p [~fox2p@ec2-3-211-34-208.compute-1.amazonaws.com] has joined #bitcoin-core-pr-reviews     
15:09 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews     
15:11 -!- lightlike [~lightlike@p200300c7ef127d0098aa4f7ef52ed5b3.dip0.t-ipconnect.de] has quit [Quit: Leaving]     
15:58 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
16:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
16:00 -!- reallll is now known as belcher     
16:39 -!- Davterra [~Davterra@89.45.90.22] has quit [Remote host closed the connection]     
16:40 -!- T3 [~T3@173.231.109.130] has quit [Ping timeout: 246 seconds]     
17:11 -!- gzhao408 [~textual@c-73-252-251-3.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
17:15 -!- gzhao408 [~textual@c-73-252-251-3.hsd1.ca.comcast.net] has quit [Client Quit]     
17:37 -!- ajonas_ [sid385278@gateway/web/irccloud.com/x-rymtsmerpmdkptpu] has quit []     
17:38 -!- ajonas [sid385278@gateway/web/irccloud.com/x-eibrygsytgwxxmbq] has joined #bitcoin-core-pr-reviews     
17:52 -!- Davterra [~Davterra@89.45.90.22] has joined #bitcoin-core-pr-reviews     
18:17 -!- evanlinjin [~evanlinji@2404:4408:43ff:bb00:9cc5:84c2:8641:8dd1] has quit [Read error: Connection reset by peer]     
18:18 -!- evanlinjin [~evanlinji@2404:4408:43ff:bb00:9cc5:84c2:8641:8dd1] has joined #bitcoin-core-pr-reviews     
18:34 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has quit [Ping timeout: 265 seconds]     
18:40 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has joined #bitcoin-core-pr-reviews     
20:41 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has quit [Ping timeout: 240 seconds]     
21:46 -!- PaulTroo_ [~paultroon@86.106.121.169] has joined #bitcoin-core-pr-reviews     
21:51 -!- PaulTroo_ [~paultroon@86.106.121.169] has quit [Ping timeout: 256 seconds]     
22:05 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
22:34 -!- T3 [~T3@173.231.109.130] has joined #bitcoin-core-pr-reviews     
23:33 -!- PaulTroo_ [~paultroon@86.106.121.169] has joined #bitcoin-core-pr-reviews     
23:54 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews