--- Day changed Mon Nov 23 2015
00:26 < aj> midnightmagic: you can get the same behaviour in C with struct A { int a; } struct B { struct A a; int b; } and go(&bs[0].a); though it's a bit more obvious what you're doing wrong there...
00:32 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 250 seconds]
00:37 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 272 seconds]
00:38 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-core-dev
00:50 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
01:04 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has joined #bitcoin-core-dev
01:10 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:29 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
01:32 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 252 seconds]
01:49 -!- guest234234 [~guest2342@171.4.239.150] has quit [Ping timeout: 260 seconds]
01:53 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
01:57 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 252 seconds]
01:58 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-core-dev
02:07 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
02:07 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
02:09 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
02:09 -!- tripleslash_h [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
02:11 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds]
02:14 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-foyoqgexffbovcym] has joined #bitcoin-core-dev
02:16 -!- tripleslash_h [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 252 seconds]
02:34 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
02:38 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 260 seconds]
02:43 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
03:08 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
03:27 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection]
03:28 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
03:28 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Client Quit]
03:29 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
03:47 -!- guest234234 [~guest2342@171.4.239.150] has joined #bitcoin-core-dev
03:55 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 272 seconds]
03:59 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
04:04 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 260 seconds]
04:12 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
04:26 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
04:27 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
04:29 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds]
04:35 -!- Jetflame [~flame@162.216.46.12] has joined #bitcoin-core-dev
04:41 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
04:42 -!- Jetflame [~flame@162.216.46.12] has quit [Quit: Leaving]
04:46 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds]
04:46 -!- tripleslash_d [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
04:49 -!- Guest32712 is now known as pigeons
04:51 -!- tripleslash_d [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 252 seconds]
04:53 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
04:53 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
05:03 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: Lost terminal]
05:18 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev
05:18 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 252 seconds]
05:28 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 255 seconds]
05:29 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
05:53 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
06:02 -!- guest234234 [~guest2342@171.4.239.150] has quit [Ping timeout: 250 seconds]
06:10 -!- tulip [~tulip@unaffiliated/tulip] has quit [Ping timeout: 240 seconds]
06:16 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds]
06:19 -!- treehug8_ [~textual@cpe-74-66-7-27.nyc.res.rr.com] has joined #bitcoin-core-dev
06:20 -!- treehug8_ [~textual@cpe-74-66-7-27.nyc.res.rr.com] has quit [Client Quit]
06:22 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
06:23 -!- adam3us [~Adium@c-98-234-64-218.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
06:55 -!- ParadoxSpiral [~ParadoxSp@p508B9574.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
07:53 -!- adam3us [~Adium@c-98-234-64-218.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
07:57 -!- zookolaptop [~user@2601:281:8001:26aa:ac94:e5d8:45fe:a98e] has joined #bitcoin-core-dev
08:02 -!- skyraider [uid41097@gateway/web/irccloud.com/x-kwgpgojvpnpfzxyd] has joined #bitcoin-core-dev
08:21 < sdaftuar_> sipa: i think i'm going to rework the direct fetch logic in 6494...  not sure how i missed this before but i realized this morning (while trying to fix a different issue) that limiting direct fetch to the blocks announced in a headers message is a bit broken
08:22 < sdaftuar_> really we want to direct fetch all the blocks that lead to the tip (even if we already had an intermediate header, and hence it wasn't announced to us)
08:22 -!- sdaftuar_ is now known as sdaftuar
08:24 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
08:24 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
08:24 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
08:39 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
08:41 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
08:56 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
09:01 -!- adam3us [~Adium@c-98-234-64-218.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
09:04 < bsm1175321> BlueMatt that sucks.  It's because sizeof(A) = 4 and sizeof(B) = 8.
09:07 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
09:07 < sipa> BlueMatt: in function prototypes, [] reduces to *, so your function is accepring a pointer to A :)
09:08 < sipa> (though a warning would be appropriate, even if it's strictly allowed)
09:08 < bsm1175321> I agree a warning would be appropriate.  It's just mean.
09:08 < sipa> they have other "helpful" warnings anyway for perfectly legal things, like not using the result of a comparison, or ambiguous parenthesis
09:33 -!- adam3us [~Adium@c-98-234-64-218.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
09:45 -!- ParadoxSpiral_ [~ParadoxSp@p508B90DC.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
09:48 -!- ParadoxSpiral [~ParadoxSp@p508B9574.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
09:51 -!- adam3us [~Adium@c-98-234-64-218.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
09:57 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds]
10:01 -!- adam3us [~Adium@c-98-234-64-218.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
10:02 -!- adam3us [~Adium@c-98-234-64-218.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
10:02 -!- rubensayshi [~ruben@91.206.81.13] has quit [Remote host closed the connection]
10:05 < GitHub151> [bitcoin] MarcoFalke opened pull request #7083: [init] Print OpenSSL version fix (master...MarcoFalke-2015-initOpenSSL) https://github.com/bitcoin/bitcoin/pull/7083
10:05 -!- adam3us [~Adium@c-98-234-64-218.hsd1.ca.comcast.net] has quit [Client Quit]
10:06 -!- MarcoFalke [50edea84@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.234.132] has joined #bitcoin-core-dev
10:14 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
10:16 -!- adam3us [~Adium@c-24-4-96-213.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
11:15 < sdaftuar> sipa: it looks like the parallel fetch logic causes a node to download towards a tip that has the same work as chainActive.Tip(), can you confirm that is correct and intentional?
11:17 < sdaftuar> i had written the direct fetch logic to only fetch towards a tip that had more work than chainActive.Tip(); i assume i should change it to match what's happening in FindNextBlocksToDownload
11:21 -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Changing host]
11:21 -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has joined #bitcoin-core-dev
11:22 < sipa> sdaftuar: it's intentional, but you're making me question the reason behind it
11:22 < sdaftuar> sipa: well i don't think it's crazy to download it -- seems like it would help reorgs propagate faster between peers on different forks
11:23 < sipa> sdaftuar: it is ppssible that we already have the tip, and in fact had it earlier than the tip we are currently at; if we fetch the blocks in between, we should switch to it
11:23 < sdaftuar> ah good point
11:24 < sdaftuar> oh
11:24 < sdaftuar> no i think that's incorrect
11:24 < sipa> that is testable, though
11:24 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-foyoqgexffbovcym] has quit [Quit: Connection closed for inactivity]
11:24 < sdaftuar> we shouldn't and don't prefer a block unless it and all parents arrived first
11:25 < sipa> i think you're right that we shouldn't
11:25 < sipa> but i think we do
11:25 < sdaftuar> #6010
11:25 < sdaftuar> we fixed this earlier this year
11:25 < sipa> we only compare the tips nSequence
11:25 < sipa> oh, ok!
11:25 < BlueMatt> sipa: yea, I knew it wouldnt work when I wrote it, I was just writing code and was like "oh i should...wait, no, that cant work....I wonder if that even compiles...wait, no warning?!"
11:26 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
11:26 < sipa> BlueMatt: fair reaction
11:26 < sdaftuar> i think i'll just make the direct fetch logic mirror the existing behavior in FindNextBlocksToDownload...
11:27 < sipa> sdaftuar: ack
11:27 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
11:28 < gmaxwell> BlueMatt: ping on PR 6915
11:36 < GitHub164> [bitcoin] MarcoFalke opened pull request #7084: mempool: Replace maxFeeRate of 10000*minRelayTxFee with maxTxFee (master...MarcoFalke-2015-mempoolMaxTxFee) https://github.com/bitcoin/bitcoin/pull/7084
11:40 < MarcoFalke> sdaftuar, Do you plan to address the nit in 7063?
11:41 < MarcoFalke> The code looks clean so you get my ACK anyway, just asking.
11:43 < sdaftuar> MarcoFalke: i was going to look at it again next week if it wasn't merged by then!  trying to get the other PRs tagged for 0.12 ready before the feature freeze
11:45 < sdaftuar> sipa: i'm going to push updates to 6494.  i had to rework the direct fetch logic somewhat substantially :(  would you prefer to see the original commit you already reviewed, or should i squash down now?
12:00 < sipa> sdaftuar: feel free to squash
12:05 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Ping timeout: 240 seconds]
12:06 -!- aj [aj@cerulean.erisian.com.au] has quit [Ping timeout: 260 seconds]
12:06 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Ping timeout: 272 seconds]
12:08 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
12:20 -!- MarcoFalke [50edea84@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.234.132] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
12:20 -!- MarcoFalke [50edea84@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.234.132] has joined #bitcoin-core-dev
12:22 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
12:24 -!- MarcoFalke [50edea84@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.234.132] has quit [Client Quit]
12:26 -!- MarcoFalke [50edea84@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.234.132] has joined #bitcoin-core-dev
12:45 -!- lightningbot [lightningb@cerulean.erisian.com.au] has joined #bitcoin-core-dev
12:47 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev
12:48 -!- aj_ [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev
12:48 -!- aj_ is now known as aj
12:49 -!- aj [aj@cerulean.erisian.com.au] has quit [Client Quit]
12:49 -!- aj [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev
12:50 < sdaftuar> sipa: thanks, done
12:53 < sdaftuar> BlueMatt: regarding #6915, do you think we should just repeat the logic that's in CheckFinalTx each place we invoke mempool.removeForReorg():
12:54 < sdaftuar>     const int64_t nBlockTime = (flags & LOCKTIME_MEDIAN_TIME_PAST)
12:54 < sdaftuar>                              ? chainActive.Tip()->GetMedianTimePast()
12:54 < sdaftuar>                              : GetAdjustedTime();
13:03 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
13:04 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
13:08 < sdaftuar> that seems not so bad, just tried it out and replaced the last commit in #6915 with one that does this instead.
13:13 -!- d4de [~d4de@41.234.215.214] has joined #bitcoin-core-dev
13:24 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
13:25 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 244 seconds]
13:53 -!- aj [aj@cerulean.erisian.com.au] has quit [Ping timeout: 250 seconds]
13:53 -!- lightningbot [lightningb@cerulean.erisian.com.au] has quit [Ping timeout: 265 seconds]
13:54 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Ping timeout: 260 seconds]
13:58 -!- MarcoFalke [50edea84@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.234.132] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
13:59 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Quit: .]
14:00 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
14:05 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
14:10 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
14:15 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-znvpjmnfafvrgwbo] has joined #bitcoin-core-dev
14:19 -!- go1111111 [~go1111111@104.200.154.92] has quit [Ping timeout: 240 seconds]
14:24 -!- adam3us [~Adium@c-24-4-96-213.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
14:35 -!- go1111111 [~go1111111@162.244.138.37] has joined #bitcoin-core-dev
14:36 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev
14:44 -!- aj [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev
14:44 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
14:58 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
15:08 -!- ParadoxSpiral_ [~ParadoxSp@p508B90DC.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
15:12 -!- guest234234 [~guest2342@171.4.239.150] has joined #bitcoin-core-dev
15:14 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-core-dev
15:16 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
15:17 < BlueMatt> sdaftuar: wait, I'm confused...this doesnt seem right
15:17 < BlueMatt> sdaftuar: the rule is block-time-cannot-go-back-from-MTP
15:17 < BlueMatt> sdaftuar: so the rule for mempool removal should be max(GMTP(), GetAdjustedTime())
15:21 < BlueMatt> oops, nvm
15:23 < BlueMatt> anyway, I'd prefer to not duplicate the code....can we pull that out into a function?
15:23 < BlueMatt> but, yea, i like that better
15:23  * BlueMatt -> lunch
15:57 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev
16:09 < gmaxwell> sipa: do you have any thoughts about where in the block acceptance plumbing it it would be best to extract a "most recent time Peer X gave us an accepted block"?  As I'm doing for transactions in #7082 ?
16:10 -!- Guest23423 [~guest2342@223.207.203.72] has joined #bitcoin-core-dev
16:13 -!- guest234234 [~guest2342@171.4.239.150] has quit [Ping timeout: 244 seconds]
16:23 -!- Guest23423 [~guest2342@223.207.203.72] has quit [Read error: Connection reset by peer]
16:32 -!- skyraider [uid41097@gateway/web/irccloud.com/x-kwgpgojvpnpfzxyd] has quit [Quit: Connection closed for inactivity]
17:14 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-znvpjmnfafvrgwbo] has quit [Quit: Connection closed for inactivity]
17:17 -!- guest234234 [~guest2342@223.207.237.177] has joined #bitcoin-core-dev
17:29 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has quit [Ping timeout: 250 seconds]
17:42 -!- parazyd [parazyd@gateway/shell/firrre/x-byqgwelkqeyxupry] has left #bitcoin-core-dev ["Leaving"]
18:48 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
18:48 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
19:07 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Ping timeout: 260 seconds]
19:07 -!- jl2012_ [~jl2012@pn-204-72.itsc.cuhk.edu.hk] has joined #bitcoin-core-dev
19:08 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
19:16 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
19:16 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
19:24 -!- go1111111 [~go1111111@162.244.138.37] has quit [Ping timeout: 246 seconds]
19:38 -!- go1111111 [~go1111111@104.200.154.31] has joined #bitcoin-core-dev
20:34 < gmaxwell> Anyone else seeing connections from 54.210.68.46 multiple times to your nodes, sitting running the mempool command as fast as its little feet will go?
20:35 < jgarzik> I've been inclined to disable mempool by default for months
20:35 < gmaxwell> I've banned this particular nussance several times, on several nodes in the past. And now it seems to be changing IPs and behaviors to avoid being banned.
20:36 < gmaxwell> If it's also spamming you, feel free to report to https://aws.amazon.com/forms/report-abuse  
20:36 < gmaxwell> jgarzik: I think we should probably only let one request per peer per block, and only return the top couple blocks worth of mempool.
20:38 < tulip> gmaxwell: yes, multiple connections announced as /btcwire:0.2.0/. 
20:38 < gmaxwell> tulip: yea, I have one node with four, one with two, one with one.
20:38 < gmaxwell> I haven't checked the others yet.
20:38 < jgarzik> gmaxwell, That's reasonable - though I really don't see much use of it.  It occasionally gets used for diagnostics or by miners - though the fingerprint/analysis people will probably use it soon if not already.
20:40 < tulip> as much as I'd like to see it gone, people will probably turn to inventory hammering to learn memory pool contents :(
20:41 < gmaxwell> most of the stuff related to the anti-fungibility/anti-privacy attacks would be more completely addressed by fixing announcement so that sybil/etc. attacking the network doesn't teach you anything interesting.
20:42 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Remote host closed the connection]
20:42 < gmaxwell> tulip: good point.  Yea, so long as there is a strong incentive to abusively data mine the network; people will do so.
20:43 < tulip> on second thought, it's probably just an incentive to stay connected to every peer permanently. 
20:43 < gmaxwell> tulip: they'd use a lot less bandwidth that way.
20:44 < gmaxwell> I mean this current mempool sucker is using 10x the bandwidth of any of my other peers.
20:45 < jgarzik> We already account traffic up & down.  You'd think this could be dealt with through generic resource accounting.
20:45 < tulip> modified clarks law: any sufficiently buggy software is indistinguishable from denial of service. 
20:47 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 272 seconds]
20:47 < gmaxwell> tulip: yea, my amazon report said that since it doesn't have a webpage or any other contact information I can't determine if its buggy or malicious.
20:48 < phantomcircuit> jgarzik, i assume that the mempool infinite loop is some kind of poorly thought out sybil attack
20:48 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
20:49 < jgarzik> phantomcircuit, plain ole asymmetric DoS
20:49 < phantomcircuit> jgarzik, responding to the mempool command is actually very cheap though
20:49 < gmaxwell> well they have to recieve the response but bandwidth is differentially valuable to them and me. :)
20:50 < phantomcircuit> both ends have equal bandwidth cost
20:50 < phantomcircuit> hmm true
20:50 < phantomcircuit> asymetric bandwidth value
20:50 < gmaxwell> phantomcircuit: I (and my partner) beg to differ!
20:50 < phantomcircuit> fyi btcwire is btcd
20:50 < gmaxwell> but I dunno that it's intentional, could just be some really ill advised anti-privacy attack, trying to bypass trickling by yanking the mempool super fast.
20:51 < jgarzik> might just be "real time network scope"
20:51 < gmaxwell> phantomcircuit: this isn't btcd; all the behavior is goofy, it's just someone using their p2p implementation.
20:51 < jgarzik> a new product
20:51 < phantomcircuit> ah
20:51 < tulip> nodes running on ADSL connections have a heavy impact from uploads, you could probably slow down most of those nodes downloading blocks by just requesting them to send you a few and ruining their ACK speed. 
20:51 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [K-Lined]
20:51 < phantomcircuit> jgarzik, ?
20:51 < tulip> requesting they send you a few blocks.
20:51 < jgarzik> phantomcircuit, speculating
20:52 < jgarzik> phantomcircuit, conceivably it's someone testing a new product that monitors mempools across the network in real time
20:52 < gmaxwell> tulip: one evidence that it could be an attack is that I _believe_ the same party (amazon, btcwire) used to be requesting a single big over and over again in a loop.
20:52 < phantomcircuit> jgarzik, if so they're doing a shit job of it
20:52 < phantomcircuit> the mempool command adds enough latency that it would actually damage their measurements
20:52 < tulip> jgarzik: if they wanted to do that, why are they using multiple connections, and why request with mempool when you can see inv messages in real time?
20:53 < gmaxwell> I don't know if the block looper stopped generally, becuase jonas' bandwidth limiter kills them. :)
20:53 < gmaxwell> (as the block they were requesting was months old)
20:53 < jgarzik> tulip, 'mempool' shows you when transactions leave the mempool too...
20:54 < phantomcircuit> jgarzik, that doesn't tell you much of anything though
20:54 < jgarzik> we're all guessing, who knows
20:54 < tulip> sure.
20:54 < phantomcircuit> im thinking gmaxwell is right and it's just an attack
20:54 < gmaxwell> maybe my abuse report will result in hearing something. 
20:54 < jgarzik> I think it's a DoS attack
20:54 < gmaxwell> I could certantly see this as a misguided monitoring attempt. But regardless, the motivations aren't that important.
20:54 < jgarzik> but it's a useful exercise to try and figure out weird, unlikely attacks ;p
20:55 < gmaxwell> I think before this discussion I hadn't connected that mempool bypasses trickling... good thing to figure that out.
20:55 < davec> fwiw, 0.2.0 is months old too, so it's likely whoever is up to it has been at it for a while
20:55 < gmaxwell> yet another gaping privacy hole we added to the protocol. :(
20:56 < gmaxwell> davec: yea, I've seen it before; it's bubbled up to the level of complaining about it here because it has persisted and changed addresses.
20:59 < tulip> jgarzik: you're the BIP author by the looks of things, would you have any qualms about removing it completely? do you know of any software which makes use of it? 
21:00 < gmaxwell> tulip: or made whitelisted peers only, perhaps?
21:00 < tulip> that sounds like a better option. 
21:01 < gmaxwell> bluematt: does the relay node client use the mempool message?
21:01  * gmaxwell greps logs
21:01 < jgarzik> tulip, scroll up ;p
21:02 < tulip> jgarzik: whoops, missed the first assertion for removal, sorry. 
21:02 < phantomcircuit> gmaxwell, it does but i cant remember how
21:03 < tulip> wouldn't the relay node be on a whitelisted port anyway? 
21:03 < davec> doesn't the testing framework use it?
21:04 -!- raskolnnikov [~raskolnni@181.194.130.224] has joined #bitcoin-core-dev
21:04 < davec> (mempool that is).  It's been a while, but I seem to recall it being used by the block tester tool to compare mempool contents
21:04 < gmaxwell> it really shouldn't, we've complained about that before.
21:04 < gmaxwell> maybe it got fixed. :P
21:04 < gmaxwell> otherwise I dunno why all the recent mempool changes didn't make it fail all over itself.
21:04 < jgarzik> rpc-tests uses getrawmempool
21:06 < gmaxwell> my log data suggests that it's being used once per connection by some wallet or something.
21:06 < gmaxwell> hm. maybe.
21:07 < gmaxwell> http://0bin.net/paste/WPN3p8EyTg5QiXwe#oc16NOdpqju3WllP7+4FO4tbcphIwDQN5ZqHBv8bOux 
21:08 < tulip> total count in the left column? 
21:09 < gmaxwell> actually no, most of those are "/bitcoin-seeder:0.01/" "/Snoopy:0.2.1/"
21:09 < gmaxwell> ah so spv clients are doing a 
21:09 < gmaxwell> 2015-11-24 02:17:45 received: filterload (1923 bytes) peer=4177
21:09 < gmaxwell> 2015-11-24 02:17:45 received: mempool (0 bytes) peer=4177
21:09 < gmaxwell> "/bitcoinj:0.13.2/MultiBitHD:0.1.4/"
21:09 < gmaxwell> but most of this stuff is ... things which are, uh, not in my interest to serve these responses to.
21:10 < tulip> bitcoin seeder does a mempool request? surely not 
21:10 < gmaxwell> something claiming to be it does.
21:10 < tulip> yep.
21:11 < gmaxwell> anyways, if we don't kill it completely we should cap its size and find a way to fix the privacy leak. :(
21:11 < raskolnnikov> hello guys, I'm beginning work on a small research about SPV's transaction validation. Anyone has some 10 mins available to discuss a bit, I'm fairly lost inside the core src...
21:12 < gmaxwell> raskolnnikov: norm on IRC is to ask your question and pray for a response. :)
21:12 < davec> there is a definitely at least one bogus client out there claiming to be bitcoin-seeder
21:12 < tulip> there's lots claiming to be satoshi as well. 
21:13 < gmaxwell> raskolnnikov: (and wait around long enough so people who aren't actively paying attention can answer)
21:13 < davec> I have noticed it not following the protocol
21:14 < gmaxwell> tulip: dunno who these things think they're fooling.  "/Satoshi:0.10.2/" ... "why are you sending me filterloads?" 
21:14 < gmaxwell> I like the ones that are copy and paste errors.
21:14 < raskolnnikov> ha, I'm fairly new to IRC!
21:14 < raskolnnikov> thanks!
21:14 < davec> Yeah that's are funny
21:14 < gmaxwell> "Satoshi:0.11.1/"
21:15 < davec> those*
21:15 < davec> I saw a few misspelled ones too
21:15 < gmaxwell> davec: I'm amagining a person with a nose-and-glasses setup.
21:16 < tulip> they're easy enough to detect, but even easier to evade again.
21:16 < raskolnnikov> SPV's wallets provide a txn hash to full nodes whenever they want to verify if the transaction exists on a previous block and is unspent. where in the SRC code does bitcoin-core process and replies to these kind of requests?
21:17 < raskolnnikov> I'd like to log these requests from a test network to a log file
21:18 < gmaxwell> raskolnnikov: ah, you can't find that because that isn't how SPV wallets work.
21:19 < gmaxwell> raskolnnikov: if someone were to give you a transaction, they could also give you the proof that it was in a block.  So there is currently no facility in the protocol to just extract a proof for an arbritary transaction. (among other things this would require an index of all transactions, which bitcoin full nodes do not usually have)
21:21 < gmaxwell> raskolnnikov: instead you can download a block and filter the download to particular transactions or addresses, see MSG_FILTERED_BLOCK in the bitcoin core source code
21:21 < raskolnnikov> so there only is a request for the particular block (which I assume is extracted from some sort of block header, in the proof provided to the wallet) from the SPV to the full node
21:21 < raskolnnikov> and then the full node only provides the requested block back to the SPV?
21:22 < davec> a merkleblock (which is a filtered version) yes
21:22 < gmaxwell> raskolnnikov: it does not necessarily provide the whole block, the block can be filtered in way that proves the filtered subset is in there. See BIP37.
21:23 < gmaxwell> The gettxoutproof RPC in bitcoin core also provides an eqivilent message over the RPC.
21:24 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
21:26 < raskolnnikov> and is there a way to single out the requests that come from SPV wallets? cause I assume that other full nodes will be requesting blocks or filtered blocks as well...
21:26 < raskolnnikov> cause those are the one I'd like to put on a log
21:26 < tulip> why?
21:26 < raskolnnikov> I'd like to measure the impact of having modified full nodes
21:27 < raskolnnikov> which "lie" back to the SPV wallet
21:28 < tulip> do you realise that BIP37 only allows lying by omission in most circumstances? 
21:29 < gmaxwell> raskolnnikov: full nodes can freely omit transactions, thats one of the limitations in the design of BIP37.  There are other schemes which lack that limitation which are possible but have not been implemented yet.
21:30 < gmaxwell> raskolnnikov: as to your question, only SPV clients currently fetch filtered blocks.
21:33 -!- tulip [~tulip@unaffiliated/tulip] has quit [Remote host closed the connection]
21:33 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-core-dev
21:41 < BlueMatt> gmaxwell: nope
21:42 < BlueMatt> gmaxwell: https://github.com/TheBlueMatt/RelayNode/issues/11
21:42 < BlueMatt> gmaxwell: there is even a whole rpcclient class thinggy that could be used
21:48 < gmaxwell> ::sigh:: seems like my laptop has a spurrious warning on mainnet:   "errors": "WARNING: check your network connection, 3 blocks received in the last 4 hours (24 expected)"
21:50 < gmaxwell> Anyone have a recent-ish count of how many distinct scriptpubkeys there are in the txout set?
21:51 < CodeShark> I used to keep a database of that but haven't been tracking that in a while
22:05 < GitHub82> [bitcoin] pstratem opened pull request #7087: [Net][WIP]Add -enforcenodebloom option (master...2015-11-23-bloom-disable) https://github.com/bitcoin/bitcoin/pull/7087
22:06 -!- pigeons [~pigeons@94.242.209.214] has quit [Ping timeout: 246 seconds]
22:07 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 260 seconds]
22:07 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev
22:08 -!- pigeons is now known as Guest1328
22:53 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
22:53 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
22:56 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
22:59 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 276 seconds]
23:01 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
23:04 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 276 seconds]
23:14 -!- guest234234 [~guest2342@223.207.237.177] has quit [Ping timeout: 255 seconds]
23:15 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
23:42 < GitHub191> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0b0fc179ab87...f91e29fd4d0e
23:42 < GitHub191> bitcoin/master 3522f49 Wladimir J. van der Laan: http: add Boost 1.49 compatibility...
23:42 < GitHub191> bitcoin/master f91e29f Wladimir J. van der Laan: Merge pull request #7065...
23:42 < GitHub27> [bitcoin] laanwj closed pull request #7065: http: add Boost 1.49 compatibility (master...2015_11_httpserver_boost1_49) https://github.com/bitcoin/bitcoin/pull/7065
23:43 -!- pkthebud [uid128839@gateway/web/irccloud.com/x-ylfluwupmuombxbu] has joined #bitcoin-core-dev
23:44 < pkthebud> Hello 😃
23:51 -!- MarcoFalke [3e4bef15@gateway/web/cgi-irc/kiwiirc.com/ip.62.75.239.21] has joined #bitcoin-core-dev
23:53 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zowntxnmndwnhcxr] has joined #bitcoin-core-dev
23:55 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev