--- Log opened Mon Mar 23 00:00:30 2020
00:01 -!- tsujp [~tsujp@pa49-196-165-9.pa.vic.optusnet.com.au] has joined #bitcoin-core-dev
00:02 -!- Highway61 [~Thunderbi@104.223.94.138] has quit [Ping timeout: 256 seconds]
00:06 -!- BamBaRay36 [~2BamBaRay@213.232.87.72] has joined #bitcoin-core-dev
00:19 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
00:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:34 < bitcoin-git> [bitcoin] hebasto closed pull request #18387: gui: Fix segfault for loading and immediately unloading wallet (master...20200319-fix-modelwallet-segfault) https://github.com/bitcoin/bitcoin/pull/18387
00:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:41 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
00:44 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
00:44 -!- vasild_ is now known as vasild
01:06 -!- manantial [~tecnecio_@unaffiliated/manantial] has joined #bitcoin-core-dev
01:11 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
01:13 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
01:13 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds]
01:16 -!- sipsorcery [~sipsorcer@37.228.254.212] has joined #bitcoin-core-dev
01:17 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 240 seconds]
01:29 < vasild> kallewoof: wrt #17994 - I assumed that we should first flush the block file to a persistent storage and afterwards flush the undo file (finalization not being relevant for this). Because in the case of a crash/power outage in between flushing both we could end up with a block on disk without undo, or with undo on disk without a block.
01:29 < gribble> https://github.com/bitcoin/bitcoin/issues/17994 | validation: flush undo files after last block write by kallewoof · Pull Request #17994 · bitcoin/bitcoin · GitHub
01:30 < vasild> and I assume we dont want the latter 
01:31 < vasild> but now I can't find anything in the code that would brick if we have undo without a block
01:56 -!- kljasdfvv [~flack@p200300D46F149D00D115F4472F4AA66F.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
02:00 -!- gnomus [~gnomus@77.243.177.38] has quit []
02:09 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:11 < vasild> https://github.com/bitcoin/bitcoin/blob/312d27b/src/validation.cpp#L4810 -- this code would get upset if it finds an undo without a block, hmm
02:13 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-161-135.adslplus.ch] has joined #bitcoin-core-dev
02:21 -!- yhsiang [~yhsiang@192.145.126.115] has joined #bitcoin-core-dev
02:22 -!- tsujp [~tsujp@pa49-196-165-9.pa.vic.optusnet.com.au] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
02:23 -!- marcoagner [~user@bl13-226-166.dsl.telepac.pt] has joined #bitcoin-core-dev
02:23 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
02:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:40 -!- Kiminuo [~mix@141.98.103.134] has quit [Ping timeout: 240 seconds]
02:42 -!- tsujp [~tsujp@pa49-196-165-9.pa.vic.optusnet.com.au] has joined #bitcoin-core-dev
02:43 -!- tsujp [~tsujp@pa49-196-165-9.pa.vic.optusnet.com.au] has quit [Client Quit]
02:47 -!- Kiminuo [~mix@141.98.103.108] has joined #bitcoin-core-dev
03:08 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
03:23 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-161-135.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
03:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:26 < bitcoin-git> [bitcoin] vova557 opened pull request #18408: Bitcoin (master...master) https://github.com/bitcoin/bitcoin/pull/18408
03:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:28 < bitcoin-git> [bitcoin] fanquake closed pull request #18408: Bitcoin (master...master) https://github.com/bitcoin/bitcoin/pull/18408
03:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:37 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-dev
03:52 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
03:53 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
04:03 -!- Jalen30Runte [~Jalen30Ru@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev
04:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
04:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:36 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 260 seconds]
04:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:39 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/57a8fa9c3b44...d478a737dbdd
04:39 < bitcoin-git> bitcoin/master fa01feb MarcoFalke: test: Remove ci timeout restriction in test_runner
04:39 < bitcoin-git> bitcoin/master fa92af5 MarcoFalke: ci: Run feature_block and feature_abortnode in valgrind
04:39 < bitcoin-git> bitcoin/master d478a73 MarcoFalke: Merge #18392: ci: Run feature_block in valgrind
04:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:39 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #18392: ci: Run feature_block in valgrind (master...2003-ciMoreVal) https://github.com/bitcoin/bitcoin/pull/18392
04:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:41 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d478a737dbdd...97b0687501ce
04:41 < bitcoin-git> bitcoin/master 7c1ac70 practicalswift: tests: Don't assume presence of __builtin_mul_overflow in MultiplicationOv...
04:41 < bitcoin-git> bitcoin/master 97b0687 MarcoFalke: Merge #18393: tests: Don't assume presence of __builtin_mul_overflow(…) in...
04:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:41 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #18393: tests: Don't assume presence of __builtin_mul_overflow(…) in MultiplicationOverflow(…) fuzzing harness (master...multiplication-overflow-fixup) https://github.com/bitcoin/bitcoin/pull/18393
04:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:47 -!- Highway61 [~Thunderbi@104.223.94.138] has joined #bitcoin-core-dev
04:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:53 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #18380: doc: Remove html comment in PULL_REQUEST_TEMPLATE (master...2003-docGitHubTemplateNoComment) https://github.com/bitcoin/bitcoin/pull/18380
04:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:00 -!- yhsiang [~yhsiang@192.145.126.115] has quit []
05:21 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 240 seconds]
05:21 -!- castironpi [~castironp@84.39.117.57] has joined #bitcoin-core-dev
05:39 -!- Jalen30Runte [~Jalen30Ru@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds]
05:41 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Quit: Leaving]
05:47 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-dev
05:47 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
05:51 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 240 seconds]
05:51 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Client Quit]
05:52 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-dev
05:55 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Client Quit]
05:55 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-dev
05:57 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Client Quit]
05:57 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-dev
06:01 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Client Quit]
06:02 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-dev
06:06 -!- roconnor [~roconnor@host-192.252-163-214.dyn.295.ca] has joined #bitcoin-core-dev
06:22 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
06:26 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 246 seconds]
06:29 < kallewoof> vasild: Damn. I guess having undo without block is bad, even if there weren't any instances of badness happening. I wanted to keep this as simple as possible...
06:29 < vasild> just composing a comment on gh...
06:29 < kallewoof> vasild: But wait. We do have the block. It's just that we don't flush the block file. Or am I confused now?
06:30 < kallewoof> vasild: Block is written when it comes in, and later it is connected to tip and undo data is written.
06:31 < kallewoof> I guess no flush essentially means no guarantees that block was actually written or not, though...
06:31 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
06:32 < vasild> posted: https://github.com/bitcoin/bitcoin/pull/17994#discussion_r396451804
06:32 < vasild> now, lets figure this out :)
06:33 < kallewoof> Thanks, your comment makes perfect sense.
06:35 < vasild> so, something like the crude patch in https://github.com/bitcoin/bitcoin/pull/17994/files#r395635091 would restore the order of flushing to blk,undo
06:36 < vasild> it can be simplified because at the time FlushBlockFile() is called thisUndoNeedsFlushingAndFinalizing == nLastBlockFile, so we can FlushUndoFile(nLastBlockFile, true).
06:37 < vasild> FlushBlockFile() flushes nLastBlockFile
06:41 < vasild> hmm
06:45 < vasild> there is a mutex protecting nLastBlockFile :/
06:47 < kallewoof> vasild: It feels like you can just use a flag. Kinda like https://github.com/bitcoin/bitcoin/pull/17994/commits/84ed7228b69a03c56dfd77bb0df84b39b77b5cea
06:47 < kallewoof> vasild: maybe I'm overengineering this
06:49 < vasild> yes, my thought, exactly!
06:49 < vasild> ^^ replying to your comment about the flag, not about overengineering ;-)
06:50  * kallewoof nodnods
06:51 < vasild> kallewoof: now the patch looks good to me, I will stare at it for some more time and will test it.
06:52 < kallewoof> Nice! :) I recompiled my running node and running this code on it now.
06:55 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
06:59 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 250 seconds]
07:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
07:02 -!- kljasdfvv [~flack@p200300D46F149D00D115F4472F4AA66F.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
07:04 -!- kljasdfvv [~flack@p57BC9A1A.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
07:11 -!- kljasdfvv [~flack@p57BC9A1A.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]
07:12 -!- apaval [~apaval@124.108.22.44] has quit [Remote host closed the connection]
07:12 -!- apaval [~apaval@124.108.22.44] has joined #bitcoin-core-dev
07:13 -!- kljasdfvv [~flack@p200300D46F0B8100D115F4472F4AA66F.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
07:18 -!- kljasdfvv [~flack@p200300D46F0B8100D115F4472F4AA66F.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]
07:19 -!- kljasdfvv [~flack@p57BC9A64.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
07:26 -!- kljasdfvv [~flack@p57BC9A64.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
07:26 -!- kljasdfvv [~flack@p57BC9A86.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
07:27 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
07:29 < hebasto> promag: mind separating a fix of #18362 from #18338 into its own pr?
07:29 < gribble> https://github.com/bitcoin/bitcoin/issues/18362 | gui: segfault unloading and immediately reloading wallet with gui · Issue #18362 · bitcoin/bitcoin · GitHub
07:29 < gribble> https://github.com/bitcoin/bitcoin/issues/18338 | Fix wallet unload race condition by promag · Pull Request #18338 · bitcoin/bitcoin · GitHub
07:31 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 240 seconds]
07:33 -!- kljasdfvv [~flack@p57BC9A86.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
07:34 -!- kljasdfvv [~flack@p57BC9AAA.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
07:40 -!- kljasdfvv [~flack@p57BC9AAA.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
07:41 -!- kljasdfvv [~flack@p57BC9ABC.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
07:48 -!- kljasdfvv [~flack@p57BC9ABC.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
07:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
08:00 -!- castironpi [~castironp@84.39.117.57] has quit []
08:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:09 < bitcoin-git> [bitcoin] jnewbery opened pull request #18410: Docs: Improve commenting for coins.cpp|h (master...2020-03-coins-comments) https://github.com/bitcoin/bitcoin/pull/18410
08:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:12 -!- kljasdfvv [~flack@p200300D46F0C14007CAE64EE37DC5BBE.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
08:16 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
08:20 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-161-135.adslplus.ch] has joined #bitcoin-core-dev
08:20 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 256 seconds]
08:22 -!- chendo_ [~chendo_@139.28.218.198] has joined #bitcoin-core-dev
08:37 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]
08:38 -!- berndj [~berndj@azna.co.za] has quit [Ping timeout: 256 seconds]
08:43 -!- berndj [~berndj@197.242.93.82] has joined #bitcoin-core-dev
08:44 < stevenroose> Are genesis txs included in the txindex?
08:44 < stevenroose> Is it possible something regarding that changed between 0.17 and 0.18? (I know it's a stretch :p)
08:44 -!- apaval [~apaval@124.108.22.44] has quit [Remote host closed the connection]
08:45 -!- apaval [~apaval@124.108.22.44] has joined #bitcoin-core-dev
08:45 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
08:46 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
08:46 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
08:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
08:48 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has joined #bitcoin-core-dev
08:48 -!- Kiminuo [~mix@141.98.103.108] has quit [Ping timeout: 265 seconds]
08:52 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
08:54 < fjahr> stevenroose: You mean the genesis coinbase tx, right? It is not in the utxo set and it should also not be in txindex. It was never indexed by satoshis original software and changing it would be a change in consensus rules, however unlikely it is that that output is spent. So I doubt there were any changes, although I don't know. See also the discussion here: https://github.com/bitcoin/bitcoin/issues/3303 
08:54 < stevenroose> fjahr: k thanks
08:55 < stevenroose> I know it's not in the UTXO set. But it might have been indexed. But so it appears not.
08:58 < fjahr> Yeah, it is skipped here: https://github.com/bitcoin/bitcoin/blame/master/src/index/txindex.cpp#L250 The changes you might be referring to are probably the rewrite of the indexing code by jimpo but that should not have changed behavior.
09:02 < stevenroose> Hmm, ed12d5df1ba52b5ef3dd3799de26bb5e1d3fc654 seems to have introduced that in 2018
09:03 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has quit [Read error: Connection reset by peer]
09:03 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has joined #bitcoin-core-dev
09:04 -!- roconnor [~roconnor@host-192.252-163-214.dyn.295.ca] has quit [Quit: Konversation terminated!]
09:05 -!- shesek [~shesek@185.3.145.94] has joined #bitcoin-core-dev
09:07 -!- shesek [~shesek@185.3.145.94] has quit [Client Quit]
09:07 -!- shesek [~shesek@185.3.145.94] has joined #bitcoin-core-dev
09:10 -!- shesek [~shesek@185.3.145.94] has quit [Changing host]
09:10 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
09:10 -!- shesek [~shesek@unaffiliated/shesek] has quit [Client Quit]
09:11 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
09:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
09:18 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has quit [Remote host closed the connection]
09:18 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has joined #bitcoin-core-dev
09:22 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has quit [Ping timeout: 250 seconds]
09:28 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 250 seconds]
09:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:29 < bitcoin-git> [bitcoin] theStack opened pull request #18412: script: fix SCRIPT_ERR_SIG_PUSHONLY error string (master...20200323-fix-script-err-sig-pushonly-error-message) https://github.com/bitcoin/bitcoin/pull/18412
09:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
09:37 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
09:41 < fjahr> stevenroose: ah, true, interesting. So it was a bug for some amount of time: https://github.com/bitcoin/bitcoin/pull/14085
09:42 < fjahr> and the blockfilter headers where want made the fix actually get in, TIL
09:43 < fjahr> s/want/what/
09:50 -!- sipsorcery [~sipsorcer@37.228.254.212] has quit [Ping timeout: 256 seconds]
09:51 -!- sipsorcery [~sipsorcer@37.228.254.212] has joined #bitcoin-core-dev
09:57 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has joined #bitcoin-core-dev
09:58 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
09:59 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
09:59 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
10:00 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
10:04 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 256 seconds]
10:07 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has quit [Ping timeout: 256 seconds]
10:08 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has joined #bitcoin-core-dev
10:12 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has quit [Client Quit]
10:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
10:13 < gleb> We don't have any shared policy for dns seeder implementations for rate-limiting, do we? There's no expectation that "one client ip will send at most 1 request per minute" or whatever? sipa
10:14 < sipa> that sounds like a client policy, not a seeder policy.
10:15 < sipa> as in: the seeder can't prevent people from querying more than once per minite
10:15 < sipa> *minute
10:15 -!- Kiminuo [~mix@141.98.103.76] has joined #bitcoin-core-dev
10:15 < luke-jr> well, it can ignore floods
10:15 < luke-jr> no reason for a shared policy on that tho
10:16 < luke-jr> gleb: also note that clients don't talk to the seed itself; they talk to DNS servers (typically run by their ISP), and that will query and cache from the seed
10:17 < sipa> honest clienta do :)
10:18 < gleb> I'm implementing DNS cache invalidation triggering by reachable (thus already known) nodes, and I think it makes sense to query like 10 different services (legacy, segwit, BLOOM), etc.
10:18 < luke-jr> sipa: you'd need to go out of your way to bypass it and go direct; and there's no benefit in doing so?
10:18 < gleb> And I was wondering if your seeders would be angry if someone from the same endpoint asks 10 requests at once for different service combinations
10:18 < sipa> gleb: they wouldn't know
10:19 < sipa> luke-jr: if you want to DoS attack the seeders, you'd want to connect to them directly i meam
10:19 < luke-jr> I don't understand why you would do that
10:19 < luke-jr> sipa: oh, true
10:19 < gleb> luke-jr: so that private nodes hit early caches more often
10:19 < sipa> gleb: i don't understanx what you're trying to do, though
10:20 < gleb> sipa: i think we were discussing this the other day
10:20 < luke-jr> gleb: I don't get it.
10:20 < sipa> gleb: DNS seeds should only be queried when addrman is low, as a fallback
10:21 < sipa> (not as a last resort like hardcoded seeds, but usually nodes shouldn't be contacting them at all if they're run before and have healthy number of connections)
10:21 < gleb> sipa: or on the first start.
10:21 < luke-jr> "if they've run before"
10:22 < sipa> yeah
10:23 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Quit: Leaving]
10:24 < sipa> i also don't understand why you're querying for multiple services
10:24 < gleb> sipa: Do you understand why I want to do it in the first place? (ignoring multiple services)
10:24 < sipa> no
10:27 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-dev
10:30 < gleb> luke-jr Managed to explain this to sipa via quoting greg from that day :)
10:30 < gleb> "I wonder if listening nodes who are getting incoming connections should randomly query dnsseeds to keep upstream caches primed, but throwing out the results (or comparing to their addrman, logging if there are a bunch of results they don't now about, then throwing away the results).  Those nodes are already not anonymous by virtue of sucessfully
10:30 < gleb> listening, so they don't gain anything by trying"
10:31 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has joined #bitcoin-core-dev
10:32 -!- Krellan_ [~Krellan@2601:640:4100:e:9d8a:ed0e:fa13:93fe] has quit [Remote host closed the connection]
10:32 < luke-jr> hmm
10:32 < luke-jr> I don't know if there's actually value to priming caches tho?
10:32 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has joined #bitcoin-core-dev
10:32 < luke-jr> even a few seconds delay querying isn't going to matter..
10:33 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Quit: Leaving]
10:34 < sipa> luke-jr: it's a privacy gain too, as it means private nodes would reveal less to the seeders, if they're coming from a network with public nodes
10:35 < gleb> I'd say privacy gain has more value than little latency decrease in this context.
10:35 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has quit [Client Quit]
10:35 < luke-jr> sipa: reveal what?
10:35 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
10:36 -!- molz_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
10:36 < sipa> luke-jr: e.g. the network that the private node is in
10:37 < sipa> i wouldn't be surprised if more things can be inferred from the DNS query
10:37 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has quit [Ping timeout: 246 seconds]
10:39 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds]
10:40 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 240 seconds]
10:40 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
10:42 < luke-jr> sipa: more queries on that same network won't hide it..
10:42 < sipa> queries from nodes that are already public
10:42 < luke-jr> the seed doesn't know if they are or aren't..
10:45 < sipa> ?
10:45 < sipa> the seed has a database of public IPs already, even when it is honest
10:47 < luke-jr> what is more queries supposed to do?
10:47 < sipa> i don't know what there is to explain
10:48 < sipa> or what you're missing
10:48 < gleb> sipa: I had the same feeling 10 minute ago with you too :)
10:48 < luke-jr> the seed knows <DNS server> made a query. <DNS server> serving more clients doesn't tell or conceal from the seed anything
10:48 < sipa> gleb: well "cache invalidation" was very confusing! there is no cache invalidation going on at all :)
10:49 < luke-jr> I suppose the querying of more service bit combos might conceal what clients using the DNS server are interested in.. but that's just as easily solved by the client using the DNS seed making multiple queries
10:50 < luke-jr> (perhaps even more reliably!)
10:50 < sipa> luke-jr: when a DNS seed sees a query from a DNS server, it has a better than average guess that there is a private node in that DNS server's network
10:50 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-161-135.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
10:51 < sipa> if the public nodes in that network keep the cache fresh, that changes to "seeing a query has a high probability of there being either private or public nodes in that network"... but the public nodes are already public
10:52 < luke-jr> it could already be public or private
10:52 < luke-jr> oh, except public nodes are already running
10:52 < luke-jr> not sure that matters actually
10:53 < sipa> that makes it much stronger (public nodes in general query much less frequently), but I don't think that's actually necessary for the argument
10:53 < sipa> i think it's still a privacy improvement to private nodes without that
10:53 < luke-jr> I don't
10:54 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has joined #bitcoin-core-dev
10:54 < sipa> imagine some networks have just 1 private node; some have just one public node; some have both; right now, assume both query the seed equally frequently
10:55 < sipa> that means if a seed now sees a query from a DNS server, it has a 50/50 guess about whether there is a private or public node behind it
10:55 < luke-jr> if there are public nodes on the same DNS-server-network, the seed has no idea if it was one of them already
10:55 < luke-jr> 50/50 seems like about the best we could hope for?
10:55 < sipa> if we now change the public nodes to query 10x more frequently, the information the seed gets about whether there is a private node when seeing a query goes down to 10% ish
10:55 < sipa> luke-jr: no, because the public nodes are already public
10:56 < sipa> they don't care about hiding their existence
10:56 < luke-jr> 90/10 means the seed can reliably determine if there is a private node querying..
10:56 < luke-jr> semi-reliably*
10:57 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 256 seconds]
10:57 < sipa> how so?
10:58 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
10:58 -!- filchef [~filchef@212.104.97.177] has joined #bitcoin-core-dev
10:59 < luke-jr> look at deviations in the query pattern?
10:59 < luke-jr> and DNS servers without a public node become very obvious
11:00 -!- chendo_ [~chendo_@139.28.218.198] has quit []
11:01 < sipa> sure
11:01 < sipa> but the ones in a network with public ones are very reliably hidden
11:01 < luke-jr> hmm, forgot caching is like an hour
11:01 < luke-jr> I wonder if the private nodes just querying every hour themselves would have the same effect
11:02 < luke-jr> maybe counter-productive if they're not 24/7 tho
11:05 -!- promag__ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
11:05 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
11:09 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 258 seconds]
11:20 -!- molz_ [~molly@unaffiliated/molly] has quit [Ping timeout: 264 seconds]
11:22 -!- ski1 [~ski@195.206.169.238] has joined #bitcoin-core-dev
11:37 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-dev
11:42 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has joined #bitcoin-core-dev
11:44 < moneyball> hi. fyi only 8 people responded "yes" to the survey for still doing a CoreDev virtually. therefore i didn't do any planning around this. obviously if contributors would like to self-organize in small remote groups, by all means.
11:48 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]
11:49 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has quit [Ping timeout: 246 seconds]
11:50 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
11:51 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds]
11:53 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
11:55 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-161-135.adslplus.ch] has joined #bitcoin-core-dev
11:56 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds]
12:09 -!- hajen [~hajen@45.92.170.184] has joined #bitcoin-core-dev
12:11 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
12:18 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 250 seconds]
12:23 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has joined #bitcoin-core-dev
12:27 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:34 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has quit [Ping timeout: 246 seconds]
12:39 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has quit [Remote host closed the connection]
12:40 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has joined #bitcoin-core-dev
12:40 -!- hajen [~hajen@45.92.170.184] has quit [Remote host closed the connection]
12:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
12:44 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
12:44 -!- vasild_ is now known as vasild
13:07 < provoostenator> moneyball: thanks for trying to coordinate! Hopefully we can do an in-person meetup again after the apocalypse.
13:15 -!- sonofhan [~sonofhan@ip72-193-7-145.lv.lv.cox.net] has joined #bitcoin-core-dev
13:15 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has joined #bitcoin-core-dev
13:29 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has quit [Ping timeout: 260 seconds]
13:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:33 < bitcoin-git> [bitcoin] pierreN opened pull request #18413: script: prevent UB when computing abs value for num opcode serialize (master...fix-script-absolute) https://github.com/bitcoin/bitcoin/pull/18413
13:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:39 < bitcoin-git> [bitcoin] MarcoFalke pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/97b0687501ce...ac579ada7e83
13:39 < bitcoin-git> bitcoin/master 77e4b06 Russell Yanofsky: refactor: Get rid of Wallet::IsWalletFlagSet method
13:39 < bitcoin-git> bitcoin/master 1c2ab1a Russell Yanofsky: refactor: Rename Node::disconnect methods
13:39 < bitcoin-git> bitcoin/master 6ceb219 Russell Yanofsky: refactor: Rename Chain::Notifications methods to be consistent with other ...
13:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:39 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #18278: interfaces: Describe and follow some code conventions (master...pr/ipc-conv) https://github.com/bitcoin/bitcoin/pull/18278
13:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:44 -!- roconnor [~roconnor@host-192.252-163-214.dyn.295.ca] has joined #bitcoin-core-dev
13:51 -!- roconnor [~roconnor@host-192.252-163-214.dyn.295.ca] has quit [Ping timeout: 256 seconds]
13:53 -!- roconnor [~roconnor@host-45-78-205-127.dyn.295.ca] has joined #bitcoin-core-dev
14:00 -!- ski1 [~ski@195.206.169.238] has quit []
14:00 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev
14:05 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 246 seconds]
14:14 -!- BamBaRay36 [~2BamBaRay@213.232.87.72] has quit [Ping timeout: 256 seconds]
14:21 -!- Aaaron1 [~Aaaron@192.145.126.115] has joined #bitcoin-core-dev
14:27 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Remote host closed the connection]
14:27 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-dev
14:29 -!- manantial [~tecnecio_@unaffiliated/manantial] has quit [Ping timeout: 256 seconds]
14:30 -!- brakmic [~brakmic@185.183.85.108] has joined #bitcoin-core-dev
14:36 -!- Krellan_ [~Krellan@c-24-130-205-67.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
15:00 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has quit [Remote host closed the connection]
15:01 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has joined #bitcoin-core-dev
15:12 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
15:13 -!- Krellan_ [~Krellan@c-24-130-205-67.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
15:20 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has quit [Remote host closed the connection]
15:30 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has joined #bitcoin-core-dev
15:30 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Remote host closed the connection]
15:35 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Quit: Leaving]
15:36 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-161-135.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:40 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
15:42 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
15:46 -!- yancy [~root@2400:8902::f03c:92ff:fe70:a5ac] has quit [K-Lined]
15:47 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 250 seconds]
15:47 -!- yancy [~root@2400:8902::f03c:92ff:fe70:a5ac] has joined #bitcoin-core-dev
15:48 -!- sonofhan [~sonofhan@ip72-193-7-145.lv.lv.cox.net] has quit [Quit: Leaving...]
15:50 -!- Klox [~Klox@c-24-1-131-19.hsd1.il.comcast.net] has quit [Ping timeout: 240 seconds]
15:51 -!- Klox [~Klox@c-24-1-131-19.hsd1.il.comcast.net] has joined #bitcoin-core-dev
16:00 -!- apaval [~apaval@124.108.22.44] has quit [Remote host closed the connection]
16:00 -!- apaval [~apaval@124.108.22.44] has joined #bitcoin-core-dev
16:03 -!- filchef [~filchef@212.104.97.177] has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
16:06 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
16:07 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 250 seconds]
16:08 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
16:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]
16:10 -!- lukedashjr is now known as luke-jr
16:15 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 256 seconds]
16:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
16:18 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
16:18 -!- brakmic_ [~brakmic@176.198.41.116] has joined #bitcoin-core-dev
16:21 -!- brakmic [~brakmic@185.183.85.108] has quit [Ping timeout: 264 seconds]
16:23 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 264 seconds]
16:23 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
16:25 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
16:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 256 seconds]
16:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
16:30 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]
16:31 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
16:34 -!- kljasdfvv [~flack@p200300D46F0C14007CAE64EE37DC5BBE.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
16:34 -!- luke-jr- [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
16:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
16:35 -!- kljasdfvv [~flack@p200300D46F0C14007CAE64EE37DC5BBE.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
16:35 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds]
16:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
16:38 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]
16:42 -!- luke-jr- [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]
16:43 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]
16:43 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
16:51 -!- marcoagner [~user@bl13-226-166.dsl.telepac.pt] has quit [Ping timeout: 256 seconds]
16:52 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
16:54 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
16:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds]
16:56 -!- lukedashjr is now known as luke-jr
16:59 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 256 seconds]
17:00 -!- Aaaron1 [~Aaaron@192.145.126.115] has quit []
17:05 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]
17:05 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
17:09 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has joined #bitcoin-core-dev
17:09 -!- lukedashjr is now known as luke-jr
17:12 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
17:16 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]
17:16 -!- lukedashjr is now known as luke-jr
17:22 -!- laxanofido [~laxanofid@185.204.1.185] has joined #bitcoin-core-dev
17:33 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has quit [Remote host closed the connection]
17:35 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has joined #bitcoin-core-dev
17:47 -!- captjakk [~captjakk@184-96-161-66.hlrn.qwest.net] has quit [Remote host closed the connection]
17:48 -!- brakmic_ [~brakmic@176.198.41.116] has quit []
17:48 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has quit [Ping timeout: 246 seconds]
17:50 -!- as_pnn [~pierreirc@119.192.247.147] has quit [Quit: killed]
17:51 -!- as_pnn [~pierreirc@119.192.247.147] has joined #bitcoin-core-dev
17:53 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has joined #bitcoin-core-dev
18:01 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has quit [Ping timeout: 246 seconds]
18:13 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has quit [Quit: Konversation terminated!]
18:24 -!- dqx [~dqx@unaffiliated/dqx] has quit [Ping timeout: 268 seconds]
18:26 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]
18:26 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
18:28 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
18:29 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
19:06 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #bitcoin-core-dev
19:09 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]
19:36 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Ping timeout: 250 seconds]
19:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
19:37 < bitcoin-git> [bitcoin] 21143875584 opened pull request #18414: Create main.yml (master...patch-3) https://github.com/bitcoin/bitcoin/pull/18414
19:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
19:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
19:37 < bitcoin-git> [bitcoin] fanquake closed pull request #18414: Create main.yml (master...patch-3) https://github.com/bitcoin/bitcoin/pull/18414
19:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
19:47 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-dev
19:52 -!- Highway61 [~Thunderbi@104.223.94.138] has quit [Ping timeout: 250 seconds]
19:59 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has joined #bitcoin-core-dev
20:00 -!- laxanofido [~laxanofid@185.204.1.185] has quit []
20:04 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
20:22 -!- jajm1 [~jajm@176.113.74.179] has joined #bitcoin-core-dev
20:29 -!- felixfoertsch [~felixfoer@2001:16b8:50d0:9800:ad41:93ff:f87d:6ee7] has joined #bitcoin-core-dev
20:30 -!- felixfoertsch23 [~felixfoer@2001:16b8:502a:c700:4083:8e4d:276d:ca45] has quit [Ping timeout: 260 seconds]
20:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
20:39 < bitcoin-git> [bitcoin] kallewoof closed pull request #16411: BIP-325: Signet support (master...signet) https://github.com/bitcoin/bitcoin/pull/16411
20:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
21:17 -!- Krellan_ [~Krellan@2601:640:4100:e:8453:2472:8414:d108] has quit [Ping timeout: 246 seconds]
21:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
21:47 < bitcoin-git> [bitcoin] fanquake opened pull request #18415: scripts: add MACHO tests to test-security-check.py (master...add_MACHO_to_security_check) https://github.com/bitcoin/bitcoin/pull/18415
21:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
21:51 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Remote host closed the connection]
23:00 -!- jajm1 [~jajm@176.113.74.179] has quit []
23:03 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-dev
23:04 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Client Quit]
23:10 -!- Kiminuo [~mix@141.98.103.76] has quit [Ping timeout: 256 seconds]
23:18 -!- Krellan_ [~Krellan@c-24-130-205-67.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
23:21 -!- greylica [~greylica@176.113.74.179] has joined #bitcoin-core-dev
23:22 -!- CubicEarth_ [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 258 seconds]
23:23 -!- Krellan_ [~Krellan@c-24-130-205-67.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
23:23 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
23:38 < vasild> What is the reason we store blocks in blk*.dat files in the order they are received and undos in rev*.dat files in height order? This convolutes the code a lot. If we can store in the same order (either receive or height) then some significant simplifications in the code can be done.
23:39 < aj> they're both stored in the order the data is discovered, which minimises having to shuffle the data on disk?
23:41 < sipa> i experimented with 1 file per block/undo early on 
23:41 < sipa> but most filesystems didn't deal well with that
23:42 < vasild> aj: is it the case that we don't have the undo for a given block before having all prior blocks?
23:42 < sipa> vasild: undo data is created when a block is activated
23:42 < sipa> a block can only be activated once we have its data + its parent is active
23:42 < vasild> sipa: right, that would be 600k small files
23:43 < vasild> I see
23:43 < sipa> so yes it requires a block + its ancestors
23:44 < sipa> but we only attempt activation in chains that would lead to a new best tip
23:44 < vasild> so if we want (I am not sure if we do) store block and undo in the same order it means to store both in height order.
23:44 < sipa> so it's possible we download a block and then never activate it
23:44 < sipa> that would mean killing parallel block download
23:45 < sipa> (which inherently downloads them in non-height order)
23:45 < vasild> sipa: what about keeping the downloaded blocks with are not connected yet in memory and only send them to disk once we have all prior blocks, together with the undo (both in height order)?
23:46 < vasild> s/with are/which are/
23:46 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev
23:46 < sipa> vasild: that's not very realistic
23:46 < sipa> except for big machines
23:46 < vasild> too much memory would be required?
23:47 < sipa> we download up to 1000 blocks simultaneously
23:47 < sipa> that number can probably be reduced
23:47 < sipa> it's too low early on in the chain, and too large later on
23:49 < sipa> i don't think this should be a big problem really
23:49 < vasild> hmm, we can deduce how much memory would have been needed if we look at an existent database where blocks are stored in receive order
23:49 < sipa> i guess
23:50 < sipa> but you can't just add gigabytes (or even 100 MB) to the memory footprint
23:50 < sipa> people configure nodes on small devicez
23:52 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 260 seconds]
23:52 -!- BamBaRay36 [~2BamBaRay@213.232.87.72] has joined #bitcoin-core-dev
23:53 < vasild> If this turns out to be worth exploring, then I guess the download would have a buffer where out of order blocks are stored until being connected and if this buffer grows too much then some blocks evicted from it (maybe highest ones) meaning they would have to be re-downloaded because we couldnt store them in memory and couldn't put them on disk
23:53 < sipa> gah
23:53 < sipa> we did that in 0.9
23:53 < sipa> it was horrible
23:54 < sipa> you'd download the same blocks over and over again
23:54 < vasild> too many re-downloads?
23:54 < sipa> i really don't see a reason to change that (i'm biased, i wrote the parallel block download code...)
23:54 < vasild> how many blocks were kept in memory before starting eviction?
23:55 < vasild> well, parallel download is a must, I am not saying to kill it
23:55 < sipa> 1000, i think - but the whole block download logic was a bunch of hacks ducktaped together back then
23:55 < sipa> it's unfair to compare it to anything you're suggesting now
23:56 < sipa> but i also don't see a good motivation for changing the order
23:56 < sipa> we could just reorder the undo data in files whenever needed too by rewriting them
23:56 < vasild> ok, two key points from the above discussion - 1. we can't write undo in receive order and 2. there is no strict reason to store blocks in receive order - it is being done to ease parallel download.
23:57 < sipa> except that'd be much harder than just fixing the flushing logi  
23:57 < sipa> well, they're stored in order to avoid needing to rewrite things
23:57 < sipa> it's just the easiest thing to do
23:58 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
23:58 < vasild> to rewrite things you mean rewrite the source code or data on disk? :)
23:59 < aj> data on disk
23:59 < vasild> if we buffer blocks and store them in height order on disk then nothing will be rewritten on disk?
23:59 < aj> if you buffer them on disk, you'll be rewriting them; if you buffer them in ram, you're adding 100M-1G of extra ram which is unreasonable
--- Log closed Tue Mar 24 00:00:31 2020