12016-09-15T00:10:11  *** Alopex has quit IRC
  22016-09-15T00:11:16  *** Alopex has joined #bitcoin-core-dev
  32016-09-15T00:18:05  *** PatBoy has quit IRC
  42016-09-15T00:20:25  *** PatBoy has joined #bitcoin-core-dev
  52016-09-15T00:28:03  *** achow101_ has joined #bitcoin-core-dev
  62016-09-15T00:28:31  *** achow101_ has quit IRC
  72016-09-15T00:48:32  *** sdaftuar has joined #bitcoin-core-dev
  82016-09-15T00:57:24  *** btcdrak has quit IRC
  92016-09-15T00:58:04  <achow101> I'm experimenting with the review thing. Can someone go to https://github.com/achow101/ProtectedBranchTest/pull/3 and submit an "Approve" review?
 102016-09-15T00:59:35  <sdaftuar> achow101: done
 112016-09-15T01:00:08  <achow101> thanks. something's not working...
 122016-09-15T01:00:12  <sdaftuar> yeah i saw :)
 132016-09-15T01:01:02  <sdaftuar> does it need to be approved by someone with write privs maybe?
 142016-09-15T01:01:44  <achow101> I don't know. I can't approve it since I wrote it. I'll try with the other account.
 152016-09-15T01:03:22  <achow101> oh yeah. That was totally it.
 162016-09-15T01:06:54  *** Ylbam has quit IRC
 172016-09-15T01:08:26  <achow101> Interesting that the status checks are still pending.
 182016-09-15T01:11:11  *** Magma has joined #bitcoin-core-dev
 192016-09-15T01:15:03  *** nibor has quit IRC
 202016-09-15T01:19:11  *** Chris_Stewart_5 has quit IRC
 212016-09-15T01:40:04  <rebroad> is the -dropmessagestest code still needed in main.cpp? It's not even mentioned as a command line option in init.cpp
 222016-09-15T01:41:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 232016-09-15T01:41:49  <rebroad> oh... sorry, it is
 242016-09-15T01:46:23  *** [Author] has quit IRC
 252016-09-15T01:58:20  <rebroad> ok, so I am wondering... develoeprs seem to complain when I either raise too many pull requests or raise a pull request with too many changes.. so it seems the complain is about the amount of development I am doing, so my thnking is that this is implying I should be working on other thnigs, code review perhaps? In what areas is it that the complaint might be indication that I am not contributing enough?
 262016-09-15T02:00:32  <achow101> I've mostly figured out how the review thing works, and it could benefit us.
 272016-09-15T02:00:54  <achow101> So comments through the review thing are just general comments on the whole thing, kind of useless. You can still do line notes though and that is good
 282016-09-15T02:01:41  <achow101> approving cannot be done commit by commit but rather by the full diff at the time of review.
 292016-09-15T02:04:10  <achow101> requesting changes seems like it will revoke a previous approval
 302016-09-15T02:04:58  <dcousens> achow101: you can't edit comments interestingly when posting an 'approval'
 312016-09-15T02:05:19  <achow101> And lastly branches can be setup with protections to require an approve from a committer, pass status checks (travis), and prevent administrators from merging regardless
 322016-09-15T02:05:56  <achow101> also the submitter can't approve or request changes in his own PR (duh)
 332016-09-15T02:06:22  <GitHub54> [bitcoin] rebroad opened pull request #8734: Send NOTFOUND when we don't have the block data. (master...NotfoundIfPruned) https://github.com/bitcoin/bitcoin/pull/8734
 342016-09-15T02:07:33  <achow101> dcousens: right. so any comments done with the review thing can't be edited
 352016-09-15T02:07:40  <rebroad> achow101, all sounds good!
 362016-09-15T02:08:17  *** luke-jr has quit IRC
 372016-09-15T02:08:30  *** dermoth has quit IRC
 382016-09-15T02:09:06  <achow101> I think the best thing about this is that it can be set so that a PR submitted by a committer must have another committer review it before it can be merged
 392016-09-15T02:09:20  <achow101> just in case someone gets hacked
 402016-09-15T02:11:26  <dcousens> achow101: eh,  they already have multiple processes in place... trusting github further isn't really necessary
 412016-09-15T02:12:35  <dcousens> achow101: RE privileges to approve, you don't need any see https://github.com/bitcoin/bitcoin/pull/8723#pullrequestreview-82853
 422016-09-15T02:13:31  <dcousens> I honestly don't see this being any better than the current ACK' system
 432016-09-15T02:15:18  <achow101> anyone can approve, but only certain people's approvals (the committers) will allow a PR to be merged when the branch is protected
 442016-09-15T02:16:25  <achow101> If you look at the one I linked earlier, you can see the message there about an "approved review" which apparantly must come from someone with write access
 452016-09-15T02:38:06  *** Alopex has quit IRC
 462016-09-15T02:39:11  *** Alopex has joined #bitcoin-core-dev
 472016-09-15T02:48:56  *** luke-jr has joined #bitcoin-core-dev
 482016-09-15T03:05:29  *** Chris_Stewart_5 has quit IRC
 492016-09-15T03:14:11  *** Alopex has quit IRC
 502016-09-15T03:15:17  *** Alopex has joined #bitcoin-core-dev
 512016-09-15T03:25:02  *** Alopex has quit IRC
 522016-09-15T03:26:07  *** Alopex has joined #bitcoin-core-dev
 532016-09-15T03:46:31  *** Giszmo has quit IRC
 542016-09-15T03:51:01  *** Alopex has quit IRC
 552016-09-15T03:51:29  *** dgenr8 has quit IRC
 562016-09-15T03:51:43  *** Soligor has quit IRC
 572016-09-15T03:52:06  *** Alopex has joined #bitcoin-core-dev
 582016-09-15T03:55:43  *** dgenr8 has joined #bitcoin-core-dev
 592016-09-15T04:02:02  *** Alopex has quit IRC
 602016-09-15T04:03:07  *** Alopex has joined #bitcoin-core-dev
 612016-09-15T04:15:17  *** Alopex has quit IRC
 622016-09-15T04:16:22  *** Alopex has joined #bitcoin-core-dev
 632016-09-15T04:37:05  *** timothy has quit IRC
 642016-09-15T04:37:08  *** drizztbsd has joined #bitcoin-core-dev
 652016-09-15T04:37:41  *** drizztbsd is now known as timothy
 662016-09-15T05:02:03  *** rebroad has quit IRC
 672016-09-15T05:18:32  *** Ylbam has joined #bitcoin-core-dev
 682016-09-15T05:28:31  *** [Author] has joined #bitcoin-core-dev
 692016-09-15T05:42:55  *** timothy has quit IRC
 702016-09-15T05:42:58  *** drizztbsd has joined #bitcoin-core-dev
 712016-09-15T05:43:31  *** drizztbsd is now known as timothy
 722016-09-15T05:50:11  *** Alopex has quit IRC
 732016-09-15T05:51:16  *** Alopex has joined #bitcoin-core-dev
 742016-09-15T06:00:21  *** drizztbsd has joined #bitcoin-core-dev
 752016-09-15T06:00:22  *** timothy has quit IRC
 762016-09-15T06:00:51  *** drizztbsd is now known as timothy
 772016-09-15T06:22:11  *** Alopex has quit IRC
 782016-09-15T06:22:57  <jonasschnelli> I guess thats also a new Githup thing: you can later change the base branch of a pull request
 792016-09-15T06:23:16  *** Alopex has joined #bitcoin-core-dev
 802016-09-15T06:31:56  *** rebroad has joined #bitcoin-core-dev
 812016-09-15T06:33:15  *** mol has quit IRC
 822016-09-15T06:41:14  *** rebroad_ has joined #bitcoin-core-dev
 832016-09-15T06:44:19  *** rebroad has quit IRC
 842016-09-15T06:48:17  <cfields_> wumpus: wip mingw toolchain: https://github.com/theuni/bitcoin/commit/6cc40455c96f8820a35f745fb03466bcdc8d9919
 852016-09-15T06:49:54  <cfields_> wumpus: lots of work remains. But, mingw depends build fully, and bitcoin build breaks with the same threading problems that have been reported, so it's enough to help with testing/debugging.
 862016-09-15T06:50:55  <cfields_> will continue with it tomorrow.
 872016-09-15T06:51:03  <jonasschnelli> nice cfields_ !
 882016-09-15T06:51:49  <cfields_> jonasschnelli: heh, not really. It's at the "it's a bloodbath, but it builds" stage of development :)
 892016-09-15T06:54:35  *** lahwran has joined #bitcoin-core-dev
 902016-09-15T07:08:41  *** jl2012 has quit IRC
 912016-09-15T07:10:19  *** jl2012 has joined #bitcoin-core-dev
 922016-09-15T07:15:12  *** btcdrak has joined #bitcoin-core-dev
 932016-09-15T07:16:49  *** btcdrak has quit IRC
 942016-09-15T07:17:12  *** btcdrak has joined #bitcoin-core-dev
 952016-09-15T07:20:56  *** Guyver2 has joined #bitcoin-core-dev
 962016-09-15T07:47:40  *** cdecker has joined #bitcoin-core-dev
 972016-09-15T08:04:16  *** Soligor has joined #bitcoin-core-dev
 982016-09-15T08:10:03  *** cdecker has quit IRC
 992016-09-15T08:18:32  *** MarcoFalke has joined #bitcoin-core-dev
