1 2015-07-06 00:03:51 <zeninfinity> hi folk, i have some questions about best pools and about BIP66. For Pool, what is the best pool to join for now? and should i upgrade my antminer machines in order to confirm BIP66 ? thx
  2 2015-07-06 00:05:55 <belcher> eligius, p2pool
  3 2015-07-06 00:08:20 <mr_burdell> ok, I have a 0.9.4 node running with an alert on any differences between that and my 0.10 nodes
  4 2015-07-06 00:09:28 <belcher> mr_burdell https://en.bitcoin.it/wiki/Comparison_of_mining_pools#SPV_Mining_.2F_Old_Bitcoin_Core
  5 2015-07-06 00:16:10 <zeninfinity> mr_burdell> thx , and for the update of machine ?
  6 2015-07-06 00:16:58 <mr_burdell> zeninfinity: i don't think you need to update the miners themselves... I think this is a pool issue
  7 2015-07-06 00:17:08 <mr_burdell> I don't mine myself though, so you should doublecheck
  8 2015-07-06 00:18:55 <zeninfinity> mr_burdell: thx
  9 2015-07-06 00:58:54 <phantomcircuit> hmm what cli parameter do i need to keep debug.log from being truncated?
 10 2015-07-06 01:00:35 <harding> phantomcircuit: -debug will supress truncating, I think.
 11 2015-07-06 01:01:08 <harding> Also looks like -shrinkdebugfile=0 will do it
 12 2015-07-06 01:02:18 <phantomcircuit> ah yeah
 13 2015-07-06 01:13:49 <phantomcircuit> harding, thanks
 14 2015-07-06 01:24:52 <leakypat> Been like that for at least the last 3 hours
 15 2015-07-06 01:25:13 <leakypat> Sorry ignore
 16 2015-07-06 01:31:34 <midnightmagic> Does anyone here run a system with > 16 cores and at least 128GB of RAM? And, can you tell me what kernel you're on and whether it's been stable for you?
 17 2015-07-06 01:32:06 <phantomcircuit> midnightmagic, i've run a system like that just with the default debian kernel
 18 2015-07-06 01:32:15 <phantomcircuit> under fairly extensive load
 19 2015-07-06 01:32:20 <midnightmagic> phantomcircuit: what uname -a?
 20 2015-07-06 01:32:24 <phantomcircuit> (8 bitcoind instances load balancing stuff)
 21 2015-07-06 01:32:30 <phantomcircuit> midnightmagic, sadly dont have it anymore
 22 2015-07-06 01:32:34 <phantomcircuit> :(
 23 2015-07-06 01:33:58 <midnightmagic> phantomcircuit: When I run mine on 3.13.0 it's super frickin unstable. spontaneous reboots, etc. So I figured, if someone else is running an equivalently absurd machine, if their kernel is stable then I can figure out whether I should update the OS itself based on what kernel is stable for *them*.
 24 2015-07-06 01:34:36 <midnightmagic> ("down"grading to 3.5.0 returns it to rock-solid, months-long stability)
 25 2015-07-06 01:35:04 <midnightmagic> maybe I'll ping wizkid..
 26 2015-07-06 01:35:12 <phantomcircuit> that's odd
 27 2015-07-06 01:38:20 <midnightmagic> (it's uh..  on-topic-ish related because this is the machine I build my gitian.sigs on)
 28 2015-07-06 02:28:43 <s1w> midnightmagic: lol
 29 2015-07-06 03:36:32 <harding> Update to the Bitcoin.org fork notice.  Reviews requested: https://github.com/bitcoin-dot-org/bitcoin.org/pull/946
 30 2015-07-06 03:46:42 <squidicuz> harding, missing a <p> https://github.com/bitcoin-dot-org/bitcoin.org/commit/d406a9af8b292534fe7496512c47d1cbe68a479c#diff-cc26f4e2ffa8941e6369c23976f0ef3eR99
 31 2015-07-06 03:48:46 <harding> squidicuz: indeed.  Thanks.
 32 2015-07-06 03:50:31 <squidicuz> yup. looks good otherwise.  Might want to break up the last paragraph, between: "list of forks." AND  "Reports that"   imo
 33 2015-07-06 03:51:05 <squidicuz> though, i dunno
 34 2015-07-06 03:52:36 <harding> squidicuz: just gave it a try in my local preview, I think I'm going to keep that as one paragraph so it's clear that the whole thing is part of the update.  Thanks for the suggestion though.
 35 2015-07-06 03:52:48 <squidicuz> okay :)
 36 2015-07-06 03:54:10 <drazisil> it's very helpful you linked what SPV was, I've had no clue what you guys meant :)
 37 2015-07-06 03:54:32 <harding> drazisil: were you the one who suggested it on Reddit?  If so, thanks!
 38 2015-07-06 03:54:40 <drazisil> nope, not i
 39 2015-07-06 04:02:13 <gmaxwell> dunno if people noticed before but the orphaned 363999 suggest some spv miners are including transactions.
 40 2015-07-06 04:02:40 <gmaxwell> as it's a v3 block on that invalid fork filled with txn.
 41 2015-07-06 04:03:41 <Luke-Jr> gmaxwell: it isn't a SPV miner, it's an old bitcoind with new Eloipool :/
 42 2015-07-06 04:04:12 <gmaxwell> Luke-Jr: ah when you upgraded elopool you didn't make it reject old bitcoind like p2pool does?
 43 2015-07-06 04:04:29 <Luke-Jr> no, though I added that today
 44 2015-07-06 04:05:13 <Luke-Jr> the "upgrade" commit was intentionally minimal so people could merge it into old branches with their own changes :/
 45 2015-07-06 04:05:43 <Luke-Jr> Eloipool doesn't have proper releases, just git branches that people usually fork
 46 2015-07-06 06:44:37 <jonasschnelli> wumpus: i have detected some differences between OSX/Linux in the CSubNet::ToString() function (or the constructor).
 47 2015-07-06 06:45:05 <wumpus> jonasschnelli: differences?
 48 2015-07-06 06:45:22 <jonasschnelli> wumpus: 1:2:3:4:5:6:7:8/fff:ffff:ffff:ffff:ffff:ffff:ffff:fff0 should result in 1:2:3:4:5:6:7::/fff:ffff:ffff:ffff:ffff:ffff:ffff:fff0 IMO (mind the 7:: at the end).
 49 2015-07-06 06:45:35 <jonasschnelli> But on linux i get 1:2:3:4:5:6:7:0/fff:ffff:ffff:ffff:ffff:ffff:ffff:fff0
 50 2015-07-06 06:45:56 <jonasschnelli> (i think both systems i'm testing are 64bit)
 51 2015-07-06 06:46:10 <wumpus> both are valid
 52 2015-07-06 06:47:04 <jonasschnelli> okay... i just recognized that the unittests failing... maybe i remove the non CIDR -> std. netmask tests.
 53 2015-07-06 06:47:07 <wumpus> we fork this out to the posix sockets C API, which is not guaranteed to behave the same way
 54 2015-07-06 06:47:24 <wumpus> the requirement is that the result, parsed, results in the same CSubnet
 55 2015-07-06 06:48:59 <jonasschnelli> wumpus: Okay. I'll then remove the failing unit tests of the CSubNet::ToString() function.
 56 2015-07-06 06:49:18 <wumpus> apart from that I the formatting has some freedom, there's no  need to put any stringent requirements on e.g. shortest output here
 57 2015-07-06 06:49:48 <wumpus> remove, or replace by sensible tests as I mention above
 58 2015-07-06 06:50:45 <wumpus> it's too bad that travis can't run the unit tests on osx, like it does for windows through wine
 59 2015-07-06 06:52:12 <jonasschnelli> wumpus: Yes. This is somehow impossible. Would require a osx in a VM which is even forbidden by apples TOC. But i saw some osx jenkins nodes  in the past...
 60 2015-07-06 06:52:29 <wumpus> or an 'oine' :-)
 61 2015-07-06 06:53:12 <jonasschnelli> wumpus: Yeah. Happy reverse-engineering. :)
 62 2015-07-06 07:03:04 <rmwb> osx in a vm is OK, as long as it's on apple hardware http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2005793
 63 2015-07-06 07:06:22 <jonasschnelli> rmwb: Yeah. But it's a heavy restriction. You can't then reuse existing server infractrusture (mostly running on linux) for any types for osx CI.
 64 2015-07-06 07:08:32 <wumpus> ideally, the test infrastructure would be hardware independent, apple with their stupid legal restrictions again makes it difficult for us
 65 2015-07-06 07:08:48 <SigmundAlpha> jonasschnelli: You don't need a full OS X machine to build for apple products. http://blog.sigmundalpha.com/developing-for-os-x-on-linux/
 66 2015-07-06 07:09:05 <SigmundAlpha> Its far from perfect, and there is no real testing, but you can at least build
 67 2015-07-06 07:09:07 <CodeShark> I've managed to get OS X to even run under windows...but it's finicky
 68 2015-07-06 07:09:24 <wumpus> SigmundAlpha: that's what we do in the gitian builder - but the issue here is running the unit tests on osx-emulation
 69 2015-07-06 07:09:32 <jonasschnelli> Technically this is no problem. But we where arguing about the TOC.
 70 2015-07-06 07:10:37 <SigmundAlpha> The TOC only applies on the operating system at that point, as long as your only using the cctools to build, you just have to follow the Apple Open Source License.
 71 2015-07-06 07:10:38 <jonasschnelli> You can't emulate a OSX environment one a linux machine without breaking apples ToC (unless you use non-exiting apple severs)
 72 2015-07-06 07:10:42 <wumpus> SigmundAlpha: cross-building for osx certainly works (although it requires signing in to apple's crappy website and downloading an ungainly large package to extract a few includes and ABI libraries)
 73 2015-07-06 07:11:08 <SigmundAlpha> Perhaps investing some time into http://www.darlinghq.org/ would be worth it.
 74 2015-07-06 07:11:59 <wumpus> SigmundAlpha: thanks for the tip, that looks like an 'oine', good stuff
 75 2015-07-06 07:13:07 <SigmundAlpha> Have no idea what a 'onie' is, but darling is far from perfect.  Some serious time would be needed to make the testing env even worth using.
 76 2015-07-06 07:13:57 <SigmundAlpha> Been working on getting a decent development env on linux for OS X for almost a month now.
 77 2015-07-06 07:16:03 <jonasschnelli> As long as apples frameworks are so heavy tied to their hardware and environment, this will never succeed.
 78 2015-07-06 07:17:07 <wumpus> the idea would be to not use the apple frameworks, but reimplementations, like wine (and in a lesser degree, mingw) does
 79 2015-07-06 07:18:25 <SigmundAlpha> Exactly what wumpus said.  You want to reimpliment the apple-specific development libraries (which are open source now), and provide a compatibility layer for the difference between the linux kernel and the apple one.
 80 2015-07-06 07:19:08 <jonasschnelli> There the problem start. Apple uses Obj-C with all it's NS (from NeXT) base classes. This would take such a big effort...
 81 2015-07-06 07:19:27 <SigmundAlpha> I admit the scope of the project is too broad for me to make an assumption on the feasibility, but I think 'never happen' is a little hyperbolic.
 82 2015-07-06 07:19:48 <jonasschnelli> SigmundAlpha: IMO apple did not open source any of it's NS classes.
 83 2015-07-06 07:20:03 <jonasschnelli> but anyways, this is something to discuss outside of #bitcoin-dev. :)
 84 2015-07-06 07:22:23 <wumpus> SigmundAlpha: wine happened too; also for the tests we don't require a full emulation, just of roughly the parts that we use. E.g. no UI stuff would be fine.
 85 2015-07-06 07:39:04 <stonecoldpat> hi, in IsStandardTx(), what does fIsBareMultisigStd stand for ?
 86 2015-07-06 07:39:47 <sipa> non-p2sh multisig
 87 2015-07-06 07:40:13 <stonecoldpat> ah ok thanks, so the multisig is in the output instead of input
 88 2015-07-06 07:40:27 <sipa> indeed
 89 2015-07-06 08:22:59 <wumpus> jonasschnelli: I remember that you had a branch with tests for post-#6297 AmountFromValue?
 90 2015-07-06 08:23:14 <jonasschnelli> wumpus: yeah... let me search
 91 2015-07-06 08:24:00 <jonasschnelli> wumpus: https://github.com/jonasschnelli/bitcoin/commit/7a7cdee66281db08dc33d405e60a5878a0388dd2
 92 2015-07-06 08:24:34 <wumpus> jonasschnelli: thanks!
 93 2015-07-06 08:54:46 <wumpus> jonasschnelli: https://github.com/bitcoin/bitcoin/pull/6379
 94 2015-07-06 08:55:00 <jonasschnelli> wumpus: Nice. Testing...
 95 2015-07-06 08:56:27 <CodeShark> really?!
 96 2015-07-06 08:56:37 <CodeShark> we're going to use scientific notation in the rpc? :)
 97 2015-07-06 08:56:51 <wumpus> CodeShark: we need to support the whole JSOn standard for numbers, that includes scientific notation
 98 2015-07-06 08:57:10 <wumpus> (remember that this is for parsing, not emitting)
 99 2015-07-06 08:59:39 <CodeShark> I suppose for quick manual entry it can be useful in some instances - but I probably would never use it programmatically :p
100 2015-07-06 09:00:09 <wumpus> I wouldn't, either. But for better or worse, apparantly a lot of JSON implementations generate them.
101 2015-07-06 09:02:09 <wumpus> (which probably means that people are using doubles instead of fixed-point monetary representations at their end, but ok :/)
102 2015-07-06 09:02:44 <CodeShark> for financial stuff I'd stick to decimal integers in all APIs...but meh...not sure how much of my problem it really is if other people do that
103 2015-07-06 09:02:57 <CodeShark> or other people don't do that, rather
104 2015-07-06 09:03:19 <CodeShark> fixed point decimal ftw :)
105 2015-07-06 09:03:27 <wumpus> to be *honest* that people use PHP worries me more @ https://github.com/bitcoin/bitcoin/issues/6297 :-)
106 2015-07-06 09:04:56 <CodeShark> PHP has perfect precision for decimal integers regardless of numeric datatype...but the same thing cannot be said for nonintegers
107 2015-07-06 09:07:42 <CodeShark> http://stackoverflow.com/questions/4921466/php-rounding-error
108 2015-07-06 09:07:51 <jouke> php rules
109 2015-07-06 09:08:45 <jouke> Ok, well, that is overstating it, but I like to use php :P
110 2015-07-06 09:09:25 <CodeShark> this isn't really a php issue specifically :)
111 2015-07-06 09:09:31 <CodeShark> it's a base incompatibility issue
112 2015-07-06 09:09:53 <CodeShark> 5 is not divisible by 2...
113 2015-07-06 09:13:03 <CodeShark> {
114 2015-07-06 09:13:03 <CodeShark> float f = 1234.12345678F;
115 2015-07-06 09:13:03 <CodeShark> #include <stdio.h>
116 2015-07-06 09:13:03 <CodeShark> int main()
117 2015-07-06 09:13:03 <CodeShark> printf("%2f\n", f);
118 2015-07-06 09:13:03 <CodeShark> return 0;
119 2015-07-06 09:13:04 <CodeShark> }
120 2015-07-06 09:13:19 <CodeShark> output: 1234.123413
121 2015-07-06 09:13:24 <CodeShark> fun stuff :)
122 2015-07-06 09:14:02 <CodeShark> it's easy to avoid all this stuff by just using integers everywhere (except perhaps in UI)
123 2015-07-06 09:27:45 <CodeShark> as for decimal scientific notation, if you really want to go that route just use separate fields for mantissa and exponent :)
124 2015-07-06 09:27:55 <CodeShark> much less error-prone than parsing it
125 2015-07-06 09:28:13 <CodeShark> for APIs, etc...
126 2015-07-06 09:29:16 <sipa> ideally , i think our api should accept string-encoded btc, or integer satoshis
127 2015-07-06 09:29:36 <sipa> but backward compatibility etc...
128 2015-07-06 09:31:33 <wumpus> accepting string-encoded BTC would be trivial
129 2015-07-06 09:32:04 <sipa> maybe we should just do that
130 2015-07-06 09:32:10 <wumpus> as everything is already hadndled as string, it's literally a matter of adding one if clause
131 2015-07-06 09:32:17 <sipa> make ValueToAmount accept strings as well
132 2015-07-06 09:32:17 <wumpus> only *emitting* it would bump against problems with backward compatibility
133 2015-07-06 09:32:21 <wumpus> right
134 2015-07-06 09:32:25 <sipa> right
135 2015-07-06 09:32:43 <sipa> and more options to support means more configurationd to test
136 2015-07-06 09:32:53 <wumpus> CodeShark: we realize that, you're really preaching against the choir
137 2015-07-06 09:33:07 <CodeShark> so why are we supporting scientific notation? :)
138 2015-07-06 09:33:14 <sipa> because we have to
139 2015-07-06 09:33:18 <wumpus> BECAUSE WE NEED TO SUPPORT THE FULL JSON STANDARD
140 2015-07-06 09:33:23 <CodeShark> ok ok...
141 2015-07-06 09:33:24 <wumpus> I said that, I quoted the issue
142 2015-07-06 09:33:43 <wumpus> stop trolling please
143 2015-07-06 09:33:49 <sipa> and JSOn only has a number type
144 2015-07-06 09:33:55 <sipa> no distinction between integers and doubles even
145 2015-07-06 09:35:03 <CodeShark> well, the thing is that it's a potentially serious issue - a source of many potential bugs - I don't think it's a troll...I've seen many apps that screw this up
146 2015-07-06 09:35:16 <CodeShark> and we're talking about money
147 2015-07-06 09:35:20 <wumpus> ...
148 2015-07-06 09:35:26 <wumpus> /kick CodeShark
149 2015-07-06 09:35:28 <CodeShark> lol
150 2015-07-06 09:35:55 <sipa> CodeShark: fully totally agree
151 2015-07-06 09:36:18 <sipa> but that mistake was made when the JSON RPC api was introruced
152 2015-07-06 09:36:29 <sipa> we can define a new json api to fix it
153 2015-07-06 09:36:43 <CodeShark> well, can we at least actively discourage the use of nondecimal floating point? :)
154 2015-07-06 09:36:44 <wumpus> yes, as said, *we are aware of the risks*, we explicitly don't use any doubles in our code when handling monetary numbers
155 2015-07-06 09:36:56 <sipa> CodeShark: define a new rpc api
156 2015-07-06 09:36:59 <wumpus> stop preaching
157 2015-07-06 09:37:45 <sipa> there is really no way to fix this but introducing a new api
158 2015-07-06 09:38:14 <wumpus> yes, switch to strings
159 2015-07-06 09:38:28 <wumpus> which I proposed, no, submitted code for more than ayear ago, but no one was interested
160 2015-07-06 09:38:49 <CodeShark> wumpus: just to be clear it's not you I'm worried about ;)
161 2015-07-06 09:38:53 <wumpus> no one actually using bitcoind, that is
162 2015-07-06 09:39:28 <wumpus> now this is something that breaks usage for users, and I rather make it working again than preach them on what they should do
163 2015-07-06 09:40:37 <CodeShark> anyhow, I'll make you happy and stop arguing, wumpus :)
164 2015-07-06 09:40:44 <wumpus> thanks.
165 2015-07-06 09:40:58 <CodeShark> there are other much more serious issues at hand :)
166 2015-07-06 09:43:10 <CodeShark> like how big should our bike shed be?
167 2015-07-06 09:46:04 <wumpus> CodeShark: sipa: https://github.com/bitcoin/bitcoin/pull/6380/files
168 2015-07-06 09:46:44 <sipa> and which name we'll give to the unit for expressing a discussion level equal to 1/1000 of a bikeshed discussion
169 2015-07-06 09:46:57 <sipa> a millibikeshed, or a bik?
170 2015-07-06 09:47:05 <CodeShark> let's use tonal numbers
171 2015-07-06 09:47:30 <CodeShark> spelled out
172 2015-07-06 09:47:34 <wumpus> bikesheddodyne
173 2015-07-06 09:50:45 <CodeShark> ParseMoney is a lot of fun :)
174 2015-07-06 09:50:48 <wumpus> or, the force with which bikes are shed. Needs +milli I guess.
175 2015-07-06 09:51:40 <sipa> off topic: given that the SI unit for mass is kilogram, i think we should use millikilograms instead of grams
176 2015-07-06 09:51:49 <sipa> and a tonne would be a kilokilogram
177 2015-07-06 09:52:37 <drazisil> I'm so confused how this went from bitcoin to bikes.
178 2015-07-06 09:53:15 <wumpus> heh
179 2015-07-06 09:53:18 <CodeShark> don't think about it too hard - you'll only get more confused
180 2015-07-06 09:53:35 <wumpus> because bikes are decentralized transportation
181 2015-07-06 09:53:40 <drazisil> it's 6am and I have yet to sleep, too late
182 2015-07-06 09:55:02 <CodeShark> so the value unit is always in bitcoins, right, wumpus? 1000 == 1000.0 == "1000.00"
183 2015-07-06 09:55:23 <wumpus> CodeShark: yes.
184 2015-07-06 09:55:38 <wumpus> that's always been the case, nothing new there
185 2015-07-06 09:55:51 <CodeShark> could we support base phi?
186 2015-07-06 09:56:33 <sipa> i endorse fibcoins as unit
187 2015-07-06 09:56:35 <CodeShark> so in all seriousness...let me get this straight...we used to support strings. we stopped supporting strings. things broke?
188 2015-07-06 09:56:36 <wumpus> yes, I even have a branch somewhere that adds base pi support, could be easily adopted
189 2015-07-06 09:56:43 <sipa> CodeShark: no
190 2015-07-06 09:56:47 <CodeShark> or we never supported strings?
191 2015-07-06 09:56:51 <wumpus> no, we never supported strings
192 2015-07-06 09:57:02 <sipa> we switched from a third party json parser to a builtin one
193 2015-07-06 09:57:09 <CodeShark> ah
194 2015-07-06 09:57:10 <wumpus> we switched to another JSON parser, and things broke
195 2015-07-06 09:57:13 <CodeShark> got it
196 2015-07-06 09:57:39 <sipa> and this new json parser has as nice feature that it preserves the string representation of input, if requested
197 2015-07-06 09:57:42 <wumpus> the old one supported scientific notation, with the new one this isn't the case, so we have to implement it ourself
198 2015-07-06 09:58:06 <sipa> no, that's not true
199 2015-07-06 09:58:15 <sipa> univalue supports scientific notation
200 2015-07-06 09:58:41 <wumpus> yes, ok, it parses it, but cannot convert it to any kind of value
201 2015-07-06 09:58:46 <wumpus> no need to argue about this
202 2015-07-06 09:59:20 <sipa> it can convert it to double
203 2015-07-06 09:59:33 <sipa> but we'd rather not do that
204 2015-07-06 09:59:39 <wumpus> right.... yes, it can....
205 2015-07-06 10:00:10 <sipa> it wouldn't hurt, because it's exactly the same as what json spirit did
206 2015-07-06 10:00:21 <sipa> but we can much better now :)
207 2015-07-06 10:00:21 <wumpus> where it did hurt in some cases
208 2015-07-06 10:00:31 <sipa> did it?
209 2015-07-06 10:00:46 <sipa> i was not aware
210 2015-07-06 10:00:51 <wumpus> yes, there's a issue on stack overflow, where interpretation of doubles caused an amount to be one satoshi off
211 2015-07-06 10:01:02 <sipa> oh
212 2015-07-06 10:01:15 <wumpus> no idea why it happened, but that's the kind of thing what can happen if you use doubles for monetary amounts
213 2015-07-06 10:01:25 <sipa> yeah
214 2015-07-06 10:01:56 <sipa> also, we can now detext incorrect rounding
215 2015-07-06 10:05:19 <CodeShark> not sure it's necessary to add " or string" to the error message
216 2015-07-06 10:05:30 <CodeShark> because even if it's a string it's expected to be in a numeric format
217 2015-07-06 10:05:46 <wumpus> woohoo, let's bikeshed the error message
218 2015-07-06 10:05:50 <CodeShark> yes!
219 2015-07-06 10:06:12 <CodeShark> and you might want to put an empty line before the CAmount amount;
220 2015-07-06 10:06:13 <wumpus> that error message is only hit when, say, an array or object is passed in
221 2015-07-06 10:06:19 <wumpus> in which case it's perfectly valid
222 2015-07-06 10:07:36 <sipa> saying "or string-encoded number" would even be incorrect, as a non-number encoded as a string would not trigger the message
223 2015-07-06 10:07:50 <sipa> so it is totally accurate, and i think nothing more accurate is possiblr
224 2015-07-06 10:07:54 <CodeShark> right - it refers to the type
225 2015-07-06 10:07:58 <CodeShark> I'm just teasing :)
226 2015-07-06 10:08:04 <sipa> ok, good :)
227 2015-07-06 10:08:16 <CodeShark> looks ok, wumpus :)
228 2015-07-06 10:08:36 <sipa> wumpus: do you have a PR for json parsing numbers?
229 2015-07-06 10:08:45 <sipa> *amounts
230 2015-07-06 10:09:28 <wumpus> sipa: https://github.com/bitcoin/bitcoin/pull/6379
231 2015-07-06 10:10:25 <CodeShark> ah, ParseFixedPoint is even more fun than ParseMoney :)
232 2015-07-06 10:10:53 <sipa> wumpus: heh, why did i not get an email?
233 2015-07-06 10:12:29 <wumpus> CodeShark: it should be a direct mapping of http://www.json.org/number.gif
234 2015-07-06 10:16:19 <CodeShark> haven't tested it but it looks right
235 2015-07-06 10:17:05 <CodeShark> you say there's still a problem with it?
236 2015-07-06 10:19:01 <wumpus> not that I know - it passes the unit tests (both new and old), RPC tests, as well as travis
237 2015-07-06 10:19:46 <CodeShark> only thing I don't see in the diagram are the bounds
238 2015-07-06 10:19:48 <wumpus> (which builds and tests on all supported platforms, except can't test on osx)
239 2015-07-06 10:20:58 <CodeShark> want me to test it on osx for you?
240 2015-07-06 10:21:04 <wumpus> yes, the requirement that it needs to fit in 18 digit fixed-point is ours, there is no reason to handle more
241 2015-07-06 10:26:01 <CodeShark> which executable is the test?
242 2015-07-06 10:26:27 <CodeShark> test_bitcoin?
243 2015-07-06 10:26:56 <sipa> yes
244 2015-07-06 10:27:00 <sipa> for the unit tests
245 2015-07-06 10:27:10 <sipa> there is a python framework for rpc/p2p tests too
246 2015-07-06 10:27:19 <CodeShark> c$ ./test_bitcoin
247 2015-07-06 10:27:19 <CodeShark> *** No errors detected
248 2015-07-06 10:27:19 <CodeShark> Running 156 test cases...
249 2015-07-06 10:27:47 <sipa> short prompt
250 2015-07-06 10:27:54 <CodeShark> lol
251 2015-07-06 10:27:59 <CodeShark> copy/paste error :p
252 2015-07-06 10:28:12 <CodeShark> that's not the important line, though
253 2015-07-06 10:28:43 <CodeShark> so is that what it's supposed to do? no fun animations?
254 2015-07-06 10:29:01 <sipa> try sl
255 2015-07-06 10:29:27 <CodeShark> sl?
256 2015-07-06 10:30:17 <CodeShark> I almost destroyed a display once because of that...so no thank you :p
257 2015-07-06 10:31:26 <sipa> CodeShark: aptitude install sl :)
258 2015-07-06 10:31:33 <sipa> (or equivalent)
259 2015-07-06 10:32:10 <wumpus> ponysay "*** No errors detected"
260 2015-07-06 10:32:32 <wumpus> destroyed a display? you take no half measures, do you? :p
261 2015-07-06 10:33:36 <CodeShark> lol sipa
262 2015-07-06 10:34:44 <CodeShark> so is there anything else I can help with regarding os x, wumpus?
263 2015-07-06 10:55:22 <wumpus> CodeShark: qa/pulltester/rpc-tests.sh maybe
264 2015-07-06 10:56:06 <yang> Are packages libdb4.8-dev still required after the bitcoin binary has been compiled or can they be removed from the system ?
265 2015-07-06 10:56:28 <CodeShark> depends on whether you've statically or dynamically linked
266 2015-07-06 10:56:36 <CodeShark> probably don't want to remove it :)
267 2015-07-06 10:56:42 <wumpus> whether required or not, I'd recommend against removing it
268 2015-07-06 10:56:44 <sipa> no, you don't need it
269 2015-07-06 10:56:52 <sipa> even when dynamically linked
270 2015-07-06 10:56:56 <yang> i mean it prohibits the installation of more recent libdb5.3-dev
271 2015-07-06 10:57:03 <sipa> you only need libdb4.8 at runtimr
272 2015-07-06 10:57:06 <wumpus> this likely won't be the last bitcoin executable you'll compile
273 2015-07-06 10:57:34 <sipa> bitcoin can be compiled against 5.3
274 2015-07-06 10:57:41 <wumpus> but if you  always compile yourself, you may as well switch to newer bdb
275 2015-07-06 10:57:44 <sipa> with --with-incompatible-bdb
276 2015-07-06 10:58:00 <wumpus> it's just that it won't work with bitcoind's compiled against older bdb anymore but you may not care
277 2015-07-06 10:58:06 <wumpus> +the wallet
278 2015-07-06 10:58:26 <CodeShark> unless you are planning on sharing the wallet with someone who uses db4.8 just use 5.3 :)
279 2015-07-06 10:58:38 <yang> ok
280 2015-07-06 10:58:48 <wumpus> "sharing the wallet" hehe
281 2015-07-06 10:59:18 <CodeShark> No rpc tests to run. Wallet, utils, and bitcoind must all be enabled
282 2015-07-06 10:59:18 <CodeShark> $ ./rpc-tests.sh
283 2015-07-06 10:59:48 <wumpus> oh, yeah, never mind then
284 2015-07-06 14:29:42 <Luke-Jr> where did GAit go? :x
285 2015-07-06 14:30:44 <sipa> he morphed into MrTratta
286 2015-07-06 14:32:21 <Luke-Jr> i c
287 2015-07-06 14:33:53 <MrTratta> thanks sipa
288 2015-07-06 15:13:01 <Guest4587> quit
289 2015-07-06 16:28:09 <hearn> sipa: heya. what's the difference between bip66dersig.py and bip66dersig-p2p.py in the regtests?
290 2015-07-06 16:28:18 <hearn> sipa: to me they look like the latter is a finished version of the former?
291 2015-07-06 16:34:20 <sdaftuar> hearn: that's basically right.  when i was building the python p2p testing framework (PR #5981) i thought it'd be helpful to finish that test
292 2015-07-06 16:34:54 <sdaftuar> (alternatively the rpc-only version could be completed using submitblock)
293 2015-07-06 16:37:41 <StephenM347> Quick question, internally, uint256's are stored in little endian, but GetHex() prints in Big endian. When I sign the binary encoded By SignatureHash(...).GetHex(), though, it doesn't work. Reversing the hex works, though. Do signatures always sign the little endian uint256?
294 2015-07-06 16:48:59 <sipa> StephenM347: bitcoin treats all cryotographic data as byte sequrnces
295 2015-07-06 16:49:11 <sipa> hearn: no clue, sdaftuar knows better
296 2015-07-06 16:49:31 <hearn> sdaftuar: hm
297 2015-07-06 16:49:38 <hearn> sdaftuar: so what is the purpose of having both?
298 2015-07-06 16:49:41 <hearn> sdaftuar: shouldn't one be deleted?
299 2015-07-06 16:49:41 <sipa> StephenM347: ecdsa internally interprets the passed message as big endian
300 2015-07-06 16:51:09 <sipa> StephenM347: but that should not matter, unless you're implementing your own signing code
301 2015-07-06 16:52:39 <StephenM347> The signing is being done externally. Signing SignatureHex(...).GetHex() does not work, but signing the byte-wise reverse of that value works. I don't think it's a problem with the python ECDSA library
302 2015-07-06 16:53:25 <StephenM347> sipa: (SignatureHash(...), I mean)
303 2015-07-06 17:06:57 <sdaftuar> hearn: yeah that sounds reasonable to me
304 2015-07-06 17:31:42 <kimon> Hello there!
305 2015-07-06 17:32:41 <kimon> Please, any developer, take a look at this thread https://bitcointalk.org/index.php?topic=1110383
306 2015-07-06 17:33:19 <kimon> May be this is some Bitcoin Core bag
307 2015-07-06 17:34:16 <morcos> wumpus: not sure if you want comments on the fee estimation changes for 0.11 release notes, but i put some at #6383
308 2015-07-06 17:38:42 <kimon> guys please help investigate this problem
309 2015-07-06 17:50:37 <michagogo> wumpus: w in wine doesn't stand for windows afaik
310 2015-07-06 17:51:42 <michagogo> 10:16:03 <jonasschnelli> As long as apples frameworks are so heavy tied to their hardware and environment, this will never succeed. <-- That's not likely to change. The whole philosophy with Apple devices (Macs and iOS) is that the hardware and software are designed together an one ~inseparable unit
311 2015-07-06 17:51:55 <michagogo> as*
312 2015-07-06 18:15:19 <wumpus> morcos: thanks!
313 2015-07-06 18:18:13 <kimon> can anyone answer me?
314 2015-07-06 18:22:01 <PRab> Is it worth writing up an issue that a hardcrash caused 0.11rc2 to need to rebuild the block DB?
315 2015-07-06 18:22:14 <PRab> (My system lost power)
316 2015-07-06 18:22:56 <wumpus> PRab: I wouldn't be surprised if there's issues about rebuilds necessary after power cycle already, especially on windows, maybe post there
317 2015-07-06 18:23:13 <wumpus> kimon: can you shortly describe the issue?
318 2015-07-06 18:24:32 <wumpus> PRab: https://github.com/bitcoin/bitcoin/issues/5610
319 2015-07-06 18:24:46 <kimon> wumpus, command "bitcoin-cli sendfrom <fromaccount> <tobitcoinaddress> <amount>" workin too slow. about 60 sec, on 240mb wallet.dat
320 2015-07-06 18:24:47 <PRab> wumpus: Yep, I just saw that also.
321 2015-07-06 18:24:55 <wumpus> seems not windows-only anymore either
322 2015-07-06 18:25:39 <wumpus> kimon: ok yes that's somewhat expected, if your wallet contains lots of unspent outputs, the optimization algorithm to choose fitting outputs for a spend will take a longer time
323 2015-07-06 18:26:14 <jonasschnelli> kimon: i know that there are performance issues with large wallets. Because I'm rewriting most of the wallets code, i try to track down the performance issue and deliver solutions.
324 2015-07-06 18:26:43 <kimon> jonasschnelli: Execute command bitcoin-cli listunspent take a 5 second and return 107 unspent outputs;
325 2015-07-06 18:27:02 <wumpus> kimon: also if your node is catching up in the background, all RPC calls can be really slow
326 2015-07-06 18:27:21 <jonasschnelli> kimon: you have to know that bitcoin-cores wallet in no high scalable solution. It's just a simple reference implementation.
327 2015-07-06 18:28:12 <jonasschnelli> kimon: but there are serval point where things can be optimized. And during core-wallet development i'll certainly will take a close look there.
328 2015-07-06 18:29:31 <denisx> is there a stresstest running right now? my relaynetworkclient is scrolling like crazy
329 2015-07-06 18:30:30 <harding> denisx: we were just talking about that in #bitcoin
330 2015-07-06 18:31:18 <kimon> jonasschnelli: thank you! and can you advise me some high scalable solution? Now in my project I have a ~1500 active bitcoin-addresses with total ~20000 input transaction and ~5000 output transactions in last half of the year.
331 2015-07-06 18:31:19 <jonasschnelli> denisx: mempoolsize: 19606 (yes there is a stresstest)
332 2015-07-06 18:33:13 <jonasschnelli> kimon: if a solution for your problem is urgent, you might hire a developer to build a custom wallet solution for your business... or, much better, try to help bitcoin-core by supporting development resources (manpower).
333 2015-07-06 18:34:24 <pigeons> i notice you're using the send-from/accounts feature. i don't know if that has any effect on your performance issue, but try comparing with not using that feature
334 2015-07-06 18:35:26 <wumpus> shouldn't matter for performance; the accounts don't influence input selection
335 2015-07-06 18:48:35 <kimon> jonasschnelli: my problem is not urgent. The next month I do not think that it would be critical for me. What do you mean "supporting development resources (manpower)"?
336 2015-07-06 18:51:34 <jonasschnelli> kimon: your wallet size looks like you are running a bitcoin business. There are serval bitcoin businesses who contribute to bitcoin-core (and other bitcoin open-source projects) by having dedicated developer for this purpose or allowing internal development to spend serval hours per week to work on os projects.
337 2015-07-06 18:51:51 <jonasschnelli> *dedicated developers
338 2015-07-06 19:20:56 <kimon> jonasschnelli: I think it's possible. Developer can work in https://github.com/jonasschnelli/bitcoin/tree/2015/05/corewallet yes?
339 2015-07-06 19:22:42 <jonasschnelli> kimon: Yes... Sure. Best would be to get in touch with me first to make sure that we don't interfere each other
340 2015-07-06 19:24:08 <jonasschnelli> I just reached the level where the two wallets (new and old wallet) can work together and create transaction between them. core wallet has support for multiwallet, flexible rpc argument ordering, multiple hd chains.
341 2015-07-06 19:24:33 <jonasschnelli> kimon: You or your devs could focus on performance....
342 2015-07-06 19:25:26 <jonasschnelli> i have also some preforged regtest wallets with >300k wtxs and some uncommited test scripts to compare performance between the two wallets.
343 2015-07-06 19:33:48 <kimon> jonasschnelli: Ok, I need a few days to deploy development environment.
344 2015-07-06 19:34:10 <jonasschnelli> no worries and nu rush... :)
345 2015-07-06 19:35:31 <gmaxwell> Hm. I wonder if we have a performance problem related to txindex.
346 2015-07-06 19:36:32 <gmaxwell> Reindexing my laptop with txindex=1 ... now 11 hours into it. I think if it had taken anywhere near that long last time I reindexed I would have noticed.
347 2015-07-06 19:36:52 <gmaxwell> But last time I reindexed on this host I didn't have txindex=1.
348 2015-07-06 19:37:07 <jcorgan> it does take awhile, even with SSD
349 2015-07-06 19:37:09 <jonasschnelli> gmaxwell: lasttime i did a txindex=1 -renindex on a ~35GB+ blockchain it also took me "a night".
350 2015-07-06 19:37:25 <jonasschnelli> (SSD + 2.6 GHz Intel Core i7)
351 2015-07-06 19:37:33 <wumpus> could be, txindex also creates a huge index, especially on newer blocks with lots of transactions
352 2015-07-06 19:38:08 <gmaxwell> jonasschnelli: considering that I have recent benchmarks on full syncs on a 3.2ghz i7 around 3 hours, would seem to implicate txindex.
353 2015-07-06 19:38:15 <jcorgan> yes
354 2015-07-06 19:40:44 <kimon> jonasschnelli: Ok, keep in touch! :)
355 2015-07-06 19:40:51 <gmaxwell> it's actually adversely impacting the usability of the system, which is interesting.
356 2015-07-06 19:41:18 <jcorgan> try adding addrindex=1 :-)
357 2015-07-06 19:42:29 <jcorgan> i actually haven't run that patch in a long time, don't even know if anyone else picked it up
358 2015-07-06 19:46:32 <wumpus> there's still a pull open for it somewhere
359 2015-07-06 19:51:14 <jcorgan> it seemed fatally destined for non-merge worthiness, and probably needs to be rewritten from scratch by now
360 2015-07-06 20:17:10 <btcdrak> OpenSSL again... https://mta.openssl.org/pipermail/openssl-announce/2015-July/000037.html
361 2015-07-06 20:18:46 <wumpus> "These releases will be made available on 9th July. They will fix a single security defect classified as "high" severity.  This defect does not affect the 1.0.0 or 0.9.8 releases."
362 2015-07-06 20:19:35 <gmaxwell> man again they didn't give the time.
363 2015-07-06 20:27:24 <wumpus> the great openssl (in)security show
364 2015-07-06 21:28:47 <gmaxwell> BlueMatt: did you implement some anti-dos somethign on the relaynetwork hub lately?  my client is just looping on initial connect and getting disconnected after relaying a bunch of txn.
365 2015-07-06 21:28:54 <gmaxwell> Closing relay socket, failed to read message header (0: )
366 2015-07-06 21:31:06 <gmaxwell> uhh and I updated the client and it never connects now.
367 2015-07-06 23:03:15 <brendafdez> pushtx is no longer used in the latest versions of Bitcoin Core? I'm on 0.10.0 and it sez "Method not found".
368 2015-07-06 23:29:44 <midnightmagic> Luke-Jr: hey, I think your key expired; the one you use to sign the gitian sig stuff..