--- Log opened Tue Dec 01 00:00:32 2020
00:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:21 < bitcoin-git> [bitcoin] naumenkogs opened pull request #20539: Avoid rebucketing on restart when it's not necessary (master...2020-12-01-rebucket-asmap-fix) https://github.com/bitcoin/bitcoin/pull/20539
00:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:25 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #bitcoin-core-dev
00:30 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Client Quit]
00:30 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #bitcoin-core-dev
00:34 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Client Quit]
00:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:42 < bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/ffd5e7a8567d...24e4857b29b3
00:42 < bitcoin-git> bitcoin/master 12bd0fc Russell Yanofsky: Move NodeImpl from interfaces/node.cpp to node/interfaces.cpp
00:42 < bitcoin-git> bitcoin/master 2a26771 Russell Yanofsky: Move ChainImpl from interfaces/chain.cpp to node/interfaces.cpp
00:42 < bitcoin-git> bitcoin/master 629a929 Russell Yanofsky: Move WalletImpl from interfaces/wallet.cpp to wallet/interfaces.cpp
00:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:42 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20494: refactor: Move node and wallet code out of src/interfaces (master...pr/ipc-mv) https://github.com/bitcoin/bitcoin/pull/20494
00:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:50 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #bitcoin-core-dev
01:04 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
01:04 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 240 seconds]
01:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:05 < bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/24e4857b29b3...cd720337fe9c
01:05 < bitcoin-git> bitcoin/master 9d4b4b2 Elle Mouton: refactor: Avoid double to int cast for nCheckFrequency
01:05 < bitcoin-git> bitcoin/master e331069 Elle Mouton: refactor: Make CTxMemPool::m_check_ratio a const and a constructor argumen...
01:05 < bitcoin-git> bitcoin/master f15e780 Elle Mouton: refactor: Clean up CTxMemPool initializer list
01:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:05 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20222: refactor: CTxMempool constructor clean up (master...ctxmempool_refactor) https://github.com/bitcoin/bitcoin/pull/20222
01:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:19 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:24 -!- BGL [~twenty@75-149-171-58-Washington.hfc.comcastbusiness.net] has quit [Ping timeout: 256 seconds]
01:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:47 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
01:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:59 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cd720337fe9c...f2a673f15b51
01:59 < bitcoin-git> bitcoin/master 86b1ab6 Hennadii Stepanov: refactor: Replace deprecated Qt::SystemLocale{Short,Long}Date
01:59 < bitcoin-git> bitcoin/master f2a673f Jonas Schnelli: Merge bitcoin-core/gui#137: refactor: Replace deprecated Qt::SystemLocale{...
01:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:59 < bitcoin-git> [gui] jonasschnelli merged pull request #137: refactor: Replace deprecated Qt::SystemLocale{Short,Long}Date (master...201127-locale) https://github.com/bitcoin-core/gui/pull/137
01:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:02 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Quit: leaving]
02:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
02:03 -!- kexkey [~kexkey@static-198-54-132-105.cust.tzulo.com] has quit [Ping timeout: 240 seconds]
02:07 -!- Tennis [~Tennis@unaffiliated/tennis] has joined #bitcoin-core-dev
02:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:18 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
02:18 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
02:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
02:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:23 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f2a673f15b51...335d27d08141
02:23 < bitcoin-git> bitcoin/master 1d578c0 Emil Engler: doc: Add bash as an OpenBSD dependency
02:23 < bitcoin-git> bitcoin/master 335d27d Jonas Schnelli: Merge #20512: doc: Add bash as an OpenBSD dependency
02:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:24 < bitcoin-git> [bitcoin] jonasschnelli merged pull request #20512: doc: Add bash as an OpenBSD dependency (master...2020-11-doc-build-openbsd-bash-dependency) https://github.com/bitcoin/bitcoin/pull/20512
02:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:27 < bitcoin-git> [bitcoin] jonasschnelli pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/335d27d08141...dcb7518067cd
02:27 < bitcoin-git> bitcoin/master 65afe4c Hennadii Stepanov: build: Drop unneeded ApplicationServices framework dependency
02:27 < bitcoin-git> bitcoin/master ec4a46d Hennadii Stepanov: build: Drop unneeded IOKit framework dependency
02:27 < bitcoin-git> bitcoin/master dcb7518 Jonas Schnelli: Merge #20496: build: Drop unneeded macOS framework dependencies
02:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:28 < bitcoin-git> [bitcoin] jonasschnelli merged pull request #20496: build: Drop unneeded macOS framework dependencies (master...201125-as) https://github.com/bitcoin/bitcoin/pull/20496
02:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:28 -!- kljasdfvv [~flack@p200300d46f24de00fb39606f311c9ef9.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
02:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:29 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/dcb7518067cd...277c225b8421
02:29 < bitcoin-git> bitcoin/master 982e548 Jonas Schnelli: Don't set BDB flags when configuring without
02:29 < bitcoin-git> bitcoin/master 277c225 Jonas Schnelli: Merge #20478: Don't set BDB flags when configuring without
02:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:29 < bitcoin-git> [bitcoin] jonasschnelli merged pull request #20478: Don't set BDB flags when configuring without (master...2020/11/bdbless_mac) https://github.com/bitcoin/bitcoin/pull/20478
02:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:33 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
02:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Client Quit]
02:35 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
02:41 -!- proofofkeags [~proofofke@174-16-212-53.hlrn.qwest.net] has quit [Ping timeout: 260 seconds]
02:44 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]
02:44 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
02:44 -!- reallll is now known as belcher
02:48 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Quit: Pavlenex]
03:03 -!- Kiminuo [~mix@141.98.103.172] has quit [Quit: Leaving]
03:18 -!- Josiane57Wyman [~Josiane57@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
03:31 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds]
03:34 -!- Josiane57Wyman [~Josiane57@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 260 seconds]
03:55 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
03:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
04:02 -!- BGL [~twenty@75-149-171-58-Washington.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
04:11 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #bitcoin-core-dev
04:25 -!- gimps [~gimps@185.163.110.116] has quit [Remote host closed the connection]
04:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:39 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #20540: test: Fix wallet_multiwallet issue on windows (master...2012-testmw) https://github.com/bitcoin/bitcoin/pull/20540
04:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:05 -!- da39a3ee5e6b4b0d [~da39a3ee5@mx-ll-171.5.161-165.dynamic.3bb.co.th] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
05:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:06 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/277c225b8421...dfd0b700886c
05:06 < bitcoin-git> bitcoin/master 17a5f17 practicalswift: fuzz: Make addrman fuzzing harness deterministic
05:06 < bitcoin-git> bitcoin/master dfd0b70 MarcoFalke: Merge #20425: fuzz: Make CAddrMan fuzzing harness deterministic
05:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:06 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20425: fuzz: Make CAddrMan fuzzing harness deterministic (master...fuzzers-make-addrman-harness-deterministic) https://github.com/bitcoin/bitcoin/pull/20425
05:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:14 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
05:15 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
05:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
05:24 < MarcoFalke> michaelfolkson: Let's take this here
05:25 < michaelfolkson> MarcoFalke: Sure, thanks
05:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
05:27 < michaelfolkson> I think I'm misunderstanding terminology. So seeds will be randomly generated...
05:28 < MarcoFalke> Some fuzz engines have command line switches to make them deterministic
05:28 < michaelfolkson> But if a fuzz tester finds an issue with a randomly generated seed a different fuzz tester who tries that same input needs to get the same result
05:29 < MarcoFalke> yes
05:29 < MarcoFalke> if you can't reproduce, it will be hard to debug and fix
05:29 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:9156:59b2:2700:3dd:eb69] has joined #bitcoin-core-dev
05:30 < michaelfolkson> But you can reproduce as long as you know what the inputs were. Whether they were randomly generated or not is surely irrelevant?
05:31 < michaelfolkson> It is surely a logging issue rather than a choice of deterministic/random?
05:32 < MarcoFalke> int main() { if (rand() > 2) crash(); }
05:33 < MarcoFalke> how would you reliably reproduce a crash here, knowing the input?
05:33 < MarcoFalke> how the input was generated is irrelevant to how to reproduce a bug
05:34 < MarcoFalke> logging helps to debug intermittent (non-reproducible) bugs better
05:35 < MarcoFalke> we have a lot of them, which is why logging is cranked up in all tests
05:36 < michaelfolkson> In your example one fuzz tester would crash the program with say an input of 3. For another fuzz tester to reproduce it they would need to know the other fuzz tester tried an input of 3
05:37 < michaelfolkson> But how the fuzz tester initially generated 3 is irrelevant. It could have been deterministic or random
05:39 < michaelfolkson> So in the PR there is a CAddrMan fuzzing harness. Again I'm not entirely sure how "harness" is defined
05:40 < michaelfolkson> But fuzz testers should be able to randomly generate addrs and try different addrs to other fuzz testers. As long as they log which addrs they tried and which addrs created issues?
05:41 < MarcoFalke> whether the above example crashes is *independent* of the input
05:41 < MarcoFalke> the progam takes no input, assuming that rand will ask the OS for randomness
05:42 < MarcoFalke> and in most cases the OS randomness is not reproducible
05:43 < michaelfolkson> And the problem is that we don't log what the OS supplied for randomness? 
05:43 < MarcoFalke> the problem is that we ask the os for randomness
05:44 < MarcoFalke> tests should supply the randomness. Either with a hardcoded seed or letting the fuzz engine pick one
05:44 < michaelfolkson> Ah so the problem is an external source of randomness rather than an internal source from within the tests
05:45 < michaelfolkson> It is still random but it is generated within the tests
05:45 < MarcoFalke> as long as the source is reproducible/deterministic, it can be from anywhere
05:46 < michaelfolkson> And by that you mean a reproducible source of randomness is one that supplies the same inputs when it is asked for randomness
05:46 < michaelfolkson> Everytime it is asked for randomness it provides say inputs of 7,2,3 as the first three random inputs
05:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
05:47 < michaelfolkson> The problem becomes when you ask it for randomness twice and it provides different inputs on the second time vs the first
05:47 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
05:48 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
05:49 -!- einyx [einyx@fsf/member/einyx] has quit [Ping timeout: 256 seconds]
05:49 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
05:50 < MarcoFalke> yes, when "s/time/program execution/"
05:50 < michaelfolkson> Gotcha. Thanks!
05:51 < michaelfolkson> How would you explain what a fuzzing "harness" is?
05:51 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
05:53 < MarcoFalke> a test case or one test target
05:54 < michaelfolkson> OK "entry-point executable" from this https://vdalabs.com/2019/02/01/microsoft-security-risk-detection-writing-a-custom-test-harness-to-fuzz-libraries/
05:54 < michaelfolkson> Ok thanks for the help
05:57 < jnewbery> hi folks. It's p2p irc meeting day. There aren't currently any topics in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#1-dec-2020. Feel free to add anything you want to discuss. The meeting starts in just over an hour.
05:57 < gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
06:02 -!- Lightlike [b9ff439e@185.255.67.158] has joined #bitcoin-core-dev
06:04 -!- untwisted [~untwisted@84.39.117.57] has joined #bitcoin-core-dev
06:05 -!- Lightlike [b9ff439e@185.255.67.158] has left #bitcoin-core-dev []
06:08 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
06:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:14 < bitcoin-git> [bitcoin] MarcoFalke pushed 9 commits to master: https://github.com/bitcoin/bitcoin/compare/dfd0b700886c...f17e8ba3a17b
06:14 < bitcoin-git> bitcoin/master 18246ed Pieter Wuille: Fix and improve taproot_construct comments
06:14 < bitcoin-git> bitcoin/master cdf900c Pieter Wuille: Document need_vin_vout_mismatch argument to make_spender
06:14 < bitcoin-git> bitcoin/master 8dbb7de Pieter Wuille: Add comments to VerifyTaprootCommitment
06:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:14 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20207: Follow-up extra comments on taproot code and tests (master...202010_taproot-comments) https://github.com/bitcoin/bitcoin/pull/20207
06:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:28 < michaelfolkson> How does one do that jnewbery? Just manually edit that dev wiki page?
06:30 -!- promag [~promag@188.250.84.129] has quit [Ping timeout: 246 seconds]
06:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
06:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
06:45 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
06:48 -!- untwisted [~untwisted@84.39.117.57] has quit [Remote host closed the connection]
06:48 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
06:50 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
06:51 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
06:51 < sdaftuar> has anyone looked at m_addr_known to see if we should be manually clearing it every day? from a quick look at my logs, i estimate that my addr messages to my peers average substantially less than 5000 messages per day, which i think means that our daily self-announcements would propagate less frequently than we'd expect (maybe once every few days, instead of once per day)
06:54 < jnewbery> michaelfolkson: yes, just edit the page
06:54 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
06:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
06:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
06:59 -!- tralfaz [~davterra@68.235.43.158] has joined #bitcoin-core-dev
07:00 -!- glozow [uid453516@gateway/web/irccloud.com/x-suaydrfreocgdkkl] has joined #bitcoin-core-dev
07:00 < jnewbery> #startmeeting
07:00 < core-meetingbot> Meeting started Tue Dec  1 15:00:17 2020 UTC.  The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
07:00 < core-meetingbot> Available commands: action commands idea info link nick
07:00 < jnewbery> #bitcoin-core-dev P2P Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james 
07:00 -!- sturles [~sturles@gufseplassen00.slxdrift.no] has joined #bitcoin-core-dev
07:00 -!- sturles [~sturles@gufseplassen00.slxdrift.no] has quit [Changing host]
07:00 -!- sturles [~sturles@unaffiliated/sturles] has joined #bitcoin-core-dev
07:00 < jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
07:01 < glozow> hi
07:01 < sipa> hi
07:01 < gleb> hi
07:01 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:9156:59b2:2700:3dd:eb69] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
07:01 < ariard> hi
07:01 < jnewbery> hi folks. No proposed topics in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#1-dec-2020 so could be a short meeting
07:01 < wumpus> hi
07:01 < gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
07:01 < ajonas> Hi
07:01 < michaelfolkson> hi
07:02 < jnewbery> anyone have any proposed topics, or anything they want to share with the group?
07:02 -!- Lightlike [b9ff439e@185.255.67.158] has joined #bitcoin-core-dev
07:02 < michaelfolkson> I'd like to chat about people's thoughts on current P2P fuzzing and whether they do it. And if not why not
07:03 < jnewbery> #topic p2p fuzzing
07:03 < core-meetingbot> topic: p2p fuzzing
07:03 -!- davterra [~davterra@68.235.43.174] has quit [Ping timeout: 256 seconds]
07:03 < gleb> fuzzing is just a new concept to me, I don't do it because I need to take time to learn it first :)
07:03 < sdaftuar> if someone pointed me to an idiot's guide to fuzzing, i might do it.  but i'm pretty clueless.
07:03 < fanquake> hi
07:04 -!- miketwenty1 [~miketwent@136.55.84.49] has joined #bitcoin-core-dev
07:04 < michaelfolkson> Ok so it is a basic understanding issue?
07:04 < gleb> i think so.
07:04 < michaelfolkson> Don't really get what it is trying to do
07:04 < sipa> find bugs
07:04 < jnewbery> There were a couple of good PR review club meetings hosted by Marco about fuzzing: https://bitcoincore.reviews/17860 https://bitcoincore.reviews/18521
07:05 < jnewbery> they contain lots of references to further reading for anyone who's curious
07:05 < ariard> you can start with the docs of AFL/libfuzzer/hongfuzz and look for talk of their authors :)
07:05 < sipa> michaelfolkson: what do you mean by p2p fuzzing btw?
07:05 < MarcoFalke> there are already p2p fuzzers
07:06 < emzy> Hi
07:06 < michaelfolkson> Yeah there is P2P code. And P2P experts in this meeting. It would be good eventually to bring that expertise on what should be fuzzed in a P2P context
07:06 < michaelfolkson> (I think)
07:06 < MarcoFalke> I am working on increasing their coverage
07:07 < ariard> IIRC practicalswift added coverage for a part of the p2p stack a while ago ?
07:07 < michaelfolkson> I guess it is an issue of whether fuzz coverage is something the expert fuzzers do or something that everyone thinks about when they open PR etc
07:07 < MarcoFalke> michaelfolkson: The ci does it on every PR
07:08 < jnewbery> I don't run the fuzzers locally because of the extra overhead of building them. I also expect most bugs except the very shallow ones to be discovered by fuzzers running continuously on dedicated machines.
07:08 < vasild> hi
07:08 < sipa> michaelfolkson: i think you need to distintuish between "writing fuzzers" and ",running fuzzers"
07:08 < michaelfolkson> Presumably say the P2P experts should also think about what should be fuzzed in a P2P contexts
07:08 < MarcoFalke> sipa: and "generating seeds"
07:08 < michaelfolkson> sipa: Right, could discuss both
07:08 < sipa> running fuzzers is something everyone can do
07:09 < sipa> writing fuzzers... that's just one way among dozens of how you can increasy confidence in code you're writing
07:09 -!- Limnoria1 [~Limnoria@195.140.213.38] has joined #bitcoin-core-dev
07:09 < sipa> up to the author and what people believe is important in that context
07:09 < michaelfolkson> Should we be thinking about writing fuzzers in the same way as we do writing unit tests and writing functional tests? Everybody should be thinking about adding them? Or just the fuzz test experts/team
07:10 < michaelfolkson> I guess that's my question on the writing them side
07:10 < michaelfolkson> And then on the running them side it is how do we get more people to run them as part of their workflow
07:10 < jnewbery> I don't think there's a problem that needs to be solved here
07:10 < nehan> hi. i found the PR club extremely helpful in learning how to fuzz. i was able to relatively quickly doing it having zero experience with it before.
07:11 < sipa> obbiously?
07:11 < MarcoFalke> michaelfolkson: I guess it is up to the author. Not everyone is adding unit tests or functional tests.
07:11 < sipa> michaelfolkson: again, it's one way among many of increasing confidence incyour code. some things lend themselves well for fuzz testing, others not so much
07:11 -!- filchef [~filchef@212.104.97.177] has joined #bitcoin-core-dev
07:12 < michaelfolkson> MarcoFalke: Not everyone is but everyone should at least be considering whether to or not. Right?
07:12 < MarcoFalke> michaelfolkson: Ideally, yes
07:13 < michaelfolkson> Ok thanks, that's helpful
07:13 -!- tralfaz is now known as davterra
07:13 < jnewbery> any other topics?
07:13 < michaelfolkson> I think the jnewbery point on what should be done on dedicated machines is something I have also wondered
07:14 < sipa> michaelfolkson: run the fuzzers
07:14 < ariard> a short note on state of tx-pinning/package-relay and discussion on the LN-side?
07:14 < sipa> like our CI runs the tests
07:14 < MarcoFalke> michaelfolkson: ./test/fuzz/test_runner.py --help
07:15 < MarcoFalke> anyone can do it. It supports single run (ci) and generation (long running)
07:15 < jnewbery> #topic tx pinning / package relay
07:15 < core-meetingbot> topic: tx pinning / package relay
07:15 < ariard> so we had this discussion few irc meeting ago with LN devs
07:16 < ariard> we found yet-another case of tx-pinning after the new anchor spec
07:16 < ariard> https://github.com/lightningnetwork/lightning-rfc/pull/803
07:16 < ariard> we would like to demo the attack actually explained here: https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
07:16 < ariard> before to know exactly what we would be cool to ask as a change on the p2p layer 
07:17 < ariard> so right now I'm spending time hacking with RL to have the necessary toolchain
07:17 < ariard> and that's all :)
07:17 < ariard> *the attacks, we have multiple scenarios
07:17 < glozow> what's the SIGHASH_SINGLE malleability? sorry i'm unfamiliar
07:18 < sipa> RL?
07:18 < fanquake> rust lightning
07:18 < sipa> ah.
07:18 < ariard> glozow: it lets you sign only the index of the output, thus adding any output without cooperation of your LN counterparty (IIRC)
07:19 < jnewbery> glozow: https://bitcoinops.org/en/newsletters/2020/09/16/#stealing-onchain-fees-from-ln-htlcs
07:19 < michaelfolkson> And by case of tx-pinning you mean another scenario in Lightning where tx pinning is a problem. Rather than a new way to tx pin in Core
07:19 < sipa> glozow: all sighash modes are effecrively *intentional* malleability, they're there so soke tgings can be changed in a tx without affecting the sig
07:20 < ariard> michaelfolkson: yes we discovered another vulnerability but it wasn't mentinonned on the ML
07:20 < glozow> ahhhh thanks
07:20 < ariard> michaelfolkson: note also that pinning doesn't only affect LN but also bitcoin protocol like vaults, DLC
07:20 < nehan> nit ariard: I don't think you should use the term "split brains" to describe differing mempools. as you point out in the doc, mempools are different *by design*. saying it's a "split brain" implies there should be an unsplit (single) brain.
07:21 < nehan> ariard: "split brain" is usually used to describe a temporary network partition in distributed systems.
07:21 < ariard> nehan: thanks, I think the expression is from zeeman and was just reused at it is by t-bast
07:21 < michaelfolkson> So the messaging is like tx pinning should be even more of a priority to solve in Core than we already knew it was
07:21 -!- miketwen_ [~miketwent@ec2-52-207-61-44.compute-1.amazonaws.com] has joined #bitcoin-core-dev
07:21 < sipa> i don't think it can be solved in general
07:21 < ariard> nehan: I think I used mempool-partition to describe the same phenomena but if you have a better distributed system expression?
07:22 < nehan> ariard: not off the top of my head! will think about it.
07:22 < jnewbery> inconsistent mempools
07:22 < ariard> sipa: define general ? if you mean for any bitcoin protocol without care of protocol designer I likely agree with you
07:24 < ariard> michaelfolkson: note that cdecker proposed a new tx-relay overlay to solve pinning instead of change to p2p tx-relay
07:24 -!- miketwenty1 [~miketwent@136.55.84.49] has quit [Ping timeout: 240 seconds]
07:24 < sipa> ariard: i think dos protection will always result in an inability to accept transactions in some scenarios where that transaction would have been accepted from p2p in another state
07:24 -!- someone235 [uid419897@gateway/web/irccloud.com/x-xrruhlejkwndamue] has quit [Quit: Connection closed for inactivity]
07:25 < sipa> we can reduce the set of situations under which that can happen using better algorithms
07:25 < sipa> but the problem in a generic sense seems inherent
07:25 < michaelfolkson> ariard: So that would potentially be run by the Core nodes that care about Lightning? And the Core nodes that don't care wouldn't run it
07:25 < ariard> sipa: yes I agree on this! I describe such scenario here https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html (the 3rd one)
07:26 < ariard> but for the other something like RBF-package relay _or_ rejecting low-fee pinning transaction might be a solution
07:26 < sipa> ariard: my poijt is you'll always be able to find more things like that
07:27 < sipa> and no solution (that doesn't introduce DOs attacks) is going to leave (possibly complicated) forms of pinning enabled
07:28 < sipa> if it's only speaking forms of pinning that pose problems to you then it'd be good to know what those are
07:28 < ariard> ariard: I don't understand fully your last sentence, if you mean we'll always have complicated cases of pinning I agree?
07:28 < sipa> yes
07:29 < sipa> ok, then we agree :)
07:29 < ariard> okay so we agree on this, what I'm more interested to solve are the easy-to-execute pinning describe as scenario 1) and 2) in my june mail
07:29 < michaelfolkson> All pinning is a problem. There are no specific forms of pinning that are particularly problematic I think...
07:30 < ariard> to mitigate more complicated scenario we had this disccusion with matt about redundant tx-relay broadcast, but that's outside the tx-relay model
07:31 < ariard> michaelfolkson: not all the pinning have the same level of difficulty :) I invite you to read this mail https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html 
07:31 < sipa> redundant as in LN would do relay?
07:31 < sipa> or something else!
07:31 < sipa> ?
07:31 < cdecker> Notice that the alternative transport over the lightning overlay is not intended to be a complete solution, just reduce the effectiveness of pinning by making it less likely to succeed
07:31 < ariard> like some broadcast your transaction over DNS or radio :)
07:31 < sipa> oh
07:32 < sipa> i was hoping LN, because it's an inherently different situation than bitcoin's identityless P2P
07:32 < ariard> like it's easy to pin a LN transaction if you know the full-node, but if this victim has another entry point to the p2p network you won't succeed
07:33 < ariard> sipa: yes, we had this discussion about embedding transaction in LN's onion, it does fit in the standard onion size
07:33 < ariard> more you have redundant tx-relay network, better you're :)
07:34 < sipa> better you're what?
07:34 < ariard> harder it is for an attacker to jam with your tx-relay
07:34 < jnewbery> "the more redundant networks you have, the better off you are"
07:35 < ariard> cdecker: yeah and it was relying on such lighthning overlay being adopted by miners? or what was the state of the discussion :) ?
07:35 < sipa> jnewbery: ah thanks
07:35 < ariard> jnewbery: ah, thanks
07:36 < ariard> anyway I didn't intend to occupy the spot, I'm working on demoing the tx-pinning LN attack we know about and learn from it 
07:36 < cdecker> Yeah, I was hoping that it'd be attractive for miners to listen to the overlay since the feerate is higher (even though they don't beat absolute fee, which is really not the miner's main motivation)
07:37 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Quit: Pavlenex]
07:37 < ariard> that might be a way to align incentives, but still I'm not sure miners are great at maintaining an extended software stack
07:39 < ariard> is anyone wants to do p2p review beg ?
07:40 < michaelfolkson> What do you mean? You want to discuss the beg process?
07:40 < michaelfolkson> Or beg for particular PRs?
07:40 < cdecker> If there's interest from miners to get access I can write up a faux-bitcoin-node that acts as a bridge between bitcoin p2p and the ln overlay relay network
07:41 < ariard> michaelfolkson: I mean p2p meetings are a nice spot for people to ask for reviews on their PR
07:41 < michaelfolkson> Ah ok
07:41 < michaelfolkson> Feel free to beg :)
07:41 < jnewbery> any other topics?
07:41 < sipa> gleb: want to mention the erlay bip updates?
07:42 < gleb> Oh yeah sure.
07:42 < jnewbery> #topic erlay bip updates
07:42 < core-meetingbot> topic: erlay bip updates
07:42 < gleb> So sometimes reconciliation fails initially (first sketch is insufficient, because it's too small and allows to decode up to N differences)
07:42 < gleb> We then don't give up, but make one more attempt.
07:43 < gleb> There are 2 ways to make one more attempt while *still being 100% efficient*: bisection and extension. They are independent alternatives.
07:43 < gleb> We used to do bisection, because it allows to spend a bit less CPU cycles on computing sketches (and just a cool trick I guess)
07:44 < gleb> In practice, the implementation turned out to be too complicated on the Bitcoin Core p2p protocol side.
07:44 < gleb> So I switched the code to do sketch extensions instead. It's much less code, and the code complexity is now more aligned with general Bitcoin project complexity.
07:44 < gleb> And the fact it's a bit more CPU expensive doesn't matter because we expect sketches of very low capacity.
07:45 < gleb> For more rationale see the updated BIP, lemme give you a link.
07:45 < gleb> https://github.com/bitcoin/bips/pull/899
07:45 < sipa> it's also easier to extend to allow doing multiple tikes, if need be
07:45 < gleb> And it's all in the #18261 now, fully ready for review, please review :)
07:45 < gribble> https://github.com/bitcoin/bitcoin/issues/18261 | Erlay: bandwidth-efficient transaction relay protocol by naumenkogs · Pull Request #18261 · bitcoin/bitcoin · GitHub
07:45 < gleb> I'm willing to do any help for review facilitation.
07:45 < gleb> Including 1-1 sessions over voice chat or something with code walkthrough.
07:46 < sdaftuar> gleb: sounds good, i will take a look
07:46 < jnewbery> sipa: I assume you mean 'multiple times'. Why would you want to do that? Is that part of the erlay BIP?
07:47 < gleb> I don't really see why we'd need more than 1 extra round for now, especially with our transaction volumes and block size :)
07:47 < sipa> jnewbery: no it's not; the current bip allows for extending exactly once
07:47 -!- Lightlike [b9ff439e@185.255.67.158] has quit [Remote host closed the connection]
07:47 < sipa> but if we ever determine that doing it multiple times is beneficial, that'd be a trivial change for extending
07:47 < sipa> but not simple at all for bisection
07:48 < jnewbery> sipa: makes sense. Thanks
07:49 < jnewbery> any final topics?
07:49 < jnewbery> Thanks all!
07:49 < jnewbery> #endmeeting
07:49 < core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
07:49 < core-meetingbot> Meeting ended Tue Dec  1 15:49:39 2020 UTC.  
07:49 < core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2020/bitcoin-core-dev.2020-12-01-15.00.moin.txt
07:55 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:58 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 256 seconds]
08:01 -!- Guyver2_ is now known as Guyver2
08:02 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #bitcoin-core-dev
08:02 < jnewbery> vasild: if you're still around, I have a question about addrv2 support negotiation. There seems to be a discrepency between the bip and the implementation in Bitcoin Core
08:02 < vasild> what?
08:02 < jnewbery> in BIP 155, it says "sendaddrv2 SHOULD be sent after receiving the verack message from the peer": https://github.com/bitcoin/bips/blob/7e3284dafda168da34888977dbf4a55519b0c54d/bip-0155.mediawiki#L137
08:03 < vasild> "if the documentation and the code disagree, then both are probably wrong"
08:03 < jnewbery> in the implementation, we send it on receiving the version message: https://github.com/bitcoin/bitcoin/blob/f17e8ba3a17b6516a1b1fb7f45d506a339e99f90/src/net_processing.cpp#L2368
08:03 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Client Quit]
08:03 < jnewbery> (which may be before the peer has sent verack)
08:04 < jnewbery> I think ideally, it'd be sent between version and verack, like the wtxidrelay message
08:06 < vasild> hmm
08:06 < vasild> they seem to disagree indeed
08:09 < sdaftuar> that reminds me - i noticed that we send "sendaddrv2" messages to block-relay-only peers.  is that intentional or desirable?
08:11 < vasild> for the implementation it does not matter when sendaddrv2 is sent and received, but I think there were considerations that no messages should be sent before sending verack (and WTXIDRELAY is somehow an exception to this)
08:12 < sipa> jnewbery: hmm, so really we have in practice two different styles of negotiation (after sending version, and after sending verack), and the bip actually suggests a third (after receiving verack)
08:12 < vasild> and since it is not necessary to send sendaddrv2 before sending verack I chose to send it after (don't add to the exception of WTXIDRELAY)
08:12 < jnewbery> if we tie addrv2 to the same p2p version as wtxidrelay (70016) we can change it to send between version and verack
08:13 < vasild> sdaftuar: it is not intentional
08:13 < sipa> well, for addrv2 it doesn't matter
08:13 < jnewbery> sdaftuar: we could skip sending the message to block-relay-only peers, but I don't think it does any harm to send it
08:14 < sipa> jnewbery, sdaftuar: agree; it seems pointless but harmless
08:14 < sdaftuar> i guess the ship has sailed on adding a flag to that message to indicate whether we participate in addr relay?
08:14 < sipa> yes
08:15 < jnewbery> there are other pointless-but-harmless messages during negotiation. We'll send wtxidrelay and sendaddrv2 to feeler connections before immediately disconnecting
08:15 < sipa> i'm happy we got bip154 in 0.21, but this isn't the time to change it anymore...
08:15 < sipa> *bip155
08:16 < sdaftuar> i'm just trying to figure out what to do with my block-relay-only peer negotiation proposal
08:16 < sdaftuar> previously i had thoguht about requiring that turning on block-relay-only would turn off addr-relay
08:16 < vasild> maybe bip155 should be corrected: "sendaddrv2 SHOULD be sent after receiving the verack message" s/receiving/sending/
08:16 < sdaftuar> but it seemed overly prescriptive in some ways, and addr-relay should perhaps be negotiated separately
08:16 < sdaftuar> but if we
08:17 < sdaftuar> but if we're giving up on addr-relay changes now, then perhaps i'll go back to my initial proposal
08:17 < jnewbery> sdaftuar: is there any benefit in turning off addr relay? We can just ignore any addr messages we get from that peer
08:17 < sipa> vasild: i think that's the simplest fix
08:18 < sdaftuar> i think it would helpful for the peer to know it shouldn't relay addresses to us because we're a black hole
08:18 < sdaftuar> so that it can relay addrs to other peers instead
08:18 < jnewbery> we already send addrs to light clients, which are addr relay black holes, I think
08:18 < sdaftuar> seems a shame that "honest" behavior results in somewhat worse addr propagation
08:18 < sdaftuar> i think that should be fixed or improved as well
08:18 < vasild> sdaftuar: I think "I participate in addr relay" and "I maintain a usable/complete addr database" should be negotiated/announced separately from sendaddrv2 (I support addrv2 format), even if we could change sendaddrv2 now.
08:19 < sdaftuar> vasild: worth adding a new p2p message for it?
08:19 < sdaftuar> we could go that route as well
08:19 < sdaftuar> i just was afraid that adding more p2p messages seems to raise complaints about the protocol being confusing or redundant
08:19 < sdaftuar> though it's free
08:19 < jnewbery> vasild: your suggested change to BIP155 isn't what Bitcoin Core is doing. It sends the message after receiving a version message
08:19 < sipa> jnewbery: and after sending the verack, no?
08:20 < jnewbery> sipa: ah yes, you're right.
08:20 < sipa> sdaftuar: how do you suggest dealing with spv clients being black holes?
08:20 < jnewbery> do we really want to allow peers to switch from addrv1 to addrv2 at any point?
08:21 < vasild> sdaftuar: what about introducing one generic message for announcing capabilities, like "I can do X, Y, Z". That idea was shot last time I mentioned it, IIRC...
08:21 < sipa> jnewbery: we already do, i think
08:21 < sdaftuar> jnewbery: is there any problem with peers switching from addrv1 to addrv2?
08:22 < sipa> jnewbery: addrv2 negotiation is really simple, it's just a message indicating "you're as of now allowed to send me addrv2 instead of addrv1"
08:22 < sdaftuar> sipa: my first thought was that if we allowed peers to opt-in (or out) of addr-relay, then we should just treat spv clients as honest network participants
08:22 < sipa> sdaftuar: which means?
08:23 < sdaftuar> if they want to participate in addr-relay, they can; the problem becomes one of software being broken for not implementing a negotiation feature if they don't relay addresses but indicate that they do
08:24 < sdaftuar> which we can't control anyway
08:24 < sdaftuar> the problem in my view is that honest software has no way to communicate not to send addr messages because they will get dropped
08:26 < sipa> sdaftuar: i guess my question is: with this new addr relay negotiation... do you make it "addr relay is by default on for NODE_NETWORK(_LIMITED) peers, off otherwise"
08:27 < sipa> or something like that, so that old spv software is set off by default
08:27 < jnewbery> It just seems easier to think about if we don't need to worry about addrv2 support changing during a peer's lifetime. I've had a quick skim of the code and agree that it's simple, but still think that the ability to effectively renegotiate addrv2 support is an unnecessary complexity.
08:27 < sipa> jnewbery: i agree, but i also think it's a cost we've already paid effectively
08:27 < sdaftuar> jnewbery: it only goes in one direction right?
08:28 < sipa> it works
08:28 < jnewbery> put another way: if we weren't currently able to renegotiate from addrv1 to addrv2 during a peer's lifetime, and I proposed that we added that as a feature, I think the suggestion would be NACKed immediately
08:28 < sipa> yes
08:28 < sdaftuar> jnewbery: only because unnecessary changes are, well, unnecessary :)
08:28 < sipa> but the same may be true in the other direction :)
08:29 < sipa> making it impossible to renegotiate would need more code, not less
08:29 < jnewbery> sipa: code complexity isn't a one-off cost. It's an ongoing burden for all current and future contributors
08:29 < sipa> jnewbery: of course
08:29 < jnewbery> sipa: no it wouldn't. The spec would say: "send sendaddrv2 between version and verack". Receiving the message at any other time would be ignored
08:30 < sipa> jnewbery: and right now, it doesn't need code ro decide whether to ignore it or not
08:30 < sipa> it's all trivial changes of course, but i don't think it's clear cut that one alternative is obviously simpler than the other
08:31 < jnewbery> sipa: yes, the burden is placed on the developer to audit whether it's safe to make that transition during the peer's lifetime, instead of it just being const
08:31 < sipa> you might have a point if *all* negotiation were between version and verack, but that's already not the case and won't be
08:32 < jnewbery> and the burden is also placed on any future developer who makes changes to the way addr relay works, to be aware that addrv2 support can change at any point
08:32 < sdaftuar> sipa: i think defaulting addr relay to off for non-NODE_NETWORK(_LIMITED) peers would be fine. (or eventually make that the default to give spv client authors sufficient warning, inc ase it's a surprise)
08:34 < sipa> jnewbery: i agree that's something to keep in mind... but is that really worth changing the code (and spec) for, given that there are several other things that behave in exactly the same way already?
08:35 < sipa> as opposed to say, add a code comment to clarify addrv2 status can change af any point
08:35 < sipa> (and sendheaders, and filter status, and ...)
08:36 < vasild> "send sendaddrv2 between version and verack" --> "send sendaddrv2 between sending version and sending verack" or "send sendaddrv2 between receiving version and receiving verack"
08:36 < jnewbery> sipa: one or both have to change anyway, and we now know the right way to negotiate features, so if there's another rc, I think we should take advantage of that
08:36 < sipa> i strongly disagree
08:37 < sipa> there is no bug here
08:37 < sipa> the time for something like this has passed
08:37 < jnewbery> vasild: "send addrv2 between sending version and sending verack"
08:37 < jnewbery> there's either a bug in the spec or the implementation
08:38 < sipa> hmm, right
08:38 < sipa> that's fair
08:38 < sipa> i was treating it as a typo in the spec, and assuked it was intended to mimick the existing feature negotiations
08:39 < sipa> and i think because of that, the spec makes no sense
08:39 < sipa> but you could see it differently
08:39 < vasild> to me it looks like a bug/typo in the spec and should s/receiving/sending/
08:39 < sipa> yeah, exactly
08:43 < jnewbery> I don't think it's worth making an rc for this
08:44 < vasild> agree
08:44 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:44 < sipa> i think the simplest solution is fixing the spec
08:44 < jnewbery> I think my preferred change to the spec would be to s/after receiving the verack/after receiving the version/. That means that at least we can send our message between version and verack.
08:45 < sipa> (not because it mismatches the implementation, but because it appears unintentional)
08:45 < sipa> does the current 0.21rc code work correctly if it receives addrv2 before verack?
08:46 < jnewbery> Oh, no we can't because we'll only process a sendaddrv2 after receiving a verack.
08:46 < jnewbery> sipa: snap
08:46 < vasild> "does the current 0.21rc code work correctly if it receives addrv2 before verack?" -- yes
08:46 < jnewbery> vasild: no, we'll drop the message if we receive it before verack
08:47 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #bitcoin-core-dev
08:47 < jnewbery> https://github.com/bitcoin/bitcoin/blob/f17e8ba3a17b6516a1b1fb7f45d506a339e99f90/src/net_processing.cpp#L2538-L2541
08:47 < jnewbery> It'd be nice if we could consolidate all these feature negotiation messages to one place, but that seems impossible at this point
08:47 < sipa> oh, i should perhaps hage brought this up during the meeting: should torv3 anchors work in 0.21?
08:48 < sipa> do we consider that a missing feature or a bug?
08:48 < vasild> jnewbery: right, sorry
08:48 < jnewbery> sipa: I'd say missing feature
08:49 < sipa> jnewbery: i'm beginning to lean in that direction too, and it seems hebasto agrees as well
08:49 < jnewbery> we didn't have either before v0.21, so people aren't depending on them working together
08:49 < sipa> yeah, and they're mostly an unobservable feature anyway
08:49 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has joined #bitcoin-core-dev
08:49 < vasild> seems like a good thing to "fix" in 0.21.1
08:50 < vasild> (torv3 anchors)
08:51 < sipa> vasild: saw #20516?
08:51 < gribble> https://github.com/bitcoin/bitcoin/issues/20516 | Well-defined CAddress disk serialization, and addrv2 anchors.dat by sipa · Pull Request #20516 · bitcoin/bitcoin · GitHub
08:51 < vasild> sipa: yes, but did not dive in it yet in order to comment
08:51 < sipa> sure, no rush
08:51 < vasild> I did not get it why did you close the other small pr
08:52 < sipa> vasild: it was intended as a quick fix for 0.21
08:52 < vasild> it would get torv3 anchors
08:52 < sipa> not as-is, it needed your patch or 20516 as well
08:52 < vasild> yes, + the patch I posted in the comments
08:53 -!- ctrlbreak [~ctrlbreak@159.2.182.106] has quit [Ping timeout: 265 seconds]
08:53 < vasild> would the small pr + my patch in the comments cause any trouble for 20516? I think no
08:53 < sipa> 201516 does exactly the same thing
08:53 < sipa> just cleaner
08:53 < sipa> (imo)
08:54 < sipa> but it's not something i feel is worth it for 0.21 anymore
08:54 < sipa> so i'd rather do it properly instead in 0.21.1 or 22
08:54 < vasild> ok
08:55 < sipa> 20516 makes it also fail deserialization if the on-disk version is unexpected, and adds more tests
08:56 < sipa> (i wrote that before you commemted with your patch, otherwise i'd have based it on yours)
08:58 < vasild> aha, since you mention "fail deserialization"...
08:59 < vasild> should we compare the stream version with ondisk version in CAddress deserialization
08:59 < vasild> and if one has ADDRV2_FORMAT set but the other does not then throw?
09:00 < vasild> is this what you mean by "unexpected"?
09:00 < sipa> that'll break anchors
09:00 < sipa> once v2 is used for those, but an old anchors.dar is read
09:00 < vasild> oh, right
09:01 < sipa> the semantics in 20516 is that the ADDRV2_FORMAT in the stream version enables/disables the use of addrv2 in the disk version
09:01 < sipa> so you get an error if it is set in the disk version, but not in the stream version, on deserialize
09:01 < vasild> during serialization?
09:02 < sipa> but the other direction works
09:02 < vasild> I see
09:03 < sipa> i have a follow-up (the serializarion parameter stuff) that just splits all the different serialization types out, and removes ADDRV2_FORMAT from stream versions (but it remains inside the CAddress disk serializer)
09:04 -!- proofofkeags [~proofofke@174-16-212-53.hlrn.qwest.net] has joined #bitcoin-core-dev
09:06 -!- lightlike [~lightlike@p200300c7ef1ab3003906d5c2a9a5021c.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
09:07 < sipa> unfortunately, that means at least 4 versions
09:07 < sipa> DISK, NETWORK_NOTIME, NETWORK_V1, NETWORK_V2
09:08 < sipa> but probably 5; so you have DISK_V1 and DISK_V1_OR_V2 (where pre-v3 addrman would set DISK_V1 which causes an error if a v2 addr on disk is in it)
09:13 < vasild> :-|
09:15 < sipa> hmm, maybe we should just remove the "notime" functionality from CAddress
09:16 -!- einyx [einyx@fsf/member/einyx] has joined #bitcoin-core-dev
09:16 < sipa> and just invoke it as serializing nServices and CService spearately
09:26 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer]
09:26 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #bitcoin-core-dev
09:33 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
09:36 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds]
09:59 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:13 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Quit: Pavlenex]
10:19 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
10:21 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 240 seconds]
10:21 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds]
10:23 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
10:36 -!- Randolf [~randolf@184.70.10.188] has joined #bitcoin-core-dev
10:36 -!- Tennis [~Tennis@unaffiliated/tennis] has quit [Quit: Leaving]
10:37 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 272 seconds]
10:38 -!- jonatack [~jon@109.232.227.138] has joined #bitcoin-core-dev
10:38 -!- Mercury_Vapor [~Mercury_V@174-082-166-092.res.spectrum.com] has quit [Quit: Leaving]
10:45 -!- Mercury_Vapor [~Mercury_V@174-082-166-092.res.spectrum.com] has joined #bitcoin-core-dev
10:50 -!- kexkey [~kexkey@static-198-54-132-121.cust.tzulo.com] has joined #bitcoin-core-dev
11:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:05 < bitcoin-git> [bitcoin] sipa opened pull request #20541: Move special CAddress-without-nTime logic to net_processing (master...202012_addr_without_time_is_no_addr) https://github.com/bitcoin/bitcoin/pull/20541
11:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:05 < sipa> vasild: ^
11:25 -!- brianhoffman [~brianhoff@pool-71-191-34-154.washdc.fios.verizon.net] has joined #bitcoin-core-dev
11:34 -!- lightlike [~lightlike@p200300c7ef1ab3003906d5c2a9a5021c.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
11:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
11:44 -!- cltrbreak_MAD2 [~ctrlbreak@159.2.182.106] has joined #bitcoin-core-dev
11:48 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has quit [Ping timeout: 240 seconds]
11:52 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has joined #bitcoin-core-dev
11:55 -!- cltrbreak_MAD2 [~ctrlbreak@159.2.182.106] has quit [Ping timeout: 260 seconds]
12:20 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:40 -!- ctrlbreak_MAD is now known as ctrlbreak
12:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
12:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
12:49 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
12:57 -!- Guest19 [~textual@78-2-110-233.adsl.net.t-com.hr] has joined #bitcoin-core-dev
13:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
13:39 -!- Guest19 [~textual@78-2-110-233.adsl.net.t-com.hr] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
13:47 -!- Guyver2__ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
13:50 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 256 seconds]
14:17 -!- Guyver2__ [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:30 -!- bhy [b0b58536@i15-les02-ntr-176-181-133-54.sfr.lns.abo.bbox.fr] has joined #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 -!- bhy [b0b58536@i15-les02-ntr-176-181-133-54.sfr.lns.abo.bbox.fr] has quit [Remote host closed the connection]
14:38 -!- joelklabo [~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
15:04 -!- mrostecki [mrostecki@nat/suse/x-kwnqnqspcazesbuo] has quit [Ping timeout: 272 seconds]
15:10 < promag> quick question, does it makes sense to limit cookie auth to loopback? anyone using it in other ways?
15:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
15:20 -!- miketwen_ [~miketwent@ec2-52-207-61-44.compute-1.amazonaws.com] has quit []
15:29 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 256 seconds]
15:35 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
15:37 -!- pinheadmz [~pinheadmz@71.190.30.138] has quit [Read error: Connection reset by peer]
15:38 -!- pinheadmz [~pinheadmz@71.190.30.138] has joined #bitcoin-core-dev
15:45 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 265 seconds]
15:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
15:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
15:57 -!- mrostecki [mrostecki@nat/suse/x-oplejjvnaxzshynh] has joined #bitcoin-core-dev
16:21 -!- da39a3ee5e6b4b0d [~da39a3ee5@mx-ll-171.5.161-165.dynamic.3bb.co.th] has joined #bitcoin-core-dev
16:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:23 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/f17e8ba3a17b...80d4231e1638
16:23 < bitcoin-git> bitcoin/master 021feb3 João Barbosa: refactor: Drop redudant CWallet::GetDBHandle
16:23 < bitcoin-git> bitcoin/master 9b74461 João Barbosa: refactor: Assert before dereference in CWallet::GetDatabase
16:23 < bitcoin-git> bitcoin/master 80d4231 fanquake: Merge #19980: refactor: Some wallet cleanups
16:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:24 < bitcoin-git> [bitcoin] fanquake merged pull request #19980: refactor: Some wallet cleanups (master...2020-09-wallet-cleanups) https://github.com/bitcoin/bitcoin/pull/19980
16:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:26 -!- Randolf [~randolf@184.70.10.188] has quit [Remote host closed the connection]
16:26 -!- Randolf [~randolf@184.70.10.188] has joined #bitcoin-core-dev
16:31 -!- balbirs [~balbirs__@bilbo.ozlabs.org] has quit [Quit: ZNC 1.8.2+deb1 - https://znc.in]
16:34 -!- da39a3ee5e6b4b0d [~da39a3ee5@mx-ll-171.5.161-165.dynamic.3bb.co.th] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
16:35 -!- pinheadm_ [~pinheadmz@71.190.30.138] has joined #bitcoin-core-dev
16:36 -!- pinheadmz [~pinheadmz@71.190.30.138] has quit [Ping timeout: 264 seconds]
16:40 -!- pinheadmz [~pinheadmz@71.190.30.138] has joined #bitcoin-core-dev
16:43 -!- pinhead__ [~pinheadmz@71.190.30.138] has joined #bitcoin-core-dev
16:43 -!- pinheadm_ [~pinheadmz@71.190.30.138] has quit [Ping timeout: 256 seconds]
16:46 -!- pinheadmz [~pinheadmz@71.190.30.138] has quit [Ping timeout: 256 seconds]
16:48 -!- davec [~davec@072-183-054-196.res.spectrum.com] has quit [Ping timeout: 264 seconds]
16:50 -!- pinheadmz [~pinheadmz@71.190.30.138] has joined #bitcoin-core-dev
16:53 -!- pinhead__ [~pinheadmz@71.190.30.138] has quit [Ping timeout: 240 seconds]
16:57 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
17:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:14 -!- pinheadm_ [~pinheadmz@71.190.30.138] has joined #bitcoin-core-dev
17:16 -!- pinheadmz [~pinheadmz@71.190.30.138] has quit [Ping timeout: 265 seconds]
17:19 -!- da39a3ee5e6b4b0d [~da39a3ee5@171.5.161.165] has joined #bitcoin-core-dev
17:22 -!- joelklabo [~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
17:25 -!- davec [~davec@072-183-054-196.res.spectrum.com] has joined #bitcoin-core-dev
17:27 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
17:30 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
17:33 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection]
17:35 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
17:35 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]
17:39 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-dev
17:46 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer]
17:46 -!- Limnoria1 [~Limnoria@195.140.213.38] has quit [Remote host closed the connection]
17:46 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #bitcoin-core-dev
17:52 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]
17:57 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev
17:57 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]
17:57 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
18:00 -!- Randolf [~randolf@184.70.10.188] has quit [Quit: Leaving]
18:06 -!- d_ed1 [~d_ed@185.163.110.116] has joined #bitcoin-core-dev
18:07 -!- pinheadmz [~pinheadmz@71.190.30.138] has joined #bitcoin-core-dev
18:09 -!- pinheadm_ [~pinheadmz@71.190.30.138] has quit [Ping timeout: 240 seconds]
18:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:12 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to 0.21: https://github.com/bitcoin/bitcoin/compare/9facca3ce0ad...68bd88597a79
18:12 < bitcoin-git> bitcoin/0.21 01b647b Niklas Gögge: build: Avoid secp256k1.h include from system
18:12 < bitcoin-git> bitcoin/0.21 68bd885 fanquake: Merge #20505: [backport] build: Avoid secp256k1.h include from system
18:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:12 < bitcoin-git> [bitcoin] fanquake merged pull request #20505: [backport] build: Avoid secp256k1.h include from system (0.21...21_backport) https://github.com/bitcoin/bitcoin/pull/20505
18:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
18:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
18:58 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
19:00 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 240 seconds]
19:02 -!- tuna [ac625c20@172.98.92.32] has joined #bitcoin-core-dev
19:07 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
20:09 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 256 seconds]
20:10 -!- tuna [ac625c20@172.98.92.32] has quit [Ping timeout: 245 seconds]
20:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
20:15 < bitcoin-git> [bitcoin] fanquake opened pull request #20543: ci: no-longer exclude feature_block in TSAN job (master...dont_exclude_feature_block_cirrus) https://github.com/bitcoin/bitcoin/pull/20543
20:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
20:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
20:17 < bitcoin-git> [bitcoin] fanquake closed pull request #20357: ci: Use travis_fold on Travis CI only (master...201109-travis) https://github.com/bitcoin/bitcoin/pull/20357
20:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
20:18 < fanquake> Anyone else want to review the 0.19 backports in #20150 ?
20:18 < gribble> https://github.com/bitcoin/bitcoin/issues/20150 | [0.19] Backports by fanquake · Pull Request #20150 · bitcoin/bitcoin · GitHub
20:18 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-dev
20:18 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
20:18 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
20:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
20:51 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
20:54 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
20:56 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
21:05 -!- pinheadmz [~pinheadmz@71.190.30.138] has quit [Quit: pinheadmz]
21:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
21:07 -!- tralfaz [~davterra@68.235.43.158] has joined #bitcoin-core-dev
21:09 -!- davterra [~davterra@68.235.43.158] has quit [Read error: Connection reset by peer]
21:15 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection]
21:18 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #bitcoin-core-dev
21:29 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
21:29 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
21:35 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
21:39 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
21:41 < fanquake> Having to double-click through to see in-progress cirrus runs is very annoying
21:42 < fanquake> What is the point of this intermediate "checks" page (i.e https://github.com/bitcoin/bitcoin/pull/20543/checks?check_run_id=1484331810) that just lists "view more details" links
21:43 < fanquake> Also the fact that the left hand column truncates the CI names just enough so that none of the identifying info is visible 
21:43 < fanquake> +1
22:12 -!- d_ed1 [~d_ed@185.163.110.116] has quit [Ping timeout: 264 seconds]
22:16 < luke-jr> fanquake: agree
22:29 -!- Khaytsus1 [~Khaytsus@185.103.96.147] has joined #bitcoin-core-dev
23:00 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds]
23:02 -!- Guest19 [~textual@89-172-133-17.adsl.net.t-com.hr] has joined #bitcoin-core-dev
23:18 < fanquake> thanks dergoegge
23:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:27 < bitcoin-git> [bitcoin] MarcoFalke reopened pull request #20357: ci: Use travis_fold on Travis CI only (master...201109-travis) https://github.com/bitcoin/bitcoin/pull/20357
23:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:30 -!- sdfs [566d29fd@86.109.41.253] has joined #bitcoin-core-dev
23:30 -!- sdfs [566d29fd@86.109.41.253] has quit [Remote host closed the connection]
23:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:34 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/80d4231e1638...607c844f3720
23:34 < bitcoin-git> bitcoin/master fada2df MarcoFalke: test: Fix wallet_multiwallet issue on windows
23:34 < bitcoin-git> bitcoin/master 607c844 MarcoFalke: Merge #20540: test: Fix wallet_multiwallet issue on windows
23:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:34 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20540: test: Fix wallet_multiwallet issue on windows (master...2012-testmw) https://github.com/bitcoin/bitcoin/pull/20540
23:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
23:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
23:55 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #bitcoin-core-dev
--- Log closed Wed Dec 02 00:00:33 2020