--- Day changed Wed Nov 23 2016
00:04 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Quit: ZNC - http://znc.in]     
00:12 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev     
00:21 < jonasschnelli> luke-jr: If I call invalidateblock(d) on a-b-c-d-e, the tip will chain will result in a-b-c
00:21 < luke-jr> jonasschnelli: it shouldn't be, if there is an alternate chain a-b-c-x
00:23 < luke-jr> to test, send a-b-c-x then reorg to -d-e then invalidate d
00:29 < BlueMatt> wumpus: might want to cancel meeting on thursday in light of american thanksgiving
00:30 < wumpus> BlueMatt: good point
00:30 < BlueMatt> wumpus: also, before you get too excited about #9128, I think sipa, cfields and I need to get togehter (or at a meeting) and figure out what we want to do about where-messages-get-hashed
00:30 < gribble> https://github.com/bitcoin/bitcoin/issues/9128 | net: Decouple CConnman and message serialization by theuni · Pull Request #9128 · bitcoin/bitcoin · GitHub
00:32 < wumpus> BlueMatt: cfields could we possibly factor out the controversial part into a seperate pull?
00:32 < BlueMatt> wumpus: I think we just need to find a few minutes to discuss when we're all here...it should be easy to come to agreement (hence why i came to the conclusion that this week's meeting wont work :( )
00:32 < wumpus> most of the changes are no-brainers w/ regard to desirability
00:33 < BlueMatt> yea     
00:33 < wumpus> but sure we can hold off on that one until you discussed
00:34 < BlueMatt> wumpus: I keep remembering after cfields goes to sleep :(
00:34 < gmaxwell> wumpus: ACK re-pings. I have seen some sit ready for a while and didn't want to nag.
00:34 < jonasschnelli> luke-jr: I think that would be a general improvement in InvalidateBlock ... 
00:38 < jonasschnelli> luke-jr: heh, InvalidateBlock(getbestblockhash()) on a fresh regtest setup (no block mined) results in a funny state
00:38 < luke-jr> does it really not work? :O
00:39 < jonasschnelli> It disconnects the genesis block but missed the undo-data
00:39 < jonasschnelli> generate 1 will fail afterwards
00:39 < luke-jr> no, I mean a-b-c-x
00:39  * jonasschnelli testing
00:40 < luke-jr> I mean, it's rare you'd want to invalidate the tip without a competing chain to reorg to
00:40 < jonasschnelli> I think InvalidateBlock is only used during RegTests/RPC tests... are there real world mainnet usecases?
00:40 < BlueMatt> so I could PR relay-compact-block-before-full-validation (https://github.com/TheBlueMatt/bitcoin/commits/2016-11-compact-fast-relay) but now I'm kinda thinking I dont want to do that prior to there being multithreaded ProcessMessages with some smarts to respond to getblocktxn without a lock for the latest block...thoughts?
00:40 < BlueMatt> (maybe gmaxwell)
00:40 < luke-jr> it was added so a fiasco like 0.8.0 could be manually dealt with
00:41 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-tnmqvwbsllijytjr] has quit [Quit: Connection closed for inactivity]     
00:46 < jonasschnelli> luke-jr: generating a-b-c-d-e, invalidating e, mining -d-x-y, reconsidering e, invalidate x results in a-b-c-d
00:46 < jonasschnelli> So reorg with InvalidateBlock seems to work
00:46 < jonasschnelli> Maybe the pprev call is not ideal
00:47 < luke-jr> that sequence doesn't make sense. you mined d twice?
00:47 < luke-jr> if a-b-c-d-e is valid, tip should never be D
00:48 < jonasschnelli> I invalidated e
00:48 < luke-jr> but then reconsidered it
00:48 < luke-jr> which should make it valid
00:48 < jonasschnelli> wait... let me write it again
00:49 < jonasschnelli> generating a-b-c-d-e, invalidating e, mining (-d)-x-y, reconsidering e, invalidate x results in a-b-c-d-e
00:50 < luke-jr> ok, good; but does this call NotifyTip with D or E?
00:50 < jonasschnelli> I'm checking now the signal... maybe its wrong.
00:50 < luke-jr> it should only call NotifyTip with E I think, but certainly both and E last
00:50 < luke-jr> err, certainly E last*
00:50 < luke-jr> (whether it calls it with D before E is a debatable question)
00:53 < gmaxwell> BlueMatt: I think it's fine to send it first without fancy getblocktxn handling. Most blocks relay without a getblocktxn.
00:54 < gmaxwell> BlueMatt: on the balance for both bandwidth usage and latency handling using the orphan pool and having an eviction pool be more important that faster getblocktxn handling.
00:56 < gmaxwell> BlueMatt: I think sipa and I convinced cfields that what you were doing was reasonable.
00:59 < gmaxwell> luke-jr: jonasschnelli: I'd be really surprised if notify behavior was sensible around invalidate block, it's a hidden and undocumented command intenteded for development and for fringe emergencies. (Though I'd certantly support making it more sensible-- AFAIK it really hasn't been tested to the level that I'd expect for a first tier user feature).
00:59 < gmaxwell> It also is massively slow at undoing blocks, enough to degrade its utility.
00:59 < luke-jr> gmaxwell: jonasschnelli just "fixed" it, but I think the fix is wrong
01:00 < jonasschnelli> luke-jr: I don't fixed it,... I merged a fix. :)
01:00 < jonasschnelli> But I guess luke-jr is right... it could be wrong.
01:01 < jonasschnelli> But my test just showed me, the signal gets called with the reconnected blocks.. so the UI state is correct... but looking deeper into it now
01:02 < gmaxwell> One challenge is that invalidateblock can cause a best block tip with lower work than the best signaled previously. There is no other way for that to happen in the codebase, so in that sense it breaks an interface invarient.
01:03 < luke-jr> well, at least that case is GIGO
01:03 < jonasschnelli> luke-jr: I think the change is correct
01:03 < gmaxwell> true. :)
01:04 < jonasschnelli> pprev = chainActive.Tip()
01:04 < jonasschnelli> And in the RPC call InvalidateBlock, we have a call ActivateBestChain(state, Params(), NULL);
01:05 < jonasschnelli> Which calls the signal again with the new tip
01:05 < jonasschnelli> so.. all good IMO
01:06 < luke-jr> ah, so the internal InvalidateBlock doesn't complete the reorg(s), and the RPC does that in a subsequent step?
01:06 < jonasschnelli> Yes     
01:06 -!- berndj [~berndj@mail.azna.co.za] has quit [Ping timeout: 252 seconds]     
01:06 < luke-jr> I guess that makes sense. Maybe better to change it, but outside the scope of this.
01:16 -!- JackH [~laptop@79-73-184-38.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
01:16 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
01:21 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
01:23 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev     
01:37 -!- laurentmt [~Thunderbi@80.215.210.20] has joined #bitcoin-core-dev     
01:56 -!- laurentmt [~Thunderbi@80.215.210.20] has quit [Quit: laurentmt]     
01:58 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
01:58 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Disconnected by services]     
01:58 -!- Victor_sueca is now known as Victorsueca     
02:02 -!- z3ustb [d390015b@gateway/web/freenode/ip.211.144.1.91] has joined #bitcoin-core-dev     
02:06 -!- z3ustb [d390015b@gateway/web/freenode/ip.211.144.1.91] has quit [Client Quit]     
02:08 -!- laurentmt [~Thunderbi@80.215.210.20] has joined #bitcoin-core-dev     
02:09 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
02:11 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/74ced54b7e7b...fa1f944107f9
02:11 < bitcoin-git> bitcoin/master 69bc8e7 Amir Abrams: [Doc] Move comments above bash command
02:11 < bitcoin-git> bitcoin/master fa1f944 Wladimir J. van der Laan: Merge #9207: [Doc] Move comments above bash command in build-unix...
02:11 < bitcoin-git> [bitcoin] laanwj closed pull request #9207: [Doc] Move comments above bash command in build-unix (master...patch-2) https://github.com/bitcoin/bitcoin/pull/9207
02:20 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev     
02:20 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host]     
02:20 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:27 -!- laurentmt [~Thunderbi@80.215.210.20] has quit [Read error: Connection reset by peer]     
02:28 -!- laurentmt [~Thunderbi@80.215.210.20] has joined #bitcoin-core-dev     
02:36 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
02:39 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
02:41 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fa1f944107f9...e662d281b837
02:41 < bitcoin-git> bitcoin/master 09dc406 BtcDrak: Make test constant consistent with consensus.h
02:41 < bitcoin-git> bitcoin/master e662d28 MarcoFalke: Merge #9206: Make test constant consistent with consensus.h...
02:41 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9206: Make test constant consistent with consensus.h (master...consistency) https://github.com/bitcoin/bitcoin/pull/9206
02:42 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit []     
02:42 < bitcoin-git> [bitcoin] sdaftuar opened pull request #9208: [WIP] Improve DisconnectTip performance (master...faster-disconnect-rebased) https://github.com/bitcoin/bitcoin/pull/9208
02:42 < sdaftuar> gmaxwell: ^ This should fix the invalidateblock performance issues
03:00 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 250 seconds]     
03:04 -!- laurentmt [~Thunderbi@80.215.210.20] has quit [Quit: laurentmt]     
03:08 -!- wvr [~wvr@21.red-83-32-74.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
03:20 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
03:51 -!- jujumax [~jujumax@host250.190-137-164.telecom.net.ar] has joined #bitcoin-core-dev     
03:57 -!- brhood9 [6b4debe5@gateway/web/freenode/ip.107.77.235.229] has joined #bitcoin-core-dev     
03:58 < brhood9> is anyone there? I need help please and I'm willing to pay.
04:01 < Victorsueca> brhood9: what with?
04:01 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9139: Change sync_blocks to pick smarter maxheight (on top of #9196) (master...sync-height) https://github.com/bitcoin/bitcoin/pull/9139
04:02 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e662d281b837...0de7fd36de57
04:02 < bitcoin-git> bitcoin/master 1126c85 Russell Yanofsky: [qa] Change sync_blocks to pick smarter maxheight...
04:02 < bitcoin-git> bitcoin/master 0de7fd3 MarcoFalke: Merge #9139: Change sync_blocks to pick smarter maxheight (on top of #9196)...
04:02 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9139: Change sync_blocks to pick smarter maxheight (on top of #9196) (master...sync-height) https://github.com/bitcoin/bitcoin/pull/9139
04:03 -!- brhood9_ [6b4debe5@gateway/web/freenode/ip.107.77.235.229] has joined #bitcoin-core-dev     
04:04 < brhood9_> This is about unconfirmed transactions that need to be fixed.
04:04 < brhood9_> Is there any way that you all could help me figure out what is going on with my bitcoin transaction? I have asked and looked and read everywhere. The transaction that you need to look at is this one. 
04:05 < brhood9_> https://blockchain.info/tx/6bef9829ddfba24ec2e613fa1a8239f09acfc36ab057e890f192863298b648b8?show_adv=true
04:05 -!- brhood9 [6b4debe5@gateway/web/freenode/ip.107.77.235.229] has quit [Ping timeout: 260 seconds]     
04:05 < brhood9_> is anyone there?
04:06 < Victorsueca> brhood9_: yes
04:06 < Victorsueca> i'm looking at it
04:06 < Victorsueca> also this is off-topic here
04:06 < Victorsueca> please move to #bitcoin
04:10 -!- brhood9_ [6b4debe5@gateway/web/freenode/ip.107.77.235.229] has quit [Ping timeout: 260 seconds]     
04:11 -!- brhood9 [6b4debe5@gateway/web/freenode/ip.107.77.235.229] has joined #bitcoin-core-dev     
04:17 -!- haakonn_ is now known as haakonn     
04:17 -!- haakonn is now known as Guest28989     
04:18 -!- Guest28989 is now known as haakonn_     
04:21 -!- jujumax [~jujumax@host250.190-137-164.telecom.net.ar] has quit [Remote host closed the connection]     
04:24 -!- takashi [~takashi@softbank126007215055.bbtec.net] has joined #bitcoin-core-dev     
04:27 < takashi> Why "maker" was added to transaction instead of increment "version" for segwit? 
04:28 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #9211: [0.12.2] Backports (0.12...Mf1611-back12) https://github.com/bitcoin/bitcoin/pull/9211
04:41 -!- gielbier [~michiel@unaffiliated/gielbier] has quit [Remote host closed the connection]     
04:42 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 260 seconds]     
05:04 -!- fanquake [~fanquake@unaffiliated/fanquake] has left #bitcoin-core-dev []     
05:12 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
05:20 < instagibbs> is there a flag I have to set to compile zmq/rest
05:21 < jonasschnelli> instagibbs: rest should compile with RPC (so not optional)
05:21 < jonasschnelli> ZMQ will compile if libzmq is present
05:21 < jonasschnelli> Rest needs to be enabled during startup
05:21 < jonasschnelli> -rest=1
05:21 -!- brhood9 [6b4debe5@gateway/web/freenode/ip.107.77.235.229] has quit [Quit: Page closed]     
05:21 < jonasschnelli> or just -rest
05:21 < jonasschnelli> also check the docs/REST.md
05:21 < instagibbs> ok thanks. I had zmq code fail to compile in Travis :)
05:22 < instagibbs> wanted to avoid this
05:22 < jonasschnelli> I think one of the ZMQ instance compiles zmq? Not?
05:22 < jonasschnelli> (or even all of them?)
05:22 < instagibbs> code I changed*
05:22 < jonasschnelli> In the REST.md, theres also a curl command that works "out-of-the-box". :)
05:27 < instagibbs> I don't see a REST.md?
05:27 < instagibbs> perhaps search fail on my part....
05:29 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []     
05:33 < paveljanik> while testing on testnet, I have just received: Assertion failed: (nSendVersion != 0), function GetSendVersion, file ./net.h, line 775.
05:34 < paveljanik> on current master
05:40 < jonasschnelli> instagibbs: REST-interface.md
05:40 < jonasschnelli> Sry: https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md
05:44 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
06:35 -!- takashi [~takashi@softbank126007215055.bbtec.net] has quit [Remote host closed the connection]     
06:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:46 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
07:27 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
07:49 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
08:04 -!- laurentmt [~Thunderbi@80.215.210.20] has joined #bitcoin-core-dev     
08:15 -!- laurentmt [~Thunderbi@80.215.210.20] has quit [Quit: laurentmt]     
08:53 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
08:57 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
09:45 < cfields> sdaftuar: interesting
09:45 < cfields> (the staller logic log)
10:35 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
10:38 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
10:39 < Chris_Stewart_5> There isn't an easy way to replace a tx in the mempool if the user had all sequence numbers set to max, correct? 
10:40 < Chris_Stewart_5> and the parent isn't RBF either
10:42 < gmaxwell> in practice you just create a replacement and keep broadcasting it. miners get restarted enough that it's pretty likely to get replaced eventually.
10:43 < gmaxwell> (assuming the prior was low fee)
10:45 < Chris_Stewart_5> Yes, it happened before this latest 'influx' or txs. Does Core's algorithm rejects txs from the mempool if it already has a tx that spends that particular output? I'm guessing it doesn't match on txids since those will be unique assuming
10:45 < Chris_Stewart_5> some sort of malleability or reordering of inputs
10:53 < BlueMatt> jonasschnelli: if you're gonna ack #9183, please also ack its dependencies, #8930
10:53 < gribble> https://github.com/bitcoin/bitcoin/issues/9183 | Final Preparation for main.cpp Split by TheBlueMatt · Pull Request #9183 · bitcoin/bitcoin · GitHub
10:53 < gribble> https://github.com/bitcoin/bitcoin/issues/8930 | Move orphan processing to ActivateBestChain by TheBlueMatt · Pull Request #8930 · bitcoin/bitcoin · GitHub
11:04 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev     
11:07 -!- JackH [~laptop@79-73-184-38.dynamic.dsl.as9105.com] has quit [Remote host closed the connection]     
11:09 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]     
11:14 < Chris_Stewart_5> Is there a command line flag to enable RBF by default when creating a tx with core's wallet?
11:14 < luke-jr> Chris_Stewart_5: AFAIK there are nodes miners who will RBF without any flag
11:14 < luke-jr> Chris_Stewart_5: -walletrbf but I don't know what Core version it's in
11:29 < Chris_Stewart_5> Thanks luke-jr 
11:32 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
11:34 < Victorsueca> luke-jr: did you check with the pillow why my ASIC didn't work with bfgminer or still no idea?
11:45 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev     
12:12 < cfields> BlueMatt: want to argue about #9128 for a little bit?
12:12 < gribble> https://github.com/bitcoin/bitcoin/issues/9128 | net: Decouple CConnman and message serialization by theuni · Pull Request #9128 · bitcoin/bitcoin · GitHub
12:12 < BlueMatt> cfields: sure
12:14 < BlueMatt> cfields: see https://github.com/TheBlueMatt/bitcoin/commit/7a42a0c95d04add8cff0cf7cf95df273169f8fa3 ?
12:14 < cfields> BlueMatt: so, before we end up in tangential discussions, i think the key thing to decide on is where encryption state should be held
12:14 < BlueMatt> cfields: fix the TODO :p
12:14 < BlueMatt> especially, send the message without hashing the message repeatedly
12:14 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
12:15 < cfields> BlueMatt: and if some nodes are using encryption?
12:15 < gmaxwell> BlueMatt: you're not thinking you can reuse the authentication value across multiple peers when encryption is in use, are you?
12:16 < BlueMatt> gmaxwell: no, but for current-style peers you can :p
12:16 < sipa> well i think cfields's design was based on the goal of being able to construct a message once, and then send it to multiple peers
12:16 < cfields> BlueMatt: fwiw, i had a discussion with sipa/gmaxwell about my grand plans for dedup, which, they made me realize doesn't make much sense
12:17 < BlueMatt> cfields: in any case, it seems massively layer-violating to have any knowledge of the structure of bytes-on-the-wire in CConnman
12:17 < sipa> BlueMatt: i don't see that
12:17 < BlueMatt> sipa: my impression is that the goal of CConnman is to be a network management library
12:17 < sipa> CConnman shouldn't know about how a block or inv message is structured
12:17 < BlueMatt> not a bitcoin-p2p-management library
12:18 < sipa> but it certainly should be able to construct and dissect network messages?
12:18 < BlueMatt> why?
12:18 < sipa> where else does that logic belong?
12:18 < BlueMatt> what if we want to change the header for encryption
12:18 < cfields> BlueMatt: at minimum, it has to have knowledge of when a message is complete
12:18 < cfields> well it doesn't have to, but for efficiency, it should
12:18 < BlueMatt> the logic belongs int he message-serialization/-deserialization logic
12:18 < gmaxwell> I really don't think it's worth the savings to conserve message hashing for the non-encrypted case, lets get everyone to encryption. :)
12:18 < BlueMatt> cfields: yes, the MessageDeserializer class thinggy we have now works great :)
12:19 < cfields> BlueMatt: which?
12:19 < gmaxwell> Serialize once is fine... 
12:19 < cfields> BlueMatt: wait... let's stop there. I was trying to avoid getting this far without answering the first question...
12:19 < BlueMatt> cfields: CNetMessage
12:20 < cfields> <cfields> BlueMatt: so, before we end up in tangential discussions, i think the key thing to decide on is where encryption state should be held
12:20 < BlueMatt> cfields: right beside current protocol versioning info in CNode?
12:20 < sipa> i think we conceptually have 3 layers 1) network bytes 2) p2p messages 3) contents of p2p messages
12:20 < cfields> BlueMatt: that stuff is now ready to be extracted, just waiting on CNodeState lock cleanups
12:21 < BlueMatt> cfields: CNetMessage is an object which is going to have to be peer-specific
12:21 < sipa> i think BlueMatt is trying to separate 1 and 2
12:21 < sipa> cfields is separating 2 and 3
12:21 < BlueMatt> sipa: yes
12:21 < sipa> i'm of the opinion that separating 2 and 3 is the more interesting problem now
12:21 < BlueMatt> cfields: yes, I dont think it should be in CNode, if you want CNode to be a "dumb thing that CConnman handles"
12:21 < BlueMatt> but it should be in the same place
12:22 < BlueMatt> sipa: p2p messages and contents of p2p message/processing thereof seem already relatively separated, no?
12:22 < cfields> BlueMatt: imo, CNode should be just the stuff related to connection state. And current iv's fall into that category.
12:22 < BlueMatt> cfields: a corollary to your question is how does CNetMessage become peer-specific?
12:22 < sipa> so the question is whether CConnman should do the serialization of the contents of messages
12:23 < BlueMatt> cfields: "ivs"?
12:23 < sipa> if CNetMessage is peer-specific, it perhaps should be just hidden behind CConnman?
12:23 < sipa> like it currently is
12:24 < sipa> that makes reuse of messages across peers impossible, but maybe we're not interested if it can't be done at the same time as hashing/encrypting
12:24 < gmaxwell> for example, some peers might use compacted transactions some might not. But is that the correct layer for it?  I don't think we'd propose implementing BIP152 block compaction inside CConnman.
12:24 < cfields> sipa: to be specific, message reuse is possible, it's only the header attachment that can't be shared
12:25 < BlueMatt> sipa: the way i see it: processing of messages and the peer handling is already well-separated, or at least somewhat separated...we currently have bitcoin-specific and general-networking code intermixed in a bunch of places, and that also needs to be separated
12:25 < sipa> cfields: i mean, the whole point of 9128 is the introduction of a serializer abstraction... that seems unnecessary if we don't plan on ever reusing network messages
12:26 < sipa> cfields: while if it remains inside CConnman, it could do hashing/encryption on the fly during serialization
12:26 < cfields> sipa: it's necessary as a layer abstraction... it's only a shortcut for callers
12:26 < BlueMatt> sipa: the serializer-abstraction in 9128 is definitely useable even if we encrypt network messages, etc
12:26 < BlueMatt> sipa: see my branch for early-sending-compact-blocks
12:27 < sipa> cfields: i guess i don't see why
12:27 < cfields> BlueMatt: fwiw, my first version used a shared_ptr for dedup, and cached the hash, so that the same message could be pushed to a bunch of peers without re-serializing or re-hashing. If you think that's worth putting back, i can.
12:28 < cfields> heh, i'm not sure which conversation to be having here :)
12:28 < BlueMatt> cfields: why shared_ptrs? that seems strange to me, but, then, I havent seen that version
12:28 < BlueMatt> cfields: heh, we have fractured....
12:28 < sipa> cfields: oops, i forgot the distinction between CSerializedNetMsg and CNetMsgMaker, ignore me
12:29 < cfields> sipa: right. CSerializedNetMsg is intended to be a dumb payload. CConnman wraps it as necessary, then sends it with no knowledge of the contents. That's the layer separation change.
12:30 -!- achow101 [~achow101@unaffiliated/achow101] has left #bitcoin-core-dev ["Leaving"]     
12:30 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
12:30 < sipa> but i don't think we answered the question whether CNetMsgMaker should be node-specific or not
12:30 < sipa> if we want it to do encryption on the fly, it should be
12:30 < sipa> but that reintroduces the dependency on cconnman
12:31 < cfields> sipa: it's only send-version specific, since that's all the serializers care about
12:31 < BlueMatt> sipa: i mean thats the whole point of the discussion - is the thing we pass into CConnman a blind bytes array to send on the wire, or a serialized message, which needs its header attached, etc
12:31 < BlueMatt> cfields: note that the way it currently is it mixes things...CNetMsgMaker adds most of the header, CConnman adds the hash
12:31 < sipa> my impression is that 9128 intends CSerializedNetMsg to be the unencrypted thing, which is reusable across connections
12:32 < BlueMatt> which seems like a layer-split
12:32 < cfields> so we're back to the original question again of who holds the current encryption state :)
12:32 < BlueMatt> cfields: first question - where are we putting current protocol version?
12:32 < cfields> sipa: yes
12:32 < BlueMatt> cfields: it was my impression you were planning on pulling that out of CNode and putting it in the State() stuff?
12:32 < sipa> cfields: but it somehow still has an optimization of having padding space preallocated
12:33 < sipa> cfields: which does not technically belong in that layer
12:33 < cfields> BlueMatt: yes
12:33 < sipa> cfields: hmm, but the State should be processing-module specific
12:33 < BlueMatt> cfields: I believe encyption state should go right there...encryption state is something negotiated on connect, just like nVersion, and should be in the same layer
12:33 < BlueMatt> sipa: it is
12:33 < sipa> BlueMatt: disagree there - i don't think every network message handler should reimplement encryption
12:34 < cfields> sipa: agreed. That's intended to be a "max padding necessary". I added it to make BlueMatt happy with zero-copy, at the cost of having to stick it at the wrong layer
12:34 < sipa> it's a meta layer
12:34 < sipa> there can be one module that deals with encryption, and once it's done negotiating, tells connman that from that point on encrypt all messages, including those from other modules
12:34 < BlueMatt> sipa: " every network message handler should reimplement encryption" huh?
12:34 < sipa> BlueMatt: my view is that there will be separate message handling modules, each with their own lock and their own state
12:35 < sipa> BlueMatt: one from ping/pong, one for block processing, one for tx relay, ...
12:35 < cfields> BlueMatt: i have a proposal for bip151 that would make it so that encryption isn't reliant on the messaging processing layer, but i haven't written it up yet
12:35 < sipa> BlueMatt: and they install handlers for specific messages
12:35 < BlueMatt> sipa: ok, and the place they hook in the handlers does the encryption, but certainly not CConnman
12:35 < sipa> BlueMatt: but all of their sent messages should get encrypted, not only those from the encryption module
12:36 < sipa> BlueMatt: i think you're envisioning a global processing layer in between the specific message processing and CConnman?
12:36 < BlueMatt> sipa: what if we want to use CConnman for some other protocol - does it now have to have the same encryption protocol?
12:36 < BlueMatt> sipa: CConnman should be a networking library, not a bitcoin networking library
12:37 < sipa> BlueMatt: heh, i thought that the networkling library would be libevent or some lower level wrapper
12:37 < BlueMatt> sipa: I mean right now its that way - the net message maker thing is a library that the processing modules all use
12:37 < sipa> CConnman is exactly the bitcoin specific thing
12:37 < sipa> cfields: opinion?
12:37 < cfields> BlueMatt: that was my original intent. But it became clear as the months went on that tighter integration is needed...
12:37 < cfields> BlueMatt: if we could get this stuff merged, we could move on to ripping out the lower-level stuff :)
12:38 < cfields> after this comes the libevent+async changes, which is maybe closer to what you want to see changed?
12:38 < sipa> BlueMatt: i would think that the separation you're talking about is maybe a later step... if we first want a net protocol, it just gets integrated into CConnman
12:38 < BlueMatt> cfields: well I dont think you mean that tighter-integration is needed between bitcoin logic and libevent/async
12:38 < BlueMatt> but clearly there is some integration needed where the net_processing stuff is aware of how to serialize a message
12:38 < BlueMatt> or at least has an api like CNetMessageMaker
12:39 < cfields> BlueMatt: yes, that's another possibility. One that sipa suggested a while back, i think
12:39 < BlueMatt> cfields: what is?
12:39 < cfields> callers could pass in abstract classes to handle the message wrapping (header)
12:40 < BlueMatt> cfields: ultimately I think there /are/ clearly three layers here, as sipa said, just a quesition of how we split them up....I think for now its much easier to dump things in net_processing and make CConnman just a "dumb pipe" or at least "semi-dumb-pipe"
12:41 < BlueMatt> because there are lots of changes that need to happen in just the network-library layer
12:41 < cfields> BlueMatt: for context, I first wrote a completely low-level, no-bitcoin network layer. Plugging that into bitcoin proved to require a bunch of bitcoin-specific hacks. In the end, I didn't think it was an improvement over what we had.
12:42 < BlueMatt> cfields: bitcoin-specific hacks like what?
12:42 < sipa> BlueMatt: in your hypothetical new network protocol, are there still network messages of the form (12-byte-command, data) that are dealt with in the same way in main etc?
12:42 < kanzure> was the networking library you were working on thrown out, cfields?
12:43 < BlueMatt> sipa: hmm? I dunno, do we need to stick to the same header format in 151?
12:43 < BlueMatt> sipa: I dont think we should be restricted to that?
12:43 < cfields> kanzure: not thrown out, but i kinda decided to converge with our current stuff instead
12:44 < BlueMatt> (plus I strongly thing having additional networking libraries would be welcome)
12:44 < sipa> i see bip151 simply as a change to the pipe, not to the messages in it
12:44 < cfields> BlueMatt: there's a strong reason to keep the header size, imo
12:44 < sipa> and i think CConnman is what is common between all network protocols that are just pipes for delivering messages of that form
12:44 < BlueMatt> sipa: indeed, but are message headers a part of the pipe, or the messages?
12:44 < cfields> though i'm aware there are plenty of drawbacks, and i wouldn't be heartbroken if it were abandoned
12:44 < sipa> BlueMatt: messages
12:45 < BlueMatt> sipa: well putting them in CConnman is pipe....
12:45 < sipa> BlueMatt: or you'd need to change every message handler too when the pipe changes
12:46 < BlueMatt> (note that clearly the headers wont all be the same - bip 151 will at least change the definition of the hash field)
12:46 < cfields> BlueMatt: i suppose we're looking at this from different sides. I originally rewrote the net layer and tried to plug it into bitcoin. I didn't like the result. I started instead trying to rip bitcoin out of our net layer, and that's where we are now. The next step would be to split the resulting CConnman into high and low levels. That's next.
12:46 < sipa> BlueMatt: i see messages as (12-byte-command, payload) things... that excludes the checksum
12:47 < sipa> bip151 changes the pipe, but the things being sent over it are still the same messages
12:48 < cfields> sipa: note that if it remains with start bytes (different ones) up front, and padded somehow to 24 bytes, the net layer can handle decryption without having to count on the messaging layer for initialization
12:48 < BlueMatt> cfields: ok, well if CConnman is gonna split, and the hashing/encryption/etc go in the high level, thats ok, but then CNetMsgMaker has to turn into what sipa said and have no knowledge of message-header
12:49 < BlueMatt> (which I think is an easy change from 9128 as it stands now?)
12:50 < cfields> BlueMatt: no knowledge as-in it's done in CConnman?
12:50 < BlueMatt> cfields: its done in CConnman-high
12:50 < BlueMatt> :p     
12:50 < sipa> i think it's fine for CSerializedMessage to have some padding space before/after for undefined purposes, which CConnman(-high) just happens to conveniently use
12:51 < BlueMatt> sipa: I see no advantage to doing so?
12:51 < cfields> right, that was only added for the zero-copy case
12:51 < sipa> BlueMatt: not needing to copy it into a single buffer afterwards
12:51 < BlueMatt> cfields: I dont think you need that? CConnman-low takes a list of vectors...just give it two instead of one
12:51 < BlueMatt> its still zero-copy
12:51 < sipa> hmm     
12:51 < sipa> i guess
12:52 < cfields> alternatively we could just send twice, that was an original TODO to investigate
12:52 < cfields> BlueMatt: is that what you're suggesting?
12:52 < BlueMatt> cfields: "send twice"?
12:53 < cfields> 2 send() calls. or a sendmsg.
12:53 < BlueMatt> yes     
12:53 < BlueMatt> thats ok
12:53 < BlueMatt> (and not performance-busting)
12:53 < cfields> (i'm pretty sure libevent uses scatter/gather anyway, so that should be freeish)
12:53 < BlueMatt> even two syscalls wont be performance-bustingn
12:53 < BlueMatt> ng     
12:53 < BlueMatt> well, do we still disable nagle?
12:54 < BlueMatt> will have to look into that
12:54 < cfields> yes     
12:54 < BlueMatt> have to use the MSG_MORE thing for the header, then
12:54 < sipa> use writev(2) :)
12:54 < cfields> BlueMatt: i was more concerned about possible awkwardness if you managed to push out exactly only the header
12:54 < BlueMatt> before what? the connection dies? so what?
12:55 < sipa> i do like this idea... just remove the message padding optimization out of CSerializedMessage, and use separate writes for header/...
12:55 < cfields> ok, i figured someone would complain about that :)
12:55 < cfields> easy, then
12:56 < cfields> i'm not going to bother with writev/sendmsg though, since libevent will handle that internally
12:56 < BlueMatt> thats fine
12:56 < BlueMatt> if you switch to libevent and I run an strace and you're wrong, I'll be upset, though :p
12:57 < cfields> heh     
12:57 < cfields> BlueMatt: so to be clear, the next steps are to begin making things async-friendly. I have a branch which adds OnConnect(), OnDisconnect(), etc
12:57 < BlueMatt> cfields: cool, sounds good :)
12:57 < cfields> once we're there, we can begin the separation, and have a virtual class (high level) that responds to those things
12:58 < BlueMatt> sounds good
12:58 < sipa> cfields: yay
12:58 < sipa> concept ack
12:59 < cfields> in the end, i think it will end up looking much like my original lib. We'll just have gone from core->lib rather than the other way around.
13:00 < cfields> anyway, after this PR, I think we can segregate the files, and no one will have to concern themselves with the churn in the net code anymore :)
13:01 < BlueMatt> cfields: yay, then I can split main :)
13:01 < cfields> BlueMatt: heh, if we've done this right, we can do them in parallel without stomping on eachother :)
13:02 < BlueMatt> cfields: nailed the timing too...you'll get your last change into main a week before it splits :p
13:02 < cfields> hehe
13:03 < cfields> BlueMatt: so to clarify, drop the pad hack, send() twice, and you're happy with the rest?
13:03 < BlueMatt> cfields: yea, I'm ok with it as a next-step :)
13:04 < cfields> BlueMatt: ok, thanks.
13:04 < cfields> and thanks sipa as well
13:10 < sipa> great
13:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
13:40 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
13:48 < cfields> BlueMatt: i'm not familiar enough, so maybe you would know... any risk of the SyncTransaction having an effect on the downstream listeners? zmq, in particular
13:48 < cfields> *SyncTransaction change
13:50 < cfields> oh nevermind, i guess they don't actually see any difference
13:53 -!- marcoagner [~marcoagne@178.162.199.99] has joined #bitcoin-core-dev     
13:56 -!- marcoagner [~marcoagne@178.162.199.99] has quit [Client Quit]     
13:57 -!- marcoagner [~marcoagne@178.162.199.99] has joined #bitcoin-core-dev     
14:05 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
14:17 -!- marcoagner [~marcoagne@178.162.199.99] has quit [Remote host closed the connection]     
14:19 -!- fubu [~saa@5.172.255.57] has joined #bitcoin-core-dev     
14:29 < BlueMatt> cfields: yea, point is now the orphan map is limited to p2p logic now :)
14:42 -!- fubu [~saa@5.172.255.57] has quit [Ping timeout: 258 seconds]     
14:43 -!- fubu [~saa@5.172.255.251] has joined #bitcoin-core-dev     
14:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
14:52 < cfields> BlueMatt: ready for the big move after #8930? Or am I missing one?
14:52 < gribble> https://github.com/bitcoin/bitcoin/issues/8930 | Move orphan processing to ActivateBestChain by TheBlueMatt · Pull Request #8930 · bitcoin/bitcoin · GitHub
14:52 < cfields> ah nm, #9183
14:52 < gribble> https://github.com/bitcoin/bitcoin/issues/9183 | Final Preparation for main.cpp Split by TheBlueMatt · Pull Request #9183 · bitcoin/bitcoin · GitHub
15:06 < BlueMatt> cfields: yea, ready after 9183
15:14 -!- dhill [~dhill@unaffiliated/dhill] has joined #bitcoin-core-dev     
15:14 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 252 seconds]     
15:15 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
15:15 < dhill> addrmap.cpp, in CAddrInfo::GetChance(), nSinceLastSeen is unused...
15:16 -!- fubu [~saa@5.172.255.251] has quit []     
15:17 -!- fubu [~saa@5.172.255.251] has joined #bitcoin-core-dev     
15:19 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 246 seconds]     
15:27 < fubu> ssij
15:27 -!- fubu [~saa@5.172.255.251] has quit []     
15:27 -!- fubu [~saa@5.172.255.251] has joined #bitcoin-core-dev     
15:34 -!- dhill [~dhill@unaffiliated/dhill] has left #bitcoin-core-dev []     
15:36 < fubu> xD     
15:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-core-dev     
15:43 < rusty> Anyone thought about removing the dust limit?  In a feemarket world, it seems a little useless, and for things like lightning it complicates things (we have to always keep everything above the dust limit otherwise risk holding a non-standard tx).
15:44 < gmaxwell> If we consistently were operating in a functioning market I'd agree strongly. 
15:45 -!- fubu [~saa@5.172.255.251] has quit [Ping timeout: 246 seconds]     
15:45 < gmaxwell> Unfortunately there are many blocks that aren't and so they'd mine huge wads of dust advertisment payments sitting around.  I dunno if segwit will make this better or worse. (increases utxo costs, but also increases capacity.)
15:45 -!- fubu [~saa@5.172.255.191] has joined #bitcoin-core-dev     
15:45 < gmaxwell> rusty: so "someday hopefully soon"? 
15:46 < gmaxwell> already one large miner bypasses it, so perhaps we should give up.
15:47 < gmaxwell> here is a week of "mempool fees available" immediately before and immediately after a block, two-ish weeks ago: https://people.xiph.org/~greg/temp/fee_avail.png
15:47 < gmaxwell> you can see there are many periods of effectively no backpressure.
15:48 < rusty> gmaxwell: makes sense.  In practice, lightning has a "don't bother making any outputs below this" for economic reasons, but version 0 might have skipped that if not for the standardness issue.
15:48 < rusty> gmaxwell: nice graph!
15:48 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
15:49 < gmaxwell> here is a few days before that graph, where there was some nicer behavior: https://people.xiph.org/~greg/temp/fee_avail2.png
15:50 < rusty> gmaxwell: it would be nice to have these nicely generated and running constantly somewhere, BTW.  Did you have to hack bitcoind to get the data?
15:50 < fubu> u     
15:50 < gmaxwell> rusty: no, set the target blocksize to 1mb... run 
15:50 < gmaxwell> $ cat fun.sh
15:50 < gmaxwell> echo `date -u +%s` `./bitcoin-cli getblockcount`  `./bitcoin-cli getblocktemplate | grep \"fee\" | awk '{aa+=$2} END {print aa}'`
15:50 < gmaxwell> every couple seconds.
15:51 < gmaxwell> I have it running on my desktop but I keep disrupting it to tinker with things.. though the disruptions are less disruptive now that we have mempool saving in master.
15:51 < gmaxwell> the graph is just a little bit of postprocessing that data to get the before/after numbers for every block change.
15:52 < gmaxwell> sipa was working on some patches that would give a "CDF" like report for the mempool. (size vs fees) multiple blocks out. 
15:53 < gmaxwell> one nice thing about this data is you can see all the miners that aren't doing CPFP mining yet... when they produce blocks that pay a lot less fee than my node would produce.
15:55 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
15:56 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
16:10 < rusty> sipa: trying to find where the relayfeerate changes, other than manual configuration... 
16:10 < sipa> rusty: it doesn't
16:11 < rusty> sipa: ah, right.  Indeed, I agree that nodes should be scaling their min output level by feerate.  But as long as they propagate that's a v1.1 problem.
16:12 < sipa> rusty: maybe for DoS reasons it should be changed at some point, but even then i can't imagine that happens in core without making sure it's certain to be consistently higher than actual feerates
16:14 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0de7fd36de57...407d9232ef5c
16:14 < bitcoin-git> bitcoin/master ca8549d Gregory Maxwell: Always drop the least preferred HB peer when adding a new one....
16:14 < bitcoin-git> bitcoin/master 407d923 Pieter Wuille: Merge #9199: Always drop the least preferred HB peer when adding a new one....
16:14 < bitcoin-git> [bitcoin] sipa closed pull request #9199: Always drop the least preferred HB peer when adding a new one. (master...remove_high_bandwidth_zombies) https://github.com/bitcoin/bitcoin/pull/9199
16:15 < rusty> gmaxwell: it's your fault I now have 'while sleep 10; do bitcoin-cli getblocktemplate | awk '/"fee"/ { FEES += $2 } /"height"/ { HEIGHT = $2 } END { print HEIGHT,FEES }'; done' running in a terminal here, BTW.
16:15 < sipa> rusty: i have a patch that builds a max-size block, removes the included transactions from the mempool, then builds another max-size block, etc
16:16 < sipa> rusty: and then store the min feerate of each of those built blocks
16:16 < sipa> last entry:
16:16 < sipa> 1479946521 0.00098826 0.00081403 0.00067987 0.00065261 0.00065000 0.00062687 0.00061134 0.00060031 0.00058407 0.00055922
16:17 < sipa> which means that it would take at least 5 blocks to get the feerate to get accepted down to 65sat/byte
16:17 < rusty> sipa: nice!
16:19 -!- Alina-malina [~Alina-mal@37.157.216.170] has joined #bitcoin-core-dev     
16:20 < rusty> So it stops when it can't make a full block?
16:20 < sipa> no, it stops at 10
16:20 < sipa> i can increase it, and probably should right now
16:27 < bitcoin-git> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/407d9232ef5c...93566e0c37c5
16:27 < bitcoin-git> bitcoin/master ec4525c Matt Corallo: Move orphan processing to ActivateBestChain...
16:27 < bitcoin-git> bitcoin/master 97e2802 Matt Corallo: Erase orphans per-transaction instead of per-block
16:27 < bitcoin-git> bitcoin/master d2b88f9 Matt Corallo: Move orphan-conflict removal from main logic into a callback...
16:32 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
16:40 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
16:45 -!- abhi_ [36f0c4b9@gateway/web/freenode/ip.54.240.196.185] has joined #bitcoin-core-dev     
16:45 -!- abhi_ [36f0c4b9@gateway/web/freenode/ip.54.240.196.185] has quit [Client Quit]     
16:47 -!- fubu [~saa@5.172.255.191] has quit [Ping timeout: 260 seconds]     
16:47 -!- fubu [~saa@5.172.255.40] has joined #bitcoin-core-dev     
17:02 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 258 seconds]     
17:15 < fubu> ;)     
17:25 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
17:27 -!- Alina-malina [~Alina-mal@37.157.216.170] has quit [Ping timeout: 252 seconds]     
17:29 -!- Alina-malina [~Alina-mal@37.157.216.170] has joined #bitcoin-core-dev     
17:48 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]     
17:49 -!- fubu [~saa@5.172.255.40] has quit [Ping timeout: 245 seconds]     
17:49 -!- fubu [~saa@5.172.255.176] has joined #bitcoin-core-dev     
18:02 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mbzagksyprqdjcek] has quit [Quit: Connection closed for inactivity]     
18:03 -!- fubu [~saa@5.172.255.176] has quit [Read error: Connection reset by peer]     
19:45 -!- crudel [crudel@gateway/shell/fnordserver.eu/x-oounzpacvdrrsscu] has quit [Quit: https://fnordserver.eu]     
19:51  * luke-jr wonders why the splashscreen has a copyright line, but nothing indicative of the license terms
19:52 < luke-jr> any objections to adding another line "Available without royalties under a free software license" or something?
19:58 < bitcoin-git> [bitcoin] luke-jr reopened pull request #8889: Qt/ModalOverlay: Use theme tooltip colours (master...overlay_theme) https://github.com/bitcoin/bitcoin/pull/8889
21:03 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
21:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
21:15 -!- Alina-malina [~Alina-mal@37.157.216.170] has quit [Changing host]     
21:15 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
21:19 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
21:29 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
21:32 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.5]     
21:33 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
21:35 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]     
22:26 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-uifjeeunnenmvqtd] has joined #bitcoin-core-dev     
22:28 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
22:30 < luke-jr> http://netpatterns.blogspot.de/2016/01/the-rising-sophistication-of-network.html
22:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 250 seconds]     
23:12 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
23:18 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 268 seconds]     
23:26 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
23:32 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
23:33 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 246 seconds]     
23:41 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
23:42 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
23:47 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds]     
23:56 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev