1 2015-05-26 07:03:35 <jonasschnelli> wumpus: https://github.com/bitcoin/bitcoin/pull/6186 looks good.
  2 2015-05-26 07:05:46 <wumpus> jonasschnelli: thanks for finding the problems, especially the bit order issue is sneaky
  3 2015-05-26 07:08:46 <jonasschnelli> wumpus: Yeah. Your fix looks nice! Was playing around with it and now i'm jealous that i couldn't find the solution you did. :)
  4 2015-05-26 07:15:14 <Balrod`> Anyone know where i could find a bitcoin Ore-Miner type game faucet for my own site?
  5 2015-05-26 08:21:33 <jonasschnelli> ThomasV: how do you solve multisig and HD? Lets say i have a two walltes on my local machine. One is a standard bip32 wallet, the other wallte is a pubkey only cosigning cold wallet. Now i generate a new 2of2 multisig address and therefore i use the next chainindex from my cold wallet (like m/0/1/0/x, where i keep a counter for x).
  6 2015-05-26 08:22:20 <jonasschnelli> When sending the only 1of2 signed transaction to my cold wallet (over QRCode, Bluetooth, etc.), how does my coldwallet know, what key is required to sign the tx?
  7 2015-05-26 08:22:57 <jonasschnelli> would adding the chaincode (like m/0/1/0/100) as metadata (not in the rawtx itself) would make sense?
  8 2015-05-26 08:23:29 <gmaxwell> Telling it (e.g. give it the redeemscript; or better further metadata) would be the obvious thing to do.
  9 2015-05-26 08:24:15 <jonasschnelli> gmaxwell: the reedemscript would allow the coldwallet to find out which key is required to sign?
 10 2015-05-26 08:25:04 <gmaxwell> It would, the same way a scanning pubkey would, but telling it precisely would be more efficient and not require it to have a coherent scanning policy with you.
 11 2015-05-26 08:26:43 <jonasschnelli> i think scanning a preshared chainpathschemes should be avoided. But IMO the reedemscript shouldn't be passed around (i need to read Bip16 in detail... sry). Isn't it sensitive?
 12 2015-05-26 08:26:59 <jonasschnelli> */scanning OR preshared...
 13 2015-05-26 08:29:08 <gmaxwell> It must be either past around or determinstically constructed from the other metadata you provide (so that it doesn't technically have to be spent)
 14 2015-05-26 08:29:29 <gmaxwell> it's absolutely not sensitive, and the signing transaction must include it.
 15 2015-05-26 08:31:37 <jonasschnelli> gmaxwell: okay. Understood. Thanks.
 16 2015-05-26 08:55:46 <Krellan> Hi all, is the top of tree working? I get compilation err in scheduler.cpp, line 54, no match for != operator.
 17 2015-05-26 09:15:38 <wumpus> travis passes, but that may be a boost version issue
 18 2015-05-26 09:18:38 <Krellan> I thought about that as well - is there a new minimum version requirement for boost?
 19 2015-05-26 09:19:30 <jonasschnelli> Krellan: official builds use 1.55.0
 20 2015-05-26 09:20:49 <jonasschnelli> Krellan: did you try "autoreconf -i"?
 21 2015-05-26 09:21:20 <jonasschnelli> Krellan: mind thinks like: https://github.com/bitcoin/bitcoin/pull/5964/files#diff-67e997bcfdac55191033d57a16d1408aR593
 22 2015-05-26 09:23:50 <Krellan> jonasschnelli: I will try that
 23 2015-05-26 09:24:39 <wumpus> I don't think so - what version of boost are you using?
 24 2015-05-26 09:25:07 <wumpus> there's even an explicit fallback for boost <1.50, but one of the intermediate versions may have a problem
 25 2015-05-26 09:27:40 <Krellan> Rats, it still fails, even after autoreconf -i, and ./autogen.sh and ./configure again.
 26 2015-05-26 09:28:27 <Krellan> #define BOOST_VERSION 105200
 27 2015-05-26 09:28:42 <Krellan> #define BOOST_LIB_VERSION "1_52"
 28 2015-05-26 09:32:41 <Krellan> Any known workaround?
 29 2015-05-26 09:33:45 <Krellan> If no workaround, perhaps configure can be changed to error out with "Your boost version is too old"
 30 2015-05-26 09:36:00 <wumpus> it's not too old, as I say, there is even a fallback for <1.50
 31 2015-05-26 09:37:26 <Krellan> Nice
 32 2015-05-26 09:37:27 <wumpus> I think no one tried it yet with that specific version of boost, there must have been an API change in between, so you'll have to add another special case, or upgrade boost
 33 2015-05-26 09:37:32 <jonasschnelli> Krellan: you error is strange. I can't see any different in boost between 1.52 and 1.55 regarding your posted code line scheduler.cppL54
 34 2015-05-26 09:37:34 <Krellan> Ah OK
 35 2015-05-26 09:37:48 <Krellan> Will pastebin my error
 36 2015-05-26 09:38:32 <jonasschnelli> wait_until() as well as cv_status have the same api (http://www.boost.org/doc/libs/1_52_0/boost/thread/cv_status.hpp / http://www.boost.org/doc/libs/1_52_0/doc/html/thread/synchronization.html#thread.synchronization.condvar_ref.condition_variable.wait_until)
 37 2015-05-26 09:41:04 <Krellan> http://pastebin.com/PeKBSFLu
 38 2015-05-26 09:44:16 <wumpus> luckily, C++ compiler errors are clean, concise and easy to understand...
 39 2015-05-26 09:44:30 <Krellan> Indeed!
 40 2015-05-26 09:45:11 <jonasschnelli> especially template overkilled boost errros!
 41 2015-05-26 12:53:17 <wumpus> added preliminary list of pulls to 0.11 release notes; https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes.md
 42 2015-05-26 12:54:02 <wumpus> anyone volunteering to add an introductionary piece to the release notes about some change they made or participated in, say, autoprune?
 43 2015-05-26 12:54:23 <jonasschnelli> impressive list.
 44 2015-05-26 12:55:11 <wumpus> it is; and that's what's left *after* removing all refactors, minor changes to this and that, etc
 45 2015-05-26 12:56:23 <wumpus> with those, it would be more than twice as large
 46 2015-05-26 12:56:36 <jonasschnelli> bff. crazy.
 47 2015-05-26 13:22:48 <fanquake> mmm, it'll be a big release. Always forget how much has changed when your always working with master.
 48 2015-05-26 13:41:49 <sdaftuar> wumpus: i'll take a stab at the release notes intro
 49 2015-05-26 13:49:49 <wumpus> sdaftuar: thanks!
 50 2015-05-26 16:49:36 <sdaftuar> petertodd: around?
 51 2015-05-26 18:54:33 <Luke-Jr> anyone have a copy of https://blog.bitcoinfoundation.org/blocksize-economics/ ? gavinandresen?
 52 2015-05-26 18:55:03 <chmod755> wtf
 53 2015-05-26 19:00:29 <gavinandresen> Luke-Jr: bah….. I don’t have a copy. I’ll see if I can get the foundation blog fixed.....
 54 2015-05-26 19:03:04 <gavinandresen> Luke-Jr: try it now
 55 2015-05-26 19:03:04 <wumpus> Luke-Jr: maybe the internet archive has?
 56 2015-05-26 19:03:32 <Luke-Jr> gavinandresen: works, thanks
 57 2015-05-26 19:10:55 <TD-Linux> neat, my random guess at .travis.yml worked
 58 2015-05-26 20:31:14 <ThomasZ> hi, in the core client, the debug dialog, I see 4 connections coming in from one IP address with the btcwire:0.2.0 useragent.  Each of them has consumed a considerable amount of data (gigabytes).
 59 2015-05-26 20:32:28 <ThomasZ> from IP 52.6.102.162, is this normal behavior?  It looks at minimum unkind...
 60 2015-05-26 20:38:06 <BlueMatt> davec: ^
 61 2015-05-26 20:38:18 <BlueMatt> dhill: ^
 62 2015-05-26 20:38:23 <BlueMatt> jrick: ^
 63 2015-05-26 20:39:06 <jrick> that a btcd node or not?
 64 2015-05-26 20:42:18 <ThomasZ> I'm running the 0.10.2 Qt bitcoin core client
 65 2015-05-26 20:42:39 <jrick> the other peer
 66 2015-05-26 20:43:26 <jrick> since btcwire is just a lib to interface with the bitcoin protocol, it may or may not be a btcd full node that's using up all that bandwidth
 67 2015-05-26 20:43:29 <jrick> but the useragent should say
 68 2015-05-26 20:44:08 <ThomasZ> the useragent is /btcwire:0.2.0/
 69 2015-05-26 20:45:36 <ThomasZ> jrick: http://imgur.com/YVMO4yn
 70 2015-05-26 20:48:15 <davec> Somebody is just using the lib then.  It would have /btcd:x.x.x/btcwire:0.2.0/ in front of it if it were a btcd node
 71 2015-05-26 20:49:48 <Luke-Jr> autoprune disables txindex? why not fail to start with both enabled?
 72 2015-05-26 20:52:29 <Balrod`> Im trying to setup a bitcoin dice game, using Crypto-Dice when i try to "setup" it doesnt allow me to connect to the wallet, everything is entered properly any idea's?
 73 2015-05-26 20:52:52 <davec> of course, that asusmes whoever is doing it doesn't claim to be something else too since that field is unvalidated in any way, people can put whatever they want in there
 74 2015-05-26 20:54:43 <ThomasZ> If someone downloads the full blockchain from the US from my machine in EU, it just feels wrong to have 3 incoming connections from one IP address.
 75 2015-05-26 20:55:10 <ThomasZ> Has anyone thought about allowing at most one incoming connection from a single IP ?  At least for sending block data to.
 76 2015-05-26 20:55:25 <ThomasZ> block-history-data
 77 2015-05-26 20:55:53 <Luke-Jr> ThomasZ: they'd have to be running 3 nodes all doing IBD for that?
 78 2015-05-26 20:56:24 <ThomasZ> Luke-Jr: I don't understand your question
 79 2015-05-26 20:57:27 <Luke-Jr> ThomasZ: Bitcoin Core at least should never open 3 outgoing connections to the same IP
 80 2015-05-26 20:58:06 <ThomasZ> sure.
 81 2015-05-26 20:58:46 <davec> btcd doesn't conect to the same addr more than once and there is a TODO to check for max peers from a single IP, but that's not implemented yet
 82 2015-05-26 21:00:57 <gmaxwell> ThomasZ: doing that would severely harm nodes on natted infrastructure (e.g. some university campuses; ... the country of quatar).  It wouldn't prevent attacks in any case, as any attacker worth their salt can just get a 10-100k node botnet.
 83 2015-05-26 21:01:07 <KrellanWk> Hey all. Any thoughts as to that boost problem I ran into last night? (scheduler.cpp does not compile, line 54, no match for != oper)
 84 2015-05-26 21:01:30 <gmaxwell> supporthing things hashcash for resource management to address attacks is something that people have been musing a bit long term.
 85 2015-05-26 21:01:57 <KrellanWk> My system is running boost 1.52 (old, I know) and the latest changes to scheduler.cpp bring out a compilation error
 86 2015-05-26 21:15:34 <hearn> ThomasZ: it'd be better to just have a way to disable serving the block chain (toggling off the service bit) and then use bittorrent or something for distribution
 87 2015-05-26 21:15:55 <hearn> ThomasZ: distributing huge files efficiently is sort of a non-core problem that i increasingly thing we should outsource to people who are much keener on it :)
 88 2015-05-26 21:15:57 <ThomasZ> gmaxwell: hashcash in this context would be for each request of blocks, and maybe for the handshake. Interesting idea.
 89 2015-05-26 21:16:41 <Balrod`> Im trying to setup a bitcoin dice game, using Crypto-Dice when i try to "setup" it doesnt allow me to connect to the wallet, everything is entered properly any idea's?
 90 2015-05-26 21:16:51 <Luke-Jr> Balrod`: wrong channel for that
 91 2015-05-26 21:16:58 <Balrod`> which channel?
 92 2015-05-26 21:17:12 <Balrod`> it is part of bitcoin dev after all
 93 2015-05-26 21:17:18 <Balrod`> deving something for btc lol
 94 2015-05-26 21:17:36 <ThomasZ> Balrod`: read the topic again :)
 95 2015-05-26 21:18:06 <Balrod`> fine whatever but can you explain why i cant connect to my wallet at all via json?
 96 2015-05-26 21:18:07 <ThomasZ> hearn: better controls would be welcome.  A black/white is too stark for me, though
 97 2015-05-26 21:18:21 <gmaxwell> hearn: I think thats an unreasonable position. Bitcoin nodes have the chain and are very very effective at serving it, moreso than bittorrent (since they understand the structure)
 98 2015-05-26 21:19:04 <gmaxwell> With the current block download logic its perfectly reasonable to rate limit the nodes and we'll likely add good controls for that soon.
 99 2015-05-26 21:19:23 <ThomasZ> I frankly don't see the advantage of bittorrent over bitcoin.  Other than that there may be more bittorrent clients out there.
100 2015-05-26 21:19:24 <hearn> bittorrent clients have already solved problems like throttling, balancing upload vs download, i think some of them try to use network-space near peers and stuff like that
101 2015-05-26 21:19:48 <ThomasZ> hearn: good thing is, its all open source code. you can just steal that code.
102 2015-05-26 21:20:06 <hearn> right. that's what i was getting at. not literally printing a message to the screen saying "go download bittorrent first" :)
103 2015-05-26 21:20:17 <gmaxwell> (we need them anyways, since even ignoring the history; bitcoin core interacts VERY poorly with buffer bloat affected routers.)
104 2015-05-26 21:21:18 <hearn> presumably bittorrent also has solved the problem of allowing peers with a partial download to upload data, too
105 2015-05-26 21:21:28 <ThomasZ> I like the ktorrent client, its written in Qt and has excellent speed throttling code.  Its GPL.  It may be easy to just use that code in bitcoin core.
106 2015-05-26 21:21:35 <gmaxwell> hearn: again, probably has nothing to do with IBD just sending out a 1MB blocks to a couple peers was causing webpages to fail to load and voip dropouts on a freshly installed 160/30mbit comcast business connection.)
107 2015-05-26 21:22:12 <hearn> huh, you can't even upload a few megabytes without issues? that's odd. i've never seen anything like that at my place
108 2015-05-26 21:22:31 <hearn> i wonder if you really have 30mbit up
109 2015-05-26 21:22:35 <hearn> (post wifi?)
110 2015-05-26 21:22:44 <gmaxwell> yea, it benchmarks fine.
111 2015-05-26 21:22:44 <Luke-Jr> for a contrasting experience, I have no problems with Bitcoin, but any time I have a torrent running I drop off IRC randomly
112 2015-05-26 21:22:55 <ThomasZ> gmaxwell: in my experience thats because of crappy router-based throttling. Too much out means the ACKs are not coming in and the ethernetwindow is reset again and again.
113 2015-05-26 21:23:00 <gmaxwell> hearn: yea, it's the trend in US broadband routers; they basically have unlimited packet buffers. :(  (because of purchasing specs for highest throughput and zero loss and whatever).
114 2015-05-26 21:23:26 <gmaxwell> I have the problem at home too, but I've intentionally not fixed it there. (it's "easy" to fix by inserting a smarter router in front of the router)
115 2015-05-26 21:24:11 <hearn> gmaxwell: what happens if you torrent from that connection?
116 2015-05-26 21:24:28 <hearn> i'm just thinking that the bittorrent community has people who spend as much time thinking about large file distribution, as we spend thinking about bitcoin
117 2015-05-26 21:24:38 <hearn> so it would make sense to me if they end up being better at it
118 2015-05-26 21:24:59 <ThomasZ> in the end its all open source code we can read and steal.
119 2015-05-26 21:26:10 <gmaxwell> hearn: modern torrent stuff uses a super low priority TCP-like protocol tunnled inside UDP.
120 2015-05-26 21:26:41 <gmaxwell> hearn: it has really high latency but won't trigger this kind of misbehavior.
121 2015-05-26 21:27:23 <gmaxwell> probably not super sutable for distributing blocks at the tip.
122 2015-05-26 21:27:52 <hearn> no, i was thinking of distributing the bulk of the chain, but obviously bittorrent wouldn't work for keeping up with the chain as it grows
123 2015-05-26 21:29:47 <ThomasZ> honestly, the bitcoin core incoming connections are really nice and well-behaved.  Its the experimental and likely buggy apps that cause the issues. Not sure how making Bitcoin Core users use torrents will be relevant.
124 2015-05-26 21:30:26 <phantomcircuit> that seems like a bad idea...
125 2015-05-26 21:31:42 <phantomcircuit> ThomasZ, so... technically literally everything in bitcoin can be shoved into a udp packet
126 2015-05-26 21:32:00 <phantomcircuit> if buffer issues are really that big of a problem
127 2015-05-26 21:32:58 <ThomasZ> sure, the idea we already have may solve it easier, though.  Have bandwidth throttling.
128 2015-05-26 21:33:33 <ThomasZ> it has the advantage that the on-the-wire protocol doesn't change.
129 2015-05-26 21:35:15 <gmaxwell> ThomasZ: the thing with bandwidth throttling is that it's not autoconfiguring.  I spent some time trying to come up with an autoconfiguring thing (with Rusty's thoughts) and found something that would work good on linux but not be portable. Have a more portable idea, but haven't had a chance to test it yet.
130 2015-05-26 21:35:38 <gmaxwell> Obviously a limiter is fully general and not hard to have; but it doesn't result in a good user expirence for most users since there will be something they need to configure.
131 2015-05-26 21:36:04 <gmaxwell> (and we'll support that for sure regardless, but I still have hope of being able to behave nicely automatically)
132 2015-05-26 21:36:20 <ThomasZ> I think asking the user what kind of internet connection she has is Ok and not an issue.
133 2015-05-26 21:36:58 <ThomasZ> Or, more specifically, I don't see any way to avoid asking in a non-streightforward setup.
134 2015-05-26 21:37:50 <ThomasZ> But I'd be happy to try out your Linux solution.
135 2015-05-26 21:37:54 <gmaxwell> ThomasZ: You're not being creative enough. In linux you can query the tcp stack after sending data and find out what RTT it's observing, and you can lower a limit when the RTT goes high (e.g. >100ms).  Seems to work fine, but it's linux only.
136 2015-05-26 21:38:28 <gmaxwell> also has the nice effect that if you don't have a stupid router then it doesn't add a gratitious limit.
137 2015-05-26 21:38:35 <ThomasZ> s/being creating/thinking low level/   ;)
138 2015-05-26 21:38:40 <gmaxwell> haha
139 2015-05-26 21:38:45 <phantomcircuit> gmaxwell, should be able to roughly estimate the bandwidth of the connection and then set the bandwidth limiter to 90% of that and just hope it works
140 2015-05-26 21:38:50 <gmaxwell> well you can do it high level by pinging one peer while feeding another.
141 2015-05-26 21:39:04 <gmaxwell> but it's ugly.
142 2015-05-26 21:39:14 <phantomcircuit> and that they're not on wifi
143 2015-05-26 21:39:21 <phantomcircuit> and... other stuff
144 2015-05-26 21:39:49 <ThomasZ> the thing that this reminds me of is the MacOs8 Photoshop setting for memory usage.  It essentially assumes your app is the only one on the system.
145 2015-05-26 21:40:53 <ThomasZ> Which may be simple to fix with a checkbox "low upstream usage"...
146 2015-05-26 21:41:03 <ThomasZ> Which is ignored by most people...
147 2015-05-26 21:41:57 <gmaxwell> Yea, may well be.  But it is really unfortunate that some people will just have a bad expirence and shut it off as fast as possible without finding the setting.
148 2015-05-26 21:42:33 <hearn> right. this is the sort of reason i am thinking bittorrent. they already wrote all the code to figure this out and be adaptive, i think
149 2015-05-26 21:43:06 <ThomasZ> i'm having a 9Gb/day upload over the last 5 days.  While I don't care, I'm guessing that people want a setting to limit that too (bytes/timeperiod)
150 2015-05-26 21:43:27 <Luke-Jr> phone users will
151 2015-05-26 21:43:46 <Luke-Jr> when Core finally gets to that point
152 2015-05-26 21:43:52 <gmaxwell> hearn: but doesn't help for the tip in any case; so ... no choice there.
153 2015-05-26 21:44:07 <hearn> yeah but if you slam your router uploading the tip, it's at least likely to be only for a few minutes instead of hours
154 2015-05-26 21:44:10 <phantomcircuit> hearn, modern bittorrent clients by default will saturate your connection unless you specify a fixed bandwidth limit
155 2015-05-26 21:44:22 <gmaxwell> hearn: it's even just a few seconds... but it's every ten minutes.
156 2015-05-26 21:44:35 <helo> when i'm not home, i don't care if my connection is slowed by e.g. bitcoin
157 2015-05-26 21:44:53 <hearn> phantomcircuit: i thought gmaxwell said they use some UDP based protocol to be lower priority than tcp
158 2015-05-26 21:45:15 <hearn> gmaxwell: more advanced block propagation protocols would also help here. like if nodes set 0xFF bloom filters
159 2015-05-26 21:45:22 <phantomcircuit> hearn, yes but that doesn't 100% fix the problem if your router has a massive buffer
160 2015-05-26 21:45:51 <phantomcircuit> the main thing is they attempt to detect available bandwidth and internally rate limit udp traffic to that
161 2015-05-26 21:46:02 <phantomcircuit> but that's complicated and lots of code
162 2015-05-26 21:46:03 <ThomasZ> hearn: lower prio is just to avoid some details in throughput. In essence get higher upload speeds.  Not lower it when another app needs data.
163 2015-05-26 21:47:37 <phantomcircuit> ThomasZ, the QoS tagging is ignored by 99.9999% of internet routers including your home isp router
164 2015-05-26 21:48:20 <phantomcircuit> really what they do is they guess how much bandwidth they have to use based on nanosecond timestamps in psh/ack
165 2015-05-26 21:48:22 <gmaxwell> hearn: there are lots of savvy things we can do, for example.. when we're hitting our limit (be it internal or just the actual link speed) we should add small delays to our INV messages, to cause less fetching from us in the first place.
166 2015-05-26 21:48:39 <gmaxwell> (so then we heal partitions but shed capacity when we don't have enough to meet demand)
167 2015-05-26 21:50:11 <ThomasZ> phantomcircuit: I agree, my personal position is that you can and should have a good default based on autodetect, but in the end the user should have a simple way to say "limit to X KiB/s"
168 2015-05-26 21:50:50 <phantomcircuit> ThomasZ, the auto detect stuff isn't compatible with tcp unless we modify the protocol significantly and then you might as well really rewrite the protocol
169 2015-05-26 21:51:21 <gmaxwell> phantomcircuit: thats not really true.
170 2015-05-26 21:51:52 <gmaxwell> phantomcircuit: e.g. ping right after sending a block. ping time over block size tells you the bandwidth, because TCP has only in-order delivery.
171 2015-05-26 21:52:16 <gmaxwell> I haven't had a chance to test it right now.
172 2015-05-26 21:53:00 <gmaxwell> but soon.
173 2015-05-26 21:55:39 <ThomasZ> midnight -> bedtime...
174 2015-05-26 21:57:22 <phantomcircuit> gmaxwell, ping is too small to accurately measure bandwidth i bet
175 2015-05-26 21:57:41 <phantomcircuit> could totally be wrong there though
176 2015-05-26 21:57:46 <ThomasZ> phantomcircuit: its not the ping that you measure. Its the block before it.
177 2015-05-26 21:58:18 <gmaxwell> what ThomasZzZ said.
178 2015-05-26 21:58:26 <gmaxwell> You're measuring the head-of-line blocking.
179 2015-05-26 21:58:32 <phantomcircuit> oh
180 2015-05-26 21:58:57 <phantomcircuit> right so basically you're adding a high resolution latency check with the ping/pong stuff
181 2015-05-26 21:59:27 <phantomcircuit> except that the block has to be processed before you'll respond to the ping
182 2015-05-26 21:59:46 <phantomcircuit> but that's limited processing now
183 2015-05-26 21:59:51 <phantomcircuit> so probably doesn't make a big difference
184 2015-05-26 22:00:48 <phantomcircuit> gmaxwell, neat
185 2015-05-26 22:01:42 <helo> latency/bandwidth from node to node may vary quite a bit, both up and down, changing throughout the day, etc
186 2015-05-26 22:01:50 <helo> so you'd do those tests very often and constantly adapt?
187 2015-05-26 22:02:04 <phantomcircuit> helo, ping after every block
188 2015-05-26 22:02:06 <phantomcircuit> it's cheap
189 2015-05-26 22:02:27 <gmaxwell> helo: we'd measure always, and use the maximum of the measurements to drive our local limiter.
190 2015-05-26 22:02:35 <gmaxwell> (with exclusions for local peers)
191 2015-05-26 22:02:42 <gmaxwell> unless the user has manually overridden.
192 2015-05-26 22:02:55 <gmaxwell> it doesn't have to be exact.
193 2015-05-26 23:08:12 <leakypat> Nice work on the sync speed on 0.10.x, new node is syncing fast!
194 2015-05-26 23:13:37 <gmaxwell> leakypat: thanks ... good to hear a positive report.
195 2015-05-26 23:49:45 <bad_duck> Hi, I just build bitcoin from master and there is a warning during make: main.cpp:4841:30: warning: unused variable ‘consensusParams’
196 2015-05-26 23:50:49 <bad_duck> seems that it's because of this last pull request: https://github.com/bitcoin/bitcoin/pull/5976/files  ,  deletion of line 4696