--- Day changed Wed Mar 10 2021 01:12 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds] 01:14 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews 02:13 -!- jadi [~jadi@188.75.94.246] has quit [Remote host closed the connection] 02:17 -!- jadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 02:17 -!- jadijadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 02:22 -!- jadi [~jadi@188.75.94.246] has quit [Ping timeout: 264 seconds] 02:27 -!- jonatack [~jon@37.173.131.107] has joined #bitcoin-core-pr-reviews 02:33 -!- jonatack [~jon@37.173.131.107] has quit [Read error: Connection reset by peer] 02:34 -!- jonatack [~jon@37.173.131.107] has joined #bitcoin-core-pr-reviews 02:35 -!- awesome_doge [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has quit [Ping timeout: 245 seconds] 02:36 -!- TypoKign [davidtypok@gateway/shell/matrix.org/x-vnahvgqzdexajgam] has quit [Quit: Bridge terminating on SIGTERM] 02:36 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-fqzdcayiqboawwcs] has quit [Quit: Bridge terminating on SIGTERM] 02:36 -!- sunon [duncandean@gateway/shell/matrix.org/x-zirkfeasgfkitoda] has quit [Quit: Bridge terminating on SIGTERM] 02:38 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 246 seconds] 02:41 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews 02:45 -!- sunon [duncandean@gateway/shell/matrix.org/x-tkqtsilxicbkgccv] has joined #bitcoin-core-pr-reviews 02:52 -!- jonatack [~jon@37.173.131.107] has quit [Read error: Connection reset by peer] 02:53 -!- jonatack [~jon@37.173.131.107] has joined #bitcoin-core-pr-reviews 02:58 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-xaqdenlnphxppscx] has joined #bitcoin-core-pr-reviews 02:59 -!- TypoKign [davidtypok@gateway/shell/matrix.org/x-rhcyhqoiwauwymcl] has joined #bitcoin-core-pr-reviews 03:32 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-pr-reviews 03:36 -!- musdom [~Thunderbi@202.184.0.102] has quit [Ping timeout: 245 seconds] 04:49 -!- musdom [~Thunderbi@202.184.0.102] has joined #bitcoin-core-pr-reviews 05:18 -!- awesome_doge [~Thunderbi@2001-b400-e272-0349-b938-37a3-0138-72fb.emome-ip6.hinet.net] has joined #bitcoin-core-pr-reviews 05:45 -!- awesome_doge [~Thunderbi@2001-b400-e272-0349-b938-37a3-0138-72fb.emome-ip6.hinet.net] has quit [Ping timeout: 260 seconds] 06:34 -!- leonardo_ [sid489830@gateway/web/irccloud.com/x-hewqwxmrmupgkqpa] has joined #bitcoin-core-pr-reviews 06:44 -!- jonatack [~jon@37.173.131.107] has quit [Read error: Connection reset by peer] 06:44 -!- scedastik [~scedastik@c-68-58-168-96.hsd1.mi.comcast.net] has joined #bitcoin-core-pr-reviews 06:46 -!- jonatack [~jon@37.173.131.107] has joined #bitcoin-core-pr-reviews 07:31 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 07:37 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 08:08 -!- jadijadi [~jadi@188.75.94.246] has quit [Remote host closed the connection] 08:08 -!- jadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 08:14 -!- jonatack [~jon@37.173.131.107] has quit [Ping timeout: 246 seconds] 08:15 -!- jonatack [~jon@37.173.131.107] has joined #bitcoin-core-pr-reviews 08:15 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds] 08:22 -!- jadi [~jadi@188.75.94.246] has quit [Remote host closed the connection] 08:26 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 08:32 -!- mol [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer] 08:33 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 08:34 -!- musdom [~Thunderbi@202.184.0.102] has quit [Ping timeout: 245 seconds] 08:35 -!- ivanacostarubio [~ivan@189.172.199.173] has joined #bitcoin-core-pr-reviews 08:40 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 08:43 < jnewbery> Hi folks. We'll get started in about 17 minutes! 08:43 < jnewbery> Notes and questions here: https://bitcoincore.reviews/20861 08:53 -!- lightlike [~lightlike@p200300c7ef13e3001907dbbcf7a603f5.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 08:56 < michaelfolkson> Getting some --descriptors functional test failures. At one point they were deliberately being skipped. But they're failing and not being skipped (at least for me) 08:58 -!- maqusat [176a3f23@23.106.63.35] has joined #bitcoin-core-pr-reviews 08:58 < MarcoFalke> bdb disabled? 08:58 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has joined #bitcoin-core-pr-reviews 08:58 -!- eoin [332556a5@51.37.86.165] has joined #bitcoin-core-pr-reviews 08:58 < MarcoFalke> Is bdb disabled in configure? 08:58 < MarcoFalke> I think that is currently unsupported by the tests 08:59 -!- AnthonyRonning [0cee2182@12.238.33.130] has joined #bitcoin-core-pr-reviews 08:59 < michaelfolkson> I didn't disable wallet. Just without-gui and enable-debug 09:00 < michaelfolkson> I'll look into it after the session 09:00 < glozow> #startmeeting 09:00 < jnewbery> hi 09:00 < glozow> Welcome to PR Review Club everyone!!! 09:00 < amiti> hi! 09:00 < maqusat> hi 09:00 < AnthonyRonning> hi 09:00 < glozow> Anyone here for the first time? 09:00 < michaelfolkson> hi 09:00 < pinheadmz> wuddup 09:00 < willcl_ark_> hi 09:00 < lightlike> hi 09:00 < AsILayHodling> hi 09:00 < b10c> hi 09:00 < glozow> Today, we're looking at #20861 BIP 350: Implement Bech32m and use it for v1+ segwit addresses 09:00 < glozow> Notes: https://bitcoincore.reviews/20861 09:00 < glozow> PR: https://github.com/bitcoin/bitcoin/pull/20861 09:00 < cguida> hi 09:00 < cguida> my first time 09:01 < glozow> Welcome cguida! :) 09:01 < AnthonyRonning> cguida: welcome! 09:01 < cguida> thanks! :) 09:01 < glozow> Did y'all get a chance to review the PR and/or BIPs? What was your review approach? 09:01 < cguida> Didn't get to running the code yet, but did some reading 09:02 < jnewbery> 0.2y 09:02 < glozow> link to BIP350: https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki 09:02 < AnthonyRonning> browsed a bit, not familiar with the concept at all yet 09:02 < amiti> mostly just looked through the review club notes & relevant sections in bips / code, didn't do a proper review. 09:02 < nehan> hi 09:02 < michaelfolkson> I'd Concept ACK, Approach ACKed a while ago. So looking at code, running tests etc 09:03 -!- n3wBEEEE [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has joined #bitcoin-core-pr-reviews 09:03 < maqusat> just had time to glance over 09:03 < sipa> hi 09:03 < pinheadmz> read bip and ML posts, havent tried code yet 09:03 < b10c> looked over the BIP and the reviews page 09:03 < emzy> hi 09:03 < glozow> Alrighty, maybe we could start with a light conceptual question: what is Bech32 used for exactly? 09:03 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has quit [Quit: Connection closed] 09:03 < pinheadmz> encoding data with error correction! 09:03 -!- tkc [~tkc@162.154.243.234] has joined #bitcoin-core-pr-reviews 09:03 < pinheadmz> using a set of 32 characters 09:04 < glozow> pinheadmz: yes! what are we encoding, in the context of Bitcoin? 09:04 < pinheadmz> ok, segwit addresses 09:04 < pinheadmz> a segwit version followed by some amount of data 09:04 < jnewbery> *error detection and correction 09:04 < pinheadmz> could be a publichey hash, script hash or in the case of taproot, a bare public key 09:04 < b10c> addresses, but 'invoice' addresses and not IP addresses etc 09:04 < cguida> with a focus on character transcription errors 09:04 < sipa> (but despite supporting error correction, you should absolutely nevwr do that - if you detect errors, you should the user to go ask the real address again) 09:04 < pinheadmz> jnewbery thank u 09:05 < jonatack> hi 09:05 < glozow> ok so how important is error detection here, on the scale of meh to we-could-lose-coins? 09:05 < cguida> and simplifying display in qr codes! 09:05 < jnewbery> right, for sending to an address we shouldn't do error correction 09:05 < nehan> we-could-lose-coins 09:05 < pinheadmz> glozow youcould be sending bitcoin to the wrong person or to an unrecovaerbale key if you mess up! 09:05 < eoin> I'm a newb and don't know C++ or Python, how should I proceed? 09:05 < glozow> pinheadmz: yeah! so the error detection is key here :) 09:05 < schmidty> hi 09:06 < pinheadmz> eoin start in english? https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki 09:06 < michaelfolkson> glozow nehan: Depending on whether it is a character or two correction chances of losing coins is veeeery low 09:06 < AnthonyRonning> human readability is another aspect of bech32 as well, right? 09:06 < cguida> we-could-lose-coins, because the error could be a valid address 09:06 < cguida> with low probability 09:06 < jnewbery> eoin: welcome! Follow along as best you can. There are some good resources for newcomers here: https://bitcoincore.reviews/#other-resources-for-new-contributors 09:06 < jonatack> good resources also at: https://bitcoinops.org/en/topics/bech32/ 09:06 < michaelfolkson> cguida: Depending on how many characters are being corrected 09:06 < nehan> glozow: i thought we were talking about error correction generally? or do you mean specifically in bech32 addresses? 09:06 < pinheadmz> the fun parts of bech32 to me are how characters are arranged by possible visual mistake i.e. v and w 09:07 < jonatack> optech topics are a "good first stop for info" 09:07 < cguida> michaelfolkson: yes 09:07 < pinheadmz> as if someone was reading a bitcoin address and typing it in manually 09:07 < nehan> *error detection 09:07 < sipa> michaelfolkson: if you do error correction the probability of sending to the wrong address goes up spectacularly; correction only works if you make up to 2 errors (with restrictions on what those errors are); if yiu make more, it is very likely that error correction will "correct" to the wrong thing 09:07 < cguida> eoin: python is easy to get started with, send me a message if you'd like some resources 09:07 < glozow> nehan: error detection generally, yes, I want to make sure we're all clear that it's a key goal here 09:07 < jnewbery> I think we should all just pretend that error *correction* is not a thing for the purposes of this conversation 09:07 < jnewbery> and just focus on error *detection* 09:08 < pinheadmz> sure but it is cool :-) 09:08 < pinheadmz> bech32 can fix up to 3 (?) mistakes 09:08 < sipa> 2 09:08 < pinheadmz> ty 09:08 < nehan> pinheadmz: id on't think that's true! 09:08 < glozow> Ok I think we're on the same page :) Next question is a little harder: Can you describe the length extension mutation issue found in Bech32? 09:09 < michaelfolkson> The probabilities are listed somewhere I think... maybe in sipa's SF Bitcoin Devs slides 09:09 < amiti> if the address ends with a p, you can insert or delete q characters right before & it won't invalidate the checksum 09:09 < nehan> checksum for p = qqqqqp 09:09 < cguida> sipa: right, a perhaps overengineered approach would be to present the 2 or 3 closest correction strings to the user? haha 09:09 < glozow> amiti: nehan: correct! 09:10 < pinheadmz> my understanding is that the bech32 data represents a polynomial, and since x^0 = 1, you can add a bunch of extra 0's at the end of a bech32 address and its just like (checksum * 1 * 1 * 1...) so it remains valid 09:10 < glozow> can anyone tells us why this is the case? 09:10 < sipa> cguida: the BIP says you cannot do more than point out likely positions of errors 09:10 < pinheadmz> or rather data * 1 * 1 * 1... so the checksum doesnt change 09:11 < tkc> cguida: I would be interested in those beginner resources also. This is not the topic for today obviously, but how to connect with you outside this? 09:11 < cguida> tkc eoin just send me a dm here on irc 09:11 < glozow> pinheadmz: nice! could you tell us how we get from a string to a polynomial? 09:12 < cguida> pinheadz: ohhh 09:12 < cguida> pinheadmz* 09:12 < pinheadmz> not... really..... but theres this chart: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 09:12 < pinheadmz> that maps charachters to numbers 09:12 < sipa> not sure i follow about the * 1 * 1 * 1 09:12 < pinheadmz> sipa my understand is pretty abstract i just barely kinda get it 09:13 < pinheadmz> that since x^0 = 1, a bunch of 0s at the end ends up just multiplying something by 1 09:13 < pinheadmz> which doesnt change the value 09:13 < sipa> hmm, no 09:13 < sipa> glozow: i can explain if you want 09:13 < michaelfolkson> +1 :) 09:14 < pinheadmz> +p 09:14 < pinheadmz> (anyone get it?) 09:14 < glozow> heh ok so, "z"=2, "p"=1 and "q"=0, so what polynomial do we get from "zqzp?" 09:14 < cguida> the checksum for bech32 has a 1 multiplied in, bech32m uses something else 09:14 < glozow> sipa: go for it :P 09:14 < cguida> or xored in 09:14 < nehan> glozow: i think you should do it and sipa can chime in :) 09:14 < michaelfolkson> nehan: +1 09:15 < sipa> if you translate the characters to poiynomials, bech32 is essentially the equation code(x) mod g(x) = 1 09:15 < glozow> jnewbery shared this earlier https://bitcoin.stackexchange.com/questions/91602/how-does-the-bech32-length-extension-mutation-weakness-work which has a good explanation 09:15 < sipa> where code(x) is the polynomial corresponding to the data (incl checksum) of the bech32 string 09:15 < sipa> and g(x) is a specific 6th degree constant 09:16 < glozow> `g(x) = x^6 + 29x^5 + 22x^4 + 20x^3 + 21x^2 + 29x + 18` 09:16 < pinheadmz> sipa what does 6th degree constant mean ? 09:16 < sipa> pinheadmz: the exact polymonial glozow just gave 09:16 < felixweis> polynomial of degree 6 09:16 < glozow> degree 6 polynomial, same one used for every encoding 09:16 < pinheadmz> sipa is that the value gmax crunched for a week on a super computer ? 09:16 < sipa> it"s constant, not as in 0th degree, but as in: it is a constant, everyone uses tbe same 09:17 < nehan> pinheadmz: a "constant" polynomial means its coefficients are fixed, I think 09:17 < glozow> constant as in `const` :P 09:17 < sipa> pinheadmz: that one took way longer; we're talking bech32 here, not bech32m 09:17 < pinheadmz> right i was refrring to bech32 09:17 < sipa> so, we can write that as code(x) = f(x) * g(x) + 1 09:17 < pinheadmz> i understand bech32m also has a bruteforced constant 09:17 < sipa> that's the definition of modulus 09:18 < sipa> or: code(x) - 1 = f(x)*g(x) 09:18 < glozow> so to answer my earlier question "z"=2, "p"=1 and "q"=0, so what polynomial do we get from "zqzp?" 09:18 < glozow> it's `2x^3 + 0x^2 + 2x + 1` i.e. `2x^3 + 2x + 1` 09:18 < sipa> indeed! 09:19 < pinheadmz> sipa how is that a modulus? like, does it "wrap around"? bc its two polynomials being multilied? 09:19 < glozow> does everyone see how we got that? 09:19 < sipa> pinheadmz: it's just like numbers 09:19 < glozow> let me know if it's unclear and we can slow down 09:19 < sipa> yes, it wraps around 09:19 < pinheadmz> but number * number approaches infinity without wrapping 09:19 < glozow> so that modulus 1 is there so that we can't trivially create a new valid string from an old one 09:19 < sipa> it"s in the degrew instead in number of digits here 09:20 < sipa> once you go over 6th ddgree, it wraps around 09:20 < nehan> pinheadmz: you might want to study group theory a little (abstract algebra). numbers are just examples; you can apply the concepts to sets of "things" as well 09:20 < sipa> because you can subtract a bigger multiple of the modulus 09:20 < nehan> pinheadmz: in this case, the set of things is a set of polynomials, and you can operate on them 09:20 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 09:20 < cguida> glozow: I see how you got a polynomial from those inputs, but what's x in this case? 09:20 < sipa> cguida: x is just a variable name 09:21 < sipa> we nwver actually evaluate it in a specific value of x 09:21 < sipa> we need one to write polynomials, that's it 09:21 < glozow> cguida: you can think of polynomials as basically a vector of coefficients 09:21 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-pr-reviews 09:21 < cguida> ok so the x doesn't matter, just the coefficients? 09:21 < glozow> helps to distinguish polynomials from polynomial functions 09:22 < sipa> cguida: yeah, you can say zqzp is just [1,2,0,2] (we tend to write low powers first when representing as lists) 09:22 < cguida> i'll need to play with it more i think 09:23 < cguida> sipa: ok cool 09:23 < sipa> but remember that when multiplying you need to think of them as popynomials 09:23 < michaelfolkson> cguida: You might do algebra with say x, y, z without ever ascribing values to them. This way you are playing around with specific polynomials instead of x, y and z 09:23 < b10c> Zx^3 + Qx^2 + Zx + P with Z=2, P=1 and Q=0 ==> `2x^3 + 0x^2 + 2x + 1`, right? 09:23 < sipa> so! 09:23 -!- tkc [~tkc@162.154.243.234] has left #bitcoin-core-pr-reviews ["Leaving"] 09:23 < glozow> ok so we have the condition for valid Bech32 being: if your string is represented as `p(x)`, you need `p(x) = f(x)*g(x) + 1` aka `p(x) mod g(x) = 1` to be true 09:23 < nehan> how did you pick g(x)? 09:23 < glozow> b10c: yep! exactly :) 09:23 < sipa> nehan: many years of CPU time 09:23 < felixweis> pinheadpmz: can confirm what nehan said, I watched a few lectures on group theory & number theory in the past couple weeks. helped also with the understanding of last weeks topic w.r.t. the magic behind minisketch 09:24 < sipa> nehan: in 2017 09:24 < nehan> sipa: what were you looking for? 09:24 < sipa> nehan: read BIP173 :) 09:24 < nehan> sipa: ok! 09:24 < glozow> so what happens if your string ends with a "p," what's the constant term in your polyonimal? 09:25 -!- tkc [~tkc@162.154.243.234] has joined #bitcoin-core-pr-reviews 09:25 < b10c> +0 09:25 < pinheadmz> felixweis thanks i watched a few as well, can recco the Christoph Parr series on youtube. still hard to grok that multiplying to things is the "definition of a modulus" :-) 09:25 < sipa> pinheadmz: no 09:25 < felixweis> also playing around and exploring stuff with sagemath 09:25 < sipa> multiplication is multiplication 09:25 < sipa> modulo is modulo 09:25 < glozow> b10c: not quite, see the example you worked out? 09:25 < cguida> It's 1? 09:26 < glozow> cguida: bingo! 09:26 < b10c> oh yeah, +1 09:26 < glozow> b10c: :) 09:26 < b10c> mixed up q and p 09:26 < nehan> oh. for anyone else who was wondering, g(x) is GEN in bip173, i think, and is the basis of the code. I watched the talk so I recall what properties you were looking for from that. 09:27 < sipa> pinheadmz: does this help? a polynomial mod 1 is always 0; a polynomial mod x is just its constant term; a polynomial mod x^2 is iets bottom 2 terms (i.e. a*x + b) 09:27 < glozow> okay so, if your polynomial `p(x)` ends with +1, `x⋅(p(x) - 1) + 1` also works 09:27 < sipa> pinheadmz: for other examples, a polynomial mod m(x) is subtracting as many times m(x) from it as yoh can, until you end up with something of degree less than 09:27 < sipa> m 09:28 < pinheadmz> sipa that does help 09:28 < sipa> what is 2x^2 + 3x + 2 mod x+1? 09:28 < pinheadmz> but "code(x) = f(x) * g(x) + 1 --- that's the definition of modulus" ? 09:28 < pinheadmz> sipa 3x+2 ? 09:29 -!- AnthonyRonning [0cee2182@12.238.33.130] has quit [Quit: Connection closed] 09:29 < glozow> so then, let's say your polyonimal `p(x)` corresponds to string "zzp", what does `x*p(x)` correspond to? 09:29 < sipa> pinheadmz: no, you subtracted x^2, that's not a multiple of x+1 09:29 < cguida> glozow: by "works", you mean, solves the equation p(x)*g(x) = 1? 09:29 < glozow> cguida: yes 09:29 < pinheadmz> oh its just x+1 ? 09:30 < sipa> pinheadmz: no 09:30 < glozow> er, it solves `p(x) = f(x)*g(x) + 1` for some `f(x)` 09:30 < glozow> but yes same idea 09:30 < pinheadmz> sorry i can work it out later, math on IRC is making me sweat 09:30 < sipa> first subtract 2x*(x+1), you get what? 09:30 -!- AnthonyRonning [0cee2182@12.238.33.130] has joined #bitcoin-core-pr-reviews 09:30 < michaelfolkson> x+2 09:30 < sipa> indeed 09:30 < cguida> whoops, yeah, i missed an f(x) haha 09:30 < sipa> what is x+2 mod x+1? 09:31 < pinheadmz> ok i see that michaelfolkson 09:31 < michaelfolkson> 1 09:31 < sipa> bingo 09:31 < sipa> so x^2 + 3x + 2 mod x+1 = 1 09:31 < michaelfolkson> Math is horrible until it clicks pinheadmz. Then it is beautiful ;) 09:31 < glozow> okie we probably should move on, heh 09:32 < glozow> How does Bech32m solve this length extension mutation issue? 09:32 < cguida> new checksum constant! 09:33 -!- tkc [~tkc@162.154.243.234] has quit [Quit: Leaving] 09:33 < glozow> cguida: yep! 09:33 < sipa> nehan: indeed g(x) is the generator 09:33 < cguida> i'm not sure why that fixes, other than to guess that it's because it's much larger than 1, so it doens't correspond to any of the letters 09:33 -!- tkc [~tkc@162.154.243.234] has joined #bitcoin-core-pr-reviews 09:34 < glozow> Imma just keep chugging along with the review club questions. Moving forward, which addresses will be encoded using Bech32, and which ones with Bech32m? 09:35 < cguida> segwit v0 with bech32, subsequent versions bech32m 09:35 < pinheadmz> segwit v0 keeps bech32, everything from here on out (starting with taproot, witness v1) will get bech32m 09:35 < glozow> cguida: pinheadmz: correct! 09:35 < sipa> cguida: the specific change doesn't work anymore, because to do the same, you'd need to (a) subtract the new constant (b) multiply by a power of x (c) add the constant again... if you work that out, you'll see that it requires changing many more characters changed, due to the new constant having many more nonzero coefficients 09:35 < glozow> How does this affect the compatibility of existing software clients? 09:35 < cguida> glozow: it doesn't! 09:36 < cguida> hopefully haha 09:36 -!- tkc [~tkc@162.154.243.234] has quit [Client Quit] 09:36 < b10c> Does not affect it: v0 does not change and v1 likely doesn't exist yet 09:36 < pinheadmz> existing, assuming no one has implemented taproot wallets yet using bech32 ...? 09:36 < b10c> v1 clients* 09:36 < sipa> pinheadmz: if they did, not for mainnet i hope! 09:36 < michaelfolkson> pinheadmz: Assuming there are no problems with bech32m (which hopefully and most likely will be the case) 09:36 < AnthonyRonning> so anyone that can send to a native segwit address can send to bech32m by default? 09:36 < cguida> sipa: ahh cool, so it's sort of unpredictable what letters would need to change in order to keep the same checksum 09:37 < pinheadmz> although sipa if i gave you a witness v1 bech32 address an old wallet would still be able to send to that address right? 09:37 < cguida> sipa: and it would be multiple letters rather than just a single q 09:37 < sipa> pinheadmz: yes, but also any miner could steal it 09:37 < glozow> AnthonyRonning: they must, if it's v1+ 09:37 < pinheadmz> before activation yah 09:38 < AnthonyRonning> glozow: cool, good to know! 09:38 < pinheadmz> but after lockin, a wallet that doesnt know about bech32m would still work? 09:38 < pinheadmz> just a version byte and data, assuming there were no actual length attacks against you 09:38 < sipa> pinheadmz: yes, but nobody will be creating bech32 v1+ addresses 09:38 < sipa> so that's not a concern 09:38 < pinheadmz> ok 09:39 < michaelfolkson> A wallet either recognizes SegWit v1 or it doesn't. bech32m is just encoding for SegWit v1 addresses 09:39 < pinheadmz> well, i did send this one a few months ago https://blockstream.info/address/bc1pqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqs3wf0qm 09:39 < pinheadmz> ;-) 09:39 < glozow> Let's dive into code :) How does `Decode` check whether an address is encoded as Bech32 or Bech32m? Can a string be valid in both formats? 09:39 < glozow> link to code: https://github.com/bitcoin/bitcoin/blob/835ff6b8568291870652ca0d33d934039e7b84a8/src/bech32.cpp#L168 09:40 < sipa> cguida: yeah... though there could be many more or less similar types of mutations with different constants; the bech32m constant was chosen by searching through many patterns of classes of mutations, and picking one that prevents most 09:40 < b10c> so would the current signet explorer does encode v1 addresses as v0: https://explorer.bc-2.jp/address/tb1p85lx6qpdvs4vlpjnhnexhqwmuetd7klc3dk4ggsmycrtc78n6nnqg2u5a8 would that break? 09:40 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 09:40 < cguida> glozow: i wasn't clear on this. it appears to be something in "polymod" 09:41 < b10c> - would* 09:41 < michaelfolkson> glozow: A string cannot be valid in both formats. Just looking at the code 09:41 < cguida> and i hear that it's impossible to have an address be both valid bech32 and bech32m 09:41 < amiti> it can't be valid in both formats, you can xor with 1 / the new constant (`0x2bc830a3`) to see if you get the checksum 09:42 < AnthonyRonning> wait so wallets/clients that do checksum checks before sending won't be able to send to a bech32m check until they update their encoding methods? 09:42 < cguida> michaelfolkson: where do you see that in the code? 09:42 < glozow> amiti: winner! yep, you basically check the mod and see which encoding it matches 09:42 < AnthonyRonning> s/encoding/decoding 09:43 < lightlike> it's in VerifyChecksum() - looks like you get the constant back 09:43 < michaelfolkson> cguida: I just know that from other reading (BIP etc) 09:43 -!- tkc_ [~tkc@162.154.243.234] has joined #bitcoin-core-pr-reviews 09:43 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 09:43 < glozow> michaelfolkson: cguida: amiti: yes, the mod can't be both 1 and 0x2bc830a3 09:43 < sipa> b10c: indeed, existing explorers show bech32 instead of bech32m for v1+... one reason why it'd nice to get bip350 implemented and adopted soon *hint* *hint* 09:44 < glozow> Next question, when I was reviewing the PR I found it peculiar that there was a space in this test: https://github.com/bitcoin/bitcoin/blob/835ff6b8568291870652ca0d33d934039e7b84a8/src/test/bech32_tests.cpp#L80 09:44 < glozow> and then I realized it's not on accident ;) 09:45 < glozow> so what's the space for? 09:45 < michaelfolkson> sipa: In the case they didn't.... and Taproot was to activate... I guess just temporarily it would suck for SegWit v1 lookups. But they would probably implement it without any need for hints?! 09:45 < cguida> glozow: would love to see what the proof of that is 09:45 < lightlike> would it be possible (with a near-zero probability) that we want to decode a BECH32M, have a wrong checksum, but get back a valid BECH32 encoding instead of Encoding::INVALID? 09:46 < michaelfolkson> sipa: I get it makes sense to be merged into Core soon though 09:46 < nehan> glowzow: space is not a valid character, right? but someone may copy/paste an address and get spaces 09:46 < glozow> lightlike: I wondered this too :O maybe sipa has an answer? 09:46 < sipa> lightlike: yes, but if that mismatches the expected code for the version number, it'll still be rejected 09:46 < glozow> nehan: yep! 09:47 < glozow> space is 0x20 in US-ASCII 09:47 < glozow> which is not a valid character in the HRP 09:47 < sipa> if you get a v0 with BECH32M: bad 09:47 < michaelfolkson> I don't know what a space represents in base32 or bech32. Invalid character, so it gets ignored? Or causes an error? 09:47 < sipa> michaelfolkson: invalid 09:47 < glozow> michaelfolkson: it's invalid 09:47 < nehan> michaelfolkson: error 09:47 < sipa> but why is the test there then? 09:48 < sipa> if you get v1+ with BECH32: bad 09:48 < jnewbery> I was expecting to see a test for the same string without the space being valid 09:48 < sipa> jnewbery: that'd be a good testcase too 09:48 < nehan> jnewbery: that seems better! 09:48 < sipa> why not both? 09:49 < sipa> this test also does something useful :) 09:49 < nehan> sipa: if the data-space is not a valid address, then it might be failing because of that, and not because of the space 09:49 < cguida> to make sure an error is thrown when a space is included 09:49 < nehan> but sure both! 09:49 < sipa> nehan: yes, but this test tests something similar 09:50 < sipa> both are trying to anticipate a particular mistake an implementer might make 09:50 < sipa> yours is: implementer accepts the space but ignores it 09:50 < glozow> it's particularly testing that the HRP can't have a space? 09:50 < cguida> in case the address is sent in parts, or with newlines or something 09:50 < b10c> why does L81 and L82 in the tests contain strings with "" in the middle? i.e. "\x7f""1g6xzxy" and "\x80""1vctc34", 09:50 < sipa> glozow: yes, but in combimation with something else 09:51 < sipa> b10c: that's just how you add unprintable characters inside a string 09:51 < sipa> glozow: i think here it's assuming the implementer treats the space as a valid HRP 09:51 < b10c> sipa: ty! 09:51 < sipa> (with value 32) 09:51 < cguida> what's hrp? sorry 09:52 < glozow> cguida: human readable part 09:52 < cguida> human readable part? 09:52 < glozow> yeah 09:52 < cguida> cool 09:52 -!- n3wBEEEE [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has quit [Quit: Connection closed] 09:52 < glozow> like "bc" or "bcrt" or "tb" 09:52 -!- n3wBEEEE [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has joined #bitcoin-core-pr-reviews 09:52 < glozow> = bitcoin, bitcoin regtest, testnet bitcoin 09:52 < glozow> (i assume) 09:53 < nehan> sipa: (this is super pedantic sorry) i think space+valid is better because it reduces the reasons why the test might fail to the one you're checking for. ok, space+invalid might happen too (you copied off by 1) but the reader of the test might not realize that space+invalid might fail even if space+valid passes, and maybe in the future someone redoes the tests and misses that. 09:53 < glozow> also cguida: note that newline is a different character from space, although also invalid 09:53 < michaelfolkson> glozow: Right https://bitcoin.stackexchange.com/questions/100508/can-you-break-down-what-data-is-encoded-into-a-bech32-address 09:54 < michaelfolkson> Signet is tb as well 09:54 < cguida> glozow: true, i was picturing a scenario in which the address is sent with newlines, and the user replaces them with a space thinking they need to be separate? really stretching here haha 09:54 < jnewbery> maybe it'd be good to add a test that a valid test vector with a trailing space fails 09:55 < MarcoFalke> jnewbery: I think we have that one already 09:55 < nehan> also my concern above could easily be fixed with comments. 09:55 < MarcoFalke> (oh, maybe we don't) 09:55 < sipa> nehan: i don"t understand why one is better than the other? 09:56 < sipa> they both test distinct failures 09:56 < b10c> MarcoFalke: don't see one 09:56 < sipa> non-overlapping ones 09:56 < glozow> Last question before we wrap up: Is Bech32 case-sensitive? 09:56 < nehan> since we're close to the end i have a question: addresses are 10 characters longer now, meaning there's more chance for a user to make a mistake. did anyone think about how to balance the # of errors detected vs. likelihood of mistake? 09:56 < glozow> (and Bech32m) 09:56 < michaelfolkson> Anyone want to add a PR to add a test for trailing space? If not I'm happy to do it 09:56 < eoin> no 09:56 < maqusat> no, but mixed case is not accepted 09:56 < emzy> ni 09:56 < emzy> no 09:57 < cguida> sipa: ahh, i see it. it's to test that p2pkh addresses with a leading space are invalid 09:57 < pinheadmz> it is kinda, mixed case is not allowed 09:57 < emzy> No, because it ends up in smaller QR codes. 09:57 < michaelfolkson> Oh it isn't merged yet, so it would be a PR to sipa's branch 09:57 < pinheadmz> and sadly many exchanges dont accept ALL CAPS bech32 addresses 09:57 < glozow> I suppose it depends on what you mean by case-sensitive, but I like maqusat's and pinheadmz's answer 09:57 < pinheadmz> even though qr codes are better 09:57 < glozow> you can't have mixed case 09:57 < glozow> but both uppercase and lowercase versions are acceptable 09:58 < pinheadmz> (btw did u know Ethereum uses MiXeD cAsE as its checksum? yeesh) 09:58 < glozow> hahahahaha 09:59 < pinheadmz> clever for backwards compatability but o_O ?! 09:59 < nehan> sipa: i am predicting a future reader of the tests might miss that they test different things and think the two tests are redundant 09:59 < glozow> Alrighty that wraps up our Bech32m program for today, I hope everybody learned something! ^_^ 09:59 < glozow> #endmeeting 09:59 < nehan> sipa: now that i say it like that it doesn't seem worth talking about 09:59 < pinheadmz> thanks glozoppppppppppppw ! 09:59 < AnthonyRonning> thank you glozow & everyone else! 09:59 < maqusat> thank you! 09:59 < nehan> thank you glozow! 10:00 < b10c> ty glozow! 10:00 < amiti> thank you glozow! 10:00 < b10c> and sipa! 10:00 < lightlike> thanks glozow! 10:00 < cguida> thanks glozow! 10:00 < michaelfolkson> pinheadmz: Hahaha 10:00 < emzy> Thank you glozow, sipa, jnewbery and all others! 10:00 < eoin> ry glozow 10:00 < ivanacostarubio> I did. Thank you! 10:00 < eoin> ty glozow 10:00 -!- AnthonyRonning [0cee2182@12.238.33.130] has quit [Quit: Connection closed] 10:00 -!- tkc_ [~tkc@162.154.243.234] has quit [Ping timeout: 260 seconds] 10:00 < michaelfolkson> Thanks glozow 10:00 < pinheadmz> michaelfolkson doesnt work without a q on the end i know i know 10:00 < jnewbery> thank you glozow! Great review club! 10:01 < MarcoFalke> jnewbery: Who's up next week? 10:01 < michaelfolkson> pinheadmz: Don't get to create a valid glozow that easily 10:01 < jnewbery> MarcoFalke: you are! 10:01 * MarcoFalke blushes 10:01 < MarcoFalke> fuzzing! 10:01 < jnewbery> which PR? 10:01 < glozow> <3 10:02 < MarcoFalke> https://github.com/bitcoin/bitcoin/pull/21142 10:02 < MarcoFalke> ( fuzz: Add tx_pool fuzz target #21142 ) 10:02 < cguida> sweet, let's do some fuzzing 10:02 -!- tkc_ [~tkc_@162.154.243.234] has joined #bitcoin-core-pr-reviews 10:04 -!- n3wBEEEE [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has quit [Quit: Connection closed] 10:04 < glozow> hoho, let's fuzz out some bugs in MemPoolAccept 10:05 < sipa> fuzzy 10:05 -!- eoin [332556a5@51.37.86.165] has quit [Ping timeout: 240 seconds] 10:05 -!- maqusat [176a3f23@23.106.63.35] has quit [Quit: Connection closed] 10:05 < emzy> So I can heat the place with my PC. *g* 10:06 < cguida> gettin' fuzzy wit' it 10:07 < jonatack> Meeting log is up at https://bitcoincore.reviews/20861#meeting-log 🍰 10:08 < michaelfolkson> emzy: Who needs to earn mining rewards with your heating when you can find bugs with your heating instead? 10:08 < emzy> \o/ 10:10 -!- jonatack [~jon@37.173.131.107] has quit [Quit: jonatack] 10:10 -!- jonatack [~jon@37.173.131.107] has joined #bitcoin-core-pr-reviews 10:10 -!- jonatack [~jon@37.173.131.107] has quit [Read error: Connection reset by peer] 10:11 -!- jonatack [~jon@37.173.131.107] has joined #bitcoin-core-pr-reviews 10:11 -!- jonatack [~jon@37.173.131.107] has quit [Client Quit] 10:11 < cguida> michaelfolkson: proof-of-bugs 10:11 -!- jonatack [~jon@37.173.131.107] has joined #bitcoin-core-pr-reviews 10:12 < amiti> sipa: I'm still kinda confused about the ` 1xj0phk` test case. you're saying its testing something beyond a space being an invalid HRP character? 10:12 < sipa> amiti: it's testing exactly tbat 10:12 -!- jonatack [~jon@37.173.131.107] has quit [Client Quit] 10:12 < amiti> oh, ok. I guess I misunderstood the conversation then. thanks :) 10:13 -!- jonatack [~jon@37.173.131.107] has joined #bitcoin-core-pr-reviews 10:13 < sipa> (but combined with the assumption that the implementer does not strip the character when processing) 10:13 -!- tkc_ [~tkc_@162.154.243.234] has quit [Quit: Leaving] 10:13 < amiti> ah, I see 10:13 -!- tkc_ [a29af3ea@162.154.243.234] has joined #bitcoin-core-pr-reviews 10:13 < sipa> while testcase of " " + (valid bech32m) would test that an implementation doesn't forget to.treat hrp space as invalid, combimed with skipping it 10:17 < amiti> I think you're saying.. we shouldn't test that " " + (valid bech32m) returns INVALID because it would be appropriate behavior for the implementation to strip the space and parse the string 10:17 < amiti> do I have that right? 10:18 < cguida> ah, right, i forgot that this was only testing the hrp, not the whole address 10:18 < amiti> but, an HRP of just a " " would be invalid regardless? 10:19 < sipa> amiti: no, we should test both 10:19 < sipa> i'm just saying they're testing distinct mistakes implementers could make 10:19 < glozow> sipa: and this is why the test is an extra " " in the front instead of a "\x20" as well? 10:20 < sipa> glozow: that's exactly the sams 10:20 < sipa> you can write spaces as \x20 if you like :) 10:20 < glozow> well i wondered why you didn't do \x20, since that would've been a bit less confoozing 10:22 < sipa> a space is not an unprintable character, so no need 10:23 < glozow> ahhh true 10:30 -!- mol_ [mol@gateway/vpn/protonvpn/molly] has joined #bitcoin-core-pr-reviews 10:31 < cguida> I guess the question is, why would an implementer somehow have a space in the middle of the address? makes sense to make sure they're stripping whitespace, but i'm trying to picture a scenario in which a developer has a bc1… string and somehow ends up with a space between the bc and the 1 10:31 < cguida> i'm not a wallet dev though haha 10:31 < sipa> not an implementer 10:31 < sipa> the user would accidentally type a space before the address 10:32 < sipa> and we want test vectors to make sure that implementations correctly reject that 10:32 < cguida> right, but then wouldn't the test string be " bc1…", not " 1…"? 10:32 < mol_> can a space after the address cause error? 10:32 < sipa> ?? 10:33 < mol_> im guessing not 10:33 -!- ccdle12 [955adef3@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews 10:33 < sipa> sorry, my '??' is in response to cguida 10:34 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 10:35 < cguida> sipa: a bech32 address starts with "bc1", right? so in order to hit the above test case, the user would have to type "bc 1…", and the implementer would have to not strip that out, correct? 10:35 < sipa> " bc1" is also invalid 10:36 < sipa> but fair point, we could also have tests for "bc 1..." or "b c1..." 10:41 < sipa> pinheadmz: so, in order to define a modulus operation you need sort of a "metric" to measure bigger/smaller elements of your ring; for integers that's just the integer value itself, for polynomials that's the degree 10:42 < pinheadmz> ok 10:42 < pinheadmz> and i get you can divide polynomials and have a "remainder" like integer modulos 10:42 < sipa> so the definition of (x mod m) is just: the value r such that x = r + q*m for some quotient q, such that r is "less" than m 10:45 < pinheadmz> aha so when you say "code(x) = f(x) * g(x) + 1" then g(x) is the modulus, f(x) is the quotient and 1 is the remainder 10:45 < pinheadmz> and code(x) is what ever you started with, the bech32 string 10:45 < sipa> exactly 10:45 < pinheadmz> dude thanks for taking the extra time ;-) 10:45 < pinheadmz> ok and so in bech32 , 1 is the remainder, as defined in bip173 ? 10:46 < sipa> indeed 10:46 < pinheadmz> so the 1 is chosen and is part of the bitcoin spec, not a property of modulo math in general 10:46 < pinheadmz> thats my confusion i think 10:46 < cguida> >" bc1" is also invalid 10:46 < pinheadmz> and in bech32m the remainder is some crazy new number ? 10:46 -!- jonatack [~jon@37.173.131.107] has quit [Read error: Connection reset by peer] 10:46 < cguida> sipa: right, and isn't that the case you're referring to? where the user enters a space before the address? 10:47 -!- jonatack [~jon@37.173.131.107] has joined #bitcoin-core-pr-reviews 10:47 < sipa> cguida: yes 10:47 < sipa> cguida: i have no idea what we're disagreeing about now actually ;) 10:47 < sipa> pinheadmz: indeed, 21x^5 + 28x^4 + 16x^3 + 12x^2 + 5x + 3 10:48 < sipa> pinheadmz: which works out; our modulus has degree 5, and the generator (the divisor) has degree 6 10:49 < pinheadmz> works out meaning the remainder is same degree as modulus and smaller than generator? 10:49 < sipa> remainder == modulus 10:50 < sipa> different words for the same thing 10:50 < pinheadmz> > "code(x) = f(x) * g(x) + 1" then g(x) is the modulus, f(x) is the quotient and 1 is the remainder 10:50 < pinheadmz> i thought modulus and remainder are different ? 10:51 < sipa> oh 10:51 < sipa> seems i'm wrong about my terminology 10:51 < sipa> the modulus operation == taking the remainder 10:51 < pinheadmz> probably me 10:51 < pinheadmz> yes 10:51 < sipa> but "the modulus" is apparently the divisor in this context, not the remainder 10:51 < pinheadmz> yes cool 10:52 < pinheadmz> so "1" and "21x^5 + 28x^4 + 16x^3 + 12x^2 + 5x + 3" -- these are remainders aka results of modulus operation 10:52 < sipa> indeed 10:53 < pinheadmz> and this "works out" because the result of modulus aka remainder is smaller than the divisor which of course it must be just like x mod y must be smaller than y 10:54 < sipa> indeed 10:54 < sipa> given that our generator aka the modulus is 6th degree, the remainder has to be of 5th degree or less 10:54 < sipa> and there are 32^6 such polynomials, and we searched them all :) 10:55 < pinheadmz> ahhhhhh hahahaha 10:56 < cguida> sipa: Sorry, I'm just trying to understand what this test is for. My point is that the test case in the code says " 1xj0phk", which (supposedly) tests whether the user enters a space before the address. But, in the real world, the test string wouldn't look like " 1…"; it would look like " bc1…". And a test case with a space anywhere in the string would be sufficient to check whether the implementer is forgetting to 10:56 < cguida> trip whitespace, so I don't understand why the space specifically needs to be at the beginning. Perhaps this is just to emphasize that the beginning of the string is the most likely place for spaces in the string, in order to remind implementers to check that they're doing this? Maybe my confusion is coming from not understanding what these tests are testing. 10:56 < pinheadmz> so this 32^6 space is what you searched recently for bech32m but back in the day (bech32) i remember you talking about using years of CPU time on a blockstream supercomputer or seomthing -- what was that for? (because the "remainder" value for bech32 is just "1"... ) 10:57 < sipa> pinheadmz: in the bech32 days we did a giant search with blockstream hardware to find g(x) 10:57 < pinheadmz> oh the divisor ok awesome 10:57 < pinheadmz> thanks again for staying after class for me :-) 10:57 < sipa> for bech32m we did slightly less giant search to find the best remainder 10:58 -!- jonatack [~jon@37.173.131.107] has quit [Quit: jonatack] 10:58 < sipa> cguida: now i understand; this is a test for bech32m, not for segwit addresses; any bech32 implementation needs this, not just things in the context of bitcoin or addresses or segwit 10:58 < sipa> and yes, the space is at the beginning because it's the most likely place where it could occur 10:59 < cguida> sipa: ok cool, sorry for all the questions :) 10:59 < sipa> cguida: bip173 and bip350 both have two parts, one about the bech32/bech32m encoding scheme, and one about using it for encoding bitcoin addresses 10:59 < sipa> and some tests are generic, some are specific 11:02 < cguida> makes sense, thanks 11:18 -!- tkc_ [a29af3ea@162.154.243.234] has quit [Quit: Connection closed] 11:20 < nehan> I'm going to re-ask my question just in case people didn't see it (also please let me know if it doesn't make sense...) 11:20 < nehan> addresses are 10 characters longer now, meaning there's more chance for a user to make a mistake. did anyone think about how to balance the # of errors detected 11:20 < nehan> vs. likelihood of mistake? 11:20 < sipa> nehan: that's a good question 11:28 -!- jonatack [~jon@37.173.131.107] has joined #bitcoin-core-pr-reviews 11:34 -!- tlev6 [~tlev@li120-195.members.linode.com] has joined #bitcoin-core-pr-reviews 11:35 -!- pinheadmz_ [~pinheadmz@hns-contributor.dev] has joined #bitcoin-core-pr-reviews 11:37 -!- justinmoon_ [~quassel@157.245.122.126] has joined #bitcoin-core-pr-reviews 11:38 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 11:38 -!- dhruvm_ [~dhruv@165.227.49.220] has joined #bitcoin-core-pr-reviews 11:42 -!- thrasher`_ [~thrasher@173.209.42.7] has joined #bitcoin-core-pr-reviews 11:42 -!- Netsplit *.net <-> *.split quits: thrasher`, shesek, tinova, pinheadmz, justinmoon, dhruvm, harrigan-, tlev 11:42 -!- tlev6 is now known as tlev 11:43 -!- Netsplit over, joins: tinova 11:45 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 246 seconds] 11:47 -!- pinheadmz_ [~pinheadmz@hns-contributor.dev] has quit [Quit: ZNC 1.8.2+deb1+bionic2 - https://znc.in] 11:48 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews 11:49 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews 11:49 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 11:49 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 11:50 -!- Netsplit over, joins: pinheadmz 11:58 -!- ccdle12 [955adef3@243.222.90.149.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 12:01 -!- TheRec_ [~toto@drupal.org/user/146860/view] has quit [] 12:04 -!- ctrlbreak_MAD [~ctrlbreak@159.2.165.130] has joined #bitcoin-core-pr-reviews 12:07 -!- ctrlbreak [~ctrlbreak@159.2.165.130] has quit [Ping timeout: 260 seconds] 12:40 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-vulfyaligsvkvsgx] has quit [] 12:41 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-lbtetyyqbzzbklbc] has joined #bitcoin-core-pr-reviews 12:55 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 13:18 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 13:31 -!- jonatack_ [~jon@37.171.231.252] has joined #bitcoin-core-pr-reviews 13:34 -!- jonatack_ [~jon@37.171.231.252] has quit [Client Quit] 13:34 -!- jonatack_ [~jon@37.171.231.252] has joined #bitcoin-core-pr-reviews 13:35 -!- jonatack [~jon@37.173.131.107] has quit [Ping timeout: 264 seconds] 13:53 -!- jonatack_ [~jon@37.171.231.252] has quit [Quit: jonatack_] 13:54 -!- jonatack [~jon@37.171.231.252] has joined #bitcoin-core-pr-reviews 14:12 -!- scedastik [~scedastik@c-68-58-168-96.hsd1.mi.comcast.net] has quit [Quit: scedastik] 14:32 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 15:04 -!- Nebraskka [~Nebraskka@51.83.249.56] has quit [Remote host closed the connection] 15:04 -!- queip [~queip@unaffiliated/rezurus] has quit [Remote host closed the connection] 15:05 -!- Nebraskka [~Nebraskka@51.83.249.56] has joined #bitcoin-core-pr-reviews 15:05 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-pr-reviews 15:10 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-ulxywzaegjotuyuq] has quit [] 15:10 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-afzpjvgfuispbzys] has joined #bitcoin-core-pr-reviews 16:01 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews 16:01 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 16:01 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 16:50 -!- musdom [~Thunderbi@202.184.0.102] has joined #bitcoin-core-pr-reviews 17:04 -!- lightlike [~lightlike@p200300c7ef13e3001907dbbcf7a603f5.dip0.t-ipconnect.de] has quit [Quit: Leaving] 18:00 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-lbtetyyqbzzbklbc] has quit [Quit: Connection closed for inactivity] 18:01 -!- molz_ [mol@gateway/vpn/protonvpn/molly] has joined #bitcoin-core-pr-reviews 18:05 -!- mol_ [mol@gateway/vpn/protonvpn/molly] has quit [Ping timeout: 265 seconds] 18:20 -!- jonatack [~jon@37.171.231.252] has quit [Ping timeout: 265 seconds] 18:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds] 19:06 -!- musdom [~Thunderbi@202.184.0.102] has quit [Quit: musdom] 19:13 -!- tkc_ [a29af3ea@162.154.243.234] has joined #bitcoin-core-pr-reviews 19:18 -!- tkc_ [a29af3ea@162.154.243.234] has quit [Quit: Connection closed] 19:56 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 19:59 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds] 20:10 -!- awesome_doge [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has joined #bitcoin-core-pr-reviews 22:00 -!- jadi [~jadi@62.102.137.156] has joined #bitcoin-core-pr-reviews 22:10 -!- jadi [~jadi@62.102.137.156] has quit [Ping timeout: 246 seconds] 22:12 -!- jadi [~jadi@62.102.137.156] has joined #bitcoin-core-pr-reviews 22:34 -!- awesome_doge [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has quit [Quit: awesome_doge] 23:10 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 23:11 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 23:31 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-yxxvxjiwadouvumq] has joined #bitcoin-core-pr-reviews 23:51 -!- jadi [~jadi@62.102.137.156] has quit [] 23:58 -!- awesome_doge [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has joined #bitcoin-core-pr-reviews