1 2016-04-11T00:13:20  *** challisto has joined #bitcoin-core-dev
  2 2016-04-11T00:46:55  *** btcdrak has quit IRC
  3 2016-04-11T00:49:35  *** PRab has quit IRC
  4 2016-04-11T01:08:44  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  5 2016-04-11T01:16:55  *** belcher has quit IRC
  6 2016-04-11T01:22:08  <BlueMatt> anyone around who might have a node which restarts occasionally, could you grep for "prev block not found" in debug.log and report the frequency?
  7 2016-04-11T01:24:13  <achow101> BlueMatt: I've got it twive
  8 2016-04-11T01:24:18  <achow101> *twice
  9 2016-04-11T01:24:26  <BlueMatt> across how many days/restarts?
 10 2016-04-11T01:26:17  <GitHub121> [bitcoin] gmaxwell opened pull request #7856: Only send one GetAddr response per connection. (master...addr_once) https://github.com/bitcoin/bitcoin/pull/7856
 11 2016-04-11T01:26:40  <achow101> since march 10th and 51 restarts
 12 2016-04-11T01:27:13  <BlueMatt> achow101: thanks
 13 2016-04-11T01:28:11  *** fengling has joined #bitcoin-core-dev
 14 2016-04-11T01:32:29  *** PRab has joined #bitcoin-core-dev
 15 2016-04-11T01:52:27  *** johnwhitton has joined #bitcoin-core-dev
 16 2016-04-11T02:00:18  *** dermoth has quit IRC
 17 2016-04-11T02:00:59  *** dermoth has joined #bitcoin-core-dev
 18 2016-04-11T02:09:15  *** xiangfu has joined #bitcoin-core-dev
 19 2016-04-11T02:10:20  *** johnwhitton has quit IRC
 20 2016-04-11T02:24:53  *** johnwhitton has joined #bitcoin-core-dev
 21 2016-04-11T02:41:04  *** Ylbam has quit IRC
 22 2016-04-11T03:05:38  *** PaulCape_ has quit IRC
 23 2016-04-11T03:07:47  *** PaulCapestany has joined #bitcoin-core-dev
 24 2016-04-11T03:11:00  *** btcdrak has joined #bitcoin-core-dev
 25 2016-04-11T03:18:00  *** Chris_Stewart_5 has quit IRC
 26 2016-04-11T04:21:03  *** xiangfu has quit IRC
 27 2016-04-11T04:21:29  *** xiangfu has joined #bitcoin-core-dev
 28 2016-04-11T04:28:56  *** ThomasV has joined #bitcoin-core-dev
 29 2016-04-11T04:45:40  *** Giszmo has quit IRC
 30 2016-04-11T05:36:16  *** fengling has quit IRC
 31 2016-04-11T05:40:01  *** Alopex has quit IRC
 32 2016-04-11T05:41:06  *** Alopex has joined #bitcoin-core-dev
 33 2016-04-11T06:00:10  *** dermoth has quit IRC
 34 2016-04-11T06:00:47  *** dermoth has joined #bitcoin-core-dev
 35 2016-04-11T06:02:51  *** jarret has quit IRC
 36 2016-04-11T06:09:00  *** ThomasV has quit IRC
 37 2016-04-11T06:19:33  *** xiangfu has quit IRC
 38 2016-04-11T06:26:55  *** btcdrak has quit IRC
 39 2016-04-11T06:29:26  *** d_t has quit IRC
 40 2016-04-11T06:39:48  *** xiangfu has joined #bitcoin-core-dev
 41 2016-04-11T06:41:51  *** fengling has joined #bitcoin-core-dev
 42 2016-04-11T06:53:29  *** Ylbam has joined #bitcoin-core-dev
 43 2016-04-11T06:55:13  *** laurentmt has joined #bitcoin-core-dev
 44 2016-04-11T06:56:49  *** cjcj_ has joined #bitcoin-core-dev
 45 2016-04-11T06:57:58  *** laurentmt has quit IRC
 46 2016-04-11T06:58:40  *** laurentmt has joined #bitcoin-core-dev
 47 2016-04-11T07:03:01  *** Alopex has quit IRC
 48 2016-04-11T07:03:23  *** laurentmt has quit IRC
 49 2016-04-11T07:03:40  <jonasschnelli> Holly! The Github traffic on weekends is extremely intense. Catch up after a weekend (people where supposed to not work on weekend,.. once) needs 1-2h! :)
 50 2016-04-11T07:04:06  *** Alopex has joined #bitcoin-core-dev
 51 2016-04-11T07:04:22  <sipa> weekends are highly overratee
 52 2016-04-11T07:04:26  <sipa> weekends are highly overrated
 53 2016-04-11T07:07:16  *** fengling has quit IRC
 54 2016-04-11T07:08:24  <jonasschnelli> Yah! Tell that my wife. :)
 55 2016-04-11T07:13:50  *** fengling has joined #bitcoin-core-dev
 56 2016-04-11T07:14:07  *** xiangfu has quit IRC
 57 2016-04-11T07:26:08  <GitHub84> [bitcoin] promag opened pull request #7857: Add fee to fundrawtransaction (master...enhancement/add-fee-to-fundrawtransaction) https://github.com/bitcoin/bitcoin/pull/7857
 58 2016-04-11T07:28:55  *** laurentmt has joined #bitcoin-core-dev
 59 2016-04-11T07:29:09  *** ThomasV has joined #bitcoin-core-dev
 60 2016-04-11T07:31:21  *** xiangfu has joined #bitcoin-core-dev
 61 2016-04-11T07:35:21  *** johnwhitton has quit IRC
 62 2016-04-11T07:48:37  *** paveljanik has quit IRC
 63 2016-04-11T07:48:45  *** abritoid has joined #bitcoin-core-dev
 64 2016-04-11T07:50:44  *** cryptapus_afk has quit IRC
 65 2016-04-11T07:50:44  *** cryptapus has joined #bitcoin-core-dev
 66 2016-04-11T07:50:44  *** cryptapus has joined #bitcoin-core-dev
 67 2016-04-11T07:50:45  *** cryptapus is now known as cryptapus_afk
 68 2016-04-11T07:56:18  *** btcdrak has joined #bitcoin-core-dev
 69 2016-04-11T08:01:09  <BlueMatt> hmm, the sendheaders stuff is pretty bitcoin-core-specific
 70 2016-04-11T08:01:38  <BlueMatt> we DoS a node for sending us a header that doesnt connect to our chain, because bitcoin core keeps track of what it thinks its peers have for headers (and assumes they never throw away headers)
 71 2016-04-11T08:01:42  <BlueMatt> sipa: ^
 72 2016-04-11T08:02:38  *** xiangfu has quit IRC
 73 2016-04-11T08:02:38  <BlueMatt> if, for example, a peer didnt want to keep track of what it thought we had in our block-headers-tree, it couldnt implement sendheaders
 74 2016-04-11T08:05:36  <sipa> you can always send all headers along the new branch you're switching to
 75 2016-04-11T08:06:06  <BlueMatt> also, we assume a node doesnt have a given set of headers based on only the most recently received or sent hash/header...this works fine for non-forked chains, but if the chain forks at the tip, we may very well fall back to sending invs
 76 2016-04-11T08:06:40  <BlueMatt> sipa: but we dont do this
 77 2016-04-11T08:06:54  <BlueMatt> sipa: also, why not just remove the DoS?
 78 2016-04-11T08:07:09  <BlueMatt> sipa: and if it doesnt connect, just send a getheaders for further-back headers
 79 2016-04-11T08:07:18  <sipa> which case are you talking about, a non-core peer sending headers to core, or the other way around?
 80 2016-04-11T08:07:32  <BlueMatt> in this case I'm talking about core-to-core
 81 2016-04-11T08:07:52  <BlueMatt> from my (not so in depth) reading, this looks like it can very easily fall back to invs if the chain is forked near the tip
 82 2016-04-11T08:08:11  <sipa> it should send all new headers along the new branch
 83 2016-04-11T08:08:26  <sipa> unless there are too many, in which case it intentionally falls back to using invs
 84 2016-04-11T08:08:27  <BlueMatt> eg we just got a new block on our chaintip B (based on A), but we only know they have C (which we may not even have, but lets say its based on A)
 85 2016-04-11T08:08:46  *** challisto has quit IRC
 86 2016-04-11T08:08:47  *** abritoid_ has joined #bitcoin-core-dev
 87 2016-04-11T08:08:54  <sipa> then we send the header for B
 88 2016-04-11T08:09:01  <BlueMatt> I dont think it will? It will only ever send invs/headers that were added to vBlockHashesTonnounce
 89 2016-04-11T08:09:19  <BlueMatt> no, because B wont be in vBlockHashesToAnnounce
 90 2016-04-11T08:09:34  <BlueMatt> only D (based on B) will be
 91 2016-04-11T08:10:29  *** abritoid has quit IRC
 92 2016-04-11T08:10:47  <BlueMatt> in any case, it is much more flexible to handle the headers-msg-that-didnt-connect case by requesting a headers with our locator and see what they come back with instead of marking that peer a DoS
 93 2016-04-11T08:10:52  *** xiangfu has joined #bitcoin-core-dev
 94 2016-04-11T08:11:06  <BlueMatt> would make it much easier for other implementors (they can skip all block inv sending, though that would be a bit less effecient)
 95 2016-04-11T08:12:10  <BlueMatt> sipa: eg https://github.com/TheBlueMatt/bitcoin/commits/1daf94f540592345dca5818321a28996fe7e04fd
 96 2016-04-11T08:12:11  <BlueMatt> ?
 97 2016-04-11T08:14:33  <sipa> hmm, i'd still like to understand the use case
 98 2016-04-11T08:15:59  *** MarcoFalke has joined #bitcoin-core-dev
 99 2016-04-11T08:15:59  <BlueMatt> sipa: the use-case is simpler code for other implementors (or maybe us in the future)
