1 2014-05-19 00:49:10 <legerde> Payment Protocol: I am working on an implementation of this.    What if the transaction in the payment message never shows up in the blockchain?  I dont have a way of notifying the customer that the payment failed... Maybe its no big deal?
  2 2014-05-19 00:51:37 <legerde> Payment Protocol:  I dont think I can hold off on the paymentACK message for 10 minutes.     Im new to this, so I probably have some fundamental misunderstanding
  3 2014-05-19 00:52:40 <Luke-Jr> legerde: it's your job to get the transaction into the blockchain
  4 2014-05-19 00:53:50 <Luke-Jr> legerde: PaymentACK isn't a promise that the payment was good, just confirmation that you received it.
  5 2014-05-19 00:54:25 <Luke-Jr> legerde: think of it like a printed receipt: if the check bounces, you still expect payment to be made good
  6 2014-05-19 00:55:26 <legerde> Im looking at this from the Merchant side..  Its the wallets job to get it in the blockchain.   THe merchant sends a PaymentACK.
  7 2014-05-19 00:56:04 <legerde> So as a merchant, if the user is gone, then I have no way to notify them.    I have a refund address.
  8 2014-05-19 00:56:37 <Luke-Jr> legerde: it's the merchant's job to get it in the blockchain.
  9 2014-05-19 00:56:54 <Luke-Jr> legerde: I suggest you get contact info before giving them a payment request.
 10 2014-05-19 00:57:22 <legerde> THats a good suggestion.  https://github.com/bitcoin/bips/blob/master/bip-0070/Protocol_Sequence.png   This sequence says its the wallets job to get the transaction in the blockchain.
 11 2014-05-19 00:58:02 <legerde> Maybe I misread that figure?
 12 2014-05-19 00:58:13 <Luke-Jr> legerde: it doesn't mention the blockchain in that image
 13 2014-05-19 00:58:23 <legerde> I believe I am the merchant server in that diagram.
 14 2014-05-19 01:00:15 <legerde> I interpreted the bitcoin-p2p network as the blockchain.    So the wallet ships the transaction to the P2P network, then I watch transactions from the P2P network to verify the transaction was successful.   Thats what that figure tells me.  But maybe I am misreading it
 15 2014-05-19 01:19:50 <Luke-Jr> legerde: in any case, PaymentACK should not wait for confirmation
 16 2014-05-19 01:25:46 <legerde> Luke-Jr: Agreed.  I thank you for your input on this.  I do not wish to gather customer data.  The entire reason I am investigating the payment protocol is so that a refund address is automatically included, rather than gather customer data.
 17 2014-05-19 01:26:36 <Diablo-D3> good job legerde, you killed him
 18 2014-05-19 01:26:54 <legerde> I guess....   Im not a violent person. :)
 19 2014-05-19 02:46:09 <wew> question: can I generate multiple addreses using 1 private key?
 20 2014-05-19 02:55:02 <jcorgan> wew: essentially, no, though technically each private key can be transformed into a compressed and uncompressed public, and each of those creates a different address
 21 2014-05-19 02:55:13 <jcorgan> *public key
 22 2014-05-19 02:55:59 <jcorgan> you may be thinking of BIP32, where a unique seed value can generate an unlimited series of public and private key pairs
 23 2014-05-19 04:07:27 <mu_> ...
 24 2014-05-19 06:41:26 <michagogo> jcorgan: minor nit: it's the same public key, just 2 representations of it
 25 2014-05-19 06:43:20 <jcorgan> yeah
 26 2014-05-19 06:43:58 <jcorgan> thought i said that with "compressed and uncompressed", but yeah, it's the same curve point
 27 2014-05-19 07:23:44 <joebaker> I was trying to envoke bandwidth limiting on bitcoind  using "trickle"  but found it throwing segmentation faults -- I envoked it as such  "trickle -u 5000 -d 5000 -s /usr/bin/bitcoind"   - this on Ubuntu 13.10 machines 8 of them were yeilding similar results.  I've removed trickle and thus far, it seems stable after an hour or so.
 28 2014-05-19 07:24:50 <joebaker> It's just an FYI -  plus these are on OpenVZ linux containers.
 29 2014-05-19 07:27:46 <Luke-Jr> joebaker: sounds like a bug for trickle
 30 2014-05-19 07:33:12 <joebaker> Thanks Luke-Jr - yes I think  that is correct.
 31 2014-05-19 07:46:26 <arowser> joebaker: There is a sample for limit the outgoing bandwidth https://github.com/bitcoin/bitcoin/blob/master/contrib/qos/tc.sh
 32 2014-05-19 08:19:21 <kostazert> Hi guys.
 33 2014-05-19 08:20:17 <kostazert> What is right boost version to comile bitcoin from source code on ubuntu 14.04?
 34 2014-05-19 08:21:23 <kostazert> Anyone there?
 35 2014-05-19 08:22:14 <kostazert> Is this the right place to ask about bitcoin development?
 36 2014-05-19 08:24:16 <michagogo> kostazert: 1.55 should be good, I think
 37 2014-05-19 08:25:13 <michagogo> 1.54 should also work, I think
 38 2014-05-19 08:25:25 <michagogo> IIRC 1.53 had problems at some point
 39 2014-05-19 08:25:36 <kostazert> thanks!
 40 2014-05-19 08:25:39 <michagogo> np
 41 2014-05-19 08:25:45 <kostazert> Trying now...
 42 2014-05-19 08:26:07 <michagogo> (if you just install the package from Ubuntu's sources, I think it should work)
 43 2014-05-19 08:26:49 <kostazert> But I want to compile it from scratch - to undertstand the steps
 44 2014-05-19 08:27:09 <michagogo> Compile boost itself from scratch? How come?
 45 2014-05-19 08:28:04 <kostazert> I mean to compile bitcoin from source code and all the needed libs on the way.
 46 2014-05-19 08:28:26 <kostazert> Anyway, boost compiles in 13 minutes - I did it already...
 47 2014-05-19 08:29:40 <kostazert> I'm on Ubuntu 14.04 and the default boost is 1.54, which is not good AFAIK
 48 2014-05-19 08:29:53 <michagogo> I think 1.54 is fine, isn't it?
 49 2014-05-19 08:29:59 <michagogo> (could be wrong, though)
 50 2014-05-19 08:30:12 <michagogo> IIRC 1.54 is fine, but there's something wrong with 1.53
 51 2014-05-19 08:30:29 <kostazert> Ok. Got it - 1.54 is ok.
 52 2014-05-19 08:30:48 <michagogo> But if you want to build it from scratch, go for it
 53 2014-05-19 08:31:27 <michagogo> (out of curiosity, when you say "all the needed libs", are you including libc et al?
 54 2014-05-19 08:31:35 <michagogo> )
 55 2014-05-19 08:31:43 <kostazert> Anyway, I need to compile libdb4.8.30, 'cause Ubuntu 14.04 has libdb5.3
 56 2014-05-19 08:31:58 <michagogo> Well, FSVO "need"
 57 2014-05-19 08:32:03 <kostazert> well, libc is excluded :-)
 58 2014-05-19 08:32:16 <michagogo> The bitcoin PPA has db4.8 packages
 59 2014-05-19 08:32:39 <sipa> 5.1 will also work
 60 2014-05-19 08:32:47 <sipa> unsire about 5.3
 61 2014-05-19 08:32:48 <wumpus> kostazert: here are some steps to compile libdb yourself and build bitcoin against it https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#berkeley-db
 62 2014-05-19 08:32:55 <wumpus> sipa: 5.3 works too
 63 2014-05-19 08:33:01 <sipa> ok, good
 64 2014-05-19 08:33:02 <warren> with 0.7.x I had trouble with 5.3
 65 2014-05-19 08:33:06 <warren> haven't tried since
 66 2014-05-19 08:33:10 <kostazert> oh, thanks wumpus
 67 2014-05-19 08:33:17 <kostazert> looking it up...
 68 2014-05-19 08:33:32 <wumpus> interoperability with other versions is a big question mark in that case
 69 2014-05-19 08:33:42 <warren> michagogo: had a chance to test 4189?
 70 2014-05-19 08:34:12 <warren> we have a remaining issue of something else leaking and breaking determinism, and intermittent configure loop
 71 2014-05-19 08:34:16 <michagogo> warren: ah, no -- I'll boot my VM now
 72 2014-05-19 08:34:35 <warren> michagogo: see if your build matches variant1 or variant2, or something else
 73 2014-05-19 08:35:45 <michagogo> Correction: s/now/after VBox updates/
 74 2014-05-19 09:55:23 <michagogo> warren: Okay, what needs doing now?
 75 2014-05-19 09:56:49 <michagogo> As of ebcf375e84a90c22ff00de28697eaf32a60ddc43, I have deba5750b02b6f1677b9c0749b25b7ec2b7bb5851ae03b277f5b22c06bbbb3bc  osx-depends-qt-5.2.0-r2.tar.gz
 76 2014-05-19 09:57:45 <michagogo> Did you say you wanted build.log from that?
 77 2014-05-19 09:59:08 <michagogo> http://paste.ubuntu.com/7487778/
 78 2014-05-19 10:06:45 <Gerendon> Any experienced developers around looking for work per chance?
 79 2014-05-19 10:24:33 <kostazert> I followed https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#berkeley-db guide.
 80 2014-05-19 10:24:44 <kostazert> libdb4.8 compiled ok
 81 2014-05-19 10:24:57 <kostazert> libdb4.8 installed ok into my bitcoin/db4 folder
 82 2014-05-19 10:25:42 <kostazert> But bitcoin compilation fails with 'db_cxx.h: No such file'
 83 2014-05-19 10:26:33 <kostazert> I checked - 'bitcoin/db4/include/db_cxx.h' is there!
 84 2014-05-19 10:26:51 <kostazert> Can anyone help on this?
 85 2014-05-19 10:26:54 <kostazert> Guys?
 86 2014-05-19 10:27:56 <kostazert> Anyone?
 87 2014-05-19 10:29:01 <sipa> you'll either need to pass the path to those headers to configure/make, or put them in a standard location (/usr/include)
 88 2014-05-19 10:29:51 <kostazert> I did it by: ./configure LDFLAGS="-L./db4/lib/" CPPFLAGS="-I./db4/include/"
 89 2014-05-19 10:30:07 <kostazert> And also tried: make LDFLAGS="-L./db4/lib/" CPPFLAGS="-I./db4/include/"
 90 2014-05-19 10:30:21 <kostazert> But the error is the same  :-(
 91 2014-05-19 10:30:27 <sipa> try absolute paths?
 92 2014-05-19 10:30:40 <kostazert> Ok. Checking...
 93 2014-05-19 10:32:30 <kostazert> Coooooool! Passed the libdb error! Waiting for compilation to finish!
 94 2014-05-19 10:32:40 <kostazert> > sipe: Thanks man!
 95 2014-05-19 10:34:43 <wumpus> yes, always use absolute paths
 96 2014-05-19 10:34:57 <kostazert> Now I got it.   :-)
 97 2014-05-19 10:34:57 <wumpus> relative paths don't work as the build works from different paths
 98 2014-05-19 10:35:09 <kostazert> Thanks, wumpus!
 99 2014-05-19 10:36:21 <Luke-Jr> $PWD is useful
