1 2015-02-17 00:30:38 <rgenito> i wonder... do any bitcoin app developers hang out here? or just bitcoin developers in general?
  2 2015-02-17 00:31:12 <Luke-Jr> uh, what's the difference? O.o
  3 2015-02-17 00:31:34 <Luke-Jr> or rather, what are you actually asking?
  4 2015-02-17 00:31:55 <rgenito> good point. wondering if anyone else here uses pycoin for their apps
  5 2015-02-17 00:32:12 <rgenito> i'm searching away in pycoin's code for the functionality to broadcast a transaction
  6 2015-02-17 00:32:30 <rgenito> we're using electrum now and blockchain.info's pushtx as a fall back
  7 2015-02-17 00:43:43 <fanquake> ;;blocks
  8 2015-02-17 00:43:44 <gribble> 343810
  9 2015-02-17 03:37:33 <askuck> will the network accept a block where the coinbase reward is below the current bounty level? (ie the miner sends the 5 btc to their specified address)
 10 2015-02-17 03:41:37 <gmaxwell> Sure.
 11 2015-02-17 03:41:43 <gmaxwell> and such things exist in the mainchain.
 12 2015-02-17 03:44:03 <askuck> gmaxwell: cool beans! thanks.
 13 2015-02-17 03:53:53 <phantomcircuit> has anybody looked at the runtime complexity of the json encoder for rpc calls?
 14 2015-02-17 03:54:08 <phantomcircuit> it should be roughly linear but...
 15 2015-02-17 04:23:28 <sipa> phantomcircuit: do the analysis for univalue, and if that's good, argue we should switch
 16 2015-02-17 05:47:13 <gmaxwell> Pretty sure we should switch just on the basis of compile time / memory.
 17 2015-02-17 05:51:26 <jgarzik> Here is the tree, converted to UniValue: https://github.com/jgarzik/bitcoin/tree/2014_univ_conv
 18 2015-02-17 05:52:01 <jgarzik> Now that 0.10 is out, my top item is to bang through the few remaining failing tests, and then PR it
 19 2015-02-17 05:52:43 <jgarzik> Only a few tests -- inevitably fiddly bits getting numeric output perfect -- block the death of json_spirit
 20 2015-02-17 06:00:47 <gmaxwell> \O/
 21 2015-02-17 06:12:11 <jgarzik> After UniValue, next item is crypto accelerators for moxiebox.  That should be fun.  atgreen added gdb & gprof support.
 22 2015-02-17 06:20:01 <gmaxwell> other than BIP66, the logging unsanitized output, and fork warning crash; is anyone aware of anything else that needs to be backported to 0.9.x?
 23 2015-02-17 06:20:31 <gmaxwell> (or rather, needs to be included in a new 0.9.x release as some of those are already backported)
 24 2015-02-17 06:58:50 <sipa> jgarzik: anxiously awaiting the death of jsonspirit :)
 25 2015-02-17 07:01:39 <jgarzik> The project is already at Linus stage #3: it builds!
 26 2015-02-17 07:02:07 <phantomcircuit> hmm?
 27 2015-02-17 07:02:21 <phantomcircuit> a json spirit replacement??
 28 2015-02-17 07:02:24 <phantomcircuit> horray
 29 2015-02-17 07:02:32 <jgarzik> phantomcircuit, it's already in-tree even ;p
 30 2015-02-17 07:02:36 <sipa> univalue has been merged like a year ago
 31 2015-02-17 07:02:45 <sipa> rpc just wasn't yet converted
 32 2015-02-17 07:10:34 <wumpus> jgarzik: well getting the numeric output 100% correct is important in this case, I don't quite remember what type do you use for json floats in univalue?
 33 2015-02-17 07:11:53 <wumpus> I suppose the best would be to go from satoshis to JSON float (and vice versa) directly, getting rid of ValueFromAmount/AmountFromValue and the intermediate double conversion
 34 2015-02-17 07:12:03 <wumpus> ie, fixed point all the way
 35 2015-02-17 07:12:25 <wumpus> but maybe you already did
 36 2015-02-17 07:13:40 <wumpus> gmaxwell: no idea, 0.9 was a long time ago, there may be tons of things that could be backported, but I can't think of anything critical off the bat
 37 2015-02-17 07:20:30 <wumpus> maybe Luke-Jr has some ideas
 38 2015-02-17 07:23:14 <phantomcircuit> https://github.com/bitcoin/bitcoin/compare/v0.9.4...v0.10.0
 39 2015-02-17 07:23:26 <wumpus> phantomcircuit: lol
 40 2015-02-17 07:23:27 <phantomcircuit> it would be nice if you could filter out the "merged"
 41 2015-02-17 07:23:43 <wumpus> git log --no-merges ?
 42 2015-02-17 07:24:03 <phantomcircuit> yeah i know i meant on github
 43 2015-02-17 07:24:10 <wumpus> anyhow, that's way too much to go through
 44 2015-02-17 07:24:29 <phantomcircuit> not really it's mostly trivial i think
 45 2015-02-17 07:24:49 <wumpus> you could just as well look at the release notes for 0.10 in that case which has a list of important commits too
 46 2015-02-17 07:25:17 <wumpus> (which is still a lot, but at least excludes refactors and trivial changes)
 47 2015-02-17 07:27:45 <wumpus> (and everything that already made it to <=0.9.3 through cherrypicking)
 48 2015-02-17 07:31:08 <phantomcircuit> wumpus, nvm it's 1200 commits
 49 2015-02-17 07:32:01 <wumpus> heh
 50 2015-02-17 07:41:19 <phantomcircuit> iono most of these are pretty obvious y/n
 51 2015-02-17 08:01:51 <bedeho> do standard p2pkh pubKeyHash scripts contain OP_CODESEPERATORS?
 52 2015-02-17 08:02:49 <phantomcircuit> bedeho, for a brief moment they kind of do in a way
 53 2015-02-17 08:02:50 <phantomcircuit> sort of
 54 2015-02-17 08:06:54 <bedeho> phantomcircuit: not sure I understand what you mean?
 55 2015-02-17 08:07:19 <bedeho> trying to understand OP_CHECKSIG, and it seems to imply that pubkeyhash may have op_codeseperators
 56 2015-02-17 08:07:29 <bedeho> is that the exception or the rule?
 57 2015-02-17 08:07:41 <phantomcircuit> you should read the source around that stuff
 58 2015-02-17 08:07:46 <bedeho> :/
 59 2015-02-17 08:09:07 <wumpus> codeseparator is not normally used in the scripts
 60 2015-02-17 08:09:49 <bedeho> wumpus: ok, great
 61 2015-02-17 08:10:08 <bedeho> does its presence make the pubkeyhash nonstandard if it otherwise looks like the standard p2pkh ?
 62 2015-02-17 08:10:21 <wumpus> I'm not exactly sure what phantomcircuit means though, I may be missing something
 63 2015-02-17 08:11:48 <wumpus> does it make the pubkeyhash nonstandard? sorry, I don't get you
 64 2015-02-17 08:11:50 <phantomcircuit> oh nvm
 65 2015-02-17 08:12:03 <phantomcircuit> wumpus, iirc there used to be weirdness with OP_CHECKSIG and OP_CODESEPARATOR
 66 2015-02-17 08:12:10 <phantomcircuit> but i cant remember exactly
 67 2015-02-17 08:12:28 <wumpus> phantomcircuit: OP_CODESEPARATOR is weirdness
 68 2015-02-17 08:12:38 <bedeho> :D
 69 2015-02-17 08:12:55 <phantomcircuit> wumpus, the codes been refactored but it's still there
 70 2015-02-17 08:13:18 <phantomcircuit> OP_CHECKSIG only applies to the stuff after OP_CODESEPARATOR
 71 2015-02-17 08:13:38 <bedeho> indeed, and if not there, the whole pubkey is used
 72 2015-02-17 08:13:47 <phantomcircuit> bedeho, script/interpreter.cpp SerializeScriptCode
 73 2015-02-17 08:14:02 <phantomcircuit> but yeah it's kind of weird logic
 74 2015-02-17 08:14:36 <bedeho> *looking*
 75 2015-02-17 08:15:04 <bedeho> one thing I am not understanding is, why does op_checksig copy the pubkey into the scriptSig of the given input when computing the sighash?
 76 2015-02-17 08:15:12 <bedeho> even leaving codeseperator aside
 77 2015-02-17 08:15:19 <bedeho> that makes no sense to me
 78 2015-02-17 08:27:41 <gmaxwell> bedeho: pubkey should logically be under the signature to prevent rebinding. In bitcoin thats already prevented another way (via the txin hashes), so its redundant.
 79 2015-02-17 08:28:54 <bedeho> gmaxwell: thank you.
 80 2015-02-17 08:58:49 <Luke-Jr> wumpus: JSON does not have a float type, just an implementation-undefined Number ;)
 81 2015-02-17 08:59:33 <wumpus> Luke-Jr: yes. Replace 'float' with 'number' in what I said above
 82 2015-02-17 08:59:51 <wumpus> (numbers with a point in them, in this case)
 83 2015-02-17 09:00:27 <rgenito> Luke-Jr, gotta check it out man
 84 2015-02-17 09:00:36 <rgenito> we've opened our API so anyone can buy/sell from our inventory
 85 2015-02-17 09:00:46 <rgenito> not "our" inventory, but everyone's basically
 86 2015-02-17 09:00:52 <Luke-Jr> rgenito: this is off-topic here
 87 2015-02-17 09:01:25 <rgenito> ah ok...it's not related to bitcoin development?
 88 2015-02-17 09:22:02 <wumpus> well there is a common agreement that this channel is about development of bitcoin core as well as the network itself, and potentially other software that interfaces with the P2P network.  third-party APIs are considered off-topic
 89 2015-02-17 09:22:40 <rgenito> i'm fine with that :) i don't wanna steer off the topic
 90 2015-02-17 09:40:43 <bengt_> is the plan to drop openssl entirely or just get it out of the consensus sensitive stuff? from what I can tell if you compile it with USE_SECP256K1 it is only used for encryption and random number generation? I.e. are there plans to write your own implementations for that stuff too?
 91 2015-02-17 09:41:12 <bengt_> note not suggesting you should lol
 92 2015-02-17 09:46:25 <rgenito> man...why peeps not using /dev/random for random numbers? damn.
 93 2015-02-17 09:46:42 <rgenito> 
