1 2014-06-26 00:44:40 <jgarzik> I think this is the first time I've _ever_ built the Qt portion of the codebase.
2 2014-06-26 01:18:05 <jgarzik> sipa, ah yes. Now I recall. You recommended that class UniValue use operator[]
3 2014-06-26 01:50:04 <jgarzik> GRUMBLE. Must convert RPC client and server to UniValue at same time. Cannot do one side, test, then do the other side.
4 2014-06-26 01:50:18 <jgarzik> ACTION makes a test fork
5 2014-06-26 01:50:58 <gmaxwell> ACTION introduces jgarzik to the power cp command that allows one to split a repository into two 'universes' which can simultaniously contain different code
6 2014-06-26 01:51:13 <gmaxwell> er powerful* :)
7 2014-06-26 01:52:12 <jgarzik> gmaxwell, that's what the test fork is
8 2014-06-26 01:52:37 <jgarzik> gmaxwell, I would prefer a single tree and chronology for testing, but #FirstWorldProblems
9 2014-06-26 03:20:54 <zone117x> could someone direct me to the appropriate channel to ask pool dev questions? (vardiff specifically)
10 2014-06-26 03:22:33 <SomeoneWeird> zone117x: maybe #bitcoin-mining
11 2014-06-26 03:23:05 <zone117x> ehh pretty sure they will just be miners not pool devs but I'll give it a shot thanks. not like there are many pool devs out there anyway
12 2014-06-26 03:25:01 <SomeoneWeird> yeah
13 2014-06-26 05:21:28 <hero> hello
14 2014-06-26 05:21:42 <hero> any one here try deal wih multisig address ?
15 2014-06-26 05:22:14 <kazcw> off topic here, ask in #bitcoin.
16 2014-06-26 05:22:41 <hero> i ask but no one answer my question
17 2014-06-26 05:22:54 <hero> i try to do multisig address in many times
18 2014-06-26 05:23:00 <hero> and read many topics
19 2014-06-26 05:23:15 <hero> i just want know something
20 2014-06-26 05:23:46 <hero> when i create multisig address from address from current wallet it work
21 2014-06-26 05:24:06 <hero> but when i create multisig address from publick key from other wallet
22 2014-06-26 05:24:21 <hero> multisig address didn't show when i call listunspent
23 2014-06-26 05:24:24 <hero> why ?
24 2014-06-26 05:25:19 <hero> hello ?
25 2014-06-26 05:26:19 <hero> can any one help me please ?
26 2014-06-26 05:26:42 <dsnrk> hero: you can't expect instant answers to your questions, same as in #bitcoin. if somebody knows they'll chime in. if they don't you'll just have to stick around and wait until there's somebody who does.
27 2014-06-26 05:27:38 <hero> ok
28 2014-06-26 05:27:46 <sam______> I am facing problem in retrieving information of old transaction using bitcoind.
29 2014-06-26 05:28:53 <dsnrk> sam______: this is really not the channel for that, but you need to enable txindex=1 in your bitcoin.conf before you can look up information about TXID you don't own.
30 2014-06-26 05:29:18 <dsnrk> enabling txindex will cause your node to reindex the block chain, which is a lengthy process.
31 2014-06-26 06:04:08 <freeroute> hi, can I please get un-banned from #bitcoin ? I was trying to help out a noob and I accidentally posted a link which contained some banned words
32 2014-06-26 06:04:42 <freeroute> but secretly I think piquire was mad at me for calling it a bunch of sticks
33 2014-06-26 06:05:46 <dsnrk> freeroute: #bitcoin-bans
34 2014-06-26 06:05:54 <freeroute> oh cool
35 2014-06-26 06:06:07 <freeroute> --> #bitcoin-bans
36 2014-06-26 06:57:55 <wumpus> as-is.
37 2014-06-26 06:57:55 <wumpus> jgarzik: sipa: IMO it makes sense for the knowledge of how to convert command line arguments to json to be in the client and not the server, after all we're offering a JSON-RPC API not a command-line API. The command-line parsing is just icing on the cake to make the bitcoin-cli tool a bit more user-friendly to use from the shell and bash scripts. It's not necessary beyond that, from all other languages people should just use JSON
38 2014-06-26 06:59:52 <wumpus> of course the server could offer some form of introspection as to what arguments are expected
39 2014-06-26 07:00:44 <wumpus> see also https://github.com/bitcoin/bitcoin/issues/4157 .. I wonder if there is a *standard* for JSON-RPC introspection so we don't have to reinvent the wheel again
40 2014-06-26 07:02:51 <wumpus> according to https://en.wikipedia.org/wiki/JSON-RPC there is a 1.1 working draft that adds introspection, but it never made it into 2.0 ...
41 2014-06-26 07:06:02 <wumpus> XMBC defines a "JSONRPC.Introspect" API for self-documentation and introspection, interesting
42 2014-06-26 07:06:32 <wumpus> hah there is even an 'JSON-RPC client generator' https://jsonrpcgen.codeplex.com/
43 2014-06-26 07:09:52 <wumpus> this makes it possible to automatically generate client-side libraries for static programming languages such as c++, c#, java etc
44 2014-06-26 08:10:46 <dekalo> hello
45 2014-06-26 08:49:15 <kiddouk> good morning all.
46 2014-06-26 08:53:35 <wumpus> morning
47 2014-06-26 08:55:00 <dekalo> morning :D
48 2014-06-26 09:00:10 <wumpus> buh, tcmalloc shows me Dumping heap profile to /tmp/profile.0012.heap (12288 MB allocated cumulatively, 78 MB currently in use) ... but top shows VIRT 573376 RES 273680
49 2014-06-26 09:03:19 <wumpus> my gut feeling is that almost all of the memory in bitcoind's memory map consists of mmapped leveldb files, not even heap, or maybe it's not tracking everything (there is something in the tcmalloc doc about some STL implementations having their own allocators, but I doubht stdc++ is one of them)
50 2014-06-26 09:03:25 <gmaxwell> so some of this is in thread stacks that tcmalloc won't see. A lot of it is in TC malloc overhead, which I think doesn't show up there (I'm not sure how to make it show up)... but 78 vs 273 is a lot. you might want to run in gdb and set breakpoints on sbrk and mmap and see if there are any obvious leaks outside of tcmalloc.
51 2014-06-26 09:03:51 <gmaxwell> virt is not a useful measure generally, lots of stuff cause a lot of extra virt usage, especially on x86_64.
52 2014-06-26 09:04:18 <gmaxwell> nah, the stl stuff uses new/malloc and should be caught (also in the profiles you'll see plenty of stl containers)
53 2014-06-26 09:05:00 <wumpus> the thread stacks are 8MB
54 2014-06-26 09:05:05 <gmaxwell> yes, per thread.
55 2014-06-26 09:05:25 <wumpus> right, for 18 threads
56 2014-06-26 09:05:36 <wumpus> so that accounts for 144MB already
57 2014-06-26 09:06:01 <gmaxwell> so only around half of whats missing.
58 2014-06-26 09:06:02 <wumpus> anyhow it looks like we're not even doing that bad heap-wise, I expected a lot more allocations
59 2014-06-26 09:06:17 <gmaxwell> we've been grinding down on them for much of the last year. :)
60 2014-06-26 09:06:29 <wumpus> sure
61 2014-06-26 09:15:54 <wumpus> anyhow, I'm profiling a reindex over time, so it may still grow a lot
62 2014-06-26 09:17:20 <wumpus> height=147000 now and 123MB heap in use
63 2014-06-26 09:28:41 <michagogo> wumpus: I'll look at rebasing my PR now
64 2014-06-26 09:31:38 <michagogo> Hm, I don't know if it's worth rebasing https://github.com/bitcoin/bitcoin/pull/3775
65 2014-06-26 09:31:51 <michagogo> https://github.com/bitcoin/bitcoin/pull/4271 does the same thing
66 2014-06-26 09:45:26 <wumpus> well, the doc change would be easy to merge
67 2014-06-26 09:46:27 <wumpus> the other one does depenency bumps and renames, I don't like those without a good reason
68 2014-06-26 09:46:41 <wumpus> (ie, a security fix or upgrade)
69 2014-06-26 09:47:23 <wumpus> so that means it will stay on hold until the next time it's really needed, like https://github.com/bitcoin/bitcoin/pull/4350
70 2014-06-26 09:47:52 <gmaxwell> "what do you mean no good reason? I worked hard to get that backdoor in that release!"
71 2014-06-26 09:48:04 <wumpus> hehe
72 2014-06-26 09:48:35 <dsnrk> w̶o̶r̶k̶e̶d̶ ̶h̶a̶r̶d̶ paid a lot
73 2014-06-26 09:49:06 <gmaxwell> hey, mowing lawns is hard work!
74 2014-06-26 09:49:12 <wumpus> height=157000, 87MB heap in use... we're actually freeing up memory, this is going the right way :)
75 2014-06-26 09:58:21 <michagogo> wumpus: bumps?
76 2014-06-26 09:58:32 <wumpus> it's a pity that it only shows where the allocations were done, not the types and classes etc
77 2014-06-26 09:59:34 <michagogo> 4271 doesn't bump any deps
78 2014-06-26 09:59:38 <wumpus> michagogo: anyhow, it means extra work for git builders for no good reason
79 2014-06-26 09:59:53 <michagogo> Consistency is a bad reason? :-(
80 2014-06-26 09:59:55 <wumpus> so NACK from me
81 2014-06-26 10:01:05 <wumpus> up to a point consistency is good, but it should not be expensive, as I said I suggest combining the rename with the next time an actual change to the dependencies is necessary
82 2014-06-26 10:01:53 <AndersAA> Just compiled latest commit. Getting a lot of "main.h:853: warning: comparison between signed and unsigned integer expressions" warnings - I know what the warning means, but why are they there specifically?
83 2014-06-26 10:02:49 <AndersAA> (main.h: In member function 'bool CBlockIndex::IsValid(BlockStatus) const')
84 2014-06-26 10:02:54 <wumpus> the warning exists because comparing unsigned and signed integers can have non-intuitive resuults in some cases
85 2014-06-26 10:03:43 <wumpus> it's a "please specify better what you want", sometimes it may be an actual problem, but not always...
86 2014-06-26 10:04:31 <AndersAA> wumpus: Yeah, that's why I was wondering about this specific case?
87 2014-06-26 10:04:57 <michagogo> wumpus: well
88 2014-06-26 10:05:19 <michagogo> 4271 improves more in the docs than 3775 does
89 2014-06-26 10:06:20 <Luke-Jr> michagogo: IMO it can wait until the deps are being split to dedicated yml files, and gitian has automatic dependency resolution :p
90 2014-06-26 10:06:44 <Luke-Jr> or at least until something needs to change for some other reason
91 2014-06-26 10:15:44 <wumpus> Luke-Jr: good point, cfields is working on a larger-scale redesign of gitian building, to make it possible to use the same scripts for pulltester (or the travis variant), might as well wait for that
92 2014-06-26 10:17:14 <wumpus> AndersAA: no idea, you're welcome to fix it
93 2014-06-26 10:19:14 <AndersAA> wumpus: Sure, may take a closer look at it next week when I have the time.
94 2014-06-26 10:24:52 <Luke-Jr> LogPrintf is always %d and %u regardless of type width, right?
95 2014-06-26 10:36:44 <michagogo> wumpus: I think you may have forgotten to remove the "After 3 or more people have gitian-built, repackage gitian-signed zips:" header
96 2014-06-26 10:45:55 <michagogo> wumpus: Thinking maybe I should split 4271 into two PRs
97 2014-06-26 10:46:17 <michagogo> One that does the cleanup and one that does the OS X renaming
98 2014-06-26 10:46:39 <michagogo> (in other words, split the rename into its own PR)
99 2014-06-26 10:46:43 <michagogo> What's the best way to do that?
100 2014-06-26 10:49:23 <michagogo> Anyway, 3775 is rebased now, as far as I can tell
101 2014-06-26 11:30:00 <wumpus> Luke-Jr: yes, tinyformat doesn't care about size specifiers
102 2014-06-26 11:30:30 <wumpus> Luke-Jr: it ignored them generally, unless it's crazy windows-ish ones, but it's better to just not specify them
103 2014-06-26 12:29:16 <Luke-Jr> ACTION needs to rework his build-and-test script :/
104 2014-06-26 13:04:13 <Luke-Jr> gavinandresen: ping
105 2014-06-26 13:04:28 <Luke-Jr> actually, wumpus: ping
106 2014-06-26 13:06:06 <Luke-Jr> wumpus: re https://github.com/bitcoin/bitcoin/pull/1816 splitting up AcceptBlock means the new split functions would need to assume the mutex is held already (thus not get it themselves) to ensure the mutex isn't released between checks & writing - forcing the callers to hold the mutex instead
107 2014-06-26 13:06:51 <Luke-Jr> in which case IMO those new methods would best be private, and the current AcceptBlock interface (with fWriteToDisk added) exposed as a wrapper
108 2014-06-26 13:07:03 <Luke-Jr> the question is, is that a change that still makes sense to you?
109 2014-06-26 13:49:15 <Anduck> what would be the best method to track for addresses (for incoming transactions)?
110 2014-06-26 13:49:41 <Anduck> without having the wallet
111 2014-06-26 13:50:52 <epscy> not sure if it is the best way but you could use block notify to let you know when a new block is found then check if the block contains any txes you are interested in
112 2014-06-26 13:51:20 <Anduck> hmm.. true
113 2014-06-26 13:51:30 <Anduck> thanks!
114 2014-06-26 14:05:56 <shesek> Anduck, I'm using btcd for that
115 2014-06-26 14:06:03 <Anduck> btcd? bitcoind?
116 2014-06-26 14:06:13 <shesek> no, a Go implementation of a full node
117 2014-06-26 14:06:26 <Anduck> i am using 'listsinceblock' from bitcoind, i guess it's good for reading all blocks?
118 2014-06-26 14:06:37 <shesek> its websocket api allows you to listen for transactions made to addresses or transactions that spends a specific output
119 2014-06-26 14:06:44 <shesek> and gives you push notifications when that happens
120 2014-06-26 14:06:48 <Anduck> is it stable?
121 2014-06-26 14:07:06 <shesek> well, yeah, but you'll have to parse the blocks yourself and all that, which isn't really ideal
122 2014-06-26 14:07:28 <shesek> its still considered alpha quality, but I've been using it for some time now and its quite stable
123 2014-06-26 14:07:31 <Anduck> hmm, the thing is i need to read the incoming stuff when needed, can't 'listen'
124 2014-06-26 14:07:35 <Anduck> alright
125 2014-06-26 14:07:52 <davec> It's beta now
126 2014-06-26 14:08:23 <shesek> oh, good to know. :)
127 2014-06-26 14:08:53 <Anduck> any thoughts about the 'listsincebblock' way?
128 2014-06-26 14:09:11 <Anduck> just testing it to see if it lists all transactions, not just wallet-address addressed
129 2014-06-26 14:51:30 <Luke-Jr> wumpus: except for above question, the rest are rebased and addressed
130 2014-06-26 14:51:50 <wumpus> Luke-Jr: it's a good question
131 2014-06-26 14:53:30 <wumpus> Luke-Jr: I don't have a quick answer to it, but I don't like complicating AcceptBlock etc even more :(
132 2014-06-26 14:53:54 <Luke-Jr> wumpus: me either, but proposals is probably the most important of those :/
133 2014-06-26 14:54:39 <Luke-Jr> (miners can run multiple versions in parallel and ensure they only mine blocks accepted by all)
134 2014-06-26 14:55:27 <wumpus> yes, the functionality makes a lot of sense
135 2014-06-26 15:34:11 <dekalo> hello
136 2014-06-26 15:43:44 <dekalo> im trying to understand why in signrawtransaction() (rpcrawtransaction.cpp) txVariants is declared as vector<CMutableTransaction>?
137 2014-06-26 15:47:17 <dekalo> maybe is the same reason of using a BOOST_FOREACH on txVariants in the signing process
138 2014-06-26 15:47:40 <dekalo> but if there is only 1 rawtx in input why to iterate ?
139 2014-06-26 18:15:11 <michagogo> Hm, anyone know what "subver" : "Dain 0.0.1" is?
140 2014-06-26 18:15:29 <michagogo> (and who's still running "/Satoshi:0.7.99/"?!?)
141 2014-06-26 18:16:41 <mpescador> I've got a question about scripts. May scriptsig's only push values to the stack, or may it also contain other opcodes? Is that invalid or just nonstandard?
142 2014-06-26 18:17:00 <michagogo> mpescador: Pretty sure scriptSigs are allowed to do more than push
143 2014-06-26 18:17:12 <michagogo> But because there's no input to them, it's pointless
144 2014-06-26 18:17:35 <michagogo> And so, IIRC any non-push opcodes render the tx non-standard according to BCC
145 2014-06-26 18:17:38 <michagogo> BC*
146 2014-06-26 18:19:00 <mpescador> I understand that they are nonstandard, I wanted to know what's valid though. For example if a scripsig contains an op_checksig command, I wouldn't know what to hash.
147 2014-06-26 18:23:40 <andytoshi> mpescador: they are valid. i can't say for sure what would happen if a scriptsig contained an CHECKSIG but i'd guess that it's no different than if the scriptpubkey you're concatenating to it contained a CHECKSIG
148 2014-06-26 18:24:25 <ninjashogun> Hi, can someone PM me who could help me in how to join/set up the WoT thing?
149 2014-06-26 18:24:37 <ninjashogun> I can't figure out how to get gribble to recognize my fingerprint
150 2014-06-26 18:24:49 <andytoshi> that is, you zero out every scriptsig (including the CHECKSIG that you're evaluating), look at the sighash type byte on the ECDSA signature (or is it on the key? i don't remember) and do the right thing
151 2014-06-26 18:25:08 <andytoshi> i bet if somebody did this it'd bump coinbase off the network :)
152 2014-06-26 18:25:18 <andytoshi> coinbase.io i mean
153 2014-06-26 18:26:34 <gmaxwell> ninjashogun: go to #bitcoin-otc
154 2014-06-26 18:26:59 <michagogo> andytoshi: Error code: DNS_PROBE_FINISHED_NXDOMAIN
155 2014-06-26 18:27:51 <michagogo> Looks like that domain is registered but has no records
156 2014-06-26 18:28:08 <ninjashogun> gmaxwell - gladamas is helping me thx. the hard part is uplodaing the cert, I thought it was automatic (as I clicked 'publish' int he client)
157 2014-06-26 18:28:10 <michagogo> (other than NSes)
158 2014-06-26 18:28:30 <andytoshi> michagogo: oh, i mean that exchange company called coinbase...don't recall the url
159 2014-06-26 18:28:44 <michagogo> The one that's also a payment processor and wallet?
160 2014-06-26 18:28:47 <andytoshi> yeah
161 2014-06-26 18:28:47 <michagogo> coinbase.com
162 2014-06-26 18:29:05 <michagogo> Why, what are they using?
163 2014-06-26 18:29:17 <andytoshi> they have ruby consensus code and are famous here for dropping off whenever a weird block rolls by
164 2014-06-26 18:29:30 <michagogo> s/fam/infam/ ?
165 2014-06-26 18:29:34 <andytoshi> :P yeah
166 2014-06-26 18:29:54 <michagogo> Someone should do it on testnet first to make sure it works, then put one in mainnet
167 2014-06-26 18:30:07 <michagogo> (with a little help from Luke, I guess)
168 2014-06-26 18:31:34 <gmaxwell> I'm pretty sure there is a scriptsig with a checksig on it someplace on the network but I can't find it.
169 2014-06-26 18:33:50 <mpescador> andytoshi: thanks for your answers. I first thought that you only had to remove the signature itself, but apparently you have to remove the whole scriptsig.
170 2014-06-26 18:34:54 <andytoshi> mpescador: yup, CHECKSIG is aware of transaction structure and the stack, but doesn't ever parse scripts (i believe)
171 2014-06-26 18:35:12 <andytoshi> so it couldn't distinguish between what's an ECDSA signature and what's not
172 2014-06-26 18:36:42 <gmaxwell> mpescador: it's probably a better mental model to reconize that scriptPubkey and scriptSig are actually the pubkey and signature of a special hybrid cryptosystem for signaturesâ Script. This cryptosystem happens to embed ecdsa, but thats no more unusual than ECDSA embedding multiplication.
173 2014-06-26 18:40:40 <ninjashogun> andytoshi, we've had our differences but it has been civil and ultimately constructive. I it's OK I would like to ask you civilly for a reference/opinion on a certain crypto community that I am considering joining, if you know anything about them. You PM'd me on this subject before - the theoretical claims against PoS systems.
174 2014-06-26 18:41:49 <ninjashogun> if*
175 2014-06-26 18:42:17 <ninjashogun> I would like to know a bit more about a certian community (if you know anything about them). I haven't connected with aonyone personally who have been in it. Mind a PM?
176 2014-06-26 18:42:56 <andytoshi> hey ninjashogun, go for it
177 2014-06-26 18:44:56 <mpescador> andytoshi: I thought I understood it, but now I'm not so sure anymore. I thought op_checksig just searched the subscript for occurrences of the signature and delete those. It's true that you would have to parse it to distinguish between the actual signature and some other sequences of bytes that happens to be the same, but such a collision is extremely unlikely. I would swear I saw such
178 2014-06-26 18:44:57 <mpescador> an implementation in some source somewhere.
179 2014-06-26 19:51:13 <Anduck> is there a patch/fork of bitcoin core to support deterministic wallet?
180 2014-06-26 19:51:25 <Anduck> with public master key (trezor-like)
181 2014-06-26 19:51:54 <gmaxwell> public master key has pretty severe security limitations, so I wouldn't recommend a wallet use only that.
182 2014-06-26 19:52:23 <gmaxwell> you'd have to remove exporting private keys if you wanted any hope of avoiding users totally footgunning their security.
183 2014-06-26 19:59:05 <Anduck> hmm..
184 2014-06-26 19:59:52 <Anduck> i thought i'd use that system so i can generate unlimited receiving addresses for people to use - and use a single private key to control all of them
185 2014-06-26 20:01:46 <Anduck> any idea how to make a system where there are public keys at server (to handle to customers) and priv keys would be offline only
186 2014-06-26 20:01:51 <Anduck> so a 'watch only' node
187 2014-06-26 20:02:30 <Anduck> i heard an idea of importing 'a shitton' of addresses in a wallet and then encrypting it with a very long passphrase and never open it when it's in production server
188 2014-06-26 20:08:11 <Anduck> hmm... gotta read more about this aproach..:)
189 2014-06-26 20:08:57 <ninjashogun> Anduck, you should join #bitcoin-dev they do things like that
190 2014-06-26 20:09:05 <Anduck> this is #bitcoin-dev
191 2014-06-26 20:09:07 <ninjashogun> Anduck, what you've described sounds like what I heard about 'stealth' addresses
192 2014-06-26 20:09:16 <ninjashogun> oh
193 2014-06-26 20:09:20 <ninjashogun> nevermind
194 2014-06-26 20:10:55 <Anduck> bip0032 sounds good
195 2014-06-26 20:11:26 <wumpus> Anduck: a patch for watch-only functionality in core has been implemented by someone, see https://github.com/bitcoin/bitcoin/pull/4045
196 2014-06-26 20:11:36 <Anduck> thanks
197 2014-06-26 20:40:37 <Einewton> Hi... Is there a way to quickly confirm a transactions before the first confirmation?
198 2014-06-26 20:41:19 <Einewton> I'm curious to know how bitpay can confirm a payment so quickly?
199 2014-06-26 20:41:57 <Swadq> Einewton: transactions are relayed before they appear in a block
200 2014-06-26 20:42:26 <Swadq> Thereâs no assurance that the transaction will appear in the block though. BitPay choose to accept transactions without confirmations and later take action if they are double spends
201 2014-06-26 20:43:00 <Swadq> If youâre using a library to interface with the bitcoin network, there will be the option for you to do this too, if you desire
202 2014-06-26 20:43:35 <TheButterZone> any code breakers, stenographers? PM me
203 2014-06-26 20:43:43 <TheButterZone> steganographer
204 2014-06-26 20:46:40 <Einewton> Swadq, Thank you.. I'll look at using a libary to interface with the bitcoin network.
205 2014-06-26 20:47:02 <Einewton> I'm building an sit to accept BitCoin, so I was just curious.
206 2014-06-26 20:47:07 <Einewton> Thank you.
207 2014-06-26 20:47:11 <Einewton> site*
208 2014-06-26 20:48:28 <Swadq> No worries. RPC to bitcoind seems to be the goto at the moment
209 2014-06-26 20:49:11 <Einewton> Alright, I am currently using bitcoin-cli as the RPC currently.
210 2014-06-26 20:49:22 <Einewton> For my testing.
211 2014-06-26 20:53:52 <dekalo> ehi Swadq :)
212 2014-06-26 20:54:02 <Swadq> Hi there :)
213 2014-06-26 21:16:24 <jgarzik> with JSON-spirit:
214 2014-06-26 21:16:25 <jgarzik> jgarzik@hum:~/repo/bitcoin/src$ size bitcoind
215 2014-06-26 21:16:26 <jgarzik> 4106544
216 2014-06-26 21:16:26 <jgarzik> text
217 2014-06-26 21:16:45 <jgarzik> without JSON-spirit (using UniValue):
218 2014-06-26 21:16:46 <jgarzik> 3680618
219 2014-06-26 21:16:46 <jgarzik> jgarzik@hum:~/repo/bitcoin/src$ size bitcoind
220 2014-06-26 21:16:46 <jgarzik> text
221 2014-06-26 21:16:56 <jgarzik> gmaxwell, wumpus: ^
222 2014-06-26 21:17:49 <jgarzik> converted the entire tree, in a private branch. still have some money-formatting related tests failing, and a few other details to sort out.
223 2014-06-26 21:18:22 <jgarzik> exact same functionality, just swapped JSON-spirit API for UniValue API
224 2014-06-26 21:21:45 <gmaxwell> pretty great! though to be a little more fair perhaps you should compile with LTO. Presumably we'll be using LTO sometime in the not far future, and it should fix at least some of the json bleeding.
225 2014-06-26 21:22:19 <gmaxwell> (not that I wouldn't prefer we switchâ for one, AFAIR we're stranded on our current json code version because they garbaged up the number precision)