--- Day changed Mon Apr 11 2016
00:03 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
00:03 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
00:03 < 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! :)
00:04 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
00:04 < sipa> weekends are highly overratee
00:04 < sipa> weekends are highly overrated
00:07 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
00:08 < jonasschnelli> Yah! Tell that my wife. :)
00:13 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
00:14 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 250 seconds]
00:26 < GitHub84> [bitcoin] promag opened pull request #7857: Add fee to fundrawtransaction (master...enhancement/add-fee-to-fundrawtransaction) https://github.com/bitcoin/bitcoin/pull/7857
00:28 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
00:29 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-core-dev
00:31 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
00:35 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton]
00:48 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
00:48 -!- abritoid [~abritoid@46.16.193.99] has joined #bitcoin-core-dev
00:50 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
00:50 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev
00:50 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]
00:50 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
00:50 -!- cryptapus is now known as cryptapus_afk
00:56 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-ntuewcdizyvajtht] has joined #bitcoin-core-dev
01:01 < BlueMatt> hmm, the sendheaders stuff is pretty bitcoin-core-specific
01:01 < 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)
01:01 < BlueMatt> sipa: ^
01:02 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 248 seconds]
01:02 < 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
01:05 < sipa> you can always send all headers along the new branch you're switching to
01: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
01:06 < BlueMatt> sipa: but we dont do this
01:06 < BlueMatt> sipa: also, why not just remove the DoS?
01:07 < BlueMatt> sipa: and if it doesnt connect, just send a getheaders for further-back headers
01:07 < sipa> which case are you talking about, a non-core peer sending headers to core, or the other way around?
01:07 < BlueMatt> in this case I'm talking about core-to-core
01:07 < 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
01:08 < sipa> it should send all new headers along the new branch
01:08 < sipa> unless there are too many, in which case it intentionally falls back to using invs
01:08 < 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)
01:08 -!- challisto [~challisto@unaffiliated/challisto] has quit [Quit: Leaving]
01:08 -!- abritoid_ [~abritoid@46.16.193.99] has joined #bitcoin-core-dev
01:08 < sipa> then we send the header for B
01:09 < BlueMatt> I dont think it will? It will only ever send invs/headers that were added to vBlockHashesTonnounce
01:09 < BlueMatt> no, because B wont be in vBlockHashesToAnnounce
01:09 < BlueMatt> only D (based on B) will be
01:10 -!- abritoid [~abritoid@46.16.193.99] has quit [Read error: Connection reset by peer]
01:10 < 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
01:10 -!- xiangfu [~xiangfu@49.4.170.106] has joined #bitcoin-core-dev
01:11 < BlueMatt> would make it much easier for other implementors (they can skip all block inv sending, though that would be a bit less effecient)
01:12 < BlueMatt> sipa: eg https://github.com/TheBlueMatt/bitcoin/commits/1daf94f540592345dca5818321a28996fe7e04fd 
01:12 < BlueMatt> ?
01:14 < sipa> hmm, i'd still like to understand the use case
01:16 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
01:16 < BlueMatt> sipa: the use-case is simpler code for other implementors (or maybe us in the future)
01:16 < sipa> we have D-B-A as tip, a peer has C-A as tip
01:16 < BlueMatt> sipa: they could even skip the inv logic
01:16 < BlueMatt> sipa: that is a separate bug
01:16 < sipa> let's talk one thing at a timr
01:17 < sipa> but the peer will have the headers for D and B already
01:17 < sipa> eh, B
01:17 < sipa> so just sending D should be fine?
01:18 < BlueMatt> this only works if either the last header we sent them or the last header they sent us is B
01:18 < sipa> it's possible that B was sent just as an inv
01:18 < sipa> and the peer hasn't getdata'd yet
01:19 < BlueMatt> no, its worse
01:19 < BlueMatt> they could have had B already from another peer
01:19 < BlueMatt> well, yea, i suppose it would be an inv, then
01:19 < BlueMatt> but they wouldnt request it
01:19 < sipa> we would still have either sent an inv or a header, indeed
01:20 < 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
01:21 < 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
01:21 < BlueMatt> why not just always use headers and if you got headers that you cant connect, treat them as invs and request more headers
01:22 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
01:23 < BlueMatt> anyway, bedtime for me
01:44 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
01:55 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
01:57 -!- cjcj_ [82ebca3a@gateway/web/freenode/ip.130.235.202.58] has quit [Quit: Page closed]
02:00 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
02:00 -!- abritoid_ [~abritoid@46.16.193.99] has quit [Ping timeout: 244 seconds]
02:06 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
02:13 -!- murch [~murch@p4FE3A113.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
02:21 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
02:26 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 244 seconds]
02:29 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-core-dev
02:30 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:30 -!- cjcj_ [82ebca3a@gateway/web/freenode/ip.130.235.202.58] has joined #bitcoin-core-dev
02:32 < GitHub33> [bitcoin] jl2012 opened pull request #7858: Add jl2012 public key for gitian build (master...patch-9) https://github.com/bitcoin/bitcoin/pull/7858
02:43 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
02:45 -!- abritoid [~abritoid@46.16.193.99] has joined #bitcoin-core-dev
02:47 -!- xiangfu [~xiangfu@49.4.170.106] has quit [Ping timeout: 268 seconds]
02:56 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit []
03:25 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 248 seconds]
03:29 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
03:46 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
03:46 < 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"
03:46 < wumpus> going to request this
03:49 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 250 seconds]
03:49 < sipa> wumpus: that will be interesting :)
03:51 < 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
03:52 < wumpus> yes it'd be nice
03:57 < GitHub183> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/065c6b443f3e...934f2b5e7693
03:57 < GitHub183> bitcoin/master 64c22be Johnson Lau: Add jl2012 public key for gitian build
03:57 < GitHub183> bitcoin/master 934f2b5 Wladimir J. van der Laan: Merge #7858: Add jl2012 public key for gitian build...
03:58 < GitHub114> [bitcoin] laanwj closed pull request #7858: Add jl2012 public key for gitian build (master...patch-9) https://github.com/bitcoin/bitcoin/pull/7858
04:02 < GitHub100> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/465d30915cd3...9779e1e1f320
04:02 < GitHub100> bitcoin/0.12 de7c34c BtcDrak: Add missing link to BIP113
04:02 < 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
04:02 < GitHub100> bitcoin/0.12 9779e1e Wladimir J. van der Laan: Merge #7852: [0.12] Add missing reference to release notes...
04:06 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
04:22 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-core-dev
04:24 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 268 seconds]
04:24 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
04:24 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
04:41 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
04:46 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
04:49 -!- jarret [~jarret@162.216.46.119] has joined #bitcoin-core-dev
04:59 < instagibbs> wumpus, you pointed to rc1 in the source on mailing list, FYI :P
04:59 < wumpus> yes I sent a mail after it correcting it right?
04:59 < instagibbs> maybe my email is slow
05:00 < wumpus> https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-April/000002.html
05:00 < instagibbs> oh i see it, maybe I checked email while asleep :)
05:06 < wumpus> :)
05:10 < sipa> oh, you're a sleepmailer too?
05:21 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
05:42 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:46 < instagibbs> with new baby you never quite know when you checked things fully awake
06:02 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds]
06:26 -!- baldur [~baldur@pool-72-69-12-130.nycmny.fios.verizon.net] has quit [Ping timeout: 244 seconds]
06:27 -!- gevs_ [~greg@ip-81-11-204-20.dsl.scarlet.be] has joined #bitcoin-core-dev
06:29 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 260 seconds]
06:45 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
06:50 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
06:50 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
06:53 < 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
06:55 -!- d_t [~textual@185.69.203.10] has quit [Ping timeout: 248 seconds]
07:03 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:32 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
07:36 -!- fkhan_ [weechat@gateway/vpn/mullvad/x-lyaogylpotuucrgl] has quit [Ping timeout: 260 seconds]
07:46 < jonasschnelli> hmm... these guys: https://twitter.com/kawalgrover/status/719535585153716224
07:49 -!- fkhan_ [weechat@gateway/vpn/mullvad/x-qtsmkusexozkucvb] has joined #bitcoin-core-dev
07:57 < Chris_Stewart_5> Is CScriptNum(0) bitwise equivalent to OP_0?
07:58 < Chris_Stewart_5> aka CScriptNum(0) OP_0 OP_EQUAL would push an OP_TRUE on the stack?
07:58 < Chris_Stewart_5> sanity check for my own sake..
07:58 -!- electrumuser_afk [~foobar@181.121.64.244] has quit [Ping timeout: 276 seconds]
08:00 < sipa> CScriptNum(0) is a C++ expression
08:00 < sipa> OP_0 is a script operator
08:01 < sipa> OP_0 pushes an empty bytearray onto the execution stack
08:01 < sipa> which, if fed as input to CScriptNum will indeed produce the same as feeding it the number 0
08:03 < 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? 
08:03 < Chris_Stewart_5> but the little script I gave about would evaluate to OP_FALSE then since an empty byte vector != 0 right?
08:03 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-core-dev
08:04 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
08:04 < Chris_Stewart_5> Seems like CScriptNum(OP_0) is a little strange.. surprised that even type checks 
08:08 < sipa> Chris_Stewart_5: "CScriotNum(0) OP_0 OP_EQUAL" has no meaning, i cannot answer your question
08:09 < sipa> CScriotNum(0) is C++
08:09 < sipa> it is not something that makes sense in a bitcoin script
08:11 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev
08:19 < 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
08:23 < 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 
08: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
08:23 < Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L290-L294
08:24 < 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 :-) 
08:26 < sipa> Chris_Stewart_5: in most languages, numbers and byte arrays are different data types, so the question does not even arise
08:27 < sipa> but in Scriot, yes, an empty stack elemented is interpreted as tje number 0, when fed to ancoperator that expects a number
08:27 -!- helloworld [~foobar@181.121.64.244] has joined #bitcoin-core-dev
08:27 -!- helloworld is now known as Guest96777
08:28 < Chris_Stewart_5> Thanks! 
08:28 -!- Guest96777 is now known as electrum_user
08:31 -!- abritoid [~abritoid@46.16.193.99] has quit [Quit: O.o]
08:41 < sipa> there are other valid serializations for 0, though.
08:46 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds]
08:48 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
08:53 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
08:56 < Chris_Stewart_5> sipa: Are you planning on doing something similar to tx_valid/invalid.json as you did with your recent pull request?
08:57 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
08:57 < Chris_Stewart_5> wrt to script_valid/invalid.json
08:58 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 260 seconds]
08:58 -!- zxzzt [~prod@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 248 seconds]
08:59 -!- morcos [~morcos@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 264 seconds]
09:00 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev
09:00 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
09:01 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
09:23 -!- xabbix_ [~xabbix@bzq-109-65-148-44.red.bezeqint.net] has joined #bitcoin-core-dev
09:23 -!- xabbix [~xabbix@unaffiliated/xabbix] has quit [Ping timeout: 260 seconds]
09:25 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
09:40 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
09:56 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
10:05 -!- gevs_ [~greg@ip-81-11-204-20.dsl.scarlet.be] has quit [Quit: bye]
10:05 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
10:50 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
10:55 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
11:15 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 250 seconds]
11:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
11:42 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
11:57 < 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..."
11:58 < 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?
11:59 < sipa> sdaftuar: that would allow you to bypass the rate limiting by continuously requesting mempool
12:00 < gmaxwell> you already bypass the rate limit via the mempool results itself though.
12:00 < sdaftuar> ah
12:00 < sdaftuar> but with my approach, you can learn about more than just 35 transactions or whatever
12:01 < 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. :)
12:01 < sipa> that makes sense
12:05 < sdaftuar> so if we're not concerned about rate limiting being weakened by a mempool-attacker, is there any downside to responding with everything?
12:07 < 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)
12:08 < 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
12:08 < sdaftuar> it's an unlikely edge case regardless
12:08 < gmaxwell> It probably shouldn't relay it.
12:09 < sdaftuar> actually, with the rate limiting, we should probably remove things that are mined or evicted prior to relay, right?
12:09 < sdaftuar> it's conceivable that you could have a big backlog if someone dumped their mempool at you
12:11 < 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
12:11 < gmaxwell> Not a PR yet because I wanted pieter's input before going and ripping out the feerate from the RelayTransaction prototype everywhere.
12:12 < 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.
12:12 < sdaftuar> that seems nice, and makes the code clearer too i suspect
12:13 < sdaftuar> i guess at the expense of slightly more memory, especially for bloom-filtering peers?
12:14 < sdaftuar> i'm not sure i understand the privacy gain though
12:14 < gmaxwell> Very slightly, but it doesn't increase the worst case.
12:14 < sdaftuar> agreed
12:14 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
12:14 < gmaxwell> sdaftuar: without that change, I can rotate my filtering to 'time tag' arrivals. 
12:14 < gmaxwell> So even though the queuing destroys timing information, by modulating my filtering I could restore some of it.
12:15 < sdaftuar> assuming a single peer connection?
12:15 < sdaftuar> or multiple?
12:15 < gmaxwell> If it's done with just a single, it means you'll miss some transactions. More effective with multiple.
12:17 < 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.
12:18 < sdaftuar> ok i think i see what you're talking about, makes sense.
12:20 < 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
12:21 < 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
12:22 < gmaxwell> I'd rather drop stragglers than drain much faster. 
12:22 < sdaftuar> yeah that seems better
12:22 < sdaftuar> otherwise a peer who dumps you garbage ruins relay for everyone...
12:25 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Disconnected by services]
12:29 < 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 
12:29 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
12:29 < gmaxwell> to expire things that sat around too long.
12:29 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:30 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
12:32 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-core-dev
12:41 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:43 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
12:48 < JackH> !seen bramc
12:48 < gribble> I have not seen bramc.
12:53 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
12:57 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
13:09 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
13:09 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Ping timeout: 240 seconds]
13:10 < 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
13:11 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
13:11 -!- Guyver2_ is now known as Guyver2
13:38 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has joined #bitcoin-core-dev
13:49 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
13:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:59 -!- luke-jr_ is now known as Luke-Jr
14:02 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has quit [Read error: Connection reset by peer]
14:02 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has joined #bitcoin-core-dev
14:04 -!- electrum_user [~foobar@181.121.64.244] has quit [Ping timeout: 244 seconds]
14:10 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has quit [Read error: Connection reset by peer]
14:10 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has joined #bitcoin-core-dev
14:11 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has quit [Read error: Connection reset by peer]
14:12 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has joined #bitcoin-core-dev
14:12 < Chris_Stewart_5> Why does the DISCOURAGE_UPGRADABLE_NOPS flag allow a OP_NOP?
14:12 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has quit [Read error: Connection reset by peer]
14:12 < Chris_Stewart_5> i.e. this test case ["1", "NOP", "P2SH,STRICTENC,DISCOURAGE_UPGRADABLE_NOPS", "OK", "Discourage NOPx flag allows OP_NOP"]
14:12 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has joined #bitcoin-core-dev
14:14 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 244 seconds]
14:20 -!- murch [~murch@p4FE3A113.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
14:20 -!- Don_John [~Don@250-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev
14:20 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has quit [Read error: Connection reset by peer]
14:20 -!- Don_John [~Don@250-223-114-134.nat.resnet.nau.edu] has quit [Remote host closed the connection]
14:21 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has joined #bitcoin-core-dev
14:29 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
14:31 < instagibbs> OP_NOP isn't in the set of NOPx
14:31 < instagibbs> although that probably doesn't answer your question
14:32 < instagibbs> OP_NOP is 0x61 while the other NOPS are 0xb0, so they were probably created for different reasons
14:32 < instagibbs> Meaning OP_NOP will probably not be relied on for future softforks, especially if they aren't currently discouraged
14:34 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has quit [Read error: Connection reset by peer]
14:34 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has joined #bitcoin-core-dev
14:51 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
14:53 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
14:56 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has quit [Read error: Connection reset by peer]
14:56 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has joined #bitcoin-core-dev
15:00 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has quit [Read error: Connection reset by peer]
15:01 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has joined #bitcoin-core-dev
15:04 -!- cguida [~chris@162.216.46.73] has quit [Read error: Connection reset by peer]
15:04 -!- cguida_ [~chris@162.216.46.73] has joined #bitcoin-core-dev
15:18 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has quit [Read error: Connection reset by peer]
15:19 -!- muuqwaul [~denetrabu@2601:45:4002:d800:ac02:a891:23ff:d540] has joined #bitcoin-core-dev
15:43 -!- electrumuser [~foobar@181.121.64.244] has joined #bitcoin-core-dev
15:55 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
16:18 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
16:19 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
16:34 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
16:35 -!- cryptapus is now known as cryptapus_afk
17:01 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
17:05 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
17:06 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
17:26 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
17:27 < Chris_Stewart_5> instagibbs: Do you think it could be used to implement some sort of waiting mechanism in a while loop eventually? I get that looping is currently disabled but if it is brought back an OP_NOP could be useful
17:28 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
17:28 < gmaxwell> no.
17:29 < gmaxwell> Chris_Stewart_5: nops were _never_ a 'waiting' mechenism, they were explicitly added for forward extensibility.
17:29 -!- fengling [~fengling@111.198.29.53] has quit [Client Quit]
17:30 < Chris_Stewart_5> gmaxwell: Back to my original question then, why is OP_NOP treated differently than the other OP_NOPs, specifically why is allowed by the DISCOURAGE_UPGRADABLE_NOPS flag? 
17:48 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-dwfrjlwepczyqsqe] has quit []
17:48 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
17:49 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-pebjoozbagdoyfop] has joined #bitcoin-core-dev
17:51 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xbbczlbabvpvxnsh] has quit [Quit: Connection closed for inactivity]
17:59 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton]
18:00 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
18:00 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Client Quit]
18:01 -!- jarret [~jarret@162.216.46.119] has quit [Ping timeout: 240 seconds]
18:02 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
18:03 -!- jarret [~jarret@162.216.46.40] has joined #bitcoin-core-dev
18:26 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
18:27 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:29 -!- xabbix_ [~xabbix@bzq-109-65-148-44.red.bezeqint.net] has quit [Ping timeout: 246 seconds]
18:30 -!- dermoth [~thomas@dsl-66-36-145-24.mtl.aei.ca] has quit [Read error: Connection reset by peer]
18:30 -!- xabbix_ [~xabbix@bzq-109-65-148-44.red.bezeqint.net] has joined #bitcoin-core-dev
18:30 -!- dermoth [~thomas@dsl-66-36-145-24.mtl.aei.ca] has joined #bitcoin-core-dev
18:32 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
18:33 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
18:41 < gmaxwell> Chris_Stewart_5: because there were already people creating them in the network.
19:00 -!- dermoth [~thomas@dsl-66-36-145-24.mtl.aei.ca] has quit [Read error: Connection reset by peer]
19:01 -!- dermoth [~thomas@dsl-66-36-145-24.mtl.aei.ca] has joined #bitcoin-core-dev
19:12 -!- ryan-c [~ryan@srv1.turboslow.net] has quit [Remote host closed the connection]
19:13 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Remote host closed the connection]
19:13 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
19:21 -!- ryan-c [~ryan@srv1.turboslow.net] has joined #bitcoin-core-dev
19:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
19:38 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev
19:47 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 276 seconds]
19:53 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
19:56 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 250 seconds]
20:02 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
20:09 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-core-dev
20:10 -!- ThomasV_ [~ThomasV@x55b63b58.dyn.telefonica.de] has joined #bitcoin-core-dev
20:14 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 244 seconds]
20:49 -!- fanquake [~Adium@unaffiliated/fanquake] has joined #bitcoin-core-dev
20:52 -!- fanquake [~Adium@unaffiliated/fanquake] has quit [Client Quit]
20:52 -!- fanquake [~Adium@unaffiliated/fanquake] has joined #bitcoin-core-dev
20:54 -!- fanquake [~Adium@unaffiliated/fanquake] has quit [Client Quit]
20:55 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
21:01 -!- jack [423ccfa7@gateway/web/freenode/ip.66.60.207.167] has joined #bitcoin-core-dev
21:02 -!- jack is now known as Guest2012
21:14 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 276 seconds]
22:11 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
22:19 < Guest2012> d
22:20 -!- Guest2012 [423ccfa7@gateway/web/freenode/ip.66.60.207.167] has quit [Quit: Page closed]
22:26 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
23:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:08 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:25 < GitHub99> [bitcoin] rustyrussell opened pull request #7863: getblockchaininfo: make bip9_softforks an object, not an array. (master...bip9-status-as-object) https://github.com/bitcoin/bitcoin/pull/7863
23:25 -!- goregrin1 [~goregrind@unaffiliated/goregrind] has joined #bitcoin-core-dev
23:26 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
23:27 -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Ping timeout: 260 seconds]
23:31 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jkjxatlnfrmusqyi] has joined #bitcoin-core-dev
23:44 -!- ThomasV_ [~ThomasV@x55b63b58.dyn.telefonica.de] has quit [Quit: Quitte]