1 2017-10-02 00:58:39	0|meshcollider|BlueMatt harding: if it's not stepping on anyone's toes (if you just want it up there asap), I can chuck up a PR in a bit for them?
  2 2017-10-02 01:00:11	0|BlueMatt|meshcollider: if its not up yet I assume just go for it
  3 2017-10-02 01:35:38	0|meshcollider|ok its up, PR 440
  4 2017-10-02 08:53:51	0|fanquake|wumpus I have some changes for the Windows builds notes ready, but can't seem to cherry-pick the commit out of 11244. If they push a commit with author info I'll grab that, otherwise will credit them in my commit message. Hopefully we'll have some clarity around the Windows build docs shortly..
  5 2017-10-02 10:58:15	0|meshcollider|Is there any permission level other than admin which can delete pages
  6 2017-10-02 10:58:25	0|meshcollider|"Lead developer" and "Original Client developers" both redirect to a deleted page, so they should be deleted too
  7 2017-10-02 10:58:34	0|meshcollider|Oops wrong channel
  8 2017-10-02 10:59:20	0|meshcollider|Meant that for the wiki channel lol
  9 2017-10-02 11:30:00	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #11437: [Docs] Update Windows build instructions for using WSL and Ubuntu 17.04 (06master...06windows-build-1704) 02https://github.com/bitcoin/bitcoin/pull/11437
 10 2017-10-02 11:30:19	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11244: Docs: Add extra step to clean $PATH var to strip out windows %PATH% paths. (06master...06windows_build_fix) 02https://github.com/bitcoin/bitcoin/pull/11244
 11 2017-10-02 12:41:29	0|bitcoin-git|13bitcoin/06master 14bb8376b 15Matt Corallo: Verify DBWrapper iterators are taking snapshots...
 12 2017-10-02 12:41:29	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e542728cde67...c641ccac5bd8
 13 2017-10-02 12:41:30	0|bitcoin-git|13bitcoin/06master 14c641cca 15Wladimir J. van der Laan: Merge #11422: qa: Verify DBWrapper iterators are taking snapshots...
 14 2017-10-02 12:42:09	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11422: qa: Verify DBWrapper iterators are taking snapshots (06master...062017-09-leveldb-check-snapshots) 02https://github.com/bitcoin/bitcoin/pull/11422
 15 2017-10-02 12:47:18	0|bitcoin-git|13bitcoin/06master 14d601f16 15Anthony Towns: Fix invalid memory access in CScript::operator+=
 16 2017-10-02 12:47:18	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c641ccac5bd8...10bee0dd4f37
 17 2017-10-02 12:47:19	0|bitcoin-git|13bitcoin/06master 1410bee0d 15Wladimir J. van der Laan: Merge #11284: Fix invalid memory access in CScript::operator+= (guidovranken, ajtowns)...
 18 2017-10-02 12:47:53	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11284: Fix invalid memory access in CScript::operator+= (guidovranken, ajtowns) (06master...06cscript_insert) 02https://github.com/bitcoin/bitcoin/pull/11284
 19 2017-10-02 12:49:24	0|bitcoin-git|13bitcoin/06master 1449f869f 15Johnson Lau: Fix bip68-sequence rpc test
 20 2017-10-02 12:49:24	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/10bee0dd4f37...557aba6ce7da
 21 2017-10-02 12:49:25	0|bitcoin-git|13bitcoin/06master 14557aba6 15Wladimir J. van der Laan: Merge #11399: Fix bip68-sequence rpc test...
 22 2017-10-02 12:50:08	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11399: Fix bip68-sequence rpc test (06master...06bip68test-1) 02https://github.com/bitcoin/bitcoin/pull/11399
 23 2017-10-02 12:55:12	0|bitcoin-git|13bitcoin/06master 1492848e5 15João Barbosa: Remove unused fTry from push_lock
 24 2017-10-02 12:55:12	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/557aba6ce7da...058c0f996b72
 25 2017-10-02 12:55:13	0|bitcoin-git|13bitcoin/06master 14058c0f9 15Wladimir J. van der Laan: Merge #11432: Remove unused fTry from push_lock...
 26 2017-10-02 12:55:48	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11432: Remove unused fTry from push_lock (06master...062017-08-clean-push-lock) 02https://github.com/bitcoin/bitcoin/pull/11432
 27 2017-10-02 13:05:12	0|bitcoin-git|13bitcoin/06master 143a4401a 15practicalswift: [Qt] Terminate string *pszExePath after readlink and without using memset
 28 2017-10-02 13:05:12	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/058c0f996b72...c5c77bdcc632
 29 2017-10-02 13:05:13	0|bitcoin-git|13bitcoin/06master 14c5c77bd 15Wladimir J. van der Laan: Merge #11193: [Qt] Terminate string *pszExePath after readlink and without using memset...
 30 2017-10-02 13:05:41	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11193: [Qt] Terminate string *pszExePath after readlink and without using memset (06master...06null-terminate-after-readlink) 02https://github.com/bitcoin/bitcoin/pull/11193
 31 2017-10-02 13:11:08	0|bitcoin-git|13bitcoin/06master 145ddf560 15Jim Posen: script: Change SignatureHash input index check to an assert....
 32 2017-10-02 13:11:08	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c5c77bdcc632...339da9ca4143
 33 2017-10-02 13:11:09	0|bitcoin-git|13bitcoin/06master 14339da9c 15Wladimir J. van der Laan: Merge #11411: script: Change SignatureHash input index check to an assert....
 34 2017-10-02 13:11:39	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11411: script: Change SignatureHash input index check to an assert. (06master...06sighash-bounds-check) 02https://github.com/bitcoin/bitcoin/pull/11411
 35 2017-10-02 13:23:10	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/339da9ca4143...90926db2381d
 36 2017-10-02 13:23:11	0|bitcoin-git|13bitcoin/06master 1407704c1 15Akio Nakamura: Add some tests for getchaintxstats...
 37 2017-10-02 13:23:11	0|bitcoin-git|13bitcoin/06master 143336676 15Akio Nakamura: Fix getchaintxstats()...
 38 2017-10-02 13:23:12	0|bitcoin-git|13bitcoin/06master 1490926db 15Wladimir J. van der Laan: Merge #11021: [rpc] fix getchaintxstats()...
 39 2017-10-02 13:23:38	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11021: [rpc] fix getchaintxstats() (06master...06fix_getchaintxstats) 02https://github.com/bitcoin/bitcoin/pull/11021
 40 2017-10-02 13:25:53	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10457: Don't use fixed "wallet.bak"-filename during salvagewallet (06master...062017/05/rename_bdb) 02https://github.com/bitcoin/bitcoin/pull/10457
 41 2017-10-02 17:13:55	0|wxxs|should 0.15 disconnect clients with version string /Satoshi:1.14.4(2X)/ ?
 42 2017-10-02 17:15:26	0|andytoshi|there's no point in having an arms race, if btc1 is going to masquerade as core then they'll masquerade as core
 43 2017-10-02 17:15:50	0|andytoshi|leaving the situation as-is at least means it's possible to identify them so individuals and businesses can manually patch them out if they cause problems
 44 2017-10-02 17:18:08	0|wxxs|so this is btc1 with the signal bit removed?
 45 2017-10-02 17:29:20	0|BlueMatt|wxxs: yea, btc1 decided to deliberately cause more harm to the network than neccessary, because they felt like trolling, I guess
 46 2017-10-02 17:29:37	0|BlueMatt|so if it didnt get disconencted, it was either a pre-version-bit version of btc1, or masquerading
 47 2017-10-02 17:29:57	0|BlueMatt|(or core with the version message changed to that)
 48 2017-10-02 17:30:27	0|wxxs|ew, I feel violated
 49 2017-10-02 17:30:36	0|BlueMatt|trolls gonna troll
 50 2017-10-02 17:32:56	0|sipa|i don't think there is any particular problem with them not having the service bit for a while
 51 2017-10-02 17:34:24	0|sipa|(up until a bit before the fork, when they'll want preferential peering)
 52 2017-10-02 17:35:32	0|BlueMatt|sipa: I dont believe they've implemented any "week before, force service bit on" logic
 53 2017-10-02 17:35:58	0|BlueMatt|so that they can maximize network disruption and possible isolate some nodes
 54 2017-10-02 17:38:07	0|Murch|Luckily, if the node count stays like this, it'll be likely only disrupt their nodes.
 55 2017-10-02 17:42:28	0|BlueMatt|true, but it still seems needlessly stupid...the only reason to have that option is to troll, but, then, that seems to be what 2x is all about
 56 2017-10-02 17:43:30	0|Murch|of course it's stupid, but if they're being stupid and only hurting themselves, that's less of an issue than if they were being stupid and hurting others
 57 2017-10-02 17:44:00	0|wxxs|wouldn't they rather isolate their own nodes this way? Do the 2X CEOs know what their engineer is doing?
 58 2017-10-02 17:44:24	0|BlueMatt|well they're risking it - if some charitable person decides 2x doesnt have enough nodes so spins up some crazy sybil like we've seen with all the previous forks, they could cause issues for both themselves and others
 59 2017-10-02 17:48:16	0|gmaxwell|We need bad block interogation.
 60 2017-10-02 17:49:01	0|gmaxwell|Whenever we reject a bad block, we should remember it, and try fetching it from every other peer we connect to... and then ban any that serve it to us.
 61 2017-10-02 17:49:26	0|gmaxwell|Still won't prevent isolation from s2x nodes entirely but it would make it less bad.
 62 2017-10-02 17:49:49	0|BlueMatt|grrr, why didnt they fucking use the hardfork bit
 63 2017-10-02 17:51:17	0|gmaxwell|because that would minimize disruption.
 64 2017-10-02 17:51:35	0|BlueMatt|trolls gonna troll.....
 65 2017-10-02 17:53:44	0|wxxs|provocation?
 66 2017-10-02 17:54:53	0|gmaxwell|the whole strategy of s2x is to try to force people to accept their rule change by disrupting everything else.
 67 2017-10-02 17:59:52	0|sturles|I suggest to just write a script which periodically scan getpeerinfo for 2x, then limit their bandwidth to a minimum where they will still stay connected.  I used to do that with BU, XT, etc.
 68 2017-10-02 18:00:32	0|sturles|They don't seem to thinkt that bandwidth can be a problem to anyone, so it shouldn't bother them.
 69 2017-10-02 19:11:42	0|achow101|gmaxwell: I've been thinking about bad block interrogation. How would you be able to distinguish between they don't have the block, they didn't accept the block, and they're just taking a really long time to respond with the block?
 70 2017-10-02 19:15:26	0|andytoshi|probably sufficient to send them a request for it, set a flag somewhere, and then if they ever reply with the block, ban them
 71 2017-10-02 19:16:31	0|sipa|it could also be done based on headers
 72 2017-10-02 19:16:57	0|sipa|as long as difficulty rule isn't modified, we'll learn about all chains our peers have through the headers
 73 2017-10-02 19:19:01	0|gmaxwell|achow101: I don't think we need to.
 74 2017-10-02 19:19:19	0|gmaxwell|achow101: we ask for it.  ... and seperately anyone who ever sends it to use gets punted.
 75 2017-10-02 19:19:25	0|gmaxwell|we don't even have to track if we asked
 76 2017-10-02 19:19:57	0|gmaxwell|though sipa notes doing it through the header is even stronger and simpler.
 77 2017-10-02 19:20:25	0|achow101|gmaxwell: well right now we only ban the first person who relays us an invalid block. So I suppose we can just change that to ban anyone who relays us an invalid block regardless of whether we have already seen it
 78 2017-10-02 19:20:47	0|achow101|I was already thinking about just using headers. It can all be done in ProcessNewBlockHeaders I think
 79 2017-10-02 19:21:04	0|gmaxwell|achow101: yes, kind of, but if its burried when they connect they won't send it to us.
 80 2017-10-02 19:22:12	0|achow101|gmaxwell: if it's buried, couldn't we imitate IBD?
 81 2017-10-02 19:22:43	0|gmaxwell|I don't understand your question.
 82 2017-10-02 19:23:17	0|bitcoin-git|13bitcoin/06master 14634e38c 15Anditto Heristyo: [Tests] Add Qt GUI tests to Overview and ReceiveCoin Page
 83 2017-10-02 19:23:17	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/90926db2381d...f199b8a33d94
 84 2017-10-02 19:23:18	0|bitcoin-git|13bitcoin/06master 14f199b8a 15MarcoFalke: Merge #11365: [Tests] Add Qt GUI tests to Overview and ReceiveCoin Page...
 85 2017-10-02 19:23:18	0|gmaxwell|I don't think we need to in any case, ejecting any peers that has a header chain with a block we consider invalid is sufficient, and simpler than anything with fetching blocks.
 86 2017-10-02 19:23:47	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11365: [Tests] Add Qt GUI tests to Overview and ReceiveCoin Page (06master...06Adding-Qt-tests) 02https://github.com/bitcoin/bitcoin/pull/11365
 87 2017-10-02 19:24:25	0|achow101|so we can just ask a peer for the headers starting from block X where block X is invalid to us. If they respond with headers, then ban
 88 2017-10-02 19:26:10	0|achow101|by imitating IBD I meant doing the whole fetch 2000 headers thing starting from some block X and seeing if they responded to us with those headers
 89 2017-10-02 19:28:23	0|gmaxwell|well there are two degress of badness to think about, one is if their best chain contains a block we consider invalid and the other is if they accept a block we consider invalid at all even if its not in their best chain right now.
 90 2017-10-02 19:29:34	0|achow101|If a block is not in their best chain, we can't fetch it, no?
 91 2017-10-02 19:29:53	0|gmaxwell|we can, if it's not too far outside of it.
 92 2017-10-02 19:30:27	0|achow101|but if it is too far outside of the best chain, we can't determine whether they accepted it or not
 93 2017-10-02 19:30:34	0|gmaxwell|it avoids a case where it was on their best chain, they offered it to us, we attempted to fetch it... but were too slow.
 94 2017-10-02 19:30:44	0|gmaxwell|yes, if it's too far outside we can't, indeed.
 95 2017-10-02 19:30:52	0|achow101|unless we give them the block, but that risks getting us banned
 96 2017-10-02 19:31:55	0|bitcoin-git|13bitcoin/06master 141088b53 15Gregory Sanders: add functional test for mempoolreplacement command line arg
 97 2017-10-02 19:31:55	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f199b8a33d94...8ddf60db7ad6
 98 2017-10-02 19:31:56	0|bitcoin-git|13bitcoin/06master 148ddf60d 15MarcoFalke: Merge #11407: [tests] add functional test for mempoolreplacement command line arg...
 99 2017-10-02 19:31:59	0|gmaxwell|But I don't think the too far limit is that limiting.
100 2017-10-02 19:32:24	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11407: [tests] add functional test for mempoolreplacement command line arg (06master...06testmempoolreplacearg) 02https://github.com/bitcoin/bitcoin/pull/11407
101 2017-10-02 19:33:19	0|achow101|the too far limit is one month.
102 2017-10-02 19:37:28	0|achow101|I guess we can't cover the case where we are connected to an isolated peer that is following different consensus rules
103 2017-10-02 19:51:45	0|r251d|If a set of nodes wanted to protect against a 51% attack, they might collectively decide to invalidateblock on an attacking block. The coordination may be difficult, deciding whether a block constitutes an attack, but it may be helpful for the defending nodes to be able to reconsiderblock in some cases. In that scenario, the temporarily invalidated block may not be a bannable offense for nodes who
104 2017-10-02 19:51:45	0|r251d|relayed it.
105 2017-10-02 20:07:05	0|gmaxwell|r251d: if it isn't your defence won't work well, because you'll invalidate that block but be surrounded by nothing but peers that have it, and so not even hear about the other chain.
106 2017-10-02 20:07:28	0|gmaxwell|so you're actually giving an argument for the importance of kicking off peers that have a block you consider invalid in their best chain.
107 2017-10-02 20:08:31	0|Oda_nobunaga|Yesterday Adam talked about "bunker mode" on slack: that is, if I understood well, a way to build the chain by selecting blocks sort of manually, and invalidating blocks from a suspected 51% attack?
108 2017-10-02 20:09:48	0|r251d|I was hoping that a hypothetical "bunker mode" could keep connections with nodes that have alternative tips until social coordination decided on the best one to follow.
109 2017-10-02 20:10:35	0|Oda_nobunaga|I was also wondering about the reaction to a 51% attack. How long would a PoW change take? Would we be talking hours or weeks?
110 2017-10-02 20:10:49	0|Oda_nobunaga|I'm afraid that Jihan might use the threat of a reorg attack (very implicitly worded of course) as a way to sap confidence in the original chain, and scare people away from investing in it - thus deflating its price and possibly chasing more hash power away. The mere threat of an attack could work almost as well as an actual one.
111 2017-10-02 20:12:03	0|sipa|please keep this channel about software development
112 2017-10-02 20:13:15	0|Oda_nobunaga|Sorry, I was eager to get devs opinions about this. Perhaps this would be more suited for #bitcoin
113 2017-10-02 20:13:42	0|mryandao|i was wondering if it would be possible to remove the libboost dependency for bitcoin-cli so it is possible to compile separately on a lightweight node with minimal libs.
114 2017-10-02 20:17:13	0|achow101|mryandao: what does bitcoin-cli use boost for?
115 2017-10-02 20:17:32	0|mryandao|that's exactly my question a week ago
116 2017-10-02 20:17:58	0|mryandao|if you run `ldd` on it, you will see that bitcoin-cli requires libboost
117 2017-10-02 20:18:38	0|achow101|oh, its for thread management
118 2017-10-02 20:21:08	0|achow101|and some of the things it includes requires boost
119 2017-10-02 20:22:40	0|mryandao|ok, i see.
120 2017-10-02 20:47:11	0|bitcoin-git|[13bitcoin] 15sipsorcery opened pull request #11438: Updated Windows build doc for WSL/Xenial workaround (06master...06wslbuilddoc) 02https://github.com/bitcoin/bitcoin/pull/11438
121 2017-10-02 21:30:14	0|bitcoin-git|[13bitcoin] 15promag opened pull request #11439: [test] Refactor ZMQ test to use one address per notification type (06master...062017-10-clean-zmq-test) 02https://github.com/bitcoin/bitcoin/pull/11439
122 2017-10-02 21:33:06	0|promag|BlueMatt: ^
123 2017-10-02 21:34:11	0|BlueMatt|promag: heh, I removed that commit
124 2017-10-02 21:36:03	0|BlueMatt|promag: https://github.com/bitcoin/bitcoin/pull/11439#issuecomment-333672328
125 2017-10-02 21:41:25	0|promag|BlueMatt: replied
126 2017-10-02 21:43:53	0|BlueMatt|promag: does zmq not give you reliable order?
127 2017-10-02 21:45:17	0|promag|AFAIK no, messages can be dropped
128 2017-10-02 21:45:26	0|promag|but that's not the issue
129 2017-10-02 21:46:07	0|promag|the issue is that if we change the publishing order then we break the test (and other clients
130 2017-10-02 21:46:35	0|BlueMatt|yes, thats my point, in common usage it seems to me that a client can vaguely rely on ordering
131 2017-10-02 21:46:38	0|promag|that's why you needed to fix in the old commit
132 2017-10-02 21:46:41	0|BlueMatt|who's to say clients dont rely on ordering today
133 2017-10-02 21:46:52	0|BlueMatt|there are no docs, there is no API, so clients could be doing who-knows-what
134 2017-10-02 21:47:08	0|promag|right
135 2017-10-02 21:47:12	0|BlueMatt|a client would be entirely justified in assuming the ordering was part of the API
136 2017-10-02 21:47:32	0|BlueMatt|so if we want to change that, we need to a) write some docs to begin with, b) document the change, with sufficient notice
137 2017-10-02 21:47:42	0|BlueMatt|and until then, imo, the test should test order
138 2017-10-02 21:48:01	0|BlueMatt|I realized this later based on sdaftuar complaining the lack of API, hence the commit removal
139 2017-10-02 21:48:03	0|promag|So atm the PR is to prevent the test to fail and to be a better example on how to subscribe notifications
140 2017-10-02 21:48:11	0|promag|> a client would be entirely justified in assuming the ordering was part of the API -- why?
141 2017-10-02 21:48:48	0|BlueMatt|why not?
142 2017-10-02 21:48:51	0|BlueMatt|it works, doesnt it?
143 2017-10-02 21:49:05	0|BlueMatt|well my point is the test *should* fail if the interface changes
144 2017-10-02 21:49:35	0|BlueMatt|a client, in the absense of any documentation whatsoever, would be justified in assuming the ordering was part of the api, imo
145 2017-10-02 21:53:39	0|promag|BlueMatt: it works, doesnt it? -- so? it's not documented as such it shouldn't be used as if it was
146 2017-10-02 21:54:15	0|promag|if the interface changes - you didn't change the interface
147 2017-10-02 21:54:58	0|BlueMatt|well then I'd prefer to rip out the whole thing...it wasnt documented so you shouldnt rely on it being there :p
148 2017-10-02 21:54:59	0|promag|you changed some internals that changed the publishing order, but nothing is said about the order, only about the message contents
149 2017-10-02 21:55:17	0|BlueMatt|nothing is said about the message contents, either
150 2017-10-02 21:55:24	0|BlueMatt|nothing is said about any part of the interface
151 2017-10-02 21:55:28	0|BlueMatt|its wholly undocumented
152 2017-10-02 21:55:51	0|promag|doc/zmq.md ?
153 2017-10-02 21:56:51	0|BlueMatt|sorry, it does say that you'll get messages, but it doesnt say why
154 2017-10-02 21:56:56	0|BlueMatt|is hashblock just for new tips?
155 2017-10-02 21:56:59	0|BlueMatt|or all blocks
156 2017-10-02 21:57:16	0|BlueMatt|should you get a hashblock for something that was disconnected? what about something removed from your mempool?
157 2017-10-02 21:57:26	0|promag|tip
158 2017-10-02 21:57:53	0|BlueMatt|err, sorry, guess it does mention tip, doenst mention mempool, though, and in this case were talking about mempool
159 2017-10-02 21:58:00	0|BlueMatt|those docs are useless
160 2017-10-02 21:58:43	0|BlueMatt|it has 4 types of things, and afaict only mentions what happens in one of them
161 2017-10-02 21:59:03	0|promag|so you suggest to improve the docs?
162 2017-10-02 21:59:21	0|BlueMatt|see, eg, #9371
163 2017-10-02 21:59:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/9371 | Notify on removal by morcos · Pull Request #9371 · bitcoin/bitcoin · GitHub
164 2017-10-02 22:00:03	0|BlueMatt|I'd love to see someone actually document what in the hell the zmq stuff actually does, yes
165 2017-10-02 22:00:31	0|BlueMatt|once we have such a doc, I think it'd be reasonable to deprecate certain behaviors being normative, eg the ordering restrictions
166 2017-10-02 22:00:32	0|promag|later jonasschnelli added sequence which I believe is not documented (sorry if it is)
167 2017-10-02 22:00:51	0|BlueMatt|its mentioned, but only in passing, no what the fuck format it has
168 2017-10-02 22:02:09	0|promag|agree BlueMatt, I'll improve the doc
169 2017-10-02 22:02:37	0|BlueMatt|I dont think we should remove ordering for a release or two, however
170 2017-10-02 22:04:37	0|promag|I can split the PR in 2 - cleanup + remove-ordering
171 2017-10-02 22:04:49	0|promag|create a 3rd improve-doc
172 2017-10-02 22:05:13	0|BlueMatt|I dont think we should remove ordering until 0.17, assuming we have docs noting it is non-normative in 0.16
173 2017-10-02 22:05:21	0|BlueMatt|(also cause there is no rush)
174 2017-10-02 22:05:57	0|BlueMatt|we have no reason to need to remove ordering, and probably will keep the same ordering requirements in validationinterface
175 2017-10-02 22:08:16	0|promag|From the client perspective, it should not rely on the order not because of bitcoind but because of zmq
176 2017-10-02 22:09:02	0|BlueMatt|are you sure zmq doesnt provide consistent ordering?
177 2017-10-02 22:09:07	0|esotericnonsense|zmq is only guaranteed to preserve order over TCP
178 2017-10-02 22:09:13	0|BlueMatt|you may lose messages but I'd assume in practice its ordered
179 2017-10-02 22:09:27	0|BlueMatt|heh, ok, so in common-usage its guaranteed to preserve order :p
180 2017-10-02 22:09:46	0|esotericnonsense|and only in the simple case with no proxies that may cause different paths to be taken by different messages
181 2017-10-02 22:10:00	0|BlueMatt|<BlueMatt> heh, ok, so in common-usage its guaranteed to preserve order :p
182 2017-10-02 22:10:03	0|esotericnonsense|hehe
183 2017-10-02 22:10:58	0|promag|> probably will keep the same ordering requirements in validationinterface - where is this tested (beside in zmq)?
184 2017-10-02 22:11:27	0|BlueMatt|stuff that calls into wallet is required, mostly
185 2017-10-02 22:11:39	0|BlueMatt|depends on which calls zmq uses, I dont recall
186 2017-10-02 22:20:08	0|BlueMatt|do we have a standard for adding options to rpc calls now? we have named args, but also lots of stuff in options{} objects....do we prefer one for new things?
187 2017-10-02 22:27:17	0|sipa|i prefer using named arguments over options - easier or equally easy to use
188 2017-10-02 22:27:37	0|sipa|unless it's options that apply to only some arguments (like per-output options in createrawtransactions eg)
189 2017-10-02 22:28:20	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #11440: Fix validationinterface build on super old boost/clang (06master...062017-10-cblock-validationinterface) 02https://github.com/bitcoin/bitcoin/pull/11440
190 2017-10-02 22:28:24	0|gmaxwell|results in a terrible commandline expirence either way.