12019-04-18T00:18:39  *** fanquake has quit IRC
  22019-04-18T00:50:15  *** millerti has quit IRC
  32019-04-18T00:54:29  *** Jackielove4u_ has joined #bitcoin-core-dev
  42019-04-18T00:55:10  *** Liliaceae_ has joined #bitcoin-core-dev
  52019-04-18T00:55:13  *** Varunram_ has joined #bitcoin-core-dev
  62019-04-18T00:55:31  *** michagogo_ has joined #bitcoin-core-dev
  72019-04-18T00:57:20  *** gmaxwell_ has joined #bitcoin-core-dev
  82019-04-18T00:57:30  *** commavir_ has joined #bitcoin-core-dev
  92019-04-18T00:57:33  *** omonk_ has joined #bitcoin-core-dev
 102019-04-18T00:57:33  *** windsok_ has joined #bitcoin-core-dev
 112019-04-18T01:00:57  *** jonasschnelli_ has joined #bitcoin-core-dev
 122019-04-18T01:02:40  *** Jackielove4u has quit IRC
 132019-04-18T01:02:40  *** omonk has quit IRC
 142019-04-18T01:02:40  *** Varunram has quit IRC
 152019-04-18T01:02:40  *** michagogo has quit IRC
 162019-04-18T01:02:40  *** Liliaceae has quit IRC
 172019-04-18T01:02:40  *** windsok has quit IRC
 182019-04-18T01:02:40  *** commavir has quit IRC
 192019-04-18T01:02:40  *** jonasschnelli has quit IRC
 202019-04-18T01:02:40  *** gmaxwell has quit IRC
 212019-04-18T01:02:44  *** commavir_ is now known as commavir
 222019-04-18T01:02:44  *** Jackielove4u_ is now known as Jackielove4u
 232019-04-18T01:02:44  *** Varunram_ is now known as Varunram
 242019-04-18T01:02:44  *** Liliaceae_ is now known as Liliaceae
 252019-04-18T01:07:33  <luke-jr> sometimes I wish software had an increment-only security-fix counter common across the rest of the version :x
 262019-04-18T01:07:53  <luke-jr> so one could know so long as the Nth digit is latest, it has all known security issues patched
 272019-04-18T01:12:36  *** Haeapw has joined #bitcoin-core-dev
 282019-04-18T01:13:39  *** pinheadmz has quit IRC
 292019-04-18T02:01:26  *** gmaxwell_ has quit IRC
 302019-04-18T02:01:26  *** gmaxwell_ has joined #bitcoin-core-dev
 312019-04-18T02:01:35  *** gmaxwell_ is now known as gmaxwell
 322019-04-18T02:15:55  *** pinheadmz has joined #bitcoin-core-dev
 332019-04-18T02:31:04  <echeveria> luke-jr: that doesn't really work so well where patches needed total rewrites, ie the utxo
 342019-04-18T02:31:51  <luke-jr> sure it does? if 99 has a bug, anything unaffected must be >=100
 352019-04-18T02:32:11  <luke-jr> then the advisory can just say "be sure you have version >= x.y.100
 362019-04-18T02:34:42  <kallewoof> that's a nice idea, but if version 2.1.3.99 has a vulnerability that none of the other versions have, then 2.1.2.99 is not affected even though its security counter < 100
 372019-04-18T02:35:33  <kallewoof> unless the authors just bump the version without changing anything every time security counter is bumped up, even for unaffected versions.
 382019-04-18T02:35:49  <kallewoof> s/bump the version/release same v with counter updated/
 392019-04-18T02:38:09  *** pinheadmz has quit IRC
 402019-04-18T02:47:05  *** scoop has quit IRC
 412019-04-18T02:59:16  *** pinheadmz has joined #bitcoin-core-dev
 422019-04-18T03:13:27  *** justanotheruser has joined #bitcoin-core-dev
 432019-04-18T03:16:01  *** pinheadmz has quit IRC
 442019-04-18T03:24:33  <luke-jr> kallewoof: yeah, but if that's the worst case scenario, it's still an improvement
 452019-04-18T03:25:34  <luke-jr> and using 2.1.3.100 instead of 2.1.2.99 is less of a problem with this, than if 2.1.3.100 might be vulnerable, but 2.1.2.99 isn't.
 462019-04-18T03:26:41  * kallewoof nods
 472019-04-18T03:38:50  *** karna has joined #bitcoin-core-dev
 482019-04-18T03:39:22  *** spinza has quit IRC
 492019-04-18T03:45:31  *** pinheadmz has joined #bitcoin-core-dev
 502019-04-18T03:52:00  *** Dean_Guss has joined #bitcoin-core-dev
 512019-04-18T03:59:30  *** spinza has joined #bitcoin-core-dev
 522019-04-18T04:01:21  *** pinheadmz has quit IRC
 532019-04-18T04:08:03  *** karna has quit IRC
 542019-04-18T04:17:04  *** dqx_ has joined #bitcoin-core-dev
 552019-04-18T04:22:03  *** dqx_ has joined #bitcoin-core-dev
 562019-04-18T04:40:03  *** belcher has quit IRC
 572019-04-18T05:19:03  *** dqx__ has joined #bitcoin-core-dev
 582019-04-18T05:22:10  *** dqx_ has quit IRC
 592019-04-18T05:31:25  *** pinheadmz has joined #bitcoin-core-dev
 602019-04-18T05:38:48  *** dqx__ has quit IRC
 612019-04-18T06:02:30  *** pinheadmz has quit IRC
 622019-04-18T06:04:05  *** jonasschnelli_ has quit IRC
 632019-04-18T06:04:05  *** jonasschnelli_ has joined #bitcoin-core-dev
 642019-04-18T06:04:40  *** jnewbery has quit IRC
 652019-04-18T06:04:54  *** jnewbery has joined #bitcoin-core-dev
 662019-04-18T06:16:27  *** hebasto has joined #bitcoin-core-dev
 672019-04-18T06:40:24  *** EagleTM has joined #bitcoin-core-dev
 682019-04-18T07:25:57  *** harding has quit IRC
 692019-04-18T07:34:21  *** harding has joined #bitcoin-core-dev
 702019-04-18T07:43:57  *** Ll1i1lL has quit IRC
 712019-04-18T07:49:42  *** murrayn_ has quit IRC
 722019-04-18T07:50:03  *** murrayn has joined #bitcoin-core-dev
 732019-04-18T08:34:57  *** Ll1i1lL has joined #bitcoin-core-dev
 742019-04-18T08:40:18  *** Ll1i1lL has quit IRC
 752019-04-18T08:51:43  *** setpill has joined #bitcoin-core-dev
 762019-04-18T09:02:06  *** dqx has quit IRC
 772019-04-18T09:02:47  *** dqx has joined #bitcoin-core-dev
 782019-04-18T09:11:20  *** darosior has joined #bitcoin-core-dev
 792019-04-18T09:14:08  *** Plush has joined #bitcoin-core-dev
 802019-04-18T09:14:38  *** zorrologo has joined #bitcoin-core-dev
 812019-04-18T09:17:18  *** belcher has joined #bitcoin-core-dev
 822019-04-18T09:21:36  *** timothy has joined #bitcoin-core-dev
 832019-04-18T09:27:50  *** IRC-Source_65 has joined #bitcoin-core-dev
 842019-04-18T09:28:10  *** IRC-Source_65 has quit IRC
 852019-04-18T09:34:51  *** profmac has quit IRC
 862019-04-18T09:37:30  *** fanquake has joined #bitcoin-core-dev
 872019-04-18T09:39:37  *** Ll1i1lL has joined #bitcoin-core-dev
 882019-04-18T09:47:46  *** profmac has joined #bitcoin-core-dev
 892019-04-18T09:48:56  *** hebasto has quit IRC
 902019-04-18T10:02:30  *** midnightmagic has joined #bitcoin-core-dev
 912019-04-18T10:22:06  *** spinza has quit IRC
 922019-04-18T10:30:36  *** spinza has joined #bitcoin-core-dev
 932019-04-18T10:38:04  *** dqx_ has joined #bitcoin-core-dev
 942019-04-18T10:47:37  *** AaronvanW has joined #bitcoin-core-dev
 952019-04-18T10:54:36  *** goatpig_ has joined #bitcoin-core-dev
 962019-04-18T10:54:52  *** goatpig_ has left #bitcoin-core-dev
 972019-04-18T10:55:27  *** goatpig has joined #bitcoin-core-dev
 982019-04-18T10:55:45  *** Aaronvan_ has joined #bitcoin-core-dev
 992019-04-18T10:57:00  *** AaronvanW has quit IRC
1002019-04-18T11:12:11  *** strattog has joined #bitcoin-core-dev
1012019-04-18T11:13:23  *** strattog has quit IRC
1022019-04-18T11:22:49  *** T-Junk has joined #bitcoin-core-dev
1032019-04-18T11:29:01  *** Claveprivada has joined #bitcoin-core-dev
1042019-04-18T11:35:46  *** darosior has quit IRC
1052019-04-18T11:41:18  *** spaced0ut has quit IRC
1062019-04-18T11:51:55  *** Guyver2 has joined #bitcoin-core-dev
1072019-04-18T12:00:02  *** T-Junk has quit IRC
1082019-04-18T12:02:01  *** belcher has quit IRC
1092019-04-18T12:14:49  *** Claveprivada has quit IRC
1102019-04-18T12:20:48  *** rafalcpp has quit IRC
1112019-04-18T12:22:34  *** rafalcpp has joined #bitcoin-core-dev
1122019-04-18T12:22:48  *** jonatack has joined #bitcoin-core-dev
1132019-04-18T12:31:58  *** bitcoin-git has joined #bitcoin-core-dev
1142019-04-18T12:31:58  <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
1152019-04-18T12:32:00  *** bitcoin-git has left #bitcoin-core-dev
1162019-04-18T12:32:11  *** belcher has joined #bitcoin-core-dev
1172019-04-18T12:41:02  *** scoop has joined #bitcoin-core-dev
1182019-04-18T12:46:10  *** spaced0ut has joined #bitcoin-core-dev
1192019-04-18T12:50:39  *** scoop_ has joined #bitcoin-core-dev
1202019-04-18T12:52:55  *** whartung1 has joined #bitcoin-core-dev
1212019-04-18T12:54:13  *** scoop has quit IRC
1222019-04-18T12:59:22  *** jonatack has quit IRC
1232019-04-18T13:10:31  *** hebasto has joined #bitcoin-core-dev
1242019-04-18T13:17:18  *** side^effects has joined #bitcoin-core-dev
1252019-04-18T13:36:25  *** scoop_ has quit IRC
1262019-04-18T13:38:02  *** scoop has joined #bitcoin-core-dev
1272019-04-18T13:38:02  *** scoop has quit IRC
1282019-04-18T13:38:10  *** scoop has joined #bitcoin-core-dev
1292019-04-18T13:45:52  *** darosior has joined #bitcoin-core-dev
1302019-04-18T13:49:32  *** bitcoin-git has joined #bitcoin-core-dev
1312019-04-18T13:49:32  <bitcoin-git> [bitcoin] MarcoFalke pushed 13 commits to master: https://github.com/bitcoin/bitcoin/compare/dae72998e857...e4beef611a42
1322019-04-18T13:49:32  <bitcoin-git> bitcoin/master 4368384 Jim Posen: index: Allow atomic commits of index state to be extended.
1332019-04-18T13:49:33  <bitcoin-git> bitcoin/master 62b7a4f Jim Posen: index: Ensure block locator is not stale after chain reorg.
1342019-04-18T13:49:34  <bitcoin-git> bitcoin/master ba6ff9a Jim Posen: blockfilter: Functions to translate filter types to/from names.
1352019-04-18T13:49:37  *** bitcoin-git has left #bitcoin-core-dev
1362019-04-18T13:49:53  *** bitcoin-git has joined #bitcoin-core-dev
1372019-04-18T13:49:53  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #14121: Index for BIP 157 block filters (master...bip157-index) https://github.com/bitcoin/bitcoin/pull/14121
1382019-04-18T13:49:55  *** bitcoin-git has left #bitcoin-core-dev
1392019-04-18T13:56:46  <jnewbery> \o/
1402019-04-18T14:14:00  *** pinheadmz has joined #bitcoin-core-dev
1412019-04-18T14:14:05  <echeveria> seems that broke the tests
1422019-04-18T14:16:48  <MarcoFalke> yeah, it compiled back when I tested it, but now the test header file has been moved to setup_common.h
1432019-04-18T14:17:00  <MarcoFalke> echeveria: Mind to fix it?
1442019-04-18T14:17:38  <MarcoFalke> yay, silent merge conflicts
1452019-04-18T14:27:04  *** bitcoin-git has joined #bitcoin-core-dev
1462019-04-18T14:27:05  <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
1472019-04-18T14:27:06  *** bitcoin-git has left #bitcoin-core-dev
1482019-04-18T14:29:08  *** scoop has quit IRC
1492019-04-18T14:29:35  *** scoop has joined #bitcoin-core-dev
1502019-04-18T14:33:08  *** scoop has quit IRC
1512019-04-18T14:33:21  *** scoop has joined #bitcoin-core-dev
1522019-04-18T14:39:30  *** bitcoin-git has joined #bitcoin-core-dev
1532019-04-18T14:39:30  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e4beef611a42...693c743a32e4
1542019-04-18T14:39:31  <bitcoin-git> bitcoin/master 89e8df1 James O'Beirne: tests: fix outdate include in blockfilter_index_tests
1552019-04-18T14:39:31  <bitcoin-git> bitcoin/master 693c743 MarcoFalke: Merge #15843: tests: fix outdated include in blockfilter_index_tests
1562019-04-18T14:39:33  *** bitcoin-git has left #bitcoin-core-dev
1572019-04-18T14:40:19  *** bitcoin-git has joined #bitcoin-core-dev
1582019-04-18T14:40:20  <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
1592019-04-18T14:40:24  *** bitcoin-git has left #bitcoin-core-dev
1602019-04-18T14:46:05  *** scoop has quit IRC
1612019-04-18T14:47:24  *** jb55 has joined #bitcoin-core-dev
1622019-04-18T14:48:00  *** scoop has joined #bitcoin-core-dev
1632019-04-18T14:54:59  *** scoop has quit IRC
1642019-04-18T14:55:08  *** scoop has joined #bitcoin-core-dev
1652019-04-18T15:00:02  *** whartung1 has quit IRC
1662019-04-18T15:00:04  *** _Sam-- has joined #bitcoin-core-dev
1672019-04-18T15:04:48  *** matael1 has joined #bitcoin-core-dev
1682019-04-18T15:12:18  *** dqx_ has quit IRC
1692019-04-18T15:13:27  *** jonatack has joined #bitcoin-core-dev
1702019-04-18T15:20:56  *** scoop has quit IRC
1712019-04-18T15:23:52  *** morcos_ has joined #bitcoin-core-dev
1722019-04-18T15:26:44  *** setpill has quit IRC
1732019-04-18T15:27:25  *** morcos has quit IRC
1742019-04-18T15:27:26  *** morcos_ is now known as morcos
1752019-04-18T15:31:17  *** pinheadmz has quit IRC
1762019-04-18T15:34:28  *** scoop has joined #bitcoin-core-dev
1772019-04-18T15:35:00  *** bitcoin-git has joined #bitcoin-core-dev
1782019-04-18T15:35:00  <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
1792019-04-18T15:35:01  *** bitcoin-git has left #bitcoin-core-dev
1802019-04-18T15:35:15  *** bitcoin-git has joined #bitcoin-core-dev
1812019-04-18T15:35:15  <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
1822019-04-18T15:35:16  *** bitcoin-git has left #bitcoin-core-dev
1832019-04-18T15:35:56  <MarcoFalke> PSA: GitHub delivered a corrupt branch for one pull request #15778
1842019-04-18T15:35:57  <gribble> https://github.com/bitcoin/bitcoin/issues/15778 | [wallet] Move maxtxfee from node to wallet by jnewbery · Pull Request #15778 · bitcoin/bitcoin · GitHub
1852019-04-18T15:44:19  *** dqx_ has joined #bitcoin-core-dev
1862019-04-18T15:45:43  *** dqx_ has quit IRC
1872019-04-18T15:46:14  *** bitcoin-git has joined #bitcoin-core-dev
1882019-04-18T15:46:16  <bitcoin-git> [bitcoin] laanwj pushed 7 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/e57462c6ba60...e753cbd64507
1892019-04-18T15:46:17  <bitcoin-git> bitcoin/0.18 8f7cfb0 James O'Beirne: gitignore: add *.dat
1902019-04-18T15:46:18  <bitcoin-git> bitcoin/0.18 c69138a James O'Beirne: gitignore: add *.plist (clang-check)
1912019-04-18T15:46:19  <bitcoin-git> bitcoin/0.18 9c572e3 Jack Mallers: doc: mention creating application support bitcoin folder on OSX
1922019-04-18T15:46:21  *** bitcoin-git has left #bitcoin-core-dev
1932019-04-18T15:46:39  *** bitcoin-git has joined #bitcoin-core-dev
1942019-04-18T15:46:39  <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
1952019-04-18T15:46:43  *** bitcoin-git has left #bitcoin-core-dev
1962019-04-18T15:47:14  *** bitcoin-git has joined #bitcoin-core-dev
1972019-04-18T15:47:15  <bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/693c743a32e4...f5aaeae0cdfc
1982019-04-18T15:47:16  <bitcoin-git> bitcoin/master 4ddeb2f Luke Dashjr: GUI: Options: Set the range of pruning size before loading its value
1992019-04-18T15:47:17  <bitcoin-git> bitcoin/master 8a33f4d Luke Dashjr: GUI: Options: Remove the upper-bound limit from pruning size setting
2002019-04-18T15:47:18  <bitcoin-git> bitcoin/master f5aaeae Wladimir J. van der Laan: Merge #15801: Bugfix: GUI: Options: Initialise prune setting range before ...
2012019-04-18T15:47:19  *** bitcoin-git has left #bitcoin-core-dev
2022019-04-18T15:47:37  *** bitcoin-git has joined #bitcoin-core-dev
2032019-04-18T15:47:38  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/e753cbd64507...a58d80d1b261
2042019-04-18T15:47:38  <bitcoin-git> bitcoin/0.18 5546207 Luke Dashjr: GUI: Options: Set the range of pruning size before loading its value
2052019-04-18T15:47:39  <bitcoin-git> bitcoin/0.18 a58d80d Luke Dashjr: GUI: Options: Remove the upper-bound limit from pruning size setting
2062019-04-18T15:47:41  *** bitcoin-git has left #bitcoin-core-dev
2072019-04-18T15:48:08  *** bitcoin-git has joined #bitcoin-core-dev
2082019-04-18T15:48:08  <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
2092019-04-18T15:48:09  *** bitcoin-git has left #bitcoin-core-dev
2102019-04-18T15:51:27  *** millerti has joined #bitcoin-core-dev
2112019-04-18T15:53:41  *** scoop has quit IRC
2122019-04-18T15:54:21  *** gggggggggggg has quit IRC
2132019-04-18T15:56:40  <MarcoFalke> john has force pushed  #15778, and the branch is no longer corrupted. Though, something to keep in mind when blindly fetching from GitHub.
2142019-04-18T15:56:43  <gribble> https://github.com/bitcoin/bitcoin/issues/15778 | [wallet] Move maxtxfee from node to wallet by jnewbery · Pull Request #15778 · bitcoin/bitcoin · GitHub
2152019-04-18T16:06:12  <wumpus> MarcoFalke: it's an argument, I think, to encourage signing of the top commit in PRs as well
2162019-04-18T16:07:34  <wumpus> at least corruption by github will then always be detected
2172019-04-18T16:07:48  <MarcoFalke> Agree
2182019-04-18T16:08:32  <MarcoFalke> They could still serve an outdated branch (what happened in this case), but signing is strictly better
2192019-04-18T16:09:32  *** ezzzy has joined #bitcoin-core-dev
2202019-04-18T16:10:08  <MarcoFalke> Even a dummy key without a passphrase would be sufficient.
2212019-04-18T16:10:55  <MarcoFalke> A one-line wrapper script can be gpg --homedir="/path/to/dummy_key/gpg_dir/"
2222019-04-18T16:11:23  <MarcoFalke> And then set git config gpg.program $THE_WRAPPER_SCRIPT
2232019-04-18T16:12:16  <MarcoFalke> And then call git commit --gpg-sign=$THE_KEY_ID (or create another wrapper for that)
2242019-04-18T16:15:45  *** tarboss has joined #bitcoin-core-dev
2252019-04-18T16:16:12  *** tarboss has left #bitcoin-core-dev
2262019-04-18T16:19:19  *** ezzzy has quit IRC
2272019-04-18T16:26:36  *** spinza has quit IRC
2282019-04-18T16:30:19  *** Dean_Guss has quit IRC
2292019-04-18T16:32:15  *** spinza has joined #bitcoin-core-dev
2302019-04-18T16:36:09  *** jarthur has joined #bitcoin-core-dev
2312019-04-18T17:09:27  *** Aaronvan_ is now known as AaronvanW
2322019-04-18T17:12:28  *** darosior has quit IRC
2332019-04-18T17:19:02  *** omonk_ has quit IRC
2342019-04-18T17:23:39  *** jarthur has quit IRC
2352019-04-18T17:23:46  *** omonk has joined #bitcoin-core-dev
2362019-04-18T17:24:16  *** jarthur has joined #bitcoin-core-dev
2372019-04-18T17:33:42  *** pinheadmz has joined #bitcoin-core-dev
2382019-04-18T17:46:12  *** bitcoin-git has joined #bitcoin-core-dev
2392019-04-18T17:46:12  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f5aaeae0cdfc...6ce77a3668b9
2402019-04-18T17:46:13  <bitcoin-git> bitcoin/master 2d8ba4f r8921039: remove out-of-date comment on pay-to-witness support
2412019-04-18T17:46:13  <bitcoin-git> bitcoin/master 6ce77a3 Wladimir J. van der Laan: Merge #15833: [doc] remove out-of-date comment on pay-to-witness support
2422019-04-18T17:46:25  *** bitcoin-git has left #bitcoin-core-dev
2432019-04-18T17:47:00  *** bitcoin-git has joined #bitcoin-core-dev
2442019-04-18T17:47:01  <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
2452019-04-18T17:47:02  *** bitcoin-git has left #bitcoin-core-dev
2462019-04-18T17:48:38  *** bitcoin-git has joined #bitcoin-core-dev
2472019-04-18T17:48:38  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6ce77a3668b9...84adc79e105c
2482019-04-18T17:48:39  <bitcoin-git> bitcoin/master 81b2830 Tobias Kaderle: qt: update request payment button text and tab description
2492019-04-18T17:48:39  <bitcoin-git> bitcoin/master 84adc79 Wladimir J. van der Laan: Merge #15829: qt: update request payment button text and tab description
2502019-04-18T17:48:42  *** bitcoin-git has left #bitcoin-core-dev
2512019-04-18T17:49:25  *** bitcoin-git has joined #bitcoin-core-dev
2522019-04-18T17:49:26  <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
2532019-04-18T17:49:29  *** bitcoin-git has left #bitcoin-core-dev
2542019-04-18T17:53:40  *** bitcoin-git has joined #bitcoin-core-dev
2552019-04-18T17:53:41  <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
2562019-04-18T17:53:42  *** bitcoin-git has left #bitcoin-core-dev
2572019-04-18T17:54:58  *** bitcoin-git has joined #bitcoin-core-dev
2582019-04-18T17:54:58  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/84adc79e105c...2d4f70cabd6d
2592019-04-18T17:54:58  <bitcoin-git> bitcoin/master 942ff20 nkostoulas: contrib: gh-merge: Use pagination to fetch all review comments
2602019-04-18T17:54:59  <bitcoin-git> bitcoin/master 2d4f70c Wladimir J. van der Laan: Merge #15838: scripts and tools: Fetch missing review comments in github-m...
2612019-04-18T17:55:00  *** bitcoin-git has left #bitcoin-core-dev
2622019-04-18T17:55:47  *** bitcoin-git has joined #bitcoin-core-dev
2632019-04-18T17:55:47  <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
2642019-04-18T17:55:48  *** bitcoin-git has left #bitcoin-core-dev
2652019-04-18T18:00:02  *** matael1 has quit IRC
2662019-04-18T18:04:31  *** darosior has joined #bitcoin-core-dev
2672019-04-18T18:05:37  *** Jayflux has joined #bitcoin-core-dev
2682019-04-18T18:23:27  *** face has quit IRC
2692019-04-18T18:32:08  *** justanotheruser has quit IRC
2702019-04-18T18:36:30  *** abbitcryptic has joined #bitcoin-core-dev
2712019-04-18T18:41:02  *** bitcoin-git has joined #bitcoin-core-dev
2722019-04-18T18:41:02  <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
2732019-04-18T18:41:15  *** bitcoin-git has left #bitcoin-core-dev
2742019-04-18T18:44:30  *** abbitcryptic has quit IRC
2752019-04-18T18:54:35  *** Aaronvan_ has joined #bitcoin-core-dev
2762019-04-18T18:57:56  *** AaronvanW has quit IRC
2772019-04-18T19:00:04  <wumpus> #startmeeting
2782019-04-18T19:00:04  <lightningbot> Meeting started Thu Apr 18 19:00:04 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2792019-04-18T19:00:04  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2802019-04-18T19:00:14  <jnewbery> hi
2812019-04-18T19:00:17  <kanzure> hi
2822019-04-18T19:00:28  <sipa> hi
2832019-04-18T19:00:33  <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
2842019-04-18T19:00:42  <achow101> hi
2852019-04-18T19:00:46  <jonasschnelli_> hi
2862019-04-18T19:00:53  <jamesob> hi
2872019-04-18T19:00:55  <meshcollider> hi
2882019-04-18T19:00:56  <MarcoFalke> when rc4?
2892019-04-18T19:01:07  <wumpus> #topic 0.18.0rc4
2902019-04-18T19:01:21  <jonasschnelli_> I guess #15839 is holding it back
2912019-04-18T19:01:23  <gribble> https://github.com/bitcoin/bitcoin/issues/15839 | [0.18] Revert GetData randomization change (#14897) by sdaftuar · Pull Request #15839 · bitcoin/bitcoin · GitHub
2922019-04-18T19:01:28  *** jonasschnelli_ is now known as jonasschnelli
2932019-04-18T19:01:30  <MarcoFalke> Needs merge
2942019-04-18T19:01:42  <wumpus> that seems to be the only one left?
2952019-04-18T19:01:54  <MarcoFalke> yeah, after that I think we are good to tag rc4
2962019-04-18T19:01:59  <wumpus> good to know
2972019-04-18T19:02:09  <gmaxwell> oh I thought the revert was merged already.
2982019-04-18T19:02:38  <wumpus> ok, let's merge that one and tag rc4 after the meeting
2992019-04-18T19:02:43  <sipa> ack
3002019-04-18T19:02:46  <jonasschnelli> ack
3012019-04-18T19:02:50  <MarcoFalke> #action merge 15839 and tag rc4
3022019-04-18T19:03:27  <wumpus> #topic High priority for review
3032019-04-18T19:03:39  <wumpus> https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+project%3Abitcoin%2Fbitcoin%2F8  6 PRs on there right now
3042019-04-18T19:04:33  <wumpus> anything to add/remove? I guess everyone does this outside of the meetings nowadays
3052019-04-18T19:04:48  <sipa> can i have 15427?
3062019-04-18T19:04:59  <sipa> #15427
3072019-04-18T19:05:01  <gribble> https://github.com/bitcoin/bitcoin/issues/15427 | Add support for descriptors to utxoupdatepsbt by sipa · Pull Request #15427 · bitcoin/bitcoin · GitHub
3082019-04-18T19:05:02  <MarcoFalke> can I have #15758?
3092019-04-18T19:05:04  <gribble> https://github.com/bitcoin/bitcoin/issues/15758 | qa: Add further tests to wallet_balance by MarcoFalke · Pull Request #15758 · bitcoin/bitcoin · GitHub
3102019-04-18T19:05: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
3112019-04-18T19:05:41  <jnewbery> gwillen asked for #15024 to go in after the last wallet meeting
3122019-04-18T19:05:43  <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
3132019-04-18T19:06:07  <gwillen> jnewbery: thanks, I was just trying to find that but I'm on an airplane with bad wifi
3142019-04-18T19:06:21  <wumpus> sipa MarcoFalke added
3152019-04-18T19:06:27  <MarcoFalke> thx
3162019-04-18T19:06:40  <sipa> thanks
3172019-04-18T19:07:03  <wumpus> also added
3182019-04-18T19:07:12  <gwillen> +1 thanks!
3192019-04-18T19:07:30  <wumpus> looks like both achow101 and sdaftuar have two PRs on the list now :o
3202019-04-18T19:07:45  <achow101> oops
3212019-04-18T19:08:05  <jonasschnelli> sdaftuar will resolve now
3222019-04-18T19:08:14  <wumpus> can/should we make a choice what to keep on there?
3232019-04-18T19:08:16  <MarcoFalke> If they were suggested by different people, it should be fine
3242019-04-18T19:08:17  <sipa> i propose a trial by combat to determine whose PRs remain
3252019-04-18T19:08:33  *** pinheadmz has left #bitcoin-core-dev
3262019-04-18T19:08:34  <MarcoFalke> Everyone can suggest one pr (it doesn't have to be their own)
3272019-04-18T19:08:39  <instagibbs> is your PR heavier than a duck
3282019-04-18T19:08:40  <wumpus> sipa:everyone gets to have one PR
3292019-04-18T19:08:47  *** pinheadmz has joined #bitcoin-core-dev
3302019-04-18T19:08:51  <wumpus> MarcoFalke: hmm
3312019-04-18T19:08:57  <achow101> instagibbs: how many lines of code does a duck weigh?
3322019-04-18T19:08:59  <gmaxwell> Yes, but based on who proposed.
3332019-04-18T19:08:59  <jonasschnelli> MarcoFalke: that really hard to keep the overview
3342019-04-18T19:09:03  <gmaxwell> not who authored.
3352019-04-18T19:09:07  <wumpus> I don't really care but it's kind of getting out of hand
3362019-04-18T19:09:12  <gmaxwell> (or that was my understanding)
3372019-04-18T19:09:13  <MarcoFalke> but I agree that achow101 and sdaftuar should pick one pull that stays
3382019-04-18T19:09:16  <wumpus> jonasschnelli: yeah, exactly
3392019-04-18T19:09:23  <jonasschnelli> How do we keep track who proposed?
3402019-04-18T19:09:24  <wumpus> github doesn't track this
3412019-04-18T19:09:43  <MarcoFalke> remove NOTFOUND for sdaftuar
3422019-04-18T19:09:44  <achow101> let's remove #15741 for now. it needs to be rebased anyways
3432019-04-18T19:09:46  <wumpus> so are all 9 things on the list proposed by different people?
3442019-04-18T19:09:46  <gribble> https://github.com/bitcoin/bitcoin/issues/15741 | Batch write imported stuff in importmulti by achow101 · Pull Request #15741 · bitcoin/bitcoin · GitHub
3452019-04-18T19:09:56  <wumpus> ok
3462019-04-18T19:10:29  <wumpus> thank you, done
3472019-04-18T19:10:30  <gmaxwell> In the future we can use some greppable line in IRC to record requests.
3482019-04-18T19:10:56  <wumpus> 7 PRs on the list now, that's just about managebale
3492019-04-18T19:11:03  <wumpus> any other topics?
3502019-04-18T19:11:10  <moneyball> there are 4
3512019-04-18T19:11:14  <MarcoFalke> moneyball: has a bunch
3522019-04-18T19:11:16  <moneyball> https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a
3532019-04-18T19:11:24  <jonasschnelli> We could also add a project column per non-author-proposer
3542019-04-18T19:11:36  <jonasschnelli> I don't expect we would have a lot
3552019-04-18T19:11:44  <wumpus> moneyball: thanks
3562019-04-18T19:12:09  <wumpus> #topic Should send-to-non-v0-witness be standard (sipa)
3572019-04-18T19:12:15  <sipa> hi
3582019-04-18T19:12:28  <sipa> so we currently have two policy rules w.r.t. future segwit versions
3592019-04-18T19:12:51  <sipa> one is an IsStandard one that makes sending _to_ a native segwit (bech32) future witness version nonstandard
3602019-04-18T19:12:52  <wumpus> jonasschnelli: it's unfortunate that it's not possible to add extra info to the 'cards'
3612019-04-18T19:13:07  <sipa> the other is a script rule that makes spending any future witness version (incl. p2sh) nonstandard
3622019-04-18T19:13:35  <sipa> i believe that first rule does more harm than good
3632019-04-18T19:14:05  <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.
3642019-04-18T19:14:09  <meshcollider> I'm inclined to agree
3652019-04-18T19:14:18  <gmaxwell> I agree the first rule does more harm than good.
3662019-04-18T19:14:20  <sipa> i suspect the reason is protecting users, but once the address is already created by the receiver it's already too late
3672019-04-18T19:14:27  *** darosior has quit IRC
3682019-04-18T19:14:34  <sipa> so if we want that rule, i believe it belongs in the wallet, not in relay policy
3692019-04-18T19:14:36  <MarcoFalke> No wallet should create thos addresses
3702019-04-18T19:14:47  <luke-jr> (getting stuck is a problem because it locks up your change)
3712019-04-18T19:14:57  <gmaxwell> To the extent that it provides some real protection, it's mostly a protection against premature activation in wallets.
3722019-04-18T19:15:09  <sdaftuar> sipa: are you suggesting it should be wallet rule to not send to those addresses?
3732019-04-18T19:15:25  <sipa> sdaftuar: i'm not sure about that; but it shouldn't be more than just wallet
3742019-04-18T19:15:30  <gmaxwell> ugh.
3752019-04-18T19:15:48  <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
3762019-04-18T19:15:57  <jnewbery> Currently wallet will send to non-v0 segwit addresses, and mempool won't accept that transaction
3772019-04-18T19:16:06  <wumpus> I tend to agree, this selfs a self-sabotaging relay policy
3782019-04-18T19:16:21  <sipa> sdaftuar: my point is, trying to guess the reason for this rule, if the rule is desirable, it should be in the wallet :)
3792019-04-18T19:16:22  <jnewbery> I think we should have the opposite. Wallet shouldn't send to non-v0 segwit addresses, but mempool should accept and relay
3802019-04-18T19:16:26  <luke-jr> tangent: if relay policy allows it, maybe it should always allow RBF on it?
3812019-04-18T19:16:50  <sipa> jnewbery: note that it also doesn't work for p2sh embedded segwit, so it's a weak protection at best
3822019-04-18T19:16:52  <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
3832019-04-18T19:16:53  <gmaxwell> jnewbery: Or better, not restict it at all. Refusing to send to it harms forward compatiblity.
3842019-04-18T19:16:57  <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?
3852019-04-18T19:17:17  <sipa> luke-jr: yup
3862019-04-18T19:17:18  <wumpus> forward compatibility is kind of useful
3872019-04-18T19:17:22  <meshcollider> Exactly...
3882019-04-18T19:17:23  <gmaxwell> and then we end back up with multiple years delay in deploying new functionality, which was what the versions were intended to address.
3892019-04-18T19:17:49  <sipa> yeah, i think my preference is not having the rule in the first place
3902019-04-18T19:17:50  <luke-jr> IMO allow relay and wallet, but force RBF opt-in ;)
3912019-04-18T19:17:59  <jnewbery> delay in bech32 adoption is not caused by Bitcoin Core not supporting bech32 in pre v0.15
3922019-04-18T19:18:05  <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.
3932019-04-18T19:18:06  <meshcollider> So I also dont think the wallet should refuse to send either, a warning at most
3942019-04-18T19:18:08  <jnewbery> it's caused by other wallets and exchanges in the ecosystem
3952019-04-18T19:18:15  <gmaxwell> We also, for example, don't prevent people from sending to 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T
3962019-04-18T19:18:23  <luke-jr> jnewbery: what we do in Core's wallet should be the same as what other wallets ought to do
3972019-04-18T19:18:30  <sdaftuar> luke-jr: +1
3982019-04-18T19:18:43  <jnewbery> which is not send to non-v0 until there is a defined v1
3992019-04-18T19:18:56  <wumpus> a warning would be okey
4002019-04-18T19:18:57  <achow101> the fact that it's not a relay policy will lock up change
4012019-04-18T19:18:58  <gmaxwell> We certantly cannot argue that varrious parties are not doing the right thing if we won't do that thing ourselves
4022019-04-18T19:19:05  <wumpus> but I think we agree, this should not be relay policy
4032019-04-18T19:19:17  <sipa> i'll PR removing it from relay policy
4042019-04-18T19:19:21  <wumpus> relay policy has never been used to protect users, if so, why no excessive fee check?
4052019-04-18T19:19:31  <sipa> wumpus: exactly
4062019-04-18T19:19:31  <jonasschnelli> indeed
4072019-04-18T19:19:32  <gmaxwell> wumpus: kinda one sec on that point.
4082019-04-18T19:19:33  <instagibbs> sipa, it's worth a mailing list email?
4092019-04-18T19:19:35  <jnewbery> I'm not saying we should never send to v1. Clearly we should change wallet policy when the node includes support for v1
4102019-04-18T19:19:55  <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.
4112019-04-18T19:19:58  <jonasschnelli> instagibbs: seems to be Core policy,... no need for ML?!
4122019-04-18T19:20:01  <luke-jr> jnewbery: but then we could just as well make a new address format for every version
4132019-04-18T19:20:05  <gmaxwell> wumpus: but for _output types_ this doesn't apply.
4142019-04-18T19:20:11  <wumpus> gmaxwell:right
4152019-04-18T19:20:11  <cfields> replace-by-version? :p
4162019-04-18T19:20:23  <MarcoFalke> jnewbery: Wallet support to generate v1 addresses can always wait after the fork activated
4172019-04-18T19:20:26  <luke-jr> jonasschnelli: it seems likely a topic other software would want to consider and act on too
4182019-04-18T19:20:27  <sipa> actually
4192019-04-18T19:20:28  <instagibbs> jonasschnelli, people may have made assumptions based on current policy, right or wrong?
4202019-04-18T19:20:32  <jnewbery> luke-jr: that' not the same at all. This is a one-line (or config) or config
4212019-04-18T19:20:35  <gmaxwell> jnewbery: and then we will end up with multiple year delays after activation before v1 can be used by wallets.
4222019-04-18T19:20:38  <sipa> this is a violation of BIP173
4232019-04-18T19:20:45  <gmaxwell> sipa: correct.
4242019-04-18T19:20:47  <sipa> "Version 0 witness addresses are always 42 or 62 characters, but implementations MUST allow the use of any version. "
4252019-04-18T19:20:47  <jonasschnelli> oh
4262019-04-18T19:21:02  <wumpus> it makes sense to inform people on the ML
4272019-04-18T19:21:08  <jonasschnelli> so we need to change BIPS.md :p
4282019-04-18T19:21:15  <gmaxwell> The intentional and widely discussed design of BIP173 was to enable seemless use of future versions.
4292019-04-18T19:21:41  <wumpus> it doesn't need to be *discussed* there, IMO, but mentioning it so there is awareness is good
4302019-04-18T19:21:48  <luke-jr> considering BIP173, it's arguably a bug to fix in backports even ;)
4312019-04-18T19:21:48  <sipa> i believe this code actually predates bip173
4322019-04-18T19:21:58  <gmaxwell> sipa: it does.
4332019-04-18T19:21:59  <wumpus> heh
4342019-04-18T19:22:01  <achow101> so is the change to allow sending to non-v0 but not relay transactions with non-v0 outputs?
4352019-04-18T19:22:10  <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
4362019-04-18T19:22:11  <luke-jr> achow101: inputs*?
4372019-04-18T19:22:35  <sipa> achow101: i'd just drop the rule entirely
4382019-04-18T19:22:47  <luke-jr> MarcoFalke: I'd even wait at least >=100 blocks after , but that's another discussion
4392019-04-18T19:22:50  <gmaxwell> We need to not relay v1+ _spends_ in order to protect the activation of future v1+ rules.  Outputs are fine.
4402019-04-18T19:22:53  <sipa> maybe we want to independently add a warning in the GUI
4412019-04-18T19:23:03  <MarcoFalke> achow101: outputs would be relayed, but spending from them would be non-standard
4422019-04-18T19:23:05  <luke-jr> sipa: policy should prevent spending v1 UTXOs
4432019-04-18T19:23:13  <sipa> luke-jr: it already does
4442019-04-18T19:23:14  <achow101> ah, I see
4452019-04-18T19:23:16  <luke-jr> sipa: nah, because of P2Sh stuff
4462019-04-18T19:23:34  <luke-jr> sipa: yes, but it sounded like you might be talking about dropping it too
4472019-04-18T19:23:36  <sipa> luke-jr: even P2SH-embedded v1 segwit output spends will not be relayed
4482019-04-18T19:23:48  <sipa> ah no, i'm only talking about the sending to part
4492019-04-18T19:23:52  <luke-jr> k
4502019-04-18T19:23:57  <sipa> (which is implemented completely independently)
4512019-04-18T19:24:07  <gmaxwell> right thats another point against blocking v1 outputs:  It's _impossible_ to block p2sh v1 outputs...
4522019-04-18T19:24:25  <sdaftuar> it would be nice to not bother implementing p2sh for v1, i think?
4532019-04-18T19:24:27  <luke-jr> and because of ^, I don't think we should warn sending to v1 outputs either
4542019-04-18T19:25:01  <luke-jr> sdaftuar: is there a benefit to that?
4552019-04-18T19:25:14  <achow101> sdaftuar: nothing prevents anyone from making a p2sh with v1 as redeemscript though
4562019-04-18T19:25:16  <sipa> that's an independent discussion
4572019-04-18T19:25:22  <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.
4582019-04-18T19:25:29  <instagibbs> achow101, you can define it to be illegal tho
4592019-04-18T19:25:39  <sipa> jnewbery: what's your opinion?
4602019-04-18T19:25:41  <instagibbs> or just leave it undefined
4612019-04-18T19:25:43  <sdaftuar> sipa: agreed, but it drives the point home that we want v1 addresses to be forward compatible
4622019-04-18T19:25:46  <gmaxwell> achow101: we could, for example, close of p2sh embedded spending in the future entirely.
4632019-04-18T19:25:58  <gmaxwell> s/of/off/
4642019-04-18T19:26:04  <jnewbery> I still believe that the wallet shouldn't send to v1+ addresses until the node can validate them
4652019-04-18T19:26:23  <gmaxwell> jnewbery: what do you mean by validate them?
4662019-04-18T19:26:27  <luke-jr> ^
4672019-04-18T19:26:38  <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
4682019-04-18T19:26:42  <gmaxwell> There normally isn't really any validation of outputs.
4692019-04-18T19:26:44  <luke-jr> why does the sender care if the recipient spends it or not
4702019-04-18T19:26:45  <jnewbery> I mean that they can be spent
4712019-04-18T19:27:11  <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
4722019-04-18T19:27:14  <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
4732019-04-18T19:27:23  <luke-jr> jnewbery: the sender doesn't know if they can or can't be spent
4742019-04-18T19:27:27  <sipa> jnewbery: would you be ok with a GUI-only warning?
4752019-04-18T19:27:29  <wumpus> so to be clear: the discussion is about the relay policy, the wallet is a different topic
4762019-04-18T19:27:39  <jnewbery> for example, we don't send to v0 with non 42/64 character witnesses
4772019-04-18T19:27:45  <gmaxwell> (FWIW, most of my inbound peers are older versions... many old enough to have no bech32 support)
4782019-04-18T19:27:49  <luke-jr> jnewbery: it is spendable, just rejected by policy
4792019-04-18T19:28:02  <gmaxwell> jnewbery: yes, because v0 is defined now. There is no forward compatiblity problem.
4802019-04-18T19:28:09  <jnewbery> I'd be ok with anything. I'm just expressing an opinion, which it appears is minority :)
4812019-04-18T19:28:13  <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
4822019-04-18T19:28:16  <sipa> gmaxwell: relaying of v0 witness outputs was added in 0.13.0 though; long before bech32 was implemented
4832019-04-18T19:28:29  <luke-jr> most nodes are 0.16 still
4842019-04-18T19:28:41  <jonasschnelli> I think we should allow sending to v1+ in the wallet and in the GUI
4852019-04-18T19:28:50  <jnewbery> Right, my opinion is that the forward-compatibility issue is not a huge issue
4862019-04-18T19:28:54  <gmaxwell> most newly syncing nodes I see are 0.16.1 ... fwiw. which it's own puzzle...
4872019-04-18T19:29:11  <wumpus> jnewbery: you mean not for relaying either?
4882019-04-18T19:29:18  <luke-jr> 0.16.1 is 50% of all nodes it looks like
4892019-04-18T19:29:19  <jonasschnelli> forward compatibility seems to be more important than foot-gun that trigger very very rarely
4902019-04-18T19:29:25  <jnewbery> No, I think we should relay sending to V anything
4912019-04-18T19:29:31  <jonasschnelli> And we don't (and can't) prevent P2SH forms anyway
4922019-04-18T19:29:43  <wumpus> I'm confused now
4932019-04-18T19:30:01  <jnewbery> I think we're all in agreement about mempool policy
4942019-04-18T19:30:03  <wumpus> so, do we agree on changing this relay policy?
4952019-04-18T19:30:09  <jonasschnelli> yes
4962019-04-18T19:30:10  <sipa> i think so
4972019-04-18T19:30:11  <meshcollider> Yes
4982019-04-18T19:30:21  <luke-jr> +1
4992019-04-18T19:30:25  <achow101> ack
5002019-04-18T19:30:25  <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...)
5012019-04-18T19:30:26  <jnewbery> the only thing we disagree about is whether there should be a wallet check. I say yes, but I haven't convinced anyone :)
5022019-04-18T19:30:30  <wumpus> ok!
5032019-04-18T19:30:37  <jonasschnelli> I guess the we are not agreeing about wether the wallet allows to send to v1+
5042019-04-18T19:30:44  <wumpus> jnewbery: I think a warning makes sense
5052019-04-18T19:30:45  <meshcollider> I'm ok with a wallet warning
5062019-04-18T19:30:50  <luke-jr> gmaxwell: Chinese users are real though?
5072019-04-18T19:30:55  <gmaxwell> I think a warning is foolish.
5082019-04-18T19:31:01  <jonasschnelli> me 2
5092019-04-18T19:31:13  <luke-jr> if we could reliably warn, it might be worth considering, but we can't
5102019-04-18T19:31:16  <gmaxwell> luke-jr: Yes but I'm not confident that they're users. We can talk offline.
5112019-04-18T19:31:20  <jonasschnelli> Assume one will send to v1 with 0.18.0 in one year where we assume having v1
5122019-04-18T19:31:22  <luke-jr> becuase of p2sh etc
5132019-04-18T19:31:40  <jonasschnelli> (if 0.18.0 would have the warning)
5142019-04-18T19:31:54  <luke-jr> jonasschnelli: if warnings were reliable, we could base it on what we see in blocks
5152019-04-18T19:31:57  <gmaxwell> I could even see blocking sending, but only up until a certian time.
5162019-04-18T19:32:06  <jonasschnelli> I'm sure users would send to the p2sh version of it just thy bypass the warning
5172019-04-18T19:32:10  <luke-jr> eg, if we see a softfork deployment, and a bunch of v1 txs getting mined, then okay
5182019-04-18T19:32:28  <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.
5192019-04-18T19:32:29  <jonasschnelli> luke-jr: yes. But that complex to implement without knowing the future
5202019-04-18T19:32:39  <MarcoFalke> How would the warning be worded?
5212019-04-18T19:32:40  <luke-jr> well, because we can't detect it reliably anyway, no point doing it even that way
5222019-04-18T19:33:05  <gmaxwell> I feel like the principle of outputs is being lost here.
5232019-04-18T19:33:08  <luke-jr> (I suppose we could look for spends getting mined instead)
5242019-04-18T19:33:25  <gmaxwell> When a third party provides you with an output, thats it. It is none of your business what their policy is.
5252019-04-18T19:33:37  <sdaftuar> gmaxwell: i agree with that
5262019-04-18T19:33:42  <gmaxwell> This is one of the underlying principles behind p2sh and later hash based addresses.
5272019-04-18T19:33:55  <luke-jr> gmaxwell: good point
5282019-04-18T19:33:58  <MarcoFalke> "Warning: You are sending to an address that miners can steal from"?
5292019-04-18T19:33:59  <gmaxwell> It's an important principle because it lets the ecosystem evolve without everyone else getting up in your business. :P
5302019-04-18T19:33:59  <instagibbs> We can't do anything when someone gives you a bcash address either
5312019-04-18T19:34:06  <luke-jr> MarcoFalke: that might not be true though
5322019-04-18T19:34:09  <jonasschnelli> Warning if the last <tbd> blocks have no Vx output spent is probably an overkill?
5332019-04-18T19:34:15  <MarcoFalke> And the the users go on reddit and ask what it means
5342019-04-18T19:34:18  <gmaxwell> MarcoFalke: that warning wouldn't be true after some point in the future.
5352019-04-18T19:34:35  <MarcoFalke> s/can/may for a limited time/
5362019-04-18T19:34:38  <instagibbs> I'm not sure what warnings would achieve.
5372019-04-18T19:35:09  <luke-jr> it would achieve people moving back to P2SH wrappers
5382019-04-18T19:35:12  *** Kvaciral has joined #bitcoin-core-dev
5392019-04-18T19:35:13  <instagibbs> lol
5402019-04-18T19:35:17  <sdaftuar> yuck!
5412019-04-18T19:35:22  <gmaxwell> and still sending to v1
5422019-04-18T19:35:24  <gmaxwell> :P
5432019-04-18T19:35:29  <luke-jr> right
5442019-04-18T19:36:12  <wumpus> time for next topic, I think
5452019-04-18T19:36:16  <jnewbery> +1
5462019-04-18T19:36:22  <wumpus> #topic Bitcoin Core design documentation (jnewbery)
5472019-04-18T19:36:25  <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....)
5482019-04-18T19:36:31  <MarcoFalke> I'd prefer: "Warning: You are sending to a p2sh address"
5492019-04-18T19:36:48  <instagibbs> gmaxwell, happens a lot, and actually forcing people onto bech32 would fix these since they have their own bch code thing
5502019-04-18T19:37:04  <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.
5512019-04-18T19:37:15  <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.
5522019-04-18T19:37:30  <jnewbery> Examples: P2P banning/disconnecting design philosophy
5532019-04-18T19:37:35  <instagibbs> jnewbery, ACK, but note that it's mostly me imagining other people doing the work
5542019-04-18T19:37:41  <wumpus> why not the doc folder?
5552019-04-18T19:37:46  <jnewbery> Past critical bugs that have been fixed
5562019-04-18T19:37:49  <achow101> we have that devwiki repo we use for release notes. could put other docs there
5572019-04-18T19:37:58  <jonasschnelli> I also prefer within the sources
5582019-04-18T19:38:04  <MarcoFalke> agree with wumpus. Should be in ./doc/
5592019-04-18T19:38:10  <jonasschnelli> Also,.. how do we prevent from getting outdated?
5602019-04-18T19:38:22  <gmaxwell> I'd prefer within the codebase, in particular because keeping a durable copy of github issues/wikis/etc is a lot more work.
5612019-04-18T19:38:24  <MarcoFalke> jonasschnelli: Yell at people for not updating the docs
5622019-04-18T19:38:26  <wumpus> achow101:yes, that would be another option
5632019-04-18T19:38:33  <jnewbery> I don't think adding docs should go through the same review process as code changes
5642019-04-18T19:38:36  <gmaxwell> Maybe put a boiler plate header on them that they could be outdated.
5652019-04-18T19:38:44  <jnewbery> gmaxwell: github wikis are repos. You can clone them locally
5662019-04-18T19:38:47  <gmaxwell> and add a last updated date to each document or something.
5672019-04-18T19:38:51  <wumpus> jonasschnelli:same with anything else, it needs to be maintained or will be removed again at some point
5682019-04-18T19:39:06  <MarcoFalke> jnewbery: yes they should. Wrong documentation is more harmful than no documentation
5692019-04-18T19:39:08  <gmaxwell> even having it in the history is useful too.
5702019-04-18T19:39:28  <luke-jr> IMO it should be separate from the code.
5712019-04-18T19:39:37  <wumpus> but I like the idea, if anyone is willing to write this ata ll
5722019-04-18T19:39:47  <luke-jr> this is an easy case to modularise; it has no ties to our versions/branches
5732019-04-18T19:39:49  <sipa> i like the idea of putting a "Last updated at" + warning it could be outdated
5742019-04-18T19:39:55  <sdaftuar> MarcoFalke: wait what, wrong documentation is more harmful than nothing?  can you explain?
5752019-04-18T19:40:21  <gmaxwell> I don't really care what repo its in, just should be in some repo for sure. :)
5762019-04-18T19:40:30  <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.
5772019-04-18T19:40:41  <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
5782019-04-18T19:40:54  <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
5792019-04-18T19:41:04  <MarcoFalke> sdaftuar: I was talking about review
5802019-04-18T19:41:09  <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.
5812019-04-18T19:41:11  <MarcoFalke> not about outdated documentation
5822019-04-18T19:41:21  <gmaxwell> (okay maybe not also)
5832019-04-18T19:41:28  <sdaftuar> wumpus: MarcoFalke: i definitely believe in review, but i imagine that mostly you're better off with old docs, rather than no docs
5842019-04-18T19:41:38  <gmaxwell> But I still think it's worth doing even if it ends up outdated.
5852019-04-18T19:42:05  <wumpus> wrong code comments can cause a lot of damage, maybe less so for high level docs
5862019-04-18T19:42:09  <gmaxwell> Its just somewhat important the the text itself reflect the possibility of it being outdated.
5872019-04-18T19:42:18  <MarcoFalke> agree that outdated (timestamped) documentation is helpful
5882019-04-18T19:42:27  <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
5892019-04-18T19:42:29  <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
5902019-04-18T19:42:51  <wumpus> well, put it in the wiki then
5912019-04-18T19:42:54  <jnewbery> *not in the repo
5922019-04-18T19:42:59  <wumpus> everyone has write access to that one :)
5932019-04-18T19:43:06  <gmaxwell> Is a bunch of spelling fixes important? :P
5942019-04-18T19:43:11  <luke-jr> github wikis are just git repos
5952019-04-18T19:43:17  <jnewbery> I don't think it exists for bitcoin/bitcoin
5962019-04-18T19:43:19  <wumpus> gmaxwell:not important, but I agree re: PR bottlenecks
5972019-04-18T19:43:20  <MarcoFalke> which is the downside that anyone can vandalize
5982019-04-18T19:43:26  <wumpus> jnewbery: it doesn't for access control
5992019-04-18T19:43:31  <wumpus> jnewbery: please use the devwiki
6002019-04-18T19:43:34  <MarcoFalke> how hard is it to run a spellchecker these days?
6012019-04-18T19:43:36  <wumpus> https://github.com/bitcoin-core/bitcoin-devwiki/wiki
6022019-04-18T19:43:39  <luke-jr> MarcoFalke: can address that when/if it happens
6032019-04-18T19:43:47  <MarcoFalke> ok
6042019-04-18T19:43:52  <jnewbery> why not a wiki in bitcoin/bitcoin?
6052019-04-18T19:44:00  <luke-jr> jnewbery: because it's Core-specific?
6062019-04-18T19:44:02  <wumpus> because it'd only be writabel by people with commit access
6072019-04-18T19:44:06  <jnewbery> ah
6082019-04-18T19:44:06  <luke-jr> (and if it isn't, we have BIPs)
6092019-04-18T19:44:08  <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
6102019-04-18T19:44:19  <gmaxwell> Also be careful with making publically writable stuff in bitcoin/bitcoin.
6112019-04-18T19:44:19  <wumpus> the only way to do delegation on github is to have multiple repos
6122019-04-18T19:44:32  <wumpus> gmaxwell: yes, I don't want that
6132019-04-18T19:44:42  <jonasschnelli> gmaxwell: indeed
6142019-04-18T19:44:44  <gmaxwell> "ATTENTION. OLD BITCOIN IS VULNERABLE. DOWNLOAD HOTFIX NOW  http://secure.haxor.com/bitcoin.exe"
6152019-04-18T19:44:55  <MarcoFalke> hmmm
6162019-04-18T19:44:56  <sdaftuar> ouch :(
6172019-04-18T19:45:00  <wumpus> no need to throw everything in the same place
6182019-04-18T19:45:01  <jonasschnelli> heh
6192019-04-18T19:45:12  <jnewbery> ok, thanks. Sounds like https://github.com/bitcoin-core/bitcoin-devwiki/wiki is the place
6202019-04-18T19:45:15  <luke-jr> gmaxwell: 404
6212019-04-18T19:45:23  <sipa> lol
6222019-04-18T19:45:25  <MarcoFalke> 15 minutes left. Next topic
6232019-04-18T19:45:27  <jonasschnelli> rofl
6242019-04-18T19:45:40  <luke-jr> but wait, I need to get the hotfix!
6252019-04-18T19:45:44  <gmaxwell> luke-jr: "wine <urlib error>: 404"
6262019-04-18T19:45:49  <wumpus> #topic opportunity to provide feedback with GitHub CEO (moneyball)
6272019-04-18T19:46:01  <instagibbs> you gotta add sudo
6282019-04-18T19:46:04  *** darosior has joined #bitcoin-core-dev
6292019-04-18T19:46:06  <MarcoFalke> moneyball is github ceo?
6302019-04-18T19:46:07  <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
6312019-04-18T19:46:07  <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.
6322019-04-18T19:46:18  <wumpus> (I don't really have anything to discuss wrt hardcoded seeds at the moment)
6332019-04-18T19:46:25  <meshcollider> wumpus: you can allow anyone to edit the wiki, not just those with write access, but yeah thats a problem in itself
6342019-04-18T19:46:39  <MarcoFalke> wumpus: ok
6352019-04-18T19:46:43  <instagibbs> moneyball, sorry who is "we" wrt demos
6362019-04-18T19:46:52  <cfields> moneyball: +1! There's something that we've been discussing in a separate thread, this would be a great opportunity.
6372019-04-18T19:47:01  *** timothy has quit IRC
6382019-04-18T19:47:04  <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
6392019-04-18T19:47:06  <gmaxwell> sounds good for people with opinions. :)
6402019-04-18T19:47:07  <cfields> (we=DCI)
6412019-04-18T19:47:32  <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
6422019-04-18T19:47:33  <cfields> instagibbs: lol, sorry, that wasn't in response to you.
6432019-04-18T19:47:34  <luke-jr> open source github? :p
6442019-04-18T19:47:42  <MarcoFalke> feature request: Nicely display pgp signed comments
6452019-04-18T19:47: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
6462019-04-18T19:47:52  <moneyball> luke-jr: i'd say nothing is off-limits!
6472019-04-18T19:48:00  <luke-jr> MarcoFalke: eh, trusting GitHub to verify PGP seems like a bad idea
6482019-04-18T19:48:12  <MarcoFalke> Just display, not verifying
6492019-04-18T19:48:12  <jonasschnelli> Probably interested people should form a list of feature requests and/or bugs (gist or wiki)
6502019-04-18T19:48:13  <instagibbs> stop having commits reported in git commit timestamp order :P
6512019-04-18T19:48:16  <moneyball> instagibbs: "we" is github
6522019-04-18T19:48:25  <jonasschnelli> No need to post your feature request here and now
6532019-04-18T19:48:31  <sipa> yeah
6542019-04-18T19:48:32  <luke-jr> instagibbs: that's git-log's default too though
6552019-04-18T19:48:37  <moneyball> yeah i am not intending to create the list right now in this meeting
6562019-04-18T19:48:48  <jonasschnelli> moneyball: Thanks and great opportunity I agree
6572019-04-18T19:48:53  <cfields> moneyball: I'd be interested.
6582019-04-18T19:48:54  <moneyball> i wanted to see if others view this as a valuable opportunity and whether 1 or more folks would join me
6592019-04-18T19:48:55  <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.
6602019-04-18T19:48:58  <gwillen> instagibbs: yes for the love of god, displaying commits in topo instead of timestamp order
6612019-04-18T19:49:06  <gwillen> there has been an open issue on this for a fucking age
6622019-04-18T19:49:10  <meshcollider> It is in-person right, not remote attendance?
6632019-04-18T19:49:52  <gwillen> (for reference https://github.com/isaacs/github/issues/386)
6642019-04-18T19:49:56  <moneyball> an in-person lunch in SF
6652019-04-18T19:50:34  <luke-jr> gwillen: --graph would be nice too :p
6662019-04-18T19:50:44  <gwillen> let's not ask for a pony here ;-)
6672019-04-18T19:50:47  <wumpus> gwillen: yes please
6682019-04-18T19:50:51  <sipa> maybe open an issue on our tracker, where people can comment with things to mention?
6692019-04-18T19:51:01  <sipa> (also, ack topo sort; i've personnally asked them for this years ago)
6702019-04-18T19:51:02  <MarcoFalke> +1 instagibbs suggestion
6712019-04-18T19:51:37  <jnewbery> yes please!
6722019-04-18T19:51:38  <moneyball> sipa: i will do that
6732019-04-18T19:51:48  <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
6742019-04-18T19:52:13  <sipa> moneyball: thanks
6752019-04-18T19:52:15  <moneyball> if anyone would like to join cfields and me, let me know so we can coordinate a date with GitHub
6762019-04-18T19:52:33  <luke-jr> wumpus: maybe github rejecting pushes that don't pass the checker script is sufficient
6772019-04-18T19:52:39  <moneyball> in the mean time please contribute to the Issue i'll create. i'll post it here once created.
6782019-04-18T19:52:53  <meshcollider> Sounds good
6792019-04-18T19:53:04  <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.
6802019-04-18T19:53:13  <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
6812019-04-18T19:53:19  <cfields> Things like "display order" they'll hear from everyone.
6822019-04-18T19:53:35  <ryanofsky> my github feature request would be ability to base prs on top of other prs (just hide commits from base pr)
6832019-04-18T19:53:37  <luke-jr> wumpus: eg, just the PGP checks
6842019-04-18T19:53:39  <jnewbery> They should hear it from everyone!
6852019-04-18T19:53:55  <luke-jr> ryanofsky: ooh, good idea
6862019-04-18T19:53:56  <meshcollider> I'd like a better "boomark this PR" system to keep track of interesting PRs I want to come back to
6872019-04-18T19:53:59  <gmaxwell> luke-jr: that was exactly my thought.
6882019-04-18T19:54:03  <sipa> cfields: good point
6892019-04-18T19:54:12  <gmaxwell> (re enforce pgp allowing for access split)
6902019-04-18T19:54:13  <jonasschnelli> paranoid-mode would probably exclude using github
6912019-04-18T19:54:15  <cfields> ok, maybe s/paranoia-related/related to the way we use github uniquely/
6922019-04-18T19:54:19  <sipa> cfields: i suspect the ways in which we most _differ_ from other projects is in centralization/trust concerns
6932019-04-18T19:54:30  <cfields> sipa: yes, right.
6942019-04-18T19:54:31  <wumpus> jonasschnelli:yes, I think that's a very slippery slope :)
6952019-04-18T19:54:34  <gwillen> cfields: that makes sense, but on the other hand they have been ignoring the display order thing for almost 5 years
6962019-04-18T19:54:38  <sipa> any other topics?
6972019-04-18T19:54:45  <instagibbs> 6 min left
6982019-04-18T19:54:48  <gmaxwell> gwillen: thre just may be an arch reason as to why its hard.
6992019-04-18T19:54:49  <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
7002019-04-18T19:54:49  <wumpus> don't think so
7012019-04-18T19:54:50  <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"
7022019-04-18T19:55:26  <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
7032019-04-18T19:55:34  <ryanofsky> luke-jr, i think that already exists, you can filter based on to address
7042019-04-18T19:55:36  <wumpus> luke-jr:there is, you acn filter on author@github.com and things like that
7052019-04-18T19:55:41  <cfields> moneyball: maybe you can provide some context for why they reached out to us specifically?
7062019-04-18T19:55:57  <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.
7072019-04-18T19:56:04  <moneyball> jimpo and i had emailed them previously during the unicorn days, so our same contact reached back out to us
7082019-04-18T19:56:08  <luke-jr> wumpus: I don't understand
7092019-04-18T19:56:24  <jonasschnelli> But never forget, they need community feedback to improve to earn money for corporate customers
7102019-04-18T19:56:32  <jonasschnelli> *from
7112019-04-18T19:56:33  <ryanofsky> luke-jr, if you want to filter mentions look for Mention <mention@noreply.github.com> in To: header
7122019-04-18T19:56:34  <gwillen> gmaxwell: I definitely agree on focusing on active problems with no good workaround
7132019-04-18T19:56:37  <wumpus> luke-jr there's a special to-address they'll add in those cases fornmentions
7142019-04-18T19:56:42  <cfields> moneyball: heh, gotcha. Thanks.
7152019-04-18T19:56:47  <luke-jr> hmm
7162019-04-18T19:57:44  <wumpus> #endmeeting
7172019-04-18T19:57:44  <lightningbot> Meeting ended Thu Apr 18 19:57:44 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7182019-04-18T19:57:44  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-18-19.00.html
7192019-04-18T19:57:44  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-18-19.00.txt
7202019-04-18T19:57:44  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-18-19.00.log.html
7212019-04-18T19:58:17  <gmaxwell> gwillen: it may also be with the ownership change their priorties are usefully different now.
7222019-04-18T19:58:29  <wumpus> luke-jr: https://help.github.com/en/articles/about-email-notifications#filtering-email-notifications mentions all of them
7232019-04-18T19:58:32  *** bitcoin-git has joined #bitcoin-core-dev
7242019-04-18T19:58:32  <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
7252019-04-18T19:58:32  <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
7262019-04-18T19:58:38  *** bitcoin-git has left #bitcoin-core-dev
7272019-04-18T19:58:49  <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
7282019-04-18T19:58:53  <cfields> moneyball: Thanks for bringing that up!
7292019-04-18T19:58:53  <gwillen> (but obviously both would be nice)
7302019-04-18T19:59:39  <luke-jr> wumpus: thanks
7312019-04-18T20:00:45  <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
7322019-04-18T20:00:45  <gmaxwell> github because it would retard account growth.
7332019-04-18T20:00:51  <gmaxwell> Maybe that would be less important now.
7342019-04-18T20:01:25  <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
7352019-04-18T20:01:28  <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!)
7362019-04-18T20:01:39  <gwillen> (I do agree it's also a good opportunity to bring up philosophically-aligned stuff about privacy and trust)
7372019-04-18T20:01:53  <instagibbs> would also be nice so i dont have to read "ACTIVATED 1GB BLOCKS" PRs
7382019-04-18T20:02:01  <instagibbs> as a non-maintainer
7392019-04-18T20:02:55  <gmaxwell> I'm not sure how much of that is just my dislike of the modern 'everyone can scribble on everything' web. :P
7402019-04-18T20:03:41  <wumpus> it would have been nice, with better people
7412019-04-18T20:04:06  <gwillen> "better people" would solve many problems, but it was not to be
7422019-04-18T20:04:20  <sipa> like the need for bitcoin?
7432019-04-18T20:04:34  <wumpus> ^^
7442019-04-18T20:04:53  <gwillen> heh!
7452019-04-18T20:05:21  <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
7462019-04-18T20:05:28  <gwillen> and also as a platform for grandstanding
7472019-04-18T20:06:15  <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)
7482019-04-18T20:06:29  <gwillen> this would help with all the "rar I want to make a political statement against your repository" issues
7492019-04-18T20:06:45  <gwillen> since there would no longer be a motivation to file them if they could be moderated before publication
7502019-04-18T20:06:54  <gmaxwell> yup.
7512019-04-18T20:07:01  <jonasschnelli> If I could ask for a feature, then it would be making github commit order rebase save
7522019-04-18T20:07:11  <gmaxwell> gwillen: Also it would be less stressful to deal with them.
7532019-04-18T20:07:22  <gwillen> jonasschnelli: is this the same as the toposort thing we were discussing upthread
7542019-04-18T20:07:27  <gwillen> or a different issue
7552019-04-18T20:07:33  <gmaxwell> just another idiot with an offtopic request, ... ploink.
7562019-04-18T20:07:46  <gmaxwell> vs oh god inescapable dramafest.
7572019-04-18T20:09:50  <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
7582019-04-18T20:10:04  <moneyball> Please submit your ideas for improving GitHub here! https://github.com/bitcoin/bitcoin/issues/15847
7592019-04-18T20:10:06  <sipa> jonasschnelli: yes, github sorts commits by author date
7602019-04-18T20:10:13  <sipa> jonasschnelli: not by their dependency order
7612019-04-18T20:10:24  *** bitcoin-git has joined #bitcoin-core-dev
7622019-04-18T20:10:24  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2d4f70cabd6d...d1c2ed8dd768
7632019-04-18T20:10:25  *** darosior has quit IRC
7642019-04-18T20:10:25  <bitcoin-git> bitcoin/master fa346fe MarcoFalke: doc: Remove upgrade note in release notes from EOL versions
7652019-04-18T20:10:25  <bitcoin-git> bitcoin/master d1c2ed8 MarcoFalke: Merge #15821: doc: Remove upgrade note in release notes from EOL versions
7662019-04-18T20:10:26  <jonasschnelli> Making it impossible to manually sort things or even group with pure "message-commits"
7672019-04-18T20:10:37  *** bitcoin-git has left #bitcoin-core-dev
7682019-04-18T20:11:12  *** bitcoin-git has joined #bitcoin-core-dev
7692019-04-18T20:11:12  <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
7702019-04-18T20:11:15  *** bitcoin-git has left #bitcoin-core-dev
7712019-04-18T20:11:30  <gwillen> jonasschnelli: yeah, that is the same issue that at least half a dozen people in here also mentioned including me
7722019-04-18T20:11:39  <gwillen> so we should include it in our feedback for sure :-)
7732019-04-18T20:11:57  *** bitcoin-git has joined #bitcoin-core-dev
7742019-04-18T20:11:57  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/a58d80d1b261...607b1b74986b
7752019-04-18T20:11:58  <bitcoin-git> bitcoin/0.18 8602d8b Suhas Daftuar: Revert "Change in transaction pull scheduling to prevent InvBlock-related ...
7762019-04-18T20:11:58  <bitcoin-git> bitcoin/0.18 607b1b7 MarcoFalke: Merge #15839: [0.18] Revert GetData randomization change (#14897)
7772019-04-18T20:12:01  *** bitcoin-git has left #bitcoin-core-dev
7782019-04-18T20:12:17  *** bitcoin-git has joined #bitcoin-core-dev
7792019-04-18T20:12:17  <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
7802019-04-18T20:12:20  *** bitcoin-git has left #bitcoin-core-dev
7812019-04-18T20:13:44  <MarcoFalke> So pull in the release notes and tag rc4?
7822019-04-18T20:16:40  <wumpus> find w/ me
7832019-04-18T20:18:20  <wumpus> huh didi I forget to push my translations update?
7842019-04-18T20:20:37  <MarcoFalke> there was one for rc3 or rc2, I might recall
7852019-04-18T20:22:15  *** bitcoin-git has joined #bitcoin-core-dev
7862019-04-18T20:22:16  <bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/607b1b74986b...a4fc2fbb111e
7872019-04-18T20:22:16  <bitcoin-git> bitcoin/0.18 a4fc2fb Wladimir J. van der Laan: gui: Pre-rc4 translations update
7882019-04-18T20:22:18  *** bitcoin-git has left #bitcoin-core-dev
7892019-04-18T20:24:35  *** darosior has joined #bitcoin-core-dev
7902019-04-18T20:28:48  <kanzure> why is bitcoin-git exiting so frequently. can we fix this?
7912019-04-18T20:29:41  <sipa> it joins for every message
7922019-04-18T20:30:38  <gwillen> it is not a persistent process, it is stateless, so it can't stay joined when not messaging
7932019-04-18T20:30:51  *** Guyver2 has quit IRC
7942019-04-18T20:30:54  <luke-jr> if we remove the +n on the channel, it can send without joining
7952019-04-18T20:31:06  <luke-jr> this may or may not be spam suicide though
7962019-04-18T20:31:09  <gwillen> right
7972019-04-18T20:31:16  <gwillen> probably better to tolerate a few extra lines
7982019-04-18T20:31:37  <wumpus> we had that in the past, but it's not a good idea
7992019-04-18T20:31:42  <gwillen> I'm not sure how -n interacts with bans, it might make them ineffective
8002019-04-18T20:32:25  <wumpus> FWIW in general it can be pretty useful to disable join/part notifications for busy channels like this
8012019-04-18T20:32:55  *** bitcoin-git has joined #bitcoin-core-dev
8022019-04-18T20:32:56  <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
8032019-04-18T20:32:57  *** bitcoin-git has left #bitcoin-core-dev
8042019-04-18T20:34:43  <luke-jr> wumpus: my client only does it globally
8052019-04-18T20:38:17  *** bitcoin-git has joined #bitcoin-core-dev
8062019-04-18T20:38:17  <bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/a4fc2fbb111e...438483983a45
8072019-04-18T20:38:17  <bitcoin-git> bitcoin/0.18 4384839 Wladimir J. van der Laan: doc: Move release notes from wiki
8082019-04-18T20:38:19  *** bitcoin-git has left #bitcoin-core-dev
8092019-04-18T20:39:19  <sdaftuar> laanwj: i was just trying to edit the wiki to remove mention of 14897 from the release notes
8102019-04-18T20:39:33  <sdaftuar> er wumpus ^^
8112019-04-18T20:41:04  <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?
8122019-04-18T20:41:06  <wumpus> sdaftuar: uhmm
8132019-04-18T20:41:16  <wumpus> sdaftuar: I see various TODOs by Pieter are also still in there
8142019-04-18T20:41:24  <sdaftuar> yeah i just saw that too
8152019-04-18T20:41:59  <wumpus> for this reason I prefer to leave merging back the release notes for -final instead of a rc
8162019-04-18T20:42:10  <wumpus> but yes, only way to edit it now is on the branch
8172019-04-18T20:42:16  <sdaftuar> ok sounds good
8182019-04-18T20:42:47  <gmaxwell> why doesn't the bot just stay in all the time?
8192019-04-18T20:43:35  <wumpus> ready to tag rc4?
8202019-04-18T20:43:50  <gwillen> gmaxwell: it can't, it's stateless
8212019-04-18T20:43:52  <wumpus> gmaxwell: gwillen | it is not a persistent process, it is stateless, so it can't stay joined when not messaging
8222019-04-18T20:43:57  <wumpus> it's a design choice
8232019-04-18T20:44:54  <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
8242019-04-18T20:47:18  <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
8252019-04-18T20:49:59  *** darosior has quit IRC
8262019-04-18T20:50:17  *** darosior has joined #bitcoin-core-dev
8272019-04-18T20:51:28  *** bitcoin-git has joined #bitcoin-core-dev
8282019-04-18T20:51:28  <bitcoin-git> [bitcoin] laanwj pushed tag v0.18.0rc4: https://github.com/bitcoin/bitcoin/compare/v0.18.0rc4
8292019-04-18T20:51:29  *** bitcoin-git has left #bitcoin-core-dev
8302019-04-18T20:51:43  *** bitcoin-git has joined #bitcoin-core-dev
8312019-04-18T20:51:43  <bitcoin-git> [bitcoin] laanwj deleted tag v0.18.0rc4: https://github.com/bitcoin/bitcoin/compare/9b2d3aafcf91...000000000000
8322019-04-18T20:51:44  *** bitcoin-git has left #bitcoin-core-dev
8332019-04-18T20:52:18  *** bitcoin-git has joined #bitcoin-core-dev
8342019-04-18T20:52:18  <bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/438483983a45...379f71ea4f27
8352019-04-18T20:52:18  <bitcoin-git> bitcoin/0.18 379f71e Wladimir J. van der Laan: build: Bump version to rc4
8362019-04-18T20:52:22  *** bitcoin-git has left #bitcoin-core-dev
8372019-04-18T20:53:09  *** bitcoin-git has joined #bitcoin-core-dev
8382019-04-18T20:53:09  <bitcoin-git> [bitcoin] laanwj pushed tag v0.18.0rc4: https://github.com/bitcoin/bitcoin/compare/v0.18.0rc4
8392019-04-18T20:53:10  *** darosior has quit IRC
8402019-04-18T20:53:22  *** bitcoin-git has left #bitcoin-core-dev
8412019-04-18T20:54:34  *** darosior has joined #bitcoin-core-dev
8422019-04-18T20:58:38  <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.
8432019-04-18T20:59:04  <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.
8442019-04-18T20:59:32  <gmaxwell> Which made me wonder if perhaps some chinese language docs pointed to an outdated download... but jl2012 was unable to find anything.
8452019-04-18T21:00:01  *** Jayflux has quit IRC
8462019-04-18T21:02:28  <gmaxwell> also their behavior appears to be weird, e.g. I see them downloading a moderate number of blocks then stop and stay connected.
8472019-04-18T21:06:00  *** darosior has quit IRC
8482019-04-18T21:06:29  <luke-jr> gmaxwell: hmm, any relation to the networks?
8492019-04-18T21:12:42  <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.
8502019-04-18T21:13:12  *** fabianfabian has joined #bitcoin-core-dev
8512019-04-18T21:13:30  <gmaxwell> beyond 'china' I'm not aware of anything that links these hosts.
8522019-04-18T21:15:03  *** bitcoin-git has joined #bitcoin-core-dev
8532019-04-18T21:15:03  <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
8542019-04-18T21:15:08  *** bitcoin-git has left #bitcoin-core-dev
8552019-04-18T21:15:09  <gmaxwell> Every network in that list is china, and thats also doubly intresting considering the historic near absence of bitcoin nodes in china.
8562019-04-18T21:17:53  <luke-jr> hrm
8572019-04-18T21:18:07  *** jb55 has quit IRC
8582019-04-18T21:19:12  *** darosior has joined #bitcoin-core-dev
8592019-04-18T21:19:49  *** EagleTM has quit IRC
8602019-04-18T21:20:02  *** EagleTM has joined #bitcoin-core-dev
8612019-04-18T21:20:30  <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.
8622019-04-18T21:20:42  <gmaxwell> if it is confused users I still don't know why there are so many.
8632019-04-18T21:21:21  *** CrystalNice has joined #bitcoin-core-dev
8642019-04-18T21:21:49  <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.
8652019-04-18T21:22:03  <gmaxwell> (and were syncing old blocks)
8662019-04-18T21:22:45  <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.
8672019-04-18T21:23:37  <midnightmagic> appliance maybe
8682019-04-18T21:24:05  <gmaxwell> possibly.
8692019-04-18T21:25:54  <luke-jr> gmaxwell: my methodology is incompatible with splitting by region, sadly
8702019-04-18T21:37:52  *** darosior has quit IRC
8712019-04-18T21:38:10  *** darosior has joined #bitcoin-core-dev
8722019-04-18T21:38:34  *** darosior has joined #bitcoin-core-dev
8732019-04-18T21:45:06  *** jb55 has joined #bitcoin-core-dev
8742019-04-18T22:29:30  *** darosior has quit IRC
8752019-04-18T22:46:04  *** owowo has quit IRC
8762019-04-18T22:51:15  *** owowo has joined #bitcoin-core-dev
8772019-04-18T22:51:47  *** justanotheruser has joined #bitcoin-core-dev
8782019-04-18T22:51:49  *** AaronvanW has joined #bitcoin-core-dev
8792019-04-18T22:51:49  *** justanotheruser has quit IRC
8802019-04-18T22:53:31  *** fabianfabian has quit IRC
8812019-04-18T22:54:03  *** Aaronvan_ has quit IRC
8822019-04-18T22:56:10  *** justanotheruser has joined #bitcoin-core-dev
8832019-04-18T22:57:37  *** spinza has quit IRC
8842019-04-18T22:59:51  *** justanotheruser has quit IRC
8852019-04-18T23:03:00  *** dqx_ has joined #bitcoin-core-dev
8862019-04-18T23:04:17  *** justanotheruser has joined #bitcoin-core-dev
8872019-04-18T23:06:19  *** jarthur has quit IRC
8882019-04-18T23:06:48  *** spinza has joined #bitcoin-core-dev
8892019-04-18T23:27:59  *** belcher has quit IRC
8902019-04-18T23:33:51  *** AaronvanW has quit IRC
8912019-04-18T23:35:08  *** dqx_ has quit IRC
8922019-04-18T23:40:06  *** belcher has joined #bitcoin-core-dev
8932019-04-18T23:59:24  *** EagleTM has quit IRC