1 2017-10-03 01:17:49	0|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
  2 2017-10-03 01:19:51	0|sipa|luke-jr: care to elaborate?
  3 2017-10-03 01:28:07	0|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.)
  4 2017-10-03 01:29:11	0|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)
  5 2017-10-03 01:29:33	0|sipa|esotericnonsense: yes, JSON RPC supports named arguments
  6 2017-10-03 01:29:42	0|sipa|where the arguments are not an array but an object
  7 2017-10-03 01:30:01	0|esotericnonsense|for all calls? that's awesome. argh, /me goes off to read the manual.
  8 2017-10-03 01:30:10	0|sipa|yes, for all calls
  9 2017-10-03 01:31:39	0|sipa|(since 0.13 or 0.14 it's implemented in bitcoin core, i believe)
 10 2017-10-03 01:33:58	0|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
 11 2017-10-03 01:34:58	0|sipa|luke-jr: an options object is also an unwieldy and terrible interface
 12 2017-10-03 01:36:05	0|sipa|(see kallewoof's comment above)
 13 2017-10-03 01:37:01	0|luke-jr|sipa: that's an issue with sh, not JSON-RPC
 14 2017-10-03 01:37:41	0|sipa|luke-jr: programmatic use of JSON-RPC should just upgrade to named arguments, IMHO
 15 2017-10-03 01:37:53	0|sipa|safer, clearer, and more flexible in every way
 16 2017-10-03 01:40:26	0|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
 17 2017-10-03 01:41:46	0|luke-jr|some languages don't even support named arguments
 18 2017-10-03 01:42:35	0|sipa|then write a wrapper - invoking that will at worst be as hard as constructing the options object you'd otherwise pass
 19 2017-10-03 01:47:11	0|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.
 20 2017-10-03 01:48:28	0|luke-jr|sipa: this is not an argument to have a crappy interface
 21 2017-10-03 01:49:02	0|sipa|luke-jr: indeed it isn't, but i know of no solution to that problem
 22 2017-10-03 01:49:14	0|sipa|having many parameters to an RPC will always be annoying to use
 23 2017-10-03 01:49:54	0|luke-jr|the options object is the solution we've used so far
 24 2017-10-03 01:50:26	0|sipa|and i claim that named arguments are in no way worse than an options object
 25 2017-10-03 01:50:35	0|sipa|(in some ways it's equally terribly, though)
 26 2017-10-03 01:51:12	0|luke-jr|even if it were true, that's irrelevant, since the topic is the ordered params API
 27 2017-10-03 01:51:56	0|sipa|i don't think that's a very interesting topic
 28 2017-10-03 01:52:03	0|sipa|when a better alternative exists
 29 2017-10-03 01:56:57	0|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
 30 2017-10-03 02:03:52	0|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.
 31 2017-10-03 02:03:53	0|gribble|https://github.com/bitcoin/bitcoin/issues/1828 | Base58 en-/de-coding by roques · Pull Request #1828 · bitcoin/bitcoin · GitHub
 32 2017-10-03 02:04:05	0|esotericnonsense|no gribble. (probably the wrong channel anyway).
 33 2017-10-03 02:33:02	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #11441: rpc/server: Support for specifying options as named parameters (06master...06rpc_namedopts) 02https://github.com/bitcoin/bitcoin/pull/11441
 34 2017-10-03 02:35:00	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #11442: [WIP] [Docs] Update OpenBSD Build Instructions for OpenBSD 6.1 (06master...06openbsd-doc-update) 02https://github.com/bitcoin/bitcoin/pull/11442
 35 2017-10-03 06:12:30	0|bitcoin-git|[13bitcoin] 15mrwhythat closed pull request #11299: [WIP] Implement pruning to location (06master...06prune-to-location-option) 02https://github.com/bitcoin/bitcoin/pull/11299
 36 2017-10-03 08:27:36	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #11443: [qa] Allow "make cov" out-of-tree; Fix rpc mapping check (06master...06Mf1710-qaFixups) 02https://github.com/bitcoin/bitcoin/pull/11443
 37 2017-10-03 09:59:32	0|tester8|hello
 38 2017-10-03 12:31:30	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8ddf60db7ad6...dbc4ae039630
 39 2017-10-03 12:31:31	0|bitcoin-git|13bitcoin/06master 1446ce223 15James O'Beirne: Add tests for CMerkleBlock usage with txids specified
 40 2017-10-03 12:31:31	0|bitcoin-git|13bitcoin/06master 145ab586f 15James O'Beirne: Consolidate CMerkleBlock constructor into a single method...
 41 2017-10-03 12:31:32	0|bitcoin-git|13bitcoin/06master 14dbc4ae0 15MarcoFalke: Merge #11293: Deduplicate CMerkleBlock construction code, add test coverage...
 42 2017-10-03 12:32:04	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11293: Deduplicate CMerkleBlock construction code, add test coverage (06master...06dedup-cmerkleblock) 02https://github.com/bitcoin/bitcoin/pull/11293
 43 2017-10-03 13:59:59	0|BlueMatt|jonasschnelli: hmm, I thought you were going to always set NODE_NETWORK_LIMITED?
 44 2017-10-03 14:00:04	0|BlueMatt|ie whether pruned or not just set it
 45 2017-10-03 15:36:18	0|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
 46 2017-10-03 15:36:58	0|BlueMatt|jnewbery: I think our tests should test for what clients may be relying on
 47 2017-10-03 15:37:07	0|BlueMatt|and I think it would be reasonable(ish) for a client to rely on ordering
 48 2017-10-03 15:37:55	0|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)
 49 2017-10-03 16:04:05	0|jj_|hi
 50 2017-10-03 16:49:54	0|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)?
 51 2017-10-03 16:50:22	0|BlueMatt|jnewbery: between notification types
 52 2017-10-03 16:50:45	0|jnewbery|ok, in that case I disagree :)
 53 2017-10-03 16:53:49	0|jnewbery|clients that are relying on that ordering rather than checking the command/topic are broken
 54 2017-10-03 16:54:53	0|jnewbery|that said, I fully support documenting all this!
 55 2017-10-03 16:55:20	0|BlueMatt|why shouldnt they rely on ordering between them? there is useful information there
 56 2017-10-03 16:57:47	0|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
 57 2017-10-03 16:58:57	0|BlueMatt|no, it also sends transactions that were either included or removed in a block connection/disconnection
 58 2017-10-03 16:59:06	0|BlueMatt|in the same tx notification that it uses for transactions added to mempool
 59 2017-10-03 16:59:12	0|BlueMatt|(none of this is documented, btw.....)
 60 2017-10-03 17:00:56	0|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
 61 2017-10-03 17:01:44	0|BlueMatt|no, brfore
 62 2017-10-03 17:01:55	0|BlueMatt|because the ordering is consistent you know that it was added after the block
 63 2017-10-03 17:02:02	0|BlueMatt|so you know that it was either part of the block or added before
 64 2017-10-03 17:02:31	0|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
 65 2017-10-03 17:02:40	0|BlueMatt|which is a useful bit of information
 66 2017-10-03 17:03:07	0|jnewbery|ah. ok, that makes sense. Thanks
 67 2017-10-03 17:03:28	0|BlueMatt|(this is, coincidentally, the bit of information our wallet cares about :p)
 68 2017-10-03 17:04:29	0|jnewbery|ok, conclusion: we need some documentation!
 69 2017-10-03 17:04:47	0|BlueMatt|100x
 70 2017-10-03 17:29:44	0|cfields|jonasschnelli: around?
 71 2017-10-03 17:31:05	0|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.
 72 2017-10-03 17:32:00	0|cfields|otherwise, we're introducing negative service flags, which is a bad idea imo.
 73 2017-10-03 17:33:43	0|BlueMatt|heh
 74 2017-10-03 17:41:29	0|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...
 75 2017-10-03 17:41:48	0|cfields|I think what we're missing is NODE_FULL, which says nothing about willingness to serve
 76 2017-10-03 18:05:55	0|Murch|Hey, is it still accurate that pruning nodes will not serve any blocks, or are they meanwhile serving the ones they have?
 77 2017-10-03 18:09:01	0|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
 78 2017-10-03 18:09:04	0|cfields|as implemented here, looks like we'll never request them from a limited node
 79 2017-10-03 18:09:24	0|cfields|i was working up my complaint about that :)
 80 2017-10-03 18:15:11	0|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.
 81 2017-10-03 18:15:20	0|cfields|(maybe that's been suggested before, but I've missed it?)
 82 2017-10-03 18:16:16	0|sipa|cfields: i've suggested that, but i'm not sure it's needed
 83 2017-10-03 18:16:24	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #11445: [qa] 0.15.1 Backports (060.15...06Mf1710-0151qaBackports) 02https://github.com/bitcoin/bitcoin/pull/11445
 84 2017-10-03 18:17:11	0|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
 85 2017-10-03 18:18:57	0|Murch|thanks sipa
 86 2017-10-03 18:24:50	0|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
 87 2017-10-03 18:25:17	0|sipa|in which case FULL is equivalent to NETWORK_LIMITEF
 88 2017-10-03 18:26:07	0|cfields|sure, but FULL could also mean "NETWORK, but I'm not serving any."
 89 2017-10-03 18:26:10	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #11446: Bad block interrogation (06master...06bad-block-interrogation) 02https://github.com/bitcoin/bitcoin/pull/11446
 90 2017-10-03 18:26:44	0|sipa|cfields: if it means strictly only tip blocks, that's not something you want to connect to... what if there's a reorg
 91 2017-10-03 18:28:45	0|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.
 92 2017-10-03 18:29:25	0|cfields|so full nodes would advertise all 3, pruned would advertise 2.
 93 2017-10-03 18:30:01	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #11447: 0.15.1: Backport fixes (060.15...06Mf1710-0151Backports) 02https://github.com/bitcoin/bitcoin/pull/11447
 94 2017-10-03 18:30:44	0|sipa|cfields: right, but i'm not sure there is a use for something that can only serve blocks at the tip
 95 2017-10-03 18:31:09	0|sipa|cfields: so right now, we'd have LIMITED which means tip + 288 blocks below
 96 2017-10-03 18:31:50	0|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
 97 2017-10-03 18:32:13	0|sipa|that only used 2 bits, while you'd use 3 :)
 98 2017-10-03 18:33:53	0|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
 99 2017-10-03 18:34:17	0|cfields|(not the strongest argument, i realize :)
