1 2017-10-03T00:01:01  *** promag has quit IRC
  2 2017-10-03T00:16:35  *** justanotheruser has joined #bitcoin-core-dev
  3 2017-10-03T00:17:37  *** promag has joined #bitcoin-core-dev
  4 2017-10-03T00:21:17  *** justanotheruser has quit IRC
  5 2017-10-03T00:21:52  *** promag has quit IRC
  6 2017-10-03T00:30:23  *** AaronvanW has quit IRC
  7 2017-10-03T00:30:59  *** AaronvanW has joined #bitcoin-core-dev
  8 2017-10-03T00:35:05  *** AaronvanW has quit IRC
  9 2017-10-03T00:37:02  *** justanotheruser has joined #bitcoin-core-dev
 10 2017-10-03T00:51:36  *** tripleslash has joined #bitcoin-core-dev
 11 2017-10-03T00:55:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 12 2017-10-03T00:58:44  *** dabura667 has joined #bitcoin-core-dev
 13 2017-10-03T01:00:08  *** promag has joined #bitcoin-core-dev
 14 2017-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
 15 2017-10-03T01:19:50  <sipa> luke-jr: care to elaborate?
 16 2017-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.)
 17 2017-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)
 18 2017-10-03T01:29:32  <sipa> esotericnonsense: yes, JSON RPC supports named arguments
 19 2017-10-03T01:29:41  <sipa> where the arguments are not an array but an object
 20 2017-10-03T01:30:00  <esotericnonsense> for all calls? that's awesome. argh, /me goes off to read the manual.
 21 2017-10-03T01:30:09  <sipa> yes, for all calls
 22 2017-10-03T01:30:34  *** justanotheruser has quit IRC
 23 2017-10-03T01:31:38  <sipa> (since 0.13 or 0.14 it's implemented in bitcoin core, i believe)
 24 2017-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
 25 2017-10-03T01:34:57  <sipa> luke-jr: an options object is also an unwieldy and terrible interface
 26 2017-10-03T01:36:04  <sipa> (see kallewoof's comment above)
 27 2017-10-03T01:37:01  <luke-jr> sipa: that's an issue with sh, not JSON-RPC
 28 2017-10-03T01:37:40  <sipa> luke-jr: programmatic use of JSON-RPC should just upgrade to named arguments, IMHO
 29 2017-10-03T01:37:52  <sipa> safer, clearer, and more flexible in every way
 30 2017-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
 31 2017-10-03T01:41:45  <luke-jr> some languages don't even support named arguments
 32 2017-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
 33 2017-10-03T01:45:36  *** justanotheruser has joined #bitcoin-core-dev
 34 2017-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.
 35 2017-10-03T01:48:27  <luke-jr> sipa: this is not an argument to have a crappy interface
 36 2017-10-03T01:49:01  <sipa> luke-jr: indeed it isn't, but i know of no solution to that problem
 37 2017-10-03T01:49:13  <sipa> having many parameters to an RPC will always be annoying to use
 38 2017-10-03T01:49:54  <luke-jr> the options object is the solution we've used so far
 39 2017-10-03T01:50:25  <sipa> and i claim that named arguments are in no way worse than an options object
 40 2017-10-03T01:50:35  <sipa> (in some ways it's equally terribly, though)
 41 2017-10-03T01:51:11  <luke-jr> even if it were true, that's irrelevant, since the topic is the ordered params API
 42 2017-10-03T01:51:42  *** promag has quit IRC
 43 2017-10-03T01:51:56  <sipa> i don't think that's a very interesting topic
 44 2017-10-03T01:52:02  <sipa> when a better alternative exists
 45 2017-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
 46 2017-10-03T01:58:17  *** Murch has quit IRC
 47 2017-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.
 48 2017-10-03T02:03:53  <gribble> https://github.com/bitcoin/bitcoin/issues/1828 | Base58 en-/de-coding by roques · Pull Request #1828 · bitcoin/bitcoin · GitHub
 49 2017-10-03T02:04:04  <esotericnonsense> no gribble. (probably the wrong channel anyway).
 50 2017-10-03T02:05:48  *** fanquake has joined #bitcoin-core-dev
 51 2017-10-03T02:20:45  *** Murch has joined #bitcoin-core-dev
 52 2017-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
 53 2017-10-03T02:34:52  *** Alina-malina has quit IRC
 54 2017-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
 55 2017-10-03T02:40:34  *** Alina-malina has joined #bitcoin-core-dev
 56 2017-10-03T02:44:43  *** fanquake has quit IRC
 57 2017-10-03T02:44:48  *** Giszmo has quit IRC
 58 2017-10-03T03:14:40  *** Chris_Stewart_5 has quit IRC
 59 2017-10-03T03:23:10  *** chjj has joined #bitcoin-core-dev
 60 2017-10-03T03:23:31  *** dermoth has quit IRC
 61 2017-10-03T03:24:11  *** dermoth has joined #bitcoin-core-dev
 62 2017-10-03T03:34:49  *** owowo has quit IRC
 63 2017-10-03T03:40:47  *** owowo has joined #bitcoin-core-dev
 64 2017-10-03T03:53:21  *** meshcollider has quit IRC
 65 2017-10-03T04:56:35  *** Alina-malina has quit IRC
 66 2017-10-03T04:57:39  *** Alina-malina has joined #bitcoin-core-dev
 67 2017-10-03T05:00:19  *** intcat has quit IRC
 68 2017-10-03T05:33:21  *** Alina-malina has quit IRC
 69 2017-10-03T05:34:40  *** Alina-malina has joined #bitcoin-core-dev
 70 2017-10-03T05:34:41  *** Alina-malina has joined #bitcoin-core-dev
 71 2017-10-03T05:42:54  *** sanada has quit IRC
 72 2017-10-03T06:12:08  *** chjj has quit IRC
 73 2017-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
 74 2017-10-03T06:36:57  *** chjj has joined #bitcoin-core-dev
 75 2017-10-03T06:53:48  *** meshcollider has joined #bitcoin-core-dev
 76 2017-10-03T07:15:58  *** timothy has joined #bitcoin-core-dev
 77 2017-10-03T07:29:49  *** laurentmt has joined #bitcoin-core-dev
 78 2017-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
 79 2017-10-03T08:27:48  *** alreadylate has joined #bitcoin-core-dev
 80 2017-10-03T08:28:17  *** murchandamus has quit IRC
 81 2017-10-03T08:31:09  *** murchandamus has joined #bitcoin-core-dev
 82 2017-10-03T08:52:35  *** dabura667 has quit IRC
 83 2017-10-03T09:13:42  *** dabura667 has joined #bitcoin-core-dev
 84 2017-10-03T09:17:18  *** Deacyde has joined #bitcoin-core-dev
 85 2017-10-03T09:49:51  *** murchandamus has quit IRC
 86 2017-10-03T09:50:52  *** murchandamus has joined #bitcoin-core-dev
 87 2017-10-03T09:57:22  *** murchandamus has quit IRC
 88 2017-10-03T09:57:49  *** murchandamus has joined #bitcoin-core-dev
 89 2017-10-03T09:59:20  *** tester8 has joined #bitcoin-core-dev
 90 2017-10-03T09:59:32  <tester8> hello
 91 2017-10-03T09:59:39  *** tester8 has left #bitcoin-core-dev
 92 2017-10-03T10:03:48  *** intcat has joined #bitcoin-core-dev
 93 2017-10-03T10:06:02  *** m8tion has joined #bitcoin-core-dev
 94 2017-10-03T10:13:34  *** AaronvanW has joined #bitcoin-core-dev
 95 2017-10-03T10:18:50  *** dabura667 has quit IRC
 96 2017-10-03T10:19:03  *** Emcy has quit IRC
 97 2017-10-03T10:22:20  *** JackH has joined #bitcoin-core-dev
 98 2017-10-03T10:33:47  *** AaronvanW has quit IRC
 99 2017-10-03T10:34:26  *** AaronvanW has joined #bitcoin-core-dev
100 2017-10-03T10:51:38  *** Guyver2 has joined #bitcoin-core-dev
101 2017-10-03T10:58:48  *** BashCo has quit IRC
102 2017-10-03T11:09:47  *** alreadylate has quit IRC
103 2017-10-03T11:15:30  *** W4RL0RD has joined #bitcoin-core-dev
104 2017-10-03T11:16:50  *** BashCo has joined #bitcoin-core-dev
105 2017-10-03T11:20:00  *** SopaXorzTaker has joined #bitcoin-core-dev
106 2017-10-03T11:33:10  *** Deacyde has quit IRC
107 2017-10-03T12:01:42  *** Giszmo has joined #bitcoin-core-dev
108 2017-10-03T12:03:49  *** Muis has quit IRC
109 2017-10-03T12:10:11  *** AaronvanW has quit IRC
110 2017-10-03T12:18:56  *** alreadylate has joined #bitcoin-core-dev
111 2017-10-03T12:21:04  *** alreadylate has quit IRC
112 2017-10-03T12:21:56  *** alreadylate has joined #bitcoin-core-dev
113 2017-10-03T12:21:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev
114 2017-10-03T12:22:46  *** AaronvanW has joined #bitcoin-core-dev
115 2017-10-03T12:31:29  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/8ddf60db7ad6...dbc4ae039630
116 2017-10-03T12:31:30  <bitcoin-git> bitcoin/master 5ab586f James O'Beirne: Consolidate CMerkleBlock constructor into a single method...
117 2017-10-03T12:31:30  <bitcoin-git> bitcoin/master 46ce223 James O'Beirne: Add tests for CMerkleBlock usage with txids specified
118 2017-10-03T12:31:31  <bitcoin-git> bitcoin/master dbc4ae0 MarcoFalke: Merge #11293: Deduplicate CMerkleBlock construction code, add test coverage...
119 2017-10-03T12:31:58  *** promag has joined #bitcoin-core-dev
120 2017-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
121 2017-10-03T12:34:16  *** alreadylate has quit IRC
122 2017-10-03T12:48:42  *** PaulCapestany has quit IRC
123 2017-10-03T12:50:11  *** promag has quit IRC
124 2017-10-03T13:12:33  *** jtimon has quit IRC
125 2017-10-03T13:25:12  *** laurentmt has quit IRC
126 2017-10-03T13:43:25  *** intcat has quit IRC
127 2017-10-03T13:44:07  *** intcat has joined #bitcoin-core-dev
128 2017-10-03T13:50:44  *** promag has joined #bitcoin-core-dev
129 2017-10-03T13:59:59  <BlueMatt> jonasschnelli: hmm, I thought you were going to always set NODE_NETWORK_LIMITED?
130 2017-10-03T14:00:04  <BlueMatt> ie whether pruned or not just set it
131 2017-10-03T14:18:13  *** alreadylate has joined #bitcoin-core-dev
132 2017-10-03T14:23:47  *** wraithm has joined #bitcoin-core-dev
133 2017-10-03T14:42:42  *** promag has quit IRC
134 2017-10-03T14:43:15  *** meshcollider has quit IRC
135 2017-10-03T14:45:03  *** promag has joined #bitcoin-core-dev
136 2017-10-03T14:59:53  *** Dizzle has joined #bitcoin-core-dev
137 2017-10-03T15:02:05  *** Murch has quit IRC
138 2017-10-03T15:03:55  *** promag has quit IRC
139 2017-10-03T15:17:33  *** promag has joined #bitcoin-core-dev
140 2017-10-03T15:21:04  *** Chris_Stewart_5 has quit IRC
141 2017-10-03T15:26:17  *** Murch has joined #bitcoin-core-dev
142 2017-10-03T15:28:01  *** alreadylate has quit IRC
143 2017-10-03T15:28:18  *** Dizzle has quit IRC
144 2017-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
145 2017-10-03T15:36:57  <BlueMatt> jnewbery: I think our tests should test for what clients may be relying on
146 2017-10-03T15:37:07  <BlueMatt> and I think it would be reasonable(ish) for a client to rely on ordering
147 2017-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)
148 2017-10-03T15:45:05  *** JackH has quit IRC
149 2017-10-03T15:51:50  *** abpa has joined #bitcoin-core-dev
150 2017-10-03T15:57:07  *** abpa has quit IRC
151 2017-10-03T15:59:01  *** JackH has joined #bitcoin-core-dev
152 2017-10-03T16:00:33  *** W4RL0RD has quit IRC
153 2017-10-03T16:01:04  *** KevinPan has joined #bitcoin-core-dev
154 2017-10-03T16:03:27  *** W4RL0RD has joined #bitcoin-core-dev
155 2017-10-03T16:03:55  *** jj_ has joined #bitcoin-core-dev
156 2017-10-03T16:04:04  <jj_> hi
157 2017-10-03T16:06:18  *** BashCo has quit IRC
158 2017-10-03T16:06:58  *** KevinPan has quit IRC
159 2017-10-03T16:17:13  *** jj_ has quit IRC
160 2017-10-03T16:18:02  *** abpa has joined #bitcoin-core-dev
161 2017-10-03T16:27:33  *** BashCo has joined #bitcoin-core-dev
162 2017-10-03T16:28:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
163 2017-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)?
164 2017-10-03T16:50:22  <BlueMatt> jnewbery: between notification types
165 2017-10-03T16:50:44  <jnewbery> ok, in that case I disagree :)
166 2017-10-03T16:53:48  <jnewbery> clients that are relying on that ordering rather than checking the command/topic are broken
167 2017-10-03T16:54:52  <jnewbery> that said, I fully support documenting all this!
168 2017-10-03T16:55:19  <BlueMatt> why shouldnt they rely on ordering between them? there is useful information there
169 2017-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
170 2017-10-03T16:58:57  <BlueMatt> no, it also sends transactions that were either included or removed in a block connection/disconnection
171 2017-10-03T16:59:06  <BlueMatt> in the same tx notification that it uses for transactions added to mempool
172 2017-10-03T16:59:11  <BlueMatt> (none of this is documented, btw.....)
173 2017-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
174 2017-10-03T17:01:43  <BlueMatt> no, brfore
175 2017-10-03T17:01:54  <BlueMatt> because the ordering is consistent you know that it was added after the block
176 2017-10-03T17:02:02  <BlueMatt> so you know that it was either part of the block or added before
177 2017-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
178 2017-10-03T17:02:39  <BlueMatt> which is a useful bit of information
179 2017-10-03T17:03:06  <jnewbery> ah. ok, that makes sense. Thanks
180 2017-10-03T17:03:27  <BlueMatt> (this is, coincidentally, the bit of information our wallet cares about :p)
181 2017-10-03T17:04:28  <jnewbery> ok, conclusion: we need some documentation!
182 2017-10-03T17:04:47  <BlueMatt> 100x
183 2017-10-03T17:12:25  *** W4RL0RD has quit IRC
184 2017-10-03T17:17:53  *** Ylbam has joined #bitcoin-core-dev
185 2017-10-03T17:24:51  *** m8tion has quit IRC
186 2017-10-03T17:28:05  *** promag has joined #bitcoin-core-dev
187 2017-10-03T17:29:43  <cfields> jonasschnelli: around?
188 2017-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.
189 2017-10-03T17:31:59  <cfields> otherwise, we're introducing negative service flags, which is a bad idea imo.
190 2017-10-03T17:33:42  <BlueMatt> heh
191 2017-10-03T17:36:34  *** Guyver2 has quit IRC
192 2017-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...
193 2017-10-03T17:41:47  <cfields> I think what we're missing is NODE_FULL, which says nothing about willingness to serve
194 2017-10-03T17:49:57  *** promag has quit IRC
195 2017-10-03T18:02:03  *** laurentmt has joined #bitcoin-core-dev
196 2017-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?
197 2017-10-03T18:05:58  *** laurentmt has quit IRC
198 2017-10-03T18:08:16  *** laurentmt has joined #bitcoin-core-dev
199 2017-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
200 2017-10-03T18:09:03  <cfields> as implemented here, looks like we'll never request them from a limited node
201 2017-10-03T18:09:23  <cfields> i was working up my complaint about that :)
202 2017-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.
203 2017-10-03T18:15:19  <cfields> (maybe that's been suggested before, but I've missed it?)
204 2017-10-03T18:16:15  <sipa> cfields: i've suggested that, but i'm not sure it's needed
205 2017-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
206 2017-10-03T18:16:57  *** meshcollider has joined #bitcoin-core-dev
207 2017-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
208 2017-10-03T18:18:56  <Murch> thanks sipa
209 2017-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
210 2017-10-03T18:25:16  <sipa> in which case FULL is equivalent to NETWORK_LIMITEF
211 2017-10-03T18:26:06  <cfields> sure, but FULL could also mean "NETWORK, but I'm not serving any."
212 2017-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
213 2017-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
214 2017-10-03T18:27:12  *** AaronvanW has quit IRC
215 2017-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.
216 2017-10-03T18:29:24  <cfields> so full nodes would advertise all 3, pruned would advertise 2.
217 2017-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
218 2017-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
219 2017-10-03T18:30:56  *** SopaXorzTaker has quit IRC
220 2017-10-03T18:31:08  <sipa> cfields: so right now, we'd have LIMITED which means tip + 288 blocks below
221 2017-10-03T18:31:27  *** AaronvanW has joined #bitcoin-core-dev
222 2017-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
223 2017-10-03T18:32:12  <sipa> that only used 2 bits, while you'd use 3 :)
224 2017-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
225 2017-10-03T18:34:16  <cfields> (not the strongest argument, i realize :)
226 2017-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
227 2017-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
228 2017-10-03T18:35:39  <sipa> when we're in sync, we should treat the two as identical
229 2017-10-03T18:35:43  <BlueMatt> sipa: we dont need to be worried about using 1 extra bit in nServices
230 2017-10-03T18:35:45  <BlueMatt> we have so many
231 2017-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
232 2017-10-03T18:36:26  <cfields> sipa: sure. It's just outbound selection i'm trying to reason through
233 2017-10-03T18:36:31  <BlueMatt> and we have so few things we want to set in nServices
234 2017-10-03T18:36:33  <sipa> BlueMatt: huh? we're not talking about that
235 2017-10-03T18:36:40  <BlueMatt> oh, did I miss context
236 2017-10-03T18:36:42  <sipa> i'm totally in favor of always setting LIMITED
237 2017-10-03T18:36:51  <BlueMatt> ok, ignore me
238 2017-10-03T18:36:52  <cfields> BlueMatt: yea, I suggested a 3rd bit for NODE_FULL
239 2017-10-03T18:37:01  <BlueMatt> ah
240 2017-10-03T18:37:01  <BlueMatt> no
241 2017-10-03T18:37:03  <BlueMatt> why
242 2017-10-03T18:37:08  <BlueMatt> thats what NODE_NETWORK means....
243 2017-10-03T18:37:16  <cfields> heh, see above
244 2017-10-03T18:37:43  <BlueMatt> how about we save it for when its useful? :P
245 2017-10-03T18:38:17  <BlueMatt> when someone introduces a NODE_SERVES_COMPRESSED_BLOCKS bit, we should talk about splitting NODE_NETWORK, until then.......... :p
246 2017-10-03T18:52:23  *** promag has joined #bitcoin-core-dev
247 2017-10-03T18:54:21  *** chjj has quit IRC
248 2017-10-03T18:57:34  *** promag has quit IRC
249 2017-10-03T18:59:05  *** Emcy has joined #bitcoin-core-dev
250 2017-10-03T19:14:30  *** promag has joined #bitcoin-core-dev
251 2017-10-03T19:19:42  *** arubi has quit IRC
252 2017-10-03T19:20:09  *** arubi has joined #bitcoin-core-dev
253 2017-10-03T19:23:12  *** Dizzle has joined #bitcoin-core-dev
254 2017-10-03T19:27:08  *** moctos has quit IRC
255 2017-10-03T19:28:27  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/dbc4ae039630...b4a509a3f817
256 2017-10-03T19:28:28  <bitcoin-git> bitcoin/master fafff12 MarcoFalke: qa: Restore bitcoin-util-test py2 compatibility
257 2017-10-03T19:28:28  <bitcoin-git> bitcoin/master b4a509a MarcoFalke: Merge #11433: qa: Restore bitcoin-util-test py2 compatibility...
258 2017-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
259 2017-10-03T19:29:44  *** laurentmt1 has joined #bitcoin-core-dev
260 2017-10-03T19:30:13  *** promag has quit IRC
261 2017-10-03T19:30:35  *** laurentmt has quit IRC
262 2017-10-03T19:30:36  *** laurentmt1 is now known as laurentmt
263 2017-10-03T19:51:17  *** chjj has joined #bitcoin-core-dev
264 2017-10-03T20:00:49  *** Guyver2 has joined #bitcoin-core-dev
265 2017-10-03T20:05:41  *** Cheeseo has joined #bitcoin-core-dev
266 2017-10-03T20:13:57  *** ndrst has quit IRC
267 2017-10-03T20:21:23  *** RobertJordan has joined #bitcoin-core-dev
268 2017-10-03T20:23:15  *** promag has joined #bitcoin-core-dev
269 2017-10-03T20:25:40  *** RobertJordan has quit IRC
270 2017-10-03T20:25:47  *** mkarrer has joined #bitcoin-core-dev
271 2017-10-03T20:28:27  *** mkarrer has quit IRC
272 2017-10-03T20:28:28  *** spinza has quit IRC
273 2017-10-03T20:28:40  *** mkarrer has joined #bitcoin-core-dev
274 2017-10-03T20:30:30  *** mess110 has joined #bitcoin-core-dev
275 2017-10-03T20:31:02  *** Guest86958 has joined #bitcoin-core-dev
276 2017-10-03T20:34:06  *** spinza has joined #bitcoin-core-dev
277 2017-10-03T20:39:27  *** promag has quit IRC
278 2017-10-03T20:42:04  *** laurentmt1 has joined #bitcoin-core-dev
279 2017-10-03T20:43:45  *** laurentmt has quit IRC
280 2017-10-03T20:43:45  *** laurentmt1 is now known as laurentmt
281 2017-10-03T20:45:36  *** goatpig has quit IRC
282 2017-10-03T21:16:27  *** laurentmt has quit IRC
283 2017-10-03T21:17:41  *** timothy has quit IRC
284 2017-10-03T21:17:43  *** drizztbsd has joined #bitcoin-core-dev
285 2017-10-03T21:19:36  *** AaronvanW has quit IRC
286 2017-10-03T21:20:15  *** AaronvanW has joined #bitcoin-core-dev
287 2017-10-03T21:24:39  *** AaronvanW has quit IRC
288 2017-10-03T21:31:44  *** AaronvanW has joined #bitcoin-core-dev
289 2017-10-03T21:40:39  *** timothy has joined #bitcoin-core-dev
290 2017-10-03T21:41:21  *** drizztbsd has quit IRC
291 2017-10-03T21:44:57  *** Guyver2 has quit IRC
292 2017-10-03T21:57:35  *** Chris_Stewart_5 has quit IRC
293 2017-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
294 2017-10-03T22:01:00  *** Scrat has joined #bitcoin-core-dev
295 2017-10-03T22:01:12  *** timothy has quit IRC
296 2017-10-03T22:06:54  *** jtimon has joined #bitcoin-core-dev
297 2017-10-03T22:29:03  *** Alina-malina has quit IRC
298 2017-10-03T22:30:31  *** Alina-malina has joined #bitcoin-core-dev
299 2017-10-03T22:34:23  *** Dizzle has quit IRC
300 2017-10-03T22:41:46  *** Cheeseo has quit IRC
301 2017-10-03T22:47:46  *** mess110 has quit IRC
302 2017-10-03T22:49:05  *** Alina-malina has quit IRC
303 2017-10-03T22:50:28  *** wraithm has quit IRC
304 2017-10-03T22:51:58  *** Alina-malina has joined #bitcoin-core-dev
305 2017-10-03T22:53:42  *** merehap__ has quit IRC
306 2017-10-03T22:54:00  *** merehap__ has joined #bitcoin-core-dev
307 2017-10-03T23:08:09  *** vicenteH has quit IRC
308 2017-10-03T23:19:20  *** PaulCapestany has joined #bitcoin-core-dev
309 2017-10-03T23:28:51  *** Vortiago has quit IRC
310 2017-10-03T23:32:07  *** Vortiago has joined #bitcoin-core-dev
311 2017-10-03T23:38:12  *** AaronvanW has quit IRC
312 2017-10-03T23:38:48  *** AaronvanW has joined #bitcoin-core-dev
313 2017-10-03T23:56:31  *** abpa has quit IRC