12016-03-10T00:15:56 *** zooko has joined #bitcoin-core-dev
22016-03-10T00:25:11 *** ghtdak has joined #bitcoin-core-dev
32016-03-10T00:34:22 *** arowser has quit IRC
42016-03-10T00:34:53 *** arowser has joined #bitcoin-core-dev
52016-03-10T00:38:54 *** Don_John has joined #bitcoin-core-dev
62016-03-10T00:43:56 *** anchow101 has joined #bitcoin-core-dev
72016-03-10T00:44:36 *** frankenmint has joined #bitcoin-core-dev
82016-03-10T00:45:07 *** Arnavion has quit IRC
92016-03-10T00:45:11 *** Arnavion3 has joined #bitcoin-core-dev
102016-03-10T00:45:15 *** Arnavion3 is now known as Arnavion
112016-03-10T00:45:43 *** jl2012_ has joined #bitcoin-core-dev
122016-03-10T00:45:43 *** ibrightly_ has joined #bitcoin-core-dev
132016-03-10T00:49:08 *** Alopex has quit IRC
142016-03-10T00:49:08 *** jl2012 has quit IRC
152016-03-10T00:49:08 *** ibrightly has quit IRC
162016-03-10T00:49:08 *** aknix has quit IRC
172016-03-10T00:49:08 *** achow101 has quit IRC
182016-03-10T00:49:08 *** cfields has quit IRC
192016-03-10T00:49:09 *** cfields_ has joined #bitcoin-core-dev
202016-03-10T00:49:10 *** jl2012_ is now known as jl2012
212016-03-10T00:49:16 *** ibrightly_ is now known as ibrightly
222016-03-10T00:50:39 *** aknix has joined #bitcoin-core-dev
232016-03-10T00:54:09 *** Alopex has joined #bitcoin-core-dev
242016-03-10T01:12:10 *** Don_John has joined #bitcoin-core-dev
252016-03-10T01:17:31 *** Arnavion has quit IRC
262016-03-10T01:17:40 *** Arnavion has joined #bitcoin-core-dev
272016-03-10T01:19:59 *** grassass has quit IRC
282016-03-10T01:22:22 *** fengling has joined #bitcoin-core-dev
292016-03-10T01:35:41 *** zooko has quit IRC
302016-03-10T02:00:58 *** Ylbam has quit IRC
312016-03-10T02:12:48 *** Giszmo has quit IRC
322016-03-10T02:12:55 *** Giszmo has joined #bitcoin-core-dev
332016-03-10T02:32:24 *** belcher has quit IRC
342016-03-10T02:44:22 *** zooko has joined #bitcoin-core-dev
352016-03-10T02:45:09 *** justanotheruser has quit IRC
362016-03-10T02:46:30 *** justanotheruser has joined #bitcoin-core-dev
372016-03-10T02:58:49 *** zooko has quit IRC
382016-03-10T03:00:09 *** wallet42 has joined #bitcoin-core-dev
392016-03-10T03:21:28 *** murr4y has quit IRC
402016-03-10T03:21:58 *** AtashiCon has quit IRC
412016-03-10T03:23:14 *** murr4y has joined #bitcoin-core-dev
422016-03-10T03:23:22 *** p15 has joined #bitcoin-core-dev
432016-03-10T03:26:37 *** frankenmint has quit IRC
442016-03-10T03:27:14 *** p15 has quit IRC
452016-03-10T03:27:27 *** p15 has joined #bitcoin-core-dev
462016-03-10T03:33:01 *** Alopex has quit IRC
472016-03-10T03:34:06 *** Alopex has joined #bitcoin-core-dev
482016-03-10T03:37:16 *** anchow101 has quit IRC
492016-03-10T03:43:14 *** mrkent has joined #bitcoin-core-dev
502016-03-10T03:55:55 <GitHub50> [bitcoin] jtimon opened pull request #7665: Contrib: Introduce script to tag compiled binaries for convenience (py) (master...0.12.99-contrib-tag) https://github.com/bitcoin/bitcoin/pull/7665
512016-03-10T04:12:43 *** frankenmint has joined #bitcoin-core-dev
522016-03-10T04:14:20 *** AtashiCon has joined #bitcoin-core-dev
532016-03-10T04:14:29 *** AtashiCon has quit IRC
542016-03-10T04:20:20 *** AtashiCon has joined #bitcoin-core-dev
552016-03-10T04:32:49 *** murr4y has quit IRC
562016-03-10T04:43:33 *** Cory has quit IRC
572016-03-10T04:43:34 *** Chris_Stewart_5 has quit IRC
582016-03-10T04:44:41 *** Pasha has joined #bitcoin-core-dev
592016-03-10T04:51:34 *** Pasha is now known as Cory
602016-03-10T04:52:51 *** nkuttler has quit IRC
612016-03-10T04:55:21 *** mrkent has quit IRC
622016-03-10T04:58:02 *** Alopex has quit IRC
632016-03-10T04:59:07 *** Alopex has joined #bitcoin-core-dev
642016-03-10T04:59:39 *** nkuttler has joined #bitcoin-core-dev
652016-03-10T05:18:56 *** Giszmo has quit IRC
662016-03-10T05:30:40 *** randy-waterhouse has joined #bitcoin-core-dev
672016-03-10T05:40:26 *** cfields_ has quit IRC
682016-03-10T05:40:27 *** anttea has quit IRC
692016-03-10T05:40:27 *** Guest15994 has quit IRC
702016-03-10T05:46:11 *** cfields_ has joined #bitcoin-core-dev
712016-03-10T05:46:12 *** anttea has joined #bitcoin-core-dev
722016-03-10T05:46:12 *** Guest15994 has joined #bitcoin-core-dev
732016-03-10T05:51:23 *** rubensayshi has quit IRC
742016-03-10T05:51:53 *** rubensayshi has joined #bitcoin-core-dev
752016-03-10T05:58:32 *** fengling has quit IRC
762016-03-10T06:00:18 *** fengling has joined #bitcoin-core-dev
772016-03-10T06:02:58 *** cfields_ has quit IRC
782016-03-10T06:02:58 *** anttea has quit IRC
792016-03-10T06:02:59 *** Guest15994 has quit IRC
802016-03-10T06:03:02 *** Alopex has quit IRC
812016-03-10T06:04:07 *** Alopex has joined #bitcoin-core-dev
822016-03-10T06:08:40 *** cfields_ has joined #bitcoin-core-dev
832016-03-10T06:08:40 *** anttea has joined #bitcoin-core-dev
842016-03-10T06:08:40 *** Guest15994 has joined #bitcoin-core-dev
852016-03-10T06:36:21 *** murr4y has joined #bitcoin-core-dev
862016-03-10T07:06:55 *** Tasoshi has quit IRC
872016-03-10T07:16:41 *** hybridsole has quit IRC
882016-03-10T07:32:01 *** Thireus has quit IRC
892016-03-10T07:38:48 *** Don_John has quit IRC
902016-03-10T07:45:37 *** arowser has quit IRC
912016-03-10T07:45:59 *** arowser has joined #bitcoin-core-dev
922016-03-10T07:53:45 *** BashCo has quit IRC
932016-03-10T07:57:08 *** Thireus has joined #bitcoin-core-dev
942016-03-10T07:58:24 *** Ylbam has joined #bitcoin-core-dev
952016-03-10T08:24:40 *** BashCo has joined #bitcoin-core-dev
962016-03-10T08:35:44 *** ibrightly has quit IRC
972016-03-10T08:36:06 *** zmanian__ has quit IRC
982016-03-10T08:36:13 *** binns has quit IRC
992016-03-10T08:36:15 *** CodeShark has quit IRC
1002016-03-10T08:36:39 *** NicolasDorier has quit IRC
1012016-03-10T08:36:39 *** eragmus has quit IRC
1022016-03-10T08:39:12 *** ibrightly has joined #bitcoin-core-dev
1032016-03-10T08:41:13 *** zmanian__ has joined #bitcoin-core-dev
1042016-03-10T08:41:16 *** NicolasDorier has joined #bitcoin-core-dev
1052016-03-10T08:45:35 *** eragmus has joined #bitcoin-core-dev
1062016-03-10T08:48:53 *** CodeShark has joined #bitcoin-core-dev
1072016-03-10T08:50:03 *** binns has joined #bitcoin-core-dev
1082016-03-10T09:02:30 *** frankenmint has quit IRC
1092016-03-10T09:06:57 *** jannes has joined #bitcoin-core-dev
1102016-03-10T09:07:51 *** chris2000 has joined #bitcoin-core-dev
1112016-03-10T09:17:39 *** Guyver2 has joined #bitcoin-core-dev
1122016-03-10T09:20:26 *** fredrin has quit IRC
1132016-03-10T09:32:33 *** fredrin has joined #bitcoin-core-dev
1142016-03-10T09:40:00 *** wallet42 has quit IRC
1152016-03-10T09:50:27 *** MarcoFalke has joined #bitcoin-core-dev
1162016-03-10T09:53:15 *** jtimon has quit IRC
1172016-03-10T10:01:23 *** Tasoshi has joined #bitcoin-core-dev
1182016-03-10T10:05:04 <GitHub191> [bitcoin] MarcoFalke opened pull request #7666: [0.12.1] Fix doc and output for rpcauth (0.12...Mf1603-012fixdocrpcauth) https://github.com/bitcoin/bitcoin/pull/7666
1192016-03-10T10:07:55 *** randy-waterhouse has quit IRC
1202016-03-10T10:48:57 <go1111111> so, wumpus commented on PR 7635 with "utACK after squash". As the PR author does this mean I should make another PR with the changes all squashed into one commit? or will whoever merges it squash them and I take no more action? (this is my first non-trivial PR)
1212016-03-10T10:50:08 <MarcoFalke> git checkout docs4; git log -1
1222016-03-10T10:50:17 *** AaronvanW has joined #bitcoin-core-dev
1232016-03-10T10:50:24 <jonasschnelli> go1111111: squash and force push on the same branch/PR
1242016-03-10T10:50:32 <MarcoFalke> You should not see you last commit 429
1252016-03-10T10:50:54 <jonasschnelli> I do that with git rebase -i HEAD~X (X needs to be replace with >= amount of commits)
1262016-03-10T10:50:59 <MarcoFalke> git rebase --interactive ed067f722a244a31809eab633fbe316028a6f80b~
1272016-03-10T10:51:17 <MarcoFalke> and then select `f` or `s`
1282016-03-10T10:51:21 <go1111111> ok, will do. thank you
1292016-03-10T10:51:50 <MarcoFalke> finally git push $origin docs4 -f
1302016-03-10T10:52:58 <go1111111> random github newb question: in the comments on that PR I referred to another branch in my repo (zmq3). it seemed like github then automatically included that branch in the PR also. which seems dangerous if I want to refer to a branch without including it. is my interpretation of how github handles that correct?
1312016-03-10T10:53:23 <go1111111> i couldn't find that behavior documented
1322016-03-10T10:57:14 <MarcoFalke> no, should not happen
1332016-03-10T10:57:42 <MarcoFalke> maybe you fiddled locally with it.
1342016-03-10T10:57:49 <MarcoFalke> Try git branch -v
1352016-03-10T10:57:59 <MarcoFalke> to see what your branches look like locally
1362016-03-10T11:00:13 <go1111111> ok, thanks.
1372016-03-10T11:50:40 *** shesek has joined #bitcoin-core-dev
1382016-03-10T12:05:18 *** p15 has quit IRC
1392016-03-10T12:14:16 *** p15x has joined #bitcoin-core-dev
1402016-03-10T12:14:49 *** laurentmt has joined #bitcoin-core-dev
1412016-03-10T12:14:55 *** fredrin has quit IRC
1422016-03-10T12:16:23 *** fredrin has joined #bitcoin-core-dev
1432016-03-10T12:22:03 *** fredrin has quit IRC
1442016-03-10T12:28:06 *** fredrin has joined #bitcoin-core-dev
1452016-03-10T12:31:10 *** laurentmt has quit IRC
1462016-03-10T12:36:27 *** blkdb has quit IRC
1472016-03-10T12:36:34 *** arowser has quit IRC
1482016-03-10T12:36:58 *** arowser has joined #bitcoin-core-dev
1492016-03-10T12:37:39 *** blkdb has joined #bitcoin-core-dev
1502016-03-10T12:45:24 *** afk11 has quit IRC
1512016-03-10T12:46:09 *** afk11 has joined #bitcoin-core-dev
1522016-03-10T12:46:39 *** afk11_ has joined #bitcoin-core-dev
1532016-03-10T12:48:12 *** afk11 has quit IRC
1542016-03-10T12:48:13 *** afk11_ has quit IRC
1552016-03-10T12:50:50 *** afk11 has joined #bitcoin-core-dev
1562016-03-10T12:51:20 *** afk11_ has joined #bitcoin-core-dev
1572016-03-10T12:54:26 *** AtashiCon has quit IRC
1582016-03-10T12:54:33 *** AtashiCon has joined #bitcoin-core-dev
1592016-03-10T12:55:30 *** nkuttler has quit IRC
1602016-03-10T12:55:44 *** nkuttler has joined #bitcoin-core-dev
1612016-03-10T13:03:19 *** cj has quit IRC
1622016-03-10T13:05:10 *** cj has joined #bitcoin-core-dev
1632016-03-10T13:05:26 *** afk11_ has quit IRC
1642016-03-10T13:05:26 *** afk11 has quit IRC
1652016-03-10T13:15:04 *** fredrin has quit IRC
1662016-03-10T13:21:51 *** afk11 has joined #bitcoin-core-dev
1672016-03-10T13:22:22 *** afk11_ has joined #bitcoin-core-dev
1682016-03-10T13:24:46 *** cj has quit IRC
1692016-03-10T13:25:49 *** afk11_ has quit IRC
1702016-03-10T13:25:49 *** afk11 has quit IRC
1712016-03-10T13:27:32 *** fredrin has joined #bitcoin-core-dev
1722016-03-10T13:30:05 *** Giszmo has joined #bitcoin-core-dev
1732016-03-10T13:33:40 *** cj has joined #bitcoin-core-dev
1742016-03-10T13:37:49 *** MarcoFalke has quit IRC
1752016-03-10T13:41:49 *** cj has quit IRC
1762016-03-10T13:49:13 *** hybridsole has joined #bitcoin-core-dev
1772016-03-10T13:59:02 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1782016-03-10T14:00:49 *** p15x has quit IRC
1792016-03-10T14:05:35 <wumpus> go1111111: should be no reason to make a new pull request - rather not - if you need help with git just let me know
1802016-03-10T14:06:20 <wumpus> I've listed the steps in various PRs scattered over the place, probably would make sense to add it to some developer faw
1812016-03-10T14:06:22 <wumpus> faq
1822016-03-10T14:11:03 *** Chris_Stewart_5 has quit IRC
1832016-03-10T14:17:14 *** afk11 has joined #bitcoin-core-dev
1842016-03-10T14:17:44 *** afk11_ has joined #bitcoin-core-dev
1852016-03-10T14:18:42 *** afk11 has quit IRC
1862016-03-10T14:18:43 *** afk11_ has quit IRC
1872016-03-10T14:19:15 *** afk11 has joined #bitcoin-core-dev
1882016-03-10T14:19:45 *** afk11_ has joined #bitcoin-core-dev
1892016-03-10T14:22:09 *** afk11 has quit IRC
1902016-03-10T14:22:45 *** afk11 has joined #bitcoin-core-dev
1912016-03-10T14:26:48 *** afk11_ has quit IRC
1922016-03-10T14:26:49 *** afk11 has quit IRC
1932016-03-10T14:27:21 *** afk11 has joined #bitcoin-core-dev
1942016-03-10T14:30:13 *** afk11 has quit IRC
1952016-03-10T14:31:06 *** afk11 has joined #bitcoin-core-dev
1962016-03-10T14:31:47 *** afk11 has quit IRC
1972016-03-10T14:32:19 *** afk11 has joined #bitcoin-core-dev
1982016-03-10T14:39:41 *** afk11 has quit IRC
1992016-03-10T14:41:19 *** afk11 has joined #bitcoin-core-dev
2002016-03-10T14:48:31 *** afk11 has quit IRC
2012016-03-10T15:19:04 *** laurentmt has joined #bitcoin-core-dev
2022016-03-10T15:29:49 *** zooko has joined #bitcoin-core-dev
2032016-03-10T15:45:02 *** laurentmt has quit IRC
2042016-03-10T15:49:51 *** fredrin has quit IRC
2052016-03-10T15:50:47 *** afk11 has joined #bitcoin-core-dev
2062016-03-10T15:50:51 *** fredrin has joined #bitcoin-core-dev
2072016-03-10T15:55:15 *** fredrin has quit IRC
2082016-03-10T15:57:20 *** fredrin has joined #bitcoin-core-dev
2092016-03-10T16:10:34 *** Thireus has quit IRC
2102016-03-10T16:20:36 *** laurentmt has joined #bitcoin-core-dev
2112016-03-10T16:21:48 *** jtimon has joined #bitcoin-core-dev
2122016-03-10T16:21:50 *** laurentmt has quit IRC
2132016-03-10T16:25:47 *** BashCo has quit IRC
2142016-03-10T16:27:52 *** laurentmt has joined #bitcoin-core-dev
2152016-03-10T16:28:10 *** laurentmt has quit IRC
2162016-03-10T16:38:27 *** hybridsole has quit IRC
2172016-03-10T16:41:12 *** hybridsole has joined #bitcoin-core-dev
2182016-03-10T16:52:13 *** wallet42 has joined #bitcoin-core-dev
2192016-03-10T16:52:15 *** BashCo has joined #bitcoin-core-dev
2202016-03-10T16:56:24 *** wallet42 has quit IRC
2212016-03-10T17:05:34 *** rubensayshi has quit IRC
2222016-03-10T17:08:45 *** Don_John has joined #bitcoin-core-dev
2232016-03-10T17:14:09 *** achow101 has joined #bitcoin-core-dev
2242016-03-10T17:14:29 *** Don_John has quit IRC
2252016-03-10T17:15:06 <morcos> btcdrak: ok. i got sucked in. i'm writing rpc/p2p tests for 68/112/113.
2262016-03-10T17:16:27 <morcos> i'm basically taking one of your tests that tests the activation logic and modifying to try many variations of different txs before and after soft fork activates and make sure they are accepted/rejected appropriately
2272016-03-10T17:18:18 *** rubensayshi has joined #bitcoin-core-dev
2282016-03-10T17:19:19 *** Don_John has joined #bitcoin-core-dev
2292016-03-10T17:38:49 *** wallet42 has joined #bitcoin-core-dev
2302016-03-10T17:39:14 *** Thireus has joined #bitcoin-core-dev
2312016-03-10T17:44:11 *** laurentmt has joined #bitcoin-core-dev
2322016-03-10T17:44:21 *** laurentmt has quit IRC
2332016-03-10T17:49:15 *** shesek has quit IRC
2342016-03-10T17:50:29 *** Don_John has quit IRC
2352016-03-10T17:52:24 *** Don_John has joined #bitcoin-core-dev
2362016-03-10T17:53:39 <btcdrak> morcos: we can never have enough test :)
2372016-03-10T17:58:02 <morcos> btcdrak: well i was letting you know in case someone else was working on them
2382016-03-10T17:58:19 <morcos> but as far as i know we don't have any other than the unit tests so far right?
2392016-03-10T17:58:33 *** gribble has quit IRC
2402016-03-10T18:02:44 *** shesek has joined #bitcoin-core-dev
2412016-03-10T18:09:31 <sipa> morcos: awesome, thanks
2422016-03-10T18:09:55 <sipa> so what is the current state of the pull request against my bip9 pr?
2432016-03-10T18:10:52 <sipa> i agree with you that it makes sense to have separate tests for "50% of the past N blocks have a version we don't know", and one for "an unknowm versionbits deployment is lockedin/activated"
2442016-03-10T18:11:52 <morcos> sipa: hmm, i guess thats up to you
2452016-03-10T18:12:09 <sipa> though the latter one should be permanent i think... if you happened to be offline during the window in which it activated, you won't ever know itherwise
2462016-03-10T18:12:25 <morcos> what do you mean by permanent?
2472016-03-10T18:12:30 <sipa> that was a downside we get from bit flags that expire: they are not visible forever
2482016-03-10T18:12:53 <morcos> i guess its not clear to me how these alerts work
2492016-03-10T18:13:02 <morcos> if you're not using QT, there is no permanent way is there?
2502016-03-10T18:13:04 <sipa> if any vb deployment ever activated in your currently active blockchain, you get a warning
2512016-03-10T18:13:06 *** laurentmt has joined #bitcoin-core-dev
2522016-03-10T18:13:25 <sipa> eh, no clue what qt does
2532016-03-10T18:13:33 <morcos> so right now that strMiscWarning isn't displayed in the errors field
2542016-03-10T18:13:38 <morcos> i don't think
2552016-03-10T18:13:48 <sipa> hmm?
2562016-03-10T18:14:08 <morcos> so the errors that are printed in getInfo won't include this
2572016-03-10T18:14:11 <morcos> i think
2582016-03-10T18:14:14 <morcos> even for ISM soft forks
2592016-03-10T18:14:23 *** skyraider has joined #bitcoin-core-dev
2602016-03-10T18:14:25 <morcos> the only way you see it is if you look at your debug log
2612016-03-10T18:14:33 <morcos> or if you're using QT or the -alertnotify script
2622016-03-10T18:14:49 <sipa> what?
2632016-03-10T18:14:52 <sipa> really?
2642016-03-10T18:15:00 <morcos> maybe?
2652016-03-10T18:15:08 <sipa> well, i have no counterevidence
2662016-03-10T18:15:32 *** laurentmt has quit IRC
2672016-03-10T18:15:39 <sipa> so i think that needs investigating
2682016-03-10T18:15:49 <morcos> maybe i taket hat back
2692016-03-10T18:15:52 <morcos> sorry, let me see
2702016-03-10T18:16:59 <morcos> yeah i think thats right
2712016-03-10T18:17:09 <morcos> look at GetWarnngs in main.cpp
2722016-03-10T18:17:23 <morcos> strRPC isn't updated by strMiscWarning
2732016-03-10T18:17:35 <sipa> heh
2742016-03-10T18:17:46 <sipa> that variable name does not even look familiar to me
2752016-03-10T18:17:54 *** frankenmint has joined #bitcoin-core-dev
2762016-03-10T18:18:58 <morcos> i also find it a bit disturbing that one warning can wipe out another
2772016-03-10T18:19:37 <sipa> i doubt i have ever looked at that code
2782016-03-10T18:20:40 <morcos> so for instance if PartitionCheck causes "abnormally high number of blocks" that wipes out your warning that a soft fork has activated
2792016-03-10T18:20:58 <morcos> and even in the ISM code, that warning only happens once
2802016-03-10T18:24:09 <morcos> so.... i'm going to quietly slink away and go back to my test writing...
2812016-03-10T18:24:34 *** zooko has quit IRC
2822016-03-10T18:26:20 <sipa> we should probably concatenate all warnings...
2832016-03-10T18:26:27 <sipa> and have a boolean for "serious" or so
2842016-03-10T18:26:59 <sipa> that can make RPCs fail or the GUI show bigger animated themed warning boxes
2852016-03-10T18:27:08 <morcos> yeah i think the quick and dirty way is to have separate variables though for each of the warnings
2862016-03-10T18:27:25 <morcos> b/c some occur repeatedly or can get cleared out or whatever
2872016-03-10T18:27:39 <morcos> and then the display mechanism can check each one and do the right thing?
2882016-03-10T18:27:58 <sipa> yeah
2892016-03-10T18:28:55 <morcos> i guess it wouldn't be that hard to just have a set of strings, and then you can clear them to
2902016-03-10T18:28:56 <sipa> anyway, the point i was trying to make (and which is independent of the warning presentation problem) is that imho a versionbits deployment from anywhere in your past should remain visible (but probably should not be considered serious)
2912016-03-10T18:29:21 <morcos> wait, an unknown one should not be considered serious?
2922016-03-10T18:30:31 <gmaxwell> Meeting in half an hour, everyone should think back to all the great topics we ran out of time for last week and have them ready for the agenda this time.
2932016-03-10T18:31:43 <morcos> sipa: i suppose what we could do is everytime you start the node we rescan for unknown deployments from the beginning (which would speak to using a real cache).. b/c otherwise there is a risk that you shutdown your old node and when you restart it you've lost the warning, is that what you meant?
2942016-03-10T18:32:00 <sipa> morcos: i think that the presence of an unknown softfork should not be treated as something serious
2952016-03-10T18:32:18 <sipa> morcos: or just have a versionbits cache per bit for warnings
2962016-03-10T18:32:24 <sipa> without special logic
2972016-03-10T18:32:39 <morcos> sipa: yes thats what i meant by speaking to using a real cache
2982016-03-10T18:32:48 <morcos> perhaps its worth the 300k extra memory
2992016-03-10T18:32:58 <morcos> but why isn't it serious?
3002016-03-10T18:33:04 *** jgarzik has quit IRC
3012016-03-10T18:33:06 <morcos> i think it should be considered quite serious
3022016-03-10T18:33:23 <morcos> we have in the past, we told you your node was obsolete and you must upgrade
3032016-03-10T18:33:42 <morcos> there is no way to know whether the soft fork was relatively benign or not
3042016-03-10T18:34:08 <morcos> but if we give the information on the bit/activation height, then it should be easy for people to look up that soft fork, and decide for themselves whether they care
3052016-03-10T18:34:29 <morcos> but to suhas's point, thats why its important to be able to warn on the same bit more than once?
3062016-03-10T18:35:51 <sipa> hmm
3072016-03-10T18:35:59 <sipa> maybe i misunderstood the code
3082016-03-10T18:36:15 <sipa> it seemed to me that it would not catch historical deployments
3092016-03-10T18:37:33 <morcos> my code will catch historical deployments but only once
3102016-03-10T18:37:47 <morcos> i mean once per each deployment, will catch multiple on the same bit
3112016-03-10T18:37:55 *** gribble has joined #bitcoin-core-dev
3122016-03-10T18:41:42 *** frankenmint has quit IRC
3132016-03-10T18:49:49 *** kangx_ has joined #bitcoin-core-dev
3142016-03-10T18:50:57 *** mrkent has joined #bitcoin-core-dev
3152016-03-10T18:52:24 <morcos> so sipa, i think if it were me, i'd just change my PR to run on start up on the entire blockchain, instead of actually populating a cache that is mostly usless and whose only effect is to obscure multiple deployments on the same bit
3162016-03-10T18:53:46 *** laurentmt has joined #bitcoin-core-dev
3172016-03-10T18:54:25 *** zooko has joined #bitcoin-core-dev
3182016-03-10T18:55:37 *** jcorgan has joined #bitcoin-core-dev
3192016-03-10T18:55:49 <sipa> ok
3202016-03-10T18:56:51 <gmaxwell> sipa: morcos: sdaftuar: petertodd: btcdrak: wumpus: cfields_: jonasschnelli: phantomcircuit: BlueMatt: jtimon: CodeShark: NicolasDorier: paveljanik: meetin in 4 minutes.
3212016-03-10T18:56:58 <jonasschnelli> here!
3222016-03-10T18:56:58 <BlueMatt> ahhhhhh
3232016-03-10T18:57:00 <BlueMatt> taggggggg
3242016-03-10T18:57:05 <btcdrak> present!
3252016-03-10T18:57:27 <wumpus> yep
3262016-03-10T18:57:37 <sipa> here
3272016-03-10T18:57:46 <warren> here
3282016-03-10T18:57:48 <morcos> sipa: so do you want me to make changes?
3292016-03-10T18:57:54 <btcdrak> it's like being in school again :)
3302016-03-10T18:58:26 <sipa> morcos: go ahead
3312016-03-10T18:58:34 <jcorgan> not invited but still here :-)
3322016-03-10T18:58:34 <gmaxwell> (sorry to ping, but we've had slow starts and time shortfalls recently)
3332016-03-10T18:59:46 *** frankenmint has joined #bitcoin-core-dev
3342016-03-10T18:59:59 <wumpus> #startmeeting
3352016-03-10T18:59:59 <lightningbot> Meeting started Thu Mar 10 18:59:59 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3362016-03-10T18:59:59 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3372016-03-10T19:00:03 <wumpus> topics?
3382016-03-10T19:00:23 <evoskuil> here
3392016-03-10T19:01:05 <morcos> we have a list of remaining segwit items that were written on whiteboard at MIT... should we assign those?
3402016-03-10T19:01:16 <wumpus> sure
3412016-03-10T19:01:18 * sipa hides
3422016-03-10T19:01:24 *** mm_1 has quit IRC
3432016-03-10T19:01:25 * btcdrak locked the door
3442016-03-10T19:01:44 <wumpus> #topic remaining segwit items
3452016-03-10T19:01:56 <jonasschnelli> I'm happy to help,... probably in the wallet section.
3462016-03-10T19:02:05 <morcos> seems to me it would nice to buckle down and prioritize BIP 9, BIPs 68,112,113 , segwit. i mean i think we are all working on those things, but there is still more to do on all of them
3472016-03-10T19:02:06 <sipa> my plan was to rebase segwit on top of bip9, add the rewind logic to continie after post-softfork uograde, and do a new testnet
3482016-03-10T19:02:10 <sipa> eh, new segnet
3492016-03-10T19:02:21 <btcdrak> great
3502016-03-10T19:02:33 <CodeShark> when do you think to deploy the new testnet?
3512016-03-10T19:02:40 <sdaftuar> we also need to discuss standardness rules
3522016-03-10T19:02:50 <sdaftuar> (or rather, propose and discuss)
3532016-03-10T19:02:55 <warren> What was decided for safety on the edge of the rule change in case of reorg?
3542016-03-10T19:03:45 <morcos> I think my suggestion would be to push that problem to wallet users
3552016-03-10T19:03:49 <sdaftuar> warren: i believe we decided to advise wallet authors to wait some time after segwit activates before using
3562016-03-10T19:03:51 <sipa> one possibility is not enabling relay/mempool logic for segwit transactions until 2 period after activatation
3572016-03-10T19:03:56 <morcos> yes authors i meant
3582016-03-10T19:04:04 <gmaxwell> warren: I don't understand the context of your question. Generall new soft fork rules should not be used immediately.
3592016-03-10T19:04:14 <sipa> another is to just be cautious and nit enable the functionality in wallets until a post segwit release
3602016-03-10T19:04:15 <sdaftuar> gmaxwell: this one is more dangerous than usual though
3612016-03-10T19:04:24 <gmaxwell> sdaftuar: it's just like p2sh.
3622016-03-10T19:04:29 <warren> OK, that seems adequate enough.
3632016-03-10T19:04:42 <CodeShark> I'm not that concerned about edge case reorg situations
3642016-03-10T19:04:55 <morcos> gmaxwell: its a bit riskier than p2sh... don't need a preimage
3652016-03-10T19:04:55 <sipa> it's not situation*s*
3662016-03-10T19:05:08 <gmaxwell> in core I would recommend that we would switch to using segwit as default in a subsiquent release after the SF activates.
3672016-03-10T19:05:40 <jonasschnelli> so have it ready and auto-use it whiteout creating another release?
3682016-03-10T19:06:00 <morcos> so in any case, i think we just advise wallet authors to wait some minimum amount of time after activation to send segwit txs.. they are already going to have to put in some code to wait until it activates
3692016-03-10T19:06:00 <jonasschnelli> *without
3702016-03-10T19:06:01 <CodeShark> either wait until next release - or wait a few blocks after activation before enabling it in wallet
3712016-03-10T19:06:11 <sipa> ok
3722016-03-10T19:06:43 <jonasschnelli> auto-enable in in the wallet after 95%?
3732016-03-10T19:06:47 <gmaxwell> no.
3742016-03-10T19:06:57 <btcdrak> I think better to wait a release code afterwards
3752016-03-10T19:06:58 <sipa> not even at 100%
3762016-03-10T19:07:19 <jonasschnelli> Okay. Then do it over the release-cycle..
3772016-03-10T19:07:31 <gmaxwell> I recommend using a release. Automatic behavior is not needed here. Also-- it's a pretty big behavioral change to use it, e.g. you'd be issuing other address styles in response.
3782016-03-10T19:07:43 <jonasschnelli> Agree.
3792016-03-10T19:07:48 <morcos> also we haven't written that code yet anyway
3802016-03-10T19:07:52 <sipa> that is an open question
3812016-03-10T19:07:53 <jonasschnelli> I just think there is a hight incentive to use it (fees)
3822016-03-10T19:07:54 <CodeShark> this is something that can be decided once segwit has already been deployed and is awaiting activation
3832016-03-10T19:07:56 <gmaxwell> having that triggered by invisible-to-the-user network behavior isn't reat.
3842016-03-10T19:08:16 <gmaxwell> great*
3852016-03-10T19:08:31 <sipa> i wish we had an address style for segwit part of the standard :(
3862016-03-10T19:08:39 *** frankenmint has quit IRC
3872016-03-10T19:09:10 <gmaxwell> sipa: no you don't. Deploying a new address style takes forever. :P what you wish for is a magic wand.
3882016-03-10T19:09:15 <btcdrak> sipa I thought we did? BIP142?
3892016-03-10T19:09:37 <CodeShark> btcdrak: we haven't been pushing it because of concerns regarding scary "new addresses"
3902016-03-10T19:09:41 <jonasschnelli> P2WPKH?
3912016-03-10T19:09:53 <sipa> i think we have more buy-in from wallet authors about segwit now, than p2sh had at the timr
3922016-03-10T19:09:54 <morcos> i think we should do that though, otherwise everyone is going to embed them in p2sh which is kind of silly
3932016-03-10T19:10:11 *** frankenmint has joined #bitcoin-core-dev
3942016-03-10T19:10:22 <CodeShark> p2sh was almost entirely under the radar as far as the community at large
3952016-03-10T19:10:24 <gmaxwell> also, continued use of base58 is awful. I am going to refuse to discuss address encodings with anyone who hasn't read an address to me over the phone. :)
3962016-03-10T19:10:48 <btcdrak> CodeShark: I would suggest brining it back. There's no problem.
3972016-03-10T19:10:57 <gmaxwell> CodeShark: thats not the case; besides there is a material difference in the sheer mass of code that must be updated. Besides why is this being discussed there.
3982016-03-10T19:11:02 <CodeShark> btcdrak: there sort of is a problem still...
3992016-03-10T19:11:06 <gmaxwell> btcdrak: I oppose it in the strongest possible terms.
4002016-03-10T19:11:08 <CodeShark> both internal and external
4012016-03-10T19:11:22 <btcdrak> CodeShark: you can change you mind :)
4022016-03-10T19:11:33 <CodeShark> internally some people hate base58, externally some people are still grandstanding with the "segwit is too hard" crap
4032016-03-10T19:11:56 <BlueMatt> gmaxwell: there is certain value in user expectations of things that look like base58
4042016-03-10T19:12:13 <CodeShark> I think it's a battle not worth fighting right now
4052016-03-10T19:12:18 <jonasschnelli> +1
4062016-03-10T19:12:22 <btcdrak> +1
4072016-03-10T19:12:24 <morcos> gmaxwell: whats your number
4082016-03-10T19:12:29 <jonasschnelli> haha
4092016-03-10T19:12:31 <gmaxwell> BlueMatt: You are on subject-matter-ignore until you call me and successfully read me a base58 address. :)
4102016-03-10T19:13:04 <sipa> i would really like to have some psegwit afdressddress as part of the "package"
4112016-03-10T19:13:10 <gmaxwell> morcos: PM :P
4122016-03-10T19:13:40 <BlueMatt> gmaxwell: I'm not suggesting I'm necessarily in support of base58 addresses, but my point is that it is not up to us here to figure out addressing for segwit...that is something WALLETS need to be involved in...people who actually have some ux experience, which does not exist here
4132016-03-10T19:14:16 <morcos> gmaxwell: BlueMatt says "..."
4142016-03-10T19:14:17 <gmaxwell> yes indeed. but thats also why taking on a new address type at the same time is not a good idea, it would get in the way of that kind of collaboration.
4152016-03-10T19:14:22 <gmaxwell> hahha
4162016-03-10T19:14:30 <BlueMatt> agreed
4172016-03-10T19:14:30 <sipa> do you think so?
4182016-03-10T19:14:37 <sipa> i think it's the opposite
4192016-03-10T19:14:46 <BlueMatt> I think the idea of pushing off address types for segwit for broader feedback is a good thing
4202016-03-10T19:14:47 <Luke-Jr> sipa: that was a lot of backspaces.
4212016-03-10T19:15:07 <CodeShark> good UI design wouldn't even burden users with having to deal with copy/pasting cryptographic keys
4222016-03-10T19:15:20 <CodeShark> but that's an entirely separate discussion
4232016-03-10T19:15:28 <Luke-Jr> FWIW, I've been thinking of implementing the payment protocol better in Core
4242016-03-10T19:15:37 <Luke-Jr> including the new BIP 75 stuff
4252016-03-10T19:15:39 <jonasschnelli> We are far away from designing the UX... this is a topic we can talk about in 2-3 years.
4262016-03-10T19:16:04 *** zooko has quit IRC
4272016-03-10T19:16:33 <sipa> :)
4282016-03-10T19:16:42 <sipa> ok, let's postpone that address discussion
4292016-03-10T19:16:42 <jonasschnelli> But sipa: is the P2WPKH address type not okay?,.. addresses like "p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm"?
4302016-03-10T19:16:53 <sipa> jonasschnelli: you mean bip142?
4312016-03-10T19:17:08 <jonasschnelli> Yes. Easy to handle by existing wallets?
4322016-03-10T19:17:17 <BlueMatt> jonasschnelli: ACK
4332016-03-10T19:17:24 <gmaxwell> sipa was raising the concern that if something weren't done sooner we'd be left stuck with 80 bit security forever, I reminded him in PM that we have an upcoming checksig improvement to reduce transaction sizes by 30% which would be a nice time to do a new address type too. :)
4342016-03-10T19:17:42 <wumpus> would be good to have concrete proposals for address formats ,say as BIPs
4352016-03-10T19:17:50 <CodeShark> we'll have plenty of opportunities to introduce new stuff in the future
4362016-03-10T19:18:00 <CodeShark> right now we should focus on the path of least resistance
4372016-03-10T19:18:14 <sipa> the reason against incorporating bip142 is people yelling "see! sehwit needs new address types! everyone has to upgrade! not backward compatible!"
4382016-03-10T19:18:17 <gmaxwell> The amount going on right now is too great to be able to afford forced seralization.
4392016-03-10T19:18:27 <CodeShark> eventually my hope is we'll actually have a competent ecosystem that can actually do tech
4402016-03-10T19:18:36 <CodeShark> but for now we must deal with what we have
4412016-03-10T19:18:40 <morcos> Yeah I think it would make a lot of sense to release just the P2WPKH address
4422016-03-10T19:18:44 <Luke-Jr> sipa: we could add sending support, and discourage anyone from using it to receive for now
4432016-03-10T19:18:45 <jonasschnelli> sipa: You could still uses it over P2SH... but we don't live for the critics.
4442016-03-10T19:18:56 <morcos> sipa: don't you think everyone is going to say that even more if we don't have address types
4452016-03-10T19:19:12 <sipa> i don't know
4462016-03-10T19:19:20 <sipa> i'm an engineer, not a marketer
4472016-03-10T19:19:31 <jonasschnelli> +1 for P2WPKH bip142
4482016-03-10T19:19:43 <wumpus> shouldn't be expected from you to act as marketeer sipa
4492016-03-10T19:19:47 <wumpus> you have enough on your plate
4502016-03-10T19:19:51 <sipa> next topic?
4512016-03-10T19:19:59 <CodeShark> yes please
4522016-03-10T19:20:07 <wumpus> suggestions?
4532016-03-10T19:20:23 <Luke-Jr> (I don't see value in p2wpkh, but let's move on)
4542016-03-10T19:21:14 <wumpus> ok, if not, that was a quick meeting
4552016-03-10T19:21:28 <gmaxwell> there were many things last week that got cut off.
4562016-03-10T19:21:29 <wumpus> (I'm still too tired and jetlaggy to contribute much now)
4572016-03-10T19:21:38 <jonasschnelli> If no one has something important... what do you think about my approach of IBD with a pregenerated signed UTXOset?
4582016-03-10T19:21:57 <btcdrak> Can I ask people to review the backport PRs for BIP68 and 112? They were straight cherry-picks into 0.12 but they do need a couple eyes on them.
4592016-03-10T19:22:10 <morcos> jonasschnelli: i think thats a bad idea
4602016-03-10T19:22:11 <Luke-Jr> jonasschnelli: sounds like a waste of time at best, to be frank. :x
4612016-03-10T19:22:21 *** droark has joined #bitcoin-core-dev
4622016-03-10T19:22:23 <wumpus> #action review backport PRs for BIP68 and 112
4632016-03-10T19:22:33 <morcos> jonasschnelli: core devs (or anybody for that matter) should not be authorizing the state of the ledger at any time
4642016-03-10T19:22:40 <wumpus> #topic IBD with a pregenerated signed UTXOse
4652016-03-10T19:22:52 <wumpus> it's risky, it brings trust into the system
4662016-03-10T19:22:56 <Luke-Jr> much prefer to see SPV mode until IBD completes
4672016-03-10T19:23:15 <jonasschnelli> Luke-Jr: Yes. Agree.
4682016-03-10T19:23:19 <wumpus> who would you trust to sign something like that?
4692016-03-10T19:23:30 <sipa> Bob.
4702016-03-10T19:23:32 <jonasschnelli> Just thought we might want to reduce the amount of block-serving even more.
4712016-03-10T19:23:36 <wumpus> yes, definitely Bob
4722016-03-10T19:23:38 <Luke-Jr> XD
4732016-03-10T19:23:52 <jonasschnelli> wumpus: could be signed by the same users/devs who are signing the gitian builds.
4742016-03-10T19:24:00 <sipa> jonasschnelli: that's not reducing block serving; it's changing the trust model instead
4752016-03-10T19:24:22 <jonasschnelli> I agree. It does change the trust model.
4762016-03-10T19:24:24 <wumpus> jonasschnelli: hmm don't put too much on their shoulders
4772016-03-10T19:24:27 <CodeShark> without TXO commitments it's unfixable
4782016-03-10T19:24:31 <CodeShark> :p
4792016-03-10T19:24:35 <morcos> if we go back to the backport question, we also need to backport all these SF's to 0.11 is that correct?
4802016-03-10T19:24:54 *** shawnmaten has joined #bitcoin-core-dev
4812016-03-10T19:24:55 <jonasschnelli> Okay... so. Then let me not implement it. :)
4822016-03-10T19:25:01 <wumpus> yea, UTXO commitments would make this somewhat more realistic, although it'd still reduce the overall trust model to SPV
4832016-03-10T19:25:21 <wumpus> jonasschnelli: yes, better not for now I think
4842016-03-10T19:25:28 <wumpus> #topic backports to 0.11
4852016-03-10T19:25:30 *** cocoBTC has joined #bitcoin-core-dev
4862016-03-10T19:25:33 <gmaxwell> morcos: I was thinking about this this morning. The normal release cadance would have us do so, I believe.
4872016-03-10T19:25:42 <jonasschnelli> SPV during IBD and a throttled(CPU) IBD is the better approach.
4882016-03-10T19:26:03 <wumpus> jonasschnelli: yes, definitely those would be good to have
4892016-03-10T19:26:07 <Luke-Jr> how practical is it to backport to 0.10?
4902016-03-10T19:26:14 <warren> why 0.10?
4912016-03-10T19:26:20 <wumpus> topic is backport to 0.11 Luke-Jr :p
4922016-03-10T19:26:20 <sipa> 0.10 and 0.11 are close
4932016-03-10T19:26:22 <morcos> 0.10? i'd hoped you guys would be willing to skip 0.11
4942016-03-10T19:26:29 <sipa> but agree; just 0.11
4952016-03-10T19:26:32 <btcdrak> morcos: I would skip 0.11
4962016-03-10T19:26:38 <sipa> we have a published release schedule, no?
4972016-03-10T19:26:51 <wumpus> I think backporting to 0.11 is fairly necessary, that's only one release back
4982016-03-10T19:26:51 <Luke-Jr> sipa: of guaranteed support, not limited-to
4992016-03-10T19:27:07 <Luke-Jr> 0.11 is necessary; 0.10 would be ideal
5002016-03-10T19:27:09 <morcos> wumpus: i suppose, i'm worried about how well tested these major changes will be
5012016-03-10T19:27:20 <sipa> master, 0.12, 0.11
5022016-03-10T19:27:21 <Luke-Jr> but I'll deal with 0.10 later I guess
5032016-03-10T19:27:24 <jonasschnelli> 0.10 is not necessary... we once agree in supporting only two major versions.
5042016-03-10T19:27:28 <btcdrak> sipa: our lifecycle doc is at https://bitcoincore.org/en/lifecycle/
5052016-03-10T19:28:00 <Luke-Jr> jonasschnelli: it was never agreed to drop support for older ones, only to not promise support for them; but that's on me for 0.10 I think
5062016-03-10T19:28:05 <wumpus> morcos: it's a challenge, but I think you can't get around it, some people won't be ready yet to upgrade to 0.12
5072016-03-10T19:28:06 <btcdrak> the backports to 0.12 are trivial, but 0.11 will be a little more annoying, especially for BIP68 I believe
5082016-03-10T19:29:03 <morcos> btcdrak: we should just backport them kind of altogether right?
5092016-03-10T19:29:10 <btcdrak> btw the backports for BIP68,112 are #7543 and #7544, I forgot to mention the numbers earlier
5102016-03-10T19:29:14 <morcos> i suppose they don't overlap that much
5112016-03-10T19:29:31 <morcos> i think i can make sure BIP68 for 0.11 backports properly
5122016-03-10T19:30:02 <btcdrak> morcos: you'd be the best person to backport BIP68 to 0.11.
5132016-03-10T19:30:10 <morcos> i will take the approach of not keeping the mempool consistent and checking sequence values in the mining code, which will probably not make much of an effect on the already absurdly slow mining code
5142016-03-10T19:30:30 <morcos> thats why 7187 was separate, that won't be backported to 0.11
5152016-03-10T19:30:42 <btcdrak> morcos: plenty miners have upgraded to 0.12 fwiw
5162016-03-10T19:30:51 <btcdrak> well pools*
5172016-03-10T19:31:26 <morcos> ok. i'll work on that
5182016-03-10T19:31:33 <wumpus> the other path would be to wait for 0.13, then only backport to 0.12, but then you'll have to wait 6 months :p
5192016-03-10T19:31:50 <Luke-Jr> >_<
5202016-03-10T19:31:55 <btcdrak> wumpus: nice joke there :-P
5212016-03-10T19:31:58 <wumpus> well not exactly 6 anymore but ok...
5222016-03-10T19:32:14 <wumpus> I don't think it's realistic no
5232016-03-10T19:32:39 <sipa> i think we can do 9/68/112/113 soon
5242016-03-10T19:32:49 <wumpus> aim for 0.13 would be july
5252016-03-10T19:33:04 <morcos> sipa: agreed!
5262016-03-10T19:33:14 <wumpus> sipa: I hope so!
5272016-03-10T19:33:16 <btcdrak> sipa: I also believe so. 68/112/113 are done from my side, morcos wants to add more RPC tests which is fine.
5282016-03-10T19:33:22 <morcos> did you ever reply to my comment on block version = 4
5292016-03-10T19:33:29 <morcos> btcdrak: there are NONE!
5302016-03-10T19:33:43 <CodeShark> any plans to remove the default version crap out of primitives?
5312016-03-10T19:33:50 <btcdrak> morcos: yes there are. same standard as for BIP65
5322016-03-10T19:33:54 <sipa> CodeShark: yes, see bip9
5332016-03-10T19:34:12 <sipa> morcos: it was needed in combination with the warning logic
5342016-03-10T19:34:18 <btcdrak> morcos: see #7648
5352016-03-10T19:34:20 <sipa> it may not be needed anymore with imoroved logic
5362016-03-10T19:34:22 *** d_t has joined #bitcoin-core-dev
5372016-03-10T19:34:36 <morcos> btcdrak: i saw, and i agree, BIP65 made it out withotu adequate tests
5382016-03-10T19:35:05 <sdaftuar> sipa: right now #7575 will revert back to version 4 blocks after the first soft fork activates, if no other soft forks are in the queue
5392016-03-10T19:35:06 <jonasschnelli> bip65 had rpc tests from petertodd?!
5402016-03-10T19:35:13 <sdaftuar> i assume that is unintentional?
5412016-03-10T19:35:18 <btcdrak> morcos: I would disagree they were not adaquet, you can always have more sure.
5422016-03-10T19:35:26 <btcdrak> bip65 had RPC tests.
5432016-03-10T19:35:29 <sipa> sdaftuar: that seems correct to mr
5442016-03-10T19:35:39 <sdaftuar> oh, i didn't realize that!
5452016-03-10T19:35:50 <morcos> sipa: huh? correct as in you wanted that?
5462016-03-10T19:36:03 <sipa> the old version is used to indicate "no versionbits"
5472016-03-10T19:36:04 <btcdrak> bip68/112/113 have the p2p RPC tests in #7648
5482016-03-10T19:36:30 <sipa> morcos: yes, otherwise the version is ambiguous based on what software miners use, ignoring deploymemts
5492016-03-10T19:36:37 <sipa> which the warning logic can't deal with
5502016-03-10T19:36:55 <sipa> it must be absolute "these deployments -> this nVersion"
5512016-03-10T19:37:05 <morcos> sipa: all prior soft forks required minors to upgrade
5522016-03-10T19:37:14 <sipa> miners :p
5532016-03-10T19:37:19 <btcdrak> lol
5542016-03-10T19:37:25 <CodeShark> minors can always get a fake ID
5552016-03-10T19:37:27 <morcos> sipa: what i would like to do is with this first soft fork, require nVersion > 4
5562016-03-10T19:37:44 <sipa> why?
5572016-03-10T19:37:50 <btcdrak> morcos: why?
5582016-03-10T19:37:51 <morcos> then we can warn on anything that is not 001... unless it is <=4 which we know are invalid
5592016-03-10T19:38:00 <morcos> that seems consistent with how we've done other soft forks
5602016-03-10T19:38:10 <morcos> there is an expected version number, unknown differences are warned on
5612016-03-10T19:38:23 *** GreenIsMyPepper has joined #bitcoin-core-dev
5622016-03-10T19:38:24 <gmaxwell> so old software versions warn.
5632016-03-10T19:38:34 <gmaxwell> and continue warning.
5642016-03-10T19:38:35 *** Adiabat has joined #bitcoin-core-dev
5652016-03-10T19:38:50 <morcos> gmaxwell: yes, old software versions are incapable of noticing transient changes
5662016-03-10T19:39:06 <morcos> thats why we need to rework alerts/warning to correctly identify them now
5672016-03-10T19:39:25 <morcos> in fact if you turned off a 0.12 node for a couple months
5682016-03-10T19:39:34 <morcos> and then turned it back on after all these SF's activated
5692016-03-10T19:39:36 <morcos> you would have no idea
5702016-03-10T19:39:43 <morcos> even if you looked at your debug logs
5712016-03-10T19:39:49 <morcos> b/c the warning logic doesn't run in IBD
5722016-03-10T19:40:08 <morcos> i feel like that makes it a requirement that we permanently increase the version number
5732016-03-10T19:40:24 <sdaftuar> agreed
5742016-03-10T19:40:51 <sipa> wth are you talking about?
5752016-03-10T19:40:56 <morcos> who?
5762016-03-10T19:41:01 <CodeShark> I don't follow
5772016-03-10T19:41:03 <morcos> me? which part?
5782016-03-10T19:41:09 <sipa> versionbits is deterministic based on the chain histotu
5792016-03-10T19:41:18 <morcos> yes 0.12 doesn't have version bits
5802016-03-10T19:41:20 <morcos> 0.12.0
5812016-03-10T19:41:25 <CodeShark> after versionbits deployment, all block versions would be > 4
5822016-03-10T19:41:26 <sipa> ah
5832016-03-10T19:41:28 <gmaxwell> sipa: he's talking about software which doesn't have versionbits.
5842016-03-10T19:41:32 <sipa> oh, now i get it
5852016-03-10T19:41:37 <sipa> sorry
5862016-03-10T19:41:43 <morcos> CodeShark: thats what i'm trying to say, thats not how its written
5872016-03-10T19:42:17 <sipa> so increase to 5 after the first vb deployment?
5882016-03-10T19:42:23 <morcos> no no no
5892016-03-10T19:42:23 <sdaftuar> why not increase to 001...?
5902016-03-10T19:42:24 <morcos> not 5
5912016-03-10T19:42:33 <sdaftuar> consensus rule is >= 5 i guess
5922016-03-10T19:42:39 <morcos> just > 4, but you expect to see 001
5932016-03-10T19:43:03 <sipa> consensus >=4, but by default set 001...000....?
5942016-03-10T19:43:16 <morcos> >4
5952016-03-10T19:43:18 <morcos> yes
5962016-03-10T19:43:57 <jonasschnelli> morcos: but you should see it in the debug log? https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2464
5972016-03-10T19:44:13 <jonasschnelli> Agree that we should also warn in IDB (but low prio IMO).
5982016-03-10T19:44:14 <sdaftuar> jonasschnelli: that code doesn't run during initialblockdownload
5992016-03-10T19:44:35 <morcos> the assumption is if you see something that starts with 001 you think you know whats happening and you're unknown activation detector can alert you with specific information
6002016-03-10T19:44:51 <jonasschnelli> Then lets improve that and BP.
6012016-03-10T19:44:55 <morcos> and if you see soemthing that doesn't start with 001 such as a 5 or a 110...
6022016-03-10T19:45:07 <morcos> jonasschnelli: thats what we're doing , but we can't retroactively change old code
6032016-03-10T19:45:29 <CodeShark> 110... would be treated as negative, no? because for some reason signed types were used
6042016-03-10T19:45:31 <morcos> then you assume that someone is doing something you really don't understand
6052016-03-10T19:45:38 <jonasschnelli> Yes. Sure... we might not be capable of warning for the next SF.
6062016-03-10T19:45:41 <morcos> CodeShark: sure i mean 010
6072016-03-10T19:45:54 <btcdrak> morcos: there is already 011 on the network too
6082016-03-10T19:46:24 <morcos> btcdrak: exactly, and we should be warning about that (and we are now) b/c its changes our software doesn't understand
6092016-03-10T19:46:35 <btcdrak> right
6102016-03-10T19:46:38 <morcos> and if > 50/100 blocks then we turn that warning into an alert
6112016-03-10T19:47:26 *** molz has joined #bitcoin-core-dev
6122016-03-10T19:47:55 <jonasschnelli> Agree. But that raises also the question how to deploy an alert... debug.log? Yes. No.
6132016-03-10T19:48:08 <morcos> jonasschnelli: see scroll back before meeting
6142016-03-10T19:48:29 * jonasschnelli has only a 500 lines scrollback >_<
6152016-03-10T19:48:53 <morcos> sipa: so agreed that we should increase version number? should i make a new BIP for that? and we'll just soft fork it in at same time, or add to existing BIP
6162016-03-10T19:49:25 <sipa> morcos: consensus or not?
6172016-03-10T19:49:53 <morcos> sipa: consensus rule that nVersion must be >= 5.
6182016-03-10T19:50:25 <sipa> morcos: why consensus?
6192016-03-10T19:50:31 <btcdrak> morcos: confused
6202016-03-10T19:51:00 <CodeShark> before or after versionbits activation?
6212016-03-10T19:51:02 <CodeShark> still don't follow
6222016-03-10T19:51:03 <morcos> sipa: well i suppose it doesn't have to be a consensus rule...
6232016-03-10T19:51:11 <morcos> CodeShark: with the first SF that activates
6242016-03-10T19:51:17 *** moli has quit IRC
6252016-03-10T19:51:30 <morcos> sipa: but i think its more clear to me that it doesn't have problems if it is a consensus rule
6262016-03-10T19:51:36 <morcos> b/c thats how the other ones worked
6272016-03-10T19:51:44 <gmaxwell> making it consensus would cause gratitious orphaning, which we were generally trying to avoid in the design of segwit.
6282016-03-10T19:51:54 <morcos> gmaxwell: this will be before segwit
6292016-03-10T19:52:04 <sipa> i prefer not introducing new consensus logic, especially when the only argument for it is better guarantees for warnings
6302016-03-10T19:52:33 <morcos> sipa: yes thats the only difference i see. is that now we somehow can't warn on version = 4 blocks
6312016-03-10T19:52:58 <sipa> and if it's not consnesus, we can say bip9 miners without active rollouts use 001000...
6322016-03-10T19:53:38 <gmaxwell> I like 001000 in that it would encourage visualization tools to parse the bitfield instead of just displaying an integer.
6332016-03-10T19:53:43 <btcdrak> yes
6342016-03-10T19:53:50 <morcos> sipa: if its not a consensus rule, you can't be SURE that old nodes will be warned that the rules have changed... perhaps thats not worth worrying about
6352016-03-10T19:54:27 <sipa> miners can already cause total network forks
6362016-03-10T19:54:28 <btcdrak> That was my initial understanding that the new version would be 00100..0 when no sfs are being deployed
6372016-03-10T19:54:28 <morcos> its just cleaner to me
6382016-03-10T19:54:38 <sipa> are we worried that they can bypass a warning mechanism?
6392016-03-10T19:54:50 <btcdrak> sipa: no
6402016-03-10T19:56:09 *** mm_1 has joined #bitcoin-core-dev
6412016-03-10T19:56:51 <morcos> sipa: ok i guess. i'm ok with not making it a consensus rule.. but just seems weird to me... i feel like we're transitioning from an old system to a new system, and the transition should conform to the old system
6422016-03-10T19:57:09 <gmaxwell> Lets wrap the metting now and talk more about warning after. Unless there are any other subject to squeek in at the end?
6432016-03-10T19:57:10 <wumpus> meeting: 3 minutes to go
6442016-03-10T19:57:17 <morcos> but as long as we make the default 00100 then i think its just theoretical concerns
6452016-03-10T19:57:21 <sipa> yeah
6462016-03-10T19:58:17 <wumpus> #endmeeting
6472016-03-10T19:58:17 <lightningbot> Meeting ended Thu Mar 10 19:58:17 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6482016-03-10T19:58:17 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.html
6492016-03-10T19:58:17 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.txt
6502016-03-10T19:58:17 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.log.html
6512016-03-10T19:59:27 <kanzure> #action review scrollback
6522016-03-10T19:59:39 <sipa> haha
6532016-03-10T19:59:39 <btcdrak> haha
6542016-03-10T19:59:55 <btcdrak> that was a really long meeting...
6552016-03-10T19:59:56 <gmaxwell> sipa: So a concern I raised on the PR is that I'd like nodes to stop mining (e.g. error on GBT results) after a SW upgrade happens. The issue I'm trying to address is say the network successfully upgrades, and then a couple huge pools reboot and end up on pre softfork code-- e.g. bootscripts start the wrong versions; things run happily for a while, but then someone mines an invalid transaction a
6562016-03-10T20:00:01 <gmaxwell> nd then a huge amount of hashpower begins a fork. Nversion progression previously prevented this, but at the expense of creating gratitious orphans around the switchover time.
6572016-03-10T20:00:33 <morcos> gmaxwell: i was wondering about that, but do miners change their version number outside of bitcoind anyway?
6582016-03-10T20:01:07 <gmaxwell> morcos: in the past some mining hardware had hardcoded versions numbers, but I think the last couple softforks probably shook out a fair amount of that.
6592016-03-10T20:01:33 <sipa> we hope...
6602016-03-10T20:01:35 <morcos> gmaxwell: so this is another reason to make >= 5 a consensus rule
6612016-03-10T20:01:42 <Luke-Jr> morcos: they set it outside bitcoind generally
6622016-03-10T20:01:44 <morcos> if you don't you can't fix that problem for 0.12.0 miners
6632016-03-10T20:01:57 <sipa> how does that help?
6642016-03-10T20:02:21 <gmaxwell> sipa: the idea is that post SW miners would do the voluntarily shut off unless overridden.
6652016-03-10T20:03:09 <morcos> sipa: well i don't know. i took gmaxwell's scenario at face value.. but maybe it doesn't make sense. i guess the difference is whether you find out right away or not?
6662016-03-10T20:03:34 <gmaxwell> It's a difference in the size of the fork; and who takes the risks.
6672016-03-10T20:03:37 <morcos> gmaxwell: are you specficially talking about SW script upgrades? or do you mean BIP 9 soft forks?
6682016-03-10T20:03:52 <gmaxwell> BIP9 softforks.
6692016-03-10T20:04:25 <morcos> gmaxwell: can you explain a bit why the fork size would be bigger?
6702016-03-10T20:04:26 <sipa> if the vereion number is set outside of bitcoim core, then logic there won't help
6712016-03-10T20:04:47 <sipa> you just need logic that stops GBT in case the vb warning logic triggered
6722016-03-10T20:04:53 *** shawnmaten has left #bitcoin-core-dev
6732016-03-10T20:05:21 <morcos> that seems a bit risky to me to automatically stop GBT
6742016-03-10T20:05:34 <gmaxwell> morcos: Because only an exceptional circumstance would begin such a fork, it might happen months or years after the change, with no one paying attention.
6752016-03-10T20:05:40 <morcos> i mean i guess it does take 95% of miners to cause a fake trigger
6762016-03-10T20:06:20 <gmaxwell> morcos: the existing warning stuff is stupid, boarderline broken-- which is why I was suggesting it only for BIP9 activation.
6772016-03-10T20:07:05 <jonasschnelli> Is https://github.com/sipa/bitcoin/tree/segwit still the most recent segnet working tree?
6782016-03-10T20:07:30 <jonasschnelli> BTW: how changes the https://github.com/bitcoin icon? Nice one!
6792016-03-10T20:07:40 <jonasschnelli> *who
6802016-03-10T20:07:47 <jonasschnelli> *changed (damit)
6812016-03-10T20:07:57 <gmaxwell> morcos: the idea that the network in bulk could silently regress rules (though detectable by the nodes themselves) concerns me; but I don't know how much of a pratical concern it should be.
6822016-03-10T20:09:06 <morcos> gmaxwell: the fact that nVersion is set outside bitcoind is disturbing, but imagine 1% of miners don't upgrade to versionbits and the 68/112/113 soft fork
6832016-03-10T20:09:49 <morcos> they will happily mine version 4 blocks for months until they accidentally mine an invalid BIP68 tx, and then all the SPV miners will just build off them
6842016-03-10T20:10:00 <morcos> as opposed to htat thing happening right away if the nVersion had to increase
6852016-03-10T20:10:52 * Luke-Jr wonders if versionbits has GBT extensions yet
6862016-03-10T20:12:06 <sipa> Luke-Jr: is it not enough to report nVersionm
6872016-03-10T20:12:08 <sipa> ?
6882016-03-10T20:12:16 <gmaxwell> morcos: right, so two questions: avoiding that for this one change vs in the long term.
6892016-03-10T20:12:21 <Luke-Jr> sipa: no, because nVersion could mean different things
6902016-03-10T20:12:46 <morcos> gmaxwell: yes, i agree that perhaps your long term change makes sense
6912016-03-10T20:13:09 <sdaftuar> gmaxwell: morcos: seems to me like we should do both things you guys are suggesting
6922016-03-10T20:13:12 <morcos> i mean your change now to solve the longer term problem
6932016-03-10T20:13:22 <sipa> Luke-Jr: ?
6942016-03-10T20:13:46 <Luke-Jr> sipa: version=69632 could mean different softforks depending on context of the block
6952016-03-10T20:13:57 <sipa> so?
6962016-03-10T20:14:10 <gmaxwell> morcos: in the long term I think it's adequate to refuse to serve GBT requests after a BIP9 activiation triggers. (and perhaps mine only empty blocks during the quiet period for further visibility)
6972016-03-10T20:14:22 <gmaxwell> sipa: matters if you're adding additional txn to the gbt output.
6982016-03-10T20:14:24 <Luke-Jr> sipa: so the GBT client won't know which softforks to enable
6992016-03-10T20:14:37 <gmaxwell> morcos: for the current issue, I agree that an upgrade to >=5 may be needed.
7002016-03-10T20:14:46 <sipa> Luke-Jr: nobody is doing that, right?
7012016-03-10T20:15:20 <gmaxwell> Luke-Jr: I think you actually want to expose the mempool validation flags in GBT for that, not just softforks.
7022016-03-10T20:15:26 <Luke-Jr> sipa: adding transactions, not at the moment AFAIK, but GBT clients always must be aware of what the block rules are to some extent
7032016-03-10T20:15:38 <sdaftuar> note that the version bits do not indicate what the consensus rules are
7042016-03-10T20:15:50 <sipa> Luke-Jr: i guess those can be per-softfork extensions to GBT
7052016-03-10T20:16:11 <sipa> as their effects can be hard to generalize
7062016-03-10T20:16:13 <Luke-Jr> sipa: some way to indicate them is still needed, but yes
7072016-03-10T20:16:51 <Luke-Jr> ie, we don't want old GBT clients to think they can handle bit X, but interpret it differently
7082016-03-10T20:17:10 <morcos> Luke-Jr: any time you are setting bit X it by definition means that soft fork isn't even active yet
7092016-03-10T20:17:21 <morcos> or at least by implementation
7102016-03-10T20:18:03 <Luke-Jr> more likely the GBT client would be the side setting the bits it implements
7112016-03-10T20:20:07 <gmaxwell> Luke-Jr: trying to move network consensus logic into gbt clients seems inadvisible and should only be done where strictly needed.
7122016-03-10T20:22:45 <sipa> gmaxwell: +1
7132016-03-10T20:25:15 <BlueMatt> instead we should be pulling out as MUCH logic as possible from gbt clients/pool servers into bitcoind
7142016-03-10T20:25:18 <BlueMatt> and also kill getblocktemplate
7152016-03-10T20:25:23 <BlueMatt> because no one uses it and everyone hates it
7162016-03-10T20:29:48 *** Thireus has quit IRC
7172016-03-10T20:30:06 *** Thireus has joined #bitcoin-core-dev
7182016-03-10T20:31:01 <gmaxwell> BlueMatt: so mean. By "kill" you mean "optimize".
7192016-03-10T20:31:14 *** Thireus has quit IRC
7202016-03-10T20:31:22 <BlueMatt> gmaxwell: I mean replace entirely
7212016-03-10T20:31:22 <sipa> making it observable what is being mined makes sense
7222016-03-10T20:31:38 *** Thireus has joined #bitcoin-core-dev
7232016-03-10T20:32:06 <BlueMatt> gmaxwell: no one cares about the features provided by gbt, and every time I talk to /anyone/ using it (except eloipool) the response is "omg, just replace it with a binary something-or-other that has nearly opposite features of what gbt provides"
7242016-03-10T20:32:14 <sipa> but i don't think GBT's goal should be letting block construction outside of bitcoind
7252016-03-10T20:32:21 <BlueMatt> ^that
7262016-03-10T20:32:28 <BlueMatt> is also what people want
7272016-03-10T20:32:30 *** Thireus has joined #bitcoin-core-dev
7282016-03-10T20:32:43 <BlueMatt> most folks just want the minimal data they need to be able to twiddle extranonce
7292016-03-10T20:32:47 <gmaxwell> if the nonce in header fork were done we could go back to getwork. :)
7302016-03-10T20:32:53 <BlueMatt> and that
7312016-03-10T20:33:27 *** Thireus has quit IRC
7322016-03-10T20:36:46 *** Thireus has joined #bitcoin-core-dev
7332016-03-10T20:37:48 <btcdrak> BlueMatt: is there any more progress on HF contents?
7342016-03-10T20:38:40 <BlueMatt> btcdrak: I havent seen anything on bitcoin-dev?
7352016-03-10T20:38:43 <BlueMatt> btcdrak: also #bitcoin-dev
7362016-03-10T20:38:54 *** Thireus has quit IRC
7372016-03-10T20:39:03 <Luke-Jr> sipa: so just give up on decentralised mining entirely?
7382016-03-10T20:39:15 <BlueMatt> Luke-Jr: that is a false dichotomy
7392016-03-10T20:39:48 <gmaxwell> there are other ways to do that, e.g. telling bitcoind what the requirements are for a block it creates and letting it create it.
7402016-03-10T20:39:53 <BlueMatt> Luke-Jr: the amount of data you need to twiddle the extranonce is almost the same as the amount of data you need to create a coinbase for gbt in the same way you want people to do decentralized mining
7412016-03-10T20:39:55 <gmaxwell> E.g. coinbase must pay to X.
7422016-03-10T20:40:03 <BlueMatt> gmaxwell: you can create the coinbase downstream of bitcoind
7432016-03-10T20:40:21 *** Thireus has joined #bitcoin-core-dev
7442016-03-10T20:40:24 <gmaxwell> only by implementing consensus rules outside of bitcoind, however.
7452016-03-10T20:40:30 *** Thireus has quit IRC
7462016-03-10T20:40:39 <BlueMatt> bitcoind should be able to tell you things like requirements for what scriptSig should look like
7472016-03-10T20:40:49 <gmaxwell> BlueMatt: you are reinventing GBT. :)
7482016-03-10T20:40:55 <Luke-Jr> gmaxwell: this is higher latency
7492016-03-10T20:41:04 *** Thireus has joined #bitcoin-core-dev
7502016-03-10T20:41:05 <BlueMatt> gmaxwell: no, gbt gives you all kinds of shit like details for every transaction in the block
7512016-03-10T20:41:12 <BlueMatt> you should only be providing minimal merkle tree info
7522016-03-10T20:41:29 <gmaxwell> BlueMatt: which is actually needed if you're building your own coinbase, because you may need to drop out transactions to make room.
7532016-03-10T20:41:32 <BlueMatt> gmaxwell: also, phantomcircuit has a protocol designed for this
7542016-03-10T20:41:34 <BlueMatt> that is pretty minimal
7552016-03-10T20:41:54 *** Thireus has quit IRC
7562016-03-10T20:42:00 <BlueMatt> gmaxwell: "meh", your coinbase shouldnt be /that/ large
7572016-03-10T20:42:22 <gmaxwell> go look at a p2pool coinbase txn.
7582016-03-10T20:42:31 <BlueMatt> I'm aware
7592016-03-10T20:43:12 *** Eliel has quit IRC
7602016-03-10T20:43:15 <BlueMatt> ehh, whatever, fine, give bitcoind a coinbase output list
7612016-03-10T20:43:54 <BlueMatt> either way, push complexity into bitcoind :)
7622016-03-10T20:43:56 * Luke-Jr notes that's the approach he took originally and gave up after years of it not being merged.
7632016-03-10T20:43:57 <morcos> i know nothing about mining, so hopefully im not wasting peoples time
7642016-03-10T20:44:14 <morcos> but it seems to me that it would be reasonable to require miners to run a bitcoind
7652016-03-10T20:44:16 *** Thireus has joined #bitcoin-core-dev
7662016-03-10T20:44:32 * gmaxwell plays taps for 'coinbaser'
7672016-03-10T20:44:35 <morcos> and we should provide an API by which they can submit a block to to a pool and say hey, is this acceptable
7682016-03-10T20:44:41 <morcos> and then they can work on that
7692016-03-10T20:44:48 <morcos> i know thats the idea behind GBT (sort of)
7702016-03-10T20:44:56 <morcos> but instead of building all the functionality into the API
7712016-03-10T20:44:58 <BlueMatt> Luke-Jr: to be fair, people also hate json, so need something outside the existing rpc
7722016-03-10T20:45:06 *** Thireus has quit IRC
7732016-03-10T20:45:07 <Luke-Jr> BlueMatt: it wasn't via RPC ;)
7742016-03-10T20:45:17 <BlueMatt> hmm, fair enough
7752016-03-10T20:45:21 <morcos> just have a testBlock RPC call that the pool can say, yeah thats cool pays the right coinbase or whatever and is valid according to our consensus rules
7762016-03-10T20:45:51 *** Thireus has joined #bitcoin-core-dev
7772016-03-10T20:46:03 <Luke-Jr> preferably there'd be a way to avoid sending the entire gen-tx around.
7782016-03-10T20:46:27 *** Thireus has quit IRC
7792016-03-10T20:46:49 <BlueMatt> Luke-Jr: so revive it now :)
7802016-03-10T20:46:55 <Luke-Jr> BlueMatt: ?
7812016-03-10T20:46:55 *** laurentmt has quit IRC
7822016-03-10T20:47:00 *** Thireus has joined #bitcoin-core-dev
7832016-03-10T20:47:15 *** belcher has joined #bitcoin-core-dev
7842016-03-10T20:47:55 <Luke-Jr> not sure the point
7852016-03-10T20:53:03 <jtimon> sipa morcos, what about always producing 0010... (even when no deployments are being checked) after the the starttime of the first deployment? (my own solution was to just do it right away for new miners, even before any start time, but sipa complained that old nodes would get warnings before start time [they're going to receive warnings before activation anyway, so I wasn't too concerned about that])
7862016-03-10T20:53:24 *** Eliel has joined #bitcoin-core-dev
7872016-03-10T20:53:38 <morcos> jtimon: yeah i think its strictly better for the old nodes to get the warnings earlier
7882016-03-10T20:53:44 *** Thireus has quit IRC
7892016-03-10T20:54:06 *** Thireus has joined #bitcoin-core-dev
7902016-03-10T20:54:25 <jtimon> that was my point, the dicsussion is there in some outdated comment in #7575
7912016-03-10T20:54:30 *** jgarzik has joined #bitcoin-core-dev
7922016-03-10T20:54:30 *** jgarzik has joined #bitcoin-core-dev
7932016-03-10T20:55:01 <jtimon> and that solution doesn't require any additional consensus checks, which seems to be what people dislike more from your proposal
7942016-03-10T20:59:22 *** e0_ has joined #bitcoin-core-dev
7952016-03-10T20:59:36 <e0_> The variables pathCached and pathCachedNetSpecific in util.cpp appears to be unused (find doesn't return any results of them being set) but can cause interesting segfaults since depending on the order in which objects are created they can be uninitialized. Are they actually unused
7962016-03-10T20:59:41 <e0_> [3:38]
7972016-03-10T20:59:44 <e0_> ?
7982016-03-10T20:59:47 <e0_> https://github.com/bitcoin/bitcoin/blob/master/src/util.cpp#L485
7992016-03-10T20:59:55 <e0_> I have a pull request, but I don't want to waste peoples time in case I am missing something
8002016-03-10T21:00:58 *** Thireus has quit IRC
8012016-03-10T21:01:21 *** Thireus has joined #bitcoin-core-dev
8022016-03-10T21:04:20 *** Thireus has quit IRC
8032016-03-10T21:12:24 *** wallet42 has quit IRC
8042016-03-10T21:14:51 *** gevs has quit IRC
8052016-03-10T21:18:16 *** wallet42 has joined #bitcoin-core-dev
8062016-03-10T21:23:01 *** Thireus has joined #bitcoin-core-dev
8072016-03-10T21:25:42 *** Thireus has quit IRC
8082016-03-10T21:26:33 *** Thireus has joined #bitcoin-core-dev
8092016-03-10T21:57:39 *** Guyver2 has quit IRC
8102016-03-10T22:04:42 *** jgarzik has quit IRC
8112016-03-10T22:12:02 *** mrkent_ has joined #bitcoin-core-dev
8122016-03-10T22:14:28 *** Arnavion has quit IRC
8132016-03-10T22:14:44 *** mrkent has quit IRC
8142016-03-10T22:29:54 *** Arnavion has joined #bitcoin-core-dev
8152016-03-10T22:35:57 *** gevs has joined #bitcoin-core-dev
8162016-03-10T22:47:45 *** zooko has joined #bitcoin-core-dev
8172016-03-10T22:55:45 *** lahwran is now known as lauren
8182016-03-10T23:11:13 <dgenr8> 144*365
8192016-03-10T23:15:28 *** Adiabat has quit IRC
8202016-03-10T23:17:20 *** gevs has quit IRC
8212016-03-10T23:20:02 *** jannes has quit IRC
8222016-03-10T23:21:50 *** musalbas has joined #bitcoin-core-dev
8232016-03-10T23:22:07 *** randy-waterhouse has joined #bitcoin-core-dev
8242016-03-10T23:22:40 *** musalbas has left #bitcoin-core-dev
8252016-03-10T23:22:54 *** musalbas has joined #bitcoin-core-dev
8262016-03-10T23:26:09 *** Arnavion has quit IRC
8272016-03-10T23:48:30 *** laurentmt has joined #bitcoin-core-dev
8282016-03-10T23:49:08 *** laurentmt has quit IRC