100 2016-04-11T08:16:06  <sipa> we have D-B-A as tip, a peer has C-A as tip
101 2016-04-11T08:16:08  <BlueMatt> sipa: they could even skip the inv logic
102 2016-04-11T08:16:13  <BlueMatt> sipa: that is a separate bug
103 2016-04-11T08:16:22  <sipa> let's talk one thing at a timr
104 2016-04-11T08:17:18  <sipa> but the peer will have the headers for D and B already
105 2016-04-11T08:17:25  <sipa> eh, B
106 2016-04-11T08:17:31  <sipa> so just sending D should be fine?
107 2016-04-11T08:18:02  <BlueMatt> this only works if either the last header we sent them or the last header they sent us is B
108 2016-04-11T08:18:37  <sipa> it's possible that B was sent just as an inv
109 2016-04-11T08:18:52  <sipa> and the peer hasn't getdata'd yet
110 2016-04-11T08:18:58  <BlueMatt> no, its worse
111 2016-04-11T08:19:07  <BlueMatt> they could have had B already from another peer
112 2016-04-11T08:19:19  <BlueMatt> well, yea, i suppose it would be an inv, then
113 2016-04-11T08:19:22  <BlueMatt> but they wouldnt request it
114 2016-04-11T08:19:34  <sipa> we would still have either sent an inv or a header, indeed
115 2016-04-11T08:20:11  <BlueMatt> anyway, minor bug, just means if chain is forked when you first connect to a peer, you will probably send block as inv instead of header
116 2016-04-11T08:21:12  <BlueMatt> butttt, this does feed into my more general protocol suggestion/question here, which is that we seem to have half-assed the sendheaders stuff....I can get that if you're sending a lot you might prefer invs over headers, but if you're only sending a few, this semi-duplicated logic doesnt make sense to me
117 2016-04-11T08:21:26  <BlueMatt> why not just always use headers and if you got headers that you cant connect, treat them as invs and request more headers
118 2016-04-11T08:22:08  *** jannes has joined #bitcoin-core-dev
119 2016-04-11T08:22:58  <BlueMatt> anyway, bedtime for me
120 2016-04-11T08:44:35  *** MarcoFalke has quit IRC
121 2016-04-11T08:55:16  *** fengling has quit IRC
122 2016-04-11T08:57:29  *** cjcj_ has quit IRC
123 2016-04-11T09:00:31  *** fengling has joined #bitcoin-core-dev
124 2016-04-11T09:00:32  *** abritoid_ has quit IRC
125 2016-04-11T09:06:30  *** gevs has joined #bitcoin-core-dev
126 2016-04-11T09:13:16  *** murch has joined #bitcoin-core-dev
127 2016-04-11T09:21:02  *** laurentmt has quit IRC
128 2016-04-11T09:26:20  *** ThomasV has quit IRC
129 2016-04-11T09:29:44  *** ThomasV has joined #bitcoin-core-dev
130 2016-04-11T09:30:19  *** AaronvanW has joined #bitcoin-core-dev
131 2016-04-11T09:30:38  *** cjcj_ has joined #bitcoin-core-dev
132 2016-04-11T09:32:08  <GitHub33> [bitcoin] jl2012 opened pull request #7858: Add jl2012 public key for gitian build (master...patch-9) https://github.com/bitcoin/bitcoin/pull/7858
133 2016-04-11T09:43:16  *** fengling has quit IRC
134 2016-04-11T09:45:06  *** abritoid has joined #bitcoin-core-dev
135 2016-04-11T09:47:22  *** xiangfu has quit IRC
136 2016-04-11T09:56:56  *** Evel-Knievel has quit IRC
137 2016-04-11T10:25:02  *** ThomasV has quit IRC
138 2016-04-11T10:29:52  *** xiangfu has joined #bitcoin-core-dev
139 2016-04-11T10:46:41  *** Evel-Knievel has joined #bitcoin-core-dev
140 2016-04-11T10:46:42  <wumpus> oh, that's too bad, I saw a "Merge button" setting under repository settings, I thought because we use a custom script we could disable it entirely. Unfortunately "You must select at least one option"
141 2016-04-11T10:46:50  <wumpus> going to request this
142 2016-04-11T10:49:29  *** xiangfu has quit IRC
143 2016-04-11T10:49:31  <sipa> wumpus: that will be interesting :)
144 2016-04-11T10:51:40  <wumpus> jonasschnelli: hah! and remember that if you take all time zones into account, I think there's only one full day it's 'weekend' everywhere
145 2016-04-11T10:52:03  <wumpus> yes it'd be nice
146 2016-04-11T10:57:52  <GitHub183> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/065c6b443f3e...934f2b5e7693
147 2016-04-11T10:57:52  <GitHub183> bitcoin/master 64c22be Johnson Lau: Add jl2012 public key for gitian build
148 2016-04-11T10:57:53  <GitHub183> bitcoin/master 934f2b5 Wladimir J. van der Laan: Merge #7858: Add jl2012 public key for gitian build...
149 2016-04-11T10:58:02  <GitHub114> [bitcoin] laanwj closed pull request #7858: Add jl2012 public key for gitian build (master...patch-9) https://github.com/bitcoin/bitcoin/pull/7858
150 2016-04-11T11:02:13  <GitHub100> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/465d30915cd3...9779e1e1f320
151 2016-04-11T11:02:13  <GitHub100> bitcoin/0.12 de7c34c BtcDrak: Add missing link to BIP113
152 2016-04-11T11:02:13  <GitHub192> [bitcoin] laanwj closed pull request #7852: [0.12] Add missing reference to release notes (0.12...bip113) https://github.com/bitcoin/bitcoin/pull/7852
153 2016-04-11T11:02:14  <GitHub100> bitcoin/0.12 9779e1e Wladimir J. van der Laan: Merge #7852: [0.12] Add missing reference to release notes...
154 2016-04-11T11:06:02  *** xiangfu has joined #bitcoin-core-dev
155 2016-04-11T11:22:34  *** ThomasV has joined #bitcoin-core-dev
156 2016-04-11T11:24:11  *** xiangfu has quit IRC
157 2016-04-11T11:24:23  *** laurentmt has joined #bitcoin-core-dev
158 2016-04-11T11:24:28  *** laurentmt has quit IRC
159 2016-04-11T11:41:43  *** fengling has joined #bitcoin-core-dev
160 2016-04-11T11:46:36  *** fengling has quit IRC
161 2016-04-11T11:49:22  *** jarret has joined #bitcoin-core-dev
162 2016-04-11T11:59:20  <instagibbs> wumpus, you pointed to rc1 in the source on mailing list, FYI :P
163 2016-04-11T11:59:35  <wumpus> yes I sent a mail after it correcting it right?
164 2016-04-11T11:59:52  <instagibbs> maybe my email is slow
165 2016-04-11T12:00:03  <wumpus> https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-April/000002.html
166 2016-04-11T12:00:17  <instagibbs> oh i see it, maybe I checked email while asleep :)
167 2016-04-11T12:06:44  <wumpus> :)
168 2016-04-11T12:10:17  <sipa> oh, you're a sleepmailer too?
169 2016-04-11T12:21:06  *** paveljanik has joined #bitcoin-core-dev
170 2016-04-11T12:42:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
171 2016-04-11T12:46:55  <instagibbs> with new baby you never quite know when you checked things fully awake
172 2016-04-11T13:02:24  *** ThomasV has quit IRC
173 2016-04-11T13:26:03  *** baldur has quit IRC
174 2016-04-11T13:27:24  *** gevs_ has joined #bitcoin-core-dev
175 2016-04-11T13:29:47  *** gevs has quit IRC
176 2016-04-11T13:45:41  *** fengling has joined #bitcoin-core-dev
177 2016-04-11T13:50:16  *** fengling has quit IRC
178 2016-04-11T13:50:34  *** d_t has joined #bitcoin-core-dev
179 2016-04-11T13:53:44  <GitHub23> [bitcoin] jonasschnelli closed pull request #7831: [CLI] refactor wallets RPC JSON conversions (master...2016/04/cli_conversion) https://github.com/bitcoin/bitcoin/pull/7831
180 2016-04-11T13:55:10  *** d_t has quit IRC
181 2016-04-11T14:03:12  *** Guyver2 has joined #bitcoin-core-dev
182 2016-04-11T14:32:32  *** Giszmo has joined #bitcoin-core-dev
183 2016-04-11T14:36:04  *** fkhan_ has quit IRC
184 2016-04-11T14:46:56  <jonasschnelli> hmm... these guys: https://twitter.com/kawalgrover/status/719535585153716224
185 2016-04-11T14:49:26  *** fkhan_ has joined #bitcoin-core-dev
186 2016-04-11T14:57:41  <Chris_Stewart_5> Is CScriptNum(0) bitwise equivalent to OP_0?
187 2016-04-11T14:58:01  <Chris_Stewart_5> aka CScriptNum(0) OP_0 OP_EQUAL would push an OP_TRUE on the stack?
188 2016-04-11T14:58:24  <Chris_Stewart_5> sanity check for my own sake..
189 2016-04-11T14:58:45  *** electrumuser_afk has quit IRC
190 2016-04-11T15:00:27  <sipa> CScriptNum(0) is a C++ expression
191 2016-04-11T15:00:35  <sipa> OP_0 is a script operator
192 2016-04-11T15:01:12  <sipa> OP_0 pushes an empty bytearray onto the execution stack
193 2016-04-11T15:01:51  <sipa> which, if fed as input to CScriptNum will indeed produce the same as feeding it the number 0
194 2016-04-11T15:03:30  <Chris_Stewart_5> interesting. Is that just something we have to live with since Satoshi put it their or have we put that in after the fact?
195 2016-04-11T15:03:51  <Chris_Stewart_5> but the little script I gave about would evaluate to OP_FALSE then since an empty byte vector != 0 right?
196 2016-04-11T15:03:54  *** ThomasV has joined #bitcoin-core-dev
197 2016-04-11T15:04:09  *** laurentmt has joined #bitcoin-core-dev
198 2016-04-11T15:04:35  <Chris_Stewart_5> Seems like CScriptNum(OP_0) is a little strange.. surprised that even type checks
199 2016-04-11T15:08:05  <sipa> Chris_Stewart_5: "CScriotNum(0) OP_0 OP_EQUAL" has no meaning, i cannot answer your question
200 2016-04-11T15:09:03  <sipa> CScriotNum(0) is C++
201 2016-04-11T15:09:32  <sipa> it is not something that makes sense in a bitcoin script
202 2016-04-11T15:11:39  *** bsm117532 has joined #bitcoin-core-dev
203 2016-04-11T15:19:08  <sipa> Chris_Stewart_5: CScriptNum(OP_0) unfortunately works due to C++ type conversion (OP_0 is part of the opcodes enum, and gets automatically converted to an int when passing to CScriptNum's constructor
204 2016-04-11T15:23:05  <Chris_Stewart_5> sipa: is the number 0 and the empty byte vector bitwise equivalent in Script? I think that is what I was really trying to ask
205 2016-04-11T15:23:23  <Chris_Stewart_5> I'm just trying to understand how exactly it is handled, it seems in the interpreter these lines are how it is interpreted
206 2016-04-11T15:23:25  <Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L290-L294
207 2016-04-11T15:24:07  <Chris_Stewart_5> I'm not sure how the idea of 0 is handled in most PLs, is it represented as 0x00 or just an empty byte vector... I guess i'll have to more research on that later :-)
208 2016-04-11T15:26:43  <sipa> Chris_Stewart_5: in most languages, numbers and byte arrays are different data types, so the question does not even arise
209 2016-04-11T15:27:01  <sipa> but in Scriot, yes, an empty stack elemented is interpreted as tje number 0, when fed to ancoperator that expects a number
210 2016-04-11T15:27:15  *** helloworld has joined #bitcoin-core-dev
211 2016-04-11T15:27:39  *** helloworld is now known as Guest96777
212 2016-04-11T15:28:04  <Chris_Stewart_5> Thanks!
213 2016-04-11T15:28:31  *** Guest96777 is now known as electrum_user
214 2016-04-11T15:31:24  *** abritoid has quit IRC
215 2016-04-11T15:41:50  <sipa> there are other valid serializations for 0, though.
216 2016-04-11T15:46:52  *** ThomasV has quit IRC
217 2016-04-11T15:48:21  *** fengling has joined #bitcoin-core-dev
218 2016-04-11T15:53:16  *** fengling has quit IRC
219 2016-04-11T15:56:12  <Chris_Stewart_5> sipa: Are you planning on doing something similar to tx_valid/invalid.json as you did with your recent pull request?
220 2016-04-11T15:57:09  *** laurentmt has quit IRC
221 2016-04-11T15:57:17  <Chris_Stewart_5> wrt to script_valid/invalid.json
222 2016-04-11T15:58:19  *** sdaftuar has quit IRC
223 2016-04-11T15:58:22  *** zxzzt has quit IRC
224 2016-04-11T15:59:16  *** morcos has quit IRC
225 2016-04-11T16:00:10  *** sdaftuar has joined #bitcoin-core-dev
226 2016-04-11T16:00:24  *** zxzzt has joined #bitcoin-core-dev
227 2016-04-11T16:00:59  *** morcos has joined #bitcoin-core-dev
228 2016-04-11T16:23:10  *** xabbix_ has joined #bitcoin-core-dev
229 2016-04-11T16:23:37  *** xabbix has quit IRC
230 2016-04-11T16:25:51  *** cryptapus_afk has quit IRC
231 2016-04-11T16:40:36  *** johnwhitton has joined #bitcoin-core-dev
232 2016-04-11T16:56:25  *** treehug88 has joined #bitcoin-core-dev
233 2016-04-11T17:05:31  *** gevs_ has quit IRC
234 2016-04-11T17:05:54  *** gevs has joined #bitcoin-core-dev
235 2016-04-11T17:50:53  *** fengling has joined #bitcoin-core-dev
236 2016-04-11T17:55:16  *** fengling has quit IRC
237 2016-04-11T18:15:23  *** bsm117532 has quit IRC
238 2016-04-11T18:31:25  *** Chris_Stewart_5 has quit IRC
239 2016-04-11T18:42:22  *** jannes has quit IRC
240 2016-04-11T18:57:42  <sdaftuar> gmaxwell: sipa: i was looking at 7840, and i think i must not understand gmaxwell's comment about "by eliminating queued entries from the mempool response and responding only at trickle time, this makes the mempool no longer leak transaction arrival order information..."
241 2016-04-11T18:58:30  <sdaftuar> it seemed to me that if we are responding to mempool messages only at trickle time, then we might as well include everything and clear the relay queue for that peer instead?
242 2016-04-11T18:59:53  <sipa> sdaftuar: that would allow you to bypass the rate limiting by continuously requesting mempool
243 2016-04-11T19:00:09  <gmaxwell> you already bypass the rate limit via the mempool results itself though.
244 2016-04-11T19:00:10  <sdaftuar> ah
245 2016-04-11T19:00:40  <sdaftuar> but with my approach, you can learn about more than just 35 transactions or whatever
246 2016-04-11T19:01:17  <gmaxwell> At least my view is that it's not necessary to enforce the limit in that case. The limit is there to soften traffic surges when floods of new transactions come in. If you're making a mempool request, you clearly don't care. ... the alernative would be to add the mempool to the inv to send set and subject it to the rate limiter... but that would make mempool requests rather slow. :)
247 2016-04-11T19:01:42  <sipa> that makes sense
248 2016-04-11T19:05:56  <sdaftuar> so if we're not concerned about rate limiting being weakened by a mempool-attacker, is there any downside to responding with everything?
249 2016-04-11T19:07:28  <gmaxwell> I think it should respond with everything*, and remove them from the set-to-send as it goes.   (*ignoring my general complaint about there existing any P2P message that sends megabytes of response to a single query)
250 2016-04-11T19:08:13  <sdaftuar> ok that makes sense to me, though i don't know if there's any point to relaying something that has been evicted in between deciding to relay and trying to relay
251 2016-04-11T19:08:34  <sdaftuar> it's an unlikely edge case regardless
252 2016-04-11T19:08:51  <gmaxwell> It probably shouldn't relay it.
253 2016-04-11T19:09:45  <sdaftuar> actually, with the rate limiting, we should probably remove things that are mined or evicted prior to relay, right?
254 2016-04-11T19:09:56  <sdaftuar> it's conceivable that you could have a big backlog if someone dumped their mempool at you
255 2016-04-11T19:11:37  <gmaxwell> sdaftuar: related to that, I'm looking to moving all the filtering to just-in-time  https://people.xiph.org/~greg/temp/0001-Just-in-time-inventory-filtering.patch
256 2016-04-11T19:11:57  <gmaxwell> Not a PR yet because I wanted pieter's input before going and ripping out the feerate from the RelayTransaction prototype everywhere.
257 2016-04-11T19:12:23  <gmaxwell> So that applies the bloom and fee-filter right before relaying, not on the queue... so that effects of changing these filters is not delayed.
258 2016-04-11T19:12:45  <sdaftuar> that seems nice, and makes the code clearer too i suspect
259 2016-04-11T19:13:12  <sdaftuar> i guess at the expense of slightly more memory, especially for bloom-filtering peers?
260 2016-04-11T19:13:58  <sdaftuar> i'm not sure i understand the privacy gain though
261 2016-04-11T19:14:01  <gmaxwell> Very slightly, but it doesn't increase the worst case.
262 2016-04-11T19:14:09  <sdaftuar> agreed
263 2016-04-11T19:14:12  *** AaronvanW has quit IRC
264 2016-04-11T19:14:17  <gmaxwell> sdaftuar: without that change, I can rotate my filtering to 'time tag' arrivals.
265 2016-04-11T19:14:39  <gmaxwell> So even though the queuing destroys timing information, by modulating my filtering I could restore some of it.
266 2016-04-11T19:15:05  <sdaftuar> assuming a single peer connection?
267 2016-04-11T19:15:19  <sdaftuar> or multiple?
268 2016-04-11T19:15:42  <gmaxwell> If it's done with just a single, it means you'll miss some transactions. More effective with multiple.
269 2016-04-11T19:17:56  <gmaxwell> But it's justifyable just on the basis of making the relays more accurate. Likewise, something that was evicted shouldn't get relayed. Though thats corner case enough I don't know if it's worth checking.
270 2016-04-11T19:18:36  <sdaftuar> ok i think i see what you're talking about, makes sense.
271 2016-04-11T19:20:32  <sdaftuar> do you think it's worth trying to drain a peer's tx relay set faster if there's a big backlog?  i'm a little worried that this thing is bounded only by the size of the mempool, and drains at a fixed rate
272 2016-04-11T19:21:13  <sdaftuar> 100k transactions would take 4 hours or so, and in the meantime you're using a bunch of memory and slowing down the heapify, i suppose
273 2016-04-11T19:22:18  <gmaxwell> I'd rather drop stragglers than drain much faster.
274 2016-04-11T19:22:38  <sdaftuar> yeah that seems better
275 2016-04-11T19:22:54  <sdaftuar> otherwise a peer who dumps you garbage ruins relay for everyone...
276 2016-04-11T19:24:59  *** gribble has quit IRC
277 2016-04-11T19:29:37  <gmaxwell> right now someone flooding at the boundary of what you'll accept turns you into a big relay amplifier, spamming people with junk. The fee filter will help that a lot, but not completely. I was thinking about using a map on id->{depth,feerate,insert time}, and using the first two for sorting (without taking the mempool lock), the feerate for filtering (again no mempool lock), and the insert time
278 2016-04-11T19:29:39  *** gribble has joined #bitcoin-core-dev
279 2016-04-11T19:29:43  <gmaxwell> to expire things that sat around too long.
280 2016-04-11T19:29:47  *** moli has joined #bitcoin-core-dev
281 2016-04-11T19:30:49  *** molz has quit IRC
282 2016-04-11T19:32:14  *** ThomasV has joined #bitcoin-core-dev
283 2016-04-11T19:41:42  *** molz has joined #bitcoin-core-dev
284 2016-04-11T19:43:47  *** moli has quit IRC
285 2016-04-11T19:48:47  <JackH> !seen bramc
286 2016-04-11T19:48:48  <gribble> I have not seen bramc.
287 2016-04-11T19:53:17  *** fengling has joined #bitcoin-core-dev
288 2016-04-11T19:57:56  *** fengling has quit IRC
289 2016-04-11T20:09:03  *** Guyver2_ has joined #bitcoin-core-dev
290 2016-04-11T20:09:04  *** aureianimus has quit IRC
291 2016-04-11T20:10:32  <GitHub88> [bitcoin] sdaftuar opened pull request #7862: Use txid as key in mapAlreadyAskedFor (master...inv-to-txid-mapalreadyaskedfor) https://github.com/bitcoin/bitcoin/pull/7862
292 2016-04-11T20:11:42  *** Guyver2 has quit IRC
293 2016-04-11T20:11:47  *** Guyver2_ is now known as Guyver2
294 2016-04-11T20:38:48  *** muuqwaul has joined #bitcoin-core-dev
295 2016-04-11T20:49:38  *** Guyver2 has quit IRC
296 2016-04-11T20:52:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
297 2016-04-11T20:59:17  *** luke-jr_ is now known as Luke-Jr
298 2016-04-11T21:02:28  *** muuqwaul has quit IRC
299 2016-04-11T21:02:52  *** muuqwaul has joined #bitcoin-core-dev
300 2016-04-11T21:04:21  *** electrum_user has quit IRC
301 2016-04-11T21:10:26  *** muuqwaul has quit IRC
302 2016-04-11T21:10:49  *** muuqwaul has joined #bitcoin-core-dev
303 2016-04-11T21:11:32  *** muuqwaul has quit IRC
304 2016-04-11T21:11:59  *** muuqwaul has joined #bitcoin-core-dev
305 2016-04-11T21:12:18  <Chris_Stewart_5> Why does the DISCOURAGE_UPGRADABLE_NOPS flag allow a OP_NOP?
306 2016-04-11T21:12:28  *** muuqwaul has quit IRC
307 2016-04-11T21:12:47  <Chris_Stewart_5> i.e. this test case ["1", "NOP", "P2SH,STRICTENC,DISCOURAGE_UPGRADABLE_NOPS", "OK", "Discourage NOPx flag allows OP_NOP"]
308 2016-04-11T21:12:54  *** muuqwaul has joined #bitcoin-core-dev
309 2016-04-11T21:14:43  *** ThomasV has quit IRC
310 2016-04-11T21:20:03  *** murch has quit IRC
311 2016-04-11T21:20:44  *** Don_John has joined #bitcoin-core-dev
312 2016-04-11T21:20:52  *** muuqwaul has quit IRC
313 2016-04-11T21:20:55  *** Don_John has quit IRC
314 2016-04-11T21:21:17  *** muuqwaul has joined #bitcoin-core-dev
315 2016-04-11T21:29:15  *** belcher has joined #bitcoin-core-dev
316 2016-04-11T21:31:24  <instagibbs> OP_NOP isn't in the set of NOPx
317 2016-04-11T21:31:33  <instagibbs> although that probably doesn't answer your question
318 2016-04-11T21:32:07  <instagibbs> OP_NOP is 0x61 while the other NOPS are 0xb0, so they were probably created for different reasons
319 2016-04-11T21:32:55  <instagibbs> Meaning OP_NOP will probably not be relied on for future softforks, especially if they aren't currently discouraged
320 2016-04-11T21:34:30  *** muuqwaul has quit IRC
321 2016-04-11T21:34:57  *** muuqwaul has joined #bitcoin-core-dev
322 2016-04-11T21:51:23  *** d_t has joined #bitcoin-core-dev
323 2016-04-11T21:53:07  *** treehug88 has quit IRC
324 2016-04-11T21:56:28  *** muuqwaul has quit IRC
325 2016-04-11T21:56:56  *** muuqwaul has joined #bitcoin-core-dev
326 2016-04-11T22:00:55  *** muuqwaul has quit IRC
327 2016-04-11T22:01:23  *** muuqwaul has joined #bitcoin-core-dev
328 2016-04-11T22:04:41  *** cguida has quit IRC
329 2016-04-11T22:04:47  *** cguida_ has joined #bitcoin-core-dev
330 2016-04-11T22:18:53  *** muuqwaul has quit IRC
331 2016-04-11T22:19:16  *** muuqwaul has joined #bitcoin-core-dev
332 2016-04-11T22:42:58  *** electrumuser has joined #bitcoin-core-dev
333 2016-04-11T22:55:21  *** d_t has quit IRC
334 2016-04-11T23:18:20  *** laurentmt has joined #bitcoin-core-dev
335 2016-04-11T23:19:33  *** laurentmt has quit IRC
336 2016-04-11T23:34:21  *** cryptapus has joined #bitcoin-core-dev
337 2016-04-11T23:35:07  *** cryptapus is now known as cryptapus_afk