100 2014-05-19 10:36:51 <wumpus> yes that's actually what I use here https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#berkeley-db
101 2014-05-19 10:37:01 <wumpus> well, $(pwd) instead of $PWD but heh
102 2014-05-19 10:41:32 <kostazert> $(pwd) is alright
103 2014-05-19 10:41:58 <kostazert> I just did all the steps manually..., hence, this mistake with relative path.   :-(
104 2014-05-19 10:44:10 <kostazert> Cool! Bitcoin compiled in ~10 minutes!
105 2014-05-19 10:44:58 <wumpus> that's quick!
106 2014-05-19 10:45:08 <wumpus> lots of memory?
107 2014-05-19 10:47:21 <michagogo> warren: building qt 5.2.1 osx on commit 0173fa15c4301cbd3079944023ac7c5c0c37a5a7 now
108 2014-05-19 10:48:06 <kostazert> Added pull request to fix build-unix.md
109 2014-05-19 10:48:09 <kostazert> https://github.com/bitcoin/bitcoin/pull/4195
110 2014-05-19 10:56:34 <michagogo> warren: erm, that link is wrong: http://michagogo.cadoth.net/build.log.qt-5.2.0-ebcf375e84a90c22ff00de28697eaf32a60ddc43
111 2014-05-19 10:58:01 <michagogo> erm, http://michagogo.cadoth.net/build.qt-5.2.0-ebcf375e84a90c22ff00de28697eaf32a60ddc43.log
112 2014-05-19 11:02:51 <minium> any way to initialize a CKey from a key string?
113 2014-05-19 11:22:40 <michagogo> wumpus: "Bitcoind was part of the Ubuntu default repos for a while, but they don't upgrade versions as we need to. This resulted in Ubuntu 12.04 stable being stuck with 0.3.xx forever. It would be even worse for Debian Stable, which has even older versions of packages." <-- Unfortunately, it still is, up through saucy :-/
114 2014-05-19 11:31:24 <minium> on ubuntu just go on https://launchpad.net/~bitcoin/+archive/bitcoin and add that repo
115 2014-05-19 11:31:50 <minium> then you'll have the freshest version (0.9.1)
116 2014-05-19 11:33:25 <michagogo> minium: yes, I know
117 2014-05-19 11:38:14 <michagogo> warren: http://michagogo.cadoth.net/build.qt-5.2.1-0173fa15c4301cbd3079944023ac7c5c0c37a5a7.log
118 2014-05-19 11:42:00 <michagogo> warren: which commit do you want me to tell gitian to build?
119 2014-05-19 12:20:39 <minium> is there any specification file for JSON-RPC in bitcoind?
120 2014-05-19 12:20:49 <minium> something like https://github.com/cinemast/libjson-rpc-cpp#step-1-writing-the-specification-file
121 2014-05-19 12:30:31 <cbeams> minium: no, but coryfields has been doing some thinking along these lines. You might want to connect with him.
122 2014-05-19 12:30:46 <minium> cbeams: alright, thanks
123 2014-05-19 12:33:52 <minium> cbeams: are you aware of any possibilities to integrate some self-made software with bitcoind using JSON-RPC?
124 2014-05-19 12:34:18 <wumpus> minium: no, though you can get info on every function with the help call
125 2014-05-19 12:34:52 <wumpus> (and get a list of functions if you pass help without argument)
126 2014-05-19 12:35:24 <sipa> automatically generating such a specification file (similar to how help is generated) would be useful too
127 2014-05-19 12:35:51 <minium> it seems rather ugly that rpcclient.h + rpcclient.cpp is built as a command-line parser
128 2014-05-19 12:36:00 <wumpus> minium: that's just the client
129 2014-05-19 12:36:15 <wumpus> minium: that's completely not interesting if you're looking to use it in your application, you should look at the servers
130 2014-05-19 12:36:37 <sipa> it would be nice if rpcclient would load the specification file from the server, and use that to do type conversions & stuff
131 2014-05-19 12:36:42 <minium> wumpus: yea, but I want to built my own client software to control the server
132 2014-05-19 12:36:52 <sipa> you can do that
133 2014-05-19 12:37:05 <minium> sipa: with the rpcserver files?
134 2014-05-19 12:37:07 <sipa> no
135 2014-05-19 12:37:12 <wumpus> JSON RPC bindings are available for many languages
136 2014-05-19 12:37:14 <minium> how then?
137 2014-05-19 12:37:14 <sipa> rpccserver is part of bitcoind
138 2014-05-19 12:37:21 <sipa> by talking json-rpc to bitcoind
139 2014-05-19 12:37:52 <sipa> that specification file is for that specific software package to automatically generate stubs to communicate
140 2014-05-19 12:37:59 <minium> sipa: correct me if I'm wrong, but for that I'd have to encode all existing commands?
141 2014-05-19 12:38:00 <sipa> but you can do it manually
142 2014-05-19 12:38:12 <sipa> there are libraries for many languages available already
143 2014-05-19 12:38:38 <wumpus> in Python you just need a proxy object, no need to encode any commands, they are wrapped automatically
144 2014-05-19 12:38:39 <sipa> you likely only need a few commands
145 2014-05-19 12:38:52 <wumpus> what language are you using?
146 2014-05-19 12:38:55 <minium> sipa: ideally, what I'm imagining, is to include a header file with all the RPC's and just use them
147 2014-05-19 12:38:57 <minium> C++
148 2014-05-19 12:40:13 <wumpus> yeah, including the header file isn't going to work, it won't magically wrap calls to another process in a lower-level language like C++
149 2014-05-19 12:42:37 <minium> I've found an example in Python https://gist.githubusercontent.com/shirriff/bfc4df70a02732493a28/raw/bitcoin-insertion-tool.py
150 2014-05-19 12:43:15 <minium> wumpus: like you said, in it you only use a proxy object and everything else is taken care of for you
151 2014-05-19 12:44:04 <minium> something like that for C++ would be nice
152 2014-05-19 12:44:58 <wumpus> there are json-rpc libraries for C++ too
153 2014-05-19 12:45:22 <hearn> hey guys
154 2014-05-19 12:45:29 <minium> hearn: hey
155 2014-05-19 12:45:48 <wumpus> although you can't have a 'nice' proxy object as in python, but with some more verbosity you'll be able to accomplish the same
156 2014-05-19 12:45:49 <minium> wumpus: would I be able to use them like in the python-example I've stated above?
157 2014-05-19 12:45:52 <wumpus> hearn: hey
158 2014-05-19 12:46:00 <wumpus> minium: sure
159 2014-05-19 12:58:34 <michagogo> How far in advance do you think a hard-fork would need to happen to protect against the year 2106 problem?
160 2014-05-19 13:11:35 <wumpus> I'm quite sure that won't cause a hard-fork at all, by 2106 everyone will have upgraded to a version after 0.9
161 2014-05-19 13:14:05 <michagogo> wumpus: Hm? At some point, some version needs to allocate more bits to the various timestamp fields
162 2014-05-19 13:14:30 <michagogo> (well, those of them that are 32 bits)
163 2014-05-19 13:14:31 <michagogo> Including the block timestamp
164 2014-05-19 13:14:47 <wumpus> oh, I thought you were talking about the BIP42 problem
165 2014-05-19 13:14:53 <michagogo> Hmm?
166 2014-05-19 13:14:59 <gribble> bips/bip-0042.mediawiki at master · bitcoin/bips · GitHub: <https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki>; bips/bip-0042 at master · bitcoin/bips · GitHub: <https://github.com/bitcoin/bips/tree/master/bip-0042>; Bitcoin / Mailing Lists - SourceForge: <http://sourceforge.net/p/bitcoin/mailman/message/32175008/>
167 2014-05-19 13:14:59 <michagogo> ;;google BIP42
168 2014-05-19 13:15:36 <wumpus> but yes the timestamps need to be bumped to 64 bit as well at some point (and maybe 128 bit later)
169 2014-05-19 13:15:42 <michagogo> Yeah, no
170 2014-05-19 13:15:57 <wumpus> or even better, use a varint
171 2014-05-19 13:16:15 <michagogo> The Y2106 problem is like the Y2038 problem, but for unsigned numbers
172 2014-05-19 13:16:38 <michagogo> Erm, I think 64 bits are plenty...
173 2014-05-19 13:17:11 <Luke-Jr> 32-bit is plenty for a block timestamp
174 2014-05-19 13:17:17 <michagogo> Quote: Using a signed 64-bit value introduces a new wraparound date that is over twenty times greater than the estimated age of the universe: approximately 292 billion years from now, at 15:30:08 on Sunday, 4 December 292,277,026,596.
175 2014-05-19 13:17:36 <michagogo> Luke-Jr: How do you mean? Just let it wrap around?
176 2014-05-19 13:17:42 <Luke-Jr> michagogo: sure, why not? :P
177 2014-05-19 13:17:49 <michagogo> Well, that's still a hardfork
178 2014-05-19 13:17:54 <michagogo> (right?)
179 2014-05-19 13:18:02 <wumpus> well if we plan for 2106 we may as well plan for the year 1 billion right, we'll be just as dead in both
180 2014-05-19 13:18:04 <Luke-Jr> is it? I'm not sure
181 2014-05-19 13:18:22 <Luke-Jr> probably is
182 2014-05-19 13:18:32 <michagogo> Luke-Jr: I assume it would need to know that it wrapped around
183 2014-05-19 13:18:57 <michagogo> wumpus: erm, 64 bits is planning for the year ~58 billion
184 2014-05-19 13:18:58 <Luke-Jr> might as well just truncate the last 8 bits when it overflows :P
185 2014-05-19 13:19:43 <michagogo> But the wrap-around idea may actually work
186 2014-05-19 13:20:03 <Luke-Jr> anyhow, we have at least 23 more years to think about it :p
187 2014-05-19 13:20:04 <michagogo> And if it's decided to do that, the software change could be made now
188 2014-05-19 13:20:10 <wumpus> yeah - wrap around would be better, wouldn't need to break compatibility with old clients when it is implemented
189 2014-05-19 13:20:40 <michagogo> Virtually guaranteeing that nobody will be using the unupdated software when the hard-fork triggers
190 2014-05-19 13:20:43 <wumpus> sure, in 2106 the old clients will still fail, but let's assume no one will be running current versions at that time anymore
191 2014-05-19 13:20:58 <wumpus> right
192 2014-05-19 13:21:43 <michagogo> hmm
193 2014-05-19 13:21:58 <Luke-Jr> we should just expand the block header to 144 bytes at some hardfork :p
194 2014-05-19 13:22:38 <michagogo> 144?
195 2014-05-19 13:22:45 <michagogo> Expand the nonce?
196 2014-05-19 13:22:52 <Luke-Jr> sure
197 2014-05-19 13:23:01 <Luke-Jr> 144 is compatible with *almost* all existing miners
198 2014-05-19 13:23:09 <Luke-Jr> basically just not Avalon2/3
199 2014-05-19 13:23:26 <Luke-Jr> and breaks stratum/GBT too, of course, but that's mere software
200 2014-05-19 13:23:46 <wumpus> yeah, breaking hardware miners would be bad, even worse than a normal hard fork
201 2014-05-19 13:23:48 <Luke-Jr> (you just have 2 blocks in the SHA2 midstate instead of 1)
202 2014-05-19 13:23:56 <michagogo> ;;blocks
203 2014-05-19 13:23:57 <gribble> 301553
204 2014-05-19 13:24:12 <michagogo> We'd have around 5 million blocks by then
205 2014-05-19 13:24:38 <Luke-Jr> as hardware moves more processing into the hardware, the ability to hardfork the block header without breaking compat drops
206 2014-05-19 13:24:49 <Luke-Jr> so it might actually be better to hardfork for 144 byte headers sooner rather than later
207 2014-05-19 13:24:49 <michagogo> Right
208 2014-05-19 13:25:20 <wumpus> though if you plan ahead far enough, it's not a problem, let's say that you make the change by 2080, hardware vendors can prepare well in advance
209 2014-05-19 13:25:48 <Luke-Jr> wumpus: why would they do that, when they can just take advantage of the hardfork to force miners to upgrade? ;)
210 2014-05-19 13:26:01 <wumpus> hehe
211 2014-05-19 13:27:08 <michagogo> 16:24:50 <Luke-Jr> so it might actually be better to hardfork for 144 byte headers sooner rather than later <-- Hmm, that's an interesting point
212 2014-05-19 13:27:28 <michagogo> I wonder if it may be worth starting this discussion seriously
213 2014-05-19 13:28:23 <minium> wumpus: I see somebody has already implemented an interface for JSON-RPC communication with the wallet (https://github.com/neojjang/bitcoinapi)
214 2014-05-19 13:31:21 <wumpus> well you can always propose it on the mailing list with some good reasons, and maybe write a BIP, there's no saying when it will be done but it doesn't hurt to have a concrete proposal
215 2014-05-19 13:31:44 <wumpus> minium: great!
216 2014-05-19 14:06:08 <devthink_> I asked this question about Bitcoin-Qt on Sunday. Given that the RPC password and wallet passphrase are in place, is there any reason not to return CORS headers to a browser. (CORS headers circumvent the browser's "same origin" policy). Also, the CORS header could be restricted to localhost.
217 2014-05-19 14:07:01 <wumpus> when does bitcoin-qt interact with a browser?
218 2014-05-19 14:07:02 <KuDeTa> is there some kind of stats package i can use to monitor my bitcoind nodes behaviour?
219 2014-05-19 14:08:20 <devthink_> A page script would be dlownloaded from (my) Bitcoin site.  I would be able to submit RPC commands (like listunspent) to the wallet and display the results in the browser.
220 2014-05-19 14:08:24 <wumpus> KuDeTa: see http://statoshi.info/ https://jlopp.github.io/statoshi/
221 2014-05-19 14:08:43 <wumpus> KuDeTa: you can already get some basic statistics though JSON RPC though, depending on what you want
222 2014-05-19 14:09:15 <KuDeTa> just somethin i can load into apache and monitor load/transactions/network etc. Will check those links, thanks
223 2014-05-19 14:10:15 <wumpus> devthink_: hmm I wouldn't be opposed to optionally returning an extra header, if there is a usecase for that
224 2014-05-19 14:12:31 <devthink_> the use case would be to allow a JS page script (rather than a downloaded App) to access the wallet.
225 2014-05-19 14:13:45 <wumpus> but would that work? can a script in a browser do JSON RPC?
226 2014-05-19 14:14:05 <KuDeTa> this satoshi.info thing looks great wumpus
227 2014-05-19 14:15:39 <KuDeTa> its a fork of bitcoind?
228 2014-05-19 14:16:02 <devthink_> wumpus: yes, a script can perform JSON-RPC just like any other HTTP access. however, the browser's "same origin" policy precludes access away from the original web site.
229 2014-05-19 14:16:41 <devthink_> CORS headers tells the browser that it is ok to access the foreign site
230 2014-05-19 14:17:54 <wumpus> devthink_: I'd say, experiment with it a bit to see if it really works, and if it does submit a pull
231 2014-05-19 14:18:19 <devthink_> ok
232 2014-05-19 14:18:31 <wumpus> KuDeTa: yes, it needs some changes to the source code to issue events to stats
233 2014-05-19 14:18:34 <wumpus> +d
234 2014-05-19 14:18:50 <KuDeTa> hmm cool
235 2014-05-19 14:18:58 <KuDeTa> need to upgrade to 14.04 to make my life easier
236 2014-05-19 14:19:13 <KuDeTa> a(ubuntu, that is) anyway, thanks dude
237 2014-05-19 14:19:57 <devthink_> also FYI, when accessing bitcointalk from FF, I get "The OCSP server experienced an internal error."
238 2014-05-19 14:21:54 <Ry4an> you don't need CORS headers on the JSON endpoints if you support jsonp.  That's how everyone idd it before the CORS spec and still the modst common.
239 2014-05-19 14:23:46 <wumpus> that would need more changes to bitcoind than just adding a header
240 2014-05-19 14:24:05 <anton000> how much mem is ideal for bitcoind node now?
241 2014-05-19 14:25:21 <wumpus> 1GB
242 2014-05-19 14:25:32 <anton000> for it alone yes? :)
243 2014-05-19 14:25:33 <anton000> ok
244 2014-05-19 14:25:53 <anton000> ************************
245 2014-05-19 14:25:53 <anton000> 2014-05-19 13:42:38 Pre-allocating up to position 0x8000000 in blk00140.dat
246 2014-05-19 14:25:53 <anton000> 2014-05-19 13:42:41
247 2014-05-19 14:25:53 <anton000> bitcoin in ProcessMessages()
248 2014-05-19 14:25:53 <anton000> EXCEPTION: St9bad_alloc
249 2014-05-19 14:25:53 <anton000> std::bad_alloc
250 2014-05-19 14:26:20 <wumpus> my node has 1.5GB but it seems that bitcoind never grows larger than ~600MB (resident)
251 2014-05-19 14:26:21 <anton000> got a bad alloc error ona small box with 512mb free
252 2014-05-19 14:26:48 <wumpus> that's with 0.9.2?
253 2014-05-19 14:27:00 <anton000> 0.9.1
254 2014-05-19 14:27:04 <wumpus> eh, yes
255 2014-05-19 14:27:11 <kjj> if I recall, that message has nothing to do with memory
256 2014-05-19 14:27:27 <wumpus> you could try reducing the dbcache size
257 2014-05-19 14:27:58 <KuDeTa> another question: my cpu usage with bitcoind is through the roof (150%!!) - is that just becasue i'm still catchig up? What are the min recommended specs?
258 2014-05-19 14:28:01 <wumpus> the default is 100mb, but it will run with 10mb or so
259 2014-05-19 14:28:39 <wumpus> I don't think we have any other tunable parameters that affect memory use
260 2014-05-19 14:29:25 <wumpus> KuDeTa: it can use 100% of all your cores while catching up, if that is too much set the paralellism with -par command line flag
261 2014-05-19 14:30:03 <KuDeTa> cheers wumpus - i can expect it to drop dramatically when it has caught up fully?
262 2014-05-19 14:30:05 <wumpus> there are no min recommended specs for the CPU, even a lowly ARM box can keep up once synced up
263 2014-05-19 14:30:13 <wumpus> yes
264 2014-05-19 14:30:19 <KuDeTa> no worries then, thanks
265 2014-05-19 14:31:44 <KuDeTa> i wonder if hte devs will decide to incentivise running nodes one day
266 2014-05-19 14:32:43 <wumpus> if no one runs nodes, the network will die... that's enough incentive isn't it :)
267 2014-05-19 14:33:13 <anton000> use cpulimit ?
268 2014-05-19 14:33:19 <kjj> the devs have no power to incentivise
269 2014-05-19 14:33:22 <KuDeTa> yea, i guess the worry is that it doesn't make sense for the average user to do..and certainly won't one we get good SPV clients etc. Might be smart to avoid node centralisation
270 2014-05-19 14:33:45 <stonecoldpat> it wouldnt be the dev's role to provide an incentive - they make the software - they aren't responsible for making people use it
271 2014-05-19 14:34:07 <wumpus> average users really don't need to run nodes
272 2014-05-19 14:35:47 <KuDeTa> there is a model of some kind though right? Some of the alt coins are doing it if i remember correct. I guess we learned a lot form the way mining has turned out, i think it would be nice to avoid the same centralisation of nodes, and have a good number of average webdev's/server operators doing it rather than some big companies.
273 2014-05-19 14:36:19 <KuDeTa> what do they call them? Masternodes or something
274 2014-05-19 14:36:21 <wumpus> agree on webdevs/server operators, that's not 'average users'
275 2014-05-19 14:37:11 <anton000> 0.9.2 realased?
276 2014-05-19 14:37:14 <wumpus> it should just be easy to set up a node
277 2014-05-19 14:37:43 <KuDeTa> no no, i agree wumpus - think i also read somewhere that actually many of the 'nodes' currently running are a little bit harmful if people are trying to do it on home broadband with limited connections/no open ports
278 2014-05-19 14:38:35 <wumpus> and indeed, more aimed at people that manage servers or VPSes with big pipes, sysadmins, developers, etc, the 'let's make it part of the wallet!' really doesn't make sense anymore
279 2014-05-19 14:38:50 <KuDeTa> ah yes it's DarkCoin that uses the masternode concept
280 2014-05-19 14:39:07 <wumpus> anton000: when? :p
281 2014-05-19 14:39:27 <wumpus> when I said 0.9.2 above it was just a typo
282 2014-05-19 14:39:53 <anton000> lol
283 2014-05-19 14:40:10 <wumpus> 0.9.2 won't take long anymore though, we have some issues with the gitian mac build to work out
284 2014-05-19 14:41:27 <gavinandresen> wumpus: I'm happy to build the osx 0.9.2 binaries if gitian mac build takes too long (and I'd suggest you set a deadline so it doesn't drag out too long)
285 2014-05-19 14:41:33 <anton000> releases got harder cause of static builds
286 2014-05-19 14:43:18 <wumpus> gavinandresen: yes good point
287 2014-05-19 14:43:46 <wumpus> anton000: huh?
288 2014-05-19 14:44:31 <anton000> supposed to be a question
289 2014-05-19 14:44:50 <anton000> did it?
290 2014-05-19 14:45:40 <wumpus> anton000: not really, it's still the same gitian build, but macosx was never built using that
291 2014-05-19 14:47:44 <wumpus> maybe even if we don't manage to get the macosx gitian build 100% determinisic it could be useful, at least it gives a consistent way of building executables for macosx with qt5
292 2014-05-19 15:44:32 <RocketNuts> if I have two bitcoind nodes running separately on the same system, each with a different data dir (and different port, different wallet etc), how can I interact with each of them from the command line?
293 2014-05-19 15:44:51 <RocketNuts> e.g. if I do bitcoind getinfo, what instance will it get the info from? (and how do I specify which instance I need?)
294 2014-05-19 15:45:40 <kjj> usually quickest to specify the config file with the port info
295 2014-05-19 15:45:51 <kjj> but you can specify a server and port too
296 2014-05-19 15:48:03 <RocketNuts> how do you mean? I started one instance with "bitcoind -daemon" (using the default ~/.bitcoin/ data dir, which has a bitcoin.conf which specifies no port, so it uses default 8333) and another with "bitcoind --datadir=~/.bitcoin2 -daemon" and ~/.bitcoin2/bitcoin.conf contains a port= setting (so it uses another port)
297 2014-05-19 15:48:16 <RocketNuts> now if I do bitcoind getinfo, it gets the first instance,
298 2014-05-19 15:48:28 <kjj> bitcoind -conf=~/.bitcoin2/bitcoin.conf getinfo
299 2014-05-19 15:48:50 <michagogo> s/bitcoind/bitcoin-cli/
300 2014-05-19 15:48:53 <RocketNuts> ah, ok, so also for sending commands it will then interact with whatever instance is running using that same config?
301 2014-05-19 15:49:05 <michagogo> Using bitcoind for sending commands is deprecated
302 2014-05-19 15:49:23 <RocketNuts> oh, should that be bitcoin-cli nowadays?
303 2014-05-19 15:49:30 <michagogo> yep
304 2014-05-19 15:49:34 <kjj> the client will use the same address and port info for the query that the daemon used to bind itself
305 2014-05-19 15:49:41 <RocketNuts> what's bitcoind for, just the daemon?
306 2014-05-19 15:50:08 <RocketNuts> should I still do "bitcoind -daemon" to start a daemon in the background? (and, optionally, do the same with --datadir=otherdir for additional daemon instances) ?
307 2014-05-19 15:51:23 <kjj> you should probably write a couple of scripts for your init system that handle startup and shutdown
308 2014-05-19 16:03:04 <RocketNuts> kjj I can't figure out how to get it running actually.. I have one default bitcoin core installed and running (0.9.1) with ./bitcoin as data dir (containing bitcoin.conf and blocks dir etc), all running fine
309 2014-05-19 16:03:57 <RocketNuts> also got a ./bitcoin2 data dir (containing a bitcoin.conf as well, which specifies port=9444) but I can't seem to get a bitcoin daemon instance running with that second dir & config..?
310 2014-05-19 16:04:58 <kjj> here is the line from my init scripts:
311 2014-05-19 16:05:00 <kjj> sudo -u bitcoind $BINFILE -conf=$CONFFILE -pid=$PIDFILE -daemon -datadir=$DATADIR
312 2014-05-19 16:05:31 <RocketNuts> For example, I try "bitcoind --datadir=~/.bitcoin2 --conf=~/.bitcoin2/bitcoin.conf --port=9444 -daemon" but it keeps saying data directory "~/.bitcoin2" does not exist. But it does.
313 2014-05-19 16:05:45 <RocketNuts> ok and what is $DATADIR, exactly?
314 2014-05-19 16:05:57 <RocketNuts> with or without trailing /, with or without quotes, etc?
315 2014-05-19 16:06:37 <kjj> with leading and trailing slashes, and enclosed in quotes, in my system
316 2014-05-19 16:06:59 <RocketNuts> ok
317 2014-05-19 16:07:07 <RocketNuts> and $BINFILE? (I don't seem to specify that here)
318 2014-05-19 16:07:13 <RocketNuts> oh and -pid param, good point
319 2014-05-19 16:07:30 <kjj> BINFILE is /usr/local/bin/bitcoind on my system
320 2014-05-19 16:09:29 <RocketNuts> damn... it keeps saying: data directory "~/.bitcoin2" does not exist
321 2014-05-19 16:09:39 <RocketNuts> but the dir is really there (and with all access rights etc)
322 2014-05-19 16:14:36 <wumpus> dont use ~
323 2014-05-19 16:14:41 <wumpus> but $HOME
324 2014-05-19 16:16:06 <RocketNuts> ah, right
325 2014-05-19 16:16:36 <MarkyRamone> anyone can give me just one node of the testnet3 network?
326 2014-05-19 16:20:45 <wumpus> ~ is a shell nicety and only works where the shell interprets the filename, which is only if it is the first character of an argument
327 2014-05-19 16:29:50 <evan82> How do I figure out the possible sizes of a normally structured CScript?
328 2014-05-19 18:57:33 <aschildbach> petertodd: Are you around?
329 2014-05-19 18:58:48 <mappum> does core make sure peers aren't behind a NAT before sending them in addr messages?
330 2014-05-19 19:15:47 <helo> mappum: yep, see IsRoutable() in netbase.cpp