12016-04-11T00:13:20  *** challisto has joined #bitcoin-core-dev
  22016-04-11T00:46:55  *** btcdrak has quit IRC
  32016-04-11T00:49:35  *** PRab has quit IRC
  42016-04-11T01:08:44  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  52016-04-11T01:16:55  *** belcher has quit IRC
  62016-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?
  72016-04-11T01:24:13  <achow101> BlueMatt: I've got it twive
  82016-04-11T01:24:18  <achow101> *twice
  92016-04-11T01:24:26  <BlueMatt> across how many days/restarts?
 102016-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
 112016-04-11T01:26:40  <achow101> since march 10th and 51 restarts
 122016-04-11T01:27:13  <BlueMatt> achow101: thanks
 132016-04-11T01:28:11  *** fengling has joined #bitcoin-core-dev
 142016-04-11T01:32:29  *** PRab has joined #bitcoin-core-dev
 152016-04-11T01:52:27  *** johnwhitton has joined #bitcoin-core-dev
 162016-04-11T02:00:18  *** dermoth has quit IRC
 172016-04-11T02:00:59  *** dermoth has joined #bitcoin-core-dev
 182016-04-11T02:09:15  *** xiangfu has joined #bitcoin-core-dev
 192016-04-11T02:10:20  *** johnwhitton has quit IRC
 202016-04-11T02:24:53  *** johnwhitton has joined #bitcoin-core-dev
 212016-04-11T02:41:04  *** Ylbam has quit IRC
 222016-04-11T03:05:38  *** PaulCape_ has quit IRC
 232016-04-11T03:07:47  *** PaulCapestany has joined #bitcoin-core-dev
 242016-04-11T03:11:00  *** btcdrak has joined #bitcoin-core-dev
 252016-04-11T03:18:00  *** Chris_Stewart_5 has quit IRC
 262016-04-11T04:21:03  *** xiangfu has quit IRC
 272016-04-11T04:21:29  *** xiangfu has joined #bitcoin-core-dev
 282016-04-11T04:28:56  *** ThomasV has joined #bitcoin-core-dev
 292016-04-11T04:45:40  *** Giszmo has quit IRC
 302016-04-11T05:36:16  *** fengling has quit IRC
 312016-04-11T05:40:01  *** Alopex has quit IRC
 322016-04-11T05:41:06  *** Alopex has joined #bitcoin-core-dev
 332016-04-11T06:00:10  *** dermoth has quit IRC
 342016-04-11T06:00:47  *** dermoth has joined #bitcoin-core-dev
 352016-04-11T06:02:51  *** jarret has quit IRC
 362016-04-11T06:09:00  *** ThomasV has quit IRC
 372016-04-11T06:19:33  *** xiangfu has quit IRC
 382016-04-11T06:26:55  *** btcdrak has quit IRC
 392016-04-11T06:29:26  *** d_t has quit IRC
 402016-04-11T06:39:48  *** xiangfu has joined #bitcoin-core-dev
 412016-04-11T06:41:51  *** fengling has joined #bitcoin-core-dev
 422016-04-11T06:53:29  *** Ylbam has joined #bitcoin-core-dev
 432016-04-11T06:55:13  *** laurentmt has joined #bitcoin-core-dev
 442016-04-11T06:56:49  *** cjcj_ has joined #bitcoin-core-dev
 452016-04-11T06:57:58  *** laurentmt has quit IRC
 462016-04-11T06:58:40  *** laurentmt has joined #bitcoin-core-dev
 472016-04-11T07:03:01  *** Alopex has quit IRC
 482016-04-11T07:03:23  *** laurentmt has quit IRC
 492016-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! :)
 502016-04-11T07:04:06  *** Alopex has joined #bitcoin-core-dev
 512016-04-11T07:04:22  <sipa> weekends are highly overratee
 522016-04-11T07:04:26  <sipa> weekends are highly overrated
 532016-04-11T07:07:16  *** fengling has quit IRC
 542016-04-11T07:08:24  <jonasschnelli> Yah! Tell that my wife. :)
 552016-04-11T07:13:50  *** fengling has joined #bitcoin-core-dev
 562016-04-11T07:14:07  *** xiangfu has quit IRC
 572016-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
 582016-04-11T07:28:55  *** laurentmt has joined #bitcoin-core-dev
 592016-04-11T07:29:09  *** ThomasV has joined #bitcoin-core-dev
 602016-04-11T07:31:21  *** xiangfu has joined #bitcoin-core-dev
 612016-04-11T07:35:21  *** johnwhitton has quit IRC
 622016-04-11T07:48:37  *** paveljanik has quit IRC
 632016-04-11T07:48:45  *** abritoid has joined #bitcoin-core-dev
 642016-04-11T07:50:44  *** cryptapus_afk has quit IRC
 652016-04-11T07:50:44  *** cryptapus has joined #bitcoin-core-dev
 662016-04-11T07:50:44  *** cryptapus has joined #bitcoin-core-dev
 672016-04-11T07:50:45  *** cryptapus is now known as cryptapus_afk
 682016-04-11T07:56:18  *** btcdrak has joined #bitcoin-core-dev
 692016-04-11T08:01:09  <BlueMatt> hmm, the sendheaders stuff is pretty bitcoin-core-specific
 702016-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)
 712016-04-11T08:01:42  <BlueMatt> sipa: ^
 722016-04-11T08:02:38  *** xiangfu has quit IRC
 732016-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
 742016-04-11T08:05:36  <sipa> you can always send all headers along the new branch you're switching to
 752016-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
 762016-04-11T08:06:40  <BlueMatt> sipa: but we dont do this
 772016-04-11T08:06:54  <BlueMatt> sipa: also, why not just remove the DoS?
 782016-04-11T08:07:09  <BlueMatt> sipa: and if it doesnt connect, just send a getheaders for further-back headers
 792016-04-11T08:07:18  <sipa> which case are you talking about, a non-core peer sending headers to core, or the other way around?
 802016-04-11T08:07:32  <BlueMatt> in this case I'm talking about core-to-core
 812016-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
 822016-04-11T08:08:11  <sipa> it should send all new headers along the new branch
 832016-04-11T08:08:26  <sipa> unless there are too many, in which case it intentionally falls back to using invs
 842016-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)
 852016-04-11T08:08:46  *** challisto has quit IRC
 862016-04-11T08:08:47  *** abritoid_ has joined #bitcoin-core-dev
 872016-04-11T08:08:54  <sipa> then we send the header for B
 882016-04-11T08:09:01  <BlueMatt> I dont think it will? It will only ever send invs/headers that were added to vBlockHashesTonnounce
 892016-04-11T08:09:19  <BlueMatt> no, because B wont be in vBlockHashesToAnnounce
 902016-04-11T08:09:34  <BlueMatt> only D (based on B) will be
 912016-04-11T08:10:29  *** abritoid has quit IRC
 922016-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
 932016-04-11T08:10:52  *** xiangfu has joined #bitcoin-core-dev
 942016-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)
 952016-04-11T08:12:10  <BlueMatt> sipa: eg https://github.com/TheBlueMatt/bitcoin/commits/1daf94f540592345dca5818321a28996fe7e04fd
 962016-04-11T08:12:11  <BlueMatt> ?
 972016-04-11T08:14:33  <sipa> hmm, i'd still like to understand the use case
 982016-04-11T08:15:59  *** MarcoFalke has joined #bitcoin-core-dev
 992016-04-11T08:15:59  <BlueMatt> sipa: the use-case is simpler code for other implementors (or maybe us in the future)
