12017-10-12T00:04:14 <bitcoin-git> [bitcoin] fanquake closed pull request #11488: Codeai fixes: remove dead code, prevent possible division by zero. (master...codeai-fixes) https://github.com/bitcoin/bitcoin/pull/11488
22017-10-12T00:04:28 *** fanquake has joined #bitcoin-core-dev
32017-10-12T00:04:40 *** fanquake has joined #bitcoin-core-dev
42017-10-12T00:04:56 <fanquake> I guess their AI didn't bother checking the open pull requests..
52017-10-12T00:12:17 *** jb55 has quit IRC
62017-10-12T00:16:21 <esotericnonsense> `CodeAi suggests` is hilarious
72017-10-12T00:20:05 <sipa> they're pretty good suggestions
82017-10-12T00:24:39 *** Ylbam has quit IRC
92017-10-12T00:35:06 <esotericnonsense> fanquake: you really missed a trick with the response. 'fanquake suggests an issue is raised on the CodeAi github regarding ...' :p
102017-10-12T00:36:24 <TD-Linux> I'm impressed that none of them were false positives
112017-10-12T00:36:57 <sipa> TD-Linux: perhaps they're human-filtered?
122017-10-12T00:39:43 <fanquake> sipa If you're are doing some review, could you check #11073 ?
132017-10-12T00:39:45 <gribble> https://github.com/bitcoin/bitcoin/issues/11073 | Remove dead store in ecdsa_signature_parse_der_lax. by BitonicEelis · Pull Request #11073 · bitcoin/bitcoin · GitHub
142017-10-12T00:39:53 *** chartractegg has joined #bitcoin-core-dev
152017-10-12T00:45:52 *** chartractegg has quit IRC
162017-10-12T00:49:14 *** chartractegg has joined #bitcoin-core-dev
172017-10-12T00:52:08 *** meshcollider has quit IRC
182017-10-12T00:59:51 *** Chris_Stewart_5 has joined #bitcoin-core-dev
192017-10-12T01:01:17 *** dabura667 has joined #bitcoin-core-dev
202017-10-12T01:07:06 *** jb55 has joined #bitcoin-core-dev
212017-10-12T01:17:10 *** wxss has quit IRC
222017-10-12T01:23:25 *** PaulCapestany has quit IRC
232017-10-12T01:23:49 *** chartractegg has quit IRC
242017-10-12T01:24:05 *** Chris_Stewart_5 has quit IRC
252017-10-12T01:32:28 *** wxss has joined #bitcoin-core-dev
262017-10-12T01:37:23 *** PaulCapestany has joined #bitcoin-core-dev
272017-10-12T01:42:12 *** chartractegg has joined #bitcoin-core-dev
282017-10-12T01:45:17 *** Chris_Stewart_5 has joined #bitcoin-core-dev
292017-10-12T01:54:50 *** Deacyde has joined #bitcoin-core-dev
302017-10-12T02:04:13 *** chartractegg has quit IRC
312017-10-12T02:07:08 *** ghost43 has quit IRC
322017-10-12T02:12:02 *** Chris_Stewart_5 has quit IRC
332017-10-12T02:13:17 *** ghost43 has joined #bitcoin-core-dev
342017-10-12T02:13:31 *** bigtimmyc has joined #bitcoin-core-dev
352017-10-12T02:13:39 <bigtimmyc> hello
362017-10-12T02:14:25 <bigtimmyc> looking for some advice fellas
372017-10-12T02:16:24 <sipa> you're generally better off on #bitcoin, but without asking a question it's hard to know
382017-10-12T02:17:16 <bigtimmyc> just looking for general starter advice for development
392017-10-12T02:17:21 <bigtimmyc> should I go to #bitcoin?
402017-10-12T02:18:06 <bigtimmyc> just a little confused with how to get started
412017-10-12T02:19:38 *** chartractegg has joined #bitcoin-core-dev
422017-10-12T02:20:05 <wxss> bigtimmyc: this channel is for development of the Bitcoin Core client, you may want to try #bitcoin for starting advice
432017-10-12T02:20:36 <bigtimmyc> sounds good, thanks
442017-10-12T02:20:41 <bigtimmyc> JOIN #bitcoin
452017-10-12T02:20:43 <bigtimmyc> fuck
462017-10-12T02:20:47 <sipa> almost!
472017-10-12T02:26:53 *** chartractegg has quit IRC
482017-10-12T02:39:26 *** btcdrak has joined #bitcoin-core-dev
492017-10-12T02:48:27 *** clusk has joined #bitcoin-core-dev
502017-10-12T03:10:17 *** meshcollider has joined #bitcoin-core-dev
512017-10-12T03:14:24 *** goatpig has joined #bitcoin-core-dev
522017-10-12T03:15:22 *** xHire has quit IRC
532017-10-12T03:20:59 <BlueMatt> someone wanna close #11481? he's asking why there are two tx sizes (hint: segwit.....)
542017-10-12T03:21:00 <gribble> https://github.com/bitcoin/bitcoin/issues/11481 | Different size and same transaction · Issue #11481 · bitcoin/bitcoin · GitHub
552017-10-12T03:52:27 *** owowo has quit IRC
562017-10-12T03:58:11 *** owowo has joined #bitcoin-core-dev
572017-10-12T04:08:34 *** wxss has quit IRC
582017-10-12T04:15:21 *** Deacydal has joined #bitcoin-core-dev
592017-10-12T04:17:26 *** Deacyde has quit IRC
602017-10-12T04:26:59 *** shesek has joined #bitcoin-core-dev
612017-10-12T04:26:59 *** shesek has joined #bitcoin-core-dev
622017-10-12T04:44:54 <bitcoin-git> [bitcoin] kallewoof opened pull request #11489: [wallet] sendtoaddress style argument (master...201709_segwitwallet2_sendtoaddress) https://github.com/bitcoin/bitcoin/pull/11489
632017-10-12T04:53:14 *** CubicEarth has joined #bitcoin-core-dev
642017-10-12T04:57:23 *** Victorsueca has quit IRC
652017-10-12T04:58:31 *** Victorsueca has joined #bitcoin-core-dev
662017-10-12T05:04:30 *** goatpig has quit IRC
672017-10-12T05:28:55 *** Ylbam has joined #bitcoin-core-dev
682017-10-12T05:30:29 *** CubicEarth has quit IRC
692017-10-12T05:48:49 *** bigtimmyc has quit IRC
702017-10-12T05:49:21 *** DrOlmer has quit IRC
712017-10-12T05:49:53 *** DrOlmer has joined #bitcoin-core-dev
722017-10-12T05:57:11 *** fanquake has quit IRC
732017-10-12T06:40:30 *** clusk has quit IRC
742017-10-12T06:41:04 *** clusk has joined #bitcoin-core-dev
752017-10-12T06:45:40 *** clusk has quit IRC
762017-10-12T06:48:41 *** clusk has joined #bitcoin-core-dev
772017-10-12T06:56:14 *** h1d has joined #bitcoin-core-dev
782017-10-12T06:56:25 *** BashCo has quit IRC
792017-10-12T07:00:38 *** RoyceX has joined #bitcoin-core-dev
802017-10-12T07:01:38 <bitcoin-git> [bitcoin] justicz closed pull request #11201: [WIP] [RPC] Add verifyrawtransaction RPC (master...maxj_add_verify_tx_rpc) https://github.com/bitcoin/bitcoin/pull/11201
812017-10-12T07:18:04 *** BashCo has joined #bitcoin-core-dev
822017-10-12T07:19:01 *** sanada has quit IRC
832017-10-12T07:20:33 *** Guyver2 has joined #bitcoin-core-dev
842017-10-12T07:22:05 *** RoyceX has quit IRC
852017-10-12T07:24:37 *** sanada has joined #bitcoin-core-dev
862017-10-12T07:54:12 *** pbase has joined #bitcoin-core-dev
872017-10-12T07:58:30 *** Emcy has quit IRC
882017-10-12T08:08:19 *** promag has joined #bitcoin-core-dev
892017-10-12T08:17:37 *** Guyver2 has quit IRC
902017-10-12T08:19:34 *** alreadylate has joined #bitcoin-core-dev
912017-10-12T08:24:00 *** alreadylate has quit IRC
922017-10-12T08:25:19 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
932017-10-12T08:29:57 *** Emcy has joined #bitcoin-core-dev
942017-10-12T08:32:24 *** Emcy_ has joined #bitcoin-core-dev
952017-10-12T08:32:40 *** promag has quit IRC
962017-10-12T08:33:35 *** clusk has quit IRC
972017-10-12T08:33:37 *** Emcy has quit IRC
982017-10-12T08:35:44 *** SopaXorzTaker has quit IRC
992017-10-12T08:38:03 *** Ylbam has quit IRC
1002017-10-12T08:43:15 *** SopaXorzTaker has joined #bitcoin-core-dev
1012017-10-12T09:05:27 *** Emcy_ has quit IRC
1022017-10-12T09:06:03 *** Emcy has joined #bitcoin-core-dev
1032017-10-12T09:19:07 *** promag has joined #bitcoin-core-dev
1042017-10-12T09:21:10 *** promag has quit IRC
1052017-10-12T09:22:03 *** timothy has joined #bitcoin-core-dev
1062017-10-12T09:36:17 *** promag has joined #bitcoin-core-dev
1072017-10-12T09:38:19 *** promag has quit IRC
1082017-10-12T09:47:16 *** promag has joined #bitcoin-core-dev
1092017-10-12T09:53:31 *** roadcrap has joined #bitcoin-core-dev
1102017-10-12T10:02:22 *** h1d has quit IRC
1112017-10-12T10:02:40 *** pbase has quit IRC
1122017-10-12T10:05:04 *** dabura667 has quit IRC
1132017-10-12T10:17:50 *** promag has quit IRC
1142017-10-12T10:19:07 *** promag has joined #bitcoin-core-dev
1152017-10-12T10:22:19 *** promag has quit IRC
1162017-10-12T10:29:08 *** btcdrak has quit IRC
1172017-10-12T10:32:12 *** AaronvanW has joined #bitcoin-core-dev
1182017-10-12T10:37:15 *** wxss has joined #bitcoin-core-dev
1192017-10-12T10:40:55 *** xHire has joined #bitcoin-core-dev
1202017-10-12T10:47:40 *** Emcy has quit IRC
1212017-10-12T10:48:21 *** Emcy has joined #bitcoin-core-dev
1222017-10-12T10:50:25 *** Aaronvan_ has joined #bitcoin-core-dev
1232017-10-12T10:52:57 *** AaronvanW has quit IRC
1242017-10-12T10:58:53 *** Emcy has quit IRC
1252017-10-12T10:59:28 *** Emcy has joined #bitcoin-core-dev
1262017-10-12T11:01:52 *** Emcy has quit IRC
1272017-10-12T11:02:10 *** Emcy has joined #bitcoin-core-dev
1282017-10-12T11:27:22 *** esotericnonsense has quit IRC
1292017-10-12T11:34:42 *** SopaXorzTaker has quit IRC
1302017-10-12T11:40:41 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/892809309c1b...a865b38bf332
1312017-10-12T11:40:41 <bitcoin-git> bitcoin/master 55509f1 practicalswift: Document assumptions that are being made to avoid division by zero
1322017-10-12T11:40:42 <bitcoin-git> bitcoin/master a865b38 Wladimir J. van der Laan: Merge #11133: Document assumptions that are being made to avoid division by zero...
1332017-10-12T11:41:12 <bitcoin-git> [bitcoin] laanwj closed pull request #11133: Document assumptions that are being made to avoid division by zero (master...div0) https://github.com/bitcoin/bitcoin/pull/11133
1342017-10-12T11:41:37 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a865b38bf332...3bb77ebee6e3
1352017-10-12T11:41:38 <bitcoin-git> bitcoin/master bfebc0b Eelis: Remove dead store in ecdsa_signature_parse_der_lax....
1362017-10-12T11:41:38 <bitcoin-git> bitcoin/master 3bb77eb Wladimir J. van der Laan: Merge #11073: Remove dead store in ecdsa_signature_parse_der_lax....
1372017-10-12T11:42:04 <bitcoin-git> [bitcoin] laanwj closed pull request #11073: Remove dead store in ecdsa_signature_parse_der_lax. (master...deadstore) https://github.com/bitcoin/bitcoin/pull/11073
1382017-10-12T12:01:03 *** xwin has joined #bitcoin-core-dev
1392017-10-12T12:01:13 *** xwin has left #bitcoin-core-dev
1402017-10-12T12:04:09 *** AaronvanW has joined #bitcoin-core-dev
1412017-10-12T12:06:41 *** Aaronvan_ has quit IRC
1422017-10-12T12:29:04 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1432017-10-12T12:46:57 *** PaulCapestany has quit IRC
1442017-10-12T12:49:13 *** meshcollider has quit IRC
1452017-10-12T12:55:06 <bitcoin-git> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/3bb77ebee6e3...f74459dba6de
1462017-10-12T12:55:07 <bitcoin-git> bitcoin/master edafc71 Russell Yanofsky: Fix uninitialized URI in batch RPC requests...
1472017-10-12T12:55:07 <bitcoin-git> bitcoin/master e02007a Russell Yanofsky: Limit AuthServiceProxyWrapper.__getattr__ wrapping...
1482017-10-12T12:55:08 <bitcoin-git> bitcoin/master 9f67646 Russell Yanofsky: Make AuthServiceProxy._batch method usable...
1492017-10-12T12:55:38 <bitcoin-git> [bitcoin] laanwj closed pull request #11277: Fix uninitialized URI in batch RPC requests (master...pr/mb) https://github.com/bitcoin/bitcoin/pull/11277
1502017-10-12T13:22:59 *** promag has joined #bitcoin-core-dev
1512017-10-12T13:38:48 *** merehap_ has quit IRC
1522017-10-12T13:42:23 *** Chris_Stewart_5 has quit IRC
1532017-10-12T13:49:53 *** DrOlmer has quit IRC
1542017-10-12T13:50:04 *** DrOlmer has joined #bitcoin-core-dev
1552017-10-12T13:56:44 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1562017-10-12T14:22:37 <wumpus> github has something new apparently
1572017-10-12T14:22:38 <wumpus> Label issues and pull requests for new contributors
1582017-10-12T14:22:38 <wumpus> Now, GitHub will help potential first-time contributors discover issues labeled with help wanted or good first issue
1592017-10-12T14:24:17 <wumpus> a good idea, though I don't like that we have to add labels in exactly their syntax (and probably capitalization) now
1602017-10-12T14:25:10 *** wraithm has joined #bitcoin-core-dev
1612017-10-12T14:30:51 <Sentineo> yeah I saw that, but the idea is certainly nice
1622017-10-12T14:31:08 *** NielsvG has joined #bitcoin-core-dev
1632017-10-12T14:38:22 <wumpus> maybe rename "Easy to implement" to "good first issue"? it's the same idea after all
1642017-10-12T14:38:43 <wumpus> was introduced for the same reason
1652017-10-12T14:39:41 <Sentineo> well easy to implement is relative :) easy for who?
1662017-10-12T14:41:09 *** promag has quit IRC
1672017-10-12T14:52:12 <wumpus> it only makes sense as a label if it's broadly true
1682017-10-12T14:54:13 <Sentineo> indeed
1692017-10-12T14:54:22 <wumpus> everything might be easy to implement for a single person with matching super-specialized knowledge
1702017-10-12T14:55:18 <wumpus> we can add an "easy to implement for sipa" label and add it to all issues *ducks*
1712017-10-12T14:58:09 *** harding has joined #bitcoin-core-dev
1722017-10-12T14:58:37 <sdaftuar> +1
1732017-10-12T15:11:24 <midnightmagic> +1
1742017-10-12T15:19:24 <Sentineo> :D
1752017-10-12T15:24:30 *** BashCo has quit IRC
1762017-10-12T15:25:07 *** BashCo has joined #bitcoin-core-dev
1772017-10-12T15:26:57 *** wasi has joined #bitcoin-core-dev
1782017-10-12T15:29:36 *** BashCo has quit IRC
1792017-10-12T15:45:40 *** jb55 has quit IRC
1802017-10-12T15:47:17 *** Ofelia has joined #bitcoin-core-dev
1812017-10-12T15:50:47 *** BashCo has joined #bitcoin-core-dev
1822017-10-12T15:53:24 *** ananteris has quit IRC
1832017-10-12T16:26:43 *** jb55 has joined #bitcoin-core-dev
1842017-10-12T16:28:13 *** promag has joined #bitcoin-core-dev
1852017-10-12T16:31:26 *** karelb has joined #bitcoin-core-dev
1862017-10-12T16:42:23 <promag> sipa: in case you missed https://github.com/bitcoin/bitcoin/pull/11221/files#r143359150
1872017-10-12T16:51:29 *** Emcy has quit IRC
1882017-10-12T16:55:01 *** promag has quit IRC
1892017-10-12T16:56:52 *** ghost43 has quit IRC
1902017-10-12T16:57:10 *** ghost43 has joined #bitcoin-core-dev
1912017-10-12T17:26:04 *** Ylbam has joined #bitcoin-core-dev
1922017-10-12T17:27:00 *** timothy has quit IRC
1932017-10-12T17:33:50 *** Giszmo has quit IRC
1942017-10-12T17:45:04 *** laurentmt has joined #bitcoin-core-dev
1952017-10-12T17:45:54 *** laurentmt has quit IRC
1962017-10-12T18:17:04 *** mess110 has joined #bitcoin-core-dev
1972017-10-12T18:26:07 *** Giszmo has joined #bitcoin-core-dev
1982017-10-12T18:26:11 <mess110> hi, I am trying to work on https://github.com/bitcoin/bitcoin/issues/7734 and I wanted to ask for advice
1992017-10-12T18:26:23 <mess110> I added the icon on the GUI, designed the icon for proxy/no proxy (still needs work, but I got this), you can see my progress here:
2002017-10-12T18:26:27 *** wxss has quit IRC
2012017-10-12T18:26:37 <mess110> https://github.com/bitcoin/bitcoin/compare/master...mess110:add_proxy_icon?expand=1
2022017-10-12T18:26:43 <mess110> I am stuck figuring out if I need to show the icon enabled or disabled depending if a proxy/tor proxy is used.
2032017-10-12T18:26:51 <mess110> I can look into settings, but I don't think that is a complete solution because it doesn't handle command line options.
2042017-10-12T18:26:57 <mess110> I tried itterating over proxies here: https://github.com/bitcoin/bitcoin/compare/master...mess110:add_proxy_icon?expand=1#diff-0db7dd184df07a48c307ccc182021a68R266
2052017-10-12T18:27:03 <mess110> but I always get not connected, even with tor browser running locally, so I was wondering if someone could give me some advice, thanks in advance
2062017-10-12T18:34:41 *** mmgen has joined #bitcoin-core-dev
2072017-10-12T18:40:46 <luke-jr> I guess there's a question of what conditions the icon should be lit; Tor *only*, or Tor at all?
2082017-10-12T18:41:16 <sipa> how do we know you're proxying through tor?
2092017-10-12T18:42:47 <wumpus> in the case of torcontrol automatically using tor it's easy
2102017-10-12T18:42:57 <wumpus> for an arbitrary socks5 proxy it's harder to say
2112017-10-12T18:43:11 <mess110> the way I see it: no proxy icon not lit. other proxy proxy icon lit. tor proxy different icon
2122017-10-12T18:43:56 <wumpus> maybe easier to do would be a proxy icon
2132017-10-12T18:44:02 <wumpus> then later on worry about tor detection
2142017-10-12T18:44:12 <wumpus> (say, in a followup PR)
2152017-10-12T18:44:21 <sipa> there is -tor, but that's about configuring a proxy for tor connections
2162017-10-12T18:44:24 <mess110> ok, but would checking the settings be enough?
2172017-10-12T18:44:33 <sipa> mess110: no
2182017-10-12T18:44:48 <wumpus> you should check the same thing getnetworkinfo checks
2192017-10-12T18:44:49 <sipa> in normal circumstances you'd just use -proxy
2202017-10-12T18:45:03 <wumpus> it has the information, per network, whether a proxy is used
2212017-10-12T18:45:47 <luke-jr> our node needs to know if it has a Tor address to advertise..
2222017-10-12T18:45:47 <wumpus> I'd say show the icon only if all networks use a proxy, becaues that's usually what the user wants to be informed of ("is everything I do proxied")
2232017-10-12T18:46:11 <luke-jr> so there should never be a question whether Tor is setup or not
2242017-10-12T18:46:18 <wumpus> luke-jr: yeah advertising the onion is what torcontrol does, let's focus on proxy first, tor later
2252017-10-12T18:47:00 <luke-jr> "are we binding any non-localhost ports?"
2262017-10-12T18:47:04 <wumpus> if a proxy is used for everything *and* that is the tor proxy, it could show a special tor icon, but that's easier to do
2272017-10-12T18:47:16 <wumpus> eh harder
2282017-10-12T18:47:24 <wumpus> this is not really about binding
2292017-10-12T18:47:37 <wumpus> proxy is foremost about outgoing connections
2302017-10-12T18:47:39 <mess110> sipa: I am using the GUI to set tor proxy and restarting the client. there is a chance I am not actually connected though a proxy because I am doing similar things like getnetworkinfo
2312017-10-12T18:47:49 <wumpus> though you could check the listening too...
2322017-10-12T18:48:14 <wumpus> if you set a proxy in the GUI, it will use a proxy next restart
2332017-10-12T18:48:16 <luke-jr> wumpus: I'm not sure why users would care only about outgoing connections?
2342017-10-12T18:48:27 <wumpus> luke-jr: because that's the only ones that go through a proxy
2352017-10-12T18:48:39 <luke-jr> we broadcast transactions on incoming connections too
2362017-10-12T18:48:54 <luke-jr> presumably the icon is desired to get a feel for privacy level
2372017-10-12T18:48:55 <wumpus> sure, but if you provide -proxy at least it disables incoming connections
2382017-10-12T18:50:24 <luke-jr> IMO, we should have 3 states: public, proxy (no non-local inbound connections accepted; outbound via proxy), and tor (no non-local inbound connections accepted; Tor hidden service address configured [and known to be working?])
2392017-10-12T18:50:48 <wumpus> yeah that sounds ok
2402017-10-12T18:51:43 <mess110> luke-jr: thats my long term plan now. will focus on detecting public/proxy in my first PR
2412017-10-12T18:52:16 <mess110> and thx, I got confirmation that getnetworkinfo is what I should look at
2422017-10-12T18:52:29 *** meshcollider has joined #bitcoin-core-dev
2432017-10-12T18:52:30 <luke-jr> yeah, that's probably a good example to go from
2442017-10-12T18:55:36 *** clarkmoody has joined #bitcoin-core-dev
2452017-10-12T19:00:04 <sipa> WOOSH
2462017-10-12T19:00:13 <achow101> meeting?
2472017-10-12T19:00:26 <Chris_Stewart_5> and HERE WE GO.
2482017-10-12T19:00:55 <gmaxwell> wumpus
2492017-10-12T19:01:06 <jonasschnelli> hi
2502017-10-12T19:01:37 *** Emcy has joined #bitcoin-core-dev
2512017-10-12T19:02:11 <achow101> hi
2522017-10-12T19:02:17 <wumpus> #startmeeting
2532017-10-12T19:02:17 <lightningbot> Meeting started Thu Oct 12 19:02:17 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2542017-10-12T19:02:17 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2552017-10-12T19:02:22 <luke-jr> before we officially start, does anyone mind if I collapse the fixups in #11383 ?
2562017-10-12T19:02:24 <gribble> https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
2572017-10-12T19:02:40 <wumpus> #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 jl2012 achow101
2582017-10-12T19:02:47 <kanzure> hi.
2592017-10-12T19:03:02 <cfields> hi
2602017-10-12T19:03:26 <wumpus> luke-jr: probably best to do that just before merge
2612017-10-12T19:03:34 <BlueMatt> suggested topics: backdating segwit/p2sh
2622017-10-12T19:03:37 <BlueMatt> suggested topics: segwit wallet
2632017-10-12T19:03:51 <BlueMatt> suggested topics: pre-2x release (possibly with no segwit wallet)?
2642017-10-12T19:04:05 <wumpus> #topic Backdating segwit/p2sh (BlueMatt)
2652017-10-12T19:04:15 * BlueMatt nominates sdaftuar/sipa/jl2012 to talk
2662017-10-12T19:04:15 <sdaftuar> i guess matt wants me to talk about this one
2672017-10-12T19:04:24 * sipa listens
2682017-10-12T19:04:32 <jl2012> hi
2692017-10-12T19:04:55 <meshcollider> Hello
2702017-10-12T19:05:17 <gmaxwell> I am pro backdating but wasn't sure how we should handle the rollback and replay. Rolling back the whole chain would be unfortunate. :P
2712017-10-12T19:05:20 <sdaftuar> in thinking about p2sh and segwit, they both have the property that it doesn't make sense to ever accept blocks that violate those rules
2722017-10-12T19:05:41 <sdaftuar> in the case of p2sh, there was only one historical block that violated SCRIPT_VERIFY_P2SH
2732017-10-12T19:05:47 <jl2012> I think backdating segwit is not trivial because the inclusion of witness commitment pre-fork
2742017-10-12T19:05:56 <sdaftuar> in the case of segwit, no blocks have ever violated the segwit scritp flag SCRIPT_VERIFY_WITNESS
2752017-10-12T19:06:13 <gmaxwell> jl2012: I thought all the prefork ones were valid.
2762017-10-12T19:06:15 <sdaftuar> but of course, the witness commitment validation rules don't really work for backdating
2772017-10-12T19:06:27 <wumpus> backdating to when? to the beginning of the chain?
2782017-10-12T19:06:27 <sdaftuar> gmaxwell: i don't think that is true, though i didn't verify myself
2792017-10-12T19:06:30 <sdaftuar> wumpus: yes
2802017-10-12T19:06:42 <wumpus> interesting
2812017-10-12T19:06:42 <cfields> jl2012: i checked the pre-activation commitments on mainnet and found them to all be valid
2822017-10-12T19:06:48 <BlueMatt> gmaxwell: somehow i thought many of them were invalid
2832017-10-12T19:06:51 <BlueMatt> oh!
2842017-10-12T19:06:52 <jl2012> gmaxwell: not exactly, because of lack of the 0000.....0000 coinbase witness
2852017-10-12T19:06:53 <sdaftuar> cfields: oh!
2862017-10-12T19:06:54 <achow101> isn't segwit only backdateable to p2sh activation at earliest?
2872017-10-12T19:07:02 <gmaxwell> I think in general its cleanest when we can backdate softforks to the start.
2882017-10-12T19:07:09 <BlueMatt> achow101: we're talking about backdating p2sh as well (with one exception)
2892017-10-12T19:07:15 <sdaftuar> yes it would take some work to manufacture the witness nonces as jl2012 points out
2902017-10-12T19:07:27 <sipa> what is the advantage over just hardcoding a height for segwit and p2sh start?
2912017-10-12T19:07:30 <sdaftuar> but if it is really true that none were invalid, that might change the way i look at it
2922017-10-12T19:07:45 <wumpus> sipa: no need to handle the non-segwit case for initial validation anymore ,I guess
2932017-10-12T19:07:49 <BlueMatt> sipa: it is a very nice property (imo) that you will *never* accept any chain with invalid segwit/p2sh spends
2942017-10-12T19:07:50 *** Emcy has quit IRC
2952017-10-12T19:07:57 <BlueMatt> irrespective of reorgs
2962017-10-12T19:08:03 <jl2012> sdaftuar: and for some blocks that was very close to 1MB, adding the coinbase witness will make it over 4M weight
2972017-10-12T19:08:23 <sipa> BlueMatt: sure, but i'm not sure that weighs up against the complication of adding exceptions, make-pretending to have coinbase witnesses nonces, ...
2982017-10-12T19:08:28 <gmaxwell> it also simplifies reasoning about further changes, e.g. what happens if someone forks early during IBD and feeds us a chain with things we assumed were impossible.
2992017-10-12T19:08:43 <BlueMatt> in any case, I believe sdaftuar's suggestion was to backdate SCRIPT_VERIFY_WITNESS/P2SH, but dissallow witnesses in blocks pre-activation, effectively disabling segwit
3002017-10-12T19:08:47 <sdaftuar> gmaxwell: yeah that's basically the reason i started thinking abotu this
3012017-10-12T19:08:51 <sipa> BlueMatt: ugh
3022017-10-12T19:08:52 <sdaftuar> but i don't feel strongly either way
3032017-10-12T19:08:57 <BlueMatt> sipa: you can skip the witness nonce part
3042017-10-12T19:09:15 <luke-jr> jl2012: are any of those blocks *also* with the commitment?
3052017-10-12T19:09:21 <sipa> that's effectively splitting the segwit logic into 2 deployments, with one always active?
3062017-10-12T19:09:23 <gmaxwell> I don't feel strongly about it except the general principle that it's better to backdate wheverever possible.
3072017-10-12T19:09:35 <BlueMatt> sipa: well I would call that splitting it into one deployment and one consensus rule
3082017-10-12T19:09:36 <BlueMatt> but ok
3092017-10-12T19:09:40 <morcos> well an always active deployment is kind of not a deployment
3102017-10-12T19:09:42 <morcos> right
3112017-10-12T19:09:45 <sdaftuar> sipa: the branch i have splits the witness commitment rule from the script verification rule, basically
3122017-10-12T19:09:46 *** Emcy has joined #bitcoin-core-dev
3132017-10-12T19:09:53 <sipa> BlueMatt: so you're not getting rid of the deployment overhead
3142017-10-12T19:09:56 <sdaftuar> i was not sure it was an improvement
3152017-10-12T19:10:15 <BlueMatt> sipa: indeed, it does not significantly simplify, it (mostly) just adds a very nice property
3162017-10-12T19:10:28 <BlueMatt> (and, as gmaxwell points out, may simplify future fork logic)
3172017-10-12T19:10:36 *** Guyver2 has joined #bitcoin-core-dev
3182017-10-12T19:10:36 <sipa> i understand the advantage of making a consensus rule always active, allowing you to get rid of some logic
3192017-10-12T19:10:42 <jl2012> luke-jr: I guess so, especially from f2pool. They mine exactly 1MB block quite frequently
3202017-10-12T19:10:43 <sdaftuar> jl2012: that weight issue is a good point
3212017-10-12T19:10:47 <sipa> but it doesn't seem that's really possible here without further complication
3222017-10-12T19:10:55 *** wxss has joined #bitcoin-core-dev
3232017-10-12T19:11:00 <BlueMatt> I dont think its adding significant new complication
3242017-10-12T19:11:01 <gmaxwell> Not just simplfy but reduce the incidence where the community makes design errors due to reasoning from current rules without realizing they don't apply in IBD.
3252017-10-12T19:11:28 <gmaxwell> but what sipa says, I don't think backdating is worth non-trivial extra complexity.
3262017-10-12T19:11:32 <luke-jr> what's the downside to allowing witness in pre-activation blocks?
3272017-10-12T19:11:47 <sipa> luke-jr: makes my head hurt
3282017-10-12T19:11:59 *** Emcy has quit IRC
3292017-10-12T19:12:07 <gmaxwell> luke-jr: that we'll make changes in the future based on an assumption that they're never there.
3302017-10-12T19:12:27 <BlueMatt> sipa: I'm looking at https://github.com/sdaftuar/bitcoin/compare/2649d1690ce9458aa344a8ccfb1fa8548b2ac57c...2017-09-p2sh-segwit-from-genesis
3312017-10-12T19:12:50 *** Emcy has joined #bitcoin-core-dev
3322017-10-12T19:12:52 <gmaxwell> We also don't have to decide this forever now, we could e.g. set it to activate at the real height now, and then later adjust it further back.
3332017-10-12T19:12:53 <morcos> sipa: i just really hate the attack scenarios that involve feeding alternate chains that eventually get reorged out but possibly with poor consequences... perhaps this is not a problem with segwit, but perhaps it is... say your wallet loses money in an unexpected way or something?
3342017-10-12T19:13:14 <sipa> BlueMatt: that doesn't look too bad, i guess
3352017-10-12T19:13:25 <sipa> but i need to think about it
3362017-10-12T19:13:39 <BlueMatt> sipa: yes, sorry, should have shared the code since we're arguing based on different understandings...anyway, something to think about, I dont think I feel *that* strongly, but I am vaguely in favor
3372017-10-12T19:13:40 <sdaftuar> if this is worth discussion, i can open a PR
3382017-10-12T19:13:49 <sdaftuar> i wasn't sure whether to move this forward
3392017-10-12T19:14:07 <sipa> but in regards to the next topic, do we want all that in 0.15.1?
3402017-10-12T19:14:20 <morcos> no, i don't
3412017-10-12T19:14:24 <sdaftuar> i don't think this so either
3422017-10-12T19:14:25 <BlueMatt> i dont think so?
3432017-10-12T19:14:29 <sipa> okay
3442017-10-12T19:14:32 <wumpus> would be kind of hurried IMO
3452017-10-12T19:14:37 <BlueMatt> very
3462017-10-12T19:14:39 <gmaxwell> It would be really nice if 0.15.1 were out before the B2X split, but we're on the thin edge of that now I think.
3472017-10-12T19:14:42 <wumpus> also let's not increase the scope of 0.15.1
3482017-10-12T19:14:46 <BlueMatt> ok, so #action sdaftuar opens pr? next topic?
3492017-10-12T19:14:46 <sipa> so this is unrelated to #11389
3502017-10-12T19:14:48 <gribble> https://github.com/bitcoin/bitcoin/issues/11389 | Support having SegWit always active in regtest by sipa · Pull Request #11389 · bitcoin/bitcoin · GitHub
3512017-10-12T19:14:52 <wumpus> #topic segwit wallet
3522017-10-12T19:15:20 <achow101> if we want 0.15.1 out before B2X, it probably needs to go into rc's within the next week
3532017-10-12T19:15:27 <jonasschnelli> For the GUI, I'm working on a Bech32 error pointer (red underlines where errors appear)
3542017-10-12T19:15:29 <sipa> achow101: seems unreasonable
3552017-10-12T19:15:34 <sipa> i first want to get 11389 in, but there seems to be some discussion about the right approach
3562017-10-12T19:15:35 <BlueMatt> (which probably means no segwit wallet)
3572017-10-12T19:15:51 <wumpus> 0.15.0.2? :p
3582017-10-12T19:15:55 <BlueMatt> yea, that
3592017-10-12T19:16:03 <sipa> or 0.15.1 without segwit wallet, 0.15.2 with
3602017-10-12T19:16:13 <wumpus> we'll just do minor-minor releases until we have the damn segwit wallet :)
3612017-10-12T19:16:18 <BlueMatt> yea, numbers...isnt someone in charge of those so I dont have to think about them?
3622017-10-12T19:16:18 <sipa> haha
3632017-10-12T19:16:23 <jnewbery> I think #11389 is related to Suhas's suggested change, no?
3642017-10-12T19:16:25 <gribble> https://github.com/bitcoin/bitcoin/issues/11389 | Support having SegWit always active in regtest by sipa · Pull Request #11389 · bitcoin/bitcoin · GitHub
3652017-10-12T19:16:38 <gmaxwell> well, RC by then at least would be good if not out...
3662017-10-12T19:16:53 <BlueMatt> sipa: wait, so you want to have segwit always active in regtest for segwit wallet, or what am I misunderstanding about the need for segwit-regtest for 0.15.1?
3672017-10-12T19:16:58 <sipa> BlueMatt: yes
3682017-10-12T19:17:16 <sipa> adapting the tests to deal with segwit activation halfway through them is a giant pain
3692017-10-12T19:17:23 <wumpus> so if we'd do 0.15.1 without segwit wallet, is there anything that still needs to go in? or can we tag rc1 after the meeting?
3702017-10-12T19:17:27 <BlueMatt> test_framework().activate_segwit() ?
3712017-10-12T19:17:31 <morcos> as much as i really want to concentrate on segwit wallet
3722017-10-12T19:17:38 <sipa> jnewbery: i was starting to respond to you, but to the last point "We already have control to make a BIP9 deployment active at a certain height in regtest using -vbparams. What advantages do you see for making a deployment buried instead of just activated at a height?" -> -vbparams doesn't permit having segwit active before block 432
3732017-10-12T19:17:50 <achow101> what's the point of doing 0.15.1 without segwit wallet?
3742017-10-12T19:17:51 <morcos> i think practically speaking we should focus on what would be good to have before 2X
3752017-10-12T19:17:56 <wumpus> I'm not sure what is the rationale for doing 0.15.1, are there important bugfixes that we need to get out?
3762017-10-12T19:17:56 <morcos> and we should do that withotu segwit wallet
3772017-10-12T19:18:13 <BlueMatt> wumpus: mostly I want https://github.com/bitcoin/bitcoin/pull/11487/commits/09cf35122a219217f841e4e4f7847386eb0b0b8a pre-b2x
3782017-10-12T19:18:18 <achow101> what needs to be done before 2X then?
3792017-10-12T19:18:20 <BlueMatt> but dunno if thats a realistic goal (it probably isnt)
3802017-10-12T19:18:20 <morcos> wumpus: there are a few edge cases with invalid chains that might cause for annoying behavior
3812017-10-12T19:18:54 <wumpus> I mean MarcoFalke backported a lot of things, that's nice to have in #11447
3822017-10-12T19:18:56 <gribble> https://github.com/bitcoin/bitcoin/issues/11447 | 0.15.1: Backports by MarcoFalke · Pull Request #11447 · bitcoin/bitcoin · GitHub
3832017-10-12T19:19:46 <wumpus> BlueMatt: so 11487 should get 0.15.1 tag?
3842017-10-12T19:19:57 <BlueMatt> its not critical, but having edge cases that you may see if you're offline during the fork and suddenly you accept blocks that are on the 2x chain (if they're <4m weight and more work and within our pruning window) thats kinda annoying
3852017-10-12T19:19:59 <wumpus> or really just that commit?
3862017-10-12T19:20:02 <gmaxwell> Just for the record I think it is terrible that we're effectively being forced to delay segwit wallet due to this nonsense.
3872017-10-12T19:20:11 <wumpus> if so, please open a separate PR for that
3882017-10-12T19:20:14 <BlueMatt> wumpus: the rest of that pr is just test changes and other tiny things
3892017-10-12T19:20:29 <wumpus> gmaxwell: yes, me to, I'd personally prefer not to change our plans for them
3902017-10-12T19:20:30 <gmaxwell> (even if we don't bump around the versions for it, the fact that people are spending time on these other things creates delays)
3912017-10-12T19:21:00 <wumpus> but if we need robustness changes now, better to do it
3922017-10-12T19:21:04 <meshcollider> And add to high priority for review?
3932017-10-12T19:21:13 <wumpus> yes, and remove the rest probably
3942017-10-12T19:21:16 <gmaxwell> In any case, so far I haven't seen PRs that we need in advance merged yet, if there were some in, I would support doing a release with them.
3952017-10-12T19:21:40 <gmaxwell> It's hard to anticipate what we'll need a month in advance...
3962017-10-12T19:22:05 <BlueMatt> wumpus: again, I dont think its a "need", but its open for discussion
3972017-10-12T19:22:07 <wumpus> if we want to do rc1 start of next week we'll really need to hurry
3982017-10-12T19:22:10 <gmaxwell> esp because B2X has already changed their behavior to undermine our protections in the past... :-/
3992017-10-12T19:22:18 <BlueMatt> its really gross that we may accept/store blocks on a chain we know is invalid
4002017-10-12T19:22:25 <BlueMatt> but its not gonna do anything but use a bit more disk
4012017-10-12T19:22:31 <gmaxwell> Yes, okay, that is a concern.
4022017-10-12T19:22:54 *** promag has joined #bitcoin-core-dev
4032017-10-12T19:22:59 <meshcollider> #11446 probably won't make it either will it
4042017-10-12T19:23:01 <gribble> https://github.com/bitcoin/bitcoin/issues/11446 | [WIP] Bad block interrogation by achow101 · Pull Request #11446 · bitcoin/bitcoin · GitHub
4052017-10-12T19:23:01 <wumpus> yes that's kind of gross
4062017-10-12T19:23:28 <gmaxwell> meshcollider: well thats the sort of thing we're talking about right now.
4072017-10-12T19:23:49 <achow101> I think 11446 would be necessary for a pre-B2X release so that we kick all peers that give us invalid blocks, not just the first
4082017-10-12T19:23:57 <gmaxwell> basically to do these things we'll need to more or less drop working on SW wallet for a moment, get those things, and RC them. ASAP.
4092017-10-12T19:24:17 <achow101> and/or maybe #10593
4102017-10-12T19:24:19 <gribble> https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr · Pull Request #10593 · bitcoin/bitcoin · GitHub
4112017-10-12T19:24:22 <meshcollider> Yeah a release including both of those would be worth it if they're ready for merge in time
4122017-10-12T19:24:50 <gmaxwell> misleading PR title. :P
4132017-10-12T19:25:03 <wumpus> ok tagged both of them for 0.15.1
4142017-10-12T19:25:48 <wumpus> will move the rest that's tagged with 0.15.1 and unmerged to 0.15.2 when we actually decide to do the release
4152017-10-12T19:25:50 <sdaftuar> fyi i have one more pr that is along these same lines that i will be opening shortly... basically trying to implement some of the outbound peer protection we talked abotu last week's meeting
4162017-10-12T19:26:20 <gmaxwell> sdaftuar: I'll put some time into helping review that. (though I'll be in the air much of the weekend...)
4172017-10-12T19:26:26 <sdaftuar> awesome, thanks
4182017-10-12T19:26:27 <cfields> sorry, i had to run out for a min.... Lots of people are expecting 0.15.1 as the release that enables more segwit wallet functionality. Releasing without that will be very confusing to lots of people. Is there any reason not to call it 0.15.0.2 ?
4192017-10-12T19:26:52 <sipa> no opinion on versioning
4202017-10-12T19:26:57 <luke-jr> gmaxwell: how is it misleading?
4212017-10-12T19:26:58 <jonasschnelli> agree with cfields
4222017-10-12T19:27:01 *** promag has quit IRC
4232017-10-12T19:27:06 <jnewbery> +1 for 0.15.0.2
4242017-10-12T19:27:07 <cfields> It's just that they've been told over and ove to wait for 0.15.1...
4252017-10-12T19:27:08 <meshcollider> Agree with cfields as well
4262017-10-12T19:27:08 <jl2012> ack 0.15.0.2
4272017-10-12T19:27:19 <wumpus> no opinion on how to call it either, 0.15.0.2 was really a joke though, usually we do minor-mimor versions only for tiny changes
4282017-10-12T19:27:31 <gmaxwell> I'd prefer to call 0.15.1 the one with segwit wallet just due to comms reasons.
4292017-10-12T19:27:40 <luke-jr> personally, I'd prefer to move segwitwallet to 0.16, but it's numbers so who cares
4302017-10-12T19:27:55 <wumpus> anyhow if everyone wants 0.15.0.2 , we'll have 0.15.0.2
4312017-10-12T19:27:55 <luke-jr> comms reasons probably outweigh any reason to move it
4322017-10-12T19:27:57 <meshcollider> Or look at #9653 now and throw everyone into confusion ;)
4332017-10-12T19:27:58 <gribble> https://github.com/bitcoin/bitcoin/issues/9653 | Versioning convention for Bitcoin Core · Issue #9653 · bitcoin/bitcoin · GitHub
4342017-10-12T19:28:04 <wumpus> yes, agree with that
4352017-10-12T19:28:07 <gmaxwell> (comms reasons is that there are a billionity messages on the internet saying 0.15.1 has segwit wallet)
4362017-10-12T19:28:10 <wumpus> we've kind of promised segwit wallet in 0.15.1
4372017-10-12T19:28:16 <cfields> right
4382017-10-12T19:28:28 <achow101> what if we did segwit wallet this weekend? *ducks*
4392017-10-12T19:28:35 <luke-jr> let's go with 0.15.½ :P
4402017-10-12T19:28:44 <wumpus> achow101: if we did that, we'ld not get around to the ultra-high-priority ones that warrant releasing now
4412017-10-12T19:28:45 <meshcollider> Lol
4422017-10-12T19:28:49 <gmaxwell> so obviously we release 0.15.3 ... and then 0.15.1 after it...
4432017-10-12T19:28:56 <wumpus> luke-jr: hehe floating point version numbers
4442017-10-12T19:29:15 <wumpus> luke-jr: eh I mean fractions
4452017-10-12T19:29:22 <meshcollider> 0.15.0.../.1
4462017-10-12T19:29:36 <cfields> gmaxwell: starting to sound like gcc. Obviously gcc 8.0 is the beta :p
4472017-10-12T19:30:02 <gmaxwell> 0.15.A
4482017-10-12T19:30:18 <wumpus> ok, so 0.15.0.2 it is, will create a milestone and change the tags
4492017-10-12T19:30:24 <gmaxwell> in any case, lets worry about that when we're actually ready to release; I think we understand the tradeoffs.
4502017-10-12T19:30:34 <gmaxwell> sounds good to me
4512017-10-12T19:30:41 <cfields> sorry for the late chime-in
4522017-10-12T19:32:18 <wumpus> yeah no problem, I guess we covered both "segwit wallet" and "pre-2x release" - any other topics?
4532017-10-12T19:32:37 <morcos> So not clear to me if we've decided
4542017-10-12T19:32:50 <morcos> Are we doing a pre-2X release or trying to at least
4552017-10-12T19:33:10 <wumpus> my impression is that we're going to try
4562017-10-12T19:33:14 <morcos> It would be helpful to note if we're clearly prioritizing that and putting them on high-priority-for-review
4572017-10-12T19:33:20 <wumpus> https://github.com/bitcoin/bitcoin/milestone/32
4582017-10-12T19:33:39 <wumpus> yes, they should be (and anything else should go for nwo)
4592017-10-12T19:33:49 <gmaxwell> it sounds like we're going to try...
4602017-10-12T19:34:24 <gmaxwell> also keep in mind that there is value in having protections in master, even if they're not in a release... a small percentage of nodes in the network being protected can help improve stability for everyone.
4612017-10-12T19:35:10 <morcos> achow101: can you please update title and description for #11446
4622017-10-12T19:35:12 <gribble> https://github.com/bitcoin/bitcoin/issues/11446 | [WIP] Bad block interrogation by achow101 · Pull Request #11446 · bitcoin/bitcoin · GitHub
4632017-10-12T19:35:17 <achow101> morcos: hehe sure
4642017-10-12T19:35:50 <morcos> And do you think we don't need #10593 if we have 11446?
4652017-10-12T19:35:51 <gribble> https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr · Pull Request #10593 · bitcoin/bitcoin · GitHub
4662017-10-12T19:35:56 <gmaxwell> in any case, based on CST prices, I think we should focus on protections that help in the case that we have disguised B2X peers and they're getting no blocks at all (Because they've rejected the bitcoin chain).
4672017-10-12T19:36:19 <achow101> morcos: #10953 does something mostly different
4682017-10-12T19:36:20 <gribble> https://github.com/bitcoin/bitcoin/issues/10953 | [Refactor] Combine scriptPubKey and amount as CTxOut in CScriptCheck by jl2012 · Pull Request #10953 · bitcoin/bitcoin · GitHub
4692017-10-12T19:36:34 <sipa> wrong pr number?
4702017-10-12T19:36:44 <morcos> 593, see above
4712017-10-12T19:36:45 <achow101> oops 10593
4722017-10-12T19:36:52 <gmaxwell> #10593
4732017-10-12T19:36:54 <gribble> https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr · Pull Request #10593 · bitcoin/bitcoin · GitHub
4742017-10-12T19:36:59 <morcos> in 593 you say it does the same as 11446
4752017-10-12T19:37:00 <wumpus> https://github.com/bitcoin/bitcoin/projects/8 updated
4762017-10-12T19:37:24 <achow101> I suggested it because luke-jr that it would do about the same thing plus some more, but I noticed that it doesn't really
4772017-10-12T19:37:24 <morcos> basically i'm just trying to get concept acks here on what we're going for
4782017-10-12T19:37:31 <morcos> ok
4792017-10-12T19:37:44 <achow101> see https://github.com/bitcoin/bitcoin/pull/10593#issuecomment-334946691
4802017-10-12T19:38:05 <achow101> I thought luke-jr might change it to include what 11446 does
4812017-10-12T19:38:38 <BlueMatt> gmaxwell: yes, regarding b2x peers that have less hashpower and are disguised, I believe thats what sdaftuar is working on
4822017-10-12T19:38:50 <gmaxwell> BlueMatt: great, okay!
4832017-10-12T19:38:59 <morcos> OK Can someone motivate 10593 for me
4842017-10-12T19:39:19 <morcos> I mean not really motivate, but explain why it is important before 2X
4852017-10-12T19:39:36 <luke-jr> It's more important before the next softfork, not so much before 2X, AFAIK
4862017-10-12T19:39:48 <morcos> ok, that was my reading...
4872017-10-12T19:39:56 <luke-jr> (if 2X would accept a reorg, it'd be useful, but 2X doesn't)
4882017-10-12T19:40:16 <luke-jr> oh, if 2X users want to switch to Bitcoin, it might be useful for them
4892017-10-12T19:40:16 <gmaxwell> I thought it also added disconnects on invalids that we currently don't have?
4902017-10-12T19:40:33 <gmaxwell> luke-jr: because it turns some bans into disconnects?
4912017-10-12T19:40:37 <luke-jr> gmaxwell: right
4922017-10-12T19:40:37 <morcos> can we perhaps remove that from high priority and concentrate on the pre-2X things... (hmm, good point i suppose)
4932017-10-12T19:40:46 <luke-jr> gmaxwell: IIRC, the disconnect-on-merely-invalid is achow101's PR
4942017-10-12T19:41:38 <achow101> gmaxwell: it turns bans into disconnects, which includes the ban on the first time we see an invalid block
4952017-10-12T19:43:26 <gmaxwell> I think that in and of itself is less critical.
4962017-10-12T19:43:48 <luke-jr> so I guess 10593 is a nice-to-have before 2X, but not a must-have
4972017-10-12T19:43:50 <luke-jr> ?
4982017-10-12T19:43:57 <achow101> luke-jr: agreed
4992017-10-12T19:44:24 <morcos> that sounds right to me
5002017-10-12T19:44:37 <gmaxwell> sounds reasonable to me.
5012017-10-12T19:45:09 <wumpus> so 10593 is less-than-higher-priority-for-review? :p
5022017-10-12T19:45:22 <sdaftuar> slightly-higher-priority-for-review
5032017-10-12T19:45:25 <sipa> elevated-priority
5042017-10-12T19:45:48 <morcos> or as we used to do it in Core: 14275131000
5052017-10-12T19:46:09 <sipa> $ date --date "@14275131000"
5062017-10-12T19:46:09 <sipa> Thu May 12 03:10:00 PDT 2422
5072017-10-12T19:46:14 * sdaftuar laughs after alex explained the joke
5082017-10-12T19:46:31 <achow101> ???
5092017-10-12T19:46:40 <morcos> heh, i made up the number b/c i was lazy, but there were number ranges.. one was for medium-high priority
5102017-10-12T19:46:55 <BlueMatt> lol, ok, so did we ever discuss segwit wallet?
5112017-10-12T19:47:01 <BlueMatt> sorry, I kinda derailed things :(
5122017-10-12T19:47:07 <sipa> apparently we discussed it being less priority
5132017-10-12T19:47:11 <sipa> or something
5142017-10-12T19:47:12 <wumpus> TIL that date command line can convert unix timestamps, thanks sipa
5152017-10-12T19:47:24 <BlueMatt> noooooo :(
5162017-10-12T19:47:25 <sipa> wumpus: also, date "+%s"
5172017-10-12T19:47:31 <morcos> how did you do that otherwise?
5182017-10-12T19:47:33 <gmaxwell> 57599999
5192017-10-12T19:47:46 <morcos> thanks gmax
5202017-10-12T19:47:46 <BlueMatt> wumpus: oh, another hint, when reading git logs, it is useful to have a vim keybinding to call that command so you can see when it happened :p
5212017-10-12T19:47:57 <wumpus> morcos: time.ctime(n) or time.localtime(n) in python
5222017-10-12T19:48:01 <gmaxwell> morcos: python is pretty useful for date math.
5232017-10-12T19:48:11 <sipa> BlueMatt: i will work on describing the alternatives for segwit wallet support, and some thoughts on wallet/ismine in 0.16
5242017-10-12T19:48:19 <sipa> BlueMatt: but blocker is the always-segwit-active
5252017-10-12T19:48:26 <gmaxwell> e.g. script I use for IBD benchmarking uses python to difference bitcoin log dates.
5262017-10-12T19:48:26 <wumpus> gmaxwell: exactly
5272017-10-12T19:48:31 <sipa> so review/discussion can focus on that for now, i think
5282017-10-12T19:49:03 <BlueMatt> sipa: well, at least personally, I'm also fine with taking the always-active-segwit pr and then reverting it if we decide we want something more like jl2012's on master, isnt a big changeset either way
5292017-10-12T19:49:10 <BlueMatt> so I'm not sure I'd call it a "blocker" in that sense.....
5302017-10-12T19:49:16 <sipa> fair
5312017-10-12T19:50:05 * luke-jr needs to move his bitcoin git to a SSD
5322017-10-12T19:51:08 <wumpus> any other topics?
5332017-10-12T19:51:44 <BlueMatt> #action activate segwit
5342017-10-12T19:51:53 <wumpus> luke-jr: well at least your entire SSD won't be full with one git checkout, as with the linux kernel :-)
5352017-10-12T19:52:01 * sipa fetches his DeLorean
5362017-10-12T19:52:12 <wumpus> activate segwit in 1970
5372017-10-12T19:52:13 <luke-jr> wumpus: git-show of a tag is taking me a full minute here :/
5382017-10-12T19:52:27 <BlueMatt> luke-jr: is that on a 10-year-old sd card?!
5392017-10-12T19:52:31 <gmaxwell> $ git grep -i delorean | wc -l
5402017-10-12T19:52:31 <gmaxwell> 1
5412017-10-12T19:52:36 <sipa> BlueMatt: it's on core memory
5422017-10-12T19:52:38 <wumpus> luke-jr: git show? that just retrieves an object, that's slow even for a mechanical hd
5432017-10-12T19:52:38 <cfields> BlueMatt: pretty sure we did that in a previous meeting. Though we could do it again and make it 2x activations...
5442017-10-12T19:52:39 <luke-jr> BlueMatt: fairly newish 5400 RPM magnetic drive
5452017-10-12T19:52:52 <luke-jr> wumpus: it does many many MB of reading for some reason
5462017-10-12T19:53:01 <wumpus> git log can be kind of slow here, especially when showing branches (as I have about 800 local branches), but show is super quick
5472017-10-12T19:53:03 <BlueMatt> 5400 RPM? eww
5482017-10-12T19:53:07 <jonasschnelli> :-)
5492017-10-12T19:53:19 <luke-jr> wumpus: I suspect part of the cause is that I never prune my git repo
5502017-10-12T19:53:38 *** promag has joined #bitcoin-core-dev
5512017-10-12T19:53:42 <wumpus> luke-jr: can you prune a git repo?
5522017-10-12T19:53:47 <wumpus> (or do you mean gc?)
5532017-10-12T19:53:47 <sipa> git gc
5542017-10-12T19:53:59 <wumpus> I interpreted that literally, like converting it to a shallow repo
5552017-10-12T19:54:09 <sipa> git prune also exists, just removes unreachable objects
5562017-10-12T19:54:19 <sipa> gc does that + compacting storage
5572017-10-12T19:54:25 <luke-jr> wumpus: gc
5582017-10-12T19:54:34 <sipa> shallow repo is something else
5592017-10-12T19:54:38 <wumpus> git gc --aggresive --force --prune=all
5602017-10-12T19:54:41 <luke-jr> my gc is configured to only compress :P
5612017-10-12T19:54:45 <sipa> why?
5622017-10-12T19:55:01 <luke-jr> so I can git-show any object hash from any point in time, even if it's long-dead
5632017-10-12T19:55:21 <CryptAxe> luke-jr I do 2 ssds in raid 0 + rsync backup to disk and it works great
5642017-10-12T19:55:22 <luke-jr> .git is only 1.1 GB, surprisingly
5652017-10-12T19:55:27 <sipa> perhaps you can split up your repo in an archive version + working version
5662017-10-12T19:55:47 <luke-jr> sipa: well, I'm hoping simply moving it to SSD will be good enough XD
5672017-10-12T19:55:51 <BlueMatt> #topic optimal git workflows for Core memory users
5682017-10-12T19:55:51 <sipa> seems this meeting is out of topics?
5692017-10-12T19:56:02 <sipa> #link https://en.wikipedia.org/wiki/Magnetic-core_memory
5702017-10-12T19:56:47 <luke-jr> wumpus: you suggested waiting to squash fixups into multiwallet until it's about to be merged; but jnewbery is asking for a rebase.. :x
5712017-10-12T19:57:08 <wumpus> when I started using worktrees I've moved everything to work from a single .git tree (with seaprate checkouts for some branches), but a seperate archive and working copy sounds pretty good
5722017-10-12T19:57:10 <sipa> if you need a rebase anyway, i generally don't care about squashing fixups
5732017-10-12T19:57:27 <wumpus> mercury delay line memory ftw
5742017-10-12T19:57:47 <wumpus> luke-jr: yes in that case feel free to squash
5752017-10-12T19:58:10 <luke-jr> k, *done*
5762017-10-12T19:58:39 <wumpus> #endmeeting
5772017-10-12T19:58:39 <lightningbot> Meeting ended Thu Oct 12 19:58:39 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5782017-10-12T19:58:39 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-10-12-19.02.html
5792017-10-12T19:58:39 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-10-12-19.02.txt
5802017-10-12T19:58:39 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-10-12-19.02.log.html
5812017-10-12T20:01:43 <wumpus> btw the meetings hasn't been updated since june https://bitcoincore.org/en/meetings/, anyone know what happened to G1lius?
5822017-10-12T20:03:11 <gmaxwell> I've seen him posting on reddit, I assume he's just been busy.
5832017-10-12T20:03:13 <wumpus> he's had no github activity at all since :/
5842017-10-12T20:03:15 <wumpus> okay
5852017-10-12T20:04:05 <karelb> wumpus: yeah I wanted to ask this too, I wanted to read some recent summaries
5862017-10-12T20:04:28 <wumpus> good to know he's alive and kicking on reddit at least :)
5872017-10-12T20:04:46 <wumpus> if he's too busy we can try to find another volunteer
5882017-10-12T20:05:03 *** Cheeseo has joined #bitcoin-core-dev
5892017-10-12T20:05:16 <achow101> I can see if someone at my school's cryptocurrency club is interested in doing that
5902017-10-12T20:05:30 <wumpus> achow101: cool, thanks
5912017-10-12T20:05:40 <achow101> or we could ask harding :)
5922017-10-12T20:05:52 <wumpus> it doesn't have to be as extensive as he did, but the basic info such as a link to the irc log and big bullet points would be nice
5932017-10-12T20:06:13 <wumpus> what G1lius did was really great though
5942017-10-12T20:06:40 <wumpus> harding is probably too busy too
5952017-10-12T20:07:01 *** promag has quit IRC
5962017-10-12T20:17:13 *** Giszmo has quit IRC
5972017-10-12T20:29:53 *** owowo has quit IRC
5982017-10-12T20:31:02 *** Giszmo has joined #bitcoin-core-dev
5992017-10-12T20:34:52 *** owowo has joined #bitcoin-core-dev
6002017-10-12T20:37:59 *** Giszmo has quit IRC
6012017-10-12T20:43:44 *** CubicEarth has joined #bitcoin-core-dev
6022017-10-12T20:44:56 *** Cogito_Ergo_Sum has quit IRC
6032017-10-12T20:51:29 *** wvr- has joined #bitcoin-core-dev
6042017-10-12T20:52:17 *** wvr has quit IRC
6052017-10-12T20:54:57 *** Chris_Stewart_5 has quit IRC
6062017-10-12T21:06:23 <bitcoin-git> [bitcoin] sdaftuar opened pull request #11490: Disconnect from outbound peers with bad headers chains (master...2017-10-outbound-peers-good-chain) https://github.com/bitcoin/bitcoin/pull/11490
6072017-10-12T21:09:53 <sdaftuar> wumpus: ^ this is the PR i had in mind as a consideration for 0.15.0.2
6082017-10-12T21:10:36 *** Emcy has quit IRC
6092017-10-12T21:13:04 <wumpus> ok, will tag
6102017-10-12T21:15:58 *** belcher has quit IRC
6112017-10-12T21:23:56 *** mmgen has quit IRC
6122017-10-12T21:24:39 <bitcoin-git> [bitcoin] mess110 opened pull request #11491: [gui] Add proxy icon in statusbar (master...add_proxy_icon) https://github.com/bitcoin/bitcoin/pull/11491
6132017-10-12T21:26:18 *** Emcy has joined #bitcoin-core-dev
6142017-10-12T21:36:53 *** promag has joined #bitcoin-core-dev
6152017-10-12T21:39:38 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6162017-10-12T21:45:58 *** esotericnonsense has joined #bitcoin-core-dev
6172017-10-12T21:50:21 *** DrOlmer has quit IRC
6182017-10-12T21:50:53 *** DrOlmer has joined #bitcoin-core-dev
6192017-10-12T21:56:18 <bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/f74459dba6de...470c730e3fa9
6202017-10-12T21:56:19 <bitcoin-git> bitcoin/master 55224af practicalswift: Remove redundant NULL checks after new
6212017-10-12T21:56:19 <bitcoin-git> bitcoin/master 7466991 practicalswift: Remove redundant check (!ecc is always true)
6222017-10-12T21:56:20 <bitcoin-git> bitcoin/master b5fb339 practicalswift: Remove duplicate uriParts.size() > 0 check
6232017-10-12T21:56:43 <bitcoin-git> [bitcoin] laanwj closed pull request #10898: Fix invalid checks (NULL checks after dereference, redundant checks, etc.) (master...invalid-logic) https://github.com/bitcoin/bitcoin/pull/10898
6242017-10-12T21:58:25 *** eck has quit IRC
6252017-10-12T21:58:27 *** asoltys has quit IRC
6262017-10-12T22:03:32 *** eck has joined #bitcoin-core-dev
6272017-10-12T22:06:34 *** asoltys has joined #bitcoin-core-dev
6282017-10-12T22:20:53 <promag> jnewbery: https://github.com/bitcoin/bitcoin/pull/11472#issuecomment-336280787 same PR or new?
6292017-10-12T22:22:23 <harding> achow101, wumpus: I'll poke G1lius and see what's up with the meeting notes.
6302017-10-12T22:22:44 <bitcoin-git> [bitcoin] promag opened pull request #11492: Fix leak in CDB constructor (master...2017-10-cdb-constructor-leak) https://github.com/bitcoin/bitcoin/pull/11492
6312017-10-12T22:22:53 *** dermoth has quit IRC
6322017-10-12T22:23:24 *** dermoth has joined #bitcoin-core-dev
6332017-10-12T22:30:01 *** wraithm has quit IRC
6342017-10-12T22:32:57 *** Chris_Stewart_5 has quit IRC
6352017-10-12T22:35:17 <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/470c730e3fa9...424be0330514
6362017-10-12T22:35:17 <bitcoin-git> bitcoin/master 8c2f4b8 Jeremy Rubin: Expose more parallelism with relaxed atomics (suggested in #9938). Fix a test to check the exclusive or of two properties rather than just or.
6372017-10-12T22:35:18 <bitcoin-git> bitcoin/master 424be03 Pieter Wuille: Merge #10099: Slightly Improve Unit Tests for Checkqueue...
6382017-10-12T22:35:27 <bitcoin-git> [bitcoin] sipa closed pull request #10099: Slightly Improve Unit Tests for Checkqueue (master...speedup-checkqueue-tests) https://github.com/bitcoin/bitcoin/pull/10099
6392017-10-12T22:36:10 <promag> Is ryanofsky around?
6402017-10-12T22:36:24 <ryanofsky> hi
6412017-10-12T22:36:41 <promag> see my comment in 11492
6422017-10-12T22:36:51 <promag> do you think I should squash?
6432017-10-12T22:36:58 <promag> ty
6442017-10-12T22:37:46 *** Guyver2 has quit IRC
6452017-10-12T22:38:41 *** timothy has joined #bitcoin-core-dev
6462017-10-12T22:39:32 <ryanofsky> slight preference for keeping two commits, and updating message on second commit so it is more clearly a bugfix not just a refactoring
6472017-10-12T22:39:56 <promag> ok, thanks
6482017-10-12T22:43:14 *** timothy has quit IRC
6492017-10-12T22:52:08 *** promag has quit IRC
6502017-10-12T22:58:40 *** CubicEarth has quit IRC
6512017-10-12T23:02:49 *** promag has joined #bitcoin-core-dev
6522017-10-12T23:05:39 *** mess110 has quit IRC
6532017-10-12T23:07:43 *** DrOlmer has quit IRC
6542017-10-12T23:18:28 *** timothy has joined #bitcoin-core-dev
6552017-10-12T23:20:07 *** DrOlmer has joined #bitcoin-core-dev
6562017-10-12T23:24:26 *** timothy has quit IRC
6572017-10-12T23:34:51 *** luke-jr has quit IRC
6582017-10-12T23:35:07 *** luke-jr has joined #bitcoin-core-dev
6592017-10-12T23:36:45 *** promag has quit IRC
6602017-10-12T23:41:47 *** gbr_ has joined #bitcoin-core-dev
6612017-10-12T23:56:13 *** timothy has joined #bitcoin-core-dev