1 2014-09-01 01:53:53 <jgarzik> gmaxwell, Can you translate this? "This also RES after startup for me by 150MB."
2 2014-09-01 01:54:52 <gmaxwell> gah!
3 2014-09-01 01:55:01 <gmaxwell> it reduces process RES. I'll fix.
4 2014-09-01 01:56:29 <gmaxwell> most of our memory usage after startup right now is the coins cacheâ not even so much the cache itself, its use of data types and the allocator is somewhat pessimal and has something like 2x overhead.
5 2014-09-01 01:56:55 <gmaxwell> The change keeps some of the data out of the coins cache, so it's a modest reduction. But we really need to put that cache on a diet.
6 2014-09-01 02:01:04 <gmaxwell> That change goes 580->427, with that changed and cache cut way down (e.g. to 4mb) the process runs in under 256 MB ram for me (202MB, in fact).
7 2014-09-01 02:01:58 <gmaxwell> Is there a reasonably portable way to determine how much memoy the system has free+cached? â we could make the default dbcache size dynamic. (e.g. large on big memory hosts, small otherwise)
8 2014-09-01 02:03:08 <Luke-Jr> I notice valgrind provides a more realistic memory usage number than anything else I can see
9 2014-09-01 02:04:27 <gmaxwell> most of the heap profilers ignore a bunch of overhead, which seems to make them seriously understate the usage of the cache, thats the best I can figure out.
10 2014-09-01 02:04:59 <gmaxwell> to reduce further than the 202MB we need to reduce some of the thread stack sizes or the number of threads (or both).
11 2014-09-01 02:06:02 <gmaxwell> The blockindex also has a fair amount of memory in use, ... I thought it might be smaller if I changed it from a map to an ordered_map and wasted a bunch of time on that yesturdayâ (it just took a lot of typing because we're not using a @#$@ typedef) but sadly it didn't reduce the memory usage.
12 2014-09-01 02:06:41 <gmaxwell> I can't even tell if it made the blockindex load times faster because for some reason the numbers are wildly inconsistent, my system seems to randomly take either 8 or 18 seconds to read the block index.
13 2014-09-01 02:08:21 <gmaxwell> http://0bin.net/paste/XeqX+ayuAea-oVwt#VmZQNLsVyGATyBRthvnQMdb+apwiqp7eBz1mDGL3GLj
14 2014-09-01 02:09:10 <gmaxwell> (I was probably running the code in valgrind in the 77 second one)
15 2014-09-01 02:10:08 <gmaxwell> Anyone have a huge wallet that they can do some benchmarks on? I suspect we can cut the bdb cache size way down with ~no impact in performance.
16 2014-09-01 02:14:00 <gmaxwell> e.g. I am down to 188MB with -dbcache=4 -rpcthreads=1 -par=1 -dnsseed=0
17 2014-09-01 02:17:29 <gmaxwell> dumpaddr, addconn, dnsseed, and perhaps ThreadFlushWalletDB can probably be merged. ext-ip goes away with my discovery patches.
18 2014-09-01 02:18:08 <gmaxwell> hm. perhaps addconn and dnsseed shouldn't be merged, the annoying thing is that you don't want dns blocking to stop other activity.
19 2014-09-01 03:27:25 <justanot1eruser> Is python-bitcoinlib just an active branch of python-bitcoin?
20 2014-09-01 03:33:31 <earlz> Has anyone experienced an issue where the bitcoin RPC interface seems to hang? Like I make a request to it, but then it just sits there, I guess waiting for more content
21 2014-09-01 03:34:11 <earlz> Oddly enough it's only mono 3.4.0 that I can produce this issue with
22 2014-09-01 03:35:51 <justanot1eruser> earlz: can you make the same RPC without mono?
23 2014-09-01 03:37:21 <earlz> hooking wireshark up to it now to see what's up
24 2014-09-01 03:37:48 <earlz> just wondeirng if there is any failure case where it's expected that the RPC interface would just hang
25 2014-09-01 03:40:07 <justanot1eruser> earlz: Maybe getrawmempool back when the enjoysochi spam was around..
26 2014-09-01 03:40:25 <justanot1eruser> hang indefinately? Not that I know of
27 2014-09-01 03:40:48 <phantomcircuit> gmaxwell, dns can be made async
28 2014-09-01 03:42:27 <earlz> heh, appears to be a really stupid mono bug
29 2014-09-01 03:42:46 <earlz> instead of actual credentials, it sends " System.Net.NetworkCredential"
30 2014-09-01 03:57:04 <earlz> er, turns out it's just an error in me doing things stupidly. go figure lol
31 2014-09-01 04:06:23 <earlz> Is the RPC interface multithreaded? Like, will it be faster doing parallel requests?
32 2014-09-01 04:08:08 <Forex> :D
33 2014-09-01 04:08:08 <Forex> earlz: go to open bazaar irc
34 2014-09-01 04:09:00 <earlz> wat
35 2014-09-01 04:17:51 <Forex> #openbazaar go there :D
36 2014-09-01 04:17:54 <Forex> u might like it
37 2014-09-01 04:18:31 <Forex> new peer to peer distributed e commerce platform
38 2014-09-01 04:18:32 <gmaxwell> Forex: do not spam people in here with crap like that.
39 2014-09-01 04:19:01 <Forex> gmaxwell: interesting, I thought its very neat idea
40 2014-09-01 04:19:07 <gmaxwell> earlz: some rpcs can run concurrently, most require access to a global lock and block each other.
41 2014-09-01 04:19:09 <Forex> any obvious pitfalls you noticed?
42 2014-09-01 04:19:41 <Forex> gmaxwell: they might utilise your multy signature ideas :)
43 2014-09-01 04:19:48 <Forex> multi
44 2014-09-01 04:21:09 <Forex> gmaxwell: u are pretty bright person, care to point to obvious faults?
45 2014-09-01 04:21:18 <Forex> that can save alot of people time then :)
46 2014-09-01 04:21:35 <Forex> sorry
47 2014-09-01 04:21:36 <Forex> :)
48 2014-09-01 04:21:40 <Forex> I though I am in #bitcoin
49 2014-09-01 04:24:53 <earlz> gmaxwell: so it depends on the rpc call you're using?
50 2014-09-01 07:56:41 <wumpus> what's up with removing the network id from CChainParams? seems more trouble than it's worth
51 2014-09-01 08:01:18 <wumpus> I know I'm guilty of it too, but right now I just get dizzy from all the code movement commits
52 2014-09-01 08:16:27 <wumpus> cozz has done some great work on the wallet lately, if anyone still cares about Bitcoin Core's wallet do help teesting and reviewing of #4331 #4697 #4701 #4712 #4798 #4800 #4805
53 2014-09-01 08:44:08 <wumpus> version message: /Mothership:Aiur/: version 70001, blocks=318564, us=:8333, peer=3705
54 2014-09-01 08:44:19 <wumpus> this one is extremely agressively connecting to my node
55 2014-09-01 08:44:45 <wumpus> holds about 36 connection slots
56 2014-09-01 08:45:36 <gmaxwell> wumpus: all from one host?
57 2014-09-01 08:45:55 <wumpus> it looks like it has a few different hosts, although there are multiple connections from the same host too
58 2014-09-01 08:47:09 <wumpus> I'll make a list
59 2014-09-01 08:55:41 <wumpus> gmaxwell: https://gist.github.com/laanwj/2a89da909bf161c7e4c2
60 2014-09-01 08:59:17 <wumpus> all are from linode hostst - they claim NODE_NETWORK, but none of them has a sync height
61 2014-09-01 09:23:17 <ThomasV> gmaxwell: I have merged an implementation of ecies in electrum. it would be nice if you could have a look
62 2014-09-01 09:23:30 <ThomasV> https://github.com/spesmilo/electrum/commit/93f61f1717deb868b73a6cf2f600c7e2f77c4908
63 2014-09-01 09:26:53 <gmaxwell> It should probably not use only the x coordinate as the input to the KDF.
64 2014-09-01 09:27:53 <ThomasV> why?
65 2014-09-01 09:29:44 <gmaxwell> Because if you give me a message, I can change it but leave the resulting ephemeral key the same. I don't know that this breaks anything but it seems like a not-good property.
66 2014-09-01 09:30:31 <gmaxwell> (it also loses one bit of security, though that also doesn't matter)
67 2014-09-01 09:30:45 <gmaxwell> I really think this class of feature is ill advised.
68 2014-09-01 09:31:17 <ThomasV> I see
69 2014-09-01 09:31:23 <gmaxwell> this is much better though!
70 2014-09-01 09:33:59 <gmaxwell> ThomasV: why do you convert the data to hex before feeding it to the hash function?
71 2014-09-01 09:34:21 <ThomasV> I don't know
72 2014-09-01 09:34:31 <ThomasV> this does not seem necessary
73 2014-09-01 09:34:52 <gmaxwell> it makes it needlessly hard to implement in languages that aren't python, and wastes cpu time.
74 2014-09-01 09:35:23 <ThomasV> hm, wait.. where do you see that ?
75 2014-09-01 09:35:29 <gmaxwell> I'd recommend seralizing the resulting point like the ephemeral key is seralized and just giving that data to the hash function.
76 2014-09-01 09:35:42 <gmaxwell> + ecdh_key = ('%064x' % ecdh_key).decode('hex')
77 2014-09-01 09:36:12 <sipa> that converts to hex and back
78 2014-09-01 09:36:20 <sipa> i assume it's just for padding
79 2014-09-01 09:36:22 <phantomcircuit> sipa, shh this is funny
80 2014-09-01 09:36:25 <ThomasV> gmaxwell: decode does the opposite
81 2014-09-01 09:36:46 <sipa> odd way of padding, but functionally identical to what gmaxwell suggests
82 2014-09-01 09:36:54 <gmaxwell> I know, it seems weird, and it makes the behavior depend on the formating (maybe it does nothing surprising?.
83 2014-09-01 09:36:58 <gmaxwell> No it's not.
84 2014-09-01 09:37:04 <sipa> no
85 2014-09-01 09:37:18 <gmaxwell> sipa: what I suggest is seralizing it like the ephemerial key isâ which would not drop the sign like its currently doing.
86 2014-09-01 09:37:19 <sipa> it converts to hex, pads with 0s, and converts back to binary
87 2014-09-01 09:37:41 <gmaxwell> and wouldn't add 32 zero bytes for no obvious reason.
88 2014-09-01 09:37:42 <ThomasV> ok
89 2014-09-01 09:39:58 <ThomasV> what is the effect of dropping the sign, btw?
90 2014-09-01 09:40:00 <gmaxwell> ah the 64 in the format specifier is the number of hex digits, duh.
91 2014-09-01 09:40:25 <sipa> ... sign?
92 2014-09-01 09:40:40 <gmaxwell> the effect is that it reduces the key space by one bit, and it introduces a trivial malleability where I can modify the input message and you'll still get the same ephemeral key.
93 2014-09-01 09:40:51 <gmaxwell> sipa: the y coorid flag.
94 2014-09-01 09:40:55 <sipa> ah
95 2014-09-01 09:41:16 <sipa> right, sign of the point i guess
96 2014-09-01 09:41:23 <sipa> not sign of a field element
97 2014-09-01 09:42:22 <gmaxwell> I'd probably have to think for a bit to come up with a case contrived enough for the 02:40 < gmaxwell> the effect is that it reduces the key space by one bit, and it introduces a trivial malleability where I can modify the input message and you'll
98 2014-09-01 09:42:39 <gmaxwell> for the malleability to cause any harm, but it just seems unfortunate (and surprising)
99 2014-09-01 09:42:57 <ThomasV> heh :)
100 2014-09-01 09:43:38 <gmaxwell> in bitcoin we've learned unneeded malleability can have some pretty unwelcome consequences. :)
101 2014-09-01 09:45:07 <gmaxwell> hm. you're signaling a whole seperate 16 byte IV? hm.
102 2014-09-01 09:46:58 <ThomasV> there's another commit: https://github.com/spesmilo/electrum/commit/a3d02525e2a96f9c166421f71f96b9d6201f0d03
103 2014-09-01 09:47:20 <gmaxwell> hm. I don't see how the size is handled here.
104 2014-09-01 09:47:42 <gmaxwell> If this is AES-CBC the ciphertext must be a multiple of the AES blocksize.
105 2014-09-01 09:48:54 <phantomcircuit> ThomasV, relying on the format code behavior is probably not a good idea, use an array ( https://docs.python.org/2/library/array.html )
106 2014-09-01 09:49:23 <ThomasV> phantomcircuit: ok
107 2014-09-01 09:50:16 <gmaxwell> I don't see how this could possibly be doing what it says unless the 'aes' code that isn't shown here is doing some non-trivial stuff behind the scenes.
108 2014-09-01 09:53:53 <gmaxwell> this also appears to have a second random input, for the IV.
109 2014-09-01 09:55:40 <ThomasV> yes, in aes
110 2014-09-01 09:56:53 <gmaxwell> where do I find the code for this? The docs onlineâ if its the same functionâ appear to suggest that you're supposted to call something to set cbc mode?
111 2014-09-01 09:57:08 <ThomasV> moment..
112 2014-09-01 09:57:30 <gmaxwell> Really this should use the same KDF that sets the AES key and the hmac key to also derrive an IV (and avoid some other uncontrolled source of randomness)
113 2014-09-01 09:58:36 <gmaxwell> since thats under the hmac with the patch I don't see a useful attack off the bat, but it adds 16 bytes (*base64 encoding) to the message data.
114 2014-09-01 09:58:47 <gmaxwell> and a need for more random inputs.
115 2014-09-01 09:59:00 <ThomasV> http://slowaes.googlecode.com/svn/trunk/python/aes.py
116 2014-09-01 09:59:02 <ThomasV> here
117 2014-09-01 09:59:23 <ThomasV> see line 608, there's a comment about message length
118 2014-09-01 10:04:19 <gmaxwell> right, it's using PKCS7 padding.
119 2014-09-01 10:05:33 <gmaxwell> this is a pretty crappy implementation, it gives you no mechenism to control the other than having it call urandom itself on the encryption side.
120 2014-09-01 10:06:20 <ThomasV> but it could be reimplemented on my side
121 2014-09-01 10:07:39 <ThomasV> why do they say it's a bad idea to store the original length?
122 2014-09-01 10:07:52 <gmaxwell> because you get heartbleed attacks and the like.
123 2014-09-01 10:08:11 <gmaxwell> It's unnecessary, the length is unambigious on account of the padding design.
124 2014-09-01 10:10:04 <gmaxwell> right sure, the format however signals the IV, I think that should be dropped and replaced with deriving it using the KDF. The PKCS7 padding should be made explicit, e.g. just mention it where it says it uses AES CBC.
125 2014-09-01 10:10:15 <ThomasV> so you suggest to derive the iv from the key, to have only one source of randomness?
126 2014-09-01 10:11:57 <gmaxwell> I doâ the same way the cipher and hmac keys are derrived, and to avoid 16 bytes (*base64) of overhead.
127 2014-09-01 10:12:10 <ThomasV> I see
128 2014-09-01 10:13:04 <gmaxwell> I take it elsewhere you have protections against malicious data coming out of this? e.g. if you display the output it's escaped?
129 2014-09-01 10:13:42 <gmaxwell> Also, what happens if I give you a message who's valid decryption ends with invalid PKCS7 padding? e.g. ending with 0?
130 2014-09-01 10:14:06 <gmaxwell> looks like it raises an exception that isn't caught anywhere?
131 2014-09-01 10:14:46 <ThomasV> I did not try that, I will
132 2014-09-01 10:14:50 <ThomasV> I guess it does
133 2014-09-01 10:16:24 <gmaxwell> (this is why libraries hiding crypto code ... isn't always good! :) )
134 2014-09-01 10:17:19 <ThomasV> what libraries?
135 2014-09-01 10:17:41 <gmaxwell> well 'modules'. I just mean that it was not at all clear at the top that this was using PKCS7 padding, and that the padding decode could fail.
136 2014-09-01 10:17:57 <gmaxwell> I only noticed it because CBC by itself can't work on arbritary length messages.
137 2014-09-01 10:19:59 <gmaxwell> the strip function is also potentially too permissive. I can construct an invalid message this software will decode, but other correct software would reject.
138 2014-09-01 10:21:00 <gmaxwell> because it only checks the last byte and not the rest of the padding.
139 2014-09-01 10:21:25 <ThomasV> it's nice to have gmaxwell review crypto code :)
140 2014-09-01 10:23:03 <ThomasV> gmaxwell: as input to the kdf, should I use the full x and y, or just x and the sign of y?
141 2014-09-01 10:25:03 <gmaxwell> I'd recommend using the same encoding used for the ephemeral keyâ where there is a 2 or 3 indicating the sign of y. The reason for that is some crazy embedded version could save some calculations in determining the full value of y. There should be no cryptographic difference between the two choices.
142 2014-09-01 10:26:53 <ThomasV> I don't get that point (about the crazy embedded version saving calculations)
143 2014-09-01 10:27:29 <gmaxwell> WRT the IV size and the KDF, you might have noticed that the KDF outputs 512 bits, and you're currently using all 512. I recommend changing to AES128 from the AES 256 is uses now. This nicely gives you 128 bits of KDF output back, and AES256 has some certificational weaknesses which may make it weaker than AES128.
144 2014-09-01 10:27:59 <gmaxwell> (though the particular weakness known now shouldn't matter for how AES is used in this application, IIRC it's a related key attack)
145 2014-09-01 10:28:50 <gmaxwell> ThomasV: it's possible to compute Point*scalar and only get the X cooridnate (and the sign of y) with less computation than getting both the X and Y cooridnate completely.
146 2014-09-01 10:30:11 <ThomasV> I see
147 2014-09-01 10:31:36 <gmaxwell> There is no extra data in the y coorid over x+sign, in that the x plus the sign uniquely identify the y.
148 2014-09-01 10:35:42 <ThomasV> gmaxwell: ok, thank you for your feedback. I will get back to you if I have more questions
149 2014-09-01 10:36:51 <gmaxwell> okay, if you want me to talk to the person who submitted the patch as well let me know. Thanks for taking the time to answer questions for me too (e.g. I probably would have wasted a ton of time finding that AES code)
150 2014-09-01 10:38:38 <ThomasV> that's nice, thank you. I met this person irl
151 2014-09-01 11:10:16 <aphorise> Whats the there for some newly mined coins sometimes being less than 25+tx? rather they are 24.9x + tx that round to 25.x something? - just trying to find something in docs / materials that can help explain.
152 2014-09-01 11:10:52 <aphorise> the reason*
153 2014-09-01 11:11:21 <sipa> answer: stupid miners
154 2014-09-01 11:11:33 <aphorise> but how so?
155 2014-09-01 11:11:44 <sipa> the coinbase is allowed to generate up to 25 BTC
156 2014-09-01 11:11:52 <sipa> but generating less is not illegal
157 2014-09-01 11:12:21 <aphorise> so why is it stupid?
158 2014-09-01 11:12:34 <sipa> because they're earning less than they could
159 2014-09-01 11:12:40 <sipa> but that's their problem
160 2014-09-01 11:13:02 <sipa> i didn't know it happened, though
161 2014-09-01 11:13:31 <aphorise> how would you measure more? - cause if its still tx amount exceeding 25 than it roughly same subject to tx u get lucky with I guess.
162 2014-09-01 11:14:33 <aphorise> I just thought it was fixed to 50, 25, 12.5, 6.25 etc
163 2014-09-01 11:15:54 <gmaxwell> aphorise: can you show me what block you're talking about?
164 2014-09-01 11:16:18 <sipa> the coinbase transaction is allowed to take up to (50.00000000 BTC) / (2 ** (height / 210000)) + tx_fees
165 2014-09-01 11:16:23 <sipa> but less is also valid
166 2014-09-01 11:16:24 <gmaxwell> I'm not aware of anyone doing <25.
167 2014-09-01 11:16:48 <aphorise> https://blockchain.info/tx/0697b41a8856c143c0446a9d26a34de61f6d1ffeee7379862fcc57ae35dcd1fc for example
168 2014-09-01 11:17:43 <gmaxwell> aphorise: 24.90034045 + 0.12512733 > 25
169 2014-09-01 11:25:56 <wumpus> more people have noticed those aiur nodes https://bitcointalk.org/index.php?topic=765157
170 2014-09-01 12:58:52 <ThomasV> gmaxwell: https://github.com/spesmilo/electrum/commit/a97375dbb4a2fd29ce2dc003abf117fb77aa6005
171 2014-09-01 12:59:05 <ThomasV> and https://github.com/spesmilo/electrum/commit/eed37c41b51f99e1fa6e532a20fe879d6388729d
172 2014-09-01 13:03:57 <gmaxwell> awesome. Don't forget to update the comment description. Hm one other possible changeâ consider using HMAC SHA-512/256 instead of SHA-256? Right now an implementation of this must have both the sha256 and sha512 functions. Whereas SHA-512/256 requires only a different initial constant.
173 2014-09-01 13:05:06 <gmaxwell> (e.g. it's AES128-CBS with PKCS7 padding)
174 2014-09-01 13:05:15 <gmaxwell> This aes.strip_PKCS7_padding(decr)? is still the function I saw earlier?
175 2014-09-01 13:05:43 <gmaxwell> it's too permissive. E.g. it will successfully decode some invalid paddings. Probably the right thing to do is to be strict.
176 2014-09-01 13:07:10 <ThomasV> oh ok
177 2014-09-01 13:07:49 <gmaxwell> (all the padding digits should be the same value, that code from earlier checked only the last one)
178 2014-09-01 13:07:50 <ThomasV> (I was just emailing Lucas who wrote the previous verion)
179 2014-09-01 13:11:26 <hearn> gmaxwell: congrats on leaving mozilla!
180 2014-09-01 13:11:32 <hearn> gmaxwell: it's good to have you full time
181 2014-09-01 13:11:43 <hearn> any idea what you'll do with your newfound (?) time?
182 2014-09-01 13:12:33 <ThomasV> hearn: code review for bitcoin projects :)
183 2014-09-01 13:12:39 <sipa> i assume he'll just start having a few hours of sleep per night?
184 2014-09-01 13:15:34 <hearn> sipa: that sounds healthy :)
185 2014-09-01 13:42:48 <ThomasV> gmaxwell: I fixed the strip_PKCS7_padding function. I don't know about HMAC SHA-512/256
186 2014-09-01 14:04:56 <andytoshi> does it make any sense that i'm getting a factor of ~10 slowdown trying to generate sequential keys instead of random ones?
187 2014-09-01 14:05:12 <andytoshi> seems at best totally backward
188 2014-09-01 14:05:36 <sipa> that makes no sense
189 2014-09-01 14:06:19 <andytoshi> must be rust's benchmarking stuff ... right now `cargo bench` runs with no optimizations so i must be seeing an artifact of the preopt code
190 2014-09-01 14:06:32 <sipa> if anything, computing A+G (== (a+1)*G) should be ~100 times faster than r*G
191 2014-09-01 14:06:37 <andytoshi> yeah exactly
192 2014-09-01 15:05:47 <samson_> One of these : http://strongvpn.com/vpn_routers_new.shtml
193 2014-09-01 15:06:33 <samson_> I'm not sure if they offer static IP's though
194 2014-09-01 15:08:01 <samson_> damn wrong window - sorry guys
195 2014-09-01 15:12:16 <dionyziz> https://en.bitcoin.it/wiki/Script#Provably_Unspendable.2FPrunable_Outputs
196 2014-09-01 15:12:30 <dionyziz> I see here in the "Provably Unspendable/Prunable Outputs" section that it says:
197 2014-09-01 15:12:35 <dionyziz> "Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet."
198 2014-09-01 15:12:40 <dionyziz> Is this information accurate or outdated?
199 2014-09-01 15:17:21 <sipa> that's outdated
200 2014-09-01 15:17:38 <sipa> under restricted conditions, such transactions are relayed
201 2014-09-01 15:22:34 <dionyziz> ok I will update the wiki, thanks :)
202 2014-09-01 16:21:26 <Luke-Jr> ACTION grumbles "/Satoshi/addrindex:0.9.99/" unknown
203 2014-09-01 16:32:14 <andytoshi> does anyone have numbers for how fast addresses can be generated? with secp256k1-rust i can create sk+pk+hash160(pk) in 120μs
204 2014-09-01 16:33:11 <Luke-Jr> andytoshi: HD wallet addresses, pure random addresses, vanitygen-type addresses, or what? ;)
205 2014-09-01 16:33:50 <jrick> lol vanity addresses
206 2014-09-01 16:33:51 <sipa> meh, the relevant part is how fast you can peform the EC trapdoor function :)
207 2014-09-01 16:33:55 <andytoshi> oh, lol, HD ckd_pub addresses
208 2014-09-01 16:34:24 <sipa> andytoshi: starting from the parent pubkey or from the parent private key?
209 2014-09-01 16:34:30 <Luke-Jr> also, on a modern CPU or old one? high end or low end? GPU accel? :P
210 2014-09-01 16:34:43 <sipa> (the latter would need 2 EC multiplications)
211 2014-09-01 16:34:45 <andytoshi> sipa: parent pubkey
212 2014-09-01 16:35:11 <andytoshi> Luke-Jr: i7-4700MQ @ 2.40Ghz
213 2014-09-01 16:35:46 <sipa> iirc, libsecp256k1 needs like 30us, but that was before i implemented slicing of the precomputed tables
214 2014-09-01 16:36:27 <sipa> oh, wait, that's for pure random keys
215 2014-09-01 16:38:22 <andytoshi> pure secp256k1 (no ripemd160 or HD stuff): for sequential keys i am at 57μs (literally (sk, pk), (sk+1, pk*G), ...) ... for random keys looks like like 230μs
216 2014-09-01 16:38:39 <andytoshi> 276μs :/
217 2014-09-01 16:39:04 <sipa> are you using libsecp256k1?
218 2014-09-01 16:39:13 <andytoshi> yeah, through rust FFI
219 2014-09-01 16:39:25 <andytoshi> libsecp256k1.so is compiled right from your sources
220 2014-09-01 16:40:11 <sipa> using 64bit_asm / gmp?
221 2014-09-01 16:41:12 <andytoshi> how can i tell? ./configure tells me -lgmp is there but yasm is not
222 2014-09-01 16:41:19 <sipa> a
223 2014-09-01 16:41:20 <sipa> ah
224 2014-09-01 16:41:25 <sipa> well, install yasm :)
225 2014-09-01 16:41:29 <andytoshi> kk will do
226 2014-09-01 16:41:45 <sipa> at the end of configure it should tell you which field and which bignum implementation it is using
227 2014-09-01 16:41:49 <andytoshi> also btw a sizable chunk (~30% i think, hard to count up all the perf entries) of my time is in the fortuna RNG..
228 2014-09-01 16:42:08 <sipa> configure: Using bignum implementation: gmp
229 2014-09-01 16:42:08 <sipa> configure: Using field implementation: 64bit_asm
230 2014-09-01 16:42:29 <andytoshi> yup, got that now. did not have asm before
231 2014-09-01 16:42:42 <sipa> it may add 20% speed or so
232 2014-09-01 16:42:50 <sipa> or less
233 2014-09-01 16:42:53 <sipa> depends on the CPU type etc
234 2014-09-01 16:43:09 <sipa> i've mostly been concerned with verification speed rather than signing speed
235 2014-09-01 16:43:25 <sipa> i think the slicing a few months ago cut signing performance by 40% or so
236 2014-09-01 16:43:38 <sipa> well, signing/generation
237 2014-09-01 16:44:32 <andytoshi> cool, down to 250μs
238 2014-09-01 16:44:53 <sipa> andytoshi: btw, using private_tweak_add + generate will be much faster than doing the tweak on both pubkey and private after generation
239 2014-09-01 16:45:05 <andytoshi> i noticed that
240 2014-09-01 16:45:07 <andytoshi> why?
241 2014-09-01 16:45:21 <sipa> because private_tweak_add is just modulo order arithmetic
242 2014-09-01 16:45:35 <sipa> while pubkey_tweak_add is an EC addition
243 2014-09-01 16:45:50 <andytoshi> yeah, but generate is an EC mult, no?
244 2014-09-01 16:46:02 <andytoshi> which should be way costlier than the addition
245 2014-09-01 16:46:02 <sipa> sorry, pubkey_tweak_add is EC mult + EC add
246 2014-09-01 16:46:24 <andytoshi> oh, right .. but if i'm doing an EC mult by 1 that should be free?
247 2014-09-01 16:46:25 <sipa> first convert the tweak to a group element, then add it to the pubkey
248 2014-09-01 16:46:58 <sipa> it's designed to be near constant time
249 2014-09-01 16:47:17 <andytoshi> gotcha, thx
250 2014-09-01 16:47:21 <andytoshi> that was really mystifying me
251 2014-09-01 16:47:28 <andytoshi> but the numbers don't lie..
252 2014-09-01 16:48:31 <sipa> pubkey_tweak_add is actually doing the wrong protection
253 2014-09-01 16:48:44 <sipa> the multiplication with G is constant-time, but the addition isn't
254 2014-09-01 16:53:15 <jgarzik> The new way to do decoderawtransaction:
255 2014-09-01 16:53:17 <jgarzik> $ ~/repo/bitcoin/src/bitcoin-cli getrawtransaction $hash | ~/repo/bitcoin/src/bitcoin-tx -json -
256 2014-09-01 16:53:30 <jgarzik> so nice and unix-y
257 2014-09-01 16:54:15 <andytoshi> ooh
258 2014-09-01 17:10:41 <jgarzik> bitcoin-tx replaces: createrawtransaction, decoderawtransaction, and a few other "pure" RPC functions.
259 2014-09-01 17:38:31 <jgarzik> boy, hearn likes to scare people
260 2014-09-01 17:38:37 <jgarzik> "bitcoin is really fragile"
261 2014-09-01 17:42:41 <btcdrak> jgarzik: maybe he is still sore from the roasting he got >_>
262 2014-09-01 17:43:29 <jgarzik> I certainly agree that bitcoin has plenty of warts and areas that are DoS-able
263 2014-09-01 17:43:37 <jgarzik> but disagree with "bitcoin is fragile" message
264 2014-09-01 17:43:47 <jgarzik> that ignores the active response component
265 2014-09-01 17:44:59 <jgarzik> In response to a DDoS that stops transactions/blocks entirely, are stakeholders of bitcoin just going to give up, assume their bitcoins are now worthless, and move on to something else?
266 2014-09-01 17:46:04 <jgarzik> oh well. Shoulda done something about $this DoS avenue. Too late now. Might as well go back to tending chickens then selling eggs via Paypal. </alt universe>
267 2014-09-01 17:47:15 <jgarzik> -People- are the ultimately bitcoin backstop. People will band together and fix things.
268 2014-09-01 17:47:35 <jgarzik> *ultimate
269 2014-09-01 17:47:57 <jgarzik> We all sink or swim together.
270 2014-09-01 17:48:22 <sipa> ACTION hands jgarzik a 500kg physical bitcoin
271 2014-09-01 17:48:43 <jgarzik> ACTION grabs his scuba gear
272 2014-09-01 17:49:16 <sipa> jgarzik: hmm, my intended meaning was that v2 transaction would be treated identically to a v1 transaction
273 2014-09-01 17:49:38 <sipa> jgarzik: as in, you have "the v1 rules, the v2 rules, the v3 rules"; v2 didn't change anything about transactions, only about blocks
274 2014-09-01 17:49:50 <sipa> but if that wasn't clear, i'll send a PR to clarify
275 2014-09-01 17:55:00 <Luke-Jr> happy programmers' day ;)
276 2014-09-01 18:14:16 <petertodd> jgarzik: re: DoS attacks, Bitcoin has the potential for better defenses against them than basically any P2P network ever made, because we can make them expensive! tx fees being a perfect example. worst case for any non-51% league attacker is a few days downtime while people scramble to setup a Freenet-style darknet linking trusted peers together
277 2014-09-01 18:16:14 <petertodd> jgarzik: personally, I worry a fair bit about DoS attacks, but only because I'd rather not have even an hour of downtime, let alone a few days, and equally darknets are a pain in the ass. but it's not a "bitcoin is really fragile" level fundemental problem
278 2014-09-01 18:16:32 <boompah> Hello everyone
279 2014-09-01 18:16:47 <boompah> :)
280 2014-09-01 18:17:41 <jgarzik> petertodd, indeed!
281 2014-09-01 18:19:26 <petertodd> jgarzik: of course, I'm biased: stopping that tx extra data DoS attack in it's tracks is probably up there in my "proudest life moments" :P
282 2014-09-01 18:22:01 <petertodd> jgarzik: re: "people will band together" <- that bitcoin can be redefined is one of its strongest features - even a 51% attack would end up being stopped in practice as we'd just find some trusted third-parties to sign the blockchain... equally, that's probably one of the most fragile aspects of bitcoin in more sophisticated attack scenarios... but that's a #bitcoin(-wizards) discussion :)
283 2014-09-01 18:24:25 <uiop> if you just define "attacker" as having < 51%, 51% "attacks" become impossible. the victors just write the history books. :)
284 2014-09-01 18:24:35 <petertodd> uiop: lol, there is that!
285 2014-09-01 18:24:59 <boompah> Can someone please help me with connecting to this server
286 2014-09-01 18:25:04 <boompah> I'm having an issue doing it with my client
287 2014-09-01 18:25:13 <petertodd> uiop: from now on I'll say "the 49% losers can redefine what bitcoin is to them"
288 2014-09-01 18:26:18 <boompah> server: bear.freenode.net port: 6665(SSL clicked)
289 2014-09-01 18:26:26 <boompah> Isn't that all I need to be able to connect with a client?
290 2014-09-01 18:27:53 <uiop> petertodd: heh, "49% losers" is good
291 2014-09-01 18:31:07 <boompah> Does anyone here use a IRC client?
292 2014-09-01 18:32:41 <btcdrak> irccloud
293 2014-09-01 18:32:42 <RBecker> we all do :P
294 2014-09-01 18:32:48 <RBecker> boompah: ssl port is 7000
295 2014-09-01 18:32:50 <RBecker> not 6665\
296 2014-09-01 18:33:43 <boompah> Thank you RBecker
297 2014-09-01 18:33:44 <boompah> I figured haha
298 2014-09-01 18:33:47 <boompah> just getting myself setup here
299 2014-09-01 18:33:50 <RBecker> yw
300 2014-09-01 18:33:53 <boompah> Which client do you prefer?
301 2014-09-01 18:34:03 <RBecker> i use mIRC
302 2014-09-01 18:34:07 <RBecker> with a ZNC bouncer
303 2014-09-01 18:35:29 <boompah> aargh, it's still not connecting for some reason
304 2014-09-01 18:35:42 <petertodd> boompah: take it to #bitcoin or something, thanks
305 2014-09-01 18:36:08 <boompah> I tried another username
306 2014-09-01 18:36:10 <boompah> here's my settings:
307 2014-09-01 18:36:12 <boompah> http://imgur.com/dkYCuC2
308 2014-09-01 18:38:17 <jgarzik> ACTION arms the kicksaber
309 2014-09-01 18:38:18 <gotboompah> Okay great
310 2014-09-01 18:38:20 <gotboompah> I figured it out!
311 2014-09-01 18:39:07 <jgarzik> gotboompah, not here. #bitcoin-dev is for development discussion. #bitcoin is for general bitcoin discussion.
312 2014-09-01 18:39:51 <gotboompah> thanks jgarzik
313 2014-09-01 18:40:00 <gotboompah> hopin' to speak about dev here though
314 2014-09-01 18:56:05 <blast_> Well, discussion of the ongoing bitcoin development does take place here ;]
315 2014-09-01 18:56:16 <blast_> There is also #cyrpotodev for mroe general discussion
316 2014-09-01 18:57:06 <blast_> #cryptodev rather, for cool crypto/bitcoin related projects ;D
317 2014-09-01 18:58:19 <Luke-Jr> blast_: #cryptodev is run by trolls IIRC
318 2014-09-01 18:58:40 <blast_> :/ I DIDNT KNOW!!!! D;
319 2014-09-01 19:19:09 <edcba> damn #bitcoin is not joking, i understand why nobody is talking there
320 2014-09-01 19:47:14 <TheRelic> ello moto
321 2014-09-01 20:42:05 <netg_> ls bin/
322 2014-09-01 20:42:07 <netg_> cd bin
323 2014-09-01 20:58:14 <cfields> sipa: still around?
324 2014-09-01 20:58:51 <cfields> if so, how interested are you in a native secp256 bignum impl?
325 2014-09-01 20:59:32 <sipa> cfields: if that is competitive with gmp, absolutely
326 2014-09-01 20:59:45 <cfields> personally, i'd really like to have that available for the script lib, when that comes about, in order to drop the big dep there
327 2014-09-01 21:00:30 <cfields> sipa: heh ok.. how about if it were way more on the naive side? better than nothing, or added burden to carry?
328 2014-09-01 21:00:40 <sipa> if not... there are potential optimizations that may make the importance of bignum performance drop dramatically
329 2014-09-01 21:01:41 <sipa> so i guess if there is a functionally complete native bignum, i'd merge it, even if just as a reference implementation with pessimal performance
330 2014-09-01 21:02:07 <cfields> ok, i think i'm interested in taking that on
331 2014-09-01 21:02:10 <sipa> the only important part for performance is the modular inverse, which is pretty nontrivial to get fast
332 2014-09-01 21:02:53 <cfields> i spent a good amount of time looking into our build and what the complications will be when it comes to shipping shared libs
333 2014-09-01 21:03:01 <sipa> for reference: gmp's modular inverse is around 10us
334 2014-09-01 21:03:09 <sipa> openssl's is around 20 or 30us
335 2014-09-01 21:03:14 <Luke-Jr> what's wrong with gmp?
336 2014-09-01 21:03:21 <sipa> an entire verification is 80-100us
337 2014-09-01 21:03:23 <cfields> much of them stem from dealing with our dependencies. I think time would be better spent on dropping those dependencies rather than figuring out how to cope with them
338 2014-09-01 21:03:33 <cfields> sipa: ok, will have a look
339 2014-09-01 21:03:38 <sipa> so a naive implementation will likely very signiciantly hurt verification speed
340 2014-09-01 21:03:40 <Luke-Jr> trying to reinvent dependencies does not seem useful
341 2014-09-01 21:04:03 <cfields> isn't libsecp256k1 a reinvention?
342 2014-09-01 21:04:11 <Luke-Jr> cfields: it's a specialisation
343 2014-09-01 21:04:16 <cfields> exactly :)
344 2014-09-01 21:04:23 <Luke-Jr> and OpenSSL is a particularly problematic dependency
345 2014-09-01 21:04:24 <gmaxwell> Luke-Jr: GMP is a huge codebase, it's not necessarily well audited for our purposes (same story as openssl). It's also LGPL, which is more restrictively licensed than libsecp256k1
346 2014-09-01 21:04:40 <MingwBUGS> Hello all
347 2014-09-01 21:04:45 <sipa> there is some tiny gmp project, with naive but very tiny implementations of the same api
348 2014-09-01 21:04:56 <cfields> sipa: yes, i saw it
349 2014-09-01 21:05:01 <gmaxwell> wrt specializationâ in particular, nothing in GMP is constant time... which we'd want to move towards.
350 2014-09-01 21:05:02 <cfields> attached to haskell iirc?
351 2014-09-01 21:05:30 <sipa> which reminds me... get rid of the division requirement for bignum
352 2014-09-01 21:05:34 <gmaxwell> libsecp256k1 also uses very little of GMP.
353 2014-09-01 21:05:55 <MingwBUGS> Something here can help me with Mingw compilation ? everything is already setting up. But i'me getting just an error.. can't find lcrypto lssl and ldb_cxx ..
354 2014-09-01 21:06:03 <Luke-Jr> wouldn't the logical step be to modify libsecp256k1 to not use bignums at all? or is that impractical for some reason?
355 2014-09-01 21:06:18 <gmaxwell> sipa: did we ever decide if the inversion elimination in verification I suggested was safe?
356 2014-09-01 21:06:26 <sipa> gmaxwell: i can't remember
357 2014-09-01 21:06:37 <gmaxwell> Luke-Jr: it nearly doesn't.
358 2014-09-01 21:06:39 <Luke-Jr> MingwBUGS: on Linux?
359 2014-09-01 21:06:39 <sipa> Luke-Jr: well we need something to do modular inverses on 256-bit integers
360 2014-09-01 21:06:52 <gmaxwell> (which is why its so easy for it to switch between libcrypto and gmp)
361 2014-09-01 21:07:34 <cfields> sipa: iirc there's also been a proposed bignum and/or 256bit int for c++1y (can't remember which)
362 2014-09-01 21:07:43 <cfields> figured that might make for a useful reference as well
363 2014-09-01 21:07:50 <gmaxwell> unlikely.
364 2014-09-01 21:08:00 <sipa> i think it's unlikely to have modular inverses :)
365 2014-09-01 21:08:37 <sipa> gmaxwell: ack #57?
366 2014-09-01 21:09:21 <cfields> sipa: well, i'll see what i can come up with. i'm very green on these operations, so i think it'd be a good learning experience anyway
367 2014-09-01 21:09:47 <sipa> uint256 in bitcoin has most of them already :)
368 2014-09-01 21:09:52 <sipa> ... except the really interesting one
369 2014-09-01 21:10:30 <cfields> ok great, that answers another question i forgot to ask :)
370 2014-09-01 21:11:14 <sipa> oh, these bignums need 512-bit space + sign
371 2014-09-01 21:11:40 <MingwBUGS> Luke-Jr mingw
372 2014-09-01 21:11:58 <MingwBUGS> Luke-Jr does it's possible to compile under Linux for windows?
373 2014-09-01 21:12:13 <Luke-Jr> MingwBUGS: that's the way it's usually done
374 2014-09-01 21:12:16 <Luke-Jr> mingw runs on Linux
375 2014-09-01 21:12:19 <gmaxwell> sipa: IIRC we only need a mod inverse mod the orderâ you're already using one for the field that makes use of the speak strucure of the field prime, right?
376 2014-09-01 21:14:01 <MingwBUGS> Luke-Jr are you telling me that i can make the build for windows users on linux ?
377 2014-09-01 21:14:03 <MingwBUGS> o.O
378 2014-09-01 21:14:31 <gmaxwell> MingwBUGS: this is how all our binaries for windows are done (and the same is true for a lot of software).
379 2014-09-01 21:14:32 <sipa> MingwBUGS: even stronger: almost every bitcoin build is done on linux
380 2014-09-01 21:15:34 <cfields> MingwBUGS: make -C depends HOST=x86_64-w64-mingw32 && ./autogen.sh && ./configure --prefix=`pwd`/depends/x86_64-w64-mingw32 && make
381 2014-09-01 21:16:25 <MingwBUGS> cfields i'm making with .pro file..
382 2014-09-01 21:16:37 <MingwBUGS> cfields that doent work.
383 2014-09-01 21:16:38 <cfields> i doubt it :)
384 2014-09-01 21:16:59 <MingwBUGS> sipa , so how should I do on linux ?
385 2014-09-01 21:17:21 <MingwBUGS> Since i've got already the deps , i made -qt for linux users.
386 2014-09-01 21:17:32 <sipa> ./autogen.sh && ./configure && make
387 2014-09-01 21:17:36 <MingwBUGS> So should be able to make the windows -qt on the linux
388 2014-09-01 21:17:48 <Luke-Jr> ./configure --host=i686-pc-mingw32
389 2014-09-01 21:18:02 <MingwBUGS> I don't have autogen..
390 2014-09-01 21:18:08 <MingwBUGS> this coe got .pro file.
391 2014-09-01 21:18:12 <MingwBUGS> code*
392 2014-09-01 21:18:23 <cfields> MingwBUGS: are you building bitcoin or some alt?
393 2014-09-01 21:18:25 <Luke-Jr> then it isn't Bitcoin Core
394 2014-09-01 21:18:51 <MingwBUGS> Luke-Jr it isn't.
395 2014-09-01 21:19:10 <sipa> we got rid of the previous build system and don't maintain it anymore
396 2014-09-01 21:19:21 <sipa> we don't support other codebases
397 2014-09-01 21:19:28 <Luke-Jr> MingwBUGS: then it's off-topic, since I don't know any maintained Bitcoin Core forks
398 2014-09-01 21:19:46 <MingwBUGS> Luke-Jr can you talk at altcoin-dev then ?
399 2014-09-01 21:20:09 <sipa> you're welcome to ask there; i don't expect many people here to care
400 2014-09-01 21:20:22 <MingwBUGS> ok
401 2014-09-01 21:20:53 <MingwBUGS> I understand.. But I know that this must sth easy.. maybe a wrong path.. but i've checked everything. Im just expecting to get someone expert on this already.
402 2014-09-01 21:21:03 <MingwBUGS> Im quite new to windows.. i prefer linux.
403 2014-09-01 21:21:21 <sipa> sorry; can't help you here
404 2014-09-01 21:21:23 <MingwBUGS> but as I read everywhere, i cant build the qt for windws using linux.
405 2014-09-01 21:31:04 <andytoshi> how does bitcoind's addrindex handle address reuse, from a UI perspective?
406 2014-09-01 21:31:24 <Luke-Jr> andytoshi: it doesn't have an addrindexâ¦
407 2014-09-01 21:31:41 <andytoshi> Luke-Jr: oh, ok. you have one though right? how do you handle it?
408 2014-09-01 21:31:50 <Luke-Jr> andytoshi: sipa has one, without a UI
409 2014-09-01 21:31:59 <Luke-Jr> and apparently known bugs with unknown cause
410 2014-09-01 21:32:25 <Luke-Jr> I have an independent one.. but still no UI
411 2014-09-01 21:33:02 <andytoshi> ok, thx, i'll think about it
412 2014-09-01 21:33:02 <sipa> i discontinued the patch
413 2014-09-01 21:33:19 <sipa> someone else took it over, but i don't know the current state
414 2014-09-01 21:33:51 <sipa> when i wrote it, it simply maintained a set of tx references for every output script
415 2014-09-01 21:33:58 <joedoe-> MingwBUGS: find gitan specs on github. everything is there
416 2014-09-01 21:34:08 <andytoshi> gross, i guess that's what i'll have to do
417 2014-09-01 21:34:26 <sipa> why do you need an address index in the first place?
418 2014-09-01 21:34:28 <joedoe-> you dont have to use gitan, just use those scripts as instruction
419 2014-09-01 21:34:48 <sipa> it has its uses, but mostly for debugging
420 2014-09-01 21:35:11 <sipa> for anything else it's just the easy but badly scalable solution
421 2014-09-01 21:35:13 <andytoshi> sipa: i am playing around with having a (prefix-filtered by HMAC(master key, scriptpubkey) addrindex so that i can load wallets quickly
422 2014-09-01 21:35:20 <sipa> bah!
423 2014-09-01 21:35:21 <andytoshi> for wizards-wallet
424 2014-09-01 21:36:11 <andytoshi> if i can build the index fast (like in a couple seconds) on startup i'll be happy
425 2014-09-01 21:36:13 <sipa> (which is exactly why i didn't continue the patch - i consider writing a wallet on top of it abuse)
426 2014-09-01 21:36:34 <Luke-Jr> andytoshi: lol?
427 2014-09-01 21:36:57 <sipa> you can read through 20 GB in a few seconds?
428 2014-09-01 21:37:00 <Luke-Jr> andytoshi: no matter how you do it, the index is huge and slow to generate
429 2014-09-01 21:37:09 <andytoshi> sipa: just the utxoset, it's 2gb and it's in ram
430 2014-09-01 21:37:13 <sipa> oh
431 2014-09-01 21:37:15 <Luke-Jr> ah
432 2014-09-01 21:37:19 <Luke-Jr> big difference then :P
433 2014-09-01 21:37:19 <sipa> that's something else
434 2014-09-01 21:37:24 <andytoshi> ohhh, i see what you guys were afraid of
435 2014-09-01 21:37:26 <sipa> was never implement afaik
436 2014-09-01 21:37:36 <hearn> bitcoinj has one of those
437 2014-09-01 21:37:42 <hearn> or you can use it that way
438 2014-09-01 21:37:51 <hearn> someone contributed it a while ago. uses postgres.
439 2014-09-01 21:38:26 <sipa> i dislike having it in core, but just because of feature creep
440 2014-09-01 21:38:36 <sipa> no objection to having the functionality itself
441 2014-09-01 21:38:43 <petertodd> andytoshi: you may find my merklized binary radix tree implementation useful, though it's being actively worked on as we speak: https://github.com/petertodd/python-merbinertree
442 2014-09-01 21:39:25 <petertodd> andytoshi: certainly going to be slower than what you're using already, but you can easily turn it into a UTXO commitment generator
443 2014-09-01 21:39:41 <andytoshi> nice, i'll keep it in mind
444 2014-09-01 21:43:09 <sipa> gmaxwell: well, yes, a single-modulus modular inverse ladder is possible, but afaik far slower than extgcd based algorithms
445 2014-09-01 21:43:21 <sipa> ... it's nicely constant time, though
446 2014-09-01 21:46:15 <gmaxwell> sipa: too bad they didn't grind the parameters to find a curve where the order was also a nicely structured prime. :P
447 2014-09-01 21:46:49 <sipa> gmaxwell, cfields: for a naive native (ha!) implementation, an exponentiation ladder for the modular inverse is probably the easiest decent and obviously-correct solution
448 2014-09-01 21:48:58 <sipa> it won't be an easy one, though...
449 2014-09-01 21:51:13 <blast_> BitcoinOS
450 2014-09-01 21:53:34 <gmaxwell> sipa: why does field.h says secp256k1_fe_inv_all is "without constant-time guarantee"?
451 2014-09-01 21:54:33 <edcba> nobody guaranteed it maybe :p
452 2014-09-01 21:54:50 <sipa> gmaxwell: it does not, afaict?
453 2014-09-01 21:54:56 <edcba> "may contain bugs"
454 2014-09-01 21:54:58 <sipa> secp256k1_fe_inv_all_var says that
455 2014-09-01 21:56:37 <gmaxwell> oh I see.
456 2014-09-01 21:57:39 <gmaxwell> huh. is USE_FIELD_INV_NUM faster?
457 2014-09-01 21:57:47 <gmaxwell> I didn't think that it was using that.
458 2014-09-01 21:58:15 <sipa> for GMP, yes; for OpenSSL, no
459 2014-09-01 21:58:29 <sipa> GMP's modular inverse is crazy fast
460 2014-09-01 21:58:35 <gmaxwell> kinda hard to believe that it's faster for the generalized mersenne prime.
461 2014-09-01 21:58:43 <gmaxwell> (unless it detects it 0_o)
462 2014-09-01 22:00:09 <sipa> feel free to rebenchmark that
463 2014-09-01 22:00:40 <sipa> perhaps i didn't do that benchmark again after peter dettman improved the exponentiation ladder
464 2014-09-01 22:10:56 <sipa> gmaxwell: actually, i do think i benchmarked it again, and decided not to change the inv implementation used for gmp
465 2014-09-01 22:18:36 <gmaxwell> sipa: indeed, I just benchmarked. I boggle.
466 2014-09-01 22:18:43 <gmaxwell> it's slower.
467 2014-09-01 22:34:44 <sipa> gmaxwell: around 3% slower for validation as a whole...
468 2014-09-01 23:41:24 <grantenierman> which blockchain code is better block explorer or bitcoin abe
469 2014-09-01 23:41:39 <grantenierman> i have a sha256 coin like bitcoin
470 2014-09-01 23:42:25 <sipa> grantenierman: this is not #altcoin-dev
471 2014-09-01 23:42:42 <grantenierman> yeah but these explorers are bticoin base
472 2014-09-01 23:42:45 <grantenierman> bitcoin*
473 2014-09-01 23:44:19 <grantenierman> and there is no altcoin-dev
474 2014-09-01 23:44:33 <sipa> not my problem
475 2014-09-01 23:46:24 <grantenierman> you are so helpfull
476 2014-09-01 23:55:10 <Luke-Jr> sipa: it's ##altcoin-dev
477 2014-09-01 23:56:31 <sipa> Luke-Jr: i don't care