--- Log opened Thu Apr 18 00:00:48 2019
00:25 -!- harding [~quassel@li1258-130.members.linode.com] has quit [Ping timeout: 255 seconds]
00:34 -!- harding [~quassel@li1258-130.members.linode.com] has joined #bitcoin-core-dev
00:43 -!- Ll1i1lL [~Ll1iiii1l@108-243-84-79.lightspeed.bcvloh.sbcglobal.net] has quit [Ping timeout: 246 seconds]
00:49 -!- murrayn_ [~murrayn@S0106f8a097f16608.ok.shawcable.net] has quit [Quit: Leaving]
00:50 -!- murrayn [~murrayn@unaffiliated/murrayn] has joined #bitcoin-core-dev
01:34 -!- Ll1i1lL [~Ll1iiii1l@108-243-84-79.lightspeed.bcvloh.sbcglobal.net] has joined #bitcoin-core-dev
01:40 -!- Ll1i1lL [~Ll1iiii1l@108-243-84-79.lightspeed.bcvloh.sbcglobal.net] has quit [Ping timeout: 246 seconds]
01:51 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
02:02 -!- dqx [~dqx@unaffiliated/dqx] has quit [Quit: leaving]
02:02 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
02:11 -!- darosior [~darosior@193-141-190-109.dsl.ovh.fr] has joined #bitcoin-core-dev
02:14 -!- Plush [31c561ef@gateway/web/freenode/ip.49.197.97.239] has joined #bitcoin-core-dev
02:14 -!- Plush [31c561ef@gateway/web/freenode/ip.49.197.97.239] has quit [Client Quit]
02:14 -!- zorrologo [6d280327@gateway/web/freenode/ip.109.40.3.39] has joined #bitcoin-core-dev
02:14 -!- zorrologo [6d280327@gateway/web/freenode/ip.109.40.3.39] has quit [Client Quit]
02:17 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
02:21 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
02:27 -!- IRC-Source_65 [6d280327@gateway/web/cgi-irc/kiwiirc.com/ip.109.40.3.39] has joined #bitcoin-core-dev
02:28 -!- IRC-Source_65 [6d280327@gateway/web/cgi-irc/kiwiirc.com/ip.109.40.3.39] has quit [Remote host closed the connection]
02:34 -!- profmac [~ProfMac@2001:470:1f0f:226:e941:42df:c6c2:47d3] has quit [Ping timeout: 250 seconds]
02:37 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
02:39 -!- Ll1i1lL [~Ll1iiii1l@108-243-84-79.lightspeed.bcvloh.sbcglobal.net] has joined #bitcoin-core-dev
02:47 -!- profmac [~ProfMac@2001:470:1f0f:226:7c72:2430:b709:315f] has joined #bitcoin-core-dev
02:48 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
03:02 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev
03:22 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
03:30 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
03:38 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
03:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:54 -!- goatpig_ [53724877@gateway/web/freenode/ip.83.114.72.119] has joined #bitcoin-core-dev
03:54 -!- goatpig_ [53724877@gateway/web/freenode/ip.83.114.72.119] has left #bitcoin-core-dev []
03:55 -!- goatpig [53724877@gateway/web/freenode/ip.83.114.72.119] has joined #bitcoin-core-dev
03:55 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]
04:12 -!- strattog [~strattog@185.103.96.135] has joined #bitcoin-core-dev
04:13 -!- strattog [~strattog@185.103.96.135] has quit [Client Quit]
04:22 -!- T-Junk [~T-Junk@89.249.74.213] has joined #bitcoin-core-dev
04:29 -!- Claveprivada [57da1aba@gateway/web/freenode/ip.87.218.26.186] has joined #bitcoin-core-dev
04:35 -!- darosior [~darosior@193-141-190-109.dsl.ovh.fr] has quit [Ping timeout: 246 seconds]
04:41 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Ping timeout: 245 seconds]
04:51 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
05:00 -!- T-Junk [~T-Junk@89.249.74.213] has quit []
05:02 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
05:14 -!- Claveprivada [57da1aba@gateway/web/freenode/ip.87.218.26.186] has quit [Ping timeout: 256 seconds]
05:20 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Excess Flood]
05:22 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev
05:22 -!- jonatack [d598a24f@gateway/web/freenode/ip.213.152.162.79] has joined #bitcoin-core-dev
05:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:31 < bitcoin-git> [bitcoin] ariard opened pull request #15842: refactor: replace isPotentialtip/waitForNotifications by higher method (master...2019-04-is-potential-tip) https://github.com/bitcoin/bitcoin/pull/15842
05:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:32 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
05:41 -!- scoop [~scoop@ip-184-248-176-199.nymnny.spcsdns.net] has joined #bitcoin-core-dev
05:46 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev
05:50 -!- scoop_ [~scoop@64.132.62.38] has joined #bitcoin-core-dev
05:52 -!- whartung1 [~whartung@185.5.172.147] has joined #bitcoin-core-dev
05:54 -!- scoop [~scoop@ip-184-248-176-199.nymnny.spcsdns.net] has quit [Ping timeout: 245 seconds]
05:59 -!- jonatack [d598a24f@gateway/web/freenode/ip.213.152.162.79] has quit []
06:10 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
06:17 -!- side^effects [~al|iss@gateway/tor-sasl/aliss/x-63218493] has joined #bitcoin-core-dev
06:36 -!- scoop_ [~scoop@64.132.62.38] has quit [Remote host closed the connection]
06:38 -!- scoop [~scoop@64.132.62.38] has joined #bitcoin-core-dev
06:38 -!- scoop [~scoop@64.132.62.38] has quit [Remote host closed the connection]
06:38 -!- scoop [~scoop@64.132.62.38] has joined #bitcoin-core-dev
06:45 -!- darosior [~darosior@193-141-190-109.dsl.ovh.fr] has joined #bitcoin-core-dev
06:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:49 < bitcoin-git> [bitcoin] MarcoFalke pushed 13 commits to master: https://github.com/bitcoin/bitcoin/compare/dae72998e857...e4beef611a42
06:49 < bitcoin-git> bitcoin/master 4368384 Jim Posen: index: Allow atomic commits of index state to be extended.
06:49 < bitcoin-git> bitcoin/master 62b7a4f Jim Posen: index: Ensure block locator is not stale after chain reorg.
06:49 < bitcoin-git> bitcoin/master ba6ff9a Jim Posen: blockfilter: Functions to translate filter types to/from names.
06:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:49 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #14121: Index for BIP 157 block filters (master...bip157-index) https://github.com/bitcoin/bitcoin/pull/14121
06:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:56 < jnewbery> \o/
07:14 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
07:14 < echeveria> seems that broke the tests 
07:16 < MarcoFalke> yeah, it compiled back when I tested it, but now the test header file has been moved to setup_common.h
07:17 < MarcoFalke> echeveria: Mind to fix it?
07:17 < MarcoFalke> yay, silent merge conflicts
07:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:27 < bitcoin-git> [bitcoin] jamesob opened pull request #15843: tests: fix outdate include in blockfilter_index_tests (master...2019-04-blockfilter-include-fix) https://github.com/bitcoin/bitcoin/pull/15843
07:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:29 -!- scoop [~scoop@64.132.62.38] has quit [Remote host closed the connection]
07:29 -!- scoop [~scoop@64.132.62.38] has joined #bitcoin-core-dev
07:33 -!- scoop [~scoop@64.132.62.38] has quit [Remote host closed the connection]
07:33 -!- scoop [~scoop@64.132.62.38] has joined #bitcoin-core-dev
07:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:39 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e4beef611a42...693c743a32e4
07:39 < bitcoin-git> bitcoin/master 89e8df1 James O'Beirne: tests: fix outdate include in blockfilter_index_tests
07:39 < bitcoin-git> bitcoin/master 693c743 MarcoFalke: Merge #15843: tests: fix outdated include in blockfilter_index_tests
07:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:40 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15843: tests: fix outdated include in blockfilter_index_tests (master...2019-04-blockfilter-include-fix) https://github.com/bitcoin/bitcoin/pull/15843
07:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:46 -!- scoop [~scoop@64.132.62.38] has quit [Remote host closed the connection]
07:47 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-dev
07:48 -!- scoop [~scoop@64.132.62.38] has joined #bitcoin-core-dev
07:54 -!- scoop [~scoop@64.132.62.38] has quit [Remote host closed the connection]
07:55 -!- scoop [~scoop@64.132.62.38] has joined #bitcoin-core-dev
08:00 -!- whartung1 [~whartung@185.5.172.147] has quit []
08:00 -!- _Sam-- [~greybits@unaffiliated/greybits] has joined #bitcoin-core-dev
08:04 -!- matael1 [~matael@89.238.178.75] has joined #bitcoin-core-dev
08:12 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 246 seconds]
08:13 -!- jonatack [52661bc3@gateway/web/freenode/ip.82.102.27.195] has joined #bitcoin-core-dev
08:20 -!- scoop [~scoop@64.132.62.38] has quit [Remote host closed the connection]
08:23 -!- morcos_ [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
08:26 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
08:27 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Ping timeout: 256 seconds]
08:27 -!- morcos_ is now known as morcos
08:31 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
08:34 -!- scoop [~scoop@64.132.62.38] has joined #bitcoin-core-dev
08:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:35 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #15778: [wallet] Move maxtxfee from node to wallet (master...remove_maxtxfeerate_from_node) https://github.com/bitcoin/bitcoin/pull/15778
08:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:35 < bitcoin-git> [bitcoin] MarcoFalke reopened pull request #15778: [wallet] Move maxtxfee from node to wallet (master...remove_maxtxfeerate_from_node) https://github.com/bitcoin/bitcoin/pull/15778
08:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:35 < MarcoFalke> PSA: GitHub delivered a corrupt branch for one pull request #15778
08:35 < gribble> https://github.com/bitcoin/bitcoin/issues/15778 | [wallet] Move maxtxfee from node to wallet by jnewbery · Pull Request #15778 · bitcoin/bitcoin · GitHub
08:44 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
08:45 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Remote host closed the connection]
08:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:46 < bitcoin-git> [bitcoin] laanwj pushed 7 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/e57462c6ba60...e753cbd64507
08:46 < bitcoin-git> bitcoin/0.18 8f7cfb0 James O'Beirne: gitignore: add *.dat
08:46 < bitcoin-git> bitcoin/0.18 c69138a James O'Beirne: gitignore: add *.plist (clang-check)
08:46 < bitcoin-git> bitcoin/0.18 9c572e3 Jack Mallers: doc: mention creating application support bitcoin folder on OSX
08:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:46 < bitcoin-git> [bitcoin] laanwj merged pull request #15818: [0.18] doc backports (0.18...0.18-doc-backports) https://github.com/bitcoin/bitcoin/pull/15818
08:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:47 < bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/693c743a32e4...f5aaeae0cdfc
08:47 < bitcoin-git> bitcoin/master 4ddeb2f Luke Dashjr: GUI: Options: Set the range of pruning size before loading its value
08:47 < bitcoin-git> bitcoin/master 8a33f4d Luke Dashjr: GUI: Options: Remove the upper-bound limit from pruning size setting
08:47 < bitcoin-git> bitcoin/master f5aaeae Wladimir J. van der Laan: Merge #15801: Bugfix: GUI: Options: Initialise prune setting range before ...
08:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:47 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/e753cbd64507...a58d80d1b261
08:47 < bitcoin-git> bitcoin/0.18 5546207 Luke Dashjr: GUI: Options: Set the range of pruning size before loading its value
08:47 < bitcoin-git> bitcoin/0.18 a58d80d Luke Dashjr: GUI: Options: Remove the upper-bound limit from pruning size setting
08:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:48 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:48 < bitcoin-git> [bitcoin] laanwj merged pull request #15801: Bugfix: GUI: Options: Initialise prune setting range before loading current value, and remove upper bound limit (master...bugfix_gui_prune_range) https://github.com/bitcoin/bitcoin/pull/15801
08:48 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:51 -!- millerti [~millerti@cpe-66-24-91-119.stny.res.rr.com] has joined #bitcoin-core-dev
08:53 -!- scoop [~scoop@64.132.62.38] has quit [Remote host closed the connection]
08:54 -!- gggggggggggg [~flack@p200300D46F0FA500BC8FAA606FCBEEF9.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
08:56 < MarcoFalke> john has force pushed  #15778, and the branch is no longer corrupted. Though, something to keep in mind when blindly fetching from GitHub.
08:56 < gribble> https://github.com/bitcoin/bitcoin/issues/15778 | [wallet] Move maxtxfee from node to wallet by jnewbery · Pull Request #15778 · bitcoin/bitcoin · GitHub
09:06 < wumpus> MarcoFalke: it's an argument, I think, to encourage signing of the top commit in PRs as well
09:07 < wumpus> at least corruption by github will then always be detected
09:07 < MarcoFalke> Agree
09:08 < MarcoFalke> They could still serve an outdated branch (what happened in this case), but signing is strictly better
09:09 -!- ezzzy [~ezzzy@unaffiliated/ezzzy] has joined #bitcoin-core-dev
09:10 < MarcoFalke> Even a dummy key without a passphrase would be sufficient.
09:10 < MarcoFalke> A one-line wrapper script can be gpg --homedir="/path/to/dummy_key/gpg_dir/"
09:11 < MarcoFalke> And then set git config gpg.program $THE_WRAPPER_SCRIPT
09:12 < MarcoFalke> And then call git commit --gpg-sign=$THE_KEY_ID (or create another wrapper for that)
09:15 -!- tarboss [4fe52b3d@gateway/web/freenode/ip.79.229.43.61] has joined #bitcoin-core-dev
09:16 -!- tarboss [4fe52b3d@gateway/web/freenode/ip.79.229.43.61] has left #bitcoin-core-dev []
09:19 -!- ezzzy [~ezzzy@unaffiliated/ezzzy] has quit []
09:26 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
09:30 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
09:32 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
09:36 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
10:09 -!- Aaronvan_ is now known as AaronvanW
10:12 -!- darosior [~darosior@193-141-190-109.dsl.ovh.fr] has quit [Remote host closed the connection]
10:19 -!- omonk_ [~omonk@unaffiliated/omonk] has quit [Read error: Connection reset by peer]
10:23 -!- jarthur [~jarthur@207.114.244.5] has quit [Remote host closed the connection]
10:23 -!- omonk [~omonk@unaffiliated/omonk] has joined #bitcoin-core-dev
10:24 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
10:33 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
10:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:46 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f5aaeae0cdfc...6ce77a3668b9
10:46 < bitcoin-git> bitcoin/master 2d8ba4f r8921039: remove out-of-date comment on pay-to-witness support
10:46 < bitcoin-git> bitcoin/master 6ce77a3 Wladimir J. van der Laan: Merge #15833: [doc] remove out-of-date comment on pay-to-witness support
10:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:47 < bitcoin-git> [bitcoin] laanwj merged pull request #15833: [doc] remove out-of-date comment on pay-to-witness support (master...fix_comment_ExtractDestinations_does_support_pay_to_witness) https://github.com/bitcoin/bitcoin/pull/15833
10:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:48 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:48 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6ce77a3668b9...84adc79e105c
10:48 < bitcoin-git> bitcoin/master 81b2830 Tobias Kaderle: qt: update request payment button text and tab description
10:48 < bitcoin-git> bitcoin/master 84adc79 Wladimir J. van der Laan: Merge #15829: qt: update request payment button text and tab description
10:48 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:49 < bitcoin-git> [bitcoin] laanwj merged pull request #15829: qt: update request payment button text and tab description (master...squash_rebase_14484) https://github.com/bitcoin/bitcoin/pull/15829
10:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:53 < bitcoin-git> [bitcoin] dongcarl opened pull request #15844: depends: Purge libtool archives (master...2019-04-depends-purge-libtool-archives) https://github.com/bitcoin/bitcoin/pull/15844
10:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:54 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/84adc79e105c...2d4f70cabd6d
10:54 < bitcoin-git> bitcoin/master 942ff20 nkostoulas: contrib: gh-merge: Use pagination to fetch all review comments
10:54 < bitcoin-git> bitcoin/master 2d4f70c Wladimir J. van der Laan: Merge #15838: scripts and tools: Fetch missing review comments in github-m...
10:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:55 < bitcoin-git> [bitcoin] laanwj merged pull request #15838: scripts and tools: Fetch missing review comments in github-merge.py  (master...2019-04-fix-merge-script) https://github.com/bitcoin/bitcoin/pull/15838
10:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:00 -!- matael1 [~matael@89.238.178.75] has quit []
11:04 -!- darosior [~darosior@2a01:e35:2ff9:8200:db25:2326:fa48:942c] has joined #bitcoin-core-dev
11:05 -!- Jayflux [~Jayflux@185.178.49.150] has joined #bitcoin-core-dev
11:23 -!- face [~face@80.72.82.160.coresnet.bg] has quit [Ping timeout: 240 seconds]
11:32 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 250 seconds]
11:36 -!- abbitcryptic [48cd4488@gateway/web/freenode/ip.72.205.68.136] has joined #bitcoin-core-dev
11:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:41 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #15845: wallet: Fast rescan with BIP157 block filters (master...1904-walletFastRescan) https://github.com/bitcoin/bitcoin/pull/15845
11:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:44 -!- abbitcryptic [48cd4488@gateway/web/freenode/ip.72.205.68.136] has quit [Quit: Page closed]
11:54 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
11:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 244 seconds]
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Apr 18 19:00:04 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < jnewbery> hi
12:00 < kanzure> hi
12:00 < sipa> hi
12:00 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb
12:00 < achow101> hi
12:00 < jonasschnelli_> hi
12:00 < jamesob> hi
12:00 < meshcollider> hi
12:00 < MarcoFalke> when rc4?
12:01 < wumpus> #topic 0.18.0rc4
12:01 < jonasschnelli_> I guess #15839 is holding it back
12:01 < gribble> https://github.com/bitcoin/bitcoin/issues/15839 | [0.18] Revert GetData randomization change (#14897) by sdaftuar · Pull Request #15839 · bitcoin/bitcoin · GitHub
12:01 -!- jonasschnelli_ is now known as jonasschnelli
12:01 < MarcoFalke> Needs merge
12:01 < wumpus> that seems to be the only one left?
12:01 < MarcoFalke> yeah, after that I think we are good to tag rc4
12:01 < wumpus> good to know
12:02 < gmaxwell> oh I thought the revert was merged already.
12:02 < wumpus> ok, let's merge that one and tag rc4 after the meeting
12:02 < sipa> ack
12:02 < jonasschnelli> ack
12:02 < MarcoFalke> #action merge 15839 and tag rc4
12:03 < wumpus> #topic High priority for review
12:03 < wumpus> https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+project%3Abitcoin%2Fbitcoin%2F8  6 PRs on there right now
12:04 < wumpus> anything to add/remove? I guess everyone does this outside of the meetings nowadays
12:04 < sipa> can i have 15427?
12:04 < sipa> #15427
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/15427 | Add support for descriptors to utxoupdatepsbt by sipa · Pull Request #15427 · bitcoin/bitcoin · GitHub
12:05 < MarcoFalke> can I have #15758?
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/15758 | qa: Add further tests to wallet_balance by MarcoFalke · Pull Request #15758 · bitcoin/bitcoin · GitHub
12:05 < moneyball> i have a brief topic i'd like to cover after we go through other topics - an opportunity to meet with the github CEO and share feedback from this project
12:05 < jnewbery> gwillen asked for #15024 to go in after the last wallet meeting
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/15024 | Allow specific private keys to be derived from descriptor by meshcollider · Pull Request #15024 · bitcoin/bitcoin · GitHub
12:06 < gwillen> jnewbery: thanks, I was just trying to find that but I'm on an airplane with bad wifi
12:06 < wumpus> sipa MarcoFalke added
12:06 < MarcoFalke> thx
12:06 < sipa> thanks
12:07 < wumpus> also added
12:07 < gwillen> +1 thanks!
12:07 < wumpus> looks like both achow101 and sdaftuar have two PRs on the list now :o
12:07 < achow101> oops
12:08 < jonasschnelli> sdaftuar will resolve now
12:08 < wumpus> can/should we make a choice what to keep on there?
12:08 < MarcoFalke> If they were suggested by different people, it should be fine
12:08 < sipa> i propose a trial by combat to determine whose PRs remain
12:08 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has left #bitcoin-core-dev []
12:08 < MarcoFalke> Everyone can suggest one pr (it doesn't have to be their own)
12:08 < instagibbs> is your PR heavier than a duck
12:08 < wumpus> sipa:everyone gets to have one PR
12:08 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
12:08 < wumpus> MarcoFalke: hmm
12:08 < achow101> instagibbs: how many lines of code does a duck weigh?
12:08 < gmaxwell> Yes, but based on who proposed.
12:08 < jonasschnelli> MarcoFalke: that really hard to keep the overview
12:09 < gmaxwell> not who authored.
12:09 < wumpus> I don't really care but it's kind of getting out of hand
12:09 < gmaxwell> (or that was my understanding)
12:09 < MarcoFalke> but I agree that achow101 and sdaftuar should pick one pull that stays
12:09 < wumpus> jonasschnelli: yeah, exactly
12:09 < jonasschnelli> How do we keep track who proposed?
12:09 < wumpus> github doesn't track this
12:09 < MarcoFalke> remove NOTFOUND for sdaftuar
12:09 < achow101> let's remove #15741 for now. it needs to be rebased anyways
12:09 < wumpus> so are all 9 things on the list proposed by different people?
12:09 < gribble> https://github.com/bitcoin/bitcoin/issues/15741 | Batch write imported stuff in importmulti by achow101 · Pull Request #15741 · bitcoin/bitcoin · GitHub
12:09 < wumpus> ok
12:10 < wumpus> thank you, done
12:10 < gmaxwell> In the future we can use some greppable line in IRC to record requests.
12:10 < wumpus> 7 PRs on the list now, that's just about managebale
12:11 < wumpus> any other topics?
12:11 < moneyball> there are 4 
12:11 < MarcoFalke> moneyball: has a bunch
12:11 < moneyball> https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a
12:11 < jonasschnelli> We could also add a project column per non-author-proposer
12:11 < jonasschnelli> I don't expect we would have a lot
12:11 < wumpus> moneyball: thanks
12:12 < wumpus> #topic Should send-to-non-v0-witness be standard (sipa)
12:12 < sipa> hi
12:12 < sipa> so we currently have two policy rules w.r.t. future segwit versions
12:12 < sipa> one is an IsStandard one that makes sending _to_ a native segwit (bech32) future witness version nonstandard
12:12 < wumpus> jonasschnelli: it's unfortunate that it's not possible to add extra info to the 'cards'
12:13 < sipa> the other is a script rule that makes spending any future witness version (incl. p2sh) nonstandard
12:13 < sipa> i believe that first rule does more harm than good
12:14 < gmaxwell> The tradeoff is: if you make payments to bech32 addresses with 'future' segwit versions, should your payment get stuck (esp ugly for a send many or if your wallet has few inputs)  OR  should users be somewhat more exposed to stupidly sending to an insecure 'future' address. 
12:14 < meshcollider> I'm inclined to agree
12:14 < gmaxwell> I agree the first rule does more harm than good.
12:14 < sipa> i suspect the reason is protecting users, but once the address is already created by the receiver it's already too late
12:14 -!- darosior [~darosior@2a01:e35:2ff9:8200:db25:2326:fa48:942c] has quit [Ping timeout: 258 seconds]
12:14 < sipa> so if we want that rule, i believe it belongs in the wallet, not in relay policy
12:14 < MarcoFalke> No wallet should create thos addresses
12:14 < luke-jr> (getting stuck is a problem because it locks up your change)
12:14 < gmaxwell> To the extent that it provides some real protection, it's mostly a protection against premature activation in wallets.
12:15 < sdaftuar> sipa: are you suggesting it should be wallet rule to not send to those addresses?
12:15 < sipa> sdaftuar: i'm not sure about that; but it shouldn't be more than just wallet
12:15 < gmaxwell> ugh.
12:15 < sdaftuar> sipa: i think i can agree that it should not be a relay policy, but i'm skeptical of making it a wallet rule
12:15 < jnewbery> Currently wallet will send to non-v0 segwit addresses, and mempool won't accept that transaction
12:16 < wumpus> I tend to agree, this selfs a self-sabotaging relay policy
12:16 < sipa> sdaftuar: my point is, trying to guess the reason for this rule, if the rule is desirable, it should be in the wallet :)
12:16 < jnewbery> I think we should have the opposite. Wallet shouldn't send to non-v0 segwit addresses, but mempool should accept and relay
12:16 < luke-jr> tangent: if relay policy allows it, maybe it should always allow RBF on it?
12:16 < sipa> jnewbery: note that it also doesn't work for p2sh embedded segwit, so it's a weak protection at best
12:16 < sdaftuar> jnewbery: if wallet doesn't send to such addresses, we will have a similar problem rolling out v1 segwit addresses as rolling out bech32
12:16 < gmaxwell> jnewbery: Or better, not restict it at all. Refusing to send to it harms forward compatiblity.
12:16 < luke-jr> jnewbery: but isn't the whole point of Bech32's extensibility in this regard, so that we don't need to upgrade wallets to send to new versions?
12:17 < sipa> luke-jr: yup
12:17 < wumpus> forward compatibility is kind of useful
12:17 < meshcollider> Exactly...
12:17 < gmaxwell> and then we end back up with multiple years delay in deploying new functionality, which was what the versions were intended to address.
12:17 < sipa> yeah, i think my preference is not having the rule in the first place
12:17 < luke-jr> IMO allow relay and wallet, but force RBF opt-in ;)
12:17 < jnewbery> delay in bech32 adoption is not caused by Bitcoin Core not supporting bech32 in pre v0.15
12:18 < wumpus> there's *tons* of ways to send coins into the void, I don't think doing this accidentally is anything more likely than sending to a non-existant classic address for ex.
12:18 < meshcollider> So I also dont think the wallet should refuse to send either, a warning at most
12:18 < jnewbery> it's caused by other wallets and exchanges in the ecosystem
12:18 < gmaxwell> We also, for example, don't prevent people from sending to 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T
12:18 < luke-jr> jnewbery: what we do in Core's wallet should be the same as what other wallets ought to do
12:18 < sdaftuar> luke-jr: +1
12:18 < jnewbery> which is not send to non-v0 until there is a defined v1
12:18 < wumpus> a warning would be okey
12:18 < achow101> the fact that it's not a relay policy will lock up change
12:18 < gmaxwell> We certantly cannot argue that varrious parties are not doing the right thing if we won't do that thing ourselves
12:19 < wumpus> but I think we agree, this should not be relay policy
12:19 < sipa> i'll PR removing it from relay policy
12:19 < wumpus> relay policy has never been used to protect users, if so, why no excessive fee check?
12:19 < sipa> wumpus: exactly
12:19 < gmaxwell> wumpus: kinda one sec on that point.
12:19 < jonasschnelli> indeed
12:19 < instagibbs> sipa, it's worth a mailing list email?
12:19 < jnewbery> I'm not saying we should never send to v1. Clearly we should change wallet policy when the node includes support for v1
12:19 < gmaxwell> wumpus: There is a non-protection argument too... we generally tend to not relay forward compatiblity features, in order to protect their future usage.
12:19 < jonasschnelli> instagibbs: seems to be Core policy,... no need for ML?!
12:20 < luke-jr> jnewbery: but then we could just as well make a new address format for every version
12:20 < gmaxwell> wumpus: but for _output types_ this doesn't apply.
12:20 < wumpus> gmaxwell:right
12:20 < cfields> replace-by-version? :p
12:20 < MarcoFalke> jnewbery: Wallet support to generate v1 addresses can always wait after the fork activated
12:20 < luke-jr> jonasschnelli: it seems likely a topic other software would want to consider and act on too
12:20 < sipa> actually
12:20 < instagibbs> jonasschnelli, people may have made assumptions based on current policy, right or wrong?
12:20 < jnewbery> luke-jr: that' not the same at all. This is a one-line (or config) or config
12:20 < gmaxwell> jnewbery: and then we will end up with multiple year delays after activation before v1 can be used by wallets.
12:20 < sipa> this is a violation of BIP173
12:20 < gmaxwell> sipa: correct.
12:20 < sipa> "Version 0 witness addresses are always 42 or 62 characters, but implementations MUST allow the use of any version. "
12:20 < jonasschnelli> oh
12:21 < wumpus> it makes sense to inform people on the ML
12:21 < jonasschnelli> so we need to change BIPS.md :p
12:21 < gmaxwell> The intentional and widely discussed design of BIP173 was to enable seemless use of future versions.
12:21 < wumpus> it doesn't need to be *discussed* there, IMO, but mentioning it so there is awareness is good
12:21 < luke-jr> considering BIP173, it's arguably a bug to fix in backports even ;)
12:21 < sipa> i believe this code actually predates bip173
12:21 < gmaxwell> sipa: it does.
12:21 < wumpus> heh
12:22 < achow101> so is the change to allow sending to non-v0 but not relay transactions with non-v0 outputs?
12:22 < MarcoFalke> wallets should send to any address a merchant provides them, but the wallet itself should only generate v1 addresses after the v1 fork activated
12:22 < luke-jr> achow101: inputs*?
12:22 < sipa> achow101: i'd just drop the rule entirely
12:22 < luke-jr> MarcoFalke: I'd even wait at least >=100 blocks after , but that's another discussion
12:22 < gmaxwell> We need to not relay v1+ _spends_ in order to protect the activation of future v1+ rules.  Outputs are fine.
12:22 < sipa> maybe we want to independently add a warning in the GUI
12:23 < MarcoFalke> achow101: outputs would be relayed, but spending from them would be non-standard
12:23 < luke-jr> sipa: policy should prevent spending v1 UTXOs
12:23 < sipa> luke-jr: it already does
12:23 < achow101> ah, I see
12:23 < luke-jr> sipa: nah, because of P2Sh stuff
12:23 < luke-jr> sipa: yes, but it sounded like you might be talking about dropping it too
12:23 < sipa> luke-jr: even P2SH-embedded v1 segwit output spends will not be relayed
12:23 < sipa> ah no, i'm only talking about the sending to part
12:23 < luke-jr> k
12:23 < sipa> (which is implemented completely independently)
12:24 < gmaxwell> right thats another point against blocking v1 outputs:  It's _impossible_ to block p2sh v1 outputs...
12:24 < sdaftuar> it would be nice to not bother implementing p2sh for v1, i think?
12:24 < luke-jr> and because of ^, I don't think we should warn sending to v1 outputs either
12:25 < luke-jr> sdaftuar: is there a benefit to that?
12:25 < achow101> sdaftuar: nothing prevents anyone from making a p2sh with v1 as redeemscript though
12:25 < sipa> that's an independent discussion
12:25 < gmaxwell> There are many ways people can hand you insecure addresses already... I at least don't have any reason to think that insecure future-version addresses are a worse problem than things like copy and pasting example addresses.
12:25 < instagibbs> achow101, you can define it to be illegal tho
12:25 < sipa> jnewbery: what's your opinion?
12:25 < instagibbs> or just leave it undefined
12:25 < sdaftuar> sipa: agreed, but it drives the point home that we want v1 addresses to be forward compatible
12:25 < gmaxwell> achow101: we could, for example, close of p2sh embedded spending in the future entirely.
12:25 < gmaxwell> s/of/off/
12:26 < jnewbery> I still believe that the wallet shouldn't send to v1+ addresses until the node can validate them
12:26 < gmaxwell> jnewbery: what do you mean by validate them?
12:26 < luke-jr> ^
12:26 < jnewbery> I think people upgrade Bitcoin Core fairly frequently in general, so I can't see this being something that holds up adoption of segwit v1
12:26 < gmaxwell> There normally isn't really any validation of outputs.
12:26 < luke-jr> why does the sender care if the recipient spends it or not
12:26 < jnewbery> I mean that they can be spent
12:27 < instagibbs> sdaftuar, another point to doing that is then you *know* which version you're sending to, up to wallet to guard against edge cases
12:27 < jnewbery> All other things being equal, I'd prefer the wallet not to be able to send to a class of unspendable addresses that we can easily check
12:27 < luke-jr> jnewbery: the sender doesn't know if they can or can't be spent
12:27 < sipa> jnewbery: would you be ok with a GUI-only warning?
12:27 < wumpus> so to be clear: the discussion is about the relay policy, the wallet is a different topic
12:27 < jnewbery> for example, we don't send to v0 with non 42/64 character witnesses
12:27 < gmaxwell> (FWIW, most of my inbound peers are older versions... many old enough to have no bech32 support)
12:27 < luke-jr> jnewbery: it is spendable, just rejected by policy
12:28 < gmaxwell> jnewbery: yes, because v0 is defined now. There is no forward compatiblity problem.
12:28 < jnewbery> I'd be ok with anything. I'm just expressing an opinion, which it appears is minority :)
12:28 < wumpus> the wallet not being able to send to certain addresses doesn't nearly block forward compatiblity as much as a restrictive relay policy does
12:28 < sipa> gmaxwell: relaying of v0 witness outputs was added in 0.13.0 though; long before bech32 was implemented
12:28 < luke-jr> most nodes are 0.16 still
12:28 < jonasschnelli> I think we should allow sending to v1+ in the wallet and in the GUI
12:28 < jnewbery> Right, my opinion is that the forward-compatibility issue is not a huge issue
12:28 < gmaxwell> most newly syncing nodes I see are 0.16.1 ... fwiw. which it's own puzzle...
12:29 < wumpus> jnewbery: you mean not for relaying either?
12:29 < luke-jr> 0.16.1 is 50% of all nodes it looks like
12:29 < jonasschnelli> forward compatibility seems to be more important than foot-gun that trigger very very rarely
12:29 < jnewbery> No, I think we should relay sending to V anything
12:29 < jonasschnelli> And we don't (and can't) prevent P2SH forms anyway
12:29 < wumpus> I'm confused now
12:30 < jnewbery> I think we're all in agreement about mempool policy
12:30 < wumpus> so, do we agree on changing this relay policy?
12:30 < jonasschnelli> yes
12:30 < sipa> i think so
12:30 < meshcollider> Yes
12:30 < luke-jr> +1
12:30 < achow101> ack
12:30 < gmaxwell> luke-jr: I think something weird is going on wrt versions, so that figure might be distored. (e.g. run your figures but exclude china...)
12:30 < jnewbery> the only thing we disagree about is whether there should be a wallet check. I say yes, but I haven't convinced anyone :)
12:30 < wumpus> ok!
12:30 < jonasschnelli> I guess the we are not agreeing about wether the wallet allows to send to v1+ 
12:30 < wumpus> jnewbery: I think a warning makes sense
12:30 < meshcollider> I'm ok with a wallet warning
12:30 < luke-jr> gmaxwell: Chinese users are real though?
12:30 < gmaxwell> I think a warning is foolish.
12:31 < jonasschnelli> me 2
12:31 < luke-jr> if we could reliably warn, it might be worth considering, but we can't
12:31 < gmaxwell> luke-jr: Yes but I'm not confident that they're users. We can talk offline.
12:31 < jonasschnelli> Assume one will send to v1 with 0.18.0 in one year where we assume having v1
12:31 < luke-jr> becuase of p2sh etc
12:31 < jonasschnelli> (if 0.18.0 would have the warning)
12:31 < luke-jr> jonasschnelli: if warnings were reliable, we could base it on what we see in blocks
12:31 < gmaxwell> I could even see blocking sending, but only up until a certian time.
12:32 < jonasschnelli> I'm sure users would send to the p2sh version of it just thy bypass the warning
12:32 < luke-jr> eg, if we see a softfork deployment, and a bunch of v1 txs getting mined, then okay
12:32 < gmaxwell> But forever warning or blocking is just going to make it so that we can't quickly switch to v1 address generation by default.
12:32 < jonasschnelli> luke-jr: yes. But that complex to implement without knowing the future
12:32 < MarcoFalke> How would the warning be worded?
12:32 < luke-jr> well, because we can't detect it reliably anyway, no point doing it even that way
12:33 < gmaxwell> I feel like the principle of outputs is being lost here.
12:33 < luke-jr> (I suppose we could look for spends getting mined instead)
12:33 < gmaxwell> When a third party provides you with an output, thats it. It is none of your business what their policy is.
12:33 < sdaftuar> gmaxwell: i agree with that
12:33 < gmaxwell> This is one of the underlying principles behind p2sh and later hash based addresses.
12:33 < luke-jr> gmaxwell: good point
12:33 < MarcoFalke> "Warning: You are sending to an address that miners can steal from"?
12:33 < gmaxwell> It's an important principle because it lets the ecosystem evolve without everyone else getting up in your business. :P
12:33 < instagibbs> We can't do anything when someone gives you a bcash address either
12:34 < luke-jr> MarcoFalke: that might not be true though
12:34 < jonasschnelli> Warning if the last <tbd> blocks have no Vx output spent is probably an overkill?
12:34 < MarcoFalke> And the the users go on reddit and ask what it means
12:34 < gmaxwell> MarcoFalke: that warning wouldn't be true after some point in the future.
12:34 < MarcoFalke> s/can/may for a limited time/
12:34 < instagibbs> I'm not sure what warnings would achieve.
12:35 < luke-jr> it would achieve people moving back to P2SH wrappers
12:35 -!- Kvaciral [~Kvaciral@94-214-185-162.cable.dynamic.v4.ziggo.nl] has joined #bitcoin-core-dev
12:35 < instagibbs> lol
12:35 < sdaftuar> yuck!
12:35 < gmaxwell> and still sending to v1
12:35 < gmaxwell> :P
12:35 < luke-jr> right
12:36 < wumpus> time for next topic, I think
12:36 < jnewbery> +1
12:36 < wumpus> #topic Bitcoin Core design documentation (jnewbery)
12:36 < gmaxwell> instagibbs: good point on the bcash addresses. I've been told that this has been causing some pretty big nussances for some people (mostly the other direction, someone buys bcash thinks its bitcoin and sends it to an exchange bitcoin address....)
12:36 < MarcoFalke> I'd prefer: "Warning: You are sending to a p2sh address"
12:36 < instagibbs> gmaxwell, happens a lot, and actually forcing people onto bech32 would fix these since they have their own bch code thing
12:37 < jnewbery> There are currently a lot of high-level design considerations that aren't documented in the codebase. Some of them may exist in individual contributor's gists, or might not be written down at all.
12:37 < jnewbery> Should we try to have some standard location to put them in so it's easier for people to understand why things are the way they are? One suggestion would be to use github's wiki feature.
12:37 < jnewbery> Examples: P2P banning/disconnecting design philosophy
12:37 < instagibbs> jnewbery, ACK, but note that it's mostly me imagining other people doing the work
12:37 < wumpus> why not the doc folder?
12:37 < jnewbery> Past critical bugs that have been fixed
12:37 < achow101> we have that devwiki repo we use for release notes. could put other docs there
12:37 < jonasschnelli> I also prefer within the sources
12:38 < MarcoFalke> agree with wumpus. Should be in ./doc/
12:38 < jonasschnelli> Also,.. how do we prevent from getting outdated?
12:38 < gmaxwell> I'd prefer within the codebase, in particular because keeping a durable copy of github issues/wikis/etc is a lot more work.
12:38 < MarcoFalke> jonasschnelli: Yell at people for not updating the docs
12:38 < wumpus> achow101:yes, that would be another option
12:38 < jnewbery> I don't think adding docs should go through the same review process as code changes
12:38 < gmaxwell> Maybe put a boiler plate header on them that they could be outdated.
12:38 < jnewbery> gmaxwell: github wikis are repos. You can clone them locally
12:38 < gmaxwell> and add a last updated date to each document or something.
12:38 < wumpus> jonasschnelli:same with anything else, it needs to be maintained or will be removed again at some point
12:39 < MarcoFalke> jnewbery: yes they should. Wrong documentation is more harmful than no documentation
12:39 < gmaxwell> even having it in the history is useful too.
12:39 < luke-jr> IMO it should be separate from the code.
12:39 < wumpus> but I like the idea, if anyone is willing to write this ata ll
12:39 < luke-jr> this is an easy case to modularise; it has no ties to our versions/branches
12:39 < sipa> i like the idea of putting a "Last updated at" + warning it could be outdated
12:39 < sdaftuar> MarcoFalke: wait what, wrong documentation is more harmful than nothing?  can you explain?
12:40 < gmaxwell> I don't really care what repo its in, just should be in some repo for sure. :)
12:40 < jnewbery> I'm not suggesting that someone goes and writes a bunch of documentation. I'm suggesting that people who want to contribute documentation should have somewhere to put it.
12:40 < instagibbs> to motivate this, things like p2p design are basically in the heads of a handful of people, I've never seen it written down anywhere aside from IRC
12:40 < wumpus> sdaftuar: because it gets people to waste time, thinking of solutions based on the documentation, then it doesn't really apply to the current code base anymore
12:41 < MarcoFalke> sdaftuar: I was talking about review
12:41 < gmaxwell> sdaftuar: I'm also of the view that wrong documentation can be worse than nothing.  ::shrugs:: it isn't always. Depends on the recipent and how the wrong doc was written.
12:41 < MarcoFalke> not about outdated documentation
12:41 < gmaxwell> (okay maybe not also)
12:41 < sdaftuar> wumpus: MarcoFalke: i definitely believe in review, but i imagine that mostly you're better off with old docs, rather than no docs
12:41 < gmaxwell> But I still think it's worth doing even if it ends up outdated.
12:42 < wumpus> wrong code comments can cause a lot of damage, maybe less so for high level docs
12:42 < gmaxwell> Its just somewhat important the the text itself reflect the possibility of it being outdated.
12:42 < MarcoFalke> agree that outdated (timestamped) documentation is helpful
12:42 < sdaftuar> anyway i would certainly appreciate having a place to put docs that i have written, so if we can decide to put stuff like that anywhere, i will happily contribute
12:42 < jnewbery> An argument for a wiki and not in the PR is that we won't get a bunch of helpful new contributors opening PRs to fix spelling in the docs
12:42 < wumpus> well, put it in the wiki then
12:42 < jnewbery> *not in the repo
12:42 < wumpus> everyone has write access to that one :)
12:43 < gmaxwell> Is a bunch of spelling fixes important? :P
12:43 < luke-jr> github wikis are just git repos
12:43 < jnewbery> I don't think it exists for bitcoin/bitcoin
12:43 < wumpus> gmaxwell:not important, but I agree re: PR bottlenecks
12:43 < MarcoFalke> which is the downside that anyone can vandalize
12:43 < wumpus> jnewbery: it doesn't for access control
12:43 < wumpus> jnewbery: please use the devwiki
12:43 < MarcoFalke> how hard is it to run a spellchecker these days?
12:43 < wumpus> https://github.com/bitcoin-core/bitcoin-devwiki/wiki
12:43 < luke-jr> MarcoFalke: can address that when/if it happens
12:43 < MarcoFalke> ok
12:43 < jnewbery> why not a wiki in bitcoin/bitcoin?
12:43 < luke-jr> jnewbery: because it's Core-specific?
12:44 < wumpus> because it'd only be writabel by people with commit access
12:44 < jnewbery> ah
12:44 < luke-jr> (and if it isn't, we have BIPs)
12:44 < sipa> we could also see from time to time whether a wiki article is sufficiently mature and stable to include it in the doc/ directory directly
12:44 < gmaxwell> Also be careful with making publically writable stuff in bitcoin/bitcoin.
12:44 < wumpus> the only way to do delegation on github is to have multiple repos
12:44 < wumpus> gmaxwell: yes, I don't want that
12:44 < jonasschnelli> gmaxwell: indeed
12:44 < gmaxwell> "ATTENTION. OLD BITCOIN IS VULNERABLE. DOWNLOAD HOTFIX NOW  http://secure.haxor.com/bitcoin.exe"
12:44 < MarcoFalke> hmmm
12:44 < sdaftuar> ouch :(
12:45 < wumpus> no need to throw everything in the same place
12:45 < jonasschnelli> heh
12:45 < jnewbery> ok, thanks. Sounds like https://github.com/bitcoin-core/bitcoin-devwiki/wiki is the place
12:45 < luke-jr> gmaxwell: 404
12:45 < sipa> lol
12:45 < MarcoFalke> 15 minutes left. Next topic
12:45 < jonasschnelli> rofl
12:45 < luke-jr> but wait, I need to get the hotfix!
12:45 < gmaxwell> luke-jr: "wine <urlib error>: 404"
12:45 < wumpus> #topic opportunity to provide feedback with GitHub CEO (moneyball)
12:46 < instagibbs> you gotta add sudo
12:46 -!- darosior [~darosior@2a01:e35:2ff9:8200:db25:2326:fa48:942c] has joined #bitcoin-core-dev
12:46 < MarcoFalke> moneyball is github ceo?
12:46 < moneyball> so jimpo and i received an email from a guy at github: I run a program for our CEO Nat Friedman connecting him with community members in GitHub. It’s an hour long chat on Friday’s where you can talk about anything GitHub that’s on your mind. I was wondering if you all would like to join us. You’re welcome to bring other maintainers up to a max of about 7 people. Many groups bring a “top 10” list with
12:46 < moneyball> them and we go through that. We also have some demos and mockups of stuff to show and then discuss. Tell us how to improve GitHub. 
12:46 < wumpus> (I don't really have anything to discuss wrt hardcoded seeds at the moment)
12:46 < meshcollider> wumpus: you can allow anyone to edit the wiki, not just those with write access, but yeah thats a problem in itself
12:46 < MarcoFalke> wumpus: ok
12:46 < instagibbs> moneyball, sorry who is "we" wrt demos
12:46 < cfields> moneyball: +1! There's something that we've been discussing in a separate thread, this would be a great opportunity.
12:47 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]
12:47 < moneyball> This is an opportunity for the project to communicate 1) annoying bugs/reliability issues 2) new feature requests 3) maybe what it would take for the project to be comfortable using GitHub long-term
12:47 < gmaxwell> sounds good for people with opinions. :)
12:47 < cfields> (we=DCI)
12:47 < moneyball> I am happy to attend this but (a) we need to compile a list (b) it would really be better if at least 1 other dev joined me who has deeper experience with the top 10 list than I do
12:47 < cfields> instagibbs: lol, sorry, that wasn't in response to you.
12:47 < luke-jr> open source github? :p
12:47 < MarcoFalke> feature request: Nicely display pgp signed comments
12:47 < wumpus> meshcollider: maybe, but once you want to lock down access, the only mechanism is the list of people with write access to the repo, which is the people with commit access
12:47 < moneyball> luke-jr: i'd say nothing is off-limits!
12:48 < luke-jr> MarcoFalke: eh, trusting GitHub to verify PGP seems like a bad idea
12:48 < MarcoFalke> Just display, not verifying
12:48 < jonasschnelli> Probably interested people should form a list of feature requests and/or bugs (gist or wiki)
12:48 < instagibbs> stop having commits reported in git commit timestamp order :P
12:48 < moneyball> instagibbs: "we" is github
12:48 < jonasschnelli> No need to post your feature request here and now
12:48 < sipa> yeah
12:48 < luke-jr> instagibbs: that's git-log's default too though
12:48 < moneyball> yeah i am not intending to create the list right now in this meeting
12:48 < jonasschnelli> moneyball: Thanks and great opportunity I agree
12:48 < cfields> moneyball: I'd be interested.
12:48 < moneyball> i wanted to see if others view this as a valuable opportunity and whether 1 or more folks would join me
12:48 < gmaxwell> if someone makes a list I'll dump some gripes in and other people can decide if they agree or think they're important.
12:48 < gwillen> instagibbs: yes for the love of god, displaying commits in topo instead of timestamp order 
12:49 < gwillen> there has been an open issue on this for a fucking age
12:49 < meshcollider> It is in-person right, not remote attendance?
12:49 < gwillen> (for reference https://github.com/isaacs/github/issues/386)
12:49 < moneyball> an in-person lunch in SF
12:50 < luke-jr> gwillen: --graph would be nice too :p
12:50 < gwillen> let's not ask for a pony here ;-)
12:50 < wumpus> gwillen: yes please
12:50 < sipa> maybe open an issue on our tracker, where people can comment with things to mention?
12:51 < sipa> (also, ack topo sort; i've personnally asked them for this years ago)
12:51 < MarcoFalke> +1 instagibbs suggestion
12:51 < jnewbery> yes please!
12:51 < moneyball> sipa: i will do that
12:51 < wumpus> what I"d like is to be able to do finer permission control, e.g. be able to give people access to issues/PR management without giving them write and merge access to the repo
12:52 < sipa> moneyball: thanks
12:52 < moneyball> if anyone would like to join cfields and me, let me know so we can coordinate a date with GitHub
12:52 < luke-jr> wumpus: maybe github rejecting pushes that don't pass the checker script is sufficient
12:52 < moneyball> in the mean time please contribute to the Issue i'll create. i'll post it here once created.
12:52 < meshcollider> Sounds good
12:53 < cfields> I think it'd be most useful for us to discuss things that are paranoia-related, since that's what's most interesting about us to them, I'd think.
12:53 < wumpus> luke-jr: well if 'checker script' is sufficiently general, sure, though I wouldn't want to include the entirety of travis in there, such a check needs to be fast
12:53 < cfields> Things like "display order" they'll hear from everyone.
12:53 < ryanofsky> my github feature request would be ability to base prs on top of other prs (just hide commits from base pr)
12:53 < luke-jr> wumpus: eg, just the PGP checks
12:53 < jnewbery> They should hear it from everyone!
12:53 < luke-jr> ryanofsky: ooh, good idea
12:53 < meshcollider> I'd like a better "boomark this PR" system to keep track of interesting PRs I want to come back to
12:53 < gmaxwell> luke-jr: that was exactly my thought.
12:54 < sipa> cfields: good point
12:54 < gmaxwell> (re enforce pgp allowing for access split)
12:54 < jonasschnelli> paranoid-mode would probably exclude using github
12:54 < cfields> ok, maybe s/paranoia-related/related to the way we use github uniquely/
12:54 < sipa> cfields: i suspect the ways in which we most _differ_ from other projects is in centralization/trust concerns
12:54 < cfields> sipa: yes, right.
12:54 < wumpus> jonasschnelli:yes, I think that's a very slippery slope :)
12:54 < gwillen> cfields: that makes sense, but on the other hand they have been ignoring the display order thing for almost 5 years
12:54 < sipa> any other topics?
12:54 < instagibbs> 6 min left
12:54 < gmaxwell> gwillen: thre just may be an arch reason as to why its hard.
12:54 < luke-jr> one thing I would find useful: a way for email notifications to distinguish between general project stuff, and stuff specifically I'm invovled in, and stuff I'm specifically mentioned in
12:54 < wumpus> don't think so
12:54 < gwillen> so if they're literally asking us for feedback, it would be good to say "why are you ignoring community feedback, please listen to it"
12:55 < luke-jr> right now I often just ignore github notifications in bulk because there's so many, and don't see when people ask me things
12:55 < ryanofsky> luke-jr, i think that already exists, you can filter based on to address
12:55 < wumpus> luke-jr:there is, you acn filter on author@github.com and things like that
12:55 < cfields> moneyball: maybe you can provide some context for why they reached out to us specifically?
12:55 < gmaxwell> I mean. there is a lot of little stuff, like they were totally unable to keep randos from taking over the attribution on imported commits, but we eventually 'fixed' that by creating a dummy account.  I don't think this is worth discussing, since we 'fixed it' but its still kind of embarassing on their part.
12:56 < moneyball> jimpo and i had emailed them previously during the unicorn days, so our same contact reached back out to us
12:56 < luke-jr> wumpus: I don't understand
12:56 < jonasschnelli> But never forget, they need community feedback to improve to earn money for corporate customers
12:56 < jonasschnelli> *from
12:56 < ryanofsky> luke-jr, if you want to filter mentions look for Mention <mention@noreply.github.com> in To: header
12:56 < gwillen> gmaxwell: I definitely agree on focusing on active problems with no good workaround
12:56 < wumpus> luke-jr there's a special to-address they'll add in those cases fornmentions
12:56 < cfields> moneyball: heh, gotcha. Thanks.
12:56 < luke-jr> hmm
12:57 < wumpus> #endmeeting
12:57 < lightningbot> Meeting ended Thu Apr 18 19:57:44 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:57 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-18-19.00.html
12:57 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-18-19.00.txt
12:57 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-18-19.00.log.html
12:58 < gmaxwell> gwillen: it may also be with the ownership change their priorties are usefully different now.
12:58 < wumpus> luke-jr: https://help.github.com/en/articles/about-email-notifications#filtering-email-notifications mentions all of them
12:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:58 < bitcoin-git> [bitcoin] sipa opened pull request #15846: [POLICY] Make sending to future native witness outputs standard (master...201904_futuresegwitstandard) https://github.com/bitcoin/bitcoin/pull/15846
12:58 < gwillen> gmaxwell: I would say the right focus is on impact-to-us in our issues, which does not rule out little things if they are actively causing problems
12:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:58 < gwillen> I think it's better to get them to fix supid little shit than to ask them for important things they'll never do
12:58 < cfields> moneyball: Thanks for bringing that up!
12:58 < gwillen> (but obviously both would be nice)
12:59 < luke-jr> wumpus: thanks
13:00 < gmaxwell> gwillen: like eons back I was talking to someone at github and telling them that I wanted a feature where you could set a repo so that newly created issues / PRs would only be visible to the submitter/project contribs (or at least logged in users) for 24 hours or whatever, in order to cut down abuse of github for trolling... and the reply was that sort of thing wouldn't be a popular feature in 
13:00 < gmaxwell> github because it would retard account growth.
13:00 < gmaxwell> Maybe that would be less important now.
13:01 < gwillen> I think this is exactly the sort of thing to bring up when they think we're important enough to ask us for feedback
13:01 < gmaxwell> (that was motivated by a couple instances where some trolling jerk opened a PR to do some dumb change then went and spammed reddit with CORE DEVS GONNA XXX!)
13:01 < gwillen> (I do agree it's also a good opportunity to bring up philosophically-aligned stuff about privacy and trust)
13:01 < instagibbs> would also be nice so i dont have to read "ACTIVATED 1GB BLOCKS" PRs
13:02 < instagibbs> as a non-maintainer
13:02 < gmaxwell> I'm not sure how much of that is just my dislike of the modern 'everyone can scribble on everything' web. :P
13:03 < wumpus> it would have been nice, with better people
13:04 < gwillen> "better people" would solve many problems, but it was not to be
13:04 < sipa> like the need for bitcoin?
13:04 < wumpus> ^^
13:04 < gwillen> heh!
13:05 < gwillen> gmaxwell: in seriousness I think better anti-troll features would be huge for github in light of its increasing use as a Social Netowkr
13:05 < gwillen> and also as a platform for grandstanding
13:06 < gmaxwell> (related, githubs anti-spam has burned us a couple times with them vanishing perfectly reasonable comments without a trace and it looking like we deleted them)
13:06 < gwillen> this would help with all the "rar I want to make a political statement against your repository" issues
13:06 < gwillen> since there would no longer be a motivation to file them if they could be moderated before publication
13:06 < gmaxwell> yup.
13:07 < jonasschnelli> If I could ask for a feature, then it would be making github commit order rebase save
13:07 < gmaxwell> gwillen: Also it would be less stressful to deal with them.
13:07 < gwillen> jonasschnelli: is this the same as the toposort thing we were discussing upthread
13:07 < gwillen> or a different issue
13:07 < gmaxwell> just another idiot with an offtopic request, ... ploink.
13:07 < gmaxwell> vs oh god inescapable dramafest.
13:09 < jonasschnelli> gwillen: I don't know what toposort refers to... but then one I mentioned is that once you do a rebase, the commit order it messed up
13:10 < moneyball> Please submit your ideas for improving GitHub here! https://github.com/bitcoin/bitcoin/issues/15847
13:10 < sipa> jonasschnelli: yes, github sorts commits by author date
13:10 < sipa> jonasschnelli: not by their dependency order
13:10 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:10 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2d4f70cabd6d...d1c2ed8dd768
13:10 -!- darosior [~darosior@2a01:e35:2ff9:8200:db25:2326:fa48:942c] has quit [Ping timeout: 258 seconds]
13:10 < bitcoin-git> bitcoin/master fa346fe MarcoFalke: doc: Remove upgrade note in release notes from EOL versions
13:10 < bitcoin-git> bitcoin/master d1c2ed8 MarcoFalke: Merge #15821: doc: Remove upgrade note in release notes from EOL versions
13:10 < jonasschnelli> Making it impossible to manually sort things or even group with pure "message-commits" 
13:10 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:11 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15821: doc: Remove upgrade note in release notes from EOL versions (master...1904-docRelEOL) https://github.com/bitcoin/bitcoin/pull/15821
13:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:11 < gwillen> jonasschnelli: yeah, that is the same issue that at least half a dozen people in here also mentioned including me
13:11 < gwillen> so we should include it in our feedback for sure :-)
13:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:11 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/a58d80d1b261...607b1b74986b
13:11 < bitcoin-git> bitcoin/0.18 8602d8b Suhas Daftuar: Revert "Change in transaction pull scheduling to prevent InvBlock-related ...
13:11 < bitcoin-git> bitcoin/0.18 607b1b7 MarcoFalke: Merge #15839: [0.18] Revert GetData randomization change (#14897)
13:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:12 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15839: [0.18] Revert GetData randomization change (#14897) (0.18...2019-04-revert-14897) https://github.com/bitcoin/bitcoin/pull/15839
13:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:13 < MarcoFalke> So pull in the release notes and tag rc4?
13:16 < wumpus> find w/ me
13:18 < wumpus> huh didi I forget to push my translations update?
13:20 < MarcoFalke> there was one for rc3 or rc2, I might recall
13:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:22 < bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/607b1b74986b...a4fc2fbb111e
13:22 < bitcoin-git> bitcoin/0.18 a4fc2fb Wladimir J. van der Laan: gui: Pre-rc4 translations update
13:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:24 -!- darosior [~darosior@37.173.83.180] has joined #bitcoin-core-dev
13:28 < kanzure> why is bitcoin-git exiting so frequently. can we fix this?
13:29 < sipa> it joins for every message
13:30 < gwillen> it is not a persistent process, it is stateless, so it can't stay joined when not messaging
13:30 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:30 < luke-jr> if we remove the +n on the channel, it can send without joining
13:31 < luke-jr> this may or may not be spam suicide though
13:31 < gwillen> right
13:31 < gwillen> probably better to tolerate a few extra lines
13:31 < wumpus> we had that in the past, but it's not a good idea
13:31 < gwillen> I'm not sure how -n interacts with bans, it might make them ineffective
13:32 < wumpus> FWIW in general it can be pretty useful to disable join/part notifications for busy channels like this
13:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:32 < bitcoin-git> [bitcoin] darosior opened pull request #15848: Add a check for free disk space at first startup. ref #15813 (master...check_free_disk_size) https://github.com/bitcoin/bitcoin/pull/15848
13:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:34 < luke-jr> wumpus: my client only does it globally
13:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:38 < bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/a4fc2fbb111e...438483983a45
13:38 < bitcoin-git> bitcoin/0.18 4384839 Wladimir J. van der Laan: doc: Move release notes from wiki
13:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:39 < sdaftuar> laanwj: i was just trying to edit the wiki to remove mention of 14897 from the release notes
13:39 < sdaftuar> er wumpus ^^
13:41 < sdaftuar> i guess there are other edits that still need to be made as well, should we just do that via PR between now and final release?
13:41 < wumpus> sdaftuar: uhmm
13:41 < wumpus> sdaftuar: I see various TODOs by Pieter are also still in there
13:41 < sdaftuar> yeah i just saw that too
13:41 < wumpus> for this reason I prefer to leave merging back the release notes for -final instead of a rc
13:42 < wumpus> but yes, only way to edit it now is on the branch
13:42 < sdaftuar> ok sounds good
13:42 < gmaxwell> why doesn't the bot just stay in all the time?
13:43 < wumpus> ready to tag rc4?
13:43 < gwillen> gmaxwell: it can't, it's stateless
13:43 < wumpus> gmaxwell: gwillen | it is not a persistent process, it is stateless, so it can't stay joined when not messaging
13:43 < wumpus> it's a design choice
13:44 < wumpus> it'd certainly be possible to have a persistent bot, but, github's own notification did exactly the same as this and that's what we ported
13:47 < wumpus> FWIW source for the bot is here, I guess persistent bot functionality would be welcome if anyone implemented it: https://github.com/gkrizek/ghi
13:49 -!- darosior [~darosior@37.173.83.180] has quit [Quit: Leaving]
13:50 -!- darosior [~darosior@37.173.83.180] has joined #bitcoin-core-dev
13:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:51 < bitcoin-git> [bitcoin] laanwj pushed tag v0.18.0rc4: https://github.com/bitcoin/bitcoin/compare/v0.18.0rc4
13:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:51 < bitcoin-git> [bitcoin] laanwj deleted tag v0.18.0rc4: https://github.com/bitcoin/bitcoin/compare/9b2d3aafcf91...000000000000
13:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:52 < bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/438483983a45...379f71ea4f27
13:52 < bitcoin-git> bitcoin/0.18 379f71e Wladimir J. van der Laan: build: Bump version to rc4
13:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:53 < bitcoin-git> [bitcoin] laanwj pushed tag v0.18.0rc4: https://github.com/bitcoin/bitcoin/compare/v0.18.0rc4
13:53 -!- darosior [~darosior@37.173.83.180] has quit [Read error: Connection reset by peer]
13:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:54 -!- darosior [~darosior@2a01:e35:2ff9:8200:db25:2326:fa48:942c] has joined #bitcoin-core-dev
13:58 < gmaxwell> luke-jr: I've been monitoring not just what versions I see out there, but also hosts that connect to me that are fetching old blocks-- IOW ones that look like they're syncing up.
13:59 < gmaxwell> luke-jr: and I've noticed that almost all syncing up hosts I see are 0.16.1 and coming from a relatively small number of networks in china.
13:59 < gmaxwell> Which made me wonder if perhaps some chinese language docs pointed to an outdated download... but jl2012 was unable to find anything.
14:00 -!- Jayflux [~Jayflux@185.178.49.150] has quit []
14:02 < gmaxwell> also their behavior appears to be weird, e.g. I see them downloading a moderate number of blocks then stop and stay connected.
14:06 -!- darosior [~darosior@2a01:e35:2ff9:8200:db25:2326:fa48:942c] has quit [Ping timeout: 258 seconds]
14:06 < luke-jr> gmaxwell: hmm, any relation to the networks?
14:12 < gmaxwell> luke-jr: these are the networks with 10 or more distinct hosts https://0bin.net/paste/WmG3qoFHHfOV2xoE#lzkxzcVyHrSvgi+yZjFvpoqocGNtWu6lDhhFOubsgGE  the first three each have many more than the others.
14:13 -!- fabianfabian [~fabianfab@94-209-115-52.cable.dynamic.v4.ziggo.nl] has joined #bitcoin-core-dev
14:13 < gmaxwell> beyond 'china' I'm not aware of anything that links these hosts.
14:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:15 < bitcoin-git> [bitcoin] jamesob opened pull request #15849: Thread names in logs and deadlock debug tools (master...2018-05-threadnames-take-2) https://github.com/bitcoin/bitcoin/pull/15849
14:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:15 < gmaxwell> Every network in that list is china, and thats also doubly intresting considering the historic near absence of bitcoin nodes in china.
14:17 < luke-jr> hrm
14:18 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Ping timeout: 250 seconds]
14:19 -!- darosior [~darosior@2a01:e35:2ff9:8200:db25:2326:fa48:942c] has joined #bitcoin-core-dev
14:19 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection]
14:20 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
14:20 < gmaxwell> so I think either something is causing chinese language users to use 0.16.1 or that there is some DOS attack or attack prep that happens to currently look like 0.16.1.
14:20 < gmaxwell> if it is confused users I still don't know why there are so many.
14:21 -!- CrystalNice [~CrystalNi@184.75.223.195] has joined #bitcoin-core-dev
14:21 < gmaxwell> in the past week-ish I've observed 1395 distinct chinese IPs syncing old blocks with 0.16.1.  And like ... 2 hosts that weren't chinese 0.16.1.
14:22 < gmaxwell> (and were syncing old blocks)
14:22 < gmaxwell> if nothing else it might make sense for you to make a versions page that split china and the rest of the world, so we could see if there was a chinese language specific issue with running old versions.
14:23 < midnightmagic> appliance maybe
14:24 < gmaxwell> possibly.
14:25 < luke-jr> gmaxwell: my methodology is incompatible with splitting by region, sadly
14:37 -!- darosior [~darosior@2a01:e35:2ff9:8200:db25:2326:fa48:942c] has quit [Remote host closed the connection]
14:38 -!- darosior [~darosior@2a01:e35:2ff9:8200:db25:2326:fa48:942c] has joined #bitcoin-core-dev
14:38 -!- darosior [~darosior@2a01:e35:2ff9:8200:db25:2326:fa48:942c] has quit [Client Quit]
14:38 -!- darosior [~darosior@2a01:e35:2ff9:8200:db25:2326:fa48:942c] has joined #bitcoin-core-dev
14:45 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-dev
15:29 -!- darosior [~darosior@2a01:e35:2ff9:8200:db25:2326:fa48:942c] has quit [Remote host closed the connection]
15:46 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 250 seconds]
15:51 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
15:51 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
15:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
15:51 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Excess Flood]
15:53 -!- fabianfabian [~fabianfab@94-209-115-52.cable.dynamic.v4.ziggo.nl] has quit [Quit: Textual IRC Client: www.textualapp.com]
15:54 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 244 seconds]
15:56 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
15:57 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
15:59 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Excess Flood]
16:02 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
16:04 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
16:06 -!- jarthur [~jarthur@207.114.244.5] has quit []
16:06 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
16:27 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
16:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
16:35 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Quit: .]
16:40 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
16:59 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 246 seconds]
17:00 -!- CrystalNice [~CrystalNi@184.75.223.195] has quit []
17:04 -!- Mister_X1 [~Mister_X@185.178.49.150] has joined #bitcoin-core-dev
17:12 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
17:14 -!- scoop [~scoop@207.237.81.122] has joined #bitcoin-core-dev
17:14 -!- scoop [~scoop@207.237.81.122] has quit [Remote host closed the connection]
17:28 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
17:29 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]
17:37 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
17:54 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 246 seconds]
17:58 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
18:02 < fanquake> Got some rc4 sigs up.
18:09 -!- scoop [~scoop@207.237.81.122] has joined #bitcoin-core-dev
18:09 < phantomcircuit> gmaxwell, sounds like a forkcoin that's got the same history upto some point
18:13 -!- scoop [~scoop@207.237.81.122] has quit [Ping timeout: 246 seconds]
18:14 -!- harding [~quassel@li1258-130.members.linode.com] has quit [Ping timeout: 244 seconds]
18:16 < gmaxwell> phantomcircuit: interesting, so I certantly have seen a bunch of those that claim to be a fork coin (superbitcoin)
18:16 < gmaxwell> that get themselves banned
18:16 -!- harding [~quassel@li1258-130.members.linode.com] has joined #bitcoin-core-dev
18:17 < echeveria> gmaxwell: can you connect back to any of them?
18:17 < gmaxwell> there is also some VDS which is apparently some ponzi scheme coin that airdropped to bitcoin users which is very popular in china.
18:20 < gmaxwell> echeveria: none of the last 12 that connected to me.
18:36 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
18:48 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
18:51 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
18:56 < echeveria> ike
18:56 < echeveria> blockfilterindex=1 on a synced node results in some impressive log spam 
18:57 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]
18:57 < echeveria> 2019-04-19T01:57:00Z Pre-allocating up to position 0x300000 in fltr00003.dat
18:57 < echeveria> 2019-04-19T01:57:01Z Pre-allocating up to position 0x400000 in fltr00003.dat
18:57 < echeveria> 2019-04-19T01:57:03Z Pre-allocating up to position 0x500000 in fltr00003.dat
18:57 < echeveria> 2019-04-19T01:57:04Z Pre-allocating up to position 0x600000 in fltr00003.dat
18:57 < echeveria> etc etc
18:58 < sipa> ha
18:58 < sipa> i think we should probably turn those off by default (incl. for block/undo)
18:59 -!- millerti [~millerti@cpe-66-24-91-119.stny.res.rr.com] has quit [Ping timeout: 268 seconds]
19:02 < echeveria> mm. my log is getting blasted.
19:05 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Remote host closed the connection]
19:07 -!- jimmysong [~jimmysong@65-36-83-142.static.grandenetworks.net] has joined #bitcoin-core-dev
19:12 < phantomcircuit> sipa, any idea if the pre-allocation still helps on ssds?
19:13 < phantomcircuit> (especially ones on top of a cow filesystem?)
19:15 < sipa> phantomcircuit: i doubt it tbh
19:15 < sipa> it'd be useful if we used mmap or so, but we don't
19:25 -!- scoop [~scoop@207.237.81.122] has joined #bitcoin-core-dev
19:26 < luke-jr> but it may save us from ugly out of disk space issues.. except on filesystems with compression :P
19:27 < luke-jr> actually, I wonder if posix_fallocate is broken on such filesystems - it's supposed to guarantee a write to the space won't fail
19:27 < luke-jr> or maybe they actually implement it such that it ensures it won't fail
19:31 < phantomcircuit> luke-jr, i doubt that it's gonna prevent an out of space issue
19:32 -!- harrymm [~harrymm@209.58.188.77] has quit [Ping timeout: 252 seconds]
19:49 -!- harrymm [~harrymm@209.58.188.77] has joined #bitcoin-core-dev
19:50 < echeveria> 2019-04-19T02:46:27Z basic block filter index is enabled at height 572248
19:50 < echeveria> 2019-04-19T02:46:27Z basic block filter index thread exit
19:50 < echeveria> 2019-04-19T02:48:49Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3114 seconds ago)
19:50 < echeveria> so about 45 minutes, as described on the PR, on a dual core i7 in a laptop. not bad. 
19:56 < echeveria> that's sort of a bug that it thinks the tip is stale when it isn't, but of no consequence. 
19:59 < echeveria> oh no there's just been no new blocks, I misunderstood what happened there.
20:00 -!- Mister_X1 [~Mister_X@185.178.49.150] has quit []
20:04 -!- ogelbukh [~ogelbukh@185.204.1.185] has joined #bitcoin-core-dev
20:07 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Ping timeout: 256 seconds]
20:11 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
20:32 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
20:35 -!- scoop [~scoop@207.237.81.122] has quit [Remote host closed the connection]
20:37 -!- scoop [~scoop@207.237.81.122] has joined #bitcoin-core-dev
20:40 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 245 seconds]
20:47 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Remote host closed the connection]
20:50 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev
20:51 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev
21:12 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Ping timeout: 246 seconds]
21:17 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
21:30 -!- ranefer [~ranefer@2601:281:c000:b92:cd6c:9c3a:c0e7:76e1] has joined #bitcoin-core-dev
21:44 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
21:46 -!- ranefer [~ranefer@2601:281:c000:b92:cd6c:9c3a:c0e7:76e1] has quit [Ping timeout: 240 seconds]
21:50 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
22:04 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
22:06 -!- scoop [~scoop@207.237.81.122] has quit [Remote host closed the connection]
22:09 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
22:11 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 250 seconds]
22:13 -!- face [~face@80.72.82.160.coresnet.bg] has joined #bitcoin-core-dev
22:37 -!- scoop [~scoop@207.237.81.122] has joined #bitcoin-core-dev
22:42 -!- scoop [~scoop@207.237.81.122] has quit [Ping timeout: 246 seconds]
22:45 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
23:00 -!- ogelbukh [~ogelbukh@185.204.1.185] has quit []
23:02 -!- face [~face@80.72.82.160.coresnet.bg] has quit [Ping timeout: 245 seconds]
23:09 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
23:17 -!- Ll1i1lL [~Ll1iiii1l@108-243-84-79.lightspeed.bcvloh.sbcglobal.net] has quit [Ping timeout: 246 seconds]
23:17 -!- Shabbypenguin [~Shabbypen@89.238.178.75] has joined #bitcoin-core-dev
23:19 -!- Ll1i1lL [~Ll1iiii1l@108-243-84-79.lightspeed.bcvloh.sbcglobal.net] has joined #bitcoin-core-dev
23:19 -!- jonatack [52661bc3@gateway/web/freenode/ip.82.102.27.195] has quit []
23:32 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
23:36 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
23:42 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 244 seconds]
23:50 -!- scoop [~scoop@207.237.81.122] has joined #bitcoin-core-dev
23:50 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has quit [Ping timeout: 255 seconds]
23:53 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
23:53 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Remote host closed the connection]
23:55 -!- scoop [~scoop@207.237.81.122] has quit [Ping timeout: 250 seconds]
--- Log closed Fri Apr 19 00:00:48 2019