1002016-04-11T08:16:06  <sipa> we have D-B-A as tip, a peer has C-A as tip
1012016-04-11T08:16:08  <BlueMatt> sipa: they could even skip the inv logic
1022016-04-11T08:16:13  <BlueMatt> sipa: that is a separate bug
1032016-04-11T08:16:22  <sipa> let's talk one thing at a timr
1042016-04-11T08:17:18  <sipa> but the peer will have the headers for D and B already
1052016-04-11T08:17:25  <sipa> eh, B
1062016-04-11T08:17:31  <sipa> so just sending D should be fine?
1072016-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
1082016-04-11T08:18:37  <sipa> it's possible that B was sent just as an inv
1092016-04-11T08:18:52  <sipa> and the peer hasn't getdata'd yet
1102016-04-11T08:18:58  <BlueMatt> no, its worse
1112016-04-11T08:19:07  <BlueMatt> they could have had B already from another peer
1122016-04-11T08:19:19  <BlueMatt> well, yea, i suppose it would be an inv, then
1132016-04-11T08:19:22  <BlueMatt> but they wouldnt request it
1142016-04-11T08:19:34  <sipa> we would still have either sent an inv or a header, indeed
1152016-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
1162016-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
1172016-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
1182016-04-11T08:22:08  *** jannes has joined #bitcoin-core-dev
1192016-04-11T08:22:58  <BlueMatt> anyway, bedtime for me
1202016-04-11T08:44:35  *** MarcoFalke has quit IRC
1212016-04-11T08:55:16  *** fengling has quit IRC
1222016-04-11T08:57:29  *** cjcj_ has quit IRC
1232016-04-11T09:00:31  *** fengling has joined #bitcoin-core-dev
1242016-04-11T09:00:32  *** abritoid_ has quit IRC
1252016-04-11T09:06:30  *** gevs has joined #bitcoin-core-dev
1262016-04-11T09:13:16  *** murch has joined #bitcoin-core-dev
1272016-04-11T09:21:02  *** laurentmt has quit IRC
1282016-04-11T09:26:20  *** ThomasV has quit IRC
1292016-04-11T09:29:44  *** ThomasV has joined #bitcoin-core-dev
1302016-04-11T09:30:19  *** AaronvanW has joined #bitcoin-core-dev
1312016-04-11T09:30:38  *** cjcj_ has joined #bitcoin-core-dev
1322016-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
1332016-04-11T09:43:16  *** fengling has quit IRC
1342016-04-11T09:45:06  *** abritoid has joined #bitcoin-core-dev
1352016-04-11T09:47:22  *** xiangfu has quit IRC
1362016-04-11T09:56:56  *** Evel-Knievel has quit IRC
1372016-04-11T10:25:02  *** ThomasV has quit IRC
1382016-04-11T10:29:52  *** xiangfu has joined #bitcoin-core-dev
1392016-04-11T10:46:41  *** Evel-Knievel has joined #bitcoin-core-dev
1402016-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"
1412016-04-11T10:46:50  <wumpus> going to request this
1422016-04-11T10:49:29  *** xiangfu has quit IRC
1432016-04-11T10:49:31  <sipa> wumpus: that will be interesting :)
1442016-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
1452016-04-11T10:52:03  <wumpus> yes it'd be nice
1462016-04-11T10:57:52  <GitHub183> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/065c6b443f3e...934f2b5e7693
1472016-04-11T10:57:52  <GitHub183> bitcoin/master 64c22be Johnson Lau: Add jl2012 public key for gitian build
1482016-04-11T10:57:53  <GitHub183> bitcoin/master 934f2b5 Wladimir J. van der Laan: Merge #7858: Add jl2012 public key for gitian build...
1492016-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
1502016-04-11T11:02:13  <GitHub100> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/465d30915cd3...9779e1e1f320
1512016-04-11T11:02:13  <GitHub100> bitcoin/0.12 de7c34c BtcDrak: Add missing link to BIP113
1522016-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
1532016-04-11T11:02:14  <GitHub100> bitcoin/0.12 9779e1e Wladimir J. van der Laan: Merge #7852: [0.12] Add missing reference to release notes...
1542016-04-11T11:06:02  *** xiangfu has joined #bitcoin-core-dev
1552016-04-11T11:22:34  *** ThomasV has joined #bitcoin-core-dev
1562016-04-11T11:24:11  *** xiangfu has quit IRC
1572016-04-11T11:24:23  *** laurentmt has joined #bitcoin-core-dev
1582016-04-11T11:24:28  *** laurentmt has quit IRC
1592016-04-11T11:41:43  *** fengling has joined #bitcoin-core-dev
1602016-04-11T11:46:36  *** fengling has quit IRC
1612016-04-11T11:49:22  *** jarret has joined #bitcoin-core-dev
1622016-04-11T11:59:20  <instagibbs> wumpus, you pointed to rc1 in the source on mailing list, FYI :P
1632016-04-11T11:59:35  <wumpus> yes I sent a mail after it correcting it right?
1642016-04-11T11:59:52  <instagibbs> maybe my email is slow
1652016-04-11T12:00:03  <wumpus> https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-April/000002.html
1662016-04-11T12:00:17  <instagibbs> oh i see it, maybe I checked email while asleep :)
1672016-04-11T12:06:44  <wumpus> :)
1682016-04-11T12:10:17  <sipa> oh, you're a sleepmailer too?
1692016-04-11T12:21:06  *** paveljanik has joined #bitcoin-core-dev
1702016-04-11T12:42:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1712016-04-11T12:46:55  <instagibbs> with new baby you never quite know when you checked things fully awake
1722016-04-11T13:02:24  *** ThomasV has quit IRC
1732016-04-11T13:26:03  *** baldur has quit IRC
1742016-04-11T13:27:24  *** gevs_ has joined #bitcoin-core-dev
1752016-04-11T13:29:47  *** gevs has quit IRC
1762016-04-11T13:45:41  *** fengling has joined #bitcoin-core-dev
1772016-04-11T13:50:16  *** fengling has quit IRC
1782016-04-11T13:50:34  *** d_t has joined #bitcoin-core-dev
1792016-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
1802016-04-11T13:55:10  *** d_t has quit IRC
1812016-04-11T14:03:12  *** Guyver2 has joined #bitcoin-core-dev
1822016-04-11T14:32:32  *** Giszmo has joined #bitcoin-core-dev
1832016-04-11T14:36:04  *** fkhan_ has quit IRC
1842016-04-11T14:46:56  <jonasschnelli> hmm... these guys: https://twitter.com/kawalgrover/status/719535585153716224
1852016-04-11T14:49:26  *** fkhan_ has joined #bitcoin-core-dev
1862016-04-11T14:57:41  <Chris_Stewart_5> Is CScriptNum(0) bitwise equivalent to OP_0?
1872016-04-11T14:58:01  <Chris_Stewart_5> aka CScriptNum(0) OP_0 OP_EQUAL would push an OP_TRUE on the stack?
1882016-04-11T14:58:24  <Chris_Stewart_5> sanity check for my own sake..
1892016-04-11T14:58:45  *** electrumuser_afk has quit IRC
1902016-04-11T15:00:27  <sipa> CScriptNum(0) is a C++ expression
1912016-04-11T15:00:35  <sipa> OP_0 is a script operator
1922016-04-11T15:01:12  <sipa> OP_0 pushes an empty bytearray onto the execution stack
1932016-04-11T15:01:51  <sipa> which, if fed as input to CScriptNum will indeed produce the same as feeding it the number 0
1942016-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?
1952016-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?
1962016-04-11T15:03:54  *** ThomasV has joined #bitcoin-core-dev
1972016-04-11T15:04:09  *** laurentmt has joined #bitcoin-core-dev
1982016-04-11T15:04:35  <Chris_Stewart_5> Seems like CScriptNum(OP_0) is a little strange.. surprised that even type checks
1992016-04-11T15:08:05  <sipa> Chris_Stewart_5: "CScriotNum(0) OP_0 OP_EQUAL" has no meaning, i cannot answer your question
2002016-04-11T15:09:03  <sipa> CScriotNum(0) is C++
2012016-04-11T15:09:32  <sipa> it is not something that makes sense in a bitcoin script
2022016-04-11T15:11:39  *** bsm117532 has joined #bitcoin-core-dev
2032016-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
2042016-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
2052016-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
2062016-04-11T15:23:25  <Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L290-L294
2072016-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 :-)
2082016-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
2092016-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
2102016-04-11T15:27:15  *** helloworld has joined #bitcoin-core-dev
2112016-04-11T15:27:39  *** helloworld is now known as Guest96777
2122016-04-11T15:28:04  <Chris_Stewart_5> Thanks!
2132016-04-11T15:28:31  *** Guest96777 is now known as electrum_user
2142016-04-11T15:31:24  *** abritoid has quit IRC
2152016-04-11T15:41:50  <sipa> there are other valid serializations for 0, though.
2162016-04-11T15:46:52  *** ThomasV has quit IRC
2172016-04-11T15:48:21  *** fengling has joined #bitcoin-core-dev
2182016-04-11T15:53:16  *** fengling has quit IRC
2192016-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?
2202016-04-11T15:57:09  *** laurentmt has quit IRC
2212016-04-11T15:57:17  <Chris_Stewart_5> wrt to script_valid/invalid.json
2222016-04-11T15:58:19  *** sdaftuar has quit IRC
2232016-04-11T15:58:22  *** zxzzt has quit IRC
2242016-04-11T15:59:16  *** morcos has quit IRC
2252016-04-11T16:00:10  *** sdaftuar has joined #bitcoin-core-dev
2262016-04-11T16:00:24  *** zxzzt has joined #bitcoin-core-dev
2272016-04-11T16:00:59  *** morcos has joined #bitcoin-core-dev
2282016-04-11T16:23:10  *** xabbix_ has joined #bitcoin-core-dev
2292016-04-11T16:23:37  *** xabbix has quit IRC
2302016-04-11T16:25:51  *** cryptapus_afk has quit IRC
2312016-04-11T16:40:36  *** johnwhitton has joined #bitcoin-core-dev
2322016-04-11T16:56:25  *** treehug88 has joined #bitcoin-core-dev
2332016-04-11T17:05:31  *** gevs_ has quit IRC
2342016-04-11T17:05:54  *** gevs has joined #bitcoin-core-dev
2352016-04-11T17:50:53  *** fengling has joined #bitcoin-core-dev
2362016-04-11T17:55:16  *** fengling has quit IRC
2372016-04-11T18:15:23  *** bsm117532 has quit IRC
2382016-04-11T18:31:25  *** Chris_Stewart_5 has quit IRC
2392016-04-11T18:42:22  *** jannes has quit IRC
2402016-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..."
2412016-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?
2422016-04-11T18:59:53  <sipa> sdaftuar: that would allow you to bypass the rate limiting by continuously requesting mempool
2432016-04-11T19:00:09  <gmaxwell> you already bypass the rate limit via the mempool results itself though.
2442016-04-11T19:00:10  <sdaftuar> ah
2452016-04-11T19:00:40  <sdaftuar> but with my approach, you can learn about more than just 35 transactions or whatever
2462016-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. :)
2472016-04-11T19:01:42  <sipa> that makes sense
2482016-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?
2492016-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)
2502016-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
2512016-04-11T19:08:34  <sdaftuar> it's an unlikely edge case regardless
2522016-04-11T19:08:51  <gmaxwell> It probably shouldn't relay it.
2532016-04-11T19:09:45  <sdaftuar> actually, with the rate limiting, we should probably remove things that are mined or evicted prior to relay, right?
2542016-04-11T19:09:56  <sdaftuar> it's conceivable that you could have a big backlog if someone dumped their mempool at you
2552016-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
2562016-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.
2572016-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.
2582016-04-11T19:12:45  <sdaftuar> that seems nice, and makes the code clearer too i suspect
2592016-04-11T19:13:12  <sdaftuar> i guess at the expense of slightly more memory, especially for bloom-filtering peers?
2602016-04-11T19:13:58  <sdaftuar> i'm not sure i understand the privacy gain though
2612016-04-11T19:14:01  <gmaxwell> Very slightly, but it doesn't increase the worst case.
2622016-04-11T19:14:09  <sdaftuar> agreed
2632016-04-11T19:14:12  *** AaronvanW has quit IRC
2642016-04-11T19:14:17  <gmaxwell> sdaftuar: without that change, I can rotate my filtering to 'time tag' arrivals.
2652016-04-11T19:14:39  <gmaxwell> So even though the queuing destroys timing information, by modulating my filtering I could restore some of it.
2662016-04-11T19:15:05  <sdaftuar> assuming a single peer connection?
2672016-04-11T19:15:19  <sdaftuar> or multiple?
2682016-04-11T19:15:42  <gmaxwell> If it's done with just a single, it means you'll miss some transactions. More effective with multiple.
2692016-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.
2702016-04-11T19:18:36  <sdaftuar> ok i think i see what you're talking about, makes sense.
2712016-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
2722016-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
2732016-04-11T19:22:18  <gmaxwell> I'd rather drop stragglers than drain much faster.
2742016-04-11T19:22:38  <sdaftuar> yeah that seems better
2752016-04-11T19:22:54  <sdaftuar> otherwise a peer who dumps you garbage ruins relay for everyone...
2762016-04-11T19:24:59  *** gribble has quit IRC
2772016-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
2782016-04-11T19:29:39  *** gribble has joined #bitcoin-core-dev
2792016-04-11T19:29:43  <gmaxwell> to expire things that sat around too long.
2802016-04-11T19:29:47  *** moli has joined #bitcoin-core-dev
2812016-04-11T19:30:49  *** molz has quit IRC
2822016-04-11T19:32:14  *** ThomasV has joined #bitcoin-core-dev
2832016-04-11T19:41:42  *** molz has joined #bitcoin-core-dev
2842016-04-11T19:43:47  *** moli has quit IRC
2852016-04-11T19:48:47  <JackH> !seen bramc
2862016-04-11T19:48:48  <gribble> I have not seen bramc.
2872016-04-11T19:53:17  *** fengling has joined #bitcoin-core-dev
2882016-04-11T19:57:56  *** fengling has quit IRC
2892016-04-11T20:09:03  *** Guyver2_ has joined #bitcoin-core-dev
2902016-04-11T20:09:04  *** aureianimus has quit IRC
2912016-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
2922016-04-11T20:11:42  *** Guyver2 has quit IRC
2932016-04-11T20:11:47  *** Guyver2_ is now known as Guyver2
2942016-04-11T20:38:48  *** muuqwaul has joined #bitcoin-core-dev
2952016-04-11T20:49:38  *** Guyver2 has quit IRC
2962016-04-11T20:52:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2972016-04-11T20:59:17  *** luke-jr_ is now known as Luke-Jr
2982016-04-11T21:02:28  *** muuqwaul has quit IRC
2992016-04-11T21:02:52  *** muuqwaul has joined #bitcoin-core-dev
3002016-04-11T21:04:21  *** electrum_user has quit IRC
3012016-04-11T21:10:26  *** muuqwaul has quit IRC
3022016-04-11T21:10:49  *** muuqwaul has joined #bitcoin-core-dev
3032016-04-11T21:11:32  *** muuqwaul has quit IRC
3042016-04-11T21:11:59  *** muuqwaul has joined #bitcoin-core-dev
3052016-04-11T21:12:18  <Chris_Stewart_5> Why does the DISCOURAGE_UPGRADABLE_NOPS flag allow a OP_NOP?
3062016-04-11T21:12:28  *** muuqwaul has quit IRC
3072016-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"]
3082016-04-11T21:12:54  *** muuqwaul has joined #bitcoin-core-dev
3092016-04-11T21:14:43  *** ThomasV has quit IRC
3102016-04-11T21:20:03  *** murch has quit IRC
3112016-04-11T21:20:44  *** Don_John has joined #bitcoin-core-dev
3122016-04-11T21:20:52  *** muuqwaul has quit IRC
3132016-04-11T21:20:55  *** Don_John has quit IRC
3142016-04-11T21:21:17  *** muuqwaul has joined #bitcoin-core-dev
3152016-04-11T21:29:15  *** belcher has joined #bitcoin-core-dev
3162016-04-11T21:31:24  <instagibbs> OP_NOP isn't in the set of NOPx
3172016-04-11T21:31:33  <instagibbs> although that probably doesn't answer your question
3182016-04-11T21:32:07  <instagibbs> OP_NOP is 0x61 while the other NOPS are 0xb0, so they were probably created for different reasons
3192016-04-11T21:32:55  <instagibbs> Meaning OP_NOP will probably not be relied on for future softforks, especially if they aren't currently discouraged
3202016-04-11T21:34:30  *** muuqwaul has quit IRC
3212016-04-11T21:34:57  *** muuqwaul has joined #bitcoin-core-dev
3222016-04-11T21:51:23  *** d_t has joined #bitcoin-core-dev
3232016-04-11T21:53:07  *** treehug88 has quit IRC
3242016-04-11T21:56:28  *** muuqwaul has quit IRC
3252016-04-11T21:56:56  *** muuqwaul has joined #bitcoin-core-dev
3262016-04-11T22:00:55  *** muuqwaul has quit IRC
3272016-04-11T22:01:23  *** muuqwaul has joined #bitcoin-core-dev
3282016-04-11T22:04:41  *** cguida has quit IRC
3292016-04-11T22:04:47  *** cguida_ has joined #bitcoin-core-dev
3302016-04-11T22:18:53  *** muuqwaul has quit IRC
3312016-04-11T22:19:16  *** muuqwaul has joined #bitcoin-core-dev
3322016-04-11T22:42:58  *** electrumuser has joined #bitcoin-core-dev
3332016-04-11T22:55:21  *** d_t has quit IRC
3342016-04-11T23:18:20  *** laurentmt has joined #bitcoin-core-dev
3352016-04-11T23:19:33  *** laurentmt has quit IRC
3362016-04-11T23:34:21  *** cryptapus has joined #bitcoin-core-dev
3372016-04-11T23:35:07  *** cryptapus is now known as cryptapus_afk