ACTION is just rankin'

 94 2015-02-17 09:46:48 <rgenito> lol rantin'*
 95 2015-02-17 09:55:46 <wumpus> bengt_: well the urgent goal is to get openssl out of the consensus implementation, removing the dependency on openssl completely 'would be nice'
 96 2015-02-17 09:56:49 <wumpus> replacing the cryptographic randomness should not be done lightly, for the rest openssl is potentially used for RPC (but that's planned to be dropped)
 97 2015-02-17 09:57:45 <wumpus> that's for bitcoind, the GUI will keep needing openssl to support https:// for payment requests
 98 2015-02-17 09:58:54 <lewellyn> now that polarssl is being renamed to mbed tls and relicensing to apache, that may be even a place openssl can be removed soon.
 99 2015-02-17 10:00:28 <wumpus> that depends on upstream decisions though; e.g. if the qt project will go with that
100 2015-02-17 10:02:51 <lewellyn> iirc, qt can use polarssl. so i expect that it'll gain mbed tls support soon.
101 2015-02-17 10:04:30 <wumpus> sure? last time I checked it looked like qt was quite tightly coupled to openssl for crypto, or does it have a very similar interface?
102 2015-02-17 10:06:04 <wumpus> ah, it's supposed to be openssl compatible, that explains it
103 2015-02-17 10:06:06 <lewellyn> it has at least some degree of compat layer. i don't know the details. i use qt with a commercial non-openssl security provider, though. so it's likely not THAT coupled.
104 2015-02-17 10:06:11 <bengt_> wumpus: I see, thanks
105 2015-02-17 10:06:43 <wumpus> lewellyn: probably something out of tree then?
106 2015-02-17 10:06:54 <lewellyn> but since it's becoming part of the mbed platform, digia's likely to support it.
107 2015-02-17 10:07:11 <lewellyn> wumpus: qt has a bajillion knobs. :/
108 2015-02-17 10:07:37 <bengt_> I definitely see the advantages of having separate easy-to-audit libraries rather than the huge blob of esoteric code that is openssl
109 2015-02-17 10:08:06 <lewellyn> openssl's real problem is that it's not had proper stewardship.
110 2015-02-17 10:08:41 <lewellyn> there's no one person or small group who can immediately answer any question about any part of the codebase. and we're seeing the results of that lately.
111 2015-02-17 10:08:49 <wumpus> bengt_: for the specialzed crypto primitives for e.g. consensus that is a good point, TLS on the other hand is a labyrinth of a protocol whose implementations are always hard to audit
112 2015-02-17 10:08:59 <bengt_> hopefully that will get better now that openssl has more funding
113 2015-02-17 10:09:12 <wumpus> tragedy of the commons, as usual
114 2015-02-17 10:09:19 <Luke-Jr> the code is terrible too
115 2015-02-17 10:09:21 <lewellyn> openssl needed fixing a dozen years ago. it's too little, too late.
116 2015-02-17 10:09:34 <bengt_> perhaps, but it is better than nothing never
117 2015-02-17 10:09:44 <gmaxwell> it's just largely irrelevant for our use.
118 2015-02-17 10:10:45 <lewellyn> i bitched about openssl wtf-ness 15+ years ago. and even then, no one really understood things well enough to really answer "why" types of questions.
119 2015-02-17 10:10:52 <gmaxwell> OpenSSL does with >400,000 very hard to audit, largely untestable, largely undocumented code.. what we only need about 10,000 lines of very straight forward and clear code for. As TLS things go its fine (? fine might not be the right word for anything TLS...) but it isn't what we need in Bitcoin.
120 2015-02-17 10:10:53 <lewellyn> security isn't something you should take on faith.
121 2015-02-17 10:11:24 <gmaxwell> bengt_: more funding makes it more dangerous for us, if anything.
122 2015-02-17 10:11:33 <wumpus> yes, apart from the GUI where we actually use TLS/SSL
123 2015-02-17 10:12:05 <gmaxwell> As we've seen, openssl can put out and update and there is a mad panic rush for distributions and users to roll out the update without even the most cursory of checks (and certantly no review for newly introduced backdoors)
124 2015-02-17 10:12:21 <bengt_> gmaxwell: I was thinking it'd increase the amount of review and security fixes it gets? are you worried about government backdoors?
125 2015-02-17 10:12:41 <lewellyn> bengt_: not even gov't backdoors. even private individuals can backdoor it at this point.
126 2015-02-17 10:13:25 <gmaxwell> bengt_: government?! wtf. come on please take this to #fantasy_land if you want to be in a world where governments are the only or even most interesting threats. ... I'm not talking about backdoors.
127 2015-02-17 10:14:02 <bengt_> :)
128 2015-02-17 10:14:03 <wumpus> bugs that happen to be usable as backdoors are more convient anyway
129 2015-02-17 10:14:50 <gmaxwell> Did you miss the lastest openssl "update" totally f@#$@ed bitcoin? openssl going and 'fix fix fix'ing thigns means they're going to break the software, and the consequences for breaking it are more significant for Bitcoin than most other users.  So long as they don't create remote execution vulnerabilities or totally bypass the crypto anything they break is forgivable for most applications.
130 2015-02-17 10:15:10 <gmaxwell> Not so much for Bitcoin.
131 2015-02-17 10:15:14 <bengt_> no I saw that, its an issue, I agree
132 2015-02-17 10:15:22 <bengt_> just didn't realize yuo were talking about that
133 2015-02-17 10:16:37 <bengt_> hopefully it won't happen again anytime soon...
134 2015-02-17 10:16:44 <bengt_> *wishful thinking*
135 2015-02-17 10:17:09 <gmaxwell> wumpus: at least the payment request stuff can be process seperated and sandboxed.
136 2015-02-17 10:19:08 <wumpus> gmaxwell: sure, would be pretty easy even
137 2015-02-17 10:20:25 <justanotheruser> Dumb question: Is there any reason not to have checkpoints in the case that a user is just downloading the client without auditing the source code?
138 2015-02-17 10:21:42 <wumpus> justanotheruser: I don't understand your question
139 2015-02-17 10:22:00 <gmaxwell> There little real reason to have them at all anymore with headers first, I expect them to go away during the 0.11 cycle.
140 2015-02-17 10:22:37 <kinlo> I was under the assumption checkpoints were just a speedup - known good hashes so you don't have to verify everything coz you know it's good
141 2015-02-17 10:22:41 <wumpus> wasn't the latest idea to replace them with verification shortcuts?
142 2015-02-17 10:22:43 <justanotheruser> wumpus: if someone isn't auditing the clients source code, why not just remove the risk of someone DoSing them by having them also not audit the initial download.
143 2015-02-17 10:22:58 <justanotheruser> or at least a chunk of the initial download
144 2015-02-17 10:23:04 <wumpus> kinlo: well right now they are not 'just a speedup'
145 2015-02-17 10:23:13 <wumpus> kinlo: right now they lock int the chain
146 2015-02-17 10:23:33 <wumpus> kinlo: but yes, one idea would be to make them just a speedup, without normative effect
147 2015-02-17 10:24:07 <gmaxwell> justanotheruser: because one is a transparrent commitment and one is not. If the source code were evil then there is some likelyhood that all the _other_ people auditing it would raise an alarm.
148 2015-02-17 10:25:00 <gmaxwell> wumpus: they're not needed for any speedup anymore, as we can now use the fact that we have verified headers on top and far ahead to do the same kind of shortcutting, and in a way that doesn't bitrot over time.
149 2015-02-17 10:25:16 <gmaxwell> oh you just said that.
150 2015-02-17 10:25:18 <gmaxwell> K. :)
151 2015-02-17 10:25:32 <justanotheruser> right, that is a good way to put it
152 2015-02-17 10:26:25 <wumpus> justanotheruser: there is no expectation that everyone is auditing the source code in the first place; the idea with gitian and deterministic builds is that there is a auditable chain from source code to released executables; so it suffices that some people audit source code changes, and the trust in the distributed files relies on that
153 2015-02-17 10:27:33 <wumpus> justanotheruser: so I don't see how specific people would be opened to doses just because they don't check the source code
154 2015-02-17 10:28:55 <justanotheruser> wumpus: my argument in question wasn't that people would be open to DoS because they didn't check the source code, it is that checkpoints are a DoS prevention mechanism and if they aren't auditing the source code the checkpoints aren't that much of an additional negative
155 2015-02-17 10:29:13 <gmaxwell> wumpus: I think the rational was that if you don't audit the source code, you don't care about your security, and your node might as well just do anything the network tells it.  The argument doesn't hold water in that there is a process which can make the source code faithful even if you don't review it, but that doesn't hold for your peers.
156 2015-02-17 10:30:15 <gmaxwell> They're not production-pratically an additional negative, beyond being a maintaince burden. But they're a hack and they cause enormous harm in causing confusion about the security model.
157 2015-02-17 10:30:16 <justanotheruser> the blockchain is secured for people who don't audit the source code by those who do and the outlets they can use to inform you of malice and the consensus mechanism?
158 2015-02-17 10:30:37 <justanotheruser> is that what you're saying
159 2015-02-17 10:31:33 <gmaxwell> (in particular, they're used by confused and dishonest people to push totally broken alternative systems, e.g. ones whos security arises out of a single anonymous developer signing the blocks and broadcasting that to the network; which they helpfully also call "checkpoints")
160 2015-02-17 10:32:10 <gmaxwell> justanotheruser: Hopefully, it's obviouslly not as strong as checking for yourself (or having your own people check for you).
161 2015-02-17 10:32:50 <gmaxwell> turns out that there are a lot of things basically no one reviews, and communications of flaws is very lossy.
162 2015-02-17 10:33:04 <justanotheruser> it is similar to how bitcoin works internally as well I think. I can be connected to 30 media sources who can give me proof that something is wrong with my current system and I need to fix it
163 2015-02-17 10:33:09 <wumpus> yes, the checkpoints are certainly misunderstood by a lot of people and result in confusion with systems that strongly rely on them, so from that angle it would be good to rid of them
164 2015-02-17 10:33:17 <gmaxwell> (consider all the services and practices that people on IRC have been saying for years are broken and still joe average ends up using them)
165 2015-02-17 10:34:28 <dario_> Hallo everyone!
166 2015-02-17 10:34:32 <dario_> Quick question:
167 2015-02-17 10:35:00 <dario_> How do I subscribe to the bitcoin-documentation mailing list?
168 2015-02-17 10:35:32 <justanotheruser> dario_: the bitcoin-development mailing list?
169 2015-02-17 10:35:47 <gmaxwell> first create the bitcoin-documentation and then subscribe to it?
170 2015-02-17 10:35:48 <dario_> No, the bitcoin-documentation mailing list
171 2015-02-17 10:36:12 <dario_> It's mentioned on the developer reference...
172 2015-02-17 10:36:27 <justanotheruser> oh wow
173 2015-02-17 10:36:28 <justanotheruser> nice catch
174 2015-02-17 10:37:21 <dario_> It seems the posting address is bitcoin-documentation@googlegroups.com, but I can find no info on the subscription address...
175 2015-02-17 10:37:46 <gmaxwell> Never heard of it, alas. I think googlegroups have a uniform interface at least.
176 2015-02-17 10:37:46 <justanotheruser> it looks like a you can post there if you have a google account https://groups.google.com/forum/#!forum/bitcoin-documentation
177 2015-02-17 10:38:09 <justanotheruser> is there a wizards mailing list?
178 2015-02-17 10:38:18 <dario_> OK
179 2015-02-17 10:38:46 <dario_> I have a question/request the developer reference, and it seems that mailing list may be the appropriate place...
180 2015-02-17 10:39:12 <justanotheruser> you probably could ask here or #bitcoin unless its a correction
181 2015-02-17 10:39:26 <dario_> It's not a correction per se...
182 2015-02-17 10:39:51 <dario_> The JSON RPC docs could be much better if...
183 2015-02-17 10:40:08 <dario_> the proper types were associated with each parameter...
184 2015-02-17 10:40:43 <dario_> Right now, the API reference is "stringly-typed", which is a disaster waiting to happen...
185 2015-02-17 10:41:09 <dario_> I created and maintain the OCaml bindings to the Bitcoin core API...
186 2015-02-17 10:41:18 <wumpus> have you looked at the help output from RPC itself?
187 2015-02-17 10:41:28 <wumpus> it specifies the types, these days
188 2015-02-17 10:42:02 <dario_> Yes, of course.  But the type information is not as precise and consistent as I need it...
189 2015-02-17 10:42:16 <dario_> (Unless 0.10 drastically improved on this; I haven't tried it yet)
190 2015-02-17 10:42:29 <wumpus> JSON doesn't really have an abundance of types
191 2015-02-17 10:42:37 <wumpus> boolean, number, string, object
192 2015-02-17 10:43:13 <wumpus> if your specific binding imposes more typing, that's specific to your binding, not the JSON RPC itself
193 2015-02-17 10:44:05 <dario_> wumpus: yes, but the fact that JSON forces squashing the types into a narrow subset, does not mean the original types are not there!
194 2015-02-17 10:45:00 <wumpus> not sure if that is new in 0.10, but right now one of these four types is specified for every value, e.g. for getblockhash:  1. index         (numeric, required) The block index
195 2015-02-17 10:45:03 <dario_> Writing these bindings is far more complex and error prone because it requires looking through the C++ source to figure out what the actual types are...
196 2015-02-17 10:46:00 <dario_> I think it help all of us using languages with richer type systems (OCaml, Haskell, Rust, etc) if the API reference were to define and list the types used by each API call
197 2015-02-17 10:46:10 <wumpus> well, go ahead.
198 2015-02-17 10:46:32 <dario_> I've done this already to a certain extent:
199 2015-02-17 10:46:34 <gmaxwell> Uh. it may be unwise to go splunking in code to infer anything about the RPC.
200 2015-02-17 10:46:58 <wumpus> TBH I don't use bindings myself, I just build the JSON and send it, also works for e.g. JSONRPC batching, AFAIK none of the bindings support that
201 2015-02-17 10:47:00 <dario_> http://ocaml-bitcoin.forge.ocamlcore.org/apidoc/Bitcoin.html
202 2015-02-17 10:47:12 <gmaxwell> Because none of us expected or intended that, and wouldn't generally consider internal implementation details a part of the interface.
203 2015-02-17 10:49:13 <dario_> gmaxwell: but I'm not talking about the internal details.  I only care about the external type. For instance: the private and public portion of a ECDSA pair are both represented as strings, yet you cannot say that they both have the same type!
204 2015-02-17 10:49:15 <wumpus> wrapping the RPC calls in 'function' like invocations looks nice, but apart from that just adds extra work so you have to update your binding e.g. every time a RPC is added or there is an extra parameter
205 2015-02-17 10:49:31 <wumpus> I've personally given up on that, but your milage may vary :)
206 2015-02-17 10:50:05 <dario_> wumpus: Yes, but if proper type information is available (which these bindings try to do), then the API is much safer to use
207 2015-02-17 10:50:19 <wumpus> well there is no type information in JSON RPC
208 2015-02-17 10:51:00 <wumpus> (beyond the four very rudimentary, and almost impossible to confuse, ones I've mentioned above)
209 2015-02-17 10:51:26 <dario_> wumpus: as I said, though JSON may squash the types into a narrow subset, this does not mean the types are not there...
210 2015-02-17 10:51:33 <wumpus> it's not JSON that squashes it
211 2015-02-17 10:51:37 <wumpus> that's just how our API is
212 2015-02-17 10:52:22 <hearn> dario_: basically anything except javascript has stricter types than json :)
213 2015-02-17 10:52:33 <gmaxwell> dario_: thanks, thats a great example. We would not think twice about adding another kind of key which was a different 'type' but also seralized out as a hex or base58 string.
214 2015-02-17 10:52:34 <dario_> wumpus: Yes, C++ is also quite bad in that regard, but that does not mean the types are not there, even if the Bitcoin-core stringly-types them
215 2015-02-17 10:52:40 <wumpus> sure you could think of some system that defines a more elaborate type system on top of JSON RPC, but it's not really that interesting
216 2015-02-17 10:53:01 <gmaxwell> dario_: so if you write a bunch of software assuming that anything in or out of those two RPC will be a particular thing, it may well be broken by future changes.
217 2015-02-17 10:53:29 <wumpus> and it'd be more than just documentation; you'd have to enforce it too
218 2015-02-17 10:53:32 <gmaxwell> So I would say the interface there really is a string.
219 2015-02-17 10:53:32 <hearn> dario_: the best way is to layer the types on top of the strings in your bindings, for sure. the main reason being that type hierarchies are not standardised across platforms, so, what works best for o'caml may be different to what works for other languages. for instance in bitcoinj the ECKey type is used to represent both private keys and public-only keys
220 2015-02-17 10:53:55 <hearn> (to my regret.... but fixing it is a task for another day)
221 2015-02-17 10:54:26 <gmaxwell> (maybe you can say one is string of pubkey, one is string of privkey, but that generalization may not be so useful)
222 2015-02-17 10:54:58 <wumpus> +base58 somewhere in there
223 2015-02-17 10:55:22 <hearn> dario_: if you want to make a better RPC interface than the JSON-RPC one though, that'd be interesting :) problem is most RPC systems that are language neutral have quite basic type systems.
224 2015-02-17 10:55:51 <dario_> hearn: I have no problem with serialization to JSON...
225 2015-02-17 10:55:56 <wumpus> you can't quite ignore the required encoding, at least when documenting the interface instead of a specific language binding
226 2015-02-17 10:58:00 <dario_> Guys, should I write a message to the bitcoin-dev mailing list detailing my concerns?  (I hope it's not off-topic for that list)
227 2015-02-17 10:58:20 <wumpus> hearn: right, unless you have, say, protobuf, in which you can define types
228 2015-02-17 10:58:42 <hearn> protobuf doesn't let you define types beyond new structs, unfortunately :( you cannot specialise strings or ints, for example. ah well. it's still better than json :)
229 2015-02-17 10:58:57 <hearn> dario_: i would consider it on-topic, at least
230 2015-02-17 10:59:13 <dario_> hearn: okay, thanks!
231 2015-02-17 10:59:28 <wumpus> hearn: right
232 2015-02-17 10:59:48 <gmaxwell> JSON RPC is a more of a 'random problem cause' and a 'remote procedure call' sadly. :)
233 2015-02-17 11:00:22 <wumpus> hehe
234 2015-02-17 11:02:34 <hearn> hah
235 2015-02-17 11:02:50 <hearn> i remembering finding a bug in web search once that could have been caught by a better type system in protobuf
236 2015-02-17 11:03:40 <hearn> URLs entered into some local business app weren't having http:// prefixed to them properly if the user forgot to do it. urls were just being represented as strings throughout the entire indexing, query and rendering pipeline, so we ended up with <a href="foo.com"> which resulted in 404 hits to google.com/foo.com
237 2015-02-17 11:03:53 <hearn> good lesson in the value of types
238 2015-02-17 16:00:05 <brendafdez> 0.10 fails miserably to run on a 512 MB RAM + 512 MB swap Debian 7 box. It just keeps crashing :( . Very disappointing bc i wanted to run it on a cheap vps
239 2015-02-17 16:00:08 <unek> hello
240 2015-02-17 16:01:03 <brendafdez> hello, i wasn't being polite, soryr, just venting the frustration, now it's rescanning but i don't hold much hope that it will work
241 2015-02-17 16:01:15 <hearn> crashing how? OOM kill?
242 2015-02-17 16:03:44 <brendafdez> yes it gets killed. Up until it synchronized some 20 GB everything was fine. Than started crashing and i had to run a script to keep starting it again every time. It finished synchronizing that way, but it still has this issue, it won't run reliably for too long.
243 2015-02-17 16:05:43 <hearn> yeah half a gig is pushing it
244 2015-02-17 16:06:04 <hearn> you might be able to play with the dbcache parameters to shrink memory usage a bit
245 2015-02-17 16:06:09 <hearn> but it's gonna struggle with 512mb no matter what
246 2015-02-17 16:06:20 <hearn> i don't think much effort has gone into RAM optimisation (e.g. all headers are stored in RAM)
247 2015-02-17 16:07:05 <brendafdez> i see
248 2015-02-17 16:11:38 <hearn> jonasschnelli: logdb seems conceptually similar to leveldb, just with a single level
249 2015-02-17 16:12:33 <hearn> jonasschnelli: does it make sense to write another key->value store?
250 2015-02-17 17:15:43 <wumpus> brendafdez: the memory usage is configurable, try reducing -dbcache, the minimum is =4
251 2015-02-17 17:16:00 <brendafdez> thaks, i'll try
252 2015-02-17 17:16:52 <wumpus> default is 100, which in practice means ~400mb for the utxo database cache
253 2015-02-17 17:17:22 <wumpus> that's indeed too much for such a constrained system, ideally you'd get a bit more RAM
254 2015-02-17 17:18:07 <wumpus> but reducing the cache works too
255 2015-02-17 17:37:11 <unek> ERROR: Non-canonical signature: S value is unnecessarily high
256 2015-02-17 17:37:16 <unek> what does thaat even mean
257 2015-02-17 17:37:28 <unek> can't send my raw transaction
258 2015-02-17 17:40:57 <wumpus> it means that your transaction is not canonical DER
259 2015-02-17 17:41:04 <wumpus> +signature
260 2015-02-17 17:41:49 <unek> I used some outdated bitcore version to create it
261 2015-02-17 17:42:45 <unek> huh
262 2015-02-17 17:43:07 <unek> used signrawtransaction
263 2015-02-17 17:43:13 <unek> and then sent the output
264 2015-02-17 17:43:16 <unek> and it worked
265 2015-02-17 17:45:00 <wumpus> ok
266 2015-02-17 18:11:52 <unek> https://github.com/bitpay/bitcore/pull/727
267 2015-02-17 18:11:55 <unek> I guess that's appropiate
268 2015-02-17 20:40:17 <paveljanik> cfields, sure :-)
269 2015-02-17 21:32:39 <paveljanik> cfields, I'd just revert strnlen part of 62e5f8f96114a872354103ef566b5c74a16154d4
270 2015-02-17 21:34:46 <cfields> paveljanik: yes, that would be much simpler. I hacked around it as-is for the sake of deviating from the 0.10 tag as little as possible. Either way is fine by me, let's see what wumpus thinks
271 2015-02-17 21:37:51 <paveljanik> yes.
272 2015-02-17 21:38:08 <paveljanik> and thanks for the quick fix :-)
273 2015-02-17 21:38:39 <paveljanik> we should probably found some testers for the oldest supported system though.
274 2015-02-17 21:42:53 <cfields> yes, at least a quick sanity check
275 2015-02-17 21:44:23 <cfields> fwiw, this is why i was so opposed to bumping the build sdk at the last minute for 0.10. Things like this (exists at build-time but not run-time) are hard to see. It stinks that one snuck in anyway :(
276 2015-02-17 21:45:01 <cfields> and nice spot on the strnlen, btw. I had completely forgotten about it.
277 2015-02-17 22:26:33 <sipa> ;;blocks
278 2015-02-17 22:26:35 <gribble> 343947
279 2015-02-17 22:26:40 <sipa> ;;diff
280 2015-02-17 22:26:41 <gribble> 4.44554159623438E10
281 2015-02-17 22:27:32 <gribble> Error: Something in there wasn't a valid number.
282 2015-02-17 22:27:32 <sipa> ;;calc log(4.44554*10^10*2^32)/log(2)
283 2015-02-17 23:23:34 <mappum> what's the ETA for 0.10?
284 2015-02-17 23:29:59 <PRab> mappum: Its out...
285 2015-02-17 23:31:50 <mappum> PRab: lol, i guess i'm out of the loop
286 2015-02-17 23:32:07 <PRab> It just came out a day or 2 ago.
287 2015-02-17 23:32:23 <mappum> i knew it would be soon, didn't see it already happened
288 2015-02-17 23:40:27 <sipa> mappum: -1 day
289 2015-02-17 23:41:01 <mappum> is there a good place to subscribe to the releases? it would be nice to get an email about it