1 2015-04-17 02:47:18 <jeremyrubin> My C++ isn't particularly strong, does anyone have advisement on good resources to pick up more comfortability for the parts that are useful to Bitcoin?
2 2015-04-17 03:21:04 <ParadoxBTC> yacuna is strange
3 2015-04-17 03:21:18 <ParadoxBTC> how does one request the last traded price with their api?
4 2015-04-17 03:22:34 <kanzure> jeremyrubin: i recommend reading more bitcoin source code.
5 2015-04-17 03:22:51 <ParadoxBTC> i just want one line of the json output not this massive barf of json data it gives me
6 2015-04-17 03:23:06 <sipa> ParadoxBTC: off topic here, sorry
7 2015-04-17 03:23:29 <ParadoxBTC> sipa: but this is a dev chan?
8 2015-04-17 03:23:40 <sipa> developmemt of bitcoin
9 2015-04-17 03:23:57 <sipa> not development of applications using third party dervices
10 2015-04-17 03:23:59 <ParadoxBTC> erm ok so what would be the proper chan
11 2015-04-17 03:24:06 <sipa> no clue, sorry
12 2015-04-17 03:24:22 <ParadoxBTC> cuse im developing bitcoin softwere but i just need to pull proper price data lol
13 2015-04-17 03:40:27 <jeremyrubin> kanzure: yeah I figured that's probably best bet.
14 2015-04-17 03:58:15 <koobs> o/~
15 2015-04-17 10:01:00 <afk11> Hi all, presently tweaking my bindings to libsecp256k1 for PHP. So at the moment if the extension is loaded, it creates 3 contexts, one for each of the possible flag types, and end users of the library don't have to worry about initializing any of this
16 2015-04-17 10:01:46 <afk11> Just wondering, does this undermine the point of specifically passing a context, and is there anything else I should be aware of?
17 2015-04-17 10:02:56 <sipa> afk11: better have one context initialized for both
18 2015-04-17 10:04:40 <sipa> afk11: the reason for the contexts is that they take time to build, and have relatively large memory usage (> 1 megabyte, which is likely nothing in your use case)
19 2015-04-17 10:05:30 <sipa> and it makes the system thread-safe; for example what if you link in another library that also depends on libsecp256k1, but with different flags
20 2015-04-17 10:09:23 <afk11> sipa: cool - that works. not so concerned about the memory usage, it's too fast to for me to be worrying about that :)
21 2015-04-17 10:09:42 <afk11> I must run some benchmarks and see how long it takes to make them I guess.
22 2015-04-17 10:09:50 <sipa> a few milliseconds :)
23 2015-04-17 10:10:15 <sipa> which is fast for a program startp, but not something you want for every function call
24 2015-04-17 10:13:34 <afk11> ah perfect! I am seeing a reduction in time by simply using the contexts, which is nice :) I was actually doing secp256k1_start() on each function call, thought didn't impact things too badly (relative to what I'm used to, which is VERY slow)
25 2015-04-17 10:14:28 <sipa> i guess this means we need better documentation in the header file to explain why contexts exists and why you'd use them
26 2015-04-17 10:15:02 <afk11> I'm not very used to C, so figured it's better to ask in case I was simply missing the point :)
27 2015-04-17 10:17:09 <afk11> mm, yeah it's not entirely apparent to me. I guess it enables certain use cases. I'm trying to make it easy for end users, so don't mind creating a context for both sign/verify... but lower memory, or even verification only devices should certainly have control over what is precomputed.
28 2015-04-17 10:17:58 <sipa> we'll soon have a few more use cases for them
29 2015-04-17 10:18:26 <sipa> gmaxwell is working on extra blinding code (which gives extra belt-and-suspenders against sidechannel attacks during signing/key creation), where you need to store the state somewhere
30 2015-04-17 10:18:41 <sipa> and we may add an option to decide at runtime whether you want large or small precomputed tables
31 2015-04-17 10:19:22 <sipa> i personally worry very much about giving PHP programmers access to raw cryptographic libraries, but that's perhaps just me :)
32 2015-04-17 10:20:24 <afk11> well, there have been far to many people including unverified pure php code (normally there's only one library you'll see integrated in this way) into their bitcoin libraries, I am hoping this is a step above it
33 2015-04-17 10:20:34 <sipa> fair enough
34 2015-04-17 10:29:50 <afk11> sipa: I do appreciate the concern on that point though :). for me the use is an adapter for EC stuff, so I've been testing pure PHP/libsecp256k1 side by side, and borrowed some of your edge case tests too!
35 2015-04-17 10:30:24 <afk11> the blinding
36 2015-04-17 10:31:16 <afk11> the blinding steps are cool, been watching github the past while. *
37 2015-04-17 10:32:53 <sipa> yw
38 2015-04-17 10:35:39 <afk11> To the world at large: any thoughts/blockers on BIP67 https://github.com/bitcoin/bips/pull/146 ? finished up my job, so my attention is back to this :)
39 2015-04-17 10:42:42 <Luke-Jr> afk11: probably should specify BIP 11 specifically?
40 2015-04-17 10:42:56 <Luke-Jr> and squash
41 2015-04-17 10:49:11 <ThomasV> afk11: electrum sorts too :)
42 2015-04-17 10:49:49 <afk11> @Luke-Jr: ah yes, otherwise I have only mentioned the BIP describing P2SH. thanks!
43 2015-04-17 10:52:05 <afk11> @ThomasV: Awesome! I'll have a look at that today, I saw your announcement not too long ago about the latest release. I've been waiting for multisig in electrum for some time :)
44 2015-04-17 10:58:16 <gmaxwell> afk11: the php ecc code I've seen actually 'wrong' too, but in a way that fortunately doesn't cause incorrect behavior. But really, even having a well constructed high level interface doesn't make for safe cryptographic software. (maybe safer though)
45 2015-04-17 11:00:29 <gmaxwell> (some typo in code that decides to switch to doubling in the addition law, but fortunately the branch in question was redundant)
46 2015-04-17 11:14:18 <afk11> @gmaxwell: oh interesting, care to elaborate? let me check that out
47 2015-04-17 11:14:34 <afk11> I assume we're talking about https://github.com/mdanter/phpecc ?
48 2015-04-17 11:18:34 <afk11> branch == secret dependent branch? or a branch on github?
49 2015-04-17 11:18:37 <afk11> https://github.com/mdanter/phpecc/blob/master/src/Primitives/Point.php
50 2015-04-17 11:24:19 <gmaxwell> afk11: that one looks okayish; there is another version of this floating around where the test thats at 183 is errored. I mentioned in in wizards before, I'd have to search the logs.
51 2015-04-17 11:26:46 <afk11> there are quite a few ancient copies of that library floating around. before it was added to composer, people just copied the folder into their project and pushed the whole lot to github, so absolutely no one upgraded.
52 2015-04-17 11:27:27 <afk11> there were some changes to point logic here: https://github.com/mdanter/phpecc/issues/16
53 2015-04-17 11:30:22 <gmaxwell> Wasn't metioned there; I suspect it was fixed without ever realizing it was wrong when changing to support different number objects or something.
54 2015-04-17 11:31:35 <gmaxwell> "if (gmp_Utils::gmp_mod2(gmp_cmp($p1->x, $p2->x), $p1->curve->getPrime()) == 0) {"
55 2015-04-17 11:38:26 <afk11> oh yes. I remember that one.. gmp_cmp returns an unspecified positive or negative number.. so if that number was +/-p, indicating they weren't equal.. it could have ended up entering that if block regardless.
56 2015-04-17 13:17:26 <priidu> is there a way to see the "subVer" value for my own node?
57 2015-04-17 13:24:25 <priidu> seems like the closest thing is to diasect a HTTP response from the node and read the "Server" header
58 2015-04-17 13:24:55 <priidu> which gives something like "bitcoin-json-rpc/v0.10.0"
59 2015-04-17 13:54:22 <wumpus> I don't think so
60 2015-04-17 13:58:17 <wumpus> (you could connect to the P2P port and send a version message to find out, but I guess that'd be considered cheating?)
61 2015-04-17 13:59:21 <sipa> this sounds like a good candidate for a 'getversioninfo' RPC
62 2015-04-17 14:02:13 <wumpus> or format it yourself based on the version returned in getinfo, it's always /Satoshi:%d.%d.%d[.%d]/
63 2015-04-17 14:02:41 <sdaftuar> sipa: i wanted to ask you about alternatives to iterating mapBlockIndex in the autoprune pull
64 2015-04-17 14:05:11 <sdaftuar> if i'm understanding your suggestion correctly, of checking whether a file is pruned whenever we try to access the data: do you think it'd make sense to just broadly change the code so we no longer are checking nStatus & HAVE_DATA everywhere, and replace it with an appropriate check for pruning?
65 2015-04-17 14:05:18 <sdaftuar> or were you suggesting something more targeted than that?
66 2015-04-17 14:07:48 <Diablo-D3> http://pastebin.com/AGmYdaqv
67 2015-04-17 14:07:49 <Diablo-D3> gmaxwell: ^
68 2015-04-17 14:10:41 <sipa> sdaftuar: that's pretty much it, yes
69 2015-04-17 14:10:50 <sipa> sdaftuar: no need to do it in the same PR
70 2015-04-17 14:10:58 <sipa> i'd like to see this merged
71 2015-04-17 14:11:12 <sdaftuar> cool, that's also how i feel :)
72 2015-04-17 14:12:12 <sdaftuar> i'll take a stab at the refactor of HAVE_DATA, and perhaps we can compare it to the approach morcos tried with the reverse lookup table and decide which looks better
73 2015-04-17 14:12:18 <sdaftuar> either way in a separate pull
74 2015-04-17 14:12:32 <sipa> 10 MB is a lot :)
75 2015-04-17 14:12:45 <sdaftuar> ah ok, was going to ask you about your thoughts on that too
76 2015-04-17 14:13:09 <sdaftuar> perhaps there's a middle ground approach that woudl take less memory
77 2015-04-17 14:13:12 <sipa> thanks for having a stab
78 2015-04-17 14:13:26 <sipa> having/taking/...
79 2015-04-17 14:13:57 <sdaftuar> sure, well we'll see what i come up with... :)
80 2015-04-17 15:26:24 <Sword_Smith> Concieggs
81 2015-04-17 15:45:21 <wwwBUKOLAYcom> ACTION :(
82 2015-04-17 16:15:22 <wwwBUKOLAYcom> ACTION
83 2015-04-17 16:22:40 <wwwBUKOLAYcom> ACTION
84 2015-04-17 17:06:08 <esso> Where can I find the Bitcoin dev mailing list?
85 2015-04-17 17:22:56 <StephenM347> esso: https://sourceforge.net/p/bitcoin/mailman/bitcoin-development/
86 2015-04-17 18:06:33 <iiLezso> hola
87 2015-04-17 18:08:46 <iiLezso> SDC
88 2015-04-17 18:09:00 <iiLezso> Could I make something for bitcoin using python
89 2015-04-17 18:10:16 <iiLezso> Is anyone here a good dev?
90 2015-04-17 18:10:17 <iiLezso> I need advice
91 2015-04-17 18:37:26 <jonasschnelli> i'm not familiar with crypto/ecdsa: do you need a PRNG when deriving a Bip32 key? And do you need a PRNG when signing?
92 2015-04-17 18:38:31 <helo> you need a prng to sign
93 2015-04-17 18:38:44 <helo> you don't need a prng to derive a bip32 key from the secret
94 2015-04-17 18:39:04 <aakselrod> i think you only need a PRNG when creating a seed... RFC 6979 lets you sign without one
95 2015-04-17 18:39:47 <helo> oh, i wasn't aware of that
96 2015-04-17 18:39:53 <aakselrod> https://tools.ietf.org/html/rfc6979
97 2015-04-17 18:40:04 <gmaxwell> DSA of any kind requires a CSPRNG (or true randomness source) to sign; it's essential that it provides output which an attacker cannot preict. RFC6979 is a specification for a CSPRNG.
98 2015-04-17 18:40:18 <aakselrod> what gmaxwell said :>
99 2015-04-17 18:40:27 <gmaxwell> (I really slow one, sadly, but who cares much about signing speed normally?)
100 2015-04-17 18:40:56 <jonasschnelli> Thanks!
101 2015-04-17 18:41:03 <gmaxwell> jonasschnelli: if you're asking about Bitcoin Core. We use 6979.
102 2015-04-17 18:41:43 <gmaxwell> The initial bip32 seeds needs strong randomness; none after that.
103 2015-04-17 18:42:45 <gmaxwell> jonasschnelli: if you're working on crypto wallet stuff... please feel free to ask _lots_ of questions here. If you just google around or look at other wallets you'll likely get a lot of bad info. :)
104 2015-04-17 18:45:38 <jonasschnelli> gmaxwell: thank you very much. Will do!
105 2015-04-17 19:20:16 <morcos> jonasschnelli: Regarding the prune rpc test, i think it might be the same problem
106 2015-04-17 19:20:35 <morcos> that assertion is raised when the height of the node isn't right within 5 minutes
107 2015-04-17 19:20:46 <morcos> it could be that for some reason the reorg's are happening much slower on your machine
108 2015-04-17 19:20:59 <morcos> do you know about how long it took to run the test until it failed
109 2015-04-17 19:21:36 <morcos> that was the very end of the test... in fact, if the nodes weren't cleaned up, i would guess that if you manually checked them they'd be synced now
110 2015-04-17 19:22:02 <morcos> for us the test usually takes about 25min on SSD or 40mins on magnetic