--- Log opened Thu Nov 12 00:00:14 2020
00:03 -!- Kiminuo [~mix@141.98.103.92] has joined #bitcoin-core-dev
00:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:04 < bitcoin-git> [bitcoin] fanquake closed pull request #18095: Fix crashes and infinite loop in ListWalletDir() (master...master) https://github.com/bitcoin/bitcoin/pull/18095
00:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
00:17 -!- bosch-0 [uid472282@gateway/web/irccloud.com/x-gjvbqlqofnghqnkw] has quit [Quit: Connection closed for inactivity]
00:28 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:34 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c2d8ba6265a4...bcd142e479fa
00:34 < bitcoin-git> bitcoin/master c82336c fanquake: Remove references to CreateWalletFromFile
00:34 < bitcoin-git> bitcoin/master bcd142e MarcoFalke: Merge #20285: Remove references to CreateWalletFromFile
00:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:35 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20285: Remove references to CreateWalletFromFile (master...createwalletfromfilenomore) https://github.com/bitcoin/bitcoin/pull/20285
00:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:36 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/bcd142e479fa...027e51f71517
00:36 < bitcoin-git> bitcoin/master ee11a41 practicalswift: Avoid signed integer overflow when loading a mempool.dat file with a malfo...
00:36 < bitcoin-git> bitcoin/master 027e51f MarcoFalke: Merge #20372: Avoid signed integer overflow when loading a mempool.dat fil...
00:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:37 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20372: Avoid signed integer overflow when loading a mempool.dat file with a malformed time field (master...load-mempool-time-integer-overflow) https://github.com/bitcoin/bitcoin/pull/20372
00:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:39 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
00:45 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th] has joined #bitcoin-core-dev
00:45 -!- IGHOR [~quassel@176.121.4.135] has quit [Quit: No Ping reply in 180 seconds.]
00:48 -!- IGHOR [~quassel@176.121.4.135] has joined #bitcoin-core-dev
00:58 -!- AdulrunaRedviva [c3d69d22@195.214.157.34] has joined #bitcoin-core-dev
00:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:59 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/027e51f71517...af8ec1d3e576
00:59 < bitcoin-git> bitcoin/master 3c77b80 practicalswift: fuzz: Improve coverage for CPartialMerkleTree fuzzing harness
00:59 < bitcoin-git> bitcoin/master af8ec1d MarcoFalke: Merge #20375: fuzz: Improve coverage for CPartialMerkleTree fuzzing harnes...
00:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:00 -!- slewis [~slewis@178.162.212.214] has quit []
01:00 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-jfxechrxuoddrluf] has quit [Quit: Idle for 30+ days]
01:00 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th] has quit [Ping timeout: 272 seconds]
01:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:00 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20375: fuzz: Improve coverage for CPartialMerkleTree fuzzing harness (master...fuzzers-2020-11-11) https://github.com/bitcoin/bitcoin/pull/20375
01:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:09 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/af8ec1d3e576...8a486158cbc3
01:09 < bitcoin-git> bitcoin/master 79ef832 practicalswift: tests: Add fuzzing harness for CConnman
01:09 < bitcoin-git> bitcoin/master 8a48615 MarcoFalke: Merge #20188: tests: Add fuzzing harness for CConnman
01:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:09 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20188: tests: Add fuzzing harness for CConnman (master...fuzzers-connman) https://github.com/bitcoin/bitcoin/pull/20188
01:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:14 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]
01:20 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
01:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:24 < bitcoin-git> [gui] hebasto closed pull request #127: Replace QMetaObject::invokeMethod with atomic operations (master...201102-queued) https://github.com/bitcoin-core/gui/pull/127
01:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
01:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
01:36 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
01:39 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
01:44 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]
01:56 -!- tsmango [~tsmango@178.239.168.171] has joined #bitcoin-core-dev
02:02 -!- sr_gi [~sr_gi@static-120-201-229-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
02:03 -!- sr_gi [~sr_gi@static-120-201-229-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
02:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:08 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
02:08 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has quit [Ping timeout: 246 seconds]
02:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
02:12 -!- vasild_ is now known as vasild
02:28 -!- AdulrunaRedviva [c3d69d22@195.214.157.34] has quit [Remote host closed the connection]
02:31 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th] has joined #bitcoin-core-dev
02:56 -!- AdulrunaRedviva [c3d69d22@195.214.157.34] has joined #bitcoin-core-dev
02:59 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
03:01 -!- Lexyon____ [sid402723@gateway/web/irccloud.com/x-xzmxwubdunekjens] has quit [Quit: Connection closed for inactivity]
03:01 -!- wonderworker [bc2b8820@188.43.136.32] has joined #bitcoin-core-dev
03:01 -!- wonderworker [bc2b8820@188.43.136.32] has left #bitcoin-core-dev []
03:02 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 256 seconds]
03:02 < jonatack> Sorry to have been reviewing less than usual the past week. After spending time chopping wood on it, #20305 "wallet: introduce fee_rate sat/vB param/option" should be ready for final review for 0.21.
03:02 < gribble> https://github.com/bitcoin/bitcoin/issues/20305 | wallet: introduce fee_rate sat/vB param/option by jonatack · Pull Request #20305 · bitcoin/bitcoin · GitHub
03:05 < jonatack> Thanks to murch and achow101 for reviewing it so far.
03:16 -!- Kiminuo [~mix@141.98.103.92] has quit [Ping timeout: 272 seconds]
03:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
03:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:18 -!- Aniyah8Lubowitz [~Aniyah8Lu@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
03:24 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #bitcoin-core-dev
03:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:24 < bitcoin-git> [gui] jonasschnelli merged pull request #120: Fix multiwallet transaction notifications (master...2020-10-fix-transaction-notifications) https://github.com/bitcoin-core/gui/pull/120
03:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:24 < bitcoin-git> [bitcoin] jonasschnelli pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/8a486158cbc3...9bd131669729
03:24 < bitcoin-git> bitcoin/master 7b3b230 João Barbosa: move-only: Define TransactionNotification before  TransactionTablePriv
03:24 < bitcoin-git> bitcoin/master 989e579 João Barbosa: qt: Make transaction notification queue wallet specific
03:24 < bitcoin-git> bitcoin/master 2414342 João Barbosa: refactor: qt: Use vQueueNotifications.clear()
03:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:34 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
03:34 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
03:35 -!- AdulrunaRedviva5 [c3d69d22@195.214.157.34] has joined #bitcoin-core-dev
03:35 -!- AdulrunaRedviva5 [c3d69d22@195.214.157.34] has left #bitcoin-core-dev []
03:38 -!- AdulrunaRedviva [c3d69d22@195.214.157.34] has quit [Ping timeout: 245 seconds]
03:44 -!- Guyver2__ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
03:47 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 256 seconds]
03:49 -!- einyx [einyx@fsf/member/einyx] has joined #bitcoin-core-dev
03:50 -!- einyx_ [einyx@fsf/member/einyx] has quit [Ping timeout: 258 seconds]
04:00 -!- tsmango [~tsmango@178.239.168.171] has quit []
04:01 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th] has quit [Ping timeout: 256 seconds]
04:02 -!- belcher_ is now known as belcher
04:16 -!- Kiminuo [~mix@141.98.103.92] has joined #bitcoin-core-dev
04:19 -!- Aniyah8Lubowitz [~Aniyah8Lu@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds]
04:21 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
04:24 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds]
04:30 < vasild> MarcoFalke: one of the test runs on https://github.com/bitcoin/bitcoin/pull/20284 is timing out, I restarted it 2 times, hmm
04:32 < MarcoFalke> vasild: Can be ignored
04:32 < MarcoFalke> Fix would be to rebase on current master, but we don't want that
04:33 < vasild> cirrus is not merging the tip of the PR into latest master before testing, like travis?
04:37 < MarcoFalke> not for the config
04:37 < vasild> ok
04:37 < MarcoFalke> Though the code is merged in the merge_base step
04:49 -!- Tennis [~Tennis@unaffiliated/tennis] has joined #bitcoin-core-dev
04:50 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
04:53 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
04:54 -!- tw1sted1 [~tw1sted@195.206.169.184] has joined #bitcoin-core-dev
04:56 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection]
04:56 -!- einyx [einyx@fsf/member/einyx] has quit [Read error: Connection reset by peer]
04:57 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
05:01 -!- einyx [einyx@fsf/member/einyx] has joined #bitcoin-core-dev
05:06 -!- Mercury_Vapor [~Mercury_V@174-082-166-092.res.spectrum.com] has joined #bitcoin-core-dev
05:07 -!- glozow [uid453516@gateway/web/irccloud.com/x-bxytrqtdrqgdakox] has joined #bitcoin-core-dev
05:23 < jonasschnelli> MarcoFalke: as for the devision by 0 in wallet.cpp, ... any idea why cirrus is not triggering the UndefinedBehaviorSanitizer error?
05:24 < queip> recommended nomenclature for keys is: SK - secret key, PK - public key, HPK - hash  of PK, right?
05:31 -!- Guyver2__ is now known as Guyver2
05:35 -!- filchef [~filchef@212.104.97.177] has joined #bitcoin-core-dev
05:44 < MarcoFalke> jonasschnelli: Nope. How is your config different from ./ci/test/00_setup_env_native_asan.sh ?
05:45 < MarcoFalke> the ci config is running Ubuntu focal
05:47 < jonasschnelli> I guess clang 8 (bbb) vs 10 (cirrus) should not make a difference
05:47 < jonasschnelli> bbb doesn't set -DARENA_DEBUG
06:08 -!- einyx_ [einyx@fsf/member/einyx] has joined #bitcoin-core-dev
06:09 -!- einyx [einyx@fsf/member/einyx] has quit [Ping timeout: 246 seconds]
06:17 < shesek> which block validity rules can be validated by spv clients?
06:17 < shesek> the ones I have in mind is checking that the previous block hash connects properly, that the nonce matches the target bits, that the target bits match the last difficulty readjustment, that the difficulty readjustments themselves are valid, and the MTP rule. what more am I missing?
06:28 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
06:34 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
06:36 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
06:36 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer]
06:37 -!- wullon [~wullon@241.243.86.88.rdns.comcable.net] has quit [Read error: Connection reset by peer]
06:37 < shesek> (I got disconnected and didn't see replies if there were any)
06:38 -!- wullon [~wullon@241.243.86.88.rdns.comcable.net] has joined #bitcoin-core-dev
06:45 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
06:51 -!- kexkey [~kexkey@static-198-54-132-137.cust.tzulo.com] has joined #bitcoin-core-dev
07:00 -!- tw1sted1 [~tw1sted@195.206.169.184] has quit []
07:18 < jonasschnelli> shesek: there where non. :)
07:20 < jonasschnelli> shesek: looks like you have a relatively complete list of what measures you can take when not validating the chain
07:20 < Kiminuo> shesek, see http://gnusha.org/bitcoin-core-dev/2020-11-12.log
07:20 < jonasschnelli> but I recommend to join #bitcoin-dev
07:20 < jonasschnelli> this channel is for bitcoin core development
07:21 -!- SLNP [~SLNP@89.249.74.218] has joined #bitcoin-core-dev
07:25 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
07:26 < shesek> jonasschnelli, of course, apologies for going off topic, will take notice next time
07:27 < shesek> honestly I kinda knew it, its just that #bitcoin-dev appears pretty much dead, all my scrollback there is join/part/quit messages
07:27 < jonasschnelli> shesek: yeah.. maybe also #bitcoin can help
07:28 < jonasschnelli> luke-jr have made some thought on that AFAIK.
07:28 < jonasschnelli> (on your SPV question).
07:28 < pinheadmz> #bitcoin is basically /r/bitcoin
07:28 < jonasschnelli> Also look at BIP180 (https://github.com/bitcoin/bips/blob/master/bip-0180.mediawiki)
07:28 < pinheadmz> shesek ive gotten a  lot of great help from #bitcoin-core-pr-reviews
07:29 -!- SLNP [~SLNP@89.249.74.218] has quit [Ping timeout: 260 seconds]
07:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:29 < bitcoin-git> [bitcoin] practicalswift opened pull request #20377: fuzz: Fill various small fuzzing gaps (master...fuzzers-2020-11-12) https://github.com/bitcoin/bitcoin/pull/20377
07:29 < shesek> pinheadmz, is off topic considered okay there when there isn't a meeting going on?
07:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:29 < pinheadmz> yup, get in there
07:30 < shesek> jonasschnelli, iirc luke-jr ended up finding some issue with his proposed weight fraud proof mechanism, no?
07:30 < jonasschnelli> probably,.. I haven't followed and can't recall
07:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:39 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #20378: fix potential devision by 0 (master...2020/11/fix_devnull_wallet) https://github.com/bitcoin/bitcoin/pull/20378
07:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:57 < warren> jonasschnelli: btw whatever happened to BIP150/151. Looking at BIPs now I don't see a replacement that supersedes them?
07:58 < jonasschnelli> warren: BIP324
07:58 < jonasschnelli> We are currently altering the AEAD though (make it simpler)
07:58 < warren> URL to draft?
07:58 < jonasschnelli> https://github.com/bitcoin/bips/pull/1024
07:59 < jonasschnelli> discussions also here: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#ChaCha20Poly1305Bitcoin_Cipher_Suite
07:59 < jonasschnelli> we're getting there... I hope it will not take another 4 years. :)
08:05 < warren> thanks just had to point at it as an example
08:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:06 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9bd131669729...0bd4929cd00e
08:06 < bitcoin-git> bitcoin/master 38ada89 Vasil Dimov: addrman: ensure old versions don't parse peers.dat
08:06 < bitcoin-git> bitcoin/master 0bd4929 Wladimir J. van der Laan: Merge #20284: addrman: ensure old versions don't parse peers.dat
08:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:07 < bitcoin-git> [bitcoin] laanwj merged pull request #20284: addrman: ensure old versions don't parse peers.dat (master...peers_dat_format) https://github.com/bitcoin/bitcoin/pull/20284
08:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:07 < vasild> \o/
08:57 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
08:58 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds]
08:59 -!- mrd [~mrd@185.163.110.116] has joined #bitcoin-core-dev
09:14 -!- Guyver2_ is now known as Guyver2
09:16 -!- nanotube [~nanotube@unaffiliated/nanotube] has quit [Ping timeout: 256 seconds]
09:21 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
09:37 -!- brianhoffman [~brianhoff@pool-71-191-34-154.washdc.fios.verizon.net] has quit [Quit: brianhoffman]
09:41 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 256 seconds]
09:47 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
09:47 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
09:50 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
09:54 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-core-dev
10:00 -!- mrd [~mrd@185.163.110.116] has quit []
10:02 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds]
10:19 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
10:21 -!- kierank1 [~kierank@184.75.221.35] has joined #bitcoin-core-dev
10:32 < jnewbery> #proposedmeetingtopic limiting C++17 feature usage (see https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-726214696)
10:37 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
10:40 -!- ja [janus@anubis.0x90.dk] has joined #bitcoin-core-dev
10:41 < ja> luke-jr: rhel 8 and fc30 was patched in february according to https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1864864/comments/2
10:41 < ja> luke-jr: writing you here since the thread is already getting really long and i don't wanna add a comment which is answering a question already answered in a posted link
10:46 < provoostenator> Looks like Btcd is allergic to sendaddrv2: https://github.com/btcsuite/btcd/issues/1661 (cc roasbeef)
10:48 < provoostenator> (I should try an earlier version just to make sure it's not something else...)
10:49 -!- lightlike [~lightlike@p200300c7ef1a1b00c04f02a7739a7f7b.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
10:51 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
10:51 -!- luke [~luke@bitnomial/staff/luke] has joined #bitcoin-core-dev
10:51 -!- luke [~luke@bitnomial/staff/luke] has quit [Client Quit]
10:53 < ja> provoostenator: is your testing setup public? it would be fun to try and connect all kinds of different versions with each other and draw a matrix :D
10:54 < provoostenator> It connects fine as of a slightly older commit 1d3ec2a1fda7446323786a52da1fd109c01aa6fb
10:54 < provoostenator> ja: it's not unfortunately; you'll have to spin up your own btcd and core machine somewhere.
11:00 < ja> i see so many booleans, and i am suspicious. for example https://github.com/bitcoin/bitcoin/commit/1d3ec2a1fda7446323786a52da1fd109c01aa6fb
11:00 < ja> i understand that it would be too much having a custom type for every single case
11:01 < hebasto> meeting?
11:01 < achow101> meeting?
11:01 < wumpus> #startmeeting
11:01 < core-meetingbot> Meeting started Thu Nov 12 19:01:12 2020 UTC.  The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
11:01 < core-meetingbot> Available commands: action commands idea info link nick
11:01 < jnewbery> hi
11:01 < amiti> hi
11:01 < jonatack> hi
11:01 < jonasschnelli> hi
11:01 < luke-jr> hi
11:01 < emzy> hi
11:01 < hebasto> hi
11:01 < achow101> hi
11:01 < provoostenator> ja: that;s just an arbitary commit, nothing to do with the issue
11:01 < provoostenator> hi
11:01 < meshcollider> hi
11:01 < ja> provoostenator: i would explain if there wasn't a meeting now ;)
11:01 < fanquake> hi
11:01 < 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:02 < fjahr> hi
11:02 < wumpus> one proposed meeting topic: limiting C++17 feature usage (jnewbery)
11:03 < wumpus> I guess the most pressing topic right now is the 0.21.0rc1 release
11:03 -!- LarryRuane [62f5cc94@c-98-245-204-148.hsd1.co.comcast.net] has joined #bitcoin-core-dev
11:03 < wumpus> at least there's only three PRs left on the milestone:  https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.21.0
11:03 < provoostenator> I'd like to get this in the release if possible: https://github.com/bitcoin-core/gui/pull/96
11:04 < wumpus> jonasschnelli's last minute fix seems trivial
11:04 < jonasschnelli> yes. can be merged I guess
11:04 < provoostenator> I reverted the string changes, so it's pretty simple now.
11:04 < hebasto> will review it tonight
11:04 < wumpus> provoostenator: ok!
11:05 < provoostenator> thx
11:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:05 < bitcoin-git> [bitcoin] practicalswift opened pull request #20379: tests: Remove no longer needed UBSan suppression (float divide-by-zero in validation.cpp) (master...remove-ubsan-suppressions) https://github.com/bitcoin/bitcoin/pull/20379
11:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:05 < jonasschnelli> I'll look into it,... but was under the impression that we had code freeze already
11:05 < wumpus> yes, it's definitely too late for string changes
11:05 < sipa> hi
11:05 < provoostenator> The biggest thing that PR does is not recommend encryptino by default
11:05 < provoostenator> Which just seems a recipe for tears for brand new users.
11:06 < wumpus> I agree with that, encryption is torture for new users
11:06 < sipa> which PR are you talking about?
11:06 < hebasto> https://github.com/bitcoin-core/gui/pull/96
11:07  * hebasto sipa: ^
11:08 < wumpus> in any case please help review the last remaining PRs for 0.21: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.21.0   and https://github.com/bitcoin-core/gui/milestone/1
11:10 < wumpus> #20305 and #18836 are the big ones
11:10 < gribble> https://github.com/bitcoin/bitcoin/issues/20305 | wallet: introduce fee_rate sat/vB param/option by jonatack · Pull Request #20305 · bitcoin/bitcoin · GitHub
11:10 < gribble> https://github.com/bitcoin/bitcoin/issues/18836 | wallet: upgradewallet fixes and additional tests by achow101 · Pull Request #18836 · bitcoin/bitcoin · GitHub
11:10 < luke-jr> 20305 should be noted to break RPC compatibility, but in a way that I and others feel is okay
11:10 < luke-jr> if anyone objects, they should speak up
11:11 < luke-jr> (see details on PR comments)
11:11 < wumpus> versus 0.20? or just versus previous intermediate master releases?
11:11 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
11:11 < wumpus> okay
11:11 < luke-jr> wumpus: 0.20
11:11 < jonatack> (for bumpfee)
11:11 < luke-jr> it's complex to explain, but IMO a reasonable concession
11:11 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
11:11 < MarcoFalke> That certainly needs release notes, no?
11:11 < jonatack> relevant comment by murch on that: "uckily, this is very benign. In the worst case, someone is going to get upped to the minRelayTxFee silently and sends at 1 sat/vB. Since RBF is on by default, they should be able bump when they notice. +1"
11:12 < jonatack> https://github.com/bitcoin/bitcoin/pull/20305#discussion_r520231413
11:12 < luke-jr> MarcoFalke: agreed
11:12 < jonatack> MarcoFalke: yes, definitely, we can edit the wiki.
11:13 -!- kierank1 [~kierank@184.75.221.35] has quit [Ping timeout: 265 seconds]
11:13 < luke-jr> most likely trying to use the old interface will just error; worst case, it's fixable
11:14 < wumpus> ok
11:14 < jonatack> yes, for the bumpfee change, there's a 1e5 times difference in units in the downward direction
11:14 < wumpus> yeah downward is the only acceptable direction
11:15 < jonatack> also added a * WARNING * in the help
11:15 -!- LarryRuane [62f5cc94@c-98-245-204-148.hsd1.co.comcast.net] has quit [Remote host closed the connection]
11:15 < luke-jr> oh. just thought of a possible danger
11:15 < luke-jr> if someone uses the new interface, with an old version
11:16 < provoostenator> luke-jr: that's dangerous in general, given some of the other fixes...
11:16 < luke-jr> provoostenator: ?
11:16 < luke-jr> I wonder if the magnitude would trigger the absurd fee warning
11:16 < provoostenator> #16257
11:16 < gribble> https://github.com/bitcoin/bitcoin/issues/16257 | [wallet] abort when attempting to fund a transaction above -maxtxfee by Sjors · Pull Request #16257 · bitcoin/bitcoin · GitHub
11:17 < sipa> the default absurd fee threshold is 0.1 BTC or so, no?
11:17 < jonatack> yes iirc
11:17 < jonatack> per the tests i've added in any case
11:17 < queip> so it's decided to go with vB? WU was popular last year
11:17 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
11:17 < provoostenator> People are still making payments with 0.1 BTC fees FWIW, quite often
11:18 < sipa> everyone uses sat/vB, afaik
11:18 < wumpus> `if there's any risk of it causing people to overpay fees it's unacceptable risk
11:18 < sipa> i think WU is dangerous because it can result in a 4x factor off, which isn't enough to be likely to trigger other warning mechanisms
11:19 < jonatack> queip: recent twitter poll showed a 20 to 1 preference for sat/vB over BTC/kB, wasn't an option though
11:19 < jonatack> *WU wasn't an option in the poll tho
11:19 < luke-jr> sipa: well, nothing is using sat/vB yet.. so it's a factor of 1e5/4
11:19 < sipa> luke-jr: almost every fee estimation website, most block explorers, ... do
11:19 < wumpus> so is that the case for #20305?
11:19 < gribble> https://github.com/bitcoin/bitcoin/issues/20305 | wallet: introduce fee_rate sat/vB param/option by jonatack · Pull Request #20305 · bitcoin/bitcoin · GitHub
11:20 < meshcollider> provoostenator: it's the wrong direction, even if they intended to send at 1btc, they'd end up at 1sat/vB
11:20 < michaelfolkson> Slight overpayment -> Risk of slight monetary loss. Slight underpayment -> Risk of not being propagated? I guess it depends on how high the original fee was
11:21 < luke-jr> minimum realistic bumpfee is probably 2sat/vB?
11:21 < meshcollider> I don't think there's ever any risk of overpayment here
11:21 < luke-jr> which at BTC/kB is 2 BTC/kB, over the absurd fee cutoff
11:21 < jonatack> luke-jr: min incremental fee is 1 sat/vB 
11:21 < sipa> luke-jr: good point
11:21 < wumpus> underpayment is at least better, could always bump again
11:21 < luke-jr> so I *think* the magnitude is sufficient to avoid any loss in either direction
11:22 < luke-jr> which only leaves the WU question - but I don't think we have time to do another poll
11:22 < luke-jr> if people prefer WU and have to divide by 4, it's not the end of the world anywaty
11:22 < jonatack> AFAIK sats seem to be far and away what people want
11:22 < queip> ok just was asking
11:22 < michaelfolkson> +1
11:23 < luke-jr> jonatack: well, I assume it'd be sats/WU in that case
11:23 < jonatack> found the poll: https://twitter.com/jonatack/status/1318890833131823104?s=20
11:23 < emzy> +1
11:23 -!- promag [~promag@188.250.84.129] has quit [Ping timeout: 256 seconds]
11:24 < sipa> i haven't paid attention to the actual solution we're going for now... but would it be easy to add more units later?
11:24 < luke-jr> sipa: no
11:24 < meshcollider> I don't think it's worth bikeshedding over but I prefer sats/vB honestly
11:24 < wumpus> no, I think it's better to settle on one unit and one unit only for RPC
11:24 < luke-jr> sipa: this removes all unit choice, and just uses sat/vB
11:24 < meshcollider> sipa: we're trying to make it simpler :)
11:25 < sipa> luke-jr: how does that not break compatibility (as earlier releases all use BTC/kvB)?
11:25 < wumpus> adding a choice of units shouldn't be necesasry, it's a programmatic interface
11:25 < jonatack> right, so people don't have to pass in a choice of units with the estimate_mode param
11:25 < wumpus> just standardize something …
11:25 < luke-jr> sipa: the field name is different for everything except bumpfee
11:25 < sipa> feel free to tell me to just go read the PR
11:25 < luke-jr> sipa: and bumpfee is protected by the magnitude
11:25 < luke-jr> sipa: the old interface to bumpfee+fee_rate won't *work*, but it won't do damage either
11:26 < sipa> ok
11:26 < luke-jr> (other RPCs used "feeRate" instead of "fee_rate")
11:27 < luke-jr> IIRC only in options objects, so no positional mess (someone should double-check this)
11:27 < jonatack> yes. (in fundrawtxn and walletcreatefundedpsbt only)
11:27 -!- evanpro [~evanpro@195.206.169.184] has joined #bitcoin-core-dev
11:28 < jonatack> feeRate is only an arg, not an option, which we can deprecate as soon as people judge feasible
11:28 < jonatack> it's in BTC/kB
11:30 < wumpus> next topic?
11:31 < jonatack> (fwiw that PR adds a fair number of RPCExamples in send and sendtoaddress to help people use it)
11:31 < michaelfolkson> wumpus: yup
11:32 < wumpus> #topic limiting C++17 feature usage (jnewbery)
11:32 < core-meetingbot> topic: limiting C++17 feature usage (jnewbery)
11:32 < jnewbery> hi
11:32 < wumpus> link: https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-726214696
11:32 < jnewbery> As a reminder, our plan for C++17 is here: https://github.com/bitcoin/bitcoin/issues/16684
11:32 < jnewbery> Once we branch v0.21 (imminently), we'll be able to start using c++14 and c++17 features.
11:33 < jnewbery> I expect lots of people have their favorite features that they want to start using.
11:33 < jnewbery> I was wondering whether we should have a project-wide policy on which new features we should allow, or if there are any we should disallow in the project for now.
11:33 < jnewbery> Prompted by https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-726214696, where Cory ran into a bug in glibc when using std::shared_mutex.
11:33 < wumpus> so there's a specific feature that triggers a libc bug?
11:33 < jnewbery> So std::shared_mutex is one that I think we should avoid, at least until we better understand the bug, but are there others?
11:34 < MarcoFalke> std::fs
11:34 < wumpus> I'd rather not do that, that for 0.22 full C++17 is allowed, but that is a good reason to disallow that one for now
11:34 < hebasto> or define minimum libc with fixed bug?
11:34 < sipa> i vaguely remember some issues with trying to use std::filesystem by someone, but i'm not sure if that was because they weren't familiar enough with the build system, or if there were actual problems with it
11:34 < MarcoFalke> We can't use std::fs because LTS versions of operating systems don't ship it
11:34 < sipa> well what's the alternative? does boost::shared_mutex not have the same problem?
11:34 < wumpus> every specific exclusion makes it more difficult for new contributors etc
11:35 < MarcoFalke> sipa: We already use boost::shared_mutex
11:35 < sipa> MarcoFalke: right, my concern is that boost, when compiled in c++17 mode, will just go "oh the STL provides this, just delegate to that"
11:35 < wumpus> people don't generally consult a list of allowed features before contributing
11:35 < MarcoFalke> ah good point
11:35 < luke-jr> hmm
11:36 < wumpus> though things like "use boost::shared_mutex instead of std::shared_mutex" are clear and easy to enforce enough
11:36 < wumpus> or the fs one
11:36 < wumpus> we have our own fs abstraction anyway
11:36 < sipa> it wouldn't be hard to add a linter to outlaw "std::filesistem" and "std::shared_mutex" in the codebase or so
11:36 < wumpus> sipa: yes
11:36 < wumpus> those two are easy
11:36 < MarcoFalke> sipa: The ci would fail if someone tried using std::fs
11:37 < sipa> oh, right
11:37 < MarcoFalke> (and gitian)
11:37 < sipa> my impression is that all these issues are STL features, not languages features
11:37 < sipa> and i expect that if you use a sufficient compiler version, all languages features will actually work
11:37 < jonatack> luke-jr: you are right, feeRate is an option
11:38 < sipa> so perhaps the policy can be "you can use all language features, but initially we'll want to whitelist STL features" ?
11:38 < sipa> that's probably too restrictive
11:38 < wumpus> no,I think it's better to reject specific things if we have a good reason
11:39 < sipa> agree
11:39 < wumpus> and just accept standard C++17 otherwise
11:39 < sipa> i guess the concern is really about things that compile, but are known to not always work
11:39 < sipa> like this shared_mutex thing
11:39 < wumpus> right
11:39 < ja> jnewbery: should std::shared_mutex be avoided even if it is unknown whether boost::shared_mutex is also broken?
11:39 < sipa> and we should just outlaw while necessary... just as with any other compiler/stl bug
11:39 < jnewbery> I don't know enough about compilers to know how stable their C++17 stl features are
11:40 < wumpus> you would hope it is stable after more then three years
11:40 < jnewbery> you would, and yet here we are
11:40 < wumpus> of course, compiler and c++ librar ybugs happen sometimes
11:40 < wumpus> well yes it's a specific thing
11:40 < wumpus> even memcmp had a bug !!!
11:40 < jnewbery> we don't know how many other specific things there are
11:40 < wumpus> should we reject c89 featurs now
11:40 < sipa> haha
11:41 < MarcoFalke> Is there a minimal test case for the shared_mutex thing?
11:41 < ja> it is still not clear to me which glibc bug it actually is, there are linked two different bugs from the c++17 thread
11:41 < ja> but glibc has test cases for the pthread primitives 
11:41 < wumpus> it's not possible to guarantee that usage of compiler or library features doesn't have bugs, this is just as true for old features as now ones
11:42 < wumpus> this is one of the biggest risks in consensus driven systems isn't it
11:42 < jnewbery> wumpus: that's doesn't seem like it'd be true. New features are more likely to have bugs
11:42 < sipa> boost 1.71 does not seem to use STL's shared_mutex
11:42 < wumpus> jnewbery: I'm not convinced about that, code rot is a thing
11:42 < jnewbery> *or uncover existing bugs
11:42 < wumpus> new features might actually have *more* eyes on them
11:43 < luke-jr> sipa: unrelease boost might
11:43 < wumpus> this is an abyss without end anyway... we can only calculate in known bugs not potential ones
11:44 < luke-jr> if every distro has a fix, maybe just a sanity check is in order
11:44 < MarcoFalke> A future release of boost might decay boost::shared_mutex into std::shared_mutex
11:44 < jnewbery> My general point is that we shouldn't rush to use new features unless there's very clear benefit
11:44 < wumpus> MarcoFalke: yep
11:44 < luke-jr> otoh, isn't it just a deadlock worst case?
11:44 < jnewbery> and that if we do that, then we should codify what features can be used at the project level
11:44 < luke-jr> I think deadlock is fairly harmless for user-built binaries that simply require an updated OS to fix
11:45 < wumpus> no, I don't think we should make a long list of allowed c++17 features
11:45 < ja> luke-jr: if you use bitcoin to back a lightning node, a deadlock could be pretty bad, no?
11:45 < wumpus> only exclude ones that we know to cause problems
11:45 -!- lightlike [~lightlike@p200300c7ef1a1b00c04f02a7739a7f7b.dip0.t-ipconnect.de] has quit [Quit: Leaving]
11:45 < luke-jr> ja: hmm, maybe - but aren't there supposed to be watchers?
11:46 < wumpus> we have already made the decision to use c++17, maybe we should be more careful in consensus code, but that's *always* the case for any change
11:46 < ja> luke-jr: i don't know how many people are running watchers. it is irrelevant whether there is supposed to be
11:46 < luke-jr> point is, that would be a scenario with two user errors
11:47 < michaelfolkson> Watchtowers only needed if you aren't online 100 percent of time (or for additional protection)
11:47 < wumpus> and sure, we should take the same care as we did for c++11, don't change things for the sake of changing them
11:47 < ja> michaelfolkson: if you bitcoin node is deadlocked on a shared_mutex, are you online?
11:48 < michaelfolkson> I'd guess not ja :)
11:48 < wumpus> that should also be standard policy for the project already, no needless refactors
11:48 < michaelfolkson> But how long would you be deadlocked for?
11:49 < ja> 2 weeks, until you come back from vacation
11:49 < jnewbery> I think only introducing new features as they're needed is the more cautious approach
11:49 < luke-jr> michaelfolkson: indefinitely
11:49 < sipa> michaelfolkson: the definition of a deadlock implies it's forever
11:49 < michaelfolkson> Ok. That is a problem
11:49 < MarcoFalke> jnewbery: I don't think C++17 is "needed". We could stay with C++11 forever
11:49 < wumpus> in new code I think full c++17 should be allowed (apart from what we have labaled as dangerous features)
11:49 < luke-jr> but the same goes for any DoS vuln
11:49 < luke-jr> which seem fairly common
11:49 < wumpus> yes, we could stay in c++11 forever
11:50 < wumpus> but we've already decided not to
11:50 < jnewbery> It would be nice if we could have some nuance in these discussions instead of talking about C89 and staying on C++11 forever
11:50 < wumpus> I don't think it would make the project any safer
11:51 < hebasto> we coudn't stay on C++11 due to new Qt versions
11:51 < luke-jr> hebasto: Qt dropped C++11 support? :o
11:51 < wumpus> just make an exception for the gui code...
11:51 < sipa> waot
11:51 < MarcoFalke> Use C++11 code, but compile it with -std=c++17
11:51 < sipa> this shared_lock thing sounds like a problem in pthread?
11:51 < sipa> which means it would also affect boost?
11:52 < wumpus> boost definitely uses pthread (but maybe in a different way?)
11:52 < hebasto> luke-jr: #19716
11:52 < gribble> https://github.com/bitcoin/bitcoin/issues/19716 | build: Qt 5.15.x by fanquake · Pull Request #19716 · bitcoin/bitcoin · GitHub
11:52 < michaelfolkson> jnewbery: I think the nuance goes when wumpus says new contributors won't consult guides. But agreed I'd guess nuance is the better way to go
11:52 < wumpus> if it's a general pthread issue then we're already affected and c++17 is unimportant to this
11:52 < sipa> indeed
11:52 < jonatack> At the end of the day, these things are going to come down to code review and incremental adjustments and guidelines as needed.
11:53 < sipa> boost has its own shared_lock implementation
11:53 < luke-jr> hebasto: that looks like the opposite
11:53 < sipa> and doesn't use pthread's rwlock interface
11:53 < wumpus> great
11:53 < sipa> (in 1.71)
11:53 < wumpus> michaelfolkson: I don't think we can front-run any compiler or c++ library issues
11:54 < wumpus> avoiding c++17 features would give a false sense of security imo, it's not like it's brand new
11:54 < luke-jr> I wonder if we ought to add a CI using roconnor's memcmp bug detection
11:54 < wumpus> but that's just my opinion
11:55 < luke-jr> seeing as GCC/distros appear to have a disinterest in actually fixing it
11:55 < fanquake> luke-jr: opposite of what? Qt started using C++14 features in its code, and essentially “forgot” that it was still meant to support c++11. An issue was opened but they never did anything to fix the issue.
11:55 < luke-jr> fanquake: I don't see that mentioning in the linked issue?
11:56 < wumpus> I'm not sure how more nuanced you want this, I don't think it's useful to evaluate every single c++17 feature in the meeting at least
11:56 < wumpus> as if we can judge how much risk the compiler or library change is anyway
11:56 < luke-jr> fanquake: you can't build Qt with C++14 and then link from C++11 code?
11:57 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
11:57 < wumpus> could you ever have predicted this?
11:57 -!- ajonas_ [uid385278@gateway/web/irccloud.com/x-vbrpaonosufznwgi] has joined #bitcoin-core-dev
11:57 < wumpus> did std::shared_mutex sound dangerous to you than boost::shared_mutex?
11:58 < wumpus> still, here we are
11:58 < jnewbery> changing to something new is always dangerous
11:58 < fanquake> luke-jr: I mentioned the details and linked to upstream in #19305
11:58 < gribble> https://github.com/bitcoin/bitcoin/issues/19305 | doc: add C++17 release note for 0.21.0 by fanquake · Pull Request #19305 · bitcoin/bitcoin · GitHub
11:58 < wumpus> okay, so not change to anything new anymore then?
11:58 < sipa> jnewbery: boost has also had its fair share of bugs though
11:58 < wumpus> would this *specifically* have been risky to you?
11:59 < sipa> and a priori it seems a reasonable assumption that things that make it into the C++ standard have matured enough that they're less risky
11:59 < wumpus> if not, it would be a blanket reject c++17 features
11:59 < wumpus> yes
11:59 -!- per [~per@gateway/tor-sasl/wsm] has quit [Ping timeout: 240 seconds]
11:59 < wumpus> and yes, boost versions have also broken things sometimes
11:59 < wumpus> not upgrading boost is dangerous too, though
12:00 < MarcoFalke> With other project upgrading, at some point boost::feature is going to be less tested than std::feature. Code changes inside boost, which we can't anticipate are going to eventually break the feautre
12:01 < jnewbery> I don't see any strong arguments against being cautious about new features, but I'm not getting the impression that I've convinced anyone
12:01 < wumpus> I don't think any general principple can be derived from this
12:01 -!- per [~per@gateway/tor-sasl/wsm] has joined #bitcoin-core-dev
12:01 < wumpus> yes, being cautious is always good
12:01 < wumpus> I hope we already are cautious?
12:01 -!- promag [~promag@188.250.84.129] has quit [Ping timeout: 264 seconds]
12:02 < sipa> jnewbery: i think we should always be caution about new features, but i don't think this is very specific to new language/stl features
12:02 < wumpus> do you have any specific suggestion?
12:02 < sipa> and we do have a review and QA cycle, which are part of the process
12:02 < queip> as it was mentioned, compiling for old mac os x will break, also related to SDK versions afair. In context of Gitian for example
12:02 < ja> the decision should ideally be derived from usage patterns, not from how new the feature is. a 10 year old language feature that nobody uses can't be relied on. the age of the feature is a proxy for how widely used it is, which is a proxy for how buggy it is
12:03 < queip> that is, c++!7 forces such bump of minimal macosx version
12:03 < jnewbery> I didn't think sipa's suggestion of having a list of allowed features was bad. That list would grow over time
12:03 < wumpus> queip: yes, I think that wa calculated in
12:03 < wumpus> I don't think that's a good idea
12:03 < wumpus> it's super confusing to new contributors for example
12:04 < michaelfolkson> Because of new contributors and because of not knowing what should go on that list wumpus?
12:04 < sipa> i think i agree with wumpus now
12:04 < wumpus> yes
12:04 < luke-jr> queip: we typically only guarantee support for the most recent stable version of an OS
12:04 < luke-jr> though Windows is apparently an exception
12:04 < sipa> what constitutes a "feature" even? is a new member function that was added to std::vector a "feature" ?
12:04 < wumpus> if we really dislike certain features then we should disallow them, but I don't think it makes sense to partially allow a standard
12:04 < wumpus> yes
12:04 < wumpus> do we hae to whitelist every function? every class?
12:05 < MarcoFalke> Generally, our insurance against build system bugs are tests
12:05 < wumpus> do you even want to maintain this list?
12:05 < sipa> maybe a good question to ask ourselves: if we had started using std::shared_mutex, would we have caught this issue before release?
12:06 < wumpus> only if we had a test reproducing the issue predictably I think
12:06 < MarcoFalke> we should add one
12:06 < jnewbery> wumpus: I don't think we should be setting our project standards based on what features new contributors might want to use. We have project standards precisely so all contributors write code in a common way
12:06 < sipa> yeah, it'd probably depend on how actively shared_mutex was used (and with how much contention...)
12:07 < wumpus> if it causes a random hang in travis, well, peple would think it's just another infrastructure issue
12:07 < wumpus> jnewbery: okay
12:07 < sipa> jnewbery: that conceptually makes sense, but what specifically is your suggestion?
12:07 < wumpus> jnewbery: feel free to make a list
12:07 < wumpus> jnewbery: and PR it
12:07 < wumpus> jnewbery: I'm not conceptually against it I just do not want to maintain it
12:07 < MarcoFalke> time, btw
12:08 < michaelfolkson> The new contributor argument I don't think is particularly convincing. But the problems of constructing a list is more convincing to me
12:08 < luke-jr> "Travis failed, can someone restart it for me?"
12:08 < queip> apparently not popular opinion, but a white list of allowed free functions, and classes, would make it easier to guard against someone using obscure function that happens to be buggy.  Though also a review can anyway guard against it - "why not use the more common solution to this problem". Either way read list of, probably 20 recommended classes and functions, is not that hard for new developer
12:08 < wumpus> queip: again, feel free to maintian such a thing
12:08 < jnewbery> queip: that seems easier to me than arguing on each PR what is and isn't acceptable
12:08 < wumpus> I'm done with this (both the meeting and the discussion)
12:09 < wumpus> #endmeeting
12:09 < 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:09 < core-meetingbot> Meeting ended Thu Nov 12 20:09:00 2020 UTC.  
12:09 < core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2020/bitcoin-core-dev.2020-11-12-19.01.moin.txt
12:09 < sipa> ok, practically, how would it be decided what is acceptable?
12:09 < wumpus> I think this project becomes impossible to maintian in the close feature
12:09 < MarcoFalke> How could we maintain the list of allowed features?
12:10 < wumpus> if you want to micro-manage every C++ function and class and feature that people use in a huge project like this go ahead
12:10 < jonatack> I don't disagree with guidelines, but reckon they'll be shaped in a bottom-up, rather than top-down, fashion: ongoing, continual, incremental
12:10 < ja> provoostenator: i linked the commit https://github.com/bitcoin/bitcoin/commit/1d3ec2a1fda7446323786a52da1fd109c01aa6fb because i wanted to discuss this compromise on boolean blindness in general, not specific to the btcd issue
12:10 < wumpus> it's too risky anyway
12:10 < wumpus> this whole thing
12:10 < jonatack> (once upon a time, one might have said agile :))))
12:10 < ja> provoostenator: my question is: would it be useful to have a general purpose type : ShouldBeChecked = Check | DontCheck instead of bool?
12:11 < ja> provoostenator: that type could be used for example in the linked commit, and it would alliviate some boolean blindness
12:11 < wumpus> I'm not convinced even CPU features are reliable enough
12:11 < sipa> ja: i see you're a haskell programmer
12:11 < wumpus> if you really want to know
12:11 < ja> provoostenator: it is deliberately ambiguous towards exactly what should be checked. but better than a boolean, no?
12:12 < ja> sipa: i am not advocating lazy evaluation here, mind you ;) i don't think it is an obscure proposal
12:12 < MarcoFalke> Compiling with C++17 will probably make the std lib use those features, and we couldn't protect against that with a allow-list
12:13 < wumpus> I think it's important to isolate the consensus code soon, and be extremely careful about that
12:13 < sipa> jnewbery: so imagine we had this whitelist - at whatever granularity - and someone suggested that std::shared_lock should be added to it... what process would be followed to decide that
12:13 < wumpus> I'm not sure we can be careful enough
12:13 < jnewbery> jonatack: in general, that seems like a reasonable approach. But in this case when there are lots of new features on offer, then starting more restrictive and gradually allowing new features seems more cautious
12:13 < sipa> jnewbery: my guess is... unless we specifically knew about this pthread issue, everyone would be like "that seems very reasonable, it's in every STL, tests work, ... go for it"
12:13 < jnewbery> sipa: I'm not sure. It might not be practical, but I wanted to raise it as something we should at least thing about
12:14 < wumpus> C++ is a way too complex language
12:14 < sipa> wumpus: as are the operating systems and hardware they run on...
12:14 < wumpus> sipa: yes
12:14 < sipa> i don't think that's a cause for despair... we have review and tests
12:14 < sipa> the real world is always messy
12:15 < jnewbery> "This is a bad idea" is different from "I'm not conceptually against it but I don't want to maintain it"
12:15 < sipa> i don't think it's just that
12:15 < wumpus> well...
12:15 < sipa> i don't know how it would be maintained - by anyone
12:15 < MarcoFalke> I don't think an allow-list would conceptually work with c++ features
12:15 < wumpus> it's a bad idea because it takes resources from other things I gues
12:15 < wumpus> it's a huge project
12:15 < jonatack> wumpus: isolating consensus code is a topic i've noticed you come back to repeatedly over time. a good topic for the next coredev...
12:16 < wumpus> an probably not a big thing in risk-reduction in general
12:16 < sipa> jonatack: and every coredev since 2015 or so ;)
12:16 < jonatack> heh
12:16 < wumpus> jonatack: yess
12:16 < jnewbery> wumpus: adding wizzy new c++17 features makes it even huger (conceptually)
12:16 < wumpus> jnewbery: I'm not convinced about that, I don't think there's anythign specific or whizzy about c++17 features
12:17 < wumpus> jnewbery: are there any you *specifcially* take offense to?
12:17 < sipa> jnewbery: maybe... but specifically here, if you didn't know about the pthread thing... wouldn't you think that replacing boost::shared_mutex with std::shared_mutex is reducing risk surface?
12:17 < wumpus> sipa: yes, that
12:17 < Kiminuo> https://github.com/bitcoin/bitcoin/pull/19245 - Do I understand correctly that this is dead for foreseeable future?
12:17 < ja> wumpus: did you see the discussion on string_view?
12:17 < jnewbery> I'm not sure we should use string_views
12:17 < MarcoFalke> we already use the features. Either through boost, or through more verbose C++11 code
12:18 < wumpus> yes, I think isolating the conensus code would be most bang for buck with regard to risk minimalization
12:18 < jnewbery> ja: which discussion?
12:18 -!- evanpro [~evanpro@195.206.169.184] has quit [Remote host closed the connection]
12:18 < wumpus> make it clear which areas of the code are the really risky ones that could break bitcoin as a thing
12:18 < ja> jnewbery: ah i just meant the comments in the issue #16684 
12:18 < gribble> https://github.com/bitcoin/bitcoin/issues/16684 | Discussion: upgrading to C++17 · Issue #16684 · bitcoin/bitcoin · GitHub
12:18 < wumpus> bitcoin core is too big
12:19 < sipa> happy to see renewed activity on that front with dongcarl's recent PRs
12:19 < wumpus> but I've been screaming into the void about this since forever, I'm happy dongcarl1 picked up on it
12:19 < wumpus> yes
12:19 < jnewbery> ja: I hadn't seen that but my instinct is to agree with practicalswift - it introduces very sharp edges
12:19 < jonatack> jnewbery: in any case for my own work and reviewing, I'll be following your cautious approach
12:20 < jnewbery> new features aren't dangerous just because they may have bugs. They're also dangerous because developers might not know how to use them safely
12:20 < sipa> i think introducing a new features/concepts should always be a red flag for review
12:20 < jnewbery> I trust sipa to use spans correctly, but I wouldn't encourage their use by everyone
12:20 < wumpus> that's different for everyone though, and just as true for old crufty featurs
12:20 < wumpus> (e.g. does anyone know about c++ multiple inheritance specifics?)
12:21 < jnewbery> spans and string_views are objectively more dangeroush than other language features
12:21 < michaelfolkson> We certainly can't have a guide that says if you are sipa you can use it and if you are not you can't haha
12:21 < luke-jr> why are we switching to spans if they're so hard to use?
12:21 < wumpus> jnewbery: well if it's a replacement for void*, size_t 
12:21 < wumpus> jnewbery: it isn't any less safe
12:21 < sipa> jnewbery: (playing the devil's advocate here) i think they're less dangerous than points and lengths passed manually
12:21 < sipa> *pointers
12:21 < wumpus> all the span refactores have been that
12:21 < wumpus> just that
12:22 < wumpus> sipa: right
12:22 < wumpus> it makes things conceptually clearer than a pair of pointers and lengths
12:22 < wumpus> that's all, it shouldn't replace owned objects
12:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:23 < bitcoin-git> [bitcoin] practicalswift opened pull request #20380: doc: Add instructions on how to fuzz the P2P layer using Honggfuzz NetDriver (master...honggfuzz-p2p-fuzzing) https://github.com/bitcoin/bitcoin/pull/20380
12:23  * jonatack taking notes on the consensus isolation mentions
12:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:23 < ja> by using a data-type, it also allows the compiler to understand more invariants about your code
12:23 < MarcoFalke> I think it would be very concerning if people ACK code changes that use features they don't know how to use safely 
12:23 < ja> a compiler could have specific protections when using Span, that wouldn't otherwise be used
12:23 < MarcoFalke> *ACKed
12:23 < wumpus> MarcoFalke: yes
12:24 < sipa> ja: about that, can some people please review #19387
12:24 < gribble> https://github.com/bitcoin/bitcoin/issues/19387 | span: update constructors to match c++20 draft spec and add lifetimebound attribute by theuni · Pull Request #19387 · bitcoin/bitcoin · GitHub
12:24 < MarcoFalke> code review is our best effort protecting against bad code
12:24 < MarcoFalke> Developer notes certainly do help to clarify guidelines
12:24 < wumpus> it's good to be cautious anyway, but I don't think making an explicit list of everything is going to help
12:25 < wumpus> and if we're worried about string_view and spans specifically then we should be careful to review changes introducing those carefully
12:25 < wumpus> that's a good point and at least a specific one
12:25 < wumpus> but we can't go over everything and make a risk estimate upfront
12:26 < michaelfolkson> Can I ask about fuzzing? At the moment fuzzing seems to be a two man show (practicalswift and MarcoFalke). Is there anything additional we can do to get more people to engage with fuzzing?
12:26 < jnewbery> I'd be wary of anyone adding try_emplace since the interface is so confusing
12:27 < MarcoFalke> michaelfolkson: You can help by writing fuzzers, reviewing fuzz pull requests, or run the fuzz engine youself and contribute seeds (hopefully ones that don't trigger bugs)
12:27 < sipa> michaelfolkson: i've been adding elaborate fuzzers in several of my recent bigger PRs
12:27 < michaelfolkson> Do you do all your fuzzing on your laptop MarcoFalke? It takes hours sometimes
12:27 < wumpus> michaelfolkson: is there good documentation on how to get started?
12:28 < MarcoFalke> michaelfolkson: wumpus doc/fuzzing.md
12:28 < wumpus> thanks
12:28 < sipa> i'd encourage everyone to do the same... 
12:28 < wumpus> I don't have any big CPUs though
12:28 < sipa> i'm less convinced about writing generic fuzzers for code you're not already familiar with
12:28 < MarcoFalke> michaelfolkson: I use my laptop with a fuzz engine, sometimes vim to create seeds. I am also running a server 24/7
12:29 < sipa> it's useful in the long term, but may need very long fuzzing times to hit anything interesting (much less actual issues)
12:29 < michaelfolkson> I think the docs could be improved (but I can't criticise if I haven't tried to improve them)
12:30 < MarcoFalke> michaelfolkson: If there is an issue with the docs you can file a bug (or fix them)
12:30 < michaelfolkson> It is daunting though when they can take hours to run. And there were troubleshooting issues on Mac which I'm going to avoid by running them on Linux instead
12:30 < MarcoFalke> sipa: Agree. The best fuzzers are the ones that trigger the most already-fixed bugs
12:30 < michaelfolkson> Right MarcoFalke. I will try to do this. But lots I don't know currently
12:30 < sipa> michaelfolkson: i run mine on my 16-core desktop, let it run overnight... all actual problems i've found are within minutes/hours of running
12:31 < sipa> (but this is for fuzzers written with very intimite knowledge of what they're testing)
12:31 -!- cfields [~cfields@unaffiliated/cfields] has joined #bitcoin-core-dev
12:32 < jonatack> michaelfolkson: fuzzers aren't an issue to run overnight to review PRs, or even for a few minutes if you're tight on time as a sanity check and describe that in your review
12:33 < jonatack> (i have an older 4-core cpu)
12:33 -!- flukiluke1 [~flukiluke@185.204.1.185] has joined #bitcoin-core-dev
12:33 < michaelfolkson> By a few minutes you mean run them and stop them hours before completion jonatack?
12:34 < jonatack> michaelfolkson: they run until you halt them or they hit an issue
12:34 < sipa> fuzzing never completes
12:34 < wumpus> fuzzers never 'complete' do they
12:34 < wumpus> sipa: heh
12:34 < jonatack> michaelfolkson: when reviewing, sometimes running them for less than a minute finds things, e.g. was the case for the BIP324 implementation
12:35 < sipa> i found several issues while developing txrequest by writing a fuzzer in parallel with it... it found several crashing bugs within minutes
12:35 < jonatack> ^
12:35 < michaelfolkson> Does that mean everyone who fuzzes for a few minutes are fuzzing the same thing? And everything else doesn't get "fuzzed"
12:35 < sipa> (all before it was PR'ed, and in some cases, started over)
12:35 < sipa> michaelfolkson: it's making random variations in the seeds, and see if those trigger anything
12:36 < sipa> it's somewhat coverage directed, the fuzzer "learns" what things are potentially relevant and what it isn't
12:36 < wumpus> there's a large degree of randomness involved so no one will be testing exactly the same thing
12:36 < sipa> but it's really just trying random things
12:36 < michaelfolkson> Ah ok. So the randomness ensures different things get "fuzzed"
12:36 < sipa> fuzzing == "introducing random variations"
12:37 < sipa> we do need a bitcoin core specific fuzzing farm that can run fuzzers with months of CPU time though
12:37 < jonatack> there were two really good Review Club meetings on fuzzing
12:37 < jonatack> https://bitcoincore.reviews/17860
12:37 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:37 < michaelfolkson> Yup. Still have lots and lots of questions though ;)
12:38 < sipa> shouldn't be too hard to find hardware
12:38 < jonatack> https://bitcoincore.reviews/18521
12:39 < michaelfolkson> It certainly seems to me the ultimate goal should be guidance on what will be done on a fuzzing farm and what should be done on individual machines
12:40 < sipa> michaelfolkson: why would there be a difference?
12:40 < MarcoFalke> michaelfolkson: fuzzing should be done
12:40 < ja> michaelfolkson: you could engineer a test that breaks only when path A getting taken exactly a million times, and then path B is taken once. if that is a "different thing", your use of "ensures" is wrong ;)
12:40 < MarcoFalke> It is additive. Running two machines is better than running one machine
12:40 < michaelfolkson> Targeted fuzzing on individual machines. Mass comprehensive fuzzing on a fuzzing farm?
12:41 < michaelfolkson> Would that not be the end goal?
12:41 < sipa> what is "targetted fuzzing" ?
12:41 < sipa> i'll run fuzzers myself locally for code i'm developing if it includes a fuzzer
12:42 < michaelfolkson> " i'm less convinced about writing generic fuzzers for code you're not already familiar with"
12:42 < michaelfolkson> s/targeted/non-generic
12:43 < ja> what's wrong with writing tests for code you don't know? you'll learn the true invariants even if you try to break invariants that don't exist
12:43 < sipa> if we had a server farm, and it's orders of magnitude more compute power than what i can do personally, i wouldn't bother with doing anything else myself
12:43 < MarcoFalke> ja: Nothing wrong, but tests that don't find issues are not that useful
12:43 < sipa> that's not the case though - and all fuzzing right now is people individually running fuzzers
12:43 < sipa> ja: if you do learn, it's a great exercise
12:44 < michaelfolkson> It is a time issue. Only 24 hours in a day
12:44 < ja> MarcoFalke: right, but given that you may find an issue, that could be fixed even if the fuzzing setup doesn't get merged, i think it should be encouraged ;)
12:44 < sipa> michaelfolkson: that was about *writing* fuzzers, not running them
12:44 < MarcoFalke> michaelfolkson: With 2 CPUs there are 48 CPU hours in one day
12:44 < michaelfolkson> Haha ok
12:44 < ja> the bottleneck is always the reviewing, right? but if you find a true invariant getting broken, that is still valuable if the fuzzer doesn't get merged
12:45 < MarcoFalke> ja: Indeed. I am not discouraging anyone to write tests.
12:45 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
12:45 < sipa> my view is that many fuzzers we currently have are very superficial, because they're written by someone who doesn't know what they should be testing
12:46 < sipa> that doesn't mean they're useless, or that i want to discourage people from doing so
12:46 < sipa> but i think there is more value in first understanding the code deeper, and then writing more targetted tests
12:46 < michaelfolkson> The problem is not understanding the Core codebase and history of bugs rather than understanding fuzzing?
12:47 < michaelfolkson> This isn't a "general expertise" in fuzzing issue?
12:47 < MarcoFalke> I do think we have a shortage of expertise 
12:52 < sipa> i think there is a useful question to be answered that probably isn't too hard with people unfamiliar with the codebase: can we reasonably merge multiple fuzzers into a single binary (and have the actual fuzzer selected by a command line argument)
12:53 < MarcoFalke> sipa: for the fuzz engine it shouldn't make a difference
12:53 < sipa> we know that it is bad to mix multiple feature tests into one fuzzer (e.g. by using the first N bytes of the input to select the feature), as the fuzz engine will try to cross-pollinate to no avail
12:54 < sipa> but right now the build dir for fuzzing is gigabytes
12:54 < MarcoFalke> the seeds are also gigabytes
12:55 < MarcoFalke> I'll probably create a pull to create a single binary after the branch-off
12:55 < MarcoFalke> then, they can also be compiled normally (by default)
12:55 < MarcoFalke> for non-fuzz builds
12:56 < sipa> yeah, it's not just a space issue, also compile time
12:56 < sipa> running the full linker 100s of times
12:56 < MarcoFalke> why can't ccache cache the linker result?
12:57 < sipa> i'm not sure if linking is ccached, actually
12:58 < sipa> but does it matter? any code change in say net_processing.cpp means all fuzzers have to be fully relinked
12:58 < MarcoFalke> fair enough
12:59 < sipa> MarcoFalke: so you're convinced it doesn't matter for the fuzzing engine?
12:59 < MarcoFalke> why should it?
12:59 < sipa> that sounds reasonable to me, but i thought we'd want to have some kind of benchmark first
12:59 < sipa> more reachable code or something
12:59 < sipa> i don't know exactly how the fuzzing engine reasons about those things
13:00 -!- flukiluke1 [~flukiluke@185.204.1.185] has quit []
13:00 < sipa> qa-assets directory is 1.3 GiB for me; a full build in fuzz mode is 7.3 GiB
13:00 < MarcoFalke> It might break symbolic execution, but we don't use that
13:00 < sipa> what's symbolic execution?
13:02 < MarcoFalke> Not using values, but symbols (as in math) for detecting violating conditions
13:02 < sipa> ok, i knew that... i mean specifially in the context of fuzzing
13:02 < sipa> are there fuzz engines that can take advantage of that?
13:03 < MarcoFalke> yes, but I haven't tried them
13:04 < sipa> ah cool
13:04 < MarcoFalke> https://www.youtube.com/watch?v=h_A8IRBEtdQ
13:05 < MarcoFalke> :( Can't play it anymore. Looks like youtube deleted all webm transcodings for videos with less than 10k views
13:07 < sipa> works fine here?
13:08 < michaelfolkson> Works for me fine in the browser
13:10 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 265 seconds]
13:10 < queip> MarcoFalke: works for me, YT has outage yesterday, perhaps it's stay intermittent in some places 
13:12 < MarcoFalke> oh, it is WEBM DASH
13:12 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
13:13 < MarcoFalke> hmm https://bugzilla.mozilla.org/show_bug.cgi?id=778617 
13:20 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:22 < ja> michaelfolkson: which codec is it using?
13:23 -!- James_F1 [~James_F@178.162.212.214] has joined #bitcoin-core-dev
13:29 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
13:36 -!- nckx [~nckx@tobias.gr] has quit [Ping timeout: 264 seconds]
13:49 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]
13:51 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
13:54 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has joined #bitcoin-core-dev
13:57 < troygiorshev> !topic
13:57 < gribble> 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
14:00 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 258 seconds]
14:06 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev
14:08 -!- filchef [~filchef@212.104.97.177] has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
14:08 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
14:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
14:12 -!- vasild_ is now known as vasild
14:19 -!- TheRec [~toto@drupal.org/user/146860/view] has quit []
14:24 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
14:28 -!- Kiminuo [~mix@141.98.103.92] has quit [Ping timeout: 256 seconds]
14:31 -!- proofofkeags [~proofofke@174-16-205-160.hlrn.qwest.net] has quit [Ping timeout: 244 seconds]
14:32 -!- nckx [~nckx@tobias.gr] has joined #bitcoin-core-dev
14:33 -!- sr_gi [~sr_gi@static-120-201-229-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
14:34 -!- sr_gi [~sr_gi@static-120-201-229-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
14:43 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-dev
14:57 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
15:07 -!- davterra [~davterra@69.4.234.71] has quit [Read error: Connection reset by peer]
15:08 -!- davterra [~davterra@69.4.234.71] has joined #bitcoin-core-dev
15:08 -!- nanotube [~nanotube@unaffiliated/nanotube] has quit [Ping timeout: 240 seconds]
15:12 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
15:16 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-core-dev
15:19 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
15:21 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds]
15:21 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #bitcoin-core-dev
15:26 -!- bralyclow2 [~bralyclow@unaffiliated/bralyclow] has joined #bitcoin-core-dev
15:26 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
15:55 -!- mol_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
15:55 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
15:57 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds]
16:00 -!- James_F1 [~James_F@178.162.212.214] has quit []
16:02 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #bitcoin-core-dev
16:13 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-91-208.revip7.asianet.co.th] has joined #bitcoin-core-dev
16:20 -!- dongcarl1 is now known as dongcarl
16:22 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
16:22 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
16:23 -!- |Kin| [~|Kin|@184.75.221.115] has joined #bitcoin-core-dev
16:25 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
16:25 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
16:28 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Quit: Leaving]
16:29 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
16:30 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
16:32 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
16:32 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
16:40 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
16:49 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
17:09 -!- |Kin| [~|Kin|@184.75.221.115] has quit [Ping timeout: 260 seconds]
17:17 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 240 seconds]
17:18 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
17:18 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
17:24 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
17:36 -!- Tennis [~Tennis@unaffiliated/tennis] has quit [Read error: Connection reset by peer]
17:41 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 256 seconds]
17:41 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Remote host closed the connection]
17:42 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #bitcoin-core-dev
17:45 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
17:52 -!- kristapsk_ is now known as kristapsk
17:54 -!- meetingology1 [~meetingol@185.204.1.185] has joined #bitcoin-core-dev
18:28 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds]
18:43 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
18:45 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 264 seconds]
18:49 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
18:50 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 240 seconds]
18:52 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
18:54 -!- davterra [~davterra@69.4.234.71] has quit [Remote host closed the connection]
18:54 -!- davterra [~davterra@69.4.234.71] has joined #bitcoin-core-dev
19:00 -!- meetingology1 [~meetingol@185.204.1.185] has quit []
19:03 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
19:16 -!- m9aq [~m9aq@106.37.187.213] has joined #bitcoin-core-dev
19:22 -!- DpEpsilon1 [~DpEpsilon@84.39.117.57] has joined #bitcoin-core-dev
19:37 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
19:38 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-91-208.revip7.asianet.co.th] has quit [Ping timeout: 260 seconds]
19:40 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
19:43 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-91-208.revip7.asianet.co.th] has joined #bitcoin-core-dev
19:48 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
19:48 < bitcoin-git> [bitcoin] fanquake closed pull request #20336: build: automatically determine macOS base translations (master...auto_find_translations) https://github.com/bitcoin/bitcoin/pull/20336
19:48 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
19:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
19:50 < bitcoin-git> [bitcoin] fanquake closed pull request #19068: build: Use a zip instead of dmg for macOS releases (master...macdeploy_zip_instead_of_dmg) https://github.com/bitcoin/bitcoin/pull/19068
19:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
19:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
19:57 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
20:32 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-91-208.revip7.asianet.co.th] has quit [Ping timeout: 260 seconds]
21:01 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-dev
21:27 -!- ajonas_ [uid385278@gateway/web/irccloud.com/x-vbrpaonosufznwgi] has quit [Quit: Connection closed for inactivity]
21:46 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 240 seconds]
22:00 -!- DpEpsilon1 [~DpEpsilon@84.39.117.57] has quit []
22:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
22:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:20 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0bd4929cd00e...99fcc2b4778f
22:20 < bitcoin-git> bitcoin/master 0ccb3ad practicalswift: tests: Remove no longer needed UBSan suppression (float-divide-by-zero in ...
22:20 < bitcoin-git> bitcoin/master 99fcc2b MarcoFalke: Merge #20379: tests: Remove no longer needed UBSan suppression (float divi...
22:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:21 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #20379: tests: Remove no longer needed UBSan suppression (float divide-by-zero in validation.cpp) (master...remove-ubsan-suppressions) https://github.com/bitcoin/bitcoin/pull/20379
22:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:38 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
22:40 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
22:40 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds]
22:41 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection]
22:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:42 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/99fcc2b4778f...28cb61646b29
22:42 < bitcoin-git> bitcoin/master e6bb9fd practicalswift: tests: Add fuzzing harness for CAddrMan
22:42 < bitcoin-git> bitcoin/master d04a17a practicalswift: fuzz: Use ConsumeRandomLengthBitVector(...) in src/test/fuzz/connman and s...
22:42 < bitcoin-git> bitcoin/master 28cb616 MarcoFalke: Merge #19065: tests: Add fuzzing harness for CAddrMan
22:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:43 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #19065: tests: Add fuzzing harness for CAddrMan (master...fuzzers-2020-05-23) https://github.com/bitcoin/bitcoin/pull/19065
22:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:50 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #bitcoin-core-dev
22:56 -!- aki_ [~aki_@139.28.218.148] has joined #bitcoin-core-dev
23:07 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 260 seconds]
23:07 -!- AdulrunaRedviva [c3d69d22@195.214.157.34] has joined #bitcoin-core-dev
23:09 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
23:10 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has joined #bitcoin-core-dev
23:13 -!- m9aq [~m9aq@106.37.187.213] has quit [Quit: m9aq]
23:13 -!- ctrlbreak [~ctrlbreak@159.2.182.106] has quit [Ping timeout: 246 seconds]
23:19 -!- AdulrunaRedviva [c3d69d22@195.214.157.34] has quit [Ping timeout: 245 seconds]
23:20 -!- cltrbreak_MAD2 [~ctrlbreak@159.2.182.106] has joined #bitcoin-core-dev
23:23 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has quit [Ping timeout: 264 seconds]
23:24 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has joined #bitcoin-core-dev
23:27 -!- cltrbreak_MAD2 [~ctrlbreak@159.2.182.106] has quit [Ping timeout: 256 seconds]
23:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:27 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/28cb61646b29...543693b92b95
23:27 < bitcoin-git> bitcoin/master 440f8d3 Jonas Schnelli: fix potential devision by 0
23:27 < bitcoin-git> bitcoin/master 543693b Jonas Schnelli: Merge #20378: wallet: fix potential division by 0 in WalletLogPrintf
23:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:27 < bitcoin-git> [bitcoin] jonasschnelli merged pull request #20378: wallet: fix potential division by 0 in WalletLogPrintf (master...2020/11/fix_devnull_wallet) https://github.com/bitcoin/bitcoin/pull/20378
23:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:33 -!- m9aq [~m9aq@106.37.187.213] has joined #bitcoin-core-dev
23:36 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
23:56 -!- glozow [uid453516@gateway/web/irccloud.com/x-bxytrqtdrqgdakox] has quit [Quit: Connection closed for inactivity]
--- Log closed Fri Nov 13 00:00:15 2020