12017-10-03T00:01:01  *** promag has quit IRC
  22017-10-03T00:16:35  *** justanotheruser has joined #bitcoin-core-dev
  32017-10-03T00:17:37  *** promag has joined #bitcoin-core-dev
  42017-10-03T00:21:17  *** justanotheruser has quit IRC
  52017-10-03T00:21:52  *** promag has quit IRC
  62017-10-03T00:30:23  *** AaronvanW has quit IRC
  72017-10-03T00:30:59  *** AaronvanW has joined #bitcoin-core-dev
  82017-10-03T00:35:05  *** AaronvanW has quit IRC
  92017-10-03T00:37:02  *** justanotheruser has joined #bitcoin-core-dev
 102017-10-03T00:51:36  *** tripleslash has joined #bitcoin-core-dev
 112017-10-03T00:55:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 122017-10-03T00:58:44  *** dabura667 has joined #bitcoin-core-dev
 132017-10-03T01:00:08  *** promag has joined #bitcoin-core-dev
 142017-10-03T01:17:48  <luke-jr> sipa: then adapt named arguments to work nicer with options? the current way is a kludge, and we shouldn't let named arguments detract from a good non-named interface
 152017-10-03T01:19:50  <sipa> luke-jr: care to elaborate?
 162017-10-03T01:28:06  <kallewoof> (JSON and *sh don't really go well together as it is. '{"address":"$myaddr"}--- oh wait I need to use " or $ won't resolve. "{'addr... oh wait JSON won't allow apos strings.. gaah... etc.)
 172017-10-03T01:29:10  <esotericnonsense> is it possible to explicitly specify named arguments in json queries? I dislike knowing that when writing an API, the commands could change out from under me and I wouldn't know. (yes, modifications to the RPC calls are designed such that it shouldn't happen, but it's still unnerving)
 182017-10-03T01:29:32  <sipa> esotericnonsense: yes, JSON RPC supports named arguments
 192017-10-03T01:29:41  <sipa> where the arguments are not an array but an object
 202017-10-03T01:30:00  <esotericnonsense> for all calls? that's awesome. argh, /me goes off to read the manual.
 212017-10-03T01:30:09  <sipa> yes, for all calls
 222017-10-03T01:30:34  *** justanotheruser has quit IRC
 232017-10-03T01:31:38  <sipa> (since 0.13 or 0.14 it's implemented in bitcoin core, i believe)
 242017-10-03T01:33:58  <luke-jr> sipa: tacking on a bunch of optional ordered arguments is unwieldy and a terrible interface; for such cases, an options object makes sense
 252017-10-03T01:34:57  <sipa> luke-jr: an options object is also an unwieldy and terrible interface
 262017-10-03T01:36:04  <sipa> (see kallewoof's comment above)
 272017-10-03T01:37:01  <luke-jr> sipa: that's an issue with sh, not JSON-RPC
 282017-10-03T01:37:40  <sipa> luke-jr: programmatic use of JSON-RPC should just upgrade to named arguments, IMHO
 292017-10-03T01:37:52  <sipa> safer, clearer, and more flexible in every way
 302017-10-03T01:40:25  <sipa> the only downside to named arguments i think is in CLI usage on the command line, where "-named ... name1= ... name2= ..." need to be added
 312017-10-03T01:41:45  <luke-jr> some languages don't even support named arguments
 322017-10-03T01:42:35  <sipa> then write a wrapper - invoking that will at worst be as hard as constructing the options object you'd otherwise pass
 332017-10-03T01:45:36  *** justanotheruser has joined #bitcoin-core-dev
 342017-10-03T01:47:10  <esotericnonsense> hey, so it does. https://bitcoin.org/en/developer-reference#remote-procedure-calls-rpcs only mentions positional parameters. I'll make a pull request.
 352017-10-03T01:48:27  <luke-jr> sipa: this is not an argument to have a crappy interface
 362017-10-03T01:49:01  <sipa> luke-jr: indeed it isn't, but i know of no solution to that problem
 372017-10-03T01:49:13  <sipa> having many parameters to an RPC will always be annoying to use
 382017-10-03T01:49:54  <luke-jr> the options object is the solution we've used so far
 392017-10-03T01:50:25  <sipa> and i claim that named arguments are in no way worse than an options object
 402017-10-03T01:50:35  <sipa> (in some ways it's equally terribly, though)
 412017-10-03T01:51:11  <luke-jr> even if it were true, that's irrelevant, since the topic is the ordered params API
 422017-10-03T01:51:42  *** promag has quit IRC
 432017-10-03T01:51:56  <sipa> i don't think that's a very interesting topic
 442017-10-03T01:52:02  <sipa> when a better alternative exists
 452017-10-03T01:56:56  <sipa> in every situation where you'd call an RPC with an options object, have JSON-RPC wrapper that takes a JSON object as argument, and treats its key-value pairs as names and values of named arguments in a call
 462017-10-03T01:58:17  *** Murch has quit IRC
 472017-10-03T02:03:51  <esotericnonsense> submitted as #1828 on the bitcoin.org repo. probably just me that's missed it having not been around for the releases but it's nice to have in there.
 482017-10-03T02:03:53  <gribble> https://github.com/bitcoin/bitcoin/issues/1828 | Base58 en-/de-coding by roques · Pull Request #1828 · bitcoin/bitcoin · GitHub
 492017-10-03T02:04:04  <esotericnonsense> no gribble. (probably the wrong channel anyway).
 502017-10-03T02:05:48  *** fanquake has joined #bitcoin-core-dev
 512017-10-03T02:20:45  *** Murch has joined #bitcoin-core-dev
 522017-10-03T02:33:01  <bitcoin-git> [bitcoin] luke-jr opened pull request #11441: rpc/server: Support for specifying options as named parameters (master...rpc_namedopts) https://github.com/bitcoin/bitcoin/pull/11441
 532017-10-03T02:34:52  *** Alina-malina has quit IRC
 542017-10-03T02:34:59  <bitcoin-git> [bitcoin] fanquake opened pull request #11442: [WIP] [Docs] Update OpenBSD Build Instructions for OpenBSD 6.1 (master...openbsd-doc-update) https://github.com/bitcoin/bitcoin/pull/11442
 552017-10-03T02:40:34  *** Alina-malina has joined #bitcoin-core-dev
 562017-10-03T02:44:43  *** fanquake has quit IRC
 572017-10-03T02:44:48  *** Giszmo has quit IRC
 582017-10-03T03:14:40  *** Chris_Stewart_5 has quit IRC
 592017-10-03T03:23:10  *** chjj has joined #bitcoin-core-dev
 602017-10-03T03:23:31  *** dermoth has quit IRC
 612017-10-03T03:24:11  *** dermoth has joined #bitcoin-core-dev
 622017-10-03T03:34:49  *** owowo has quit IRC
 632017-10-03T03:40:47  *** owowo has joined #bitcoin-core-dev
 642017-10-03T03:53:21  *** meshcollider has quit IRC
 652017-10-03T04:56:35  *** Alina-malina has quit IRC
 662017-10-03T04:57:39  *** Alina-malina has joined #bitcoin-core-dev
 672017-10-03T05:00:19  *** intcat has quit IRC
 682017-10-03T05:33:21  *** Alina-malina has quit IRC
 692017-10-03T05:34:40  *** Alina-malina has joined #bitcoin-core-dev
 702017-10-03T05:34:41  *** Alina-malina has joined #bitcoin-core-dev
 712017-10-03T05:42:54  *** sanada has quit IRC
 722017-10-03T06:12:08  *** chjj has quit IRC
 732017-10-03T06:12:29  <bitcoin-git> [bitcoin] mrwhythat closed pull request #11299: [WIP] Implement pruning to location (master...prune-to-location-option) https://github.com/bitcoin/bitcoin/pull/11299
 742017-10-03T06:36:57  *** chjj has joined #bitcoin-core-dev
 752017-10-03T06:53:48  *** meshcollider has joined #bitcoin-core-dev
 762017-10-03T07:15:58  *** timothy has joined #bitcoin-core-dev
 772017-10-03T07:29:49  *** laurentmt has joined #bitcoin-core-dev
 782017-10-03T08:27:36  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #11443: [qa] Allow "make cov" out-of-tree; Fix rpc mapping check (master...Mf1710-qaFixups) https://github.com/bitcoin/bitcoin/pull/11443
 792017-10-03T08:27:48  *** alreadylate has joined #bitcoin-core-dev
 802017-10-03T08:28:17  *** murchandamus has quit IRC
 812017-10-03T08:31:09  *** murchandamus has joined #bitcoin-core-dev
 822017-10-03T08:52:35  *** dabura667 has quit IRC
 832017-10-03T09:13:42  *** dabura667 has joined #bitcoin-core-dev
 842017-10-03T09:17:18  *** Deacyde has joined #bitcoin-core-dev
 852017-10-03T09:49:51  *** murchandamus has quit IRC
 862017-10-03T09:50:52  *** murchandamus has joined #bitcoin-core-dev
 872017-10-03T09:57:22  *** murchandamus has quit IRC
 882017-10-03T09:57:49  *** murchandamus has joined #bitcoin-core-dev
 892017-10-03T09:59:20  *** tester8 has joined #bitcoin-core-dev
 902017-10-03T09:59:32  <tester8> hello
 912017-10-03T09:59:39  *** tester8 has left #bitcoin-core-dev
 922017-10-03T10:03:48  *** intcat has joined #bitcoin-core-dev
 932017-10-03T10:06:02  *** m8tion has joined #bitcoin-core-dev
 942017-10-03T10:13:34  *** AaronvanW has joined #bitcoin-core-dev
 952017-10-03T10:18:50  *** dabura667 has quit IRC
 962017-10-03T10:19:03  *** Emcy has quit IRC
 972017-10-03T10:22:20  *** JackH has joined #bitcoin-core-dev
 982017-10-03T10:33:47  *** AaronvanW has quit IRC
 992017-10-03T10:34:26  *** AaronvanW has joined #bitcoin-core-dev
1002017-10-03T10:51:38  *** Guyver2 has joined #bitcoin-core-dev
1012017-10-03T10:58:48  *** BashCo has quit IRC
1022017-10-03T11:09:47  *** alreadylate has quit IRC
1032017-10-03T11:15:30  *** W4RL0RD has joined #bitcoin-core-dev
1042017-10-03T11:16:50  *** BashCo has joined #bitcoin-core-dev
1052017-10-03T11:20:00  *** SopaXorzTaker has joined #bitcoin-core-dev
1062017-10-03T11:33:10  *** Deacyde has quit IRC
1072017-10-03T12:01:42  *** Giszmo has joined #bitcoin-core-dev
1082017-10-03T12:03:49  *** Muis has quit IRC
1092017-10-03T12:10:11  *** AaronvanW has quit IRC
1102017-10-03T12:18:56  *** alreadylate has joined #bitcoin-core-dev
1112017-10-03T12:21:04  *** alreadylate has quit IRC
1122017-10-03T12:21:56  *** alreadylate has joined #bitcoin-core-dev
1132017-10-03T12:21:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1142017-10-03T12:22:46  *** AaronvanW has joined #bitcoin-core-dev
1152017-10-03T12:31:29  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/8ddf60db7ad6...dbc4ae039630
1162017-10-03T12:31:30  <bitcoin-git> bitcoin/master 5ab586f James O'Beirne: Consolidate CMerkleBlock constructor into a single method...
1172017-10-03T12:31:30  <bitcoin-git> bitcoin/master 46ce223 James O'Beirne: Add tests for CMerkleBlock usage with txids specified
1182017-10-03T12:31:31  <bitcoin-git> bitcoin/master dbc4ae0 MarcoFalke: Merge #11293: Deduplicate CMerkleBlock construction code, add test coverage...
1192017-10-03T12:31:58  *** promag has joined #bitcoin-core-dev
1202017-10-03T12:32:03  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #11293: Deduplicate CMerkleBlock construction code, add test coverage (master...dedup-cmerkleblock) https://github.com/bitcoin/bitcoin/pull/11293
1212017-10-03T12:34:16  *** alreadylate has quit IRC
1222017-10-03T12:48:42  *** PaulCapestany has quit IRC
1232017-10-03T12:50:11  *** promag has quit IRC
1242017-10-03T13:12:33  *** jtimon has quit IRC
1252017-10-03T13:25:12  *** laurentmt has quit IRC
1262017-10-03T13:43:25  *** intcat has quit IRC
1272017-10-03T13:44:07  *** intcat has joined #bitcoin-core-dev
1282017-10-03T13:50:44  *** promag has joined #bitcoin-core-dev
1292017-10-03T13:59:59  <BlueMatt> jonasschnelli: hmm, I thought you were going to always set NODE_NETWORK_LIMITED?
1302017-10-03T14:00:04  <BlueMatt> ie whether pruned or not just set it
1312017-10-03T14:18:13  *** alreadylate has joined #bitcoin-core-dev
1322017-10-03T14:23:47  *** wraithm has joined #bitcoin-core-dev
1332017-10-03T14:42:42  *** promag has quit IRC
1342017-10-03T14:43:15  *** meshcollider has quit IRC
1352017-10-03T14:45:03  *** promag has joined #bitcoin-core-dev
1362017-10-03T14:59:53  *** Dizzle has joined #bitcoin-core-dev
1372017-10-03T15:02:05  *** Murch has quit IRC
1382017-10-03T15:03:55  *** promag has quit IRC
1392017-10-03T15:17:33  *** promag has joined #bitcoin-core-dev
1402017-10-03T15:21:04  *** Chris_Stewart_5 has quit IRC
1412017-10-03T15:26:17  *** Murch has joined #bitcoin-core-dev
1422017-10-03T15:28:01  *** alreadylate has quit IRC
1432017-10-03T15:28:18  *** Dizzle has quit IRC
1442017-10-03T15:36:17  <jnewbery> I'm late to the promag BlueMatt zmq party, but my view is that there are no docs stating that block/tx/wallet notifications are sent in any particular order, therefore our tests shouldn't expect a particular ordering
1452017-10-03T15:36:57  <BlueMatt> jnewbery: I think our tests should test for what clients may be relying on
1462017-10-03T15:37:07  <BlueMatt> and I think it would be reasonable(ish) for a client to rely on ordering
1472017-10-03T15:37:54  <BlueMatt> (but, more importantly, it doesnt matter much atm...keeping the ordering consistent across 0.16 should be no problem, and we can follow a deprecation window if we write up some docs easily)
1482017-10-03T15:45:05  *** JackH has quit IRC
1492017-10-03T15:51:50  *** abpa has joined #bitcoin-core-dev
1502017-10-03T15:57:07  *** abpa has quit IRC
1512017-10-03T15:59:01  *** JackH has joined #bitcoin-core-dev
1522017-10-03T16:00:33  *** W4RL0RD has quit IRC
1532017-10-03T16:01:04  *** KevinPan has joined #bitcoin-core-dev
1542017-10-03T16:03:27  *** W4RL0RD has joined #bitcoin-core-dev
1552017-10-03T16:03:55  *** jj_ has joined #bitcoin-core-dev
1562017-10-03T16:04:04  <jj_> hi
1572017-10-03T16:06:18  *** BashCo has quit IRC
1582017-10-03T16:06:58  *** KevinPan has quit IRC
1592017-10-03T16:17:13  *** jj_ has quit IRC
1602017-10-03T16:18:02  *** abpa has joined #bitcoin-core-dev
1612017-10-03T16:27:33  *** BashCo has joined #bitcoin-core-dev
1622017-10-03T16:28:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1632017-10-03T16:49:53  <jnewbery> BlueMatt: to be clear, are you talking about ordering within a notification type (ie blocks are published in the order they arrive), or between notification types (ie the hashtx notification always comes before the rawtx notification)?
1642017-10-03T16:50:22  <BlueMatt> jnewbery: between notification types
1652017-10-03T16:50:44  <jnewbery> ok, in that case I disagree :)
1662017-10-03T16:53:48  <jnewbery> clients that are relying on that ordering rather than checking the command/topic are broken
1672017-10-03T16:54:52  <jnewbery> that said, I fully support documenting all this!
1682017-10-03T16:55:19  <BlueMatt> why shouldnt they rely on ordering between them? there is useful information there
1692017-10-03T16:57:46  <jnewbery> is there? bitcoind receives a transaction and sends (1) a notification of the txid; and (2) a notification of the raw tx. What is the useful information in that order? Seems arbitrary to me
1702017-10-03T16:58:57  <BlueMatt> no, it also sends transactions that were either included or removed in a block connection/disconnection
1712017-10-03T16:59:06  <BlueMatt> in the same tx notification that it uses for transactions added to mempool
1722017-10-03T16:59:11  <BlueMatt> (none of this is documented, btw.....)
1732017-10-03T17:00:55  <jnewbery> right, so if I receive a block notification and then a tx notification I can infer that the tx was received in the block... or that it was received and added to the mempool shortly after the block was connected. Again, not much useful information there
1742017-10-03T17:01:43  <BlueMatt> no, brfore
1752017-10-03T17:01:54  <BlueMatt> because the ordering is consistent you know that it was added after the block
1762017-10-03T17:02:02  <BlueMatt> so you know that it was either part of the block or added before
1772017-10-03T17:02:31  <BlueMatt> specifically, when you get a block notification, you know that youve gotten notified for all transactionw which in blocks prior to and including the block for which you were notified
1782017-10-03T17:02:39  <BlueMatt> which is a useful bit of information
1792017-10-03T17:03:06  <jnewbery> ah. ok, that makes sense. Thanks
1802017-10-03T17:03:27  <BlueMatt> (this is, coincidentally, the bit of information our wallet cares about :p)
1812017-10-03T17:04:28  <jnewbery> ok, conclusion: we need some documentation!
1822017-10-03T17:04:47  <BlueMatt> 100x
1832017-10-03T17:12:25  *** W4RL0RD has quit IRC
1842017-10-03T17:17:53  *** Ylbam has joined #bitcoin-core-dev
1852017-10-03T17:24:51  *** m8tion has quit IRC
1862017-10-03T17:28:05  *** promag has joined #bitcoin-core-dev
1872017-10-03T17:29:43  <cfields> jonasschnelli: around?
1882017-10-03T17:31:04  <cfields> BlueMatt: hah! I came to nag jonasschnelli about the same thing. NODE_NETWORK implies NODE_NETWORK_LIMITED, so I agree that _LIMITED should always be set.
1892017-10-03T17:31:59  <cfields> otherwise, we're introducing negative service flags, which is a bad idea imo.
1902017-10-03T17:33:42  <BlueMatt> heh
1912017-10-03T17:36:34  *** Guyver2 has quit IRC
1922017-10-03T17:41:28  <cfields> jonasschnelli: I think the complicated address selection and "alternative services" points out another issue with the BIP. When we're making outgoing connections (assuming we're not in ibd), we don't care if the node we connect to is limited or not...
1932017-10-03T17:41:47  <cfields> I think what we're missing is NODE_FULL, which says nothing about willingness to serve
1942017-10-03T17:49:57  *** promag has quit IRC
1952017-10-03T18:02:03  *** laurentmt has joined #bitcoin-core-dev
1962017-10-03T18:05:54  <Murch> Hey, is it still accurate that pruning nodes will not serve any blocks, or are they meanwhile serving the ones they have?
1972017-10-03T18:05:58  *** laurentmt has quit IRC
1982017-10-03T18:08:16  *** laurentmt has joined #bitcoin-core-dev
1992017-10-03T18:09:00  <sipa> Murch: i believe they have always served the blocks they have, but no other node would ask blocks from them due to lack of a service bit indicating that they do
2002017-10-03T18:09:03  <cfields> as implemented here, looks like we'll never request them from a limited node
2012017-10-03T18:09:23  <cfields> i was working up my complaint about that :)
2022017-10-03T18:15:10  <cfields> sipa: what do you think about a NODE_FULL (or so) flag which indicates that the node can validate the entire chain? That way (say in a year or two from now), we can require NODE_FULL, prefer NODE_NETWORK, and tolerate NODE_NETWORK_LIMITED ? I really don't like the outbound selection policy wonkyness that bip159 gives us.
2032017-10-03T18:15:19  <cfields> (maybe that's been suggested before, but I've missed it?)
2042017-10-03T18:16:15  <sipa> cfields: i've suggested that, but i'm not sure it's needed
2052017-10-03T18:16:23  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #11445: [qa] 0.15.1 Backports (0.15...Mf1710-0151qaBackports) https://github.com/bitcoin/bitcoin/pull/11445
2062017-10-03T18:16:57  *** meshcollider has joined #bitcoin-core-dev
2072017-10-03T18:17:10  <cfields> that also makes it much simpler for nodes just interested in mempool transactions, as they don't have to go through any selection process
2082017-10-03T18:18:56  <Murch> thanks sipa
2092017-10-03T18:24:49  <sipa> cfields: the question is whether we see having 288 blocks (or some other small number) as essential to being able to stay in sync
2102017-10-03T18:25:16  <sipa> in which case FULL is equivalent to NETWORK_LIMITEF
2112017-10-03T18:26:06  <cfields> sure, but FULL could also mean "NETWORK, but I'm not serving any."
2122017-10-03T18:26:09  <bitcoin-git> [bitcoin] achow101 opened pull request #11446: Bad block interrogation (master...bad-block-interrogation) https://github.com/bitcoin/bitcoin/pull/11446
2132017-10-03T18:26:43  <sipa> cfields: if it means strictly only tip blocks, that's not something you want to connect to... what if there's a reorg
2142017-10-03T18:27:12  *** AaronvanW has quit IRC
2152017-10-03T18:28:44  <cfields> sipa: I'm not saying that actually running that way would be useful. I don't imagine anyone would. I'm just arguing for advertising that capability, which would almost certainly be paired with some other capability. but if you don't have it, we know we're not interested in connecting.
2162017-10-03T18:29:24  <cfields> so full nodes would advertise all 3, pruned would advertise 2.
2172017-10-03T18:30:00  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #11447: 0.15.1: Backport fixes (0.15...Mf1710-0151Backports) https://github.com/bitcoin/bitcoin/pull/11447
2182017-10-03T18:30:43  <sipa> cfields: right, but i'm not sure there is a use for something that can only serve blocks at the tip
2192017-10-03T18:30:56  *** SopaXorzTaker has quit IRC
2202017-10-03T18:31:08  <sipa> cfields: so right now, we'd have LIMITED which means tip + 288 blocks below
2212017-10-03T18:31:27  *** AaronvanW has joined #bitcoin-core-dev
2222017-10-03T18:31:49  <sipa> at some point there appears a need for more pruning, or less bandwidth, or whatever, and only guaranteeing tip + 10 blocks deep, so a VERY_LIMITED is added for that
2232017-10-03T18:32:12  <sipa> that only used 2 bits, while you'd use 3 :)
2242017-10-03T18:33:52  <cfields> yes, but now nobody connects to VERY_LIMITED for a few weeks/months, whereas they could be used as a last resort with 3 bits because we know they're full and might have ~tip
2252017-10-03T18:34:16  <cfields> (not the strongest argument, i realize :)
2262017-10-03T18:34:43  <sipa> my point is that there is no point having a separate bit for a feature that is not separately useful
2272017-10-03T18:35:18  <cfields> i guess this achieves what I'm after as-is... in a year or two, we simply require LIMITED and prefer NETWORK
2282017-10-03T18:35:39  <sipa> when we're in sync, we should treat the two as identical
2292017-10-03T18:35:43  <BlueMatt> sipa: we dont need to be worried about using 1 extra bit in nServices
2302017-10-03T18:35:45  <BlueMatt> we have so many
2312017-10-03T18:36:18  <BlueMatt> no reason to get complicated and save the ability to re-use NODE_NETWORK_LIMITED when NODE_NETWORK is set
2322017-10-03T18:36:26  <cfields> sipa: sure. It's just outbound selection i'm trying to reason through
2332017-10-03T18:36:31  <BlueMatt> and we have so few things we want to set in nServices
2342017-10-03T18:36:33  <sipa> BlueMatt: huh? we're not talking about that
2352017-10-03T18:36:40  <BlueMatt> oh, did I miss context
2362017-10-03T18:36:42  <sipa> i'm totally in favor of always setting LIMITED
2372017-10-03T18:36:51  <BlueMatt> ok, ignore me
2382017-10-03T18:36:52  <cfields> BlueMatt: yea, I suggested a 3rd bit for NODE_FULL
2392017-10-03T18:37:01  <BlueMatt> ah
2402017-10-03T18:37:01  <BlueMatt> no
2412017-10-03T18:37:03  <BlueMatt> why
2422017-10-03T18:37:08  <BlueMatt> thats what NODE_NETWORK means....
2432017-10-03T18:37:16  <cfields> heh, see above
2442017-10-03T18:37:43  <BlueMatt> how about we save it for when its useful? :P
2452017-10-03T18:38:17  <BlueMatt> when someone introduces a NODE_SERVES_COMPRESSED_BLOCKS bit, we should talk about splitting NODE_NETWORK, until then.......... :p
2462017-10-03T18:52:23  *** promag has joined #bitcoin-core-dev
2472017-10-03T18:54:21  *** chjj has quit IRC
2482017-10-03T18:57:34  *** promag has quit IRC
2492017-10-03T18:59:05  *** Emcy has joined #bitcoin-core-dev
2502017-10-03T19:14:30  *** promag has joined #bitcoin-core-dev
2512017-10-03T19:19:42  *** arubi has quit IRC
2522017-10-03T19:20:09  *** arubi has joined #bitcoin-core-dev
2532017-10-03T19:23:12  *** Dizzle has joined #bitcoin-core-dev
2542017-10-03T19:27:08  *** moctos has quit IRC
2552017-10-03T19:28:27  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/dbc4ae039630...b4a509a3f817
2562017-10-03T19:28:28  <bitcoin-git> bitcoin/master fafff12 MarcoFalke: qa: Restore bitcoin-util-test py2 compatibility
2572017-10-03T19:28:28  <bitcoin-git> bitcoin/master b4a509a MarcoFalke: Merge #11433: qa: Restore bitcoin-util-test py2 compatibility...
2582017-10-03T19:29:06  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #11433: qa: Restore bitcoin-util-test py2 compatibility (master...Mf1710-qaUtilPy2) https://github.com/bitcoin/bitcoin/pull/11433
2592017-10-03T19:29:44  *** laurentmt1 has joined #bitcoin-core-dev
2602017-10-03T19:30:13  *** promag has quit IRC
2612017-10-03T19:30:35  *** laurentmt has quit IRC
2622017-10-03T19:30:36  *** laurentmt1 is now known as laurentmt
2632017-10-03T19:51:17  *** chjj has joined #bitcoin-core-dev
2642017-10-03T20:00:49  *** Guyver2 has joined #bitcoin-core-dev
2652017-10-03T20:05:41  *** Cheeseo has joined #bitcoin-core-dev
2662017-10-03T20:13:57  *** ndrst has quit IRC
2672017-10-03T20:21:23  *** RobertJordan has joined #bitcoin-core-dev
2682017-10-03T20:23:15  *** promag has joined #bitcoin-core-dev
2692017-10-03T20:25:40  *** RobertJordan has quit IRC
2702017-10-03T20:25:47  *** mkarrer has joined #bitcoin-core-dev
2712017-10-03T20:28:27  *** mkarrer has quit IRC
2722017-10-03T20:28:28  *** spinza has quit IRC
2732017-10-03T20:28:40  *** mkarrer has joined #bitcoin-core-dev
2742017-10-03T20:30:30  *** mess110 has joined #bitcoin-core-dev
2752017-10-03T20:31:02  *** Guest86958 has joined #bitcoin-core-dev
2762017-10-03T20:34:06  *** spinza has joined #bitcoin-core-dev
2772017-10-03T20:39:27  *** promag has quit IRC
2782017-10-03T20:42:04  *** laurentmt1 has joined #bitcoin-core-dev
2792017-10-03T20:43:45  *** laurentmt has quit IRC
2802017-10-03T20:43:45  *** laurentmt1 is now known as laurentmt
2812017-10-03T20:45:36  *** goatpig has quit IRC
2822017-10-03T21:16:27  *** laurentmt has quit IRC
2832017-10-03T21:17:41  *** timothy has quit IRC
2842017-10-03T21:17:43  *** drizztbsd has joined #bitcoin-core-dev
2852017-10-03T21:19:36  *** AaronvanW has quit IRC
2862017-10-03T21:20:15  *** AaronvanW has joined #bitcoin-core-dev
2872017-10-03T21:24:39  *** AaronvanW has quit IRC
2882017-10-03T21:31:44  *** AaronvanW has joined #bitcoin-core-dev
2892017-10-03T21:40:39  *** timothy has joined #bitcoin-core-dev
2902017-10-03T21:41:21  *** drizztbsd has quit IRC
2912017-10-03T21:44:57  *** Guyver2 has quit IRC
2922017-10-03T21:57:35  *** Chris_Stewart_5 has quit IRC
2932017-10-03T21:57:45  <bitcoin-git> [bitcoin] mess110 opened pull request #11448: [gui] reset addrProxy/addrSeparateProxyTor if colon char missing (master...ensure_colon_in_proxies_qsettings_storage) https://github.com/bitcoin/bitcoin/pull/11448
2942017-10-03T22:01:00  *** Scrat has joined #bitcoin-core-dev
2952017-10-03T22:01:12  *** timothy has quit IRC
2962017-10-03T22:06:54  *** jtimon has joined #bitcoin-core-dev
2972017-10-03T22:29:03  *** Alina-malina has quit IRC
2982017-10-03T22:30:31  *** Alina-malina has joined #bitcoin-core-dev
2992017-10-03T22:34:23  *** Dizzle has quit IRC
3002017-10-03T22:41:46  *** Cheeseo has quit IRC
3012017-10-03T22:47:46  *** mess110 has quit IRC
3022017-10-03T22:49:05  *** Alina-malina has quit IRC
3032017-10-03T22:50:28  *** wraithm has quit IRC
3042017-10-03T22:51:58  *** Alina-malina has joined #bitcoin-core-dev
3052017-10-03T22:53:42  *** merehap__ has quit IRC
3062017-10-03T22:54:00  *** merehap__ has joined #bitcoin-core-dev
3072017-10-03T23:08:09  *** vicenteH has quit IRC
3082017-10-03T23:19:20  *** PaulCapestany has joined #bitcoin-core-dev
3092017-10-03T23:28:51  *** Vortiago has quit IRC
3102017-10-03T23:32:07  *** Vortiago has joined #bitcoin-core-dev
3112017-10-03T23:38:12  *** AaronvanW has quit IRC
3122017-10-03T23:38:48  *** AaronvanW has joined #bitcoin-core-dev
3132017-10-03T23:56:31  *** abpa has quit IRC