100 2017-10-03 18:34:44	0|sipa|my point is that there is no point having a separate bit for a feature that is not separately useful
101 2017-10-03 18:35:19	0|cfields|i guess this achieves what I'm after as-is... in a year or two, we simply require LIMITED and prefer NETWORK
102 2017-10-03 18:35:40	0|sipa|when we're in sync, we should treat the two as identical
103 2017-10-03 18:35:44	0|BlueMatt|sipa: we dont need to be worried about using 1 extra bit in nServices
104 2017-10-03 18:35:46	0|BlueMatt|we have so many
105 2017-10-03 18:36:19	0|BlueMatt|no reason to get complicated and save the ability to re-use NODE_NETWORK_LIMITED when NODE_NETWORK is set
106 2017-10-03 18:36:27	0|cfields|sipa: sure. It's just outbound selection i'm trying to reason through
107 2017-10-03 18:36:32	0|BlueMatt|and we have so few things we want to set in nServices
108 2017-10-03 18:36:34	0|sipa|BlueMatt: huh? we're not talking about that
109 2017-10-03 18:36:41	0|BlueMatt|oh, did I miss context
110 2017-10-03 18:36:43	0|sipa|i'm totally in favor of always setting LIMITED
111 2017-10-03 18:36:52	0|BlueMatt|ok, ignore me
112 2017-10-03 18:36:53	0|cfields|BlueMatt: yea, I suggested a 3rd bit for NODE_FULL
113 2017-10-03 18:37:01	0|BlueMatt|ah
114 2017-10-03 18:37:02	0|BlueMatt|no
115 2017-10-03 18:37:03	0|BlueMatt|why
116 2017-10-03 18:37:08	0|BlueMatt|thats what NODE_NETWORK means....
117 2017-10-03 18:37:17	0|cfields|heh, see above
118 2017-10-03 18:37:43	0|BlueMatt|how about we save it for when its useful? :P
119 2017-10-03 18:38:18	0|BlueMatt|when someone introduces a NODE_SERVES_COMPRESSED_BLOCKS bit, we should talk about splitting NODE_NETWORK, until then.......... :p
120 2017-10-03 19:28:28	0|bitcoin-git|13bitcoin/06master 14fafff12 15MarcoFalke: qa: Restore bitcoin-util-test py2 compatibility
121 2017-10-03 19:28:28	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/dbc4ae039630...b4a509a3f817
122 2017-10-03 19:28:29	0|bitcoin-git|13bitcoin/06master 14b4a509a 15MarcoFalke: Merge #11433: qa: Restore bitcoin-util-test py2 compatibility...
123 2017-10-03 19:29:07	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11433: qa: Restore bitcoin-util-test py2 compatibility (06master...06Mf1710-qaUtilPy2) 02https://github.com/bitcoin/bitcoin/pull/11433
124 2017-10-03 21:57:46	0|bitcoin-git|[13bitcoin] 15mess110 opened pull request #11448: [gui] reset addrProxy/addrSeparateProxyTor if colon char missing (06master...06ensure_colon_in_proxies_qsettings_storage) 02https://github.com/bitcoin/bitcoin/pull/11448