--- Log opened Thu Dec 03 00:00:34 2020
00:05 -!- benthecarman [~ben@108-95-148-10.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-core-dev
00:09 -!- da39a3ee5e6b4b0d [~da39a3ee5@ppp-223-24-170-139.revip6.asianet.co.th] has joined #bitcoin-core-dev
00:09 -!- bosch-0 [uid472282@gateway/web/irccloud.com/x-mblandatniuyyvuo] has quit [Quit: Connection closed for inactivity]
00:20 -!- twistedline [~twisted@unaffiliated/twistedline] has quit [Read error: Connection reset by peer]
00:21 -!- twistedline [~twisted@unaffiliated/twistedline] has joined #bitcoin-core-dev
00:35 -!- bosch-0 [uid472282@gateway/web/irccloud.com/x-hjzqeykpbkgroeyg] has joined #bitcoin-core-dev
00:38 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:42 -!- da39a3ee5e6b4b0d [~da39a3ee5@ppp-223-24-170-139.revip6.asianet.co.th] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
00:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
00:58 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:9156:658b:3008:cf:28b1] has joined #bitcoin-core-dev
01:08 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-dev
01:08 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host]
01:08 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-dev
01:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:11 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a35b948836db...681ce59d0eac
01:11 < bitcoin-git> bitcoin/master fad7be5 MarcoFalke: test: Fix intermittent p2p_finerprint issue
01:11 < bitcoin-git> bitcoin/master 681ce59 MarcoFalke: Merge #20466: test: Fix intermittent p2p_fingerprint issue
01:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:12 -!- benthecarman [~ben@108-95-148-10.lightspeed.austtx.sbcglobal.net] has quit [Ping timeout: 260 seconds]
01:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:12 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20466: test: Fix intermittent p2p_fingerprint issue (master...2011-testIntFixp2p) https://github.com/bitcoin/bitcoin/pull/20466
01:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:19 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #20556: rpc: Properly document return values (submitblock, gettxout, getblocktemplate, scantxoutset) (master...2012-rpcDoc) https://github.com/bitcoin/bitcoin/pull/20556
01:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:35 -!- Guest19 [~textual@78-0-24-193.adsl.net.t-com.hr] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
01:37 < promag> MarcoFalke: is #20017 something to push forward? what is the best time work on it?
01:37 < gribble> https://github.com/bitcoin/bitcoin/issues/20017 | rpc: Add RPCContext by promag · Pull Request #20017 · bitcoin/bitcoin · GitHub
01:43 < MarcoFalke> promag: Heh, depends on other reviewers
01:48 < promag> I don't mean to merge. with branch 21 "done" maybe its something to work on early on 22
01:54 -!- Guest19 [~textual@95.168.100.138] has joined #bitcoin-core-dev
01:56 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 256 seconds]
01:57 -!- jonatack [~jon@134.19.179.187] has joined #bitcoin-core-dev
02:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:40 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #20548: RPC: Tolerate unknown parameters, but with clear warning/errors (master...soften_rpcauth) https://github.com/bitcoin/bitcoin/pull/20548
02:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:00 -!- Guest19 [~textual@95.168.100.138] has quit [Quit: Textual IRC Client: www.textualapp.com]
03:02 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Remote host closed the connection]
03:03 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #bitcoin-core-dev
03:03 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]
03:18 -!- Madaline26Gibson [~Madaline2@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
03:25 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Quit: Pavlenex]
03:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:39 < bitcoin-git> [bitcoin] jnewbery opened pull request #20557: addrman: Fix new table bucketing during unserialization (master...2020-12-fix-addrman-bucketing) https://github.com/bitcoin/bitcoin/pull/20557
03:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:43 -!- roconnor [~roconnor@host-45-58-200-239.dyn.295.ca] has quit [Remote host closed the connection]
03:51 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds]
03:55 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #bitcoin-core-dev
03:56 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Client Quit]
03:56 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #bitcoin-core-dev
03:58 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Client Quit]
04:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:23 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/681ce59d0eac...a3186b6da60e
04:23 < bitcoin-git> bitcoin/master c82d15b Hennadii Stepanov: depends: Do not force Precompiled Headers (PCH) for building Qt on Linux
04:23 < bitcoin-git> bitcoin/master a3186b6 Wladimir J. van der Laan: Merge #20520: depends: Do not force Precompiled Headers (PCH) for building...
04:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:24 < bitcoin-git> [bitcoin] laanwj merged pull request #20520: depends: Do not force Precompiled Headers (PCH) for building Qt on Linux (master...201127-pch) https://github.com/bitcoin/bitcoin/pull/20520
04:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:24 -!- bosch-0 [uid472282@gateway/web/irccloud.com/x-hjzqeykpbkgroeyg] has quit [Quit: Connection closed for inactivity]
04:37 -!- Madaline26Gibson [~Madaline2@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds]
04:40 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds]
04:40 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
04:43 -!- pinheadmz [~pinheadmz@71.190.30.138] has joined #bitcoin-core-dev
04:47 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
04:48 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
04:50 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #bitcoin-core-dev
05:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:03 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #20558: test: Add MaybeCompactWalletDB tsan suppression (take 2) (master...2012-testSanTsan) https://github.com/bitcoin/bitcoin/pull/20558
05:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:04 -!- reallll is now known as belcher
05:04 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Quit: Pavlenex]
05:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:05 < bitcoin-git> [bitcoin] naumenkogs closed 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
05:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:08 -!- rhiaro [~opendatas@178.62.242.100] has quit [Quit: No Ping reply in 180 seconds.]
05:10 -!- rhiaro [~opendatas@178.62.242.100] has joined #bitcoin-core-dev
05:16 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:9156:658b:3008:cf:28b1] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
05:21 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
05:28 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
05:35 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:9156:658b:3008:cf:28b1] has joined #bitcoin-core-dev
05:35 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
05:35 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]
05:36 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
05:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:42 < bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/a3186b6da60e...3fa6a9fc8c90
05:42 < bitcoin-git> bitcoin/master 8b99e60 Aaron Clauson: Adjusted msvc compiler and linker settings to remove optimisations that ar...
05:42 < bitcoin-git> bitcoin/master 2c69381 Aaron Clauson: Removed redundant git pull from appveyor config.
05:42 < bitcoin-git> bitcoin/master 3fa6a9f Wladimir J. van der Laan: Merge #20506: ci: AppVeyor fixes for Visual Studio 2019 16.8.1 image
05:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:42 < bitcoin-git> [bitcoin] laanwj merged pull request #20506: ci: AppVeyor fixes for Visual Studio 2019 16.8.1 image (master...msvc-no-optimise) https://github.com/bitcoin/bitcoin/pull/20506
05:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:42 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
05:48 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:9156:658b:3008:cf:28b1] has quit [Ping timeout: 264 seconds]
05:53 -!- feb [~feb@178.162.212.214] has quit [Remote host closed the connection]
05:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:54 < bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/3fa6a9fc8c90...a0489f3472f3
05:54 < bitcoin-git> bitcoin/master 467c346 Hennadii Stepanov: net: Drop unneeded Windows headers in compat.h
05:54 < bitcoin-git> bitcoin/master f796f00 Hennadii Stepanov: net: Drop unneeded headers when compat.h included
05:54 < bitcoin-git> bitcoin/master cadb77a Hennadii Stepanov: net: Add compat.h header for htonl function
05:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:55 < bitcoin-git> [bitcoin] laanwj merged pull request #20221: net: compat.h related cleanup (master...201022-compat) https://github.com/bitcoin/bitcoin/pull/20221
05:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:55 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
05:55 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
06:02 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #bitcoin-core-dev
06:04 -!- vasild_ is now known as vasild
06:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:07 < bitcoin-git> [bitcoin] testingaccount234234 opened pull request #20559: Update README.md (master...fix-readme-term-change) https://github.com/bitcoin/bitcoin/pull/20559
06:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:09 < bitcoin-git> [bitcoin] laanwj closed pull request #20559: Update README.md (master...fix-readme-term-change) https://github.com/bitcoin/bitcoin/pull/20559
06:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:10 -!- reallll [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
06:11 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
06:23 -!- sunweaver1 [~sunweaver@185.163.110.125] has joined #bitcoin-core-dev
06:24 < vasild> hebasto: I guess s/a0489f3/0e2d9ef/ in your comment https://github.com/bitcoin/bitcoin/pull/20182#issuecomment-738023008
06:25 < hebasto> vasild: thanks! fixed
06:28 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
06:28 < vasild> yw :)
06:30 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
06:37 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
06:37 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
06:40 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
06:43 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]
06:48 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Quit: leaving]
06:59 -!- proofofkeags [~proofofke@174-16-212-53.hlrn.qwest.net] has quit [Ping timeout: 256 seconds]
07:05 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
07:07 -!- guest534543 [~mix@141.98.103.196] has quit [Ping timeout: 260 seconds]
07:09 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
07:33 -!- reallll is now known as belcher
07:35 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]
07:36 -!- Kiminuo [~mix@141.98.103.196] has joined #bitcoin-core-dev
07:37 -!- miketwenty1 [~miketwent@ec2-18-211-157-212.compute-1.amazonaws.com] has joined #bitcoin-core-dev
07:41 < miketwenty1> Question about bitcoin builds and gitian builds, when you build from source you can put in build options/flags to exclude/include certain things like whether or not the wallet, UPnP, zmq.. are these build options baked into gitian builds to enable everything? If I for example wanted to do a gitian build and not build someone or include something do I have this flexibility?
07:42 < miketwenty1> not build something* like exclude wallet 
07:42 < fanquake> yes
07:42 < fanquake> just adjust the CONFIGFLAGS in the gitian descriptor
07:42 < fanquake> https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/gitian-linux.yml#L42
07:43 < miketwenty1> ok.. but this would now result in different binaries if you start messing with the descriptor files right?
07:44 < fanquake> yes
07:51 < miketwenty1> in the future / even with guix .. would you imagine gitian sigs for multiple common options for each minor/major release of bitcoin?  like one with everything enabled.. another build is just the node.. another build with zmq and maybe a few other things .. etc.. 
07:54 < fanquake> Yes that's possible, and probably quite likely. I'd imagine there are many people running bitcoin nodes, that have no interest in it supporting UPNP, ZMQ, or even having the wallet compiled into it.
07:55 -!- budo [4f45b238@79-69-178-56.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev
07:57 -!- budo [4f45b238@79-69-178-56.dynamic.dsl.as9105.com] has quit [Remote host closed the connection]
08:03 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
08:06 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
08:06 < luke-jr> jnewbery: are you trolling? "to make life easier for maintainers of downstream projects."
08:07 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
08:10 < luke-jr> I mean, not only is the premise false, but you're saying you want to reject my PRs simply to go out of the way to discriminate against and make things harder for me personally?
08:22 < harding> luke-jr: what are you responding to?
08:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:23 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #20560: fuzz: Link all targets once (master...2012-fuzzLinkOnce) https://github.com/bitcoin/bitcoin/pull/20560
08:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:25 < harding> Ah, that was a comment from https://github.com/bitcoin/bitcoin/pull/20548
08:27 -!- kexkey [~kexkey@static-198-54-132-121.cust.tzulo.com] has joined #bitcoin-core-dev
08:27 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:30 -!- jarolrod [uid475272@gateway/web/irccloud.com/x-rlfzxaphdcoussrw] has joined #bitcoin-core-dev
08:51 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Quit: Pavlenex]
08:51 -!- Pavlenex [~Thunderbi@178.220.103.52] has joined #bitcoin-core-dev
08:52 -!- Klox04809318631 [~Klox@c-24-1-131-19.hsd1.il.comcast.net] has quit [Ping timeout: 256 seconds]
09:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:11 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #20550: RPC: Tolerate invalid rpcauth options (master...soften_rpcauth2) https://github.com/bitcoin/bitcoin/pull/20550
09:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:12 -!- Kiminuo [~mix@141.98.103.196] has quit [Read error: Connection reset by peer]
09:13 < luke-jr> MarcoFalke: please stop abusing github access
09:13 < MarcoFalke> the pull has three NACKs, I am personally fine with it, but I don't see how it could be merged
09:14 < luke-jr> there isn't a single NACK
09:16 < luke-jr> and all three negative-sounding comments, are based on false assumptions
09:16 < luke-jr> (contrast to the change this is fixing, where I had in fact posted a reasoned NACK on true premises)
09:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:17 < bitcoin-git> [bitcoin] MarcoFalke reopened pull request #20550: RPC: Tolerate invalid rpcauth options (master...soften_rpcauth2) https://github.com/bitcoin/bitcoin/pull/20550
09:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:18 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 246 seconds]
09:22 < promag> > On the command line only, not in config files
09:22 < promag> why?
09:23 < promag> what's the reason for this behavior? I wasn't aware of it
09:23 < promag> and are you saying that -rpcauth=foo on the cmdline should fail?
09:23 < luke-jr> promag: config files are expected to possibly have unknown options
09:24 < luke-jr> -rpcauth=foo on the cmdline failing sounds okay - I can't think of a use case for tolerating that
09:24 < promag> this is a known option though
09:24 < luke-jr> and it would match the existing behaviour
09:24 < promag> it's a known option with an invalid value
09:24 < luke-jr> promag: >3 fields is unknown
09:26 < promag> no, it's invalid
09:26 < luke-jr> …
09:27 < promag> for instance, -zmqpubrawtx=foo is invalid, not unknown
09:28 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
09:29 < luke-jr> except rpcauth isn't zmqpubrawtx
09:29 < luke-jr> it's a group
09:30 < luke-jr> it also has no effect on startup/running
09:32 < promag> iirc invalid zmqpubrawtx fails init
09:33 < promag> hmm checking
09:34 < luke-jr> as it needs to
09:34 < luke-jr> ZMQ is something that needs to be understood at startup..
09:34 < luke-jr> it actually affects what startup does
09:36 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has joined #bitcoin-core-dev
09:37 < sipa> why would rpcauth be any different?
09:37 < sipa> if software doesn't know what an option means, it should fail
09:37 < luke-jr> it can fail at runtime, for that one user
09:37 < sipa> this seems especially true for something as security-sensitive as rpcauth
09:38 < luke-jr> it can be reasonably assumed that >3 fields would be used for more details in the future
09:39 < sipa> what if the option means "only allowed to run certain RPCs"?
09:39 < luke-jr> that's why it fails at runtime ;)
09:39 < sipa> that seems incredibly annoying
09:39 < luke-jr> how?
09:39 < sipa> "wth is this not working"
09:40 < luke-jr> we don't throw errors if the config file has GUI options, in non-GUI builds..
09:40 < luke-jr> sipa: well, that's why my first PR had an explanatory error..
09:40 < sipa> because they have a known meaning
09:40 < harding> But if the future config says that user foo can only run RPC bar and you use that config with an old node, now user foo can run dumpwallet.  That doesn't sound sane.
09:41 < luke-jr> harding: that's not correct; it will refuse to let user foo do anything
09:41 < sipa> harding: luke-jr's point is that this should be detected, and then refuse *any* RPCs from that user
09:41 < luke-jr> sipa: that's how it always worked, yes
09:41 < sipa> which is not crazy, but still far more annoying than just failing
09:42 < luke-jr> sipa: #20548 would give the user "Invalid rpcauth configuration line" as an error
09:42 < harding> Ok.  Agree that's not insane.
09:42 < gribble> https://github.com/bitcoin/bitcoin/issues/20548 | RPC: Tolerate unknown parameters, but with clear warning/errors by luke-jr · Pull Request #20548 · bitcoin/bitcoin · GitHub
09:42 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
09:46 < luke-jr> sipa: annoying in theory for some corner case that probably has never occurred, perhaps; but the new behaviour is annoying in practice for real users..
09:47 < luke-jr> (or if you want to pretend Knots doesn't exist, it's a lot more realistic a hypothesis to talk about users of a future Core version making use of the 4th+ field)
09:47 < sipa> luke-jr: i don't think the existence of Knots is relevant in this discussion
09:48 < luke-jr> my point is it's a lot more realistic an annoyance to error at startup, than to error at runtime might be in some weird case
09:48 < sipa> i'm not confinced about that
09:48 < luke-jr> k
09:49 < promag> tbh I prefer startup errors
09:49 < luke-jr> err, how not? (sorry, misread "convinced" as "confused")
09:49 < luke-jr> promag: even when it isn't actually an error?
09:50 < luke-jr> users of Core 99.0 intentionally putting these rpcauth lines in their config file, is far more likely than someone putting a truly erroneous line
09:50 < sipa> i can see the argument in favor of instituting a policy that future rpcauth flags are reserved for future restrictions of the permission, and thus that it is safe to treat unknown ones as "act as if the auth line didn't exist"
09:50 < sipa> but that's orthogonal to the question if we should in general aim to reject unknown options
09:51 < luke-jr> and the former would be forced to jump through hoops to workaround the behaviour, where the latter wouldn't really need to do anything different
09:51 < luke-jr> (error at startup vs runtime means the latter needs to fix the problem either way)
09:51 < sipa> yes, but at startup you immediately know the problem is there and fix it
09:52 < sipa> if it happens at runtime it may result in wondering why CoinFancyPoolMixer stopped working
09:52 < luke-jr> but with erroring at startup, the former case has no real solution but to maintain two config files and keep renaming them
09:52 < luke-jr> all to workaround an erroneous error message..
09:52 < sipa> but it's not an erroneous message; if the node can't do what you're asking it to do in the configuration, something is wrong and you need to fix it
09:53 < sipa> as it's won't do what you ask it to do
09:53 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
09:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
10:00 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 246 seconds]
10:03 < luke-jr> [17:49:33] <luke-jr> promag: even when it isn't actually an error?
10:03 < luke-jr> [17:50:15] <luke-jr> users of Core 99.0 intentionally putting these rpcauth lines in their config file, is far more likely than someone putting a truly erroneous line
10:03 < luke-jr> [17:51:17] <luke-jr> and the former would be forced to jump through hoops to workaround the behaviour, where the latter wouldn't really need to do anything different
10:03 < luke-jr> [17:51:34] <luke-jr> (error at startup vs runtime means the latter needs to fix the problem either way)
10:03 < luke-jr> [17:52:15] <luke-jr> but with erroring at startup, the former case has no real solution but to maintain two config files and keep renaming them
10:04 < sipa> if you're going to frequently switch between different versions, it seems entirely reasonable to have 2 config files and use -conf
10:04  * luke-jr peers at freenode
10:05 < sipa> or, more likely, not rely on any features that are only present in one version
10:08 < luke-jr> all the avoid one node restart of some hypothetical guy with a truly erroneous rpcauth line that is unlikely to ever exist…?
10:09 < sipa> no
10:09 < sipa> to make sure that someone who is relying on a future command line option doesn't need to break his head over why it isn't working
10:10 < sipa> i'm talking generically, not specifically about rpcauth
10:11 < promag> I'd bet lots of startups were lost to bad -rpcauth :)
10:12 < luke-jr> I'm starting to like promag's -strict idea
10:12 < sipa> i think that will fail to have the same effect; people just won't turn it on
10:12 < luke-jr> sipa: it could possibly be on by default
10:12 < sipa> that's fair
10:12 < luke-jr> then people who want to switch between versions regularly can just put strict=0 in bitcoin.conf
10:13 < promag> yeah, on by default
10:17 < promag> like gcc -Werror
10:17 < luke-jr> well, -Werror is not on by default :P
10:20 -!- zndtoshi [~zndtoshi@79.112.20.148] has joined #bitcoin-core-dev
10:21 < promag> right, bad example because it is an error in the first place x)
10:22 < luke-jr> promag: so do you want to do the PR, or should I? :p
10:22 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
10:23 < promag> you mean -strict ?
10:23 < luke-jr> yes
10:24 < promag> hmmm
10:26 < promag> :) I mean, if it gets concept ack why not, it could be discussed in the meeting
10:26 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
10:27 -!- Pavlenex [~Thunderbi@178.220.103.52] has quit [Quit: Pavlenex]
10:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:39 < bitcoin-git> [bitcoin] sdaftuar opened pull request #20561: p2p: periodically clear m_addr_known, and choose new peers to receive relayed addresses (master...2020-12-moar-addrz) https://github.com/bitcoin/bitcoin/pull/20561
10:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:45 -!- adiabat [~adiabat@63.209.32.102] has quit [Ping timeout: 260 seconds]
10:50 < jnewbery> luke-jr: not trolling. If a PR is opened where the goal is primarily to make things easier for downstream projects, then (1) that should be explicitly declared in the PR description (2) it should be judged for inclusion in Bitcoin Core solely on whether it's a benefit to the users of this project.
10:52 < wumpus> agreed...
10:58 < luke-jr> jnewbery: that wasn't even the case here
10:59 < wumpus> what is this altnerative syntax that you introduced in a downstream project anyway?
11:00 < jonatack> meeting?
11:00 < achow101> meeting?
11:00 < sipa>     meeting?
11:00 < wumpus> we could, I guess, ignore alternative syntax that we know about and don't support, though it's a bit strange
11:00 < wumpus> but it's better than ignoring all errors
11:00 < wumpus> #startmeeting
11:00 < core-meetingbot> Meeting started Thu Dec  3 19:00:38 2020 UTC.  The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
11:00 < core-meetingbot> Available commands: action commands idea info link nick
11:00 < jonasschnelli> hi
11:00 < jonatack> hi
11:00 < promag> howdy
11:00 < hebasto> hi
11:00 < jnewbery> hi
11:00 < wumpus> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
11:01 < wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
11:01 < luke-jr> wumpus: #10615 has supported a 4th field with a wallet name
11:01 < gribble> https://github.com/bitcoin/bitcoin/issues/10615 | RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet by luke-jr · Pull Request #10615 · bitcoin/bitcoin · GitHub
11:01 < achow101> hi
11:01 < wumpus> luke-jr: oh okay, so separate access control per wallet
11:01 < amiti> hi
11:01 < fjahr> hi
11:01 < sipa>  hi
11:02 < luke-jr> wumpus: yes; not sure what else it could be used for, but the behaviour of rejecting the line (at runtime) should be generally safe
11:02 < aj> hi
11:02 < luke-jr> hi
11:02 < wumpus> two proposed topics for today: rc3, 0.19 release, 0.20 release (marcofalke), bitcoin-util cli utility for 19937 (aj)
11:03 < MarcoFalke> hi
11:03 < luke-jr> wumpus: maybe should add -strict if we have time
11:03 < jonasschnelli> #19937
11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/19937 | signet mining utility by ajtowns · Pull Request #19937 · bitcoin/bitcoin · GitHub
11:03 -!- jesseposner [~jp@2601:643:8980:bfd2:21a3:28f3:d78:7f10] has joined #bitcoin-core-dev
11:03 < wumpus> any last minute topics anyone wants to discuss?
11:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Read error: Connection reset by peer]
11:04 < wumpus> #topic High priority for review
11:04 < core-meetingbot> topic: High priority for review
11:04 < wumpus> https://github.com/bitcoin/bitcoin/projects/8  11 blockers, 2 chasing concept ACK
11:05 < jonatack> can rm #20483
11:05 < gribble> https://github.com/bitcoin/bitcoin/issues/20483 | wallet: deprecate feeRate in fundrawtransaction/walletcreatefundedpsbt by jonatack · Pull Request #20483 · bitcoin/bitcoin · GitHub
11:06 < wumpus> jonatack: done
11:06 < MarcoFalke> I'd like to switch mine out for #20362 
11:06 < gribble> https://github.com/bitcoin/bitcoin/issues/20362 | test: Implicitly sync after generate* to preempt races and intermittent test failures by MarcoFalke · Pull Request #20362 · bitcoin/bitcoin · GitHub
11:06 < jonatack> (it can't go in until we have estimatefeerate / setfeerate)
11:06 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
11:06 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Quit: Leaving]
11:07 < wumpus> MarcoFalke: done
11:07 < wumpus> jonatack: yes, makes sense
11:07 < MarcoFalke> thx
11:07 < jonatack> (e.g. sat/vB versions of settxfee and estimatesmartfee)
11:08 < wumpus> anything else to add/remove? or that's ready to merge?
11:08 < wumpus> #19937 is already a topic in itself
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/19937 | signet mining utility by ajtowns · Pull Request #19937 · bitcoin/bitcoin · GitHub
11:09 < hebasto> jnewbery: kindly reminder to rebase #19910
11:09 < gribble> https://github.com/bitcoin/bitcoin/issues/19910 | net processing: Move peer_map to PeerManager by jnewbery · Pull Request #19910 · bitcoin/bitcoin · GitHub
11:09 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
11:09 < jnewbery> hebasto: thanks. Will do!
11:10 < wumpus> #topic rc3, 0.19 release, 0.20 release (marcofalke)
11:10 < core-meetingbot> topic: rc3, 0.19 release, 0.20 release (marcofalke)
11:10 < MarcoFalke> ok, 0.19 first. Are we going to tag a release?
11:11 < MarcoFalke> https://github.com/bitcoin/bitcoin/milestone/46 is empty
11:11 < wumpus> sounds fine to me
11:11 < MarcoFalke> if yes, are we going to gitian build?
11:11 < luke-jr> might as well do a rc1 at least
11:11 < wumpus> I think that's what he means, tag rc1
11:11 < luke-jr> whether there will be enough people who test it to warrant a final, dunno
11:12 < wumpus> well we can tag it we'll see if people care about building it
11:12 < luke-jr> looks like 0.19 is still pretty common use
11:12 < MarcoFalke> Ok, so it seems 0.19.2rc1 soon
11:12 < luke-jr> ~12% of the network
11:12 < MarcoFalke> Then 0.20
11:12 < wumpus> not really something I care about but tagging isn't much work 
11:12 < wumpus> 0.20 on the other hand
11:13 < MarcoFalke> https://github.com/bitcoin/bitcoin/milestone/49
11:13 < MarcoFalke> There is one issue, hasen't gotten more review
11:13 < MarcoFalke> What to do about that?
11:13 < MarcoFalke> outstanding thing is #19740 
11:13 < gribble> https://github.com/bitcoin/bitcoin/issues/19740 | [0.20] wallet: Simplify and fix CWallet::SignTransaction by achow101 · Pull Request #19740 · bitcoin/bitcoin · GitHub
11:13 < luke-jr> most 0.19 nodes are 0.19.0.1 still
11:14 < hebasto> if 0.21 is around the coner is 0.19.2 really needed?
11:14 < MarcoFalke> hebasto: At least the tag, so that people building from source can use it
11:14 < luke-jr> hebasto: doesn't hurt
11:14 < hebasto> ok
11:14 < MarcoFalke> the branch will be deleted eventually, so a tag also helps to archive the latest branch
11:15 < wumpus> looks like 19740 has some difficulty getting review, please focus on that, 0.20 is much more relevant
11:15 < hebasto> MarcoFalke: I see
11:15 < MarcoFalke> does 19740 warrant holding back 0.20.2?
11:15 < wumpus> maybe we should add it to high prio
11:15 < luke-jr> probably not
11:15 < wumpus> achow101: here?
11:16 < MarcoFalke> I think we should ping reviewers directly
11:16 < luke-jr> IIRC I hit the bug only by some corner case
11:16 < achow101> MarcoFalke: IMO yes. it's a pretty significant bug
11:16 < MarcoFalke> achow101: Any suggestions who could review it?
11:17 < achow101> meshcollider and ryanofsky at least
11:17 -!- adiabat [~adiabat@63.209.32.102] has joined #bitcoin-core-dev
11:17 < wumpus> it's ony a change in one function, a very important one though
11:17 < MarcoFalke> I checked that the function content is copied from master, that is easy to check
11:17 < achow101> and anyone who reviewed the changes leading up to descriptor wallets
11:18 < MarcoFalke> what is the worst thing that could happen? I guess a tx could come back unsigned?
11:18 < achow101> yes
11:20 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
11:20 < wumpus> the functional tests should catch that though
11:20 < MarcoFalke> SignTransaction is marked const, so it shouldn't modify the spkm either
11:21 < achow101> the bug was that a fully signed tx would come back as supposedly not complete, although nothing would change in that tx
11:21 < MarcoFalke> Seems almost safe to merge as-is (famous last words?)
11:21 < jonatack> nice simplification, surprising that no tests need to be updated if something was broken
11:21 < achow101> given that 0.20 only has the LegacySPKM implemented, I think this could be trivially correct?
11:22 < wumpus> jonatack: right seems there's no test for the fixed behavior
11:22 < wumpus> in any case if it's 'trivially correct' I'd like to see some ACKs soon :)
11:22 < jonatack> a description of what was broken/fixed in the PR or commit would be nice
11:23 < achow101>  #17204 apparently tests this kind of accidentally
11:23 < gribble> https://github.com/bitcoin/bitcoin/issues/17204 | wallet: Do not turn OP_1NEGATE in scriptSig into 0x0181 in signing code (sipa) by meshcollider · Pull Request #17204 · bitcoin/bitcoin · GitHub
11:24 < wumpus> would be worth a try then maybe
11:24 < MarcoFalke> #action tag 0.19.2rc1 now , tag 0.20.2rc1 after 19740
11:24 < core-meetingbot> ACTION: tag 0.19.2rc1 now , tag 0.20.2rc1 after 19740
11:25 < MarcoFalke> ok, finally rc3
11:25 < MarcoFalke> Anything missing for rc3?
11:25 < jnewbery> is there definitely going to be an rc3?
11:25 < sipa> short topic: can people read over https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.21.0-Release-Notes-Draft? i think a few things are missing
11:25 < wumpus> do we have any serious issues reported for rc2 yet?
11:25 < MarcoFalke> https://github.com/bitcoin/bitcoin/milestone/45
11:26 < MarcoFalke> jnewbery: Yes, stuff has been merged, so there must be one
11:26 < wumpus> did we merge stuff? oh
11:26 < jonatack> achow101: you mean the test I added in 17204? That PR was a bit of a head-scratcher tbh
11:26 < sipa> #20511: i think we should drop it for 0.21
11:26 < gribble> https://github.com/bitcoin/bitcoin/issues/20511 | anchors.dat doesnt support V2 addresses · Issue #20511 · bitcoin/bitcoin · GitHub
11:27 < MarcoFalke> merged stuff: https://github.com/bitcoin/bitcoin/commits/0.21
11:27 < sipa> it's harder to fix than i initially imagined, and anchors.dat didn't exist at all so it's a new feature anyway
11:27 < wumpus> did we have any regressions then?
11:27 < sdaftuar> what's the status of sendaddrv2/bip155, there was a report that it caused other peers to disconnect us i think?
11:27 < luke-jr> couldn't anchors.dat store all V2 then?
11:27 < jnewbery> sipa: I removed #20511 from the milestone
11:27 < gribble> https://github.com/bitcoin/bitcoin/issues/20511 | anchors.dat doesnt support V2 addresses · Issue #20511 · bitcoin/bitcoin · GitHub
11:28 < MarcoFalke> sdaftuar: Yes, the protocol version wasn't bumped, and some peers use the protocol version to determine which message types are "expected"
11:28 < sipa> sdaftuar: you mean gating it based on protocol version?
11:29 < sdaftuar> yes, that
11:29 < jnewbery> If we're doing an rc3, then I think we should merge a change to only send sendaddrv2 to peers on v70016+
11:29 < wumpus> my initial proposal was to increase the protocol version but this was almost universally hated
11:29 < sipa> we did bump the version number anyway, right?
11:29 < MarcoFalke> is 70016 the version of wtxidrelay?
11:29 < jnewbery> and if we're doing that (which means changing the code and spec), then we should also move it to be done between version and verack like wtxidrelay
11:29 < wumpus> everyone wanted some other mechanism
11:29 < sipa> wumpus: this isn't about protocol version vs sendaddrv2; it's about using protocol version to know whether "sendaddrv2" is a legal message
11:29 < wumpus> so where is it given problems?
11:30 < sdaftuar> i think the feedback from maintainers of other software was a preference to bump the version numbers when we roll out new messages like this, since that is easy, i think we should
11:30 < wumpus> we don't have *any* mechanism like that
11:30 < jnewbery> wumpus: btcd drops the connection if it receives a sendaddrv2
11:30 < wumpus> that's their problem
11:30 < MarcoFalke> libbitcoin might, too
11:30 < sipa> wumpus: i agree it's silly
11:30 < wumpus> we've always ignored unknown messages
11:30 < wumpus> and that's how it should be 
11:31 < wumpus> it was always the idea that new messages could be used as an extension mechanism
11:31 < hebasto> ^^^ isn't this rule a part of ptotocol?
11:31 < sipa> apparently historically new messages have always been accompagnied with a protocol bump; i'm kind of surprised by this, as it forces serialized coordination for adding new messages
11:31 < wumpus> sipa: exactly
11:31 < sipa> hebasto: "the protocol" will differ depending on who you ask
11:31 < wumpus> it shouldn't be like that in a decentralized protocol
11:32 < luke-jr> NACK bullying other implementations on the p2p protocol
11:32 < wumpus> I'm pretty sure we've added messages before without increasing the version
11:32 < luke-jr> though I agree it's a dumb idea to force protocol version increments like this
11:32 < wumpus> "bullying" wtf
11:32 < wumpus> come on
11:32 < MarcoFalke> incrementing the protocol version number doesn't mean p2p dev is centralized
11:32 < luke-jr> wumpus: causing them to disconnect when we could easily remain compatible?
11:32 < sipa> i don't think this is bullying; it's a disagreement about what the protocol entails
11:33 < wumpus> luke-jr: it was their choice to disconnect on a silly reason like that
11:33 < sdaftuar> whatever we decide to do, i think the updated bip that describes what we do should be reposted to the mailing list
11:33 < aj> btcd would stay connected to 0.20 and earlier nodes so won't drop off from the network entirely, no? is this that big a problem?
11:33 < luke-jr> wumpus: this isn't their change
11:33 < wumpus> in any case my first proposal for the BIP was to do it with a version bump
11:33 < wumpus> but no one wanted it and now suddenly ...
11:33 < jonasschnelli> Was/is there a reason to _not_ bump the protocol version for addr2?
11:33 < wumpus> just because some other imnplementation does something weird
11:33 < jonasschnelli> like it was done for sendheaders BIP 130
11:33 < MarcoFalke> wumpus: Yes, I think it wasn't clear that btcd and libbitcoin did that
11:33 < wumpus> I honestly don't know
11:34 < sipa> wumpus: oh, another minor point is that the bip and the implementation currently mismatch
11:34 < MarcoFalke> wumpus: I just learned about that last week
11:34 < wumpus> I'm not going to reconsider based on that anyway
11:34 < sipa> wumpus: about a related thing
11:34 < sipa> the bip says send sendaddrv2 after receiving verack, but the implementation sends it after sending verack
11:34 < luke-jr> right now, the network is all talking fine; Core intentionally deploying a change that breaks it seems wrong
11:35 < Victorsueca> ´causing them to disconnect when we could easily remain compatible?´ < The reverse could also be said, causing us to implement things in a specific way when they could easily ignore the messages?
11:35 < wumpus> so they don't plan on implementing addrv2 at all?
11:35 < wumpus> let's just drop it
11:35 < sipa> wumpus: what?
11:35 < sipa> they're just concerned because their _old_ versions can't talk to new core anymore
11:36 < wumpus> sipa: Im ean if no one else wants to move forward on that
11:36 < jonasschnelli> why not just bump the protocol version?
11:36 < wumpus> or maybe don't send addrv2 to ipv4 and ipv6 nodes at all
11:36 < wumpus> they don't care about the other networks
11:37 < sdaftuar> i'm a bit confused. the only question is whether to send the "sendaddrv2" message on startup?
11:37 < luke-jr> they might
11:37 < MarcoFalke> I think for rc3 we should aim for a minimal fix (or no fix at all)
11:37 < MarcoFalke> I liked jnewbery's suggestion
11:37 < MarcoFalke> I suspect that can be implemented with a one-line patch
11:37 < jnewbery> It's really just a very small fix, moving a few lines of code
11:37 < jnewbery> and updating the BIP to match
11:38 < wumpus> but addrv2 isn't bound to any protocol version
11:38 < hebasto> but we bumper protocol version due to new wtxidrelay message
11:38 < wumpus> it shouldn't be
11:38 < hebasto> #18044
11:38 < sipa> that part doesn't even need a bip change; we can just as courtesy decide to not send sendaddrv2 below a certain protocol version, because we know locally that things with lower protocol version don't support it anyway
11:38 < wumpus> it's silly to do this now in a last minute rc chang
11:38 < gribble> https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar · Pull Request #18044 · bitcoin/bitcoin · GitHub
11:38 < sipa> wumpus: yeah...
11:38 < jnewbery> wumpus: i'm confused. You said earlier you wanted it to be done with a version bump
11:38 < wumpus> jnewbery: at the time, yes
11:39 < luke-jr> anyone want to throw together a BIP saying the same protocol version bump also implies unknown messages are ignored? ;)
11:39 < MarcoFalke> and the workaround can be removed later on
11:39 < wumpus> then we spent months discussing it and no one else wanted it
11:39 < sipa> luke-jr: good luck opening that can of worms again
11:39 < luke-jr> though I suspect libbitcoin will disagree with that BIP
11:39 < wumpus> because it was so much easier to do it without a version bump
11:39 < jnewbery> wumpus: why is it easier?
11:39 < sdaftuar> luke-jr: i proposed something similar recently, and then withdrew it after opposition on the mailing list
11:39 < wumpus> because agreeing on a version bump is hard ESPECIALLY BETWEEN IMPLEMENTATIONS
11:39 < luke-jr> sigh
11:40 < wumpus> just adding an identification message allowed for a mechanism to extend the protocol without a central point of agreement !
11:40 < wumpus> this doensn't bind it together with other protocol changes
11:40 < sipa> wumpus: well, i fully agree
11:41 < wumpus> so implemetnations can implement and relay v2 without implementing other protocol changes
11:41 < wumpus> so many people told this to me
11:41 < sipa> but isn't it reasonable to try to not break things on the existing network, regardless of who is at fault for it?
11:41 < jonasschnelli> I agree. IMO it should be handled on the side of btcd/libbitcoin. Dropping on unknown messages makes backward compatibility just insanely hard.
11:41 < wumpus> yes
11:41 < luke-jr> jonasschnelli: can't change deployed nodes
11:42 < jonasschnelli> Sure you can
11:42 < luke-jr> …
11:42 < jonasschnelli> by upgrading
11:42 < sipa> jonasschnelli: ?
11:42 < jonasschnelli> I guess a fix send a wrong signal
11:42 < aj> or by adding a compatability node in between
11:42 < MarcoFalke> Maybe we shouldn't modify the bip, but add a temporary patch to be able to speak to non-upgraded nodes
11:42 < sipa> i'm happy to reach out to btcd and tell them this is silly, and we don't think it makes sense to continue this... but in order not to break their existing nodes, we'll not send sendaddrv2 to older versions this one time
11:42 < sipa> MarcoFalke: that's my suggestion
11:43 < luke-jr> what about libbitcoin which fundamentally disagrees with us?
11:43 < jonasschnelli> Probably an adequate trade-off. There is just the risk our codebase will have many workaround in the future to protect falling alternative implementations
11:43 < sipa> i can't comprehend their stance
11:43 < wumpus> as ssaid we don't need this for ipv4/ipv6 nodes
11:43 < luke-jr> sipa: I suspect it's just disagreement for the sake of disagreement :/
11:43 < MarcoFalke> luke-jr: I think that can be hashed out on the mailing list
11:44 < wumpus> maybe I made a mistake to try this at all
11:44 < MarcoFalke> no need to block rc3 on resolving that discussion
11:44 < sipa> wumpus: we do want torv3 addresses to relay across ipv4/ipv6 nodes
11:44 < jonasschnelli> wumpus: no you didn't
11:44 < luke-jr> MarcoFalke: true
11:44 < jonasschnelli> It's clearly a missimplementation
11:44 < sipa> wumpus: indeed you don't- i think there are just misunderstandings about what the protocol entails
11:44 < sipa> and it's unfortunate that this comes out now
11:45 < wumpus> mostly sorry for vasild who did all the actual implementation work
11:45 < luke-jr> jonasschnelli: it's intentional, so not mis-
11:45 < jonatack> is there a post on the btcd/libbitcoin position and plans? seems quite late
11:45 < jonasschnelli> are they (btcd) dropping on any unknown message?
11:45 < jonasschnelli> or to they just pin valid message to protocol versions?
11:45 < wumpus> jonatack: yes, why does this come up last minute? between rcs?
11:45 < MarcoFalke> wumpus: I think it was the right choice, and everyone agreed with you. the mismatch on the live network was just not anticipated back then.
11:46 < sipa> wumpus: well that's when people test
11:46 < sdaftuar> i am not sure an updated version of bip155 was ever sent to the mailing list describing that the version bump was being dropped. so it's hard to blame them, imo, other than for a long-running misunderstanding of how we think unknown messaegs should be treated
11:46 < luke-jr> sdaftuar: we also have no authority to impose BIP155 on them anyway
11:46 < sdaftuar> luke-jr: agreed
11:46 < sipa> sdaftuar: i think the initial discussion was about version bump vs sendaddrv2 as the negotiation mechanism itself
11:46 < MarcoFalke> (we still have one more topic, so we should slowly wrap up)
11:46 < wumpus> they're free to not implement it, but disconnecting just doens't make sese
11:47 < wumpus> there's no question of "authority" here
11:47 < wumpus> they're preventing us from implementing new messages
11:47 < wumpus> sipa: yes
11:47 < luke-jr> well, preventing it from being implemented nicely anyway
11:48 < sipa> wumpus: yes, agree, i believe that going forward using new messages is absolutely the right way, not tied to protocol version
11:48 < wumpus> it's enforcing authority by denying the upgrade method of introducing new messages
11:48 < sdaftuar> sipa: was that discussion on hte mailing list? 
11:48 < wumpus> because everyone needs to agree on new version numbers then
11:48 < wumpus> and what messages come with them
11:48 < sipa> wumpus: but it's kind of similar to "don't break userspace" in linux's philosophy... somehow someone ended up relying on something that wasn't guaranteed; we can be courteous and make sure it doesn't cause problems
11:49 < wumpus> this is not accetpable for a protocol that is not centrally coordinated
11:49 < sipa> https://github.com/btcsuite/btcd/issues/1661
11:49 < jonasschnelli> same with the service bits (a bit more flexible)
11:49 < wumpus> if there was some organization like IANA it'd be different
11:50 < MarcoFalke> there is still the "central" BIP repo
11:50 < sipa> looks like they were just completely unaware that ignoring unknown messages was the right thing to do, but are ok with ignoring unknown messages otherwise
11:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:50 < bitcoin-git> [bitcoin] achow101 opened pull request #20562: tests: Test that a fully signed tx given to signrawtx is unchanged (master...test-signraw-fullysigned) https://github.com/bitcoin/bitcoin/pull/20562
11:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:50 < luke-jr> IANA and BIPs aren't that different
11:50 < luke-jr> sipa: that's just btcd though; IIRC, libbitcoin disagrees explicitly
11:50 < wumpus> MarcoFalke: well, yes, but a lot of things get accepted as BIP, not only if they're really implemented
11:51 < jonasschnelli> indeed.
11:51 < MarcoFalke> as long as the bip process doesn't allow duplicate assignments, it shouldn't lead to issues
11:51 < wumpus> I mean 'accepted as BIP' as in merged to the repository
11:51 < jonasschnelli> Overlap of version numbers might happen quicky
11:51 < wumpus> it only has to ofllow basic protocol for that
11:51 < luke-jr> MarcoFalke: well, it does even then
11:51 < MarcoFalke> (not advocating for it, just saying it is possible)
11:51 < wumpus> it's not a real selection process
11:51 < luke-jr> if ver 100 defines X, and ver 101 defines Y, now everyone who wants Y needs X
11:51 < wumpus> nor a central coordination
11:51 < aj> luke-jr: needs X or needs to successfully ignore X
11:51 < MarcoFalke> luke-jr: it would be on top of the negotiation message type
11:52 < luke-jr> aj: good point
11:52 < jonasschnelli> define a protocol version where tolerating unknown message is a must?
11:52 < sipa> jonasschnelli: that's what sdaftuar tried
11:52 < wumpus> jonasschnelli: heh, use the reasoning against themselves
11:52 < jonasschnelli> I see
11:53 < luke-jr> jonasschnelli: but they will reject the BIP defining it
11:53 < wumpus> I'm pretty tired of this
11:53 < jonasschnelli> well,.. then it should be their mess to clean up?
11:53 < sipa> we don't need their consent to implement anything
11:53 < sipa> but we can take discussion points into accoutn
11:53 < sdaftuar> jonasschnelli: see thread starting here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018084.html
11:54 < wumpus> could freeze the current P2P network and define a new one :)
11:54 < sdaftuar> i think we should just decide what we want to do and let everyone know what that is
11:54 < luke-jr> jonasschnelli: that implies we have authority to impose this on them?
11:54  * sipa points at BIP324
11:54 < wumpus> with jonasschnelli 's encryption and stuff
11:54 < luke-jr> oooh good idea
11:54 < jonasschnelli> yes. That will be a nightmare
11:54 < aj> luke-jr: can't impose anything on them, they can keep disconnecting if they think that's desirable
11:54 < luke-jr> ?
11:54 < luke-jr> jonasschnelli: make the ignoring unknown msgs part of it
11:54 < wumpus> the old one will still work and it's entirely voluntary to implement it *shrug*
11:55 < jonasschnelli> Its not even messages in BIP324,.. its the handshake that is headerless
11:55 < aj> wumpus: bender meme, we'll make our own p2p with encryption and blow?
11:55 < jonasschnelli> agree with sdaftuar 
11:55 < wumpus> I really don't want these kind of questions about authority, no one needs authority to do anything, that's not the point
11:55 < wumpus> aj: yess
11:55 < jonasschnelli> aj: heh. Yes.
11:55 < aj> blackjack and encryption apparently
11:56 < wumpus> and permissionlessness
11:56 < luke-jr> wumpus: when existing nodes on the network stop working because of a change we make, it takes authority to say that the blame is on someone else..
11:56 < aj> 4min left if we want to quickly discuss bitcoin-util
11:56 < wumpus> #topic bitcoin-util (aj)
11:56 < core-meetingbot> topic: bitcoin-util (aj)
11:56 < MarcoFalke> #action bender meme, we'll make our own p2p with encryption and blow?
11:56 < core-meetingbot> ACTION: bender meme, we'll make our own p2p with encryption and blow?
11:56 < wumpus> aj: sorry
11:56 < aj> #19937
11:57 < jonasschnelli> BIP324 is probably different since we want to get disconnected when the handshake is not supported
11:57 < gribble> https://github.com/bitcoin/bitcoin/issues/19937 | signet mining utility by ajtowns · Pull Request #19937 · bitcoin/bitcoin · GitHub
11:57 < MarcoFalke> aj: I still don't get why it needs a new way of parsing args
11:57 < aj> signet mining has high enough difficulty that grinding in python doesn't work. but gridning needs libconsensus code so can't be stuck in bitcoin-cli without bloating it
11:57 < MarcoFalke> this is just asking for an unmaintaible mess if new features are added
11:58 < aj> bitcoin-util as a generic thing has been proposed in #14671 iirc for doing things like psbt without needing a running node
11:58 < gribble> https://github.com/bitcoin/bitcoin/issues/14671 | Utility to replace RPC calls that dont need wallet or chain context · Issue #14671 · bitcoin/bitcoin · GitHub
11:58 < MarcoFalke> ACK on adding the utility in general
11:58 < wumpus> python bindings for libconsensus 
11:58 < sipa> aj: any reason why it can't be an RPC?
11:58 < MarcoFalke> sipa: I asked that too
11:58 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]
11:58 < sipa> (i know it doesn't *need* to be an RPC, but in this specific case, is there a reason why that'd be problematic)
11:59 < aj> sipa: 14671 talks about not adding RPCs for utility functions in general, and having a separate command for that
11:59 < sipa> ok
11:59 < sipa> That's fair
11:59 < wumpus> I guess the drawback is adding yet another executable, which links in a lot of stuff, but if we have other plans for bitcoin-util apart from just the signet grinding it may be worth it
11:59 < aj> sipa: could be, but would be a bit weird. no specific problem i thnk. making "generate" just work is a pain since signet signing needs a wallet
12:00 < MarcoFalke> aj: If someone already has the server running, it might be faster to call the rpc instead of figuring out how to run the util
12:00 < aj> wumpus suggested adding it to bitcoin-tx which works fine (it already links libconsensus), but is klunky
12:00 < wumpus> it's too bad we already have bitcoin-tx with the same (in)dependency idea
12:00 < wumpus> yes
12:00 < andytoshi> in elements we had this issue with our signed blocks, we had to back out some of the separation between wallet and node
12:00 < andytoshi> which i was not happy about
12:00 < aj> might make sense to do it in bitcoin-tx now, and have a new PR later that adds bitcoin-util with multiple functionality bits (and better arg handling like MarcoFalke suggests)
12:00 < andytoshi> and i wish we didn't have that RPC. fwiw.
12:01 < sipa> andytoshi: that's useful information
12:01 < wumpus> aj: I don't particularly need to have that intermediate state FWIW
12:01 < wumpus> aj: if there are plans for bitcoin-util it's okay with me
12:01 < andytoshi> esp as, in practice, the requirements for a blocksigner are different from the requirements for a generic wallet, so probably signers would want their own sepaarte software anyway. the RPC is mostly just good for testing
12:01 < MarcoFalke> the private keys could be passed in to the grind command. *hides
12:01 < wumpus> aj: and yes, it needs to use the same argument handling as our other binaries
12:02 < sipa> aj: btw, why is the difficulty too high for python? you control the difficulty yourself, no?
12:02 < luke-jr> separate repo that runs a temporary bitcoind, runs a RPC, and exits? :P
12:02 < sipa> also have you tried pypy?
12:02 < sipa> it tends to be several times faster for things like this
12:02 < wumpus> we definitely don't want to use differnt argument handling between binaries
12:02 < aj> sipa: min difficulty for signet is higher than original because the retarget calculations don't work right for particularly high targets
12:02 < sipa> ha
12:03 < aj> sipa: pypy is faster, but not crazy faster and it makes it more complicated to run
12:04 < sipa> aj: what is the effective min difficulty?
12:04 < wumpus> you can load libconsensus using ctypes
12:04 < wumpus> *ducks*
12:04 < luke-jr> if libconsensus works, the util should be a separate repo ;)
12:05 < sipa> libconsensus doesn't do mining; you'd still be calling python->c++ for every individual hash attempt
12:05 < wumpus> (ctypes works very well I've used it in the past for python bindings)
12:05 < sipa> pretty sure that's going to be slower than the actual time spent hashing
12:05 < wumpus> huh yes
12:05 < MarcoFalke> *libbitcoinkernel
12:05 < luke-jr> doesn't Python have its own hashing stuff?
12:05 < aj> doesn't have double sha256
12:06 < wumpus> yes, python has its own hashing stuff, but appearntly it's too slow
12:06 < luke-jr> maybe just do it in C then?
12:06 < luke-jr> libblkmaker has a straightforward example.c
12:06 < luke-jr> that could be extended
12:06 < wumpus> yes, loading shared libraries from python is straightforward
12:07 < wumpus> ok, time to end the meeting I think
12:07 < wumpus> #endmeeting
12:07 < 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
12:07 < core-meetingbot> Meeting ended Thu Dec  3 20:07:40 2020 UTC.  
12:07 < core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2020/bitcoin-core-dev.2020-12-03-19.00.moin.txt
12:07 < jonatack> bitcoin-util SGTM
12:08 < achow101> re #19740, i've updated the description and added a specific test case
12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/19740 | [0.20] wallet: Simplify and fix CWallet::SignTransaction by achow101 · Pull Request #19740 · bitcoin/bitcoin · GitHub
12:08 < aj> so conclusion is stick with -util and fix up marcofalke's arg handling objections?
12:08 < jonatack> sipa: thanks for the link to the btcd issue
12:08 < luke-jr> example.c is 135 lines and mines a block from a GBT template
12:08 < wumpus> even better, shared libraries have less call overhead than a separate process
12:08 < sipa> aj: seems reasonable to me
12:08 < aj> luke-jr: there's also the nbits to target and comparison against target stuff that arith_uint256 currently handles
12:09 < luke-jr> aj: true
12:09 < aj> wumpus: shared libraries seem like it'd be a super pita to make work for people running mac and windows?
12:10 < wumpus> aj: why?
12:10 < wumpus> aj: windows has dlls and mac simply has so's
12:10 < aj> wumpus: everything seems like a pain for mac and windows? i don't know :)
12:10 < luke-jr> dunno about mac, but it's even easier on Windows
12:10 < luke-jr> Windows will prefer a DLL in your working directory ;)
12:10 < wumpus> windows has a better shared library implementatin than POSIX imo *ducks*
12:10 < MarcoFalke> #20483 is also tagged for 0.21.0
12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/20483 | wallet: deprecate feeRate in fundrawtransaction/walletcreatefundedpsbt by jonatack · Pull Request #20483 · bitcoin/bitcoin · GitHub
12:11 < luke-jr> wumpus: well, Windows has no way out of DLL hell system-wide
12:11 < MarcoFalke> is  20483 needed?
12:12 < jonatack> MarcoFalke: for 0.21 I agree with your review, it seems too late as the current plan is to not merge it until estimatefeerate/setfeerate in sat/vB
12:12 < luke-jr> yeah, too late for 0.21 IMO
12:12 < jonatack> based on the discussion in luke-jr's estimatesmartfee PR
12:13 < jonatack> yeah
12:13 < wumpus> luke-jr: I'm very much exagaratting, what I like about windows is their separation between link libraries (.lib) and the dlls themselves, the versioning stuff is much worse on windows
12:14 < wumpus> jonatack: ok let's remove it then
12:14 < MarcoFalke> ok, removed milestone on #20483 
12:14 < gribble> https://github.com/bitcoin/bitcoin/issues/20483 | wallet: deprecate feeRate in fundrawtransaction/walletcreatefundedpsbt by jonatack · Pull Request #20483 · bitcoin/bitcoin · GitHub
12:15 < wumpus> I think we should only tag regression fixes for 0.21 for now
12:16 < MarcoFalke> So I guess #19362 will go away too?
12:16 < gribble> https://github.com/bitcoin/bitcoin/issues/19362 | rpc/blockchain: Reset scantxoutset progress before inferring descriptors by prusnak · Pull Request #19362 · bitcoin/bitcoin · GitHub
12:17 < wumpus> I guess so, especially as there is still discussion in the PR what way to go
12:18 < wumpus> it's fine for backport -- for 0.21.1
12:19 < wumpus> I mean, not everything that could be backported to 0.21 needs to go in between rcs
12:21 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:23 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
12:33 -!- sunweaver1 [~sunweaver@185.163.110.125] has quit [Remote host closed the connection]
12:35 -!- davterra [~davterra@static-198-54-131-92.cust.tzulo.com] has joined #bitcoin-core-dev
12:38 -!- tralfaz [~davterra@static-198-54-131-92.cust.tzulo.com] has quit [Ping timeout: 256 seconds]
13:04 -!- murch [murch@2a01:4f8:141:1272::2] has quit [Read error: Connection reset by peer]
13:24 -!- mdrjr1 [~mdrjr@178.239.168.171] has joined #bitcoin-core-dev
13:33 -!- Pavlenex [~Thunderbi@178.220.68.122] has joined #bitcoin-core-dev
13:34 < vasild> Is there any email post, chat message or anything from btcd or libbitcoin on sendaddrv2? I think is it ok to proceeed with 0.21 as it is now in current master because as mentioned above agreeing on a protocol version is indeed too centralized. What if there are 7 implementations and they never agree?
13:34 < luke-jr> vasild: uh, as things are now, we have *disagreement*
13:35 < vasild> The first response by somebody to https://github.com/btcsuite/btcd/issues/1661 is 19 days (!?) after the bug was opened
13:35 < luke-jr> breaking the network and blaming others is even more centralised
13:35 < luke-jr> vasild: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018088.html
13:36 < vasild> luke-jr: thanks, I will read and followup tomorrow
13:37 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
13:41 < wumpus> yes, breaking the network would be a bad thing
13:43 < wumpus> i don't think torv3 support is more important than breaking the network, if push comes to shove they win
13:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:46 < bitcoin-git> [bitcoin] hebasto opened pull request #20563: build: Check that Homebrew's berkeley-db4 package is actually installed (master...201203-bdb) https://github.com/bitcoin/bitcoin/pull/20563
13:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:47 < wumpus> do they have a proposal to support torv3? or is that just not important
13:47 < luke-jr> wumpus: I think they just want the protocol number bumped
13:47 < wumpus> I could see how it would be beneficial to some parties to break tor hidden service support
13:48 < sipa> wumpus: the discussion there isn't about addrv2 at all, but in general (and started by the wtxid discussion)
13:48 < wumpus> it wouldn't be so much of a hurry if v2 support wasn't deprecated
13:49 < sipa> and in any case it's a minor thing - it's not like the entire network is suddenly going to run 0.21
13:49 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Remote host closed the connection]
13:49 < wumpus> sipa: so essentailly this means that clients before that version (and implement *all* its features) could never support torv3 relaying
13:50 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
13:50 < sipa> wumpus: well the last few years at least all new features have used a combination of protocol version bump that triggers a "sendFEATURE" message
13:50 < wumpus> which means they can't support tor hidden services at all anymore in short time
13:50 < wumpus> period
13:50 < luke-jr> wumpus: from my understanding, libbitcoin's vision is that every new feature bumps the version number *and* negotiates availability
13:51 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:51 < sipa> wumpus: so really all that a version bump does is "sendaddrv2 and addrv2 now exist" - if they're not negotiated they'll still not be used
13:51 < wumpus> it was already short while and I'm very disappointed people try to sabotage this
13:51 < luke-jr> so you could support the latest version number by simply ignoring the negotiation of everything
13:51 < sipa> wumpus: there are two separate discussions here
13:51 < wumpus> just send version number 9999999
13:51 < sipa> wumpus: the libbitcoin one, which was related to wtxid relay
13:51 < luke-jr> XD
13:52 < wumpus> deprecate protocol version numbers
13:52 < sipa> and now the btcd disconnecting when sendaddrv2 is sent
13:52 < sipa> wumpus: yes, agree
13:52 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
13:52 < sipa> i don't think it's constructive to call this sabotage
13:52 < wumpus> well no one else came up with a solution to this even with so little time left
13:53 < sipa> what do you mean? there is a solution, it works, it's tested, and it'll be in the next release
13:53 < luke-jr> ?
13:53 < wumpus> sipa: if it's up to me, yes
13:54 < sipa> oh i assumed "solution to this" was about addrv2 itself; not about protocol negotiation
13:55 < sipa> my suggestion is to just only send sendaddrv2 to clients with protocol version>=70016, as i believe that'll just work with no practical downsides
13:55 < sipa> and tell btcd people that it's in their own interest to not keep expecting such bumps going forward, as a single version number for negotiation things just doesn't work
13:55 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 246 seconds]
13:56 < sipa> i don't know what to do about libbitcoin - it seems we just fundamentally disagree about what the protocol is there
13:57 < luke-jr> as long as we ensure they can't continue their silliness into BIP324, at least it has an end date?
13:58 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Remote host closed the connection]
13:58 < luke-jr> (we can just add new features only within the context of BIP324)
13:59 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
14:01 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
14:01 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Read error: Connection reset by peer]
14:02 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
14:20 -!- Murch [murch@2a01:4f8:141:1272::2] has joined #bitcoin-core-dev
14:26 < wumpus> luke-jr: I just had the idea we could recycle the alert message, it allows arbirary content, right, and as long as the signature doesn't check out old clients won't interpret it as an actual alert
14:27 < sipa> haha
14:39 -!- Pavlenex [~Thunderbi@178.220.68.122] has quit [Quit: Pavlenex]
14:52 -!- zndtoshi [~zndtoshi@79.112.20.148] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:56 < luke-jr> wumpus: O.o
14:57 -!- Tennis [~Tennis@unaffiliated/tennis] has joined #bitcoin-core-dev
14:57 < luke-jr> eh, IMO not worth it
14:57 < luke-jr> easier to just gratuitously bump the protocol version number for everything
14:57 < luke-jr> until we switch to BIP324
14:59 < wumpus> I'm not seriously considering it, but if people want silly I can do silly very well :)
15:00 < luke-jr> :p
15:00 < wumpus> it's always possible to find a away to shuttle data over some protocol
15:01 < wumpus> and impossible to block all such vectors
15:03 < wumpus> one thing I had never imagined was having to do this for the bitcoin P2P protocol, I mean usually it's about trying to smuggle bitcoin P2P data like blocks and transactions over some other layer
15:04 < wumpus> but in any case, no, they can't block permissionless extensibility
15:04 < wumpus> there are sneaky ways to negotiate :p
15:06 < wumpus> maybe one day we have the entire protocol running over the alert message
15:06 < sipa> https://github.com/bitcoin/bitcoin/pull/20564
15:06 < jonatack> curious, the PR didn't appear here
15:06 < wumpus> weird is the bot broken
15:06 < sipa> indeed
15:10 < wumpus> Connecting to chat.freenode.net:6697 with nick bitcoin-git and channels: #bitcoin-commits,#bitcoin-core-dev: There was a problem sending messages to IRC: timed out
15:10 < wumpus> eh hopefully it's a temporary problem
15:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
15:12 < bitcoin-git> [bitcoin] laanwj closed pull request #20476: contrib: Add test for ELF symbol-check (master...2020_11_test_symbol_check) https://github.com/bitcoin/bitcoin/pull/20476
15:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
15:13 < wumpus> seems so
15:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
15:13 < bitcoin-git> [bitcoin] laanwj reopened pull request #20476: contrib: Add test for ELF symbol-check (master...2020_11_test_symbol_check) https://github.com/bitcoin/bitcoin/pull/20476
15:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
15:18 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
15:22 -!- yoyo-slays [615fc728@097-095-199-040.res.spectrum.com] has joined #bitcoin-core-dev
15:22 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
15:23 -!- yoyo-slays [615fc728@097-095-199-040.res.spectrum.com] has quit [Remote host closed the connection]
15:23 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 260 seconds]
15:25 -!- Tennis [~Tennis@unaffiliated/tennis] has quit [Read error: Connection reset by peer]
15:50 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
16:01 -!- glozow [uid453516@gateway/web/irccloud.com/x-suaydrfreocgdkkl] has quit [Quit: Connection closed for inactivity]
16:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:02 < bitcoin-git> [bitcoin] BlockMechanic opened pull request #20565: Android : Ensure pic build for bdb (master...fix-bdb-android) https://github.com/bitcoin/bitcoin/pull/20565
16:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:09 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
16:12 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a1c2:b119:a4c8:3942:7eb] has joined #bitcoin-core-dev
16:41 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 260 seconds]
16:43 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has quit [Remote host closed the connection]
16:44 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has joined #bitcoin-core-dev
16:56 -!- amiti [sid373138@gateway/web/irccloud.com/x-ivprtaazvjpsstjf] has quit [Ping timeout: 244 seconds]
16:56 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-qlebbpueqzhclgdu] has quit [Ping timeout: 244 seconds]
16:57 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has quit [Quit: leaving]
16:57 -!- michagogo [sid14316@wikia/Michagogo] has quit [Ping timeout: 244 seconds]
16:58 -!- amiti [sid373138@gateway/web/irccloud.com/x-ayunlkaefenrhtuj] has joined #bitcoin-core-dev
16:58 -!- valwal_ [sid334773@gateway/web/irccloud.com/x-xpdkkmqnrtcjkded] has joined #bitcoin-core-dev
16:59 -!- michagogo [sid14316@wikia/Michagogo] has joined #bitcoin-core-dev
16:59 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer]
16:59 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
17:09 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has quit [Ping timeout: 246 seconds]
17:10 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
17:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
17:56 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
18:09 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
18:10 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 246 seconds]
18:15 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a1c2:b119:a4c8:3942:7eb] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
18:17 -!- da39a3ee5e6b4b0d [~da39a3ee5@171.5.167.167] has joined #bitcoin-core-dev
18:36 -!- freeyao [ac69eb05@172.105.235.5] has joined #bitcoin-core-dev
18:36 -!- freeyao [ac69eb05@172.105.235.5] has quit [Remote host closed the connection]
18:42 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
19:00 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
19:03 -!- pinheadm_ [~pinheadmz@86.107.55.243] has joined #bitcoin-core-dev
19:05 -!- pinheadmz [~pinheadmz@71.190.30.138] has quit [Ping timeout: 256 seconds]
19:06 -!- pinheadmz [~pinheadmz@71.190.30.138] has joined #bitcoin-core-dev
19:09 -!- pinheadm_ [~pinheadmz@86.107.55.243] has quit [Ping timeout: 256 seconds]
19:31 -!- pinheadmz [~pinheadmz@71.190.30.138] has quit [Quit: pinheadmz]
19:35 -!- pinheadmz [~pinheadmz@71.190.30.138] has joined #bitcoin-core-dev
19:58 -!- baldur [~baldur@pool-108-30-51-126.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
20:10 -!- pinheadmz [~pinheadmz@71.190.30.138] has quit [Quit: pinheadmz]
20:12 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection]
20:23 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #bitcoin-core-dev
20:24 < andytoshi> how does travis know the subtree remotes? if i try to run the ci/test/06_script.sh script locally i get a bunch of errors like
20:24 < andytoshi> subtree commit 3967d96bf184519eb98b766af665b4d4b072563e unavailable: cannot compare. Did you add and fetch the remote?
20:24 < andytoshi> and i see some manual instructions in the README for how to add these remotes
20:24 < andytoshi> but i don't understand how travis is doing it
20:32 < fanquake> some sort of black magic
20:32 < fanquake> unclear to me as well after a quick look in ci/
20:32 < fanquake> MarcoFalke can probably enlighten us
20:33 < sipa> does travis even check the remotes?
20:34 < fanquake> it's  running the subtree checker against all the subtrees, which should require fetching the remotes
20:36 < sipa> sure, but if it doesn"t have the remotes it succeeds with a warning
20:42 < achow101> travis doesn't seem to have those remotes
20:42 < achow101> the most recent job has the same error, but the script doesn't fail so the job doesn't fail
20:47 < sipa> yes, it only does the local check iirc
20:48 < andytoshi> ah cool, i am no longer confused then :)
20:51 < sipa>  that script should probablybtake a cmdline argument to decide whether to do the remote check
21:02 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
21:08 -!- da39a3ee5e6b4b0d [~da39a3ee5@171.5.167.167] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:23 -!- cltrbreak_MAD2 [~ctrlbreak@159.2.182.106] has joined #bitcoin-core-dev
21:26 -!- pinheadmz [~pinheadmz@71.190.30.138] has joined #bitcoin-core-dev
21:26 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has quit [Ping timeout: 246 seconds]
21:27 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 256 seconds]
21:27 < fanquake> could be done while it's ported to cirrus
22:10 -!- mdrjr1 [~mdrjr@178.239.168.171] has quit [Remote host closed the connection]
22:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:27 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a0489f3472f3...e2ae6a2befad
22:27 < bitcoin-git> bitcoin/master 2f6fe4e Hennadii Stepanov: ci: Build with --enable-werror by default, and document exceptions
22:27 < bitcoin-git> bitcoin/master e2ae6a2 MarcoFalke: Merge #20182: ci: Build with --enable-werror by default, and document exce...
22:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:27 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20182: ci: Build with --enable-werror by default, and document exceptions (master...201018-error) https://github.com/bitcoin/bitcoin/pull/20182
22:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:31 -!- popey1 [~popey@185.163.110.125] has joined #bitcoin-core-dev
22:50 -!- da39a3ee5e6b4b0d [~da39a3ee5@171.5.167.167] has joined #bitcoin-core-dev
23:20 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
23:23 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 260 seconds]
23:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:23 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #20566: refactor: Use C++17 std::array where possible (master...2012-array) https://github.com/bitcoin/bitcoin/pull/20566
23:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:41 < wumpus> andytoshi: it doesn't really know, there's a manual fetch of all the repositories in there IIRC< it spooked me too once
23:43 < wumpus> or no there isn't, I don't really know
23:44 < wumpus> but I ran into some issues when I had to use a non-standard subtree for some temporary patches / experimentation in a PR (for a leveldb update)
23:45 < wumpus> https://github.com/bitcoin/bitcoin/pull/17398#issuecomment-552811611
23:50 < wumpus> on one hand I'm happy no longer being the only person running into this, on the other it would be good if it had better documentation 
23:52 < wumpus> err wait the 'error' exit has a positive exit status, riight 
--- Log closed Fri Dec 04 00:00:36 2020