1 2016-01-22 00:51:14 <xabbix> When a tx is rejected, I can see that in my debug.log, however, for some reason, I'm not seeing the reject message for some of the txs. For example: 411c7550e43a0fbec14ed98eac2f322b7f8384cb89246cbdb9c203fcd5aa5877
  2 2016-01-22 00:52:03 <xabbix> It should be rejected by bitcoin-core, as far as I understand, I can see the AcceptToMemoryPool line in my debug.log, however no reject row. Any ideas?
  3 2016-01-22 01:53:18 <Chris_Stewart_5> all script operations are combined to a single byte, correct?
  4 2016-01-22 01:53:28 <Chris_Stewart_5> contained*
  5 2016-01-22 02:14:53 <btcdrak> ping luke-jr
  6 2016-01-22 02:15:04 <btcdrak> could you merge https://github.com/bitcoin/bips/pull/292 urgently please
  7 2016-01-22 02:17:51 <altoidnerd> I see the relase candidate binaries here: https://bitcoin.org/bin/bitcoin-core-0.12.0/test/ But, if I want to build from source, where to?
  8 2016-01-22 02:26:24 <Luke-Jr> btcdrak:
  9 2016-01-22 02:30:34 <btcdrak> luke-jr: yes, sorry was afk. could you merge that BIP PR because it's necessary for part of the segwit release announces
 10 2016-01-22 02:35:28 <kefkius> Chris_Stewart_5: Opcodes each take up one byte in a serialized script, yeah
 11 2016-01-22 02:39:04 <Chris_Stewart_5> thanks kefkius
 12 2016-01-22 02:39:13 <kefkius> np
 13 2016-01-22 04:57:45 <kefkius> Why do OP_RETURN scripts have to be push-only if they're never executed anyway?
 14 2016-01-22 05:14:56 <altoidnerd> new release candidate looks real fast
 15 2016-01-22 07:12:28 <altoidnerd> my 0.12 release candidate looks right on track to fully sync in 4 hours total
 16 2016-01-22 07:13:15 <CubicEarth> what computer specs?
 17 2016-01-22 07:13:31 <altoidnerd> i7-4770, 20GB ram
 18 2016-01-22 07:14:01 <altoidnerd> I have a fairly detailed log I will post, it tracks the blockheight every 2 seconds
 19 2016-01-22 07:14:58 <CubicEarth> I'll look forward to seeing how fast my Core2Duo / 2GB of ram gets the job done.
 20 2016-01-22 07:15:12 <Luke-Jr> "on track" means little :/
 21 2016-01-22 07:15:31 <CubicEarth> It's me dedicated node machine.
 22 2016-01-22 07:16:05 <altoidnerd> Luke-Jr: True, I am just guessing at the moment.  2hrs28 mins in, 352000 blocks
 23 2016-01-22 07:17:41 <CubicEarth> My XT Node has taken about two weeks to sync.  2.0 Ghz Core2Duo with 4 GB ram.  I'm guessing it's a DDoS thing?  I haven't noticed any other internet issues, but I guess it could be a port specific attack?  I'm no expert on the DDoS.
 24 2016-01-22 07:18:08 <CubicEarth> And laugh all you want... I run a different nodes for differetn reasons
 25 2016-01-22 07:18:49 <altoidnerd> CubicEarth: I am interested to see the performance with 0.12 as I understand a new EC library was merged
 26 2016-01-22 07:19:06 <altoidnerd> CubicEarth: in comparison to your old time of 14 days
 27 2016-01-22 07:19:56 <CubicEarth> altoidnerd: Yes.  Me too, for the same reason.  But the 14 days... that is not CPU bound as far as I can tell.  Maybe it's some bug in XT, or DDoS keeping the node from getting the block data
 28 2016-01-22 07:20:22 <aj> CubicEarth: bitcoin-cli getpeerinfo should tell you what blocks it's trying to receive?
 29 2016-01-22 07:20:44 <CubicEarth> My Core2Duo machines have synced in about 2 days with 11.2
 30 2016-01-22 07:22:15 <CubicEarth> aj: Just put that in the console?
 31 2016-01-22 07:22:24 <CubicEarth> aj: It worked
 32 2016-01-22 07:24:36 <CubicEarth> It's oldest connection is only 20 minutes old.  Ports are forwarded, but it only has 9 total connections, 8 out, 1 in.
 33 2016-01-22 07:25:06 <aj> CubicEarth: there should be some blocks listed as "inflight" if you're still downloading
 34 2016-01-22 07:26:35 <CubicEarth> the inflight field is listed, but empty.
 35 2016-01-22 07:27:45 <altoidnerd> would using bitcoin-cli getblockcount every N seconds would affect the sync time
 36 2016-01-22 07:27:54 <CubicEarth> But the CPU doesn't show it's very busy either.  Eh - I don't really care because XT has been abandon, and I never found much good information on it anyway.
 37 2016-01-22 07:28:37 <altoidnerd> sorry - thats a question.  would bitcoin-cli calls affect the sync time?
 38 2016-01-22 07:31:35 <CubicEarth> altoidnerd: maybe if you did it multiple times a second?  Hard to imagine it having a material impact if you polled it once per minute or 5
 39 2016-01-22 07:32:52 <aj> altoidnerd: hasn't that i've seen; though if bitcoin is burning cpu validating blocks, bitcoin-cli will take a while to actually return
 40 2016-01-22 07:33:51 <aj> CubicEarth: i've had to wait a while for bitcoind to start trying to download blocks, and it sounds like you're in that state. i don't get why that would happen after 14 days of syncing, unless your ip changes a lot or something?
 41 2016-01-22 07:33:59 <altoidnerd> aj: thats exactly what I am finding.  My script calls getblockcount every 2 seconds, I think, but the log file shows responses sometimes in 2 seconds, sometimes in up to 30 seconds
 42 2016-01-22 07:34:45 <aj> altoidnerd: yeah, that just means bitcoind is validating stuff and too busy to tell you where it's up to, afaik. no actual harm. (afaik, i think, i might be wrong, disclaimer, etc)
 43 2016-01-22 07:35:20 <altoidnerd> aj: yes after long gaps of no response itll jump by hundreds of blocks
 44 2016-01-22 07:36:19 <CubicEarth> IP has been static for over a year now (I'm lucky).  It's just been slow since the beginning.  It should finally be synced by the morning.  But soon I'll have some new clients to choose from, and I'll wipe XT and the blocks and start from scratch.  Hopefully it will be situation normal, which for me is fast.
 45 2016-01-22 07:37:53 <aj> altoidnerd: i think what happens is it downloads out of order, so it gets blocks [xx501-xx600] from a fast peer, then a slow peer finally finishes sending [xx500] so it does all 101 blocks at once
 46 2016-01-22 07:38:14 <altoidnerd> aj: interesting
 47 2016-01-22 07:38:54 <altoidnerd> aj: is it possible to ask the network for the actual network blockheight right now (currently 394421)
 48 2016-01-22 07:38:56 <aj> altoidnerd: ("out of order" isn't quite right, each peer sends in order, it's just different speeds result in them arriving out of order)
 49 2016-01-22 07:39:22 <aj> altoidnerd: getblockchaininfo -> headers should give you the actual block height?
 50 2016-01-22 07:39:29 <altoidnerd> aj: so I can make my script stop logging at some point and end the process
 51 2016-01-22 07:40:01 <altoidnerd> aj: bingo, that worked
 52 2016-01-22 07:40:21 <aj> altoidnerd: (it won't work when it first starts up, but headers gets synced first, then blocks catch up to headers)
 53 2016-01-22 07:40:46 <altoidnerd> aj: for this purpose, it only needs to work at the end of the sync
 54 2016-01-22 07:40:56 <aj> altoidnerd: should be fine then
 55 2016-01-22 07:43:36 <altoidnerd> client is flying at 366k blocks
 56 2016-01-22 07:49:06 <altoidnerd> aj: can I receive a signal from the client that it is caught up fully?
 57 2016-01-22 07:56:18 <aj> altoidnerd: i think you could use zeromq for notifications, but i haven't tried that out myself
 58 2016-01-22 07:58:02 <jonasschnelli> altoidnerd: you can call getblockchaininfo over RPC (./src/bitcoin-cli getblockchaininfo)
 59 2016-01-22 07:58:18 <jonasschnelli> You see "blocks": 394424 .... as well as "headers": 394424
 60 2016-01-22 07:58:36 <jonasschnelli> Your should be in sync if your blocks ~matches your headers.
 61 2016-01-22 07:59:56 <altoidnerd> jonasschnelli: yes, was wondering if I needed to test that myself or if there is a builtin status.
 62 2016-01-22 08:00:26 <altoidnerd> 3 hours into sync, 371000 blocks. fast
 63 2016-01-22 08:00:48 <jonasschnelli> altoidnerd: but current mainnet height is somewhere around 394424
 64 2016-01-22 08:00:55 <jonasschnelli> You miss a couple of blocks...
 65 2016-01-22 08:01:06 <jonasschnelli> but still, 3h to 371000 is blazing fast!
 66 2016-01-22 08:01:38 <altoidnerd> I am doing the benchmarking as we discussed earlier, its still cruising along
 67 2016-01-22 08:01:53 <altoidnerd> here is outfile: https://github.com/Altoidnerd/bitcoin-bench/blob/master/bitcoin_bench_1453438402.log
 68 2016-01-22 08:16:24 <maaku> Kefkius because let's not break parsers
 69 2016-01-22 08:18:13 <kefkius> Yeah fair enough
 70 2016-01-22 08:21:10 <altoidnerd> jonasschnelli: I think this data can be used to give the user a projected sync finish time.
 71 2016-01-22 08:21:47 <jonasschnelli> altoidnerd: nice data output!
 72 2016-01-22 08:23:17 <altoidnerd> jonasschnelli: this is right in my wheelhouse
 73 2016-01-22 08:24:24 <maaku> btcdrak I'm a bit concerned that BIP142 is listed on the segwit announcement page. It is still contentious.
 74 2016-01-22 08:24:30 <altoidnerd> jonasschnelli: unfortunately I wrote it in bash, so I can't make it much better
 75 2016-01-22 08:26:14 <LeMiner2> @altcoinnerd, can you output unix time from a 0 baseline?
 76 2016-01-22 08:26:33 <LeMiner2> replace it i meant
 77 2016-01-22 08:27:08 <altoidnerd> LeMiner2: I could subtract the startTime, but once I start doing that, I want to rewrite this in python or something
 78 2016-01-22 08:28:05 <altoidnerd> LeMiner2: In the header, there are a few indicators of the initiation time, one of them is in unix time = 1453438402
 79 2016-01-22 08:28:12 <LeMiner2> kk
 80 2016-01-22 08:30:01 <altoidnerd> LeMiner2: you can contribute if you want that feature now
 81 2016-01-22 08:31:31 <LeMiner2> I'm quiet horrible at coding but i'll take a look ;)
 82 2016-01-22 08:32:30 <maaku> jl2012 could you at the very least add a Damm error code?
 83 2016-01-22 08:47:39 <jl2012> I have an earlier version with that but no one seemed to be interested to implement it
 84 2016-01-22 08:48:33 <jl2012> The current spec does not encode any raw script. Everything is hash
 85 2016-01-22 08:49:13 <jl2012> The security level should be same as existing address formats
 86 2016-01-22 08:52:58 <aj> jl2012: oh, huh? just version 0 and a 32 byte hash = script sha256, 20 byte hash = pubkey hash160
 87 2016-01-22 08:53:58 <aj> jl2012: (is there somewhere these changes get discussed?)
 88 2016-01-22 08:55:00 <jl2012> aj, it just followed the changes in the script format
 89 2016-01-22 10:45:12 <altoidnerd> here is getblockcount vs time during a 4 hour, 4 minute sync with 0.12rc http://i.imgur.com/obcLjDD.png
 90 2016-01-22 10:52:31 <phantomcircuit> altoidnerd, yup, pages 6/7 http://strateman.ninja/initial_block_synchronization.pdf
 91 2016-01-22 10:53:01 <phantomcircuit> (note the axis are inverted)
 92 2016-01-22 10:54:23 <altoidnerd> does our data show the same kinks?
 93 2016-01-22 10:54:47 <phantomcircuit> altoidnerd, the results aren't entirely smooth
 94 2016-01-22 11:19:30 <altoidnerd> phantomcircuit: are the deviations from a smooth log plot due to network effects or something else
 95 2016-01-22 11:20:24 <phantomcircuit> altoidnerd, i never seriously investigated them, i dont think it's significant just boundaries of various parameters like maximum write cache size etc
 96 2016-01-22 12:22:59 <wumpus> xabbix: are you using 0.12 rc? due to error flooding "panic" concerns, rejections for incoming transactions are no longer logged by default, try adding -debug=mempoolrej
 97 2016-01-22 13:20:06 <timothy> hi, do you suggest to build bitcoin-qt (linux) with qt4 or qt5?
 98 2016-01-22 13:20:15 <timothy> and which modules of qt5 do bitcoin-qt needs?
 99 2016-01-22 14:02:16 <wumpus> timothy, qt5 is better, doc/build-unix.md lists the necessary packages for both qts
100 2016-01-22 14:06:17 <timothy> wumpus: yes, I still have some issues with -fPIC that I have to solve
101 2016-01-22 14:06:34 <timothy> --with-pic doesn't help
102 2016-01-22 14:09:25 <wumpus> sounds like this problem: https://github.com/bitcoin/bitcoin/pull/6978  should be fixed in 0.12 at least
103 2016-01-22 14:15:46 <timothy> wumpus: I'll port https://github.com/theuni/bitcoin/commit/69d05134367da9a897ad14562a1d266750db450a thank you
104 2016-01-22 14:21:13 <timothy> uhm not so simple
105 2016-01-22 14:21:33 <timothy> well I'll keep bitcoin-qt with qt4 on archlinux and I'll port it to qt5 on next release (0.12)
106 2016-01-22 14:31:05 <RCasatta> Is segwit implementation storing bitcoin value in tx inputs?
107 2016-01-22 14:47:53 <jl2012> RCasatta, value is always associated with outputs
108 2016-01-22 14:56:46 <RCasatta> thanks jl2012, because I heard something in the like for fraud proof wallets...
109 2016-01-22 14:57:55 <jl2012> that should happen in a future upgrade
110 2016-01-22 15:13:34 <cisko> Hi
111 2016-01-22 15:13:49 <cisko> anyone here I'm stuck
112 2016-01-22 15:15:38 <cisko> I've sended 1,911.00 BCN from my bytecoin wallet but the transaction is not confirmed and has no date also my adress isn't seen (anymore?) on the blockchain
113 2016-01-22 15:15:59 <cisko> Does anyone have tips about hot to solve this?
114 2016-01-22 15:16:32 <cisko> okee I see Im in the wrong channel
115 2016-01-22 15:16:36 <cisko> byebye
116 2016-01-22 15:16:37 <instagibbs> :)
117 2016-01-22 15:21:43 <Luke-Jr> timothy: 0.11 has a backport of that in the branch
118 2016-01-22 15:25:20 <chiwawa_> can anyone remember when the 1mb rule was first implemented. i thought it was something like 2012-2013 when there was a big block issue that caused a fork
119 2016-01-22 15:25:51 <Luke-Jr> no, 2010 at the latest
120 2016-01-22 15:26:11 <Luke-Jr> unless you mean the hardfork in 2013 to make 1 MB practically reachable
121 2016-01-22 15:26:32 <Luke-Jr> but that would be an increase, not the first time there was a limit
122 2016-01-22 15:27:05 <chiwawa_> yea when they made 1mb possible
123 2016-01-22 15:27:22 <Luke-Jr> 2013 May
124 2016-01-22 15:27:40 <xabbix> Is there any where I can read about how and when the network decides to drop/discard a transaction?
125 2016-01-22 15:27:43 <wumpus> right, 1MB was the theoretical limit far before that, it just couldn't be reached in practice due to a a datbaase failure
126 2016-01-22 15:28:48 <Luke-Jr> xabbix: on-chain never get dropped; off-chain is at the whim of the node operator
127 2016-01-22 15:30:02 <xabbix> So if a tx isn't accepted to a block, each client has its own mechanism to decide when to drop it and remove it from his mempool?
128 2016-01-22 15:31:22 <Luke-Jr> yes
129 2016-01-22 15:31:22 <xabbix> What's core's definitions in regards to that? How long does a tx have to be outside a block for it to be discarded?
130 2016-01-22 15:31:32 <wumpus> yes, though in the end, the miner decides what to include in their block
131 2016-01-22 15:31:57 <Luke-Jr> xabbix: until 0.12, it was basically "until the node operator restarts his node"
132 2016-01-22 15:32:01 <wumpus> but nodes relaying the transaction along the way can have dropped it
133 2016-01-22 15:32:25 <xabbix> wumpus: makes sense.
134 2016-01-22 15:32:31 <xabbix> Luke-Jr: and after 0.12?
135 2016-01-22 15:33:24 <Luke-Jr> xabbix: 0.12 and newer has some mempool limiting stuff that drops the lowest fee
136 2016-01-22 15:33:53 <chiwawa_> Luke-Jr... are you 'team classic' or did you do the Sha3 commit just for drama sake to cause debate within team classic?
137 2016-01-22 15:35:01 <xabbix> Another question, when core drops a tx due to fees or whatever. Then the miner decides to include it after a few blocks, will core go through the new block txs and request the tx info (that it dropped minutes before) from other nodes? What if it can't find it?
138 2016-01-22 15:35:14 <Luke-Jr> chiwawa_: I am 'team Bitcoin'; I primarily contribute to Core, have had my own fork since 2011, and welcome new alternative forks (but not hardforks without consensus).
139 2016-01-22 15:35:51 <Luke-Jr> xabbix: all txs in a block, are relayed with the block right now
140 2016-01-22 15:36:05 <xabbix> Luke-Jr: oh, didn't know that, cool.
141 2016-01-22 15:36:24 <chiwawa_> ok. im team bitcoin too. but thought that your SHA3 was a mega hardfork idea so thought you were doing it more for drama than an actual plausible thing you actually wanted
142 2016-01-22 15:36:38 <xabbix> Thanks Luke-Jr
143 2016-01-22 15:38:07 <gijensen> xabbix, you asked how long. There's an option "mempoolexpiry" "Do not keep transactions in mempool for longer than x hrs" the default is "72"
144 2016-01-22 15:38:08 <Luke-Jr> chiwawa_: basically a reminder to miners that if they betray the rest of the community, they will be the ones to lose out in the end; and that hardforks need consensus, not merely miners trying to strong-arm it
145 2016-01-22 15:38:41 <proslogion> Luke-Jr: could you provide me with the name of the Wechat group you debated Chinese miners with?
146 2016-01-22 15:38:57 <proslogion> or was that report even real
147 2016-01-22 15:39:12 <Luke-Jr> proslogion: no, it's in Chinese and my browser doesn't seem to display it :p
148 2016-01-22 15:39:27 <proslogion> k tks
149 2016-01-22 15:39:31 <Luke-Jr> I wouldn't call it a debate though
150 2016-01-22 15:39:36 <proslogion> yeah i get that
151 2016-01-22 15:39:59 <proslogion> people are super polite but the message is loud and clear
152 2016-01-22 15:40:10 <chiwawa_> it was a good 'statement' to make.. i personally am not teal classic or team blockstream. my implementation already has 2mb there as a buffer ready for whatever happens next.. as i know it will take ages for miners to start mining >1mb so im not worried.. worse that can happen is my local chain se's a few extra orphans until consensus is reached.
153 2016-01-22 15:40:49 <Luke-Jr> chiwawa_: it's not safe to fail to implement consensus rules completely.
154 2016-01-22 15:41:06 <Luke-Jr> chiwawa_: it's not the miners you need to worry about necessarily, but attackers
155 2016-01-22 15:42:19 <chiwawa_> well even though my implementation has 2mb set.. it is still happily receiving 1mb blocks.. and if an attacker did send out a >1mb block.. eventually the blockheights will ignore and orphan off the >1mb
156 2016-01-22 15:42:42 <chiwawa_> until consensus keeps >1mb
157 2016-01-22 15:44:46 <Luke-Jr> chiwawa_: a miner with 30% can double-spend 6-block confirmation with 50/50 success chances. I'm pretty sure their chance is even better in terms of violating consensus rules to make a longer chain upfront.
158 2016-01-22 15:49:48 <chiwawa_> well thats where merchants shouldnt change the rules until users are ready.. and then when users and merchants are ready.. then miners can change.. in that order.. and if miners change first.. then merchants orphan it and users orphan it if they are not ready.. which is where i though classic done things wrong by lobbying miners and merchants before users..
159 2016-01-22 15:55:05 <dgenr8> Luke-Jr: a miner with 30% can attack 5 deep with 17% success (6 deep less likely) [bitcoin.pdf]
160 2016-01-22 16:17:17 <paveljanik> Luke-Jr, changing PoW is really too radical. I'd drop the one useless byte on OP_CHECKMULTISIG. A lot of saved space from the block chain!
161 2016-01-22 16:17:34 <paveljanik> You radicalist! :-)
162 2016-01-22 16:22:44 <xabbix> gijensen: great, thanks!
163 2016-01-22 16:25:39 <proslogion> paveljanik: if some payment processors could lobby for a takeover, then nothing is radical, someone who want to eat the Chinese miners lunch certainly could, and they can be VC backed, write lots of pretty words on paper, "We are helping decentralization!" etc, and every gamer in the world would want those block rewards as well
164 2016-01-22 16:25:57 <proslogion> and they can offer big blocks as a bonus! the chinese miners, i guess, get that eventually
165 2016-01-22 19:20:02 <Lauda> http://prntscr.com/9the60
166 2016-01-22 19:20:06 <Lauda> Is this correct?
167 2016-01-22 19:25:45 <AlienTrooper> Lauda; it may be exactly like this. Devs know better.
168 2016-01-22 19:27:33 <Lauda> I wrote that, that's why I'm asking.
169 2016-01-22 19:27:45 <aknix> Lauda, Ask in #bitcoin or ##bitcoin this is not the place for generic questions
170 2016-01-22 19:27:46 <AlienTrooper> nice work.
171 2016-01-22 19:29:52 <Lauda> AlienTrooper thanks. aknix in most cases the best input is received here though.
172 2016-01-22 19:33:43 <aknix> Lauda, First of all the plan for Classic was misleading, now there road map points to a SF before later HF in March (I think). Once SW SF is rolled only the new SW enabled clients will be able to validate blocks.
173 2016-01-22 19:34:17 <aknix> basically everything you hasve stated is correct but also misleading thanks to Classics deception in the matter
174 2016-01-22 19:35:13 <gmaxwell> Lauda: thats currect; pedantically the first point is "unable to validate signatures in segwit using transactions" older style transactions still get validated like always.
175 2016-01-22 19:35:17 <aknix> s/there/their/
176 2016-01-22 20:15:16 <bitcoin017_> Hello, I'm studying bitcoin's P2P network for my school project. As far as I know Bitcoin-core is based on WinSock library, but it's documentation (and many example codes) only cover(s) simple client to server communication, whereas in P2P network each node behaves both as a client and server. Please, can anybody recommend any book or article about bitcoin's P2P network implementation (or similar P2P network using winsock)?
177 2016-01-22 20:19:22 <Luke-Jr> bitcoin017_: 1) WinSock is just a copyoff of BSD sockets, which is what Core is actually written around; 2) p2p is implemented using standard client-server TCP protocol; 3) bitcoin.org has some docs
178 2016-01-22 20:21:32 <bitcoin017_> thanks Luke-Jr
179 2016-01-22 20:47:06 <bitcoin017_> I have one more question about bitcoin network, I'm currently looking at CNetAddr::ToStringIP() (in netbase.cpp), It mentions if(IsIPv4()), isn't this equivalent to: if(((SOCKADDR*)&sockaddr)->sa_family == AF_INET)? Thanks
180 2016-01-22 21:01:45 <gijensen> bitcoin017_, it appears so, I guess IsIPv4() is just more portable.
181 2016-01-22 21:02:41 <gijensen> IsIPv4() is defined in the same file
182 2016-01-22 21:07:15 <bitcoin017_> yes, I've found it gijensen, thanks
183 2016-01-22 21:10:25 <bitcoin017_> so If I understood correctly netbase.cpp-s initializer (which takes ip address as input (sockaddr)) assigns globally defined ip variable (in the same file) to the input, and the IsIPv4() uses that globally defined ip address to make it compact. Is this correct, or did I got something wrong? thanks
184 2016-01-22 21:18:05 <gijensen> Well, its not global persay. I'm not sure how to answer your question, this returns True: CNetAddr("127.0.0.1").IsIPv4()
185 2016-01-22 21:19:18 <gijensen> bitcoin017_, plenty of examples in https://github.com/bitcoin/bitcoin/blob/605c17844ea32b6d237db6d83871164dc7d59dab/src/test/netbase_tests.cpp
186 2016-01-22 21:21:09 <gijensen> Sorry, meant to link master  https://github.com/bitcoin/bitcoin/blob/master/src/test/netbase_tests.cpp
187 2016-01-22 21:22:24 <bitcoin017_> thanks gijensen
188 2016-01-22 21:25:11 <gijensen> np :)