1002016-09-15T08:20:13  *** Lauda has quit IRC
1012016-09-15T08:33:54  *** Lauda has joined #bitcoin-core-dev
1022016-09-15T08:48:46  *** mol has joined #bitcoin-core-dev
1032016-09-15T08:55:21  *** Guyver2 has quit IRC
1042016-09-15T09:11:09  *** timothy has quit IRC
1052016-09-15T09:11:13  *** drizztbsd has joined #bitcoin-core-dev
1062016-09-15T09:11:24  <GitHub156> [bitcoin] jonasschnelli opened pull request #8735: [Wallet] add option for a custom extended master privat key (xpriv) (master...2016/09/hd_set_seed) https://github.com/bitcoin/bitcoin/pull/8735
1072016-09-15T09:11:46  *** drizztbsd is now known as timothy
1082016-09-15T09:41:54  *** jannes has joined #bitcoin-core-dev
1092016-09-15T09:44:55  *** rebroad_ has quit IRC
1102016-09-15T09:49:51  <dcousens> wumpus: oh, I wanted to mention.  And all other things aside.  A small RPC cache works wonders for reducing some of the performance issues with high loads (10-20 mb)
1112016-09-15T10:08:09  *** laurentmt has joined #bitcoin-core-dev
1122016-09-15T10:10:19  <GitHub24> [bitcoin] wjx opened pull request #8736: base58: Improve DecodeBase58 performance. (master...speedup-decodebase58) https://github.com/bitcoin/bitcoin/pull/8736
1132016-09-15T10:13:25  *** laurentmt has quit IRC
1142016-09-15T10:14:24  *** timothy has quit IRC
1152016-09-15T10:14:26  *** drizztbsd has joined #bitcoin-core-dev
1162016-09-15T10:14:59  *** drizztbsd is now known as timothy
1172016-09-15T10:42:50  <GitHub86> [bitcoin] paveljanik opened pull request #8737: Trivial: UndoReadFromDisk works on undo files (rev), not on block files. (master...20160915_Undo_error_message_fix) https://github.com/bitcoin/bitcoin/pull/8737
1182016-09-15T10:52:55  *** rebroad_ has joined #bitcoin-core-dev
1192016-09-15T10:57:27  *** laurentmt has joined #bitcoin-core-dev
1202016-09-15T10:58:12  *** laurentmt has quit IRC
1212016-09-15T11:30:11  *** paveljanik has quit IRC
1222016-09-15T11:51:14  *** cryptapus has joined #bitcoin-core-dev
1232016-09-15T11:51:14  *** cryptapus has joined #bitcoin-core-dev
1242016-09-15T12:11:54  *** Giszmo has joined #bitcoin-core-dev
1252016-09-15T12:12:20  *** paveljanik has joined #bitcoin-core-dev
1262016-09-15T12:12:21  *** paveljanik has joined #bitcoin-core-dev
1272016-09-15T12:21:39  *** laurentmt has joined #bitcoin-core-dev
1282016-09-15T12:21:42  *** laurentmt has quit IRC
1292016-09-15T12:25:13  *** timothy has quit IRC
1302016-09-15T12:26:25  *** timothy has joined #bitcoin-core-dev
1312016-09-15T12:35:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1322016-09-15T12:47:51  *** dcousens has quit IRC
1332016-09-15T12:49:33  *** dcousens has joined #bitcoin-core-dev
1342016-09-15T12:51:05  *** Chris_Stewart_5 has quit IRC
1352016-09-15T12:54:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1362016-09-15T12:54:55  *** kadoban has joined #bitcoin-core-dev
1372016-09-15T12:56:45  *** kadoban has quit IRC
1382016-09-15T12:57:11  *** kadoban has joined #bitcoin-core-dev
1392016-09-15T13:38:15  *** cryptapus has quit IRC
1402016-09-15T13:39:32  *** MarcoFalke has left #bitcoin-core-dev
1412016-09-15T13:41:28  *** paveljanik has quit IRC
1422016-09-15T13:43:32  *** dcousens has quit IRC
1432016-09-15T13:47:08  *** laurentmt has joined #bitcoin-core-dev
1442016-09-15T13:47:47  *** laurentmt has quit IRC
1452016-09-15T13:49:16  *** paveljanik has joined #bitcoin-core-dev
1462016-09-15T13:51:15  *** cryptapus has joined #bitcoin-core-dev
1472016-09-15T13:51:15  *** cryptapus has joined #bitcoin-core-dev
1482016-09-15T14:09:04  *** ganger has joined #bitcoin-core-dev
1492016-09-15T14:22:22  *** laurentmt has joined #bitcoin-core-dev
1502016-09-15T14:27:31  *** wjx has quit IRC
1512016-09-15T14:27:51  *** laurentmt has quit IRC
1522016-09-15T14:44:37  <GitHub111> [bitcoin] rebroad closed pull request #8729: More granular debug (master...MoreGranularDebug6) https://github.com/bitcoin/bitcoin/pull/8729
1532016-09-15T14:46:49  *** ganger has quit IRC
1542016-09-15T15:02:03  *** Chris_Stewart_5 has quit IRC
1552016-09-15T15:05:01  *** cryptapus has quit IRC
1562016-09-15T15:10:36  *** cryptapus has joined #bitcoin-core-dev
1572016-09-15T15:10:36  *** cryptapus has joined #bitcoin-core-dev
1582016-09-15T15:14:14  *** e4xit_ has joined #bitcoin-core-dev
1592016-09-15T15:16:58  *** e4xit has quit IRC
1602016-09-15T15:16:58  *** e4xit_ is now known as e4xit
1612016-09-15T15:17:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1622016-09-15T15:36:42  *** laurentmt has joined #bitcoin-core-dev
1632016-09-15T15:41:18  *** laurentmt has quit IRC
1642016-09-15T16:02:47  <phantomcircuit> jonasschnelli: poke 8696 updated to address nits
1652016-09-15T16:06:17  *** laurentmt has joined #bitcoin-core-dev
1662016-09-15T16:08:52  *** laurentmt has quit IRC
1672016-09-15T16:32:31  *** cryptapus has quit IRC
1682016-09-15T16:32:31  *** cryptapus_ has joined #bitcoin-core-dev
1692016-09-15T16:40:15  <GitHub112> [bitcoin] sdaftuar opened pull request #8739: [qa] Fix broken sendcmpct test in p2p-compactblocks.py (master...fix-cb-test) https://github.com/bitcoin/bitcoin/pull/8739
1702016-09-15T16:40:51  *** laurentmt has joined #bitcoin-core-dev
1712016-09-15T16:40:52  *** laurentmt has quit IRC
1722016-09-15T16:49:26  *** cryptapus_ is now known as cryptapus
1732016-09-15T17:04:23  *** jannes has quit IRC
1742016-09-15T17:10:41  *** cryptapus has quit IRC
1752016-09-15T17:26:50  *** echonaut1 has quit IRC
1762016-09-15T17:27:04  *** echonaut has joined #bitcoin-core-dev
1772016-09-15T17:37:30  *** Giszmo has quit IRC
1782016-09-15T17:56:08  *** Giszmo has joined #bitcoin-core-dev
1792016-09-15T18:29:41  *** cryptapus has joined #bitcoin-core-dev
1802016-09-15T18:29:41  *** cryptapus has joined #bitcoin-core-dev
1812016-09-15T18:42:08  *** achow101 has left #bitcoin-core-dev
1822016-09-15T18:42:23  *** achow101 has joined #bitcoin-core-dev
1832016-09-15T18:48:43  *** MarcoFalke has joined #bitcoin-core-dev
1842016-09-15T18:52:29  <paveljanik> wumpus, jonasschnelli: here is a rough QT -Wshadow commit (https://github.com/paveljanik/bitcoin/commit/f9d00d7e624a6760a099ca61caca25d7982844d1). I'd like to hear what you like or dislike about such changes or what to do in some other way.
1852016-09-15T18:54:00  <paveljanik> E.g. using member initializers instead in some places etc.
1862016-09-15T18:54:06  <jonasschnelli> phantomcircuit: newline nits: https://github.com/bitcoin/bitcoin/pull/8696/files#diff-b2bb174788c7409b671c46ccc86034bdR2518
1872016-09-15T18:54:37  <jonasschnelli> phantomcircuit: I prefere modeIn instead of _mode
1882016-09-15T18:54:42  <jonasschnelli> But consider it as nit
1892016-09-15T18:54:57  <paveljanik> for ~qt we already agreed on _...
1902016-09-15T18:55:12  <jonasschnelli> Okay. Fair enought.
1912016-09-15T18:55:14  <jonasschnelli> _ look always after instance vars IMO
1922016-09-15T18:55:29  <jonasschnelli> But maybe because of my Obj-C past
1932016-09-15T18:56:04  <jonasschnelli> phantomcircuit: But the change-set looks good!
1942016-09-15T18:56:12  <jonasschnelli> ah. meant paveljanik
1952016-09-15T18:56:31  <paveljanik> it is a bit huge :-(
1962016-09-15T18:57:01  <paveljanik> and there are still two other issues, but they are more serialization related than qt/
1972016-09-15T18:57:48  <paveljanik> and I do not like how I solved this-> stuff because it can be a lot nicer.
1982016-09-15T18:58:04  <jonasschnelli> Maybe split it into parts? But I don't care. I'm happy to merge it at once. Its fairly reviewable.
1992016-09-15T18:59:16  <paveljanik> this itself is a part ;-)
2002016-09-15T18:59:52  <cfields_> jonasschnelli: completely agree, but i didn't want to create noise :)
2012016-09-15T18:59:53  <jonasschnelli> Ah. Okay then. :)
2022016-09-15T19:00:00  <sipa> DING
2032016-09-15T19:00:04  *** cdecker has joined #bitcoin-core-dev
2042016-09-15T19:00:08  <jonasschnelli> meeting?
2052016-09-15T19:00:08  <petertodd> pong
2062016-09-15T19:00:09  <cfields_> (about _foo being member)
2072016-09-15T19:00:11  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
2082016-09-15T19:00:13  <kanzure> greetz.
2092016-09-15T19:00:13  <paveljanik> peng
2102016-09-15T19:00:24  <sdaftuar> hi
2112016-09-15T19:00:39  <jonasschnelli> cfields_, paveljanik: do we already make use of _var instead of varIn?
2122016-09-15T19:00:56  <cfields_> jonasschnelli: yea, in the PRs that are already in
2132016-09-15T19:01:08  *** cryptapus has quit IRC
2142016-09-15T19:01:18  *** andytoshi has joined #bitcoin-core-dev
2152016-09-15T19:01:19  <jonasschnelli> #startmeeting
2162016-09-15T19:01:19  <lightningbot> Meeting started Thu Sep 15 19:01:19 2016 UTC.  The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot.
2172016-09-15T19:01:19  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2182016-09-15T19:01:28  <jonasschnelli> topic proposals?
2192016-09-15T19:01:46  <MarcoFalke> proposed short topic: EOL 0.11
2202016-09-15T19:02:11  <jonasschnelli> #topic EOL 0.11
2212016-09-15T19:02:18  <cfields_> I'll only be around for ~30 min before I have to head out.
2222016-09-15T19:02:29  <MarcoFalke> #link https://github.com/bitcoin-core/bitcoincore.org/pull/211
2232016-09-15T19:02:37  <wumpus> if we're following the same schedule as usual, 0.11 was EOL at the moment 0.13 was released
2242016-09-15T19:02:47  <sipa> except critical fixes?
2252016-09-15T19:02:50  <jonasschnelli> agree with wumpus
2262016-09-15T19:03:02  <MarcoFalke> it is about critical fixes
2272016-09-15T19:03:03  <wumpus> security problems may be an exception
2282016-09-15T19:03:22  <MarcoFalke> We should set a date when we no longer fix critial issues
2292016-09-15T19:03:29  <gmaxwell> I thought 0.11 was EOL when 0.13 was released, except for whatever exceptions we decide...
2302016-09-15T19:03:33  <jeremyrubin> nheren
2312016-09-15T19:03:33  <wumpus> but usually no new executables will be built, just simple backports
2322016-09-15T19:03:35  <sipa> gmaxwell: agree
2332016-09-15T19:03:53  <petertodd> ack EOL; you can always run 0.11 behind a 0.13 node if you need too
2342016-09-15T19:03:59  <sipa> so we need to get https://bitcoincore.org/en/lifecycle/ updated?
2352016-09-15T19:04:07  <kanzure> i think the concern was that 0.11 was not marked as EOL, not that it wasn't considered EOL.
2362016-09-15T19:04:09  <MarcoFalke> Jup, note that I already changed maintenance end to 2016-08-23
2372016-09-15T19:04:18  <wumpus> yes the bitcoin.org page needs to be updated
2382016-09-15T19:04:31  <wumpus> +Core
2392016-09-15T19:04:38  <achow101> If 0.11 is EOL, then what about 0.10?
2402016-09-15T19:04:48  <sipa> ah, so 0.11 is not EOL but maintenance end
2412016-09-15T19:04:59  <sipa> EOL means not even security critical backports
2422016-09-15T19:05:04  <sipa> according to that website
2432016-09-15T19:05:07  <gmaxwell> achow101: it was unmaintained as of january or so.
2442016-09-15T19:05:28  <achow101> gmaxwell: but it is still marked as receiving critical updates on bitcoincore.org
2452016-09-15T19:05:33  <jonasschnelli> According to bitcoincore.org 0.10 has EOL in 2017
2462016-09-15T19:05:35  <sipa> but 0.10 should be EOL at 2016-08-23
2472016-09-15T19:05:40  <morcos> it seems to me that ending security critical backports depends not just on how old the release is but on how many people are still using it
2482016-09-15T19:05:50  <gmaxwell> what morcos says.
2492016-09-15T19:05:54  <wumpus> and how difficult it is to backport/test
2502016-09-15T19:06:00  <morcos> ha ha, of course!
2512016-09-15T19:06:08  <wumpus> I mean if it's just updating a dependency library like upnp...
2522016-09-15T19:06:17  <gmaxwell> the reality is that it has nothing to do with dates. We're not actively seeking to maintain these versions but will do what it takes to protect the ecosystem.
2532016-09-15T19:06:19  <sipa> sure, but the reason for having a clearly stated policy is so that people can make informed decisions about what to run
2542016-09-15T19:06:26  <MarcoFalke> ^
2552016-09-15T19:06:47  <wumpus> I think this will always be a discussion people can't really agree on
2562016-09-15T19:06:48  <MarcoFalke> We should communicate the EOL in advance
2572016-09-15T19:06:51  <luke-jr> frankly 0.12 seems like EOL before 0.14 at this rate
2582016-09-15T19:06:56  <petertodd> gmaxwell: setting expectations also can help protect the ecosystem
2592016-09-15T19:07:07  <gmaxwell> We also continue to see no feedback from parties that would prefer to use a 0.old.next over a 0.new.hottness. :)
2602016-09-15T19:07:08  *** cryptapus has joined #bitcoin-core-dev
2612016-09-15T19:07:16  * jonasschnelli still count 569 0.10.x peers with status "good" on his seeder
2622016-09-15T19:07:19  <morcos> agreed with all, but i'm saying we should be supplementing our discussion with #'s of nodes running 0.10, 0.11
2632016-09-15T19:07:23  <sipa> i wish we had more insight in users' needs... that there would be requests of the form "wait! no! i can't upgrade to 0.12 yet for reason X, but we really need updated for now"
2642016-09-15T19:07:24  <wumpus> in practice it's indeed not about dates, but if someone cares about using/maintainging it
2652016-09-15T19:07:27  <BlueMatt> am I the only one who wasnt aware of that page? I mean I dont think a strict N-monghts schedule really works, so we'd need to all be thinking about it/aware of it, at least, to make it reasonable
2662016-09-15T19:07:28  <wumpus> it seems to be 0 people
2672016-09-15T19:07:29  <gmaxwell> Which supports the view that effort spent supporting older versions is of negative value.
2682016-09-15T19:07:45  <luke-jr> wumpus: maintaining it is not practical without testing/usage
2692016-09-15T19:07:51  <petertodd> morcos: so many nodes are run because users "want to contribute" - I wouldn't read too much into that number. Equally, a lot of nodes are likely spy-nodes...
2702016-09-15T19:07:57  <wumpus> luke-jr: right it's a chicken egg problem
2712016-09-15T19:08:00  <sipa> wumpus: that's a fair characterization of reality, but perhaps that page should reflect that
2722016-09-15T19:08:02  <kanzure> BlueMatt: i think it's something like "people should be following the mailing lists and announcement mailing lists and the webpage, although apparently the webpage is out of sync with reality for the moment"
2732016-09-15T19:08:41  *** cdecker has quit IRC
2742016-09-15T19:08:45  <wumpus> yes, updating the webpage to reflect reality would make sense
2752016-09-15T19:08:46  <BlueMatt> kanzure: hmm? people shouldnt have to follow the ml to find out if their node is EOL...we should have some kind of information for users, but devs have to be aware that it exists for it to be accurate :p
2762016-09-15T19:08:50  <gmaxwell> If we were being completely pragmatic we would probably say that we only support the very latest thing put out at all.-- this is all that I can tell people are upgrading to. But I think that is a bad principle and the fact that the only thing people upgrade to is the latest thing is an aspect of industry immaturity which will hopefully go away.
2772016-09-15T19:08:56  <luke-jr> wumpus: I maintained old versions back to 0.4 for years with no indication of real usage or feedback - the first few got some testing, but after a while it never made it past RC
2782016-09-15T19:09:43  <petertodd> fwiw I've never gotten any feedback from python-bitcoinlib users complaining about non-backwards-compatible changes
2792016-09-15T19:09:43  <luke-jr> IMO we *should* have longer support, but it just doesn't seem feasible with softforks
2802016-09-15T19:09:47  <wumpus> the point of creating that webpage was to have an easier available place where release maintenance status was available, but yes if it runs out of date with reality then at some point it's only confusing
2812016-09-15T19:09:50  * BlueMatt wishes there was an "ask the community" button for this kind of thing....
2822016-09-15T19:10:06  <petertodd> BlueMatt: too bad we got rid of the alert system... /ducks
2832016-09-15T19:10:19  <kanzure> wumpus: probably a good fix would be to have a checklist for releases, and add EOL webpage updates to that checklist.
2842016-09-15T19:10:21  <wumpus> and it should reflect how things are, not how we think ideally they should be
2852016-09-15T19:10:28  <sipa> we could make node software automatically show a warning X months after being released...
2862016-09-15T19:10:37  <luke-jr> kanzure: we do have release-process.md
2872016-09-15T19:10:43  <kanzure> well is it in there?
2882016-09-15T19:10:50  <luke-jr> sipa: +1
2892016-09-15T19:10:54  <wumpus> kanzure: there's one in the release process, but there is already so much stuff there. I don't thin kthe assumption should be that the same person does all that
2902016-09-15T19:10:56  *** cdecker has joined #bitcoin-core-dev
2912016-09-15T19:11:06  <kanzure> "EOL" not found in that doc, nor variations of it.
2922016-09-15T19:11:07  <petertodd> sipa: signal does that actually - they forgot the timer expired once and scared a bunch of people
2932016-09-15T19:11:26  <kanzure> wumpus: sure, sure, perhaps it's multiple people. but a checklist can still be helpful regardless of number of people that use it.
2942016-09-15T19:11:29  <BlueMatt> petertodd: is that automated? heh, yea, maybe
2952016-09-15T19:11:48  <achow101> has anyone actually tried asking the community? like posting on reddit, bitcointalk, etc.
2962016-09-15T19:12:08  <luke-jr> petertodd: if we stagnate for 12 months, something else is wrong
2972016-09-15T19:12:19  <wumpus> I think we should first document how things are clearly on the site, and only then worry about maybe changing it
2982016-09-15T19:12:25  <btcdrak> oh sorry I am late
2992016-09-15T19:12:31  <jonasschnelli> The problem is probably not what the community want, its more what the team is capable of delivering
3002016-09-15T19:12:36  <gmaxwell> achow101: we've posted asking for feedback on older versions many times in the past, and also called for testing on old support backups.
3012016-09-15T19:12:37  <wumpus> exactly jonasschnelli
3022016-09-15T19:12:58  <jonasschnelli> Its an OSS, if people want longer EOL, they should contribute
3032016-09-15T19:13:19  <gmaxwell> I've also gone 1:1 to several companies. Mostly we've recieved complete silence. scanning the network (and watching inbounds) also shows that adoption of point releases after a new major is out is basically non-existant.
3042016-09-15T19:13:20  <wumpus> as I've said before I have nothing against maintaining old releases if someone really commits to that
3052016-09-15T19:13:24  <sipa> that's fair... we're only so many people, and review for backports is a significant burden
3062016-09-15T19:13:25  <luke-jr> I'm happy to go back to maintaining stable versions longer if people will actually use it (and can't upgrade)
3072016-09-15T19:13:31  <gmaxwell> jonasschnelli: or at least speak up.
3082016-09-15T19:13:31  <wumpus> but I've never seen much interest, so reality is, it doesn't
3092016-09-15T19:13:38  <kanzure> i don't know what to think about re: automatic warnings after timelapse.   as long a there's some good reason to think it' dissimilar from automatic updates, i suppose..
3102016-09-15T19:13:54  <jonasschnelli> gmaxwell: right.
3112016-09-15T19:13:55  <wumpus> kanzure: I don't know what to think about it either
3122016-09-15T19:13:58  <kanzure> didn't mean to impose on wumpus with the checklist suggestion
3132016-09-15T19:14:09  <luke-jr> maybe update EOL page, and mention the lack of usage as the reason, suggesting if people want it, they should get in touch
3142016-09-15T19:14:17  <jonasschnelli> Luke-Jr: +1
3152016-09-15T19:14:20  <BlueMatt> ok, so lets post something on the ml or so that says "We're gonna stop doing this, but would very much love to hear if anyone actually wants it" and then link to that from reddit/emails/twitter/whatever
3162016-09-15T19:14:27  <BlueMatt> yea, that
3172016-09-15T19:14:29  <gmaxwell> stop doing what?
3182016-09-15T19:14:32  <gmaxwell> I am really confused.
3192016-09-15T19:14:37  <BlueMatt> stop supporting backports
3202016-09-15T19:14:42  <BlueMatt> beyond like one or two versions, maybe
3212016-09-15T19:14:46  <wumpus> kanzure: I really don't like time-locks in programs. Though this would just be a warning I guess... but it could be intimidating
3222016-09-15T19:14:46  <gmaxwell> We have a stated policy, we maintain one major version behind.
3232016-09-15T19:14:47  <luke-jr> gmaxwell: stop promising backports we aren't really doing anyway
3242016-09-15T19:14:55  <gmaxwell> BlueMatt: we already did that, like, a yea ago.
3252016-09-15T19:14:58  <jonasschnelli> stop doing sound negative... something more like "...we are concentrating ressources on X"
3262016-09-15T19:15:01  <gmaxwell> year*
3272016-09-15T19:15:06  <sipa> BlueMatt: "beyond one version" is exactly what the page says
3282016-09-15T19:15:07  <BlueMatt> s/one or two versions/one or so point releases/
3292016-09-15T19:15:15  <luke-jr> wumpus: might be good to make the time limit fuzzy, so not everyone gets hit at the same time
3302016-09-15T19:15:17  <btcdrak> Seems there's a lot of discussion here which was _already)_ covered in previous meetings and is detailed in the Lifecycle document https://bitcoincore.org/en/lifecycle/ tldr maintenance and EOL are two different things.
3312016-09-15T19:15:22  <luke-jr> perhaps 1 year from when it was installed?
3322016-09-15T19:15:25  <gmaxwell> what btcdrak says
3332016-09-15T19:15:28  <BlueMatt> sipa: gmaxwell to be fair, the website doesnt say that
3342016-09-15T19:15:36  <wumpus> well then add it to the website!
3352016-09-15T19:15:42  <wumpus> everyone can submit pulls there you know
3362016-09-15T19:15:45  <btcdrak> I suggest people re-read the Lifecycle page after the meeting :)
3372016-09-15T19:15:57  <wumpus> we can spend an hour discussing what should be added to the website, or just add it
3382016-09-15T19:16:03  <jonasschnelli> #action update Lifecycle page on bitcoincore.org
3392016-09-15T19:16:04  <Chris_Stewart_5> ^
3402016-09-15T19:16:08  <kanzure> luke-jr: cool idea. fuzzy random noise time-delay notifications.  (hopefully nobody proposes "intentionally low performance over time until someone thinks to get a new version")
3412016-09-15T19:16:10  <BlueMatt> ok, next topic
3422016-09-15T19:16:30  <gmaxwell> BlueMatt: read the "Maintance period" section on the site, I think it's completely clear.
3432016-09-15T19:16:32  <wumpus> any other topics?
3442016-09-15T19:16:48  <jonasschnelli> #into hackdays in milan: http://coredev.tech/nextmeeting_tmp.html
3452016-09-15T19:16:56  <wumpus> 0.14 release schedule maybe
3462016-09-15T19:17:00  <jonasschnelli> Its a temporary page.. not public yet. But feel free to register
3472016-09-15T19:17:19  <wumpus> I've posted a proposal for the 0.14 release schedule here: https://github.com/bitcoin/bitcoin/issues/8719
3482016-09-15T19:17:29  <jonasschnelli> #topic 0.14 release schedule
3492016-09-15T19:17:34  <MarcoFalke> sounds fine
3502016-09-15T19:17:44  <sipa> yes, sounds good
3512016-09-15T19:17:49  <jonasschnelli> yes. fine for me
3522016-09-15T19:18:00  <btcdrak> looks good to me
3532016-09-15T19:18:06  <BlueMatt> yea, looks good now
3542016-09-15T19:18:06  <wumpus> I'll mail it around on the mailing lists if there are no issues with it
3552016-09-15T19:18:08  <CodeShark> +1
3562016-09-15T19:18:12  <wumpus> ok great!
3572016-09-15T19:18:15  <kanzure> jonasschnelli: you have a typo in your form ("your are")
3582016-09-15T19:18:33  <morcos> wumpus: my only thought is 0.13.1 release is a bit of a heavy lift, and depending on when that happens, it may seem like 0.14.0 is coming up quite quickly...  but i don't feel strongly about it
3592016-09-15T19:18:34  <jonasschnelli> kanzure: ill give you edit right. :)
3602016-09-15T19:18:56  <wumpus> morcos: it's already a month later compared to 0.12 was this year
3612016-09-15T19:19:13  <MarcoFalke> No worries. I am sure the will be last-minute blockers for 0.14.0
3622016-09-15T19:19:14  <wumpus> morcos: postponsing major releases for minor releases makes very little sense I think
3632016-09-15T19:19:51  <morcos> wumpus: yeah i was only pointing out that 0.13.1 is not minor in a lot of ways..  but if others are fine with it, i don't object
3642016-09-15T19:19:51  <wumpus> 0.14 will have lots of new features, 0.13.1 will not
3652016-09-15T19:20:09  <wumpus> morcos: I agree with that
3662016-09-15T19:20:26  <luke-jr> ? 0.13.1 should only be fixes + softfork
3672016-09-15T19:20:33  <btcdrak> yes.
3682016-09-15T19:20:33  <wumpus> luke-jr: it is
3692016-09-15T19:20:38  <morcos> anyway, seems not its a widely shared concern, so lets stick with the schedule
3702016-09-15T19:20:45  <gmaxwell> having a short gap between releases would be a good problem to have. :)
3712016-09-15T19:20:53  <BlueMatt> yup
3722016-09-15T19:20:55  <jonasschnelli> #topic 0.13.1 release
3732016-09-15T19:21:00  <wumpus> it's a minor release strictly, just a lot of code changes, so you can jokingly call it 'major'
3742016-09-15T19:21:14  <btcdrak> Here are the remaining PRs and issues for 0.13.1 https://github.com/bitcoin/bitcoin/milestone/22
3752016-09-15T19:21:22  <btcdrak> #link https://github.com/bitcoin/bitcoin/milestone/22
3762016-09-15T19:21:42  <sdaftuar> i wanted to suggest that we consider dropping some of those PRs from the 0.13.1 milestone
3772016-09-15T19:21:54  <btcdrak> sdaftuar which in particular?
3782016-09-15T19:21:55  <wumpus> sdaftuar: specific suggestions?
3792016-09-15T19:22:15  <BlueMatt> nulldummy as softfork?
3802016-09-15T19:22:16  <sdaftuar> 8654 is one
3812016-09-15T19:22:20  <kanzure> was there a mempool issue still open for 0.13.1.. don't see it listed there.
3822016-09-15T19:22:24  <BlueMatt> I figure I'd get yelled at, but I'm not convinced
3832016-09-15T19:22:25  <CodeShark> Is the mempool dos thing still urgent?
3842016-09-15T19:22:27  <kanzure> ah there it is.
3852016-09-15T19:22:27  <sdaftuar> that's a performance optimization that i think is not urgent
3862016-09-15T19:22:35  <kanzure> (8279)
3872016-09-15T19:22:39  <btcdrak> I recall sipa saying #8635 may not be essential for 0.13.1
3882016-09-15T19:22:46  <luke-jr> I reviewed a few merged fixes and commented on a few that they should be backported. Did someone with tagging access get to tag those?
3892016-09-15T19:23:13  <jonasschnelli> Luke-Jr: I'll have a look
3902016-09-15T19:23:16  <MarcoFalke> luke-jr: I think I did
3912016-09-15T19:23:22  <jl2012> i think #8635 may be dropped for 0.13.1
3922016-09-15T19:23:36  <sipa> agree
3932016-09-15T19:23:44  <jonasschnelli> jl2012: what do you think about https://github.com/bitcoin/bitcoin/pull/8654?
3942016-09-15T19:23:46  <btcdrak> ok let's untag it
3952016-09-15T19:23:56  <sipa> i'd like to see 8654 in
3962016-09-15T19:23:57  <btcdrak> *untag 8635
3972016-09-15T19:24:09  <luke-jr> ACK dropping 8635 for 0.13.1
3982016-09-15T19:24:20  <btcdrak> I guess the big blocker is #8393 compact blocks.
3992016-09-15T19:24:21  <jonasschnelli> untagged
4002016-09-15T19:24:45  <wumpus> #decision dropped #8635 for 0.13.1
4012016-09-15T19:24:51  <luke-jr> jonasschnelli: if that's strictly an optimisation, it should wait for 0.14
4022016-09-15T19:25:12  <jonasschnelli> sipa: why did you want to see 8654 in 0.13.1?
4032016-09-15T19:25:15  <wumpus> luke-jr: depends on whether it's an optimisation or an 'optimisation' (e.g. - DoS fix)
4042016-09-15T19:25:22  <gmaxwell> btcdrak: thats ... working fine for me, but we probably need to do a bit more organized testing. sdaftuar was updating some tests for it.
4052016-09-15T19:25:27  <luke-jr> wumpus: right, hence "if" ☺
4062016-09-15T19:25:49  <btcdrak> gmaxwell: well it's fine to merge afaik, but there was some discussion about the BIP text which is blocking it afaik
4072016-09-15T19:26:06  <btcdrak> I think #8636 is ok to merge.
4082016-09-15T19:26:37  <wumpus> that has a lot of ACKs
4092016-09-15T19:26:40  <michagogo> Hi
4102016-09-15T19:26:48  <wumpus> #action merge #8636
4112016-09-15T19:26:53  <wumpus> michagogo: hey!
4122016-09-15T19:27:00  <gmaxwell> Can someone make a list of all PR's merged for master that are not in 0.13 so we can check to make sure we haven't missed any that need backport?
4132016-09-15T19:27:10  * BlueMatt isnt a huge fan of 8636 in 0.13.1
4142016-09-15T19:27:11  <morcos> oh i was going to vote against 8636 as well
4152016-09-15T19:27:25  <morcos> i haven't reviewed it and don't necessarily have any concrete concerns
4162016-09-15T19:27:29  <wumpus> gmaxwell: all that still need backport should have the 'needs backport' tag
4172016-09-15T19:27:35  <wumpus> https://github.com/bitcoin/bitcoin/labels/Needs%20backport
4182016-09-15T19:27:42  <BlueMatt> its just more stuff for segwit that could easily fit in another softfork
4192016-09-15T19:27:46  <michagogo> Sorry, not too around -- was with my grandmother (my grandfather passed away on Sunday), and now shopping with the family.
4202016-09-15T19:27:48  <gmaxwell> assuming they got tagged.
4212016-09-15T19:27:53  <BlueMatt> better to push any more complication further
4222016-09-15T19:27:54  <luke-jr> gmaxwell: I did, but I may have missed some. (minor ones I didn't comment on, and have a local list I can backport myself)
4232016-09-15T19:27:55  <wumpus> (including what is already merged)
4242016-09-15T19:27:56  <morcos> but just seems it possibly hasn't been thought about enough to know there isn't a hidden risk like jl2012 found low-s
4252016-09-15T19:28:08  <gmaxwell> it's an istandardness rule
4262016-09-15T19:28:11  * michagogo wonders if zu will become the new 11
4272016-09-15T19:28:20  <btcdrak> morcos: it's already a standard rule
4282016-09-15T19:28:21  <gmaxwell> oh you're talkign about nulldummy sorry.
4292016-09-15T19:28:47  <BlueMatt> gmaxwell: yea, sorry, nulldummy...I'm more ok with adding standard rules for things we want to softfork out soon
4302016-09-15T19:28:53  <wumpus> michagogo:  hah, luckily the C parser doesn't accept it as number
4312016-09-15T19:29:20  <wumpus> otherwise some magic constants should be defined as zuzuzuzu, especially on windows
4322016-09-15T19:29:56  <jl2012> #8499 actually somehow depends on nulldummy softfork
4332016-09-15T19:29:58  <luke-jr> #define zu 11
4342016-09-15T19:30:08  <luke-jr> fixed C parser
4352016-09-15T19:30:20  <jl2012> it still works, just can't protect CHECKMULTISIG
4362016-09-15T19:30:20  <morcos> re: nulldummy, ok so if we think its got sufficient technical review, and we also think its technical enough it doesn't need more community discussion (for instance never appears in chain?) then ok wiht me
4372016-09-15T19:30:41  <sipa> i think the risk for nulldummy is very low
4382016-09-15T19:30:46  <petertodd> nulldummy is very, very simple
4392016-09-15T19:30:51  <jl2012> since without a softfork, we can't DoS ban a peer sending us a violating transaction
4402016-09-15T19:31:16  <sipa> jl2012: well we can't generally do that anyway
4412016-09-15T19:31:32  <sipa> an attacker node can always pretend to be an old version
4422016-09-15T19:31:37  <jl2012> for segwit tx we could
4432016-09-15T19:31:39  <gmaxwell> we could for Sw things however, as it doesn't have transisiton issue.
4442016-09-15T19:31:39  <cfields_> crap, gtg. wumpus: not a meeting topic, but I noticed that the libevent unit tests fail for the zu case. We should consider running unit tests for deps somewhere.
4452016-09-15T19:31:44  <cfields_> bbl
4462016-09-15T19:31:44  <jl2012> 8499 is for segwit only
4472016-09-15T19:31:48  <luke-jr> sipa: if it's bundled with segwit I think we can?
4482016-09-15T19:31:56  <gmaxwell> But we could ban without the softfork in such a case too.
4492016-09-15T19:32:02  <sipa> luke-jr: an old node can always pretend to be pre-segwit
4502016-09-15T19:32:11  <gmaxwell> There is no need to link those behaviors though we have previously.
4512016-09-15T19:32:13  <wumpus> cfields_: yes did you see https://github.com/bitcoin/bitcoin/pull/8730?
4522016-09-15T19:32:22  <luke-jr> but then it won't have witness data at all
4532016-09-15T19:32:30  *** Guyver2 has joined #bitcoin-core-dev
4542016-09-15T19:32:40  <wumpus> cfields_: running libevent tests would make some sense, yes, although we'd first need a travis run on ubuntu 16.04
4552016-09-15T19:32:46  <sipa> luke-jr: so? it's an attacker node. it just won't send segwit txn
4562016-09-15T19:32:54  <cfields_> wumpus: yes, I'm still making my way through that problem.
4572016-09-15T19:32:55  <sipa> it can make up all its transactions
4582016-09-15T19:33:00  <gmaxwell> in any case, I only think that its urgent to at least have these behaviors non-standard.
4592016-09-15T19:33:01  <cfields_> wumpus: indeed, it was just a general thought
4602016-09-15T19:33:21  <luke-jr> sipa: afaik the proposal is to ban Nulldummy-violating sw txns
4612016-09-15T19:33:37  <sipa> luke-jr: to ban nulldummy-violation sw *peers*
4622016-09-15T19:33:50  <sipa> so an attacker will just not be an sw peer
4632016-09-15T19:33:53  <wumpus> cfields_: at least that one's easy to fix, the -stack-protector-all problem is more worrying
4642016-09-15T19:34:21  <wumpus> cfields_: anyhw better to speak of this outside the meeting some time
4652016-09-15T19:34:24  <jl2012> sipa: I think it's to ban segwit-nulldummy-violation peers
4662016-09-15T19:34:37  <sipa> jl2012: ok
4672016-09-15T19:34:39  <morcos> too many conversations
4682016-09-15T19:34:41  <sipa> same thing
4692016-09-15T19:34:43  <sipa> morcos: agree
4702016-09-15T19:34:47  <luke-jr> well, whether it's useful or not is another matter - maybe it isn't
4712016-09-15T19:34:49  <sipa> what is the topic?
4722016-09-15T19:34:55  <jonasschnelli> 0.13.1
4732016-09-15T19:34:57  <morcos> in summary i'm happy to let you guys decide what should go into 0.13.1 and what shouldn't, as i have been a bit out of the loop
4742016-09-15T19:34:59  <jonasschnelli> (nulldummy)
4752016-09-15T19:35:03  <wumpus> 0.13.1 still
4762016-09-15T19:35:13  <morcos> however i just want to raise the concern that maybe we're putting a lot of things in very quickly at the end
4772016-09-15T19:35:18  <gmaxwell> welcome back
4782016-09-15T19:35:18  <morcos> and that should cause us to be nervous
4792016-09-15T19:35:22  <sipa> i think nulldummy is very low risk, but also not very useful
4802016-09-15T19:35:23  <gmaxwell> :)
4812016-09-15T19:35:39  <morcos> when already the segwit activation is going to be a lot to pay attention to
4822016-09-15T19:35:42  <BlueMatt> 0.13.1 - various things...I think morcos, sdaftuar and I generally arent a fan of all these policy and various things coming in last minute before 0.13.1, but, I think we've all been out of the loop so maybe they have more review than we think
4832016-09-15T19:35:44  <sipa> it should happen at some point, and perhaps doing it together with segwit is easier
4842016-09-15T19:35:51  <btcdrak> morcos: in all fairness, these PRs have been worked on over quite a long time.. they arent out of the blue.
4852016-09-15T19:36:01  <BlueMatt> maybe nulldummy is ok, but still, so many things happening at the same time is a review burden and complicates things further
4862016-09-15T19:36:02  <btcdrak> you need to sync up on the conversations / background of them
4872016-09-15T19:36:03  <sipa> BlueMatt: yes, i don't like that either, but i think we just discovered many things to improve
4882016-09-15T19:36:06  <BlueMatt> when segwit is already complicated
4892016-09-15T19:36:13  <BlueMatt> sipa: ok, lets do it in a later sf
4902016-09-15T19:36:13  <BlueMatt> ?
4912016-09-15T19:36:26  <BlueMatt> i mean sf-able things, that is
4922016-09-15T19:36:38  <gmaxwell> it's unclear whats being discussed now.
4932016-09-15T19:36:39  <BlueMatt> and maybe if policy isnt as restrictive as we'd like in 0.13.1, thats ok
4942016-09-15T19:36:42  <sipa> nulldummy sf
4952016-09-15T19:37:29  <btcdrak> the only sf is nulldummy, the rest is just policy standardness.
4962016-09-15T19:37:36  <jonasschnelli> Didn't we had this discussion already and where mostly for including nulldummy sf together with SW in 0.13.1?
4972016-09-15T19:37:40  <gmaxwell> bluematt is talking about many, if the discussion is limited to nulldummy whatever.
4982016-09-15T19:38:01  <gmaxwell> But the policy changes are more important.
4992016-09-15T19:38:03  <wumpus> yes I think trying to stash a lot of changes into 0.13.1 has caused some delays already, at the least we shouldn't be adding anything else now and focus on what is there getting in
5002016-09-15T19:38:10  <gmaxwell> jonasschnelli: yes, we did.
5012016-09-15T19:38:30  <luke-jr> IMO nulldummy isn't worth all the time we're spending disucssing it now.
5022016-09-15T19:38:41  <jonasschnelli> https://bitcoincore.org/en/meetings/2016/09/01/#nulldummy-and-lows-softfork-proposals
5032016-09-15T19:38:47  <Chris_Stewart_5> Do we have a tentative release date for 0.13.1 or feature freeze?
5042016-09-15T19:38:53  <gmaxwell> wumpus: that isn't what happened. We had specific necessary to fix issues related to SW specific moderate risk denial of service attacks, and the path to fixing them spun off a number of sub isues along the way.
5052016-09-15T19:38:55  <wumpus> if you discover any other nice improvements they can wait until next version, unless it's critical to deployment of segwit
5062016-09-15T19:38:57  <jonasschnelli> cfields_: no
5072016-09-15T19:39:01  <jonasschnelli> Chris_Stewart_5: no
5082016-09-15T19:39:15  <gmaxwell> It's a little frustrating to loop rediscussing the same things over again. Makes the meetings feel like a waste of time, FWIW.
5092016-09-15T19:39:21  <wumpus> gmaxwell: agreed
5102016-09-15T19:39:30  <wumpus> there are a lot of repeated topics lately
5112016-09-15T19:39:31  <jonasschnelli> agree with gmaxwell
5122016-09-15T19:39:50  <jonasschnelli> (which is mostly a sign of not made decistions)
5132016-09-15T19:39:50  <wumpus> e.g. people that have been out of the loop then bring up something that was discussed a meeting or a few meetings ago
5142016-09-15T19:39:56  <wumpus> meetings are not there to bring you up to speed
5152016-09-15T19:40:18  <btcdrak> we publish meeting summaries, people should be reading them :-p
5162016-09-15T19:40:26  <wumpus> the logs and minutes are available, and summaries are made and published on the site
5172016-09-15T19:40:41  <gmaxwell> okay, thats enough probably. :) people get the point.
5182016-09-15T19:40:44  <wumpus> and you can always ask about things outside the meeting
5192016-09-15T19:40:57  <gmaxwell> (I am glad to not be alone!)
5202016-09-15T19:40:58  <BlueMatt> wumpus: IIRC there are folks complaining now who were in favor of it, as there are now 5 related issues that are coming up.....8634, eg, was not previously discussed and is in the same veign
5212016-09-15T19:41:03  <BlueMatt> maybe that should be the next topic
5222016-09-15T19:41:41  <BlueMatt> otherwise, someone can propose a different topic :)
5232016-09-15T19:41:47  <wumpus> BlueMatt: yes, I'm not saying it should be impossible to reconsider things discussed in previous meetings if convinng new reasons come up! just that repeating the same discussions with the same outcomes is not constructive
5242016-09-15T19:41:49  <gmaxwell> BlueMatt: thats fine, things can be rediscussed again, but instead of repeating the discussion we should focus on whats changed or whats disagreed with.. a diff rather than a redo.
5252016-09-15T19:41:58  <btcdrak> We need some more ACKs on #8634 and #8499 and #8526
5262016-09-15T19:42:04  <wumpus> yes
5272016-09-15T19:42:12  <wumpus> #action review #8634 and #8499 and #8526
5282016-09-15T19:42:42  <sipa> it's not clear what is being discussed. if we're talking about nulldummy sf, i think there is little risk, but little benefit. it was discussed before however, and unless people strongly feel that everything being done is too much, then this is something that can be reconsidered. please don't start reconsidering everything. there are good reasons and they were discussed before
5292016-09-15T19:42:43  <btcdrak> then the compact block/BIP thing needs to be finalised so we can merge the compact block pull #8393
5302016-09-15T19:43:04  <BlueMatt> sipa: eg, btcdrak just pointed out three prs...two of which i think are optional in 0.13.1
5312016-09-15T19:43:06  <BlueMatt> as is nulldummy
5322016-09-15T19:43:24  <BlueMatt> now we're in a position where we have a at least 3 prs that are "optional", at least one or two has been previously agreed upon
5332016-09-15T19:43:33  <wumpus> nulldummy softwork has been discussed zillions of times in the meeting, everytime the sentiment was slightly in favor of doing it because it has very little risk
5342016-09-15T19:43:34  <btcdrak> sipa: it's been well reviewed, and run on testnet for 4 weeks already.
5352016-09-15T19:43:41  <BlueMatt> but we want to get this thing out the door without spreading ourselves thin over too much review
5362016-09-15T19:43:49  <wumpus> and by now it has lots of testing and review too
5372016-09-15T19:43:51  <btcdrak> can we move on?
5382016-09-15T19:43:51  <sipa> so let's just stick to it
5392016-09-15T19:43:58  <wumpus> so if you want to reconsider it have a very good reason
5402016-09-15T19:44:04  <wumpus> not just 'I personally don't like it very much'
5412016-09-15T19:44:07  <BlueMatt> btcdrak: "run on testnet for 4 weeks" is the opposite of "good testing"
5422016-09-15T19:44:08  <gmaxwell> fwiw, all of my testing lately has been with most of this stack applied.
5432016-09-15T19:44:26  <btcdrak> BlueMatt: it's completely trivial, come on.
5442016-09-15T19:44:47  <wumpus> topc nulldummy is over now
5452016-09-15T19:44:50  <btcdrak> Is there any thing I can do regarding CB, I'm sort of confused about what is holding it up?
5462016-09-15T19:44:55  <wumpus> other topic proposals?
5472016-09-15T19:45:00  <sipa> segwit cb?
5482016-09-15T19:45:05  <btcdrak> yes please
5492016-09-15T19:45:14  <wumpus> #topic segwit cb
5502016-09-15T19:45:18  <gmaxwell> yes, I'm also unsure what else is required. I have been testing.
5512016-09-15T19:45:24  <sipa> gmaxwell: the latest version?
5522016-09-15T19:45:30  <sdaftuar> i'm working on testing.  i foudn a bunch of problems with the test unfortunately :(
5532016-09-15T19:45:31  <sipa> (as of a few days ago)
5542016-09-15T19:45:47  <BlueMatt> it was updated a few days ago, afaik only sdaftuar has looked at it since
5552016-09-15T19:45:48  *** cdecker has quit IRC
5562016-09-15T19:45:54  <sipa> i did
5572016-09-15T19:45:57  <morcos> i like the concept of the latest version, and looked at the code.  but unfortunately i have to review CB in the first place before i can review the pull, so thats what i'm doing
5582016-09-15T19:46:04  <BlueMatt> and sdaftuar is now rewriting the testers for it, so not much to talk about aside from people should look at it?
5592016-09-15T19:46:09  <gmaxwell> sipa: as of a week ago? I could check.
5602016-09-15T19:46:34  <morcos> not to say you need to wait for my review of course
5612016-09-15T19:46:35  <sipa> gmaxwell: 2 days ago
5622016-09-15T19:47:55  <BlueMatt> next topic?
5632016-09-15T19:48:12  <gmaxwell> (Fwiw, more segwit traffic on testnet would make live testing of that PR more useful)
5642016-09-15T19:48:27  <luke-jr> gmaxwell: where did you guys go btw?
5652016-09-15T19:48:35  <gmaxwell> luke-jr: to the photo room.
5662016-09-15T19:48:37  <btcdrak> gmaxwell: roasbeef is preparing to produce some load in the next day
5672016-09-15T19:48:56  <gmaxwell> btcdrak: okay, I'll try to get things updated to the latest first.
5682016-09-15T19:49:53  *** laurentmt has joined #bitcoin-core-dev
5692016-09-15T19:49:58  <jonasschnelli> any other topics?
5702016-09-15T19:50:10  <sipa> specifically it would be useful to test connections between 0.13-with-segwit-activation-removed testnet nodes with #8393
5712016-09-15T19:50:24  <sdaftuar> sipa: i'm also working on doing that in regtest, fyi
5722016-09-15T19:50:32  <sipa> awesome
5732016-09-15T19:50:34  <btcdrak> great
5742016-09-15T19:50:40  <gmaxwell> sipa: okay, I'll make sure that I run with that too.
5752016-09-15T19:50:52  <sipa> thanks
5762016-09-15T19:51:37  <luke-jr> would be handy to have some regular segwit spam on testnet in general IMO
5772016-09-15T19:51:56  <btcdrak> luke-jr: it's coming, roasbeef is setting something up
5782016-09-15T19:52:08  *** laurentmt has quit IRC
5792016-09-15T19:53:02  <btcdrak> *silence*
5802016-09-15T19:53:41  <jonasschnelli> #endmeeting
5812016-09-15T19:53:41  <lightningbot> Meeting ended Thu Sep 15 19:53:41 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5822016-09-15T19:53:41  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-15-19.01.html
5832016-09-15T19:53:41  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-15-19.01.txt
5842016-09-15T19:53:41  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-15-19.01.log.html
5852016-09-15T19:55:49  * btcdrak looks around
5862016-09-15T19:56:03  <btcdrak> I think I entered the twilight zone
5872016-09-15T19:56:04  * sipa hands btcdrak a handful of crickets
5882016-09-15T19:56:12  <btcdrak> XD
5892016-09-15T19:56:48  * petertodd hands btcdrak a cricket of handfuls
5902016-09-15T19:56:49  <jonasschnelli> Well,... everyone went reviewing the 0.13.1 PRs
5912016-09-15T19:57:14  * btcdrak beer
5922016-09-15T19:57:20  <petertodd> jonasschnelli: and I released OpenTimestamps earlier today, and have been up all night :) https://petertodd.org/2016/opentimestamps-announcement
5932016-09-15T19:57:31  <jonasschnelli> Saw that! Nice job btw!
5942016-09-15T19:57:38  * sipa hands petertodd a giveful of btcdraks
5952016-09-15T19:57:39  <petertodd> thanks!
5962016-09-15T19:58:02  <petertodd> jonasschnelli: gonna (hopefully!) have a blog post tomorrow morning about the git commit timestamping it does as well
5972016-09-15T19:58:40  <petertodd> sipa: "hands.... hands everywhere...."
5982016-09-15T19:58:51  <jonasschnelli> petertodd: Yes. I think a "non-technical" description of the possibilities would be nice
5992016-09-15T19:59:30  <petertodd> jonasschnelli: I've actually written up (most) of that post already: https://github.com/opentimestamps/opentimestamps-client/blob/master/doc/git-integration.md
6002016-09-15T19:59:59  <petertodd> jonasschnelli: a step-by-step example of a case where you could use it (e.g. sipa's key compromise) would be good though
6012016-09-15T20:01:12  <jonasschnelli> petertodd: your git sig time-stamping is very clever...
6022016-09-15T20:02:33  <petertodd> jonasschnelli: yeah, that's a fun hack! I noticed it was possible awhile back, and made a demo of a PGP-signed git commit with signatures from Isis Lovecruft and myself on one commit :)
6032016-09-15T20:02:48  <petertodd> jonasschnelli: unfortunately, github shows those sigs as "unverified", but that's a minor problem
6042016-09-15T20:03:12  <jonasschnelli> Yes. The github-verified icon is nice. But does not prove anything. :)
6052016-09-15T20:03:27  <roasbeef> re testnet segwit spam: would help if we could get more segwit enabled hashpower on testnet and to get those currently mining to limit by max weight (4mil) instead of stripped size
6062016-09-15T20:03:44  <petertodd> jonasschnelli: well, if you trust github...
6072016-09-15T20:03:48  <roasbeef> err I mean regular size
6082016-09-15T20:04:43  <sipa> jonasschnelli: sure it does. as long as you trust github and the companies hosting their hardware.
6092016-09-15T20:04:46  <sipa> if.
6102016-09-15T20:04:52  <jonasschnelli> kanzure: I gave you edit right on https://docs.google.com/forms/d/1HbJecbEN62r8sL2H0nBjlznmJEa1VDCR_FWC76-qEvo/edit
6112016-09-15T20:04:57  <jonasschnelli> Thanks for fixing the typos. :)
6122016-09-15T20:05:03  <kanzure> oh.
6132016-09-15T20:05:43  <jonasschnelli> sipa: Yes. And probably trust all your browser plugins. :)
6142016-09-15T20:06:13  <jonasschnelli> I guess github.com does not include any third-party CDN-ish CSS/JS files..
6152016-09-15T20:06:15  <sipa> yes, and you c library, X server, kernel, cpu, motherboard manufacturer, delivery company, ...
6162016-09-15T20:06:23  <jonasschnelli> okay. stop. :)
6172016-09-15T20:07:31  <btcdrak> roasbeef: will pass it on
6182016-09-15T20:07:38  <sipa> (but admittedly, the browser is the easiest target of all of those)
6192016-09-15T20:07:48  <luke-jr> sipa: ping
6202016-09-15T20:08:05  <sipa> luke-jr: pung
6212016-09-15T20:17:51  *** cdecker has joined #bitcoin-core-dev
6222016-09-15T20:39:45  *** aalex has quit IRC
6232016-09-15T20:40:41  *** cdecker has quit IRC
6242016-09-15T20:47:45  *** aalex has joined #bitcoin-core-dev
6252016-09-15T20:50:40  <phantomcircuit> jonasschnelli: just the newline?
6262016-09-15T21:18:06  *** cryptapus has quit IRC
6272016-09-15T21:48:03  *** lightningbot has joined #bitcoin-core-dev
6282016-09-15T21:48:18  *** sipa has joined #bitcoin-core-dev
6292016-09-15T21:48:53  *** helo has joined #bitcoin-core-dev
6302016-09-15T21:50:20  *** mappum has joined #bitcoin-core-dev
6312016-09-15T21:50:26  *** mjdecour has joined #bitcoin-core-dev
6322016-09-15T21:51:34  *** CyrusV has joined #bitcoin-core-dev
6332016-09-15T21:51:55  *** lesderid has joined #bitcoin-core-dev
6342016-09-15T21:51:59  *** Lightsword has joined #bitcoin-core-dev
6352016-09-15T21:52:05  *** TD-Linux has joined #bitcoin-core-dev
6362016-09-15T21:52:18  *** GreenIsMyPepper has joined #bitcoin-core-dev
6372016-09-15T21:52:40  *** jonasschnelli has joined #bitcoin-core-dev
6382016-09-15T21:54:12  *** cdecker has joined #bitcoin-core-dev
6392016-09-15T21:55:11  *** aalex has quit IRC
6402016-09-15T22:00:55  <gmaxwell> would it be unreasonable for us to keep a bitcoin-core keyring file that has the pgp keys of all the regulars around here in it?
6412016-09-15T22:09:15  *** cdecker has quit IRC
6422016-09-15T22:15:29  *** MarcoFalke has left #bitcoin-core-dev
6432016-09-15T22:20:05  <BlueMatt> argh ffs...can we all agree to not use github's fancy new review mode thing? it seems to be breaking github's emails as they are no longer threaded together for a single issue...hopefully they can fix in a day or two but they really broke my bitcoin-email workflow :(
6442016-09-15T22:20:25  <BlueMatt> damn github and their not always working perfectly :(
6452016-09-15T22:20:41  <BlueMatt> gmaxwell: https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-keys
6462016-09-15T22:20:45  <BlueMatt> we already have that :)
6472016-09-15T22:21:14  <gmaxwell> thats gitian, and doesn't include things like morcos' key.
6482016-09-15T22:21:38  <midnightmagic> mine's not in there either.
6492016-09-15T22:21:39  <BlueMatt> it doesnt include morcos' key because he had +/- never used it until a few days ago...
6502016-09-15T22:21:46  <BlueMatt> I had to push his to the keyserver for him :(
6512016-09-15T22:22:07  <BlueMatt> gmaxwell: but, I dont see why we shouldnt just include everyone there, whether the folder is renamed from gitian or not :)
6522016-09-15T22:22:15  <gmaxwell> right.
6532016-09-15T22:22:56  <btcdrak> seems about right.
6542016-09-15T22:23:47  <BlueMatt> oh, it doesnt have you there, gmaxwell :'(
6552016-09-15T22:24:01  *** jnewbery has joined #bitcoin-core-dev
6562016-09-15T22:28:46  <luke-jr> BlueMatt: is there an issue for this on GitHub?
6572016-09-15T22:28:47  *** cdecker has joined #bitcoin-core-dev
6582016-09-15T22:29:16  <BlueMatt> luke-jr: dunno, I emailed their support@ alias that has been responsive to me in the past
6592016-09-15T22:30:45  *** jnewbery has quit IRC
6602016-09-15T23:03:56  *** Chris_Stewart_5 has quit IRC
6612016-09-15T23:18:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6622016-09-15T23:19:31  *** Guyver2 has quit IRC
6632016-09-15T23:37:49  *** adiabat has quit IRC
6642016-09-15T23:55:38  *** cdecker has quit IRC