--- Log opened Tue Feb 11 00:00:39 2020 00:03 -!- coucou_bot [~coucou_bo@94.239.63.9] has joined #bitcoin-core-dev 00:03 -!- coucou_bot [~coucou_bo@94.239.63.9] has left #bitcoin-core-dev [] 00:03 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection] 00:04 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 268 seconds] 00:07 < sipa> jaheller: ask on bitcoin.stackexchange.com 00:07 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev 00:10 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has quit [Remote host closed the connection] 00:10 -!- victorSN [~victorSN@unaffiliated/victorsn] has quit [Remote host closed the connection] 00:10 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has joined #bitcoin-core-dev 00:11 -!- victorSN [~victorSN@unaffiliated/victorsn] has joined #bitcoin-core-dev 00:16 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 00:17 -!- marcoagner [~user@bl11-16-246.dsl.telepac.pt] has joined #bitcoin-core-dev 00:18 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 00:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 00:21 < bitcoin-git> [bitcoin] hebasto opened pull request #18116: depends: Use clang for Ubuntu 16.04 (master...20200211-clang-ubuntu) https://github.com/bitcoin/bitcoin/pull/18116 00:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 00:24 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 272 seconds] 00:24 < jaheller> sipa Done, thanks. 00:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 00:32 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/35b7a8e539fa...98264e2ccb17 00:32 < bitcoin-git> bitcoin/master fa55a25 MarcoFalke: depends: Remove reference to win32 00:32 < bitcoin-git> bitcoin/master fae9084 MarcoFalke: build: Skip i686 build by default in guix and gitian 00:32 < bitcoin-git> bitcoin/master 98264e2 fanquake: Merge #18104: build: Skip i686 build by default in guix and gitian 00:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 00:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 00:33 < bitcoin-git> [bitcoin] fanquake merged pull request #18104: build: Skip i686 build by default in guix and gitian (master...2002-i686NoBuildByDefault) https://github.com/bitcoin/bitcoin/pull/18104 00:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 00:44 -!- jaheller [1fcc968a@31.204.150.138] has quit [Ping timeout: 260 seconds] 00:59 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:00 -!- ButterflyOfFire [~Butterfly@139.28.218.198] has quit [] 01:04 -!- jarthur [~jarthur@2605:6000:1019:4971:1535:b61e:34b3:3354] has joined #bitcoin-core-dev 01:05 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has quit [] 01:08 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has joined #bitcoin-core-dev 01:08 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has quit [Client Quit] 01:09 -!- jarthur [~jarthur@2605:6000:1019:4971:1535:b61e:34b3:3354] has quit [Ping timeout: 245 seconds] 01:18 -!- Kmos [~Kmos@139.28.218.198] has joined #bitcoin-core-dev 01:19 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 272 seconds] 01:25 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 01:38 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has joined #bitcoin-core-dev 01:38 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has quit [Client Quit] 01:38 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has joined #bitcoin-core-dev 01:38 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has quit [Client Quit] 01:39 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has joined #bitcoin-core-dev 01:39 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has quit [Client Quit] 01:40 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has joined #bitcoin-core-dev 01:40 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has quit [Client Quit] 01:41 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has joined #bitcoin-core-dev 01:41 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has quit [Client Quit] 01:41 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has joined #bitcoin-core-dev 01:41 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has quit [Client Quit] 01:41 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has joined #bitcoin-core-dev 01:42 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has quit [Client Quit] 01:42 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has joined #bitcoin-core-dev 01:47 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has quit [Ping timeout: 272 seconds] 01:52 -!- tecnecio_ [~tecnecio_@92.58.58.54] has joined #bitcoin-core-dev 01:53 -!- manantial [~tecnecio_@unaffiliated/manantial] has quit [Ping timeout: 272 seconds] 01:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:58 -!- Kmos [~Kmos@139.28.218.198] has quit [Ping timeout: 240 seconds] 02:06 < elichai2> j #regex 02:06 < elichai2> ops 02:08 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 02:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 02:22 < bitcoin-git> [bitcoin] hebasto opened pull request #18117: build: Fix Qt link issue for macOS target with DEBUG=1 (master...20200211-macos-debug) https://github.com/bitcoin/bitcoin/pull/18117 02:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 02:27 -!- jcoe [seru@gateway/vpn/protonvpn/joncoe] has joined #bitcoin-core-dev 02:31 -!- turbo_choo [~turbo_cho@124.128.246.58] has quit [Ping timeout: 268 seconds] 02:39 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 02:42 -!- jaqque1 [~jaqque@195.206.183.79] has joined #bitcoin-core-dev 02:45 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 02:45 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 02:46 -!- jaqque1 [~jaqque@195.206.183.79] has quit [Ping timeout: 240 seconds] 02:48 -!- anon_ribit [anon_ribit@gateway/vpn/mullvad/anonribit/x-62038582] has quit [Remote host closed the connection] 02:48 -!- anon_ribit [anon_ribit@gateway/vpn/mullvad/anonribit/x-62038582] has joined #bitcoin-core-dev 03:03 -!- Delbert71Koelpin [~Delbert71@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev 03:05 -!- jarthur [~jarthur@2605:6000:1019:4971:1535:b61e:34b3:3354] has joined #bitcoin-core-dev 03:07 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has joined #bitcoin-core-dev 03:10 -!- jarthur [~jarthur@2605:6000:1019:4971:1535:b61e:34b3:3354] has quit [Ping timeout: 260 seconds] 03:10 -!- mterwoord [~mterwoord@185.169.255.76] has joined #bitcoin-core-dev 03:12 -!- rex4539 [~rex4539@2a02:587:350c:a200:5d57:aa64:5677:918c] has quit [] 03:19 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 03:19 -!- rex4539 [~rex4539@2a02:587:350c:a200:b5a0:693d:72cd:3b5e] has joined #bitcoin-core-dev 03:23 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 265 seconds] 03:24 -!- turbo_choo [~turbo_cho@124.128.120.243] has joined #bitcoin-core-dev 03:54 -!- Delbert71Koelpin [~Delbert71@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 265 seconds] 04:00 -!- mterwoord [~mterwoord@185.169.255.76] has quit [] 04:05 -!- filchef [~filchef@212.104.97.177] has joined #bitcoin-core-dev 04:14 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Killed (Sigyn (Spam is off topic on freenode.))] 04:18 -!- guilhermeblanco [~guilherme@185.189.112.11] has joined #bitcoin-core-dev 04:30 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Read error: Connection reset by peer] 04:34 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev 05:06 -!- jarthur [~jarthur@2605:6000:1019:4971:1535:b61e:34b3:3354] has joined #bitcoin-core-dev 05:09 -!- Highway61 [~Thunderbi@104.223.94.154] has joined #bitcoin-core-dev 05:11 -!- jarthur [~jarthur@2605:6000:1019:4971:1535:b61e:34b3:3354] has quit [Ping timeout: 260 seconds] 05:19 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 240 seconds] 05:22 -!- abrissbi1ne is now known as abrissbirne 05:24 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 05:25 -!- rex4539 [~rex4539@2a02:587:350c:a200:b5a0:693d:72cd:3b5e] has quit [] 05:29 < wumpus> newer boost::test output is nicely colorful 05:29 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 05:29 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 05:49 -!- pabed____ [uid121039@gateway/web/irccloud.com/x-jnxdjewxuzuoumlg] has joined #bitcoin-core-dev 05:57 -!- mol [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer] 06:04 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection] 06:09 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 06:12 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev 06:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 06:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 06:40 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-dev 06:41 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-dev 06:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:56 -!- qwerty [31ce000b@49.206.0.11] has joined #bitcoin-core-dev 06:59 -!- qwerty [31ce000b@49.206.0.11] has quit [Remote host closed the connection] 07:00 -!- guilhermeblanco [~guilherme@185.189.112.11] has quit [] 07:07 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 07:07 -!- jarthur [~jarthur@2605:6000:1019:4971:1535:b61e:34b3:3354] has joined #bitcoin-core-dev 07:12 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 240 seconds] 07:12 -!- jarthur [~jarthur@2605:6000:1019:4971:1535:b61e:34b3:3354] has quit [Ping timeout: 240 seconds] 07:14 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 07:18 -!- SAnnaBot [~SAnnaBot@77.243.177.38] has joined #bitcoin-core-dev 07:21 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 07:25 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 240 seconds] --- Log closed Tue Feb 11 07:32:13 2020 --- Log opened Tue Feb 11 07:32:13 2020 07:32 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev 07:39 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 07:44 -!- turbo_choo [~turbo_cho@124.128.120.243] has quit [Ping timeout: 268 seconds] 07:48 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev 07:48 -!- goatpig [~goat@blocksettle-gw.cust.31173.se] has quit [Quit: Konversation terminated!] 07:49 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds] 07:57 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 07:58 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 08:04 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-dev 08:06 -!- cubancorona [~cubancoro@pool-72-77-31-161.pitbpa.ftas.verizon.net] has joined #bitcoin-core-dev 08:11 -!- jarthur [~jarthur@207.114.244.5] has quit [] 08:13 -!- goatpig [~goat@h-2-155.A498.priv.bahnhof.se] has joined #bitcoin-core-dev 08:16 -!- Highway61 [~Thunderbi@104.223.94.154] has quit [Quit: Highway61] 08:28 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 08:28 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev 08:29 -!- pabed____ [uid121039@gateway/web/irccloud.com/x-jnxdjewxuzuoumlg] has quit [Quit: Connection closed for inactivity] 08:36 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev 08:41 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 08:42 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 08:43 < jb55> sipa: do we know how slow passing around vector of vectors is in script eval? its the one thing I noticed when writing my own script interpreter, that can't be good for overall perf? or does it not matter much. 08:46 < sipa> jb55: where specifically? 08:46 < jb55> sipa: I'm working from memory, sec I'll look 08:48 < jb55> sipa: the stack, first argument to EvalScript 08:51 < sipa> that one is passed bt reference 08:51 < sipa> *by 08:52 < jb55> sipa: like, is vector moving contiguous chunks of memory on each operations, or just pointers to chunks? 08:52 < jb55> talking about the inner vector in stack 08:53 < sipa> that depends on the operation 08:53 < sipa> hard to say without a specific case to talk about 09:00 < jb55> I think I just misunderstood the memory layout... looks like its all points to dynamically allocated memory, so my concern wasn't really valid, modulo you could probably come up with something more cache friendly. 09:02 < sipa> oh, you definitely can 09:02 < sipa> but most stack affecting operations only happen once during script execution 09:03 < sipa> one crazy one is OP_ROLL that can cause a huge amount of memory operations 09:03 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Quit: Leaving] 09:04 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-dev 09:05 < jb55> but alas, consensus code. probably won't be able to make drastic changes to that just for a slight perf increase 09:14 < sipa> well, if it doesn't hurt it's also not worth optimizing :) 09:15 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 09:19 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 260 seconds] 09:32 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 09:40 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 265 seconds] 10:00 -!- SAnnaBot [~SAnnaBot@77.243.177.38] has quit [] 10:16 -!- Zao_ [~Zao_@84.39.116.180] has joined #bitcoin-core-dev 10:24 < jeremyrubin> you could imagine making everything COW non atomic shared pointers 10:25 < sipa> that wouldn't help with OP_ROLL actually 10:25 < jeremyrubin> hang on 10:28 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 10:29 < jeremyrubin> had a phone call come up was going to suggest not doing this 10:49 < jeremyrubin> anyways my point was going to be that it would help with things like OP_PICK but not OP_ROLL because any time you're moving something it has to move a lot of pointers on the stack. 10:51 < jeremyrubin> doing this plus a double linked list would be the space/time tradeoff you'd want to make 10:51 < jeremyrubin> (maybe single works too...) 10:52 < jeremyrubin> Then you could detach a node and rotate it without having to do O(n) moves 10:53 < jeremyrubin> But, then you would have to walk the entire list for a lot of operations which could be just as bad 10:53 < aj> i think a deque instead of a vector would fix ROLL for very large stacks on some implementations 10:53 < jeremyrubin> not quite 10:53 < jeremyrubin> deque remove is O(N) 10:54 < aj> http://www.cplusplus.com/reference/deque/deque/erase/ -- only linear in remaining elements on some implementations 10:55 < jeremyrubin> which is the same as std::vector no? 10:55 < aj> it's a vector of vectors instead sometimes apparently 10:56 < jeremyrubin> OP_DEPTH OP_ROLL gets you the last thing on the stack (or OP_DEPTH OP_1 OP_ROLL...) 10:56 < jeremyrubin> aj: I mean that remove from vector is also linear in remaining elements 10:56 < jeremyrubin> but you can use some efficient backshifting thing IIRC 10:57 < jeremyrubin> The benefit of the deque is just at best a 1/2 improvement 10:57 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.7] 10:58 < aj> http://www.cplusplus.com/reference/vector/vector/erase/ -- vector is always linear in subsequent elements, deque can be more efficient 10:58 < jeremyrubin> It's at most 1/2 10:58 < jeremyrubin> err I guess you're saying if it is a vector> then you can be better... 10:58 < jeremyrubin> I see 10:59 < jeremyrubin> depending on the bucket size 10:59 < aj> bucket size is a constant factor, so you ignore that with O notation 10:59 < aj> but probably means it's worse for every real script 10:59 < jeremyrubin> well ~kinda. If the bucket size is > max stack... 11:00 < jeremyrubin> Then for big O we can ignore, but for our intepreter we're already at the maximally bad thing 11:00 < jeremyrubin> Buckets are what? 128? 11:00 < jeremyrubin> (in normal implementations) 11:01 < jeremyrubin> it seems implementations vary widely 11:02 < jeremyrubin> something like 200 stack elements 11:02 < jeremyrubin> MAX_STACK_SIZE = 1000 11:08 < jeremyrubin> (I think it'd be better to stick with something that has more regular implementations so that there isn't divergent performance characteristics) 11:11 < sipa> as long as the max stack size isn't increased there is no reason to worry about any of this 11:18 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev 11:18 < sdaftuar> jeremyrubin: around? 11:18 < jeremyrubin> ya 11:19 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev 11:19 < jeremyrubin> So I thought of a hybrid approach you might like 11:19 < sdaftuar> i thought it might be easier to talk about your very detailed comment here rather than go back and forth on your PR 11:19 < sdaftuar> first observation: you make a good point about memory blowup 11:19 < jeremyrubin> Keep the cache, but only store it if it is larger than 32 elements or something 11:20 * jeremyrubin listening mode 11:20 < sdaftuar> i have not quite worked through your picture examples involving N/2 parents and N/2 children yet, but i had a question for you about your linear example- 11:21 < jeremyrubin> ask away! 11:21 < sdaftuar> in the linear case, aren't we doing N^2 lookups into GetMempoolChildren, versus something much smaller if we use a cache? 11:21 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 11:21 < sdaftuar> I think N 11:21 < jeremyrubin> Good question. 11:22 < jeremyrubin> At node M (M < N), we look at the cache below us and do (N-M) lookups 11:22 < sdaftuar> it's just one lookup? 11:22 < sdaftuar> the cache is built from bottom to top 11:22 < jeremyrubin> but what's the length of the cache! 11:23 < jeremyrubin> We need to iterate over that cache to "read it" 11:23 < jeremyrubin> So maybe I'm confusing you when I say lookup 11:23 -!- cubancorona [~cubancoro@pool-72-77-31-161.pitbpa.ftas.verizon.net] has quit [Quit: Leaving] 11:23 < sdaftuar> well, it's one map lookup, and then we read N-M elements i guess 11:23 < jeremyrubin> Yes 11:23 < jeremyrubin> That's the point I'm making 11:24 < jeremyrubin> Reading those N - M elements also requires visiting them for de-duplication 11:24 < jeremyrubin> Pre epochs, this was... really bad 11:24 < jeremyrubin> (well in the linear case not so bad, but in general n log n to merge into our set) 11:24 < sdaftuar> oh right 11:24 < jeremyrubin> Post epochs, you just iterate and visit 11:25 < sdaftuar> yeah so if your point is we're already doing N^2 work in this pathological case, that doing a little more N^2 work isn't asymptotically worse 11:25 < sdaftuar> then maybe that's a good point 11:25 < jeremyrubin> We could maybe make an optimization where if you only have one child we do something smart 11:25 < jeremyrubin> sdaftuar: yeah that's my point 11:25 < sdaftuar> i wonder if we should be doing something else altogether in these pathological cases 11:25 < jeremyrubin> evict everything and reinsert isn't too bad 11:25 < sdaftuar> hmm, ok i will give this more thought, thanks for the clarification 11:26 < jeremyrubin> I think the case I'm concerned about most is a -> b -> c....-> {big tree of things} 11:27 < jeremyrubin> because if the first part is N/2 and the big tree of things is (N/2)^2, it can get kind of annoying 11:27 < jeremyrubin> and then you really do want a cache 11:27 < sdaftuar> you're saying there's a sweet spot where the memory tradeoff is worth the cpu benefit? 11:27 < jeremyrubin> which might be why only caching when you have more than X things not in the cache could be nice 11:28 < jeremyrubin> Yeah. essentially any time you are running and you trigger some traversal limit excluding things in the cache, you make a new cache entry 11:28 < jeremyrubin> right now we work this way, but the limit is 1 11:29 < jeremyrubin> you could imagine preferring to traverse until our traversal is having a poor hit rate and is big. E.g., we traversed 10000 things, but we only saw 100 things uniquely, so we should create a cache line for this sub-unit 11:30 < sdaftuar> if i understand you correctly -- something like this is just a constant factor benefit at best, fundamentally we're pretty screwed by pathological chains in reorged blocks, right? 11:30 < jeremyrubin> Yeah 11:30 < jeremyrubin> But we can maybe make the constants large enough so that the pathological case is bounded 11:30 < sdaftuar> so that is disappointing :) i mean, i feel like we need to do something just much smarter 11:30 < jeremyrubin> maybe goes from N^3 to N^2 11:30 < sdaftuar> N here is the number of transactions in a block though 11:30 < jeremyrubin> But overall my opinion is I expect the map lookups and insertions (using ordered or not) to dominate just not using a map 11:30 < sdaftuar> which is way too big for even N^2 i think 11:31 < jeremyrubin> Well so that's what I did the math on, or tried to 11:31 < jeremyrubin> smallest txn is 61 bytes 11:32 < sdaftuar> yeah well the memory blowup there is certainly bad, but the cpu blowup is something that is more fundamentally broken i think? 11:32 < sdaftuar> i mean, we can take your advice and get rid of the cache to avoid OOM 11:32 < jeremyrubin> also fundamentally a memory blowup implies a CPU blowup 11:32 < sdaftuar> but we need to rearchitect what happens on a reorg to get rid of the CPU DoS 11:32 < jeremyrubin> because you need to touch the memory anywasy 11:32 < sdaftuar> sure 11:32 < jeremyrubin> it only matters if the memory blowup is less than the CPU blowup 11:33 < jeremyrubin> But I agree 11:33 < jeremyrubin> We're talking about something very slow to deal with 11:35 < jeremyrubin> how long do we think traversal takes? 11:35 < jeremyrubin> Because another option is to parallelize it 11:36 < sdaftuar> i think maybe the best option is to evict things that have too many descendants? or come up with some lazily updating data structures 11:37 < sdaftuar> not sure exactly how to do either of those ideas 11:37 < jeremyrubin> Or maybe we run a thread which times out the reorg 11:37 < jeremyrubin> and evicts everything if it took too long to update 11:37 < jeremyrubin> E.g., optimistically this should be simple. But if it takes too long, do the dumb thing 11:38 < sdaftuar> the fundamental problem is that we need to get the mempool back in a consistent state, ideally with some useful fee-paying transactions, so that we can produce a new block template as quickly as possible 11:39 < jeremyrubin> Maybe we should spend the effort to time some "worst case" blocks? 11:39 < sdaftuar> so evicting everything is nice for consistency, but not really the right thing in the long run 11:39 < sdaftuar> yeah i will try to do that. after giving this more thought and reading your writeup, i'm not optimistic about the results 11:39 < jeremyrubin> sdaftuar: hence do the right thing optimistically (e.g., 10 seconds? 100 seconds?) and otherwise evict 50% and repeat? 11:39 < sdaftuar> but maybe you're right that we're within a constant factor of workable 11:40 < sdaftuar> small constant factor* 11:40 < jeremyrubin> (100 seconds/((1e6/61)**2)) == 370 ns 11:41 < jeremyrubin> but it's actual n-1*n/2 so 11:41 < jeremyrubin> 750 ns 11:42 < jeremyrubin> We can parallelize traversals (let's assume this helps us by at most a factor of 2 because of concurrency overhead) 11:43 < sdaftuar> if you want to be a bit more depressed, we're not bounded by the size of a block here 11:43 < jeremyrubin> Ah is it mempool bounded? 11:43 < jeremyrubin> I thought we were block bounded 11:43 < jeremyrubin> I guess we're updating descendents in mempool? 11:43 < sdaftuar> in a multi-block reorg, i think we will process a big batch of transactions in this way 11:43 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 11:43 < sdaftuar> and yes we can have an unbounded number of descendants in mempool 11:44 < jeremyrubin> Well in multi-block reorg we should definitely go block by block not all at once 11:44 < jeremyrubin> But in multi-block I guess we can then get unbounded? 11:44 < jeremyrubin> I thought we have a 25 limit presently? 11:44 < sdaftuar> the 25 limit does not apply in the case of a reorg 11:44 < jeremyrubin> Ah 11:44 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 11:44 < jeremyrubin> So in multi block it might not be that bad to at a certain point evict everything and resubmit to mempool 11:44 < sdaftuar> the issue is that our main code path for accepting a new transaction to the mempool implicitly assumes no in-mempool descendants 11:45 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev 11:45 < sdaftuar> jeremyrubin: i think conceptually that is corret 11:45 < jeremyrubin> because then we're at least guaranteed to not have too much N^2 stuff 11:45 < jeremyrubin> But it still is sucky 11:46 < sdaftuar> architecting it might be a bit messy, but maybe the right intuition is to build the mempool from scratch by reinserting things from disconnected blocks in-order for just as long as you need to produce a reasonable new fee-paying block 11:46 < sdaftuar> and then let the mining code run, and go back to inserting more stuff, etc 11:47 -!- Highway61 [~Thunderbi@104.223.94.154] has joined #bitcoin-core-dev 11:47 < sdaftuar> i think we should have some alternative to the whole thing hanging if we get some messy blocks reorged out, anyway 11:48 < jeremyrubin> I guess as a sidebar, if we know that reorging is already *yikes* I see a few paths forward for this PR: 1) drop entirely because review not worth if we're going to need to re-do it all 2) Accept, if we can show that it's better/not worse 3) Accept half and keep cache so we at least preserve the same failure modes 4) Accept both, knowing we have new/different failure modes 5) time out after 100 seconds, switch algorithms, try 11:48 < jeremyrubin> again for unbounded with caching? 11:48 < jeremyrubin> the switching between algorithms with some exponential backing on time isn't actually that dumb. 11:49 < sdaftuar> i think either 2/4 or 3 are the most likely outcomes IMO? but i want to do some more benchmarking to get a sense of how bad things acn be 11:49 < aj> a 100 second "stall" sounds horrible? 11:49 < jeremyrubin> Because you would need to have an attack against both the memory version and the time version which maybe we can prove is impossible 11:49 < jeremyrubin> aj: scylla charbidis 11:50 < jeremyrubin> This isn't a problem that we're introducing, the existing algorithms can already be wicked slow 11:50 < jeremyrubin> the 100 second switch is *in the hopes* that a different algorithm could be faster for this reorg 11:50 < jeremyrubin> We could measure historical reorg times (e.g., if it's 10s per block, do 20, and then switch back and forth doubling) 11:51 < jeremyrubin> The idea is just to time a give up point and switch to a different algorithm (for the rest of the block that is, we're still making monotonic progress) 11:53 < aj> if we've got a different algorithm that goes faster, seems better to do that from the start i guess 11:53 < jeremyrubin> aj we don't 11:53 < jeremyrubin> you can review the problem here 11:53 < jeremyrubin> #18063 11:53 < gribble> https://github.com/bitcoin/bitcoin/issues/18063 | Improve UpdateForDescendants by using Epochs and Removing CacheMap by JeremyRubin . Pull Request #18063 . bitcoin/bitcoin . GitHub 11:54 < jeremyrubin> The algorithms we have with or without caching have different worst cases 11:54 < jeremyrubin> And caching opens up to memory based attackers 11:54 < jeremyrubin> so short of no new magic bullet, getting rid of caching reduces attack surface to just time based DoS 11:54 < aj> all we really need is to from {reorged blocks} + {old mempool} to 4 to 8 megaweight of highish-value txs in a new mempool as quickly as possible 11:54 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 240 seconds] 11:54 < sdaftuar> aj: agreed 11:55 < jeremyrubin> we could filter the to_reorg set by feerate 11:56 < jeremyrubin> with a max 8 megaweight ordered map, dropping anything else 11:57 < jeremyrubin> Then, we could process the updates for just that max feerate list 11:58 < jeremyrubin> But then the descendants could still be unbounded. 11:59 -!- jarthur_ [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 12:00 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection] 12:00 < jeremyrubin> didn't even say bye :'( 12:00 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev 12:00 < jeremyrubin> ragequit 12:00 < aj> ragerejoin 12:00 < sdaftuar> maybe i quit in disgust at this problem 12:01 < sdaftuar> (or maybe my internet is flaky) 12:01 < jeremyrubin> hah 12:02 < jeremyrubin> Anyways... maybe I should abandon #18603 for the "fast track" and open up some more obvious mempool wins (like eliminating mapLinks)? 12:02 < gribble> https://github.com/bitcoin/bitcoin/issues/18603 | HTTP Error 404: Not Found 12:02 < jeremyrubin> #18063 12:02 < gribble> https://github.com/bitcoin/bitcoin/issues/18063 | Improve UpdateForDescendants by using Epochs and Removing CacheMap by JeremyRubin . Pull Request #18063 . bitcoin/bitcoin . GitHub 12:02 < jeremyrubin> It seems like it's going to take some time to ensure we're doing the right thing. 12:03 < aj> yay for easy wins? 12:03 < sdaftuar> hmm, i think if we're not getting rid of cachemap, it should be the case that your patch is strictly better. i think i need to do a little more work to determine whether removing the cache is strictly better, probably better overall but maybe not strictly better, or somehow worse 12:03 -!- jarthur [~jarthur@207.114.244.5] has quit [Ping timeout: 265 seconds] 12:03 < sdaftuar> but eg the first commit seems like a no-brainer? 12:04 < jeremyrubin> ok why don't I open up a new PR with just the no-brainer one? 12:04 < jeremyrubin> We can keep the broader discussion going on 18063 12:04 < sdaftuar> sure, that's fine with me 12:04 < jeremyrubin> And then we can keep progress up on fixing all the other hot mess in the mempool ;) 12:05 < aj> sdaftuar: did you get a chance to look at https://github.com/ajtowns/bitcoin/commit/43528b17e88ec5b8378c923106053561c909a7e5 ? 12:05 < aj> sdaftuar: does an O( peers * log(txs_announced) ) lookup to retry NOTFOUNDs 12:05 < sdaftuar> oh, i did look at it briefly -- my immediate reaction was a small amount of concern at iterating over all peers whenever there's a NOTFOUND 12:07 < sdaftuar> because we coudl get up to 100 at once, i think, in one message -- so that's like 10k map lookups? 12:07 < sdaftuar> if we spaced out processing though then i think that would be fine, or maybe it's fast enough as-is and i just need to benchmark it to convince myself 12:09 < aj> hmm, 100 is also the max in flight from a peer 12:09 < sdaftuar> right, that's why i figure we could get 100 at once 12:10 < sdaftuar> (we coudl get more from a malicious peer, but we filter out things that weren't in-flight, so 100 should be the right max) 12:10 < aj> txs_announced maxes out at 100k 12:10 < sdaftuar> oh, right 12:10 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 12:10 < bitcoin-git> [bitcoin] JeremyRubin opened pull request #18120: Change UpdateForDescendants to use Epochs (master...epoch-mempool-clean-split-updatefordescendants-pt1) https://github.com/bitcoin/bitcoin/pull/18120 12:10 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 12:11 < jeremyrubin> ok feel free to review just that chunk (same as the commit from the other branch) 12:11 < sdaftuar> jeremyrubin: will do 12:11 < aj> jeremyrubin: ack 12:12 < aj> hmm, maybe that's ambiguous :) 12:12 < sdaftuar> ready for merge! 12:12 < jeremyrubin> lgtm 12:12 < jeremyrubin> sdaftuar: good catch with the grandchild it thing btw earlier 12:12 < jeremyrubin> We should probably have a test for that... 12:13 < sdaftuar> agreed, that code is definitely undertested 12:14 < sdaftuar> oh! i misremembered how chain limits get applied in the case of a reorg 12:15 < sdaftuar> so there are an unbounded number of in-mempool descendants, but there is a bound on chain limits with respect to what is in the block(s) 12:15 < jeremyrubin> I was just thinking more about that 12:15 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 260 seconds] 12:15 < sdaftuar> so the worst-case scenarios we were talking about are not quite right 12:15 < jeremyrubin> The issue with the unbounded in-mempool descendants is also that the cache entries can get HUGE 12:15 < jeremyrubin> e.g., the entire mempool 12:15 < sdaftuar> yes 12:16 < jeremyrubin> so we should definitely get rid of the cache IMO, even if our runtime goes up 12:16 < jeremyrubin> because the entire mempool * N is bad 12:17 < jeremyrubin> like maybe even brick the network today with a few blocks bad 12:17 < sdaftuar> well, one alternative is to memory cap it instead? 12:17 < jeremyrubin> Or LRU cache 12:17 < sdaftuar> right 12:18 < jeremyrubin> IIRC the philosophy that BCash deals with this is not... awful? 12:18 < jeremyrubin> step 1: clone the mempool 12:18 < jeremyrubin> step 2: fork the reorging 12:18 < sdaftuar> it's starting to make more sense to me though that if what is in the mempool is bounded in some reasonable-ish way, and what gets added back from blocks is bounded in some way, that we could get comfortable with some kind of CPU bound on the combination and be comfortable dropping the cache 12:19 < jeremyrubin> step3: continue mining on the non-reorg chain 12:19 < jeremyrubin> step4; if reorg finishes, switch 12:20 < jeremyrubin> if the reorg never finishes then it was done by a malicious miner, so it's not economically good anyways maybe 12:20 < sdaftuar> not sure that really makes sense, as until we return a new block template, mining on the old chain is almost certainly what the default behavior of miners would be regardless 12:20 < sdaftuar> so i think our job is to make it so that we can produce a valid new block on the new chain as fast as possible 12:20 < jeremyrubin> Fair point 12:21 < jeremyrubin> I wonder if a randomized algorithm can also help here 12:21 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 12:22 < jeremyrubin> The attacker is exploiting some specific structures 12:22 < jeremyrubin> I wonder if there's an algorithm with a random order that can prevent them from exposing some of the worst case stuff 12:22 < jeremyrubin> but being on average much slower maybe 12:23 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:25 -!- jarthur_ [~jarthur@207.114.244.5] has quit [Read error: Connection reset by peer] 12:26 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 12:38 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection] 12:44 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 12:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 12:44 < bitcoin-git> [bitcoin] hebasto opened pull request #18121: gui: Throttle GUI update pace when -reindex (master...20200211-reindex-gui) https://github.com/bitcoin/bitcoin/pull/18121 12:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:00 -!- Zao_ [~Zao_@84.39.116.180] has quit [] 13:00 -!- goatpig [~goat@h-2-155.A498.priv.bahnhof.se] has quit [Quit: Konversation terminated!] 13:03 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 13:10 -!- Highway61 [~Thunderbi@104.223.94.154] has quit [Ping timeout: 272 seconds] 13:12 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 260 seconds] 13:13 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 13:15 -!- bsm1175321 [~mcelrath@2601:196:4902:25b0:f14a:e421:2d96:e145] has joined #bitcoin-core-dev 13:15 -!- bsm1175321 [~mcelrath@2601:196:4902:25b0:f14a:e421:2d96:e145] has quit [Read error: Connection reset by peer] 13:18 -!- Khaytsus1 [~Khaytsus@77.243.177.38] has joined #bitcoin-core-dev 13:18 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 13:27 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 13:27 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-dev 13:32 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 240 seconds] 13:43 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-dev 13:51 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection] 13:51 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev 13:58 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 14:09 -!- tecnecio_ [~tecnecio_@92.58.58.54] has quit [Ping timeout: 268 seconds] 14:11 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 272 seconds] 14:15 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 14:19 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev 14:20 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 265 seconds] 14:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 14:20 < bitcoin-git> [bitcoin] theStack opened pull request #18122: rpc: update validateaddress RPCExamples to bech32 (master...20200211-rpc-update-validateaddress-rpcexamples-to-bech32) https://github.com/bitcoin/bitcoin/pull/18122 14:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 14:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 14:28 < bitcoin-git> [bitcoin] ryanofsky opened pull request #18123: gui: Fix race in WalletModel::pollBalanceChanged (master...pr/pollbug) https://github.com/bitcoin/bitcoin/pull/18123 14:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 14:31 -!- filchef [~filchef@212.104.97.177] has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/] 14:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 14:33 < bitcoin-git> [bitcoin] practicalswift opened pull request #18124: init: Clarify C and C++ locale assumptions. Add locale sanity check to verify assumptions at run-time. (master...LocaleSanityCheck) https://github.com/bitcoin/bitcoin/pull/18124 14:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 14:33 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 14:33 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev 14:36 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev 15:00 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 15:03 -!- Highway61 [~Thunderbi@104.223.94.154] has joined #bitcoin-core-dev 15:07 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 15:07 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 15:09 -!- jcoe [seru@gateway/vpn/protonvpn/joncoe] has quit [Ping timeout: 272 seconds] 15:10 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 15:15 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 15:18 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 15:43 -!- hirish_ [~hirish@137.74.20.85] has quit [Quit: ZNC - https://znc.in] 15:56 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 265 seconds] 16:00 -!- Khaytsus1 [~Khaytsus@77.243.177.38] has quit [] 16:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 16:10 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 16:10 -!- anon_ribit [anon_ribit@gateway/vpn/mullvad/anonribit/x-62038582] has quit [Ping timeout: 265 seconds] 16:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:14 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:17 -!- Barras2 [~Barras2@185.189.112.19] has joined #bitcoin-core-dev 16:18 < yevaud> jeremyrubin: the absolute worst case is probably one where an attacking miner attempts to balance two competing forks. it is free for them to swap work between two nodes on competing forks, but incredibly expensive to re-wind and sync forward repeatedly. 16:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 16:25 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 265 seconds] 16:25 -!- marcoagner [~user@bl11-16-246.dsl.telepac.pt] has quit [Ping timeout: 265 seconds] 16:35 -!- hirish [~hirish@ip85.ip-137-74-20.eu] has joined #bitcoin-core-dev 16:38 -!- jarthur_ [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 16:41 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 16:42 -!- jarthur [~jarthur@207.114.244.5] has quit [Ping timeout: 260 seconds] 16:43 -!- jarthur_ [~jarthur@207.114.244.5] has quit [Ping timeout: 272 seconds] 16:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 16:50 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/98264e2ccb17...73a396e0280a 16:50 < bitcoin-git> bitcoin/master cb9e88e fanquake: build: don't embed a build-id when building libdmg-hfsplus 16:50 < bitcoin-git> bitcoin/master 73a396e fanquake: Merge #18004: build: don't embed a build-id when building libdmg-hfsplus 16:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 16:53 < aj> jeremyrubin: i don't get why you're switching from setEntries to vecEntries in #18120 16:53 < gribble> https://github.com/bitcoin/bitcoin/issues/18120 | Change UpdateForDescendants to use Epochs by JeremyRubin . Pull Request #18120 . bitcoin/bitcoin . GitHub 16:54 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:11 < yevaud> jeremyrubin: though this is a lot less likely with per-output UTXOs, it's harder to craft a situation where you have two competing forks with completely dissimilar, distinct transactions. 17:29 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-dev 17:35 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 272 seconds] 17:52 -!- highlow [bd0623c3@189.6.35.195] has joined #bitcoin-core-dev 17:56 -!- turbo_choo [~turbo_cho@124.128.120.243] has joined #bitcoin-core-dev 18:01 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.7] 18:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 18:02 < bitcoin-git> [bitcoin] fanquake opened pull request #18125: doc: remove PPA note from release-process.md (master...dont_bug_the_bluematt) https://github.com/bitcoin/bitcoin/pull/18125 18:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 18:14 -!- kljasdfvv [~flack@p200300D46F0FB30000B503BBB8C9A5A5.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds] 18:15 -!- jarthur [~jarthur@2605:6000:1019:4971:94ff:30c7:8c0:b90c] has joined #bitcoin-core-dev 18:16 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 18:18 -!- jarthur [~jarthur@2605:6000:1019:4971:94ff:30c7:8c0:b90c] has quit [Remote host closed the connection] 18:18 -!- jarthur [~jarthur@2605:6000:1019:4971:94ff:30c7:8c0:b90c] has joined #bitcoin-core-dev 18:21 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 272 seconds] 18:29 < jeremyrubin> aj: why not? 18:30 < aj> jeremyrubin: because you do .find() on it which is linear for a vec but log for a set? 18:30 < jeremyrubin> yevaud: I don't think what you're saying has anything to do with what we're talking about? 18:30 < jeremyrubin> Where do I do find on it? 18:30 < jeremyrubin> ah I see 18:31 < aj> cacheMap::iterator cached_great_grand_children = cache.find(grand_child_it); 18:31 < jeremyrubin> cacheMap is a std::set 18:31 < jeremyrubin> std::set> 18:31 < jeremyrubin> so we are finding the cache line 18:31 < jeremyrubin> and then we add the entire cache line 18:32 < aj> oh, i missed a level >:( 18:33 -!- jarthur [~jarthur@2605:6000:1019:4971:94ff:30c7:8c0:b90c] has quit [Remote host closed the connection] 18:34 < jeremyrubin> get on my level! 18:35 -!- Highway61 [~Thunderbi@104.223.94.154] has quit [Quit: Highway61] 18:35 -!- jarthur [~jarthur@2605:6000:1019:4971:94ff:30c7:8c0:b90c] has joined #bitcoin-core-dev 18:46 -!- jarthur [~jarthur@2605:6000:1019:4971:94ff:30c7:8c0:b90c] has quit [Remote host closed the connection] 18:46 -!- jarthur [~jarthur@2605:6000:1019:4971:94ff:30c7:8c0:b90c] has joined #bitcoin-core-dev 18:55 -!- felixfoertsch [~felixfoer@2001:16b8:5071:2700:f90f:a6d9:ef60:b428] has quit [Ping timeout: 246 seconds] 18:59 -!- Highway61 [~Thunderbi@ip184-186-2-14.no.no.cox.net] has joined #bitcoin-core-dev 19:00 -!- Barras2 [~Barras2@185.189.112.19] has quit [] 19:01 -!- abrissbi1ne [~abrissbir@unaffiliated/abrissbirne] has joined #bitcoin-core-dev 19:04 -!- abrissbirne [~abrissbir@unaffiliated/abrissbirne] has quit [Ping timeout: 256 seconds] 19:18 -!- wolfy13391 [~wolfy1339@141.98.101.133] has joined #bitcoin-core-dev 19:28 -!- turbo_choo [~turbo_cho@124.128.120.243] has quit [Ping timeout: 240 seconds] 19:33 -!- jarthur [~jarthur@2605:6000:1019:4971:94ff:30c7:8c0:b90c] has quit [Remote host closed the connection] 19:34 -!- turbo_choo [~turbo_cho@124.128.120.243] has joined #bitcoin-core-dev 19:34 -!- jarthur [~jarthur@cpe-66-68-134-212.austin.res.rr.com] has joined #bitcoin-core-dev 19:46 -!- highlow [bd0623c3@189.6.35.195] has quit [Remote host closed the connection] 19:53 -!- turbo_choo [~turbo_cho@124.128.120.243] has quit [Ping timeout: 265 seconds] 19:55 -!- turbo_choo [~turbo_cho@124.128.120.243] has joined #bitcoin-core-dev 20:23 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 20:26 -!- Highway61 [~Thunderbi@ip184-186-2-14.no.no.cox.net] has quit [Ping timeout: 240 seconds] 20:41 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 272 seconds] 20:56 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 20:59 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 272 seconds] 21:00 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 21:10 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev 21:33 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds] 21:41 -!- gkrizek [~gkrizek@ec2-54-149-179-115.us-west-2.compute.amazonaws.com] has quit [Remote host closed the connection] 21:43 -!- gkrizek [~gkrizek@ec2-54-149-179-115.us-west-2.compute.amazonaws.com] has joined #bitcoin-core-dev 22:00 -!- wolfy13391 [~wolfy1339@141.98.101.133] has quit [] 22:03 -!- jarthur [~jarthur@cpe-66-68-134-212.austin.res.rr.com] has quit [] 22:17 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 22:30 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 22:34 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 22:42 -!- wjp [~wjp@77.243.177.38] has joined #bitcoin-core-dev 22:59 -!- Highway61 [~Thunderbi@ip184-186-2-14.no.no.cox.net] has joined #bitcoin-core-dev 23:12 < fanquake> I was hoping we might be able to take advantage of Microsoft's "new" version checking APIs, for enabling various process mitigations / security features. 23:12 < fanquake> However, it turns out they've written functions, such as IsWindows10OrGreater(), that will return false, even if the OS is Windows 10..., unless you bundle an additional XML file with your executable. 23:26 -!- tecnecio_ [~tecnecio_@92.58.58.54] has joined #bitcoin-core-dev 23:26 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 260 seconds] 23:30 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 268 seconds] 23:30 -!- abrissbi1ne is now known as abrissbirne 23:38 -!- goatpig [~goat@blocksettle-gw.cust.31173.se] has joined #bitcoin-core-dev 23:39 -!- kljasdfvv [~flack@p200300D46F149D0000E86D569814A5D1.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 23:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 23:45 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev 23:52 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-dev --- Log closed Wed Feb 12 00:00:37 2020