--- Log opened Mon May 06 00:00:04 2019 00:03 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 00:07 -!- riperk [uid352992@gateway/web/irccloud.com/x-sfazftlxxqsxwfyn] has quit [Quit: Connection closed for inactivity] 00:08 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 246 seconds] 00:23 -!- roconnor [~roconnor@2600:1700:4570:fe1:3db2:7bfb:2a36:77bb] has joined #bitcoin-core-dev 00:23 -!- roconnor_ [~roconnor@host-104-157-228-210.dyn.295.ca] has quit [Ping timeout: 255 seconds] 00:28 -!- chaus [~chaus@81.193.44.230] has quit [Remote host closed the connection] 00:36 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has quit [Ping timeout: 276 seconds] 00:37 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has joined #bitcoin-core-dev 00:41 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 00:42 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 00:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds] 00:45 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 00:46 -!- lukedashjr is now known as luke-jr 00:59 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [] 01:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 01:05 < bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/d7d7d3150606...9bbaac73bb1f 01:05 < bitcoin-git> bitcoin/master 77851ab Luke Dashjr: GUI: Refactor actual QR code rendering into new QRImageWidget::setQR 01:05 < bitcoin-git> bitcoin/master fc92984 Luke Dashjr: GUI: Move QRImageWidget to its own file-pair 01:05 < bitcoin-git> bitcoin/master 9bbaac7 Wladimir J. van der Laan: Merge #15928: GUI: Move QRImageWidget to its own file-pair 01:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 01:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 01:06 < bitcoin-git> [bitcoin] laanwj merged pull request #15928: GUI: Move QRImageWidget to its own file-pair (master...split_qrencoder) https://github.com/bitcoin/bitcoin/pull/15928 01:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 01:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 01:08 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9bbaac73bb1f...773e16f9190f 01:08 < bitcoin-git> bitcoin/master 00d1104 Daniel Kraft: Install bitcoin-wallet manpage. 01:08 < bitcoin-git> bitcoin/master 773e16f Wladimir J. van der Laan: Merge #15947: Install bitcoin-wallet manpage 01:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 01:08 -!- ccdle12 [~ccdle12@103.5.140.151] has quit [Remote host closed the connection] 01:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 01:08 < bitcoin-git> [bitcoin] laanwj merged pull request #15947: Install bitcoin-wallet manpage (master...install-wallet-man) https://github.com/bitcoin/bitcoin/pull/15947 01:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 01:11 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 01:19 -!- chaus [~chaus@81.193.44.230] has joined #bitcoin-core-dev 01:22 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 01:26 -!- ralphaaboy [9a7b97e2@gateway/web/freenode/ip.154.123.151.226] has joined #bitcoin-core-dev 01:28 -!- ralphaaboy [9a7b97e2@gateway/web/freenode/ip.154.123.151.226] has quit [Client Quit] 01:30 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 01:34 -!- shesek [~shesek@5.22.134.182] has joined #bitcoin-core-dev 01:34 -!- shesek [~shesek@5.22.134.182] has quit [Changing host] 01:34 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 01:35 -!- fredcooke1 [~fredcooke@184.75.223.195] has quit [Remote host closed the connection] 01:39 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 01:40 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 01:42 -!- chaus [~chaus@81.193.44.230] has quit [Remote host closed the connection] 01:44 -!- andyvk5 [~andyvk5@185.204.1.185] has joined #bitcoin-core-dev 01:48 -!- rex4539 [~rex4539@ppp-94-66-20-149.home.otenet.gr] has joined #bitcoin-core-dev 02:00 -!- andyvk5 [~andyvk5@185.204.1.185] has quit [] 02:11 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 02:13 -!- ccdle12 [~ccdle12@SODcd-03p21-215.ppp11.odn.ad.jp] has joined #bitcoin-core-dev 02:19 -!- chaus [~chaus@81.193.44.230] has joined #bitcoin-core-dev 02:23 -!- chaus [~chaus@81.193.44.230] has quit [Remote host closed the connection] 02:23 -!- rex4539 [~rex4539@ppp-94-66-20-149.home.otenet.gr] has quit [Quit: rex4539] 02:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 02:37 < bitcoin-git> [bitcoin] laanwj pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/773e16f9190f...a3d2d6b0674c 02:37 < bitcoin-git> bitcoin/master fad40ec MarcoFalke: wallet: Use IsValidNumArgs in getwalletinfo rpc 02:37 < bitcoin-git> bitcoin/master fad13e9 MarcoFalke: rpcwallet: Make helper methods const on CWallet 02:37 < bitcoin-git> bitcoin/master 999931c MarcoFalke: rpc: Add getbalances RPC 02:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 02:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 02:38 < bitcoin-git> [bitcoin] laanwj merged pull request #15930: rpc: Add balances RPC (master...1904-rpcWalletBalances) https://github.com/bitcoin/bitcoin/pull/15930 02:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 02:39 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 02:40 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has joined #bitcoin-core-dev 02:50 -!- chaus [~chaus@81.193.44.230] has joined #bitcoin-core-dev 02:53 -!- chaus [~chaus@81.193.44.230] has quit [Remote host closed the connection] 03:00 -!- chaus [~chaus@81.193.44.230] has joined #bitcoin-core-dev 03:03 -!- benj1 [~benj@185.204.1.185] has joined #bitcoin-core-dev 03:08 -!- chaus [~chaus@81.193.44.230] has quit [Remote host closed the connection] 03:12 -!- chaus [~chaus@bl4-44-230.dsl.telepac.pt] has joined #bitcoin-core-dev 03:14 -!- scoop [~scoop@205.178.77.52] has joined #bitcoin-core-dev 03:15 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 250 seconds] 03:16 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 03:16 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Ping timeout: 244 seconds] 03:18 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 245 seconds] 03:29 -!- jonatack [6d0d4c36@gateway/web/freenode/ip.109.13.76.54] has joined #bitcoin-core-dev 03:30 -!- rex4539 [~rex4539@ppp-94-66-20-149.home.otenet.gr] has joined #bitcoin-core-dev 03:34 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-dev 03:36 -!- rex4539 [~rex4539@ppp-94-66-20-149.home.otenet.gr] has quit [Quit: rex4539] 03:36 -!- benj1 [~benj@185.204.1.185] has quit [Remote host closed the connection] 03:37 -!- rex4539 [~rex4539@ppp-94-69-228-154.home.otenet.gr] has joined #bitcoin-core-dev 03:38 -!- ccdle12_ [~ccdle12@SODcd-03p21-215.ppp11.odn.ad.jp] has joined #bitcoin-core-dev 03:38 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 03:41 -!- ccdle12 [~ccdle12@SODcd-03p21-215.ppp11.odn.ad.jp] has quit [Ping timeout: 250 seconds] 03:45 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 03:46 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 03:48 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds] 04:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 04:10 -!- chaus [~chaus@bl4-44-230.dsl.telepac.pt] has quit [Remote host closed the connection] 04:18 -!- Guest48528 [~jdolan@84.39.117.57] has joined #bitcoin-core-dev 04:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:38 < bitcoin-git> [bitcoin] laanwj pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/a3d2d6b0674c...c5ffe8d5155b 04:38 < bitcoin-git> bitcoin/master 2ee811e João Barbosa: wallet: Track scanning duration 04:38 < bitcoin-git> bitcoin/master 90e27ab João Barbosa: wallet: Track current scanning progress 04:38 < bitcoin-git> bitcoin/master d3e8458 João Barbosa: rpc: Show scanning details in getwalletinfo 04:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:39 < bitcoin-git> [bitcoin] laanwj merged pull request #15730: rpc: Show scanning details in getwalletinfo (master...2019-04-getwalletinfo-scanning) https://github.com/bitcoin/bitcoin/pull/15730 04:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:39 -!- chaus [~chaus@81.193.44.230] has joined #bitcoin-core-dev 04:44 -!- chaus [~chaus@81.193.44.230] has quit [Ping timeout: 248 seconds] 04:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:45 < bitcoin-git> [bitcoin] meshcollider opened pull request #15957: Show "No wallets available" in open menu instead of nothing (master...201905_openwallet_empty) https://github.com/bitcoin/bitcoin/pull/15957 04:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:46 -!- chaus [~chaus@81.193.44.230] has joined #bitcoin-core-dev 04:52 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds] 05:00 -!- Guest48528 [~jdolan@84.39.117.57] has quit [] 05:05 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 05:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:05 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 05:13 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 05:32 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 05:33 -!- secdragon [~secdragon@185.204.1.185] has joined #bitcoin-core-dev 05:35 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 05:44 -!- chaus [~chaus@81.193.44.230] has quit [Remote host closed the connection] 05:46 -!- chaus [~chaus@81.193.44.230] has joined #bitcoin-core-dev 05:51 -!- chaus [~chaus@81.193.44.230] has quit [Ping timeout: 250 seconds] 06:04 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 06:07 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 248 seconds] 06:07 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 06:09 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 246 seconds] 06:11 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 06:12 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 06:18 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds] 06:19 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Ping timeout: 248 seconds] 06:20 -!- jonatack [6d0d4c36@gateway/web/freenode/ip.109.13.76.54] has quit [] 06:29 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 244 seconds] 06:30 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 06:40 -!- shesek [~shesek@5.102.219.164] has joined #bitcoin-core-dev 06:40 -!- shesek [~shesek@5.102.219.164] has quit [Changing host] 06:40 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 06:41 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Remote host closed the connection] 06:41 -!- fasfasdfasfd [3e1cd796@gateway/web/freenode/ip.62.28.215.150] has joined #bitcoin-core-dev 06:45 -!- fasfasdfasfd [3e1cd796@gateway/web/freenode/ip.62.28.215.150] has quit [Client Quit] 06:45 -!- scoop [~scoop@205.178.77.52] has joined #bitcoin-core-dev 06:47 -!- Mirko_ [4f3737cd@gateway/web/freenode/ip.79.55.55.205] has joined #bitcoin-core-dev 06:49 -!- scoop [~scoop@205.178.77.52] has quit [Ping timeout: 248 seconds] 06:52 -!- chaus [~chaus@81.193.44.230] has joined #bitcoin-core-dev 06:56 -!- promag_ [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 06:57 -!- chaus [~chaus@81.193.44.230] has quit [Ping timeout: 248 seconds] 06:58 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev 07:03 -!- davterra [~tralfaz@178.128.106.205] has quit [Quit: Leaving] 07:03 -!- rex4539 [~rex4539@ppp-94-69-228-154.home.otenet.gr] has quit [Quit: rex4539] 07:09 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 07:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 07:19 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #15959: refactor: Work around gcc compiler bug 90348 (master...1905-gccBugWorkaround) https://github.com/bitcoin/bitcoin/pull/15959 07:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 07:25 -!- dfsg [~dfsg@unaffiliated/dfsg] has joined #bitcoin-core-dev 07:25 -!- dfsg [~dfsg@unaffiliated/dfsg] has left #bitcoin-core-dev [] 07:31 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 07:34 -!- chaus [~chaus@bl4-44-230.dsl.telepac.pt] has joined #bitcoin-core-dev 07:50 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 08:00 -!- secdragon [~secdragon@185.204.1.185] has quit [] 08:04 -!- manuel3 [~manuel@84.39.117.57] has joined #bitcoin-core-dev 08:09 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:10 -!- IGHOR [~quassel@93.178.216.72] has quit [Quit: http://quassel-irc.org ? ??????????? ?????????. ????-??.] 08:13 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Ping timeout: 255 seconds] 08:14 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev 08:15 -!- promag_ [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection] 08:17 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 08:18 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Ping timeout: 248 seconds] 08:21 -!- dcousens [~dcousens@124.189.34.146] has quit [Ping timeout: 258 seconds] 08:22 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev 08:23 -!- dcousens [~dcousens@124.182.32.122] has joined #bitcoin-core-dev 08:27 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 245 seconds] 08:28 -!- dcousens [~dcousens@124.182.32.122] has quit [Ping timeout: 258 seconds] 08:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 08:34 < bitcoin-git> [bitcoin] Annasadra opened pull request #15960: git (master...master) https://github.com/bitcoin/bitcoin/pull/15960 08:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 08:34 -!- dcousens [~dcousens@124.182.33.29] has joined #bitcoin-core-dev 08:39 -!- jonatack [58aba822@gateway/web/freenode/ip.88.171.168.34] has joined #bitcoin-core-dev 08:39 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 08:40 -!- chaus [~chaus@bl4-44-230.dsl.telepac.pt] has quit [Remote host closed the connection] 08:40 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:43 -!- Mirko_ [4f3737cd@gateway/web/freenode/ip.79.55.55.205] has quit [Ping timeout: 256 seconds] 08:43 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 08:44 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Ping timeout: 245 seconds] 08:55 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 08:56 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:57 -!- rex4539 [~rex4539@athedsl-171280.home.otenet.gr] has joined #bitcoin-core-dev 08:59 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 08:59 -!- dcousens [~dcousens@124.182.33.29] has quit [Ping timeout: 252 seconds] 08:59 -!- scoop_ [~scoop@ip-173-137-236-91.chcgil.spcsdns.net] has joined #bitcoin-core-dev 08:59 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Read error: Connection reset by peer] 09:00 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:01 -!- ccdle12_ [~ccdle12@SODcd-03p21-215.ppp11.odn.ad.jp] has quit [Remote host closed the connection] 09:04 -!- scoop_ [~scoop@ip-173-137-236-91.chcgil.spcsdns.net] has quit [Ping timeout: 248 seconds] 09:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 09:08 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #15960: git (master...master) https://github.com/bitcoin/bitcoin/pull/15960 09:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 09:11 -!- chaus [~chaus@bl4-44-230.dsl.telepac.pt] has joined #bitcoin-core-dev 09:16 -!- chaus [~chaus@bl4-44-230.dsl.telepac.pt] has quit [Ping timeout: 246 seconds] 09:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 09:36 < bitcoin-git> [bitcoin] practicalswift opened pull request #15962: Add locking annotation for RewindBlockIndex (requires holding cs_main) (master...RewindBlockIndex) https://github.com/bitcoin/bitcoin/pull/15962 09:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 09:46 -!- roconnor_ [~roconnor@2600:1700:4570:fe1:113a:8cc7:57de:58be] has joined #bitcoin-core-dev 09:47 -!- roconnor [~roconnor@2600:1700:4570:fe1:3db2:7bfb:2a36:77bb] has quit [Ping timeout: 264 seconds] 09:52 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev 09:53 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 09:54 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:56 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 09:56 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 10:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 10:01 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/c5ffe8d5155b...8ec7121a4590 10:01 < bitcoin-git> bitcoin/master ba534cc John Newbery: [tests] log thread names by default in functional tests 10:01 < bitcoin-git> bitcoin/master 7b29ec2 John Newbery: [tests] Comment for why logging config is set as command-line args. 10:01 < bitcoin-git> bitcoin/master 8ec7121 MarcoFalke: Merge #15927: [tests] log thread names by default in functional tests 10:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 10:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 10:01 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15927: [tests] log thread names by default in functional tests (master...2019-04-log-threads-tests) https://github.com/bitcoin/bitcoin/pull/15927 10:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 10:02 -!- promag_ [~promag@83.223.234.100] has joined #bitcoin-core-dev 10:17 -!- chaus [~chaus@bl4-44-230.dsl.telepac.pt] has joined #bitcoin-core-dev 10:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 10:19 < bitcoin-git> [bitcoin] jnewbery opened pull request #15963: [tests] Make random seed logged and settable (master...2019-05-test-deterministic-randomness) https://github.com/bitcoin/bitcoin/pull/15963 10:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 10:20 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 10:22 -!- chaus [~chaus@bl4-44-230.dsl.telepac.pt] has quit [Ping timeout: 246 seconds] 10:22 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 10:27 -!- chaus [~chaus@81.193.44.230] has joined #bitcoin-core-dev 10:34 -!- davterra [~tralfaz@178.128.106.205] has joined #bitcoin-core-dev 10:40 -!- omonk [~omonk@unaffiliated/omonk] has quit [Quit: quit] 10:41 -!- omonk [~omonk@unaffiliated/omonk] has joined #bitcoin-core-dev 10:51 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 10:52 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:57 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 10:57 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 10:59 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev 11:00 -!- manuel3 [~manuel@84.39.117.57] has quit [] 11:00 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 11:02 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Ping timeout: 252 seconds] 11:04 -!- obsrver [~quassel@p5DC6BDE0.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 11:06 -!- Suntop1 [~Suntop@178.162.209.171] has joined #bitcoin-core-dev 11:18 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Read error: Connection reset by peer] 11:21 -!- _Sam-- [~greybits@unaffiliated/greybits] has joined #bitcoin-core-dev 11:22 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 11:24 -!- promag_ [~promag@83.223.234.100] has quit [Remote host closed the connection] 11:30 -!- jarthur_ [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 11:33 -!- jarthur [~jarthur@207.114.244.5] has quit [Ping timeout: 245 seconds] 11:35 -!- user2019 [55c3eb12@gateway/web/freenode/ip.85.195.235.18] has joined #bitcoin-core-dev 11:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 11:37 < bitcoin-git> [bitcoin] giulio92 opened pull request #15964: Docs: Improve build-osx document formatting (master...feature/update-macOS-doc) https://github.com/bitcoin/bitcoin/pull/15964 11:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 11:55 < tryphe> if the default maximum open file descriptors on Mac OS 10 is 256 ('ulimit -n' == 256), and the leveldb default is 1000, what would a reasonable leveldb default be so that bitcoind + leveldb won't exceed 256 fds total? 11:56 < tryphe> on one hand, if it goes too low, it could hurt performance, but on the other hand, we don't want it to exceed 256, which seems low for having tons of files around for compaction. 11:57 < tryphe> i guess i should clarify: it's 256 per process, not system-wide, of course. 11:59 < gwillen> tryphe: have you actually hit the limit? 11:59 < luke-jr> is it really? :/ 11:59 < gwillen> I'm asking because I'm on OS X and I'm kind of suprised I never have 11:59 < gwillen> luke-jr: yes, it sucks 11:59 < luke-jr> including mmaps? 11:59 < gwillen> I had to change one of the linter tests because it tried to open every file in the tree at once, and it would crash on OS X 11:59 < gwillen> mm, I don't know about mmaps, I wouldn't think so 11:59 < gwillen> maybe that's why I've never hit it? 12:00 < tryphe> ^ i was looking at #14870 and realized this was most likely the culprit after running ulimit 12:00 < gribble> https://github.com/bitcoin/bitcoin/issues/14870 | Bitcoind crashes with Too Many Files error · Issue #14870 · bitcoin/bitcoin · GitHub 12:00 < tryphe> but it's hard to know how many files will need to be read by the compaction mechanism... i doubt it's identical across different configurations and whatnot 12:01 < tryphe> read simultaneously, rather 12:02 < gwillen> the change that raised the leveldb limit to 1000 is https://github.com/bitcoin/bitcoin/pull/12495 12:02 < gwillen> which says (like luke-jr was just asking): "On 64-bit POSIX hosts LevelDB will open up to 1000 file descriptors using mmap(), and it does not retain an open file descriptor for such files." 12:02 < tryphe> gwillen, i didn't hit the limit personally, but my Mac box is mostly just for testing, not for full node running 12:02 < gwillen> so I wonder if something else is actually the culprit 12:03 < gwillen> I regularly run full nodes on my box for testing and real use 12:03 < gwillen> and I've _never_ hit this 12:03 -!- jarthur_ [~jarthur@207.114.244.5] has quit [Remote host closed the connection] 12:03 < gwillen> although I guess these days I wouldn't, since I upped my default at some point... if I did that before 12495 was merged, I might be a bad test case 12:03 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 12:03 < gwillen> but I would expect that if the leveldb file count were the culprit, LOTS of people would be affected, and I believe the theory that mmaps should not count 12:06 < tryphe> yeah, i'm not sure. my hunch was that leveldb would approach that limit, and bitcoind opening files could cause the issue to appear, without leveldb being the sole cause (depends how many files bitcoind is also accessing) 12:06 < tryphe> which would make sense i guess, 256 isn't insanely high 12:09 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 12:14 -!- chaus [~chaus@81.193.44.230] has quit [Remote host closed the connection] 12:14 -!- waxwing [~waxwing@unaffiliated/waxwing] has quit [Ping timeout: 252 seconds] 12:14 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 12:19 -!- waxwing [~waxwing@193.29.57.116] has joined #bitcoin-core-dev 12:24 -!- jarthur [~jarthur@207.114.244.5] has quit [Remote host closed the connection] 12:25 -!- obsrver [~quassel@p5DC6BDE0.dip0.t-ipconnect.de] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 12:27 -!- chaus [~chaus@bl4-44-230.dsl.telepac.pt] has joined #bitcoin-core-dev 12:32 -!- promag_ [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 12:34 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 12:34 -!- jarthur [~jarthur@207.114.244.5] has quit [Remote host closed the connection] 12:34 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 12:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 12:34 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8ec7121a4590...3632143ebbfd 12:34 < bitcoin-git> bitcoin/master d2eee87 Ben Woosley: Lift prevector default vals to the member declaration 12:34 < bitcoin-git> bitcoin/master 3632143 MarcoFalke: Merge #14266: refactor: Lift prevector default vals to the member declarat... 12:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 12:34 -!- michagogo_ [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev 12:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 12:34 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #14266: refactor: Lift prevector default vals to the member declaration (master...prevector-defaults) https://github.com/bitcoin/bitcoin/pull/14266 12:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 12:35 -!- roconnor [~roconnor@2600:1700:4570:fe1:113a:8cc7:57de:58be] has joined #bitcoin-core-dev 12:35 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 12:35 -!- jonny_osaka [25e4f652@gateway/web/freenode/ip.37.228.246.82] has joined #bitcoin-core-dev 12:35 -!- scoop_ [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 12:38 < gmaxwell> gwillen: bitcoin increases the ulimit, see RaiseFileDescriptorLimit(). 12:38 -!- jarthur [~jarthur@207.114.244.5] has quit [Ping timeout: 246 seconds] 12:38 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 12:39 < gmaxwell> mmaps also don't themselves count. (also most of the time any 'large' malloc also results in a mmap) 12:39 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has quit [Ping timeout: 248 seconds] 12:39 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has quit [Ping timeout: 248 seconds] 12:39 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 248 seconds] 12:39 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 248 seconds] 12:39 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Ping timeout: 248 seconds] 12:39 -!- roconnor_ [~roconnor@2600:1700:4570:fe1:113a:8cc7:57de:58be] has quit [Ping timeout: 248 seconds] 12:39 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 248 seconds] 12:39 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Ping timeout: 248 seconds] 12:39 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has quit [Ping timeout: 248 seconds] 12:39 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 248 seconds] 12:39 -!- michagogo_ is now known as michagogo 12:39 -!- ovovo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 12:40 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 12:40 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has joined #bitcoin-core-dev 12:42 -!- chaus [~chaus@bl4-44-230.dsl.telepac.pt] has quit [] 12:54 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has joined #bitcoin-core-dev 12:58 < tryphe> gmaxwell, it looks like it would call RaiseFileDescriptorLimit(125 + 150 + 8), which only gets you 283 instead of 256 12:59 < tryphe> gmaxwell: https://github.com/bitcoin/bitcoin/blob/12aa2ac988d0ccb21019a20b109e018cf31b78cf/src/init.cpp#L1007 12:59 < sipa> tryphe: on 64-bit systems, LevelDB uses mmap which doesn't need many simultaneous file descriptors 12:59 < tryphe> and on linux, it's less than 1024, which is the default, so it does nothing 13:02 < gwillen> right, if leveldb isn't taking up fds then the whole leveldb thing is a red herring and the cause must be something else 13:02 < tryphe> sipa, i see, but what about too many concurrent mmap() calls? assuming you have a bunch of 2MB files at one level, it seems to me like you could potentially still be opening hundreds of handles at once 13:03 -!- drexl_ [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 13:03 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev 13:04 < tryphe> sipa, what i mean by that is, the fd isn't closed until mmap returns the mapping 13:04 < gmaxwell> tryphe: yes, but they are created sequentially. 13:04 < sipa> tryphe: i don't think those things happen in separate threads 13:05 < tryphe> i see, thanks. maybe i'm thinking of rocksdb, where it happens in a thread pool. 13:05 < gmaxwell> the comment about RPC in the reporter is a pretty strong indication that they're likely hammering the RPC... 13:05 < tryphe> gmaxwell, yeah, but usually you don't have leveldb throw that error unless something is implemented wrong, it's a common problem 13:06 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Ping timeout: 252 seconds] 13:07 < gmaxwell> tryphe: the error being reported by the user is not from leveldb. 13:07 < gmaxwell> It's from libevent-- which handles the rpc. 13:09 < tryphe> gmaxwell, look at the first instance 13:09 < gmaxwell> tryphe: it looks to me like they're hammering the rpc and used up all the FDs that way, and leveldb is unable to get a single FD to open a file. 13:10 < tryphe> gmaxwell, 2018-12-04T17:09:42Z leveldb: Compaction error: IO error: /Users/matt/Library/Application Support/Bitcoin/testnet3/indexes/txindex/012589.ldb: Too many open files 13:11 < sipa> maybe we should increasy fds also proportionally to -rpcthreads ? 13:11 -!- jonny_osaka [25e4f652@gateway/web/freenode/ip.37.228.246.82] has quit [Ping timeout: 256 seconds] 13:12 < gmaxwell> sipa: yes, I was just looking for where we did that, seems we don't. 13:13 < gmaxwell> we might want to add some instrumentation that runs during tests, and checks to see if the total open fds is ever greater than we pass to RaiseFileDescriptorLimit. 13:13 < tryphe> if it raises the fds to 283 if it's <283, but the default is 1024 on most linux/unix systems (except mac os), would a sane thing to be just to increase the fds to 1024 on mac os? (i think the max per process is 10240) 13:14 < gmaxwell> otherwise we're going to keep ending up with bugs that are invisible when RaiseFileDescriptorLimit does nothing. 13:14 < gmaxwell> tryphe: well that would just be covering up the bug that RaiseFileDescriptorLimit isn't being increased by the rpc thread count. 13:16 < tryphe> gmaxwell, yeah, i'm not even sure how to reproduce it, but if that's one glaring difference, it might make sense to increase it? 13:16 < gmaxwell> tryphe: then the problem will just show up again when users set rpcthreads even higher 13:17 < gmaxwell> if you don't understand an issue, just changing things blindly risks introducing new issues, and not fixing them. 13:17 < gmaxwell> But I think we do understand it-- RaiseFileDescriptorLimit should be getting the rpcthreads added. 13:17 < sipa> but by how much? 13:18 < tryphe> gmaxwell, i don't see how adding in the number of rpcs would do anything if RaiseFileDescriptorLimit() doesn't do anything if my fd limit is 1024 by default 13:18 < tryphe> rpcs/rpc threads 13:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 13:18 < bitcoin-git> [bitcoin] zenosage opened pull request #15965: check bad-prevblk is right error for invalid descendants (master...bad-prevblk) https://github.com/bitcoin/bitcoin/pull/15965 13:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:20 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds] 13:20 < gmaxwell> tryphe: go look at the code in init.cpp. It works out how many FDs we can actually use. 13:20 < sipa> tryphe: what if you have 2000 rpc threads? :) 13:21 < gmaxwell> Right now it doesn't account for the RPC threads (they're just assumed to be part of MIN_CORE_FILEDESCRIPTORS, but that doesn't hold if someone changes the setting) 13:21 < gmaxwell> it should account for RPC threads. 13:21 < gmaxwell> Which would be the actual bug. 13:22 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 13:23 < tryphe> gmaxwell, i already looked at it before i told you anything 13:24 < sipa> tryphe: i think you're missing something, but i don't see what 13:25 < tryphe> i see why you would want to add the number of rpc threads, but not why you would want different fd max values on different systems 13:26 < sipa> what are you talking about with "different fd max values on different systems" ? 13:27 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 248 seconds] 13:27 < gmaxwell> sipa: he's referring to the fact that we don't raise it if it's already more than we need. 13:27 < tryphe> sipa, on mac os 10, if 'limit -n' gives 256, what would RaiseFileDescriptorLimit() set the value to? 13:27 < tryphe> sipa, likewise, on linux, what would it do? 13:27 < gmaxwell> sipa: and on OSX the default is lower than we need (with defaults), but on linux it's higher. 13:27 < sipa> it tries to raise it if needed 13:27 < tryphe> the difference is a value of ~700 13:27 < sipa> if it's not needed, there is nothing to be done 13:28 < sipa> yes, so the number needed is miscomputed, and we should fix that 13:28 < gmaxwell> tryphe: The limit is compltely irrelevant so long as it is greater than our need. If our caclulated need is incorrect, then we will have problems in some configurations. 13:28 < sipa> that fact that it's already 1024 only helps mask the problem 13:29 < gmaxwell> If we set the limit higher than we think we need, it won't fix any bugs-- the program will still fail in some configurations-- but it will make some bugs less visible. 13:29 < gmaxwell> So instead of failing on mac when you adjust rpc threads at all, it'll still fail, but everwhere when you set rpcthreads to 700. (or whatever) 13:30 < tryphe> right but <300 seems pretty low, especially if they are running bitcoin-qt which accesses a bunch of files, not to mention future features 13:30 < sipa> tryphe: so we should fix the computation that incorrectly determines 300 is enough 13:30 < gmaxwell> Any new features that use FDs need to increase the calculated limit. 13:30 < sipa> i don't understand what you're arguing for 13:30 < tryphe> sipa, because it's a glaring difference, and you're blowing it off like it's nothing 13:30 < gmaxwell> No fixed amount is safe, only computing the required amount is safe. 13:31 < sipa> tryphe: no... 13:31 < sipa> i'm not 13:31 < tryphe> for every 1 github issue there's 1000 morons that ignored it and stopped using it 13:31 < sipa> i 13:31 < tryphe> for the same reason 13:31 < gwillen> tryphe: we are statically computing the exact number of file descriptors we need, and raising the limit to that exact value, which we will never exceed, so there is never a reason for it to be higher 13:31 < gwillen> in this case, there is a bug, which is that we compute the wrong number 13:31 < gwillen> once the bug is fixed, there will again be no reason to ever raise the number 13:31 < gmaxwell> tryphe: I think we're failing to communicate here. I think we should fix the problem, which is now known in part thanks to your exploration. We should not, however, paper over misbehavior as that can create much more serious issues. 13:32 < gwillen> it sounds like you believe that Core will sometimes open other file descriptors not accounted for here, but that is not supposed to ever happen, and would represent a bug 13:32 < gmaxwell> Fixing the calculation will fix the bug. Blindly increasing the value on OSX will paper over the bug and any similar bug in the future but not actually fix it. 13:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 13:32 < bitcoin-git> [bitcoin] hebasto opened pull request #15966: net: Drop the ancient miniUPnPc API version support (master...20190506-drop-ancient-miniupnpc-api) https://github.com/bitcoin/bitcoin/pull/15966 13:32 < gmaxwell> what gwillen says. All FDs _must_ be accounted for. 13:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:33 < gwillen> I think this is unusual, and it's much more typical for people to just give a high number and hope for the best 13:33 < tryphe> sipa, gmaxwell, gwillen, i see. that makes sense. 13:33 < gwillen> cool :-) 13:33 < sipa> yeah, we try to account for all resource usage 13:33 < gmaxwell> (it's a little less crtical now that we don't use select on linux, but they still need to be accounted for) 13:33 < sipa> disk, memory, cpu, fds 13:33 < gwillen> could we actually _lower_ it from 1024 on linux, instead of leaving it alone? 13:34 < gwillen> that would make this kind of thing show up much faster 13:34 < gwillen> rather than only happening on oddball os x 13:34 < sipa> yeah, perhaps 13:34 < gwillen> and it would satisfy tryphe's very reasonable desire that it be the same across platforms, which I think is a good thought :-) 13:34 < gmaxwell> we should at least in some test builds. 13:34 < tryphe> i do think it's sort of a hinderance that mac os is somehow bundled in with other "linux/unix" compile targets and has some funny differences, though. 13:34 < gwillen> yeah 13:34 < gwillen> as one of the few people actively developing on OS X, I agree ;-) 13:34 < tryphe> but yeah i think raising it is silly especially with mmap 13:34 < gmaxwell> like make one of the debug builds reduce fd limit to the computed amount. 13:35 < tryphe> i didn't intend to suggest raising it as a key argument, just nitpicking differences between systems i guess 13:36 < gmaxwell> difference between systems are good though-- without this one we wouldn't have found this issue until some other change increased usage to the point where it was making 1024 limit get busted. 13:36 < gmaxwell> which might have happened across the whole network at once 13:37 < gwillen> heh, that's an interesting point 13:38 < tryphe> yeah, i would think lowering it and dynamically setting it across all platforms would make sense, as you only really need to increase it if you are running some insane file server or something 13:38 < tryphe> and that's when you -need- overkill 13:38 < tryphe> here, you know what you need 13:38 < sipa> what does file server have to do with it? 13:38 < gwillen> I raised it in my .profile, I should maybe take that out :-\ 13:38 < gwillen> since it masks any problem like this 13:38 < sipa> this limit is per process, not system wide 13:38 < gwillen> I did it so I could get the tests to run, but then I fixed the tests 13:39 < tryphe> sipa, it just as an example of extremes where people blindly raise the limit to 10000 or whatever :p 13:40 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection] 13:40 < tryphe> sipa, but in those cases they are maybe succombing to future DoS problems and whatnot 13:44 -!- scoop_ [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 13:44 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 13:47 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 258 seconds] 13:48 -!- scoop [~scoop@50-77-133-26-static.hfc.comcastbusiness.net] has quit [Ping timeout: 250 seconds] 13:51 < tryphe> gmaxwell, do you think i should give it a test with a lower MIN_CORE_FILEDESCRIPTORS value, and add the rpc threads in? maybe use 0 for MIN_CORE_FILEDESCRIPTORS instead of 150 13:52 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev 13:53 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 13:54 < sipa> We certainly need a few FDs independent of RPC handling (including those for accessing block files, undo files, ...) 13:54 < tryphe> right, i'll give it a try! thanks 13:55 < sipa> i also don't know how many FDs we need per RPC, and it's hard to experimentally determine the upper bound as it depends on the type of RPCs 13:56 < sipa> but there is at least 1 for the TCP connection itself (except on windows, where sockets don't count as FDs...), and maybe 1 or 2 more for files that may be accessed for handling the RPC 14:00 -!- Suntop1 [~Suntop@178.162.209.171] has quit [] 14:01 < tryphe> i see, because an rpc might trigger a file to be read? 14:02 < sipa> yes 14:05 -!- Avelino [~Avelino@84.39.117.57] has joined #bitcoin-core-dev 14:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 14:06 < bitcoin-git> [bitcoin] practicalswift closed pull request #15962: Add locking annotations for RewindBlockIndex and GetNetworkHashPS. Add missing locks. (master...RewindBlockIndex) https://github.com/bitcoin/bitcoin/pull/15962 14:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 14:11 < tryphe> sipa, i wonder if an "rpc thread fd factor" could be used, perhaps to replace MIN_CORE_FILEDESCRIPTORS which is a value of 150. 20 fds per thread *8 threads=160, so you'd get 160, which is roughly the same, but a little more 14:11 < sipa> tryphe: we still have a number of fds independent of RPCs 14:11 < sipa> probably the majority 14:11 < tryphe> sipa, right, that's true 14:12 < tryphe> good point 14:15 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 14:17 < jamesob> anyone think it'd be a good idea to prefix class member function calls with `this->` for clarity? 14:18 < luke-jr> jamesob: no, that's why they're supposed to be named m_* 14:19 < jamesob> that only applies to class *data* members afaict 14:19 < luke-jr> oh, methods 14:20 < luke-jr> `this->` seems ugly, but I don't know that I have a better solution, and I agree it can at times be unclear 14:21 < jamesob> luke-jr: agreed 14:21 < sipa> jamesob: the explicit way to do that is writing Classname::Method(...) 14:21 < sipa> but that's also ugly 14:21 < tryphe> i think it makes a little sense if you consider how you destruct this->~Class(); 14:21 < tryphe> but maybe adds clutter 14:22 < luke-jr> what? 14:22 < luke-jr> you destruct with delete.. 14:22 < jamesob> sipa: yeah that's wordy 14:23 * luke-jr wonders why `this` is a pointer and not a reference anyway 14:23 < jamesob> something something destructors something something? 14:34 < sipa> http://www.stroustrup.com/bs_faq2.html#pointers-and-references 14:34 < sipa> Why is "this" not a reference? 14:34 < sipa> Because "this" was introduced into C++ (really into C with Classes) before references were added. Also, I chose "this" to follow Simula usage, rather than the (later) Smalltalk use of "self". 14:34 < tryphe> luke-jr, they are identical, but you can use delete to destruct an array 14:35 < sipa> tryphe: no, you need delete[] to destruct an array 14:35 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds] 14:35 < sipa> and invoking a destructor does not release its memory 14:35 < sipa> it only destroys the object allocated in it 14:36 < tryphe> sipa, that's what i said 14:36 < sipa> 1) "but you can use delete to destruct an array", that's wrong, you need to use delete[] 14:37 < tryphe> sipa, yeah.... i meant delete or delete[] 14:37 < sipa> 2) "they are identical", that's wrong; deleting an object invokes the relevant destructors as needed, but actually cleans up allocated memory 14:37 < tryphe> just 'delete' as the keyword 14:37 * luke-jr wonders if there's ever a case where calling this->~class directly actually makes sense. :x 14:38 < sipa> luke-jr: if you're constructing objects objects in self-allocated space 14:39 < sipa> https://github.com/bitcoin/bitcoin/blob/master/src/prevector.h#L396 14:40 < tryphe> sipa, luke-jr, but i zero out the memory in the destructor. that's what it's for... 14:41 < sipa> tryphe: the destructor is invoked automatically when destroying the object (when it goes out of scope, when delete is called, ...); you usually don't need to invoke it yourself 14:42 < luke-jr> sipa: hmm, I figured since new can be used with preallocated space, so could delete, but I guess not 14:42 < sipa> the only counterexample i know is when you're writing your own container classes that manually manage memory 14:43 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 250 seconds] 14:44 < sipa> luke-jr: https://en.cppreference.com/w/cpp/language/new#Placement_new 14:45 < luke-jr> sipa: yes, that's what I mean 14:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 14:47 < bitcoin-git> [bitcoin] hebasto closed pull request #15966: net: Drop the ancient miniUPnPc API version support (master...20190506-drop-ancient-miniupnpc-api) https://github.com/bitcoin/bitcoin/pull/15966 14:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 14:49 < tryphe> sipa, right, it's just hard to explain how i'm using it, it's a thread cleanup at the end of an application. if i invoke the destructor inside of itself, i don't have to call 'delete' from main() and the pointer gets popped off of the stack when main unwinds 14:49 < tryphe> sipa, i guess i wrote "this->Class()" because i have "delete" all over the place and wanted to mark "i'm exiting the thread here" 14:50 < tryphe> well, thread manager* 14:50 < sipa> ah, this is starting to get off topic :) 14:51 < tryphe> sipa, lol, sorry <3 14:54 -!- waxwing [~waxwing@193.29.57.116] has quit [Changing host] 14:54 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined #bitcoin-core-dev 14:57 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 258 seconds] 14:58 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 15:05 -!- Yamato [240c58e2@gateway/web/freenode/ip.36.12.88.226] has joined #bitcoin-core-dev 15:06 -!- Yamato is now known as Guest280 15:06 -!- Guest280 [240c58e2@gateway/web/freenode/ip.36.12.88.226] has quit [Client Quit] 15:07 -!- YamatoSueoka [240c58e2@gateway/web/freenode/ip.36.12.88.226] has joined #bitcoin-core-dev 15:08 -!- YamatoSueoka_ [240c58e2@gateway/web/freenode/ip.36.12.88.226] has joined #bitcoin-core-dev 15:09 -!- YamatoSueoka_ [240c58e2@gateway/web/freenode/ip.36.12.88.226] has quit [Client Quit] 15:09 -!- YamatoSueoka_ [240c58e2@gateway/web/freenode/ip.36.12.88.226] has joined #bitcoin-core-dev 15:09 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 15:10 -!- YamatoSueoka_ [240c58e2@gateway/web/freenode/ip.36.12.88.226] has quit [Client Quit] 15:10 -!- YamatoSueoka_ [240c58e2@gateway/web/freenode/ip.36.12.88.226] has joined #bitcoin-core-dev 15:11 -!- YamatoSueoka [240c58e2@gateway/web/freenode/ip.36.12.88.226] has quit [Ping timeout: 256 seconds] 15:13 -!- YamatoSueoka_ [240c58e2@gateway/web/freenode/ip.36.12.88.226] has quit [Client Quit] 15:37 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 16:03 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 16:11 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 16:14 -!- drexl_ [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Remote host closed the connection] 16:15 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection] 16:16 -!- ccdle12 [~ccdle12@SODcd-03p21-215.ppp11.odn.ad.jp] has joined #bitcoin-core-dev 16:17 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 16:18 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev 16:19 < jeremyrubin> I happened to be reviewing VerifyScript, and wanted to check that it is the intended behavior that if CastToBool(witnessprogram) == false that validation fails? 16:20 < jeremyrubin> I just couldn't find it in the documentation (practically speaking it doesn't exclude very many scripts...) 16:20 < sipa> jeremyrubin: yes 16:20 < sipa> "not very many" is really "practically none", as the witness program is a hash 16:21 -!- ccdle12 [~ccdle12@SODcd-03p21-215.ppp11.odn.ad.jp] has quit [Ping timeout: 248 seconds] 16:22 -!- scoop [~scoop@205.178.77.52] has joined #bitcoin-core-dev 16:23 < jeremyrubin> Yep it's fine, just wanted to clarify as it's not documented that it is intentional. 16:24 < jeremyrubin> The same sort of thing is true for P2SH 16:25 < jeremyrubin> My reason for looking at it is refactoring the VerifyScript code so that I understand it better. 16:32 -!- ccdle12 [~ccdle12@SODcd-03p21-215.ppp11.odn.ad.jp] has joined #bitcoin-core-dev 16:36 -!- ccdle12 [~ccdle12@SODcd-03p21-215.ppp11.odn.ad.jp] has quit [Remote host closed the connection] 16:36 -!- ccdle12 [~ccdle12@SODcd-03p21-215.ppp11.odn.ad.jp] has joined #bitcoin-core-dev 16:41 -!- bitbee [~bitbee@unaffiliated/cryptocat] has quit [Quit: Leaving.] 16:42 -!- bitbee [~bitbee@unaffiliated/cryptocat] has joined #bitcoin-core-dev 16:50 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 16:56 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 16:56 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 16:58 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 256 seconds] 17:00 -!- Avelino [~Avelino@84.39.117.57] has quit [] 17:02 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [] 17:07 -!- rlaager1 [~rlaager@184.75.223.195] has joined #bitcoin-core-dev 17:10 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 17:15 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 17:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 17:19 < bitcoin-git> [bitcoin] grim-trigger opened pull request #15968: Fix portability issue with pthreads (master...master) https://github.com/bitcoin/bitcoin/pull/15968 17:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 17:30 -!- kljasdfvv [~flack@pD95EFED1.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 17:31 -!- IGHOR [~quassel@93.178.216.72] has quit [Quit: http://quassel-irc.org ? ??????????? ?????????. ????-??.] 17:34 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev 17:37 -!- YamatoSueoka [240c5483@gateway/web/freenode/ip.36.12.84.131] has joined #bitcoin-core-dev 17:37 -!- YamatoSueoka [240c5483@gateway/web/freenode/ip.36.12.84.131] has quit [Client Quit] 17:38 -!- YamatoSueoka [240c5483@gateway/web/freenode/ip.36.12.84.131] has joined #bitcoin-core-dev 17:40 -!- kljasdfvv [~flack@p200300D46F03EB0015E4C7424E8A8003.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 17:48 -!- goatpig [53724877@gateway/web/freenode/ip.83.114.72.119] has quit [Ping timeout: 256 seconds] 18:00 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 18:00 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 18:02 -!- ccdle12 [~ccdle12@SODcd-03p21-215.ppp11.odn.ad.jp] has quit [Remote host closed the connection] 18:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 18:06 < bitcoin-git> [bitcoin] JeremyRubin opened pull request #15969: Refactor: explicit VerifyScript control flow based on pattern matching (master...explicit-verifyscript) https://github.com/bitcoin/bitcoin/pull/15969 18:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 18:10 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 252 seconds] 18:11 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 18:31 -!- YamatoSueoka [240c5483@gateway/web/freenode/ip.36.12.84.131] has quit [Quit: Page closed] 18:32 -!- YamatoSueoka [240c5483@gateway/web/freenode/ip.36.12.84.131] has joined #bitcoin-core-dev 18:40 -!- roconnor [~roconnor@2600:1700:4570:fe1:113a:8cc7:57de:58be] has quit [Quit: Konversation terminated!] 18:40 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 18:42 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds] 18:59 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: leaving] 19:08 -!- ccdle12 [~ccdle12@103.5.140.136] has joined #bitcoin-core-dev 19:21 -!- scoop [~scoop@205.178.77.52] has quit [Remote host closed the connection] 19:44 < gmaxwell> test/sanitizer_suppressions/ubsan contains suppressions of what appears to be actual undefined behavior, which I can't find any discussions of anywhere. 19:44 < gmaxwell> alignment:move.h 19:44 < gmaxwell> alignment:prevector.h 19:45 < gmaxwell> vptr:fs.cpp 19:45 < gmaxwell> in particular 19:50 < gmaxwell> Git blame says they were added by https://github.com/bitcoin/bitcoin/pull/14252 but there isn't any discussion of them there. 20:00 -!- rlaager1 [~rlaager@184.75.223.195] has quit [] 20:01 -!- ccdle12 [~ccdle12@103.5.140.136] has quit [Remote host closed the connection] 20:04 -!- YamatoSueoka [240c5483@gateway/web/freenode/ip.36.12.84.131] has quit [Ping timeout: 256 seconds] 20:50 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.4] 20:51 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection] 20:52 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev 20:53 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #bitcoin-core-dev 21:16 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev 21:20 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 250 seconds] 21:24 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 21:28 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has quit [Ping timeout: 255 seconds] 21:38 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection] 21:39 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev 21:47 -!- kljasdfvv [~flack@p200300D46F03EB0015E4C7424E8A8003.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 21:48 -!- kljasdfvv [~flack@p200300D46F03EB00FDA83991803D7566.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 22:00 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 22:06 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 22:06 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Remote host closed the connection] 22:07 -!- rex4539 [~rex4539@athedsl-171280.home.otenet.gr] has quit [Quit: rex4539] 22:11 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 22:22 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 22:25 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 22:42 < jeremyrubin> sipa: why does taproot need a new witness version if the WITNESS_V1_TAPROOT_SIZE != WITNESS_V0_SCRIPTHASH_SIZE? 22:42 -!- aqu4 [~aqu4@84.39.117.57] has joined #bitcoin-core-dev 22:43 < sipa> jeremyrubin: because of a stupid mistake in bip141 that makes v0 segwit with program sizes other than 20 or 32 invalid 22:44 < jeremyrubin> got it 22:44 < gmaxwell> to be fair, I believe it was an intentional decision, jut a bad one. :P 22:45 < jeremyrubin> Also this is kinda stupid, but the SIGTYPE::ECDSA/SIGTYPE::SCHNORR can be a template parameter because we never (in the code I've reviewed) use it without knowing it's type as a literal 22:46 < sipa> jeremyrubin: sure, but premature optimization :) 22:46 < gmaxwell> probably doesn't change the output code. 22:46 < sipa> it likely does (there's some indirection) 22:47 < jeremyrubin> Ah not so much as an optimization, but as better code (IMO) safety because someone never does something silly with dynamically figuring out what kind of signature you are passing in 22:47 < sipa> it makes the code harder to review too 22:48 < jeremyrubin> only a little -- I think it's easier because I spent some time looking to see how we were determining what type signature to pass in -- fortunately at present it's literals 22:48 < sipa> but i agree it would make some classes of bugs harder 22:50 < jeremyrubin> yeah it's not something that like *has* to change, just thought it was worth pointing out that the SignatureType argument looked a little smelly to me 22:50 < jeremyrubin> compiler errors > assert(false) 22:52 < jeremyrubin> sipa: BTW; could you open a Pull Request on your local repo 22:52 < jeremyrubin> sipa: that way can add review comments/notes 22:53 < sipa> yes, you can? 22:55 < jeremyrubin> I mean github fork. I don't think I can open one on your fork 22:55 < sipa> sure you can 22:55 < sipa> there are a number of prs against my repo 22:56 < jeremyrubin> can you update your master it's out of date 22:56 < jeremyrubin> (figured out how to do it) 22:57 < sipa> u 22:57 < sipa> you shouldn't care about my master 22:57 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has quit [Ping timeout: 245 seconds] 22:58 < sipa> also, this isn't really the time to go perfect the code yet 22:58 < jeremyrubin> Well I'm opening the PR of your taproot against your master -- if I open it against bitcoin/master it will show up in core's PR? 22:58 < sipa> you can choose both the base repo and branch 22:58 < jeremyrubin> Yeah I just want to review to understand the trade offs better for looking at the specs 22:58 < gmaxwell> sipa: you should blow it away, like my secp256k1 https://github.com/gmaxwell/secp256k1/ (incidentally yours has come back, IIRC you'd done the same bfore) 23:00 -!- aqu4 [~aqu4@84.39.117.57] has quit [] 23:00 < jeremyrubin> sipa: maybe I'm missing something but when I open a PR on your fork, it has to be against one of your branches. 23:00 < jeremyrubin> https://github.com/sipa/bitcoin/compare/master...sipa:taproot 23:02 < sipa> well, then you're doing it wrong :) 23:03 < jeremyrubin> ugh... 23:03 < jeremyrubin> why isn't there a CLI for this 23:04 < kallewoof> sipa: stupid question, but where is the epoch stored? It is used in the SHA256 for the transaction digest, but is it just assumed to be 0 for now? 23:04 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 23:05 < sipa> kallewoof: it is not stored. it's defined to be 0 23:05 < gmaxwell> kallewoof: it isn't, it's implicit. 23:05 < jeremyrubin> I have absolutely no clue how to do this. 23:05 < gmaxwell> later a new checksig operation or something might be added that defines it to be 1 23:05 < sipa> something somewhere sometime someplace may use the same hashing algorithm with another epoch value 23:05 < sipa> it's likely never needed 23:05 * jeremyrubin bangs head on keyboard 23:05 < kallewoof> okay. so once we introduce epoch 1 and there may be ambiguity, we start storing it..? 23:06 < sipa> no 23:06 < kallewoof> gmaxwell: oh i see. that makes sense, thanks. 23:06 < sipa> it's just part of the hashing algorithm 23:08 < kallewoof> the purpose of the epoch is to avoid users being able to spend an output using a different operation that happens to use the same signature and "content" (content being the sighash sans the epoch) 23:08 < kallewoof> IIUC 23:08 < gmaxwell> right 23:08 < gmaxwell> like in some v2 script it might be defined to be 1, which will prevent you from rebinding a signature from a v2 pubkey to v1... but in no case would it need to be signaled 23:09 < kallewoof> got it! 23:10 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 23:10 < jeremyrubin> is 1 byte kinda small? 23:11 < sipa> 1 byte is infinite 23:11 < sipa> :) 23:11 < jeremyrubin> we can extend it if we hit 255? 23:11 < sipa> yes 23:11 < gmaxwell> one bit would be sufficient, but would complicate alignment. 23:12 < sipa> all we need is making sure no preimage ever collides 23:12 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 23:12 < sipa> if the existing extension mechanisms are insufficients, we can always switch to a different tag in the hash or so 23:13 < jeremyrubin> In the future how do we infer the epoch? Like from tx version or something? 23:13 < jeremyrubin> I guess it doesn't matter that much... 23:14 < jeremyrubin> Just trying to determine the benefit of doing this approach v.s. having a pre-salted SHA256 23:14 < sipa> jeez peoe 23:14 < sipa> if the byte wasn't there nobody would even talking about these issues 23:14 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 23:14 < sipa> it's just a mechanism for future extension, like so many others 23:15 < sipa> none of this is critical 23:15 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 23:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 23:15 < bitcoin-git> [bitcoin] orientye opened pull request #15970: fix static_assert for macro HAVE_THREAD_LOCAL (master...master) https://github.com/bitcoin/bitcoin/pull/15970 23:15 < jeremyrubin> Hah, not trying to give u an aneurism 23:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 23:15 < gmaxwell> it may never be used for anything, but its important to use unaliasable hashes. 23:16 < sipa> jeremyrubin: sorry, don't worry :) 23:16 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has quit [Client Quit] 23:17 < jeremyrubin> Sure, I get the purpose and the issue with rebinding a signature -- and I was only looking at it because kalle brought it up 23:17 * jeremyrubin kicks kalle 23:17 < jeremyrubin> ;) 23:18 < wumpus> new proposal for 0.19.0 release schedule (looks like I included two months too much) https://github.com/bitcoin/bitcoin/issues/15940#issuecomment-489921644 23:19 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 248 seconds] 23:19 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 268 seconds] 23:20 < wumpus> gmaxwell: no, there was no discussion of specific surpressions as far as I know, this was for adding a travis run to catch new UBsan problems, so all the current ones had to be surpressed for that to not fail every single time :) 23:20 < sipa> wumpus: not releasing right after new year is probably good 23:22 < wumpus> sipa: so that's a vote for moving it, I guess? 23:23 < wumpus> I'm just asking to be sure that having two months less than initially expected doesn't ruin anyone's plans 23:30 < wumpus> "not doing a release on new year" is a good point, although it's quite a nice release date :-) 23:30 < jeremyrubin> Bitcoin 2020! 23:30 < wumpus> yess 23:31 < jeremyrubin> Actually Bitcoin Satoshi's 2020 Visison 23:31 < jeremyrubin> '__' 23:31 < jonasschnelli> Provable correct ChaCha20-Poly1305 implementation (vectorised assembly): https://arxiv.org/abs/1904.04606 23:32 < jonasschnelli> https://github.com/tfaoliveira/libjc 23:32 < gmaxwell> "We illustrate ur approach" written by lolcats? 23:33 < jonasschnelli> heh 23:37 < wumpus> interesting approach 23:37 < jeremyrubin> sipa: the annex is a bit unclear to me -- my understanding is that it's a space to provide an extra data argument? But what stops this from being malleated? It's covered by the signature? Is one annex certainly enough? What if I want 2 23:37 -!- Guest44098 [~ericb2@84.39.117.57] has joined #bitcoin-core-dev 23:37 < jeremyrubin> Sorry if those are bad questions 23:38 < wumpus> at least it avoids the 'assebmly language is hard to review' problem by the code being provable correct at every manipulation step 23:38 < jeremyrubin> I think what I would expect is that when I open a taproot i climb back through the witness data up to the 0xc0 leaf 23:40 < gmaxwell> jeremyrubin: the annex is signed. 23:41 < jeremyrubin> Ok -- I think I'd rather the spec say 'covered by the wtxid' rather than 'transaction digest' (less ambiguous by a smidge) 23:42 < jeremyrubin> If a particular tap branch doesn' 23:42 < jeremyrubin> * doesn't require a signature, then the annex is malleable (doesn't affect txid so no big deal I guess) 23:43 < gmaxwell> if an output can be spent without a signature it's going to be malleable in many ways, including txid impacting ones. :) 23:44 < jeremyrubin> That's kind of true -- could imagine a world where it's not true 23:44 < jeremyrubin> imagine opcode 'CHECK_INPUT_ALSO_SPENT_VERIFY' 23:44 < gmaxwell> regardless, the annex is protected from malleation in the same way anything else is (and more so than many things are) 23:47 < jeremyrubin> Fair -- might be good to introduce a OP_NO_ANNEX or something at some point if annexes are doing anything... interesting. 23:47 < jeremyrubin> is there anywhere the annex has been discussed more in detail on what it might be used for? 23:48 < gmaxwell> the main purpose of the annex is to be able to adjust transaction weight prior to looking up inputs. 23:48 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Ping timeout: 256 seconds] 23:49 < gmaxwell> (well to be clear, its a generic signed data extension... but the construction is specifically motivated so it can work inputlessly) 23:50 < jeremyrubin> Can you calrify that a little bit for me? {inputlessly, adjust transaction weight} 23:51 < gmaxwell> opcodes which are very expensive to verify would increase the transaction's weight, but its important that we can check the effective weight of a transaction before doing the work of verifying it (in particular, looking up the inputs). 23:52 -!- user2019 [55c3eb12@gateway/web/freenode/ip.85.195.235.18] has quit [Ping timeout: 256 seconds] 23:52 < jeremyrubin> OK, so the idea of an annex is to specify a non malleable 'promise' of how much work validation will cost 23:53 < gmaxwell> right, or rather it's an extension mechenism which is sufficient for that application. though it might turn out to have other ones later. 23:53 < jeremyrubin> and if we ever see a txn which breaks that contract we ban the peer who sent or something 23:53 < gmaxwell> Right. 23:53 < jeremyrubin> gotcha -- annex is a peculiar word 23:54 -!- rex4539 [~rex4539@ppp-94-66-20-149.home.otenet.gr] has joined #bitcoin-core-dev 23:54 < jeremyrubin> hint/heuristic would pass the intention to me much better 23:55 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #bitcoin-core-dev 23:55 < gmaxwell> It's just a general extension mechenism. 23:55 < jeremyrubin> But if we don't yet know what it might be for, then something more general is fine 23:55 < gmaxwell> The only real relationship to the application is that application requires the extension payload be in the transaction, that it be unambigiously interpertable without knowing the input script, and that it get signed. 23:56 < gmaxwell> (also: because of the final fork, we couldn't add the annex later so easily...) 23:56 < gmaxwell> (by final fork, I mean that it has to be signed) 23:56 < gmaxwell> otherwise we would have left it out. 23:56 < jeremyrubin> Ok, so new question: why *not* pass the annex to the stack? 23:56 < jeremyrubin> just less efficient? 23:56 < jeremyrubin> But seems crappy if there's a use case where you'd want to pass it 23:57 < gmaxwell> if you want data on the stack, just put data onto the stack. 23:57 < jeremyrubin> I guess we can just introduce an opcode THIS_DATA_WAS_THE_ANNEX and include it twice 23:57 < jeremyrubin> gmaxwell: you might both want to pass the data and know that it was the annex 23:59 < jeremyrubin> or I guess FETCH_ANNEX also works 23:59 < gmaxwell> right, though I can't imagine what this would be useful for, but sure that could be done. --- Log closed Tue May 07 00:00:05 2019