1 2014-12-08 02:36:10 <ericwooley> Can anyone tell me what the size property is, that is returned from getBlock, I am having a hard time finding it in any guide/api reference, other then the fact that it exists
2 2014-12-08 02:36:21 <ericwooley> is it the number of tx in the block?
3 2014-12-08 02:37:10 <ericwooley> *I'm pretty new to developing using bitcoin, sorry if it's a stupid question*
4 2014-12-08 03:52:55 <teward> e
5 2014-12-08 04:59:07 <rusty> test/test_bitcoin saying "replication requires locking support" on make check. Is this anything to do with me configuring with --with-incompatible-bdb ?
6 2014-12-08 05:00:00 <phantomcircuit> rusty, can you post the full output?
7 2014-12-08 05:01:46 <rusty> phantomcircuit: http://pastebin.com/9xuE8nmd
8 2014-12-08 05:01:56 <rusty> phantomcircuit: not very enlightening, at least for me.
9 2014-12-08 05:02:08 <phantomcircuit> (battery is about to die i might not respond)
10 2014-12-08 05:03:36 <rusty> phantomcircuit: guessing this is a libdb error message, actually.
11 2014-12-08 08:39:03 <wumpus> rusty: haven't seen that before; what version of bdb are you using?
12 2014-12-08 08:39:31 <wumpus> in any case if you don't need the wallet at all it is better to do --disable-wallet than --with-incompatible-bdb
13 2014-12-08 08:40:22 <wumpus> instead of a version problem it could also be that it is performing the test in a strange filesystem that doesn't support locking
14 2014-12-08 09:14:14 <rusty> wumpus: found it: was using the libdb 5.3 headers, and linking against libdb 4.8...
15 2014-12-08 09:15:16 <rusty> What's the preferred method for sending a couple of (related) code cleanup patches? Pull req. via github?
16 2014-12-08 09:15:51 <wumpus> yes pr it
17 2014-12-08 09:17:06 <wumpus> if you really prefer you can also send patches per mail but prs make sure that it doesn't get lost and review can take place in a single place
18 2014-12-08 09:25:05 <wumpus> it looks like qt has no way to say "don't use sslv3", all you can do is force it to use a certain protocol, say tlsv1
19 2014-12-08 09:25:37 <gmaxwell> I couldn't make sense of it. It seemed obnoxious.
20 2014-12-08 09:26:09 <gmaxwell> might just be possible to check after it connected but before making the request and terminate it if it's SSLv3.
21 2014-12-08 09:27:53 <wumpus> the idea would be to override NetworkAccessManager::createRequest and force the SSL protocol to QSsl::TlsV1
22 2014-12-08 09:28:13 <gmaxwell> thats kind of obnoxious.
23 2014-12-08 09:28:34 <wumpus> yes
24 2014-12-08 09:29:06 <gmaxwell> (I mean, you'd not be able to connect to a server which had prudently restricted itself to TLSv1.2, which right now you could reasonably do... and might want to do in the future if more issues are discovered.
25 2014-12-08 09:29:07 <wumpus> and non-future-proof
26 2014-12-08 09:29:10 <gmaxwell> )
27 2014-12-08 09:29:40 <wumpus> I suppose TLSv1.2 is still TLSv1
28 2014-12-08 09:30:32 <wumpus> from qt's point of view it's not more specific than the major version, it's either SSLv2, SSLv3 or TLSv1
29 2014-12-08 09:31:00 <wumpus> so I *think* forcing TLSv1 and connecting to a TLSv1.2-only server will work
30 2014-12-08 09:35:46 <wumpus> but that's kind of easy to test
31 2014-12-08 09:37:23 <wumpus> SSLProtocol -ALL +TLSv1.2 on the webserver, then server a payment request from it
32 2014-12-08 09:47:52 <rusty> wumpus: thanks..
33 2014-12-08 09:56:44 <wumpus> oh shit, for qt5 they did subdivide TLSv1.x into specific sub versions
34 2014-12-08 09:58:03 <wumpus> why didn't they just make it a bit field...
35 2014-12-08 09:58:27 <wumpus> but no, we have an enumeration value QtSSL::SecureProtocols that invokes some mystery meat
36 2014-12-08 09:59:08 <wumpus> yesterday's secure is not today's secure
37 2014-12-08 10:06:08 <wumpus> all the openssl handling is internal code, and there's no way to inject SSL_OP_NO_SSLv3 into it
38 2014-12-08 10:07:59 <wumpus> in any case the gitian builds are protected as their openssl is built with no sslv2 and sslv3, I'll just leave it at that
39 2014-12-08 10:09:08 <wumpus> going to file an issue with qt, but I suspect by the time it makes it into the default qt distributions, ssl will be a forgotten thing of the past
40 2014-12-08 10:17:24 <gmaxwell> wumpus: is there a way to check what it negoiated after its up?
41 2014-12-08 10:23:41 <wumpus> there is a feedback from openssl to qt yes
42 2014-12-08 10:27:35 <michagogo> How come Qt does the fetching?
43 2014-12-08 10:28:23 <wumpus> because we tell it to?
44 2014-12-08 10:30:07 <wumpus> in theory, that avoids a direct dependency from the GUI code on OpenSSL, as Qt could (in theory) use another SSL library
45 2014-12-08 10:30:45 <wumpus> (and in that case also avoid an indirect one)
46 2014-12-08 10:33:43 <wumpus> in practice the paymentserver code already does some direct calls into OpenSSL for x509 handling
47 2014-12-08 10:34:08 <michagogo> Ah, I see
48 2014-12-08 10:34:42 <wumpus> so it could in principle bypass Qt completely, and instead of have everything integrated into the event loop, do the openssl calls in a separate thread
49 2014-12-08 10:34:52 <michagogo> I would think that it would be easier to just pull it ourselves, but I see what you mean
50 2014-12-08 10:35:43 <wumpus> well, feel free to implement that if you think that's easier :)
51 2014-12-08 10:37:23 <michagogo> hehe
52 2014-12-08 10:38:15 <wumpus> we don't use openssl directly anywhere yet
53 2014-12-08 10:38:26 <wumpus> and using boost in qt code... nah, rather not
54 2014-12-08 10:43:04 <wumpus> gmaxwell: the problem with checking the cipher after the connection is made is that you'd somehow have to inject code between having made the SSL connection and the start of the HTTP processing
55 2014-12-08 10:43:46 <wumpus> I'm sure that's possible somehow, but it would require quite a lot of diving to find out
56 2014-12-08 10:45:42 <wumpus> in principle Qt just offers a simple 'give me this URI and get back to me when the request is finished or failed' API
57 2014-12-08 10:57:20 <wumpus> oh, qt5 grew a QNetworkReply::encrypted signal which is invoked when the connection is encrypted http://qt-project.org/doc/qt-5/qnetworkreply.html#encrypted
58 2014-12-08 11:00:29 <wumpus> it would be possible to check there what :sslConfiguration()->sessionCipher()->protocol() and see if it is in today's set of allowable protocols
59 2014-12-08 11:01:35 <wumpus> and if not, call ->abort()
60 2014-12-08 11:15:33 <michagogo> So for Qt4 you tell it that you want it to use TLSv1, and for Qt5 you can use this new piece of data to check?
61 2014-12-08 11:16:40 <wumpus> possible
62 2014-12-08 11:18:34 <wumpus> for now I'm going to implement this only for qt5
63 2014-12-08 11:25:05 <wumpus> how incredibly useful 2014-12-08 11:24:44 GUI: netRequestEncrypted : protocol is "" ( -1 )
64 2014-12-08 11:29:49 <wumpus> and sslConfiguration().protocol() is still "SecureProtocols".. eh yes
65 2014-12-08 11:33:07 <wumpus> maybe this is called before choosing a cipher
66 2014-12-08 11:38:03 <wumpus> does anyone know a SSLv3-only webserver to test with?
67 2014-12-08 11:39:18 <wumpus> ... I suppose getCiphers() on a SSLv3 connection should return only SSLv3 ciphers, and not TLS ones, but I need to test this
68 2014-12-08 11:41:18 <wumpus> hm, no, this won't work, as TLSv1.0/v1.1 didn't introduce any ciphers...
69 2014-12-08 11:41:49 <wumpus> so e.g. TLSv1.0 will also announce only SSLv3 ciphers
70 2014-12-08 11:44:03 <wumpus> giving up on this for now, this is useless
71 2014-12-08 11:48:33 <wumpus> filed a qt bug, let's see what they say https://bugreports.qt-project.org/browse/QTBUG-43168
72 2014-12-08 11:53:32 <sipa> wumpus: to find the bug in #5439, i'm really going to have to see the binary that Travis builds, i'm afraid
73 2014-12-08 11:54:26 <wumpus> you could add an upload step to your travis script, I suppose
74 2014-12-08 11:56:00 <michagogo> wumpus: done
75 2014-12-08 11:58:45 <wumpus> .travis.yml has a commented-out scp line, the only issue is access control
76 2014-12-08 12:00:52 <gr33n-ion> yo guys wassup
77 2014-12-08 12:36:57 <raji_> hello any one there?
78 2014-12-08 12:37:22 <raji_> I need a website to exchange btc to pm and vice versa
79 2014-12-08 12:39:49 <wumpus> #bitcoin please
80 2014-12-08 12:49:01 <wumpus> qt's http implementation is driving me crazy https://github.com/bitcoin/bitcoin/pull/5216/files#r21449258
81 2014-12-08 12:51:00 <sipa> travis is not noticing my new commit on #5439 :(
82 2014-12-08 12:55:16 <wumpus> huh, I don't see a travis overview at all anymore in that commit
83 2014-12-08 12:55:50 <sipa> maybe it's blacklisting that commit or so... too many failed attempts?
84 2014-12-08 12:56:21 <wumpus> let's see if I can manually relaunch it
85 2014-12-08 13:10:12 <BitLuck__> Use http://bitluck.info/ Protect your Anonymity!
86 2014-12-08 13:10:32 <sipa> not here
87 2014-12-08 14:21:59 <rubensayshi> does anyone know a decent (open source) implementation of estimating fees (before signing) ?
88 2014-12-08 14:24:10 <sipa> are you referring the the floating fees mechanism (which afaik is only implemented in bitcoin core), or just knowing in advance what the fees of a to-be-constructed transaction are?
89 2014-12-08 14:32:43 <rubensayshi> sipe, the 2nd, constructing a (p2sh) tx and I need to know what the size (and thus the resulting fee) would be once signed
90 2014-12-08 14:32:47 <rubensayshi> sipa*
91 2014-12-08 14:33:54 <sipa> rubensayshi: you can't know that without knowing the number of inputs you'll need to use
92 2014-12-08 14:34:05 <sipa> rubensayshi: if you need control over that, you need to use the raw transaction api
93 2014-12-08 14:34:53 <rubensayshi> I'm constructing the TX in my own project
94 2014-12-08 14:35:45 <rubensayshi> I guess I can got all the data to estimate it more or less
95 2014-12-08 14:36:44 <sipa> if you create the transaction yourself it is easy: size * fee_per_byte :)
96 2014-12-08 14:37:11 <Luke-Jr> (size should include the expected signature sizes)
97 2014-12-08 14:39:50 <sipa> rubensayshi: as to what a reasonable fee_per_byte is... that's a hard problem; you should definitely go above the minimum relay fee on the network if you care to see your transaction relayed, but that does not guarantee it will be mined in a reasonable time
98 2014-12-08 14:40:47 <Luke-Jr> unless the transaction is urgent, I'd personally just go for gradually re-issuing the transaction (be sure to respend the same UTXOs!) with a higher fee
99 2014-12-08 14:41:13 <rubensayshi> the system has 2 parts, where the 2nd part 'cosigns' the multisig TX
100 2014-12-08 14:41:24 <rubensayshi> but I want to calculate the size (and the fee) in first part
101 2014-12-08 14:41:25 <Luke-Jr> heh, I guess that makes it harder too >_<
102 2014-12-08 14:41:31 <rubensayshi> before the last signature
103 2014-12-08 14:41:58 <sipa> the actual ECDSA signatures are ~72 bytes
104 2014-12-08 14:42:08 <sipa> that should be enough to estimate the resulting size?
105 2014-12-08 14:43:44 <rubensayshi> hmm, yea I guess I could just get the size of the tx and add the 72 bytes for the remaining signature
106 2014-12-08 14:44:02 <rubensayshi> was overthinking it I guess by wanting to calculate the whole size seperate from the creating of the tx
107 2014-12-08 14:48:20 <rubensayshi> thanks btw ;-)
108 2014-12-08 14:50:08 <Soze49> Hi, what is the status of the 'header first' or any other parallel download method (acording to core development update #5, work was in progress for version .9) ?
109 2014-12-08 14:50:58 <wumpus> Soze49: it has been merged in master weeks ago
110 2014-12-08 14:52:29 <sipa> on october 17th, to be specific
111 2014-12-08 14:52:38 <sipa> so months is probably more accurate :)
112 2014-12-08 14:52:53 <Soze49> ok, I see, but is it the default method for bitcoin-qt ? because I notice huge amount of outgoing traffic in a full clone
113 2014-12-08 14:53:02 <sipa> which version are you running?
114 2014-12-08 14:53:15 <Soze49> I mean, the outgoing traffic is twice of the incoming traffic, in a full sync
115 2014-12-08 14:53:18 <sipa> it's not in any release yet
116 2014-12-08 14:53:24 <Soze49> ah, ok
117 2014-12-08 14:53:33 <sipa> so unless you compiled from master yourself, you're using the old code
118 2014-12-08 14:53:37 <wumpus> in *master*, not in any release
119 2014-12-08 14:53:52 <wumpus> you'll have to wait for the next major release if you use releases
120 2014-12-08 14:56:12 <Soze49> I see. I want to put out 3 full nodes, but the bandwidth is too high and limiting it without all the majority of clients doing parallel download will punish any first timer that gets into any of thouse nodes
121 2014-12-08 14:57:34 <sipa> you can copy the blocks and chainstate directory from nodes you trust
122 2014-12-08 14:57:42 <sipa> (like nodes you're running yourself)
123 2014-12-08 14:59:15 <wumpus> as long as you don't copy between ARM and x86 or vice-versa, that's fixed in master but not any release
124 2014-12-08 15:02:03 <Soze49> yes, but the problem is not for creating nodes, is for putting out there something that will not chase way newcomers. I mean, If I put out a low bandwith node, or if I limit the bandwith per connection and If the 'first timer' is not using 'headers only' he will have a very low sync time if he reaches one of my nodes.
125 2014-12-08 15:04:54 <sipa> yes
126 2014-12-08 15:06:54 <stonecoldpat> could you not just kick him from using your node? that way you won't be punishing him with a slow speed
127 2014-12-08 15:07:28 <stonecoldpat> e.g. only accept headers first, i don't think thats a bad approach
128 2014-12-08 15:07:52 <wumpus> I'm sure there are plenty of slow nodes though, so unless you limit the bandwidth to something *really* crappy I doubt you'll be doing a bad thing by adding more nodes
129 2014-12-08 15:08:08 <sipa> Soze49: at this point, if you want to run a node but don't want to provide upload to other nodes, run with -nolistne
130 2014-12-08 15:08:11 <sipa> -nolisten
131 2014-12-08 15:08:22 <sipa> the usefulness will be much lower, obviously
132 2014-12-08 15:08:52 <wumpus> see eg the scripts in contrib/qos
133 2014-12-08 15:12:22 <sipa> stonecoldpat: that's actually not a bad idea... a means to only provide upload to headersfirst clients (which can deal with being throttled)
134 2014-12-08 15:12:31 <sipa> stonecoldpat: though only after significant adoption, i guess
135 2014-12-08 15:18:06 <wumpus> but even for headers-first clients, if you throttle to a really silly slow speed it may be you're doing more hurt than good
136 2014-12-08 15:20:18 <wumpus> but indeed, you won't ever completely block their progress
137 2014-12-08 15:23:00 <wumpus> I like tor's throttling, you can tell it to use X bytes per period Y, say 4GB per day, and it will serve that amount at the full speed then hibernate until the next period
138 2014-12-08 15:24:06 <wumpus> (on top of that it can also do actual bandwidth throttling, but I like the approach, it slows nothing down)
139 2014-12-08 16:27:48 <gmaxwell> wumpus: probably the biggest source of complaints about bandwidth isn't monthly limits, but broken bufferbloat routers where high usage causes really annoying latency for the user. A windowed cap doesn't really address that.
140 2014-12-08 16:31:34 <wumpus> for VPSes you don't really get around having monthly limits though
141 2014-12-08 16:35:29 <wumpus> would be nice to say I donate X GB/month to serving historical blocks to the bitcoin networks on servers that don't normally reach their monthly cap, can't really do that right now
142 2014-12-08 16:37:14 <sipa> one way of doing that would be downgrading off NODE_NETWORK (and disconnecting block requesting peer) occasionally
143 2014-12-08 16:37:31 <sipa> but that can only fix monthly limits, not really peak usage
144 2014-12-08 16:37:41 <wumpus> just throttling is already possible at the OS level (well okay, so would just by killing bitcoind and restarting it in cron...)
145 2014-12-08 16:38:01 <gavinandresen> sipa gmaxwell wumpus: Iâm working on a âtest until failureâ branch to experiment with much larger block sizesâ want to run my plans by you to sanity check them.
146 2014-12-08 16:38:03 <wumpus> then again you may want to *keep up* with blocks just not serve them
147 2014-12-08 16:38:27 <wumpus> sipa: right, that sounds good
148 2014-12-08 16:39:35 <wumpus> gavinandresen: okay
149 2014-12-08 16:40:01 <gavinandresen> I want to propose that the block size increase to 20MB, so the goal is to test with real-world 20-MB+ blocks and see what happens
150 2014-12-08 16:40:40 <gavinandresen> So Iâm creating a tool to create a weird -regtest-mode chain that is based on real-world transactions in the actual blockchain
151 2014-12-08 16:42:01 <gavinandresen> After that is working, I plan on creating some re-org scenarios and just generally banging on it until I can convince yâall that everything actually works at big block sizes.
152 2014-12-08 16:42:58 <gavinandresen> Sound like a reasonable approach?
153 2014-12-08 16:43:07 <wumpus> a 20-MB-testnet would make sense
154 2014-12-08 16:43:40 <gavinandresen> wumpus: good idea, I should do that too
155 2014-12-08 16:44:50 <sipa> gavinandresen: sounds good; it'll take some time to convince me that we actually need such big blocks, but researching where our current bottlenecks before we can scale to that point is definitely needed first
156 2014-12-08 16:44:59 <wumpus> but rest sounds good, makes sense to start testing with larger sizes to know how far it can scale with the current code (and where the bottlenecks are)
157 2014-12-08 16:45:32 <wumpus> sipa: agreed, I don't think it's quite necessary yet either, but it doesn't hurt to know where we stand
158 2014-12-08 16:45:38 <sipa> exactly
159 2014-12-08 16:45:54 <sipa> it would be the #1 blocker in any case: not knowing whether we can deal with it
160 2014-12-08 16:46:10 <gmaxwell> gavinandresen: well what you'd proposed before was something like 20mb and sizes that increase after at some pace, and that would fail over at the first further increase because there are deep protocol assumptions that no message is greater than 32mbytes.
161 2014-12-08 16:47:26 <gavinandresen> gmaxwell: ⦠would fail if no changes are made to how blocks are communicated. That would obviously have to change, or the 32-mb message limit would be a de-facto soft limit.
162 2014-12-08 16:48:21 <gavinandresen> I really want to never hit the limit, just like we have never really hit the 1MB limit.
163 2014-12-08 16:48:37 <hearn> wumpus: i think the easiest way to implement that is to simply control the pruning depth - i think it was discussed a lot some time ago and there was agreement it was reasonable approach?
164 2014-12-08 16:48:49 <wumpus> it may be wise to keep the message limit at what it is, with regard to DoSes
165 2014-12-08 16:49:04 <sipa> so TIL wrt x86_64 assembly: there is a 'red zone' which is 128 bytes beyond the stack, for scratch space which may be overwritten by other functions. Turns out, if the compiler uses this space in a function with an inline asm block, you basically can't use the stack, as you don't know what the stack pointer points to
166 2014-12-08 16:49:05 <hearn> wumpus: i.e. nodes advertise that they have the last N blocks and if you want to cut down on bandwidth usage or disk space, you just reduce N. can't serve data you don't have. then nodes are smart enough to rebalance their downloading as they progress through the chain
167 2014-12-08 16:49:07 <wumpus> hearn: pruning depth?
168 2014-12-08 16:49:26 <sipa> yes, if we had a way to advertize that, sure
169 2014-12-08 16:49:38 <hearn> sipa: there is a gcc flag to control the red zone size, iirc
170 2014-12-08 16:49:42 <sipa> now the only choice is between full node and not, and that definitely has to be made more flexible
171 2014-12-08 16:49:51 <hearn> ACTION has vague memories of amd64 red zone causing some kind of bugs a long time ago in the kernel
172 2014-12-08 16:50:07 <wumpus> hearn: I've never regarded that as a bandwidth-saving feature, just a disk space saving one
173 2014-12-08 16:50:23 <hearn> wumpus: but it can also control bandwidth, right? imperfectly but might as well try and kill two birds with one stone.
174 2014-12-08 16:50:26 <sipa> hearn: there's another trivial workaround, allocating the temp variables you need outside the asm block, and pass their address as input to the asm template
175 2014-12-08 16:50:38 <sipa> hearn: which has the advantage that it can actually make use of the red zone optimization
176 2014-12-08 16:50:46 <hearn> sipa: sounds good to me
177 2014-12-08 16:51:24 <sipa> and right when i want to point you to the PR to do so, i see that travis failed on it...
178 2014-12-08 16:52:29 <wumpus> sounds dangerous to use that in consensus code
179 2014-12-08 16:52:57 <wumpus> maybe you're taking the asm optimization one step too far
180 2014-12-08 16:53:11 <sipa> well, i know of no other way of making it work
181 2014-12-08 16:53:15 <sipa> (with inline asm)
182 2014-12-08 16:53:46 <wumpus> I know, but at some point, a bit of extra gain in speed is just not worth the risk, and also the reviewing difficulty
183 2014-12-08 16:54:21 <wumpus> crypto code is already difficult to understand enough with plain C, let alone all kinds of platform specific magic
184 2014-12-08 16:55:20 <gmaxwell> wumpus: really the asm isn't substantially harder to review than the C code. Platform specific fun is a pain, but thats also why there are build time and runtime tests.
185 2014-12-08 16:55:49 <gmaxwell> We take a lot of risk from libraries, we can just pretend its not there.
186 2014-12-08 16:56:10 <wumpus> gmaxwell: platform specific does mean that it's replicated for different platforms, so has to be reviewed for every platform separately + risk of divergence between platforms
187 2014-12-08 16:56:48 <wumpus> yes, it's not better by using other people's libraries, that's not what I mean
188 2014-12-08 16:57:08 <gmaxwell> wumpus: And, alas. The same can happen with C code too.
189 2014-12-08 16:57:21 <wumpus> sure it can
190 2014-12-08 16:57:37 <gmaxwell> wumpus: plus you take other consistency risks, if the code isn't taking the available performance there is an incentive for people to use entirely different code.
191 2014-12-08 16:57:57 <wumpus> ok, never mind then
192 2014-12-08 16:58:33 <sipa> wumpus: i'm fine with not using the secp256k1 asm code in consensus code in bitcoin, until we think it's sufficiently stable and reviewed
193 2014-12-08 16:58:57 <wumpus> sipa: I think that'd be a good precaution
194 2014-12-08 16:59:17 <sipa> for now, it's only for one platform anyway
195 2014-12-08 16:59:43 <sipa> if there would be more asm-optimized platforms, we can make the decision (once it's used in consensus code) independently for each platform too
196 2014-12-08 16:59:51 <wumpus> sure, but it sets a precedence for other platforms
197 2014-12-08 17:00:15 <sipa> agree
198 2014-12-08 17:02:05 <wumpus> don't get me wrong I think it's very nice to get secp256k1 as fast as possible on every given platform, but I get a bit scared when we start talking about scary stack overwrite bugs and such :-)
199 2014-12-08 17:03:04 <sipa> if it's any consolation: any bug i've encountered so far since publishing that code, has been due to some incorrect usage of the inline asm construct
200 2014-12-08 17:03:21 <sipa> as in: they all failed immediately in some configuration
201 2014-12-08 17:03:34 <gmaxwell> wumpus: well it wasn't like that. That code makes no dynamic memory accesses.. everything is accessing fixed offsets. It's just an issue that resulted from getting rid of YASM and the enclosing enviroment for inline asm being somewhat different.
202 2014-12-08 17:04:17 <sipa> it seems there are indeed many things to take into account when using that construct (and indeed, very platform-specific ones), but it's not something that won't be caught by tests
203 2014-12-08 17:05:29 <wumpus> if it gets deterministically caught by tests that's good; it would be worse if for example an unpredictable interrupt at a certain point causes a value on the stack to be overwritten and possible a validation to fail/pass
204 2014-12-08 17:06:16 <sipa> funny that you bring that up; interrupt handlers are guaranteed to never touch the red zone
205 2014-12-08 17:09:56 <hearn> ye gods
206 2014-12-08 17:10:05 <sipa> ...?
207 2014-12-08 17:10:05 <wumpus> I'd hoped so, just don't accidentally use more than the 128 bytes <:
208 2014-12-08 17:10:11 <hearn> b.i managed to update their wallet so every single transaction leaked the private keys?!
209 2014-12-08 17:10:12 <sipa> wumpus: i can't
210 2014-12-08 17:10:20 <sipa> wumpus: it's GCC doing that, not the asm code
211 2014-12-08 17:10:46 <sipa> wumpus: i'll show you once travis passes :)
212 2014-12-08 17:11:45 <wumpus> sipa: ok that's reassuring
213 2014-12-08 17:11:50 <wumpus> hearn: whoa
214 2014-12-08 17:12:04 <wumpus> *transactions* leak the private key?
215 2014-12-08 17:12:22 <sipa> hearn: wth?
216 2014-12-08 17:12:51 <hearn> https://www.reddit.com/r/Bitcoin/comments/2onm5r/blockchaininfo_security_disclosure/
217 2014-12-08 17:13:15 <hearn> wumpus: it's a bit hard to tell what's going on but it appears b.i did something to their RNG such that every tx (?) reused an R value. or close to every, perhaps
218 2014-12-08 17:13:16 <hearn> not sure
219 2014-12-08 17:13:27 <hearn> but about $100k worth of coin got leaked within a few hours, it seems
220 2014-12-08 17:16:23 <wumpus> in that link they speak about generating addresses, so it sounds like they generated predictable private keys, but it makes sense a bad rng would affect nonces as well
221 2014-12-08 17:16:34 <paveljanik> here it is https://github.com/blockchain/My-Wallet/commit/98d5a7ca59ef04d06ac6aee468634b12975a0f5c
222 2014-12-08 17:18:12 <wumpus> // extract some randomness from Math.random() *cringe*
223 2014-12-08 17:19:05 <hearn> i wonder where the bug exactly lies? i'm guessing maybe new Int32Array(rng_psize/4) didn't evaluate to what was expected?
224 2014-12-08 17:19:34 <gmaxwell> wumpus: I don't know why after multiple hundreds of bitcoin loss they still refuse to stop using things like homebrew rngs and use the browsers strong cryptographic rng (and refuse to run if its not available).
225 2014-12-08 17:19:36 <hearn> although this whole construct looks scary. it's using the browser crypto RNG as input to a custom javascript "userland" rng
226 2014-12-08 17:19:53 <hearn> easy to mess that up. as the android team learned the hard way.
227 2014-12-08 17:20:11 <gmaxwell> hearn: yes, it doesn't even require the cryptographic rng be available.
228 2014-12-08 17:20:54 <gmaxwell> hearn: looked like it was wiping out its state and ending up only seeding it with the time. Though it's hard to tell, they force pushed that repository several times and the history there looks inconsistent with what it was last night.
229 2014-12-08 17:21:29 <paveljanik> looks like it is - _window.crypto.getRandomValues(word_array); for _window.msCrypto?
230 2014-12-08 17:21:45 <wumpus> gmaxwell: "mixing a value into the random pool" using just xor, what could possibly go wrong
231 2014-12-08 17:22:34 <wumpus> gmaxwell: right, they definitely should just use the system's rng and bail out if not available
232 2014-12-08 17:22:56 <wumpus> mixing an entropy pool seems like a definite 'don't try this at home'
233 2014-12-08 17:23:37 <gmaxwell> paveljanik: it uses it but not directly and not mandatorily. The prior huge losses from an rng was because they changed things around so that signing ran in webworkers where it wasn't available and if fell back to math.random (a 32 or 48 bit LCG seeded by time in most browsers)
234 2014-12-08 17:24:23 <gmaxwell> I like to analyize failures else where to see what lessons can be extracted to prevent future failures, but I didn't see anything here that hadn't already been cautioned against.
235 2014-12-08 17:25:28 <hearn> actually this was a good kick for me. it reminded me that the workaround i wrote for the android rng issue was never integrated into bitcoinj directly, it was added into wallet apps themselves.
236 2014-12-08 17:25:47 <hearn> if someone were to write a new android wallet that wasn't based on andreas' and they forgot about/didn't know about the android screwup, they might forget to use the workaround. it should be integrated.
237 2014-12-08 17:25:50 <hearn> i will do this soon
238 2014-12-08 17:26:23 <wumpus> that sounds like a good precaution
239 2014-12-08 17:27:04 <hearn> + if (rng_pool.filter(function(v) { return Math.abs(v) == 0; }).length > 12) {
240 2014-12-08 17:27:05 <hearn> + }
241 2014-12-08 17:27:05 <hearn> + throw 'RNG Pool contains a large number of zero elements'
242 2014-12-08 17:27:19 <hearn> interesting attempt to self check there. guess it didn't work
243 2014-12-08 17:33:27 <hearn> interestingly the js verifier detected a git/serving mismatch. i guess they were too panicked to check code in during the attempt to fix it. but they posted and said "it's all good guys" and everyone was relieved.
244 2014-12-08 17:43:08 <b-itcoinssg> did I miss the discussion? was in the reuse of the random number in generating private keys that was at fault with blockchain . info ?
245 2014-12-08 17:43:27 <b-itcoinssg> if so how did someone exploit it so quickly?
246 2014-12-08 17:44:39 <gmaxwell> people have automation to exploit this kind of bug, they've also made that sort of mistake before.
247 2014-12-08 17:44:47 <gmaxwell> so attackers were ready.
248 2014-12-08 17:45:05 <hearn> the attacker in this case is apparently a "good guy" attacker who wants to reunite people with their coins
249 2014-12-08 17:47:11 <gmaxwell> well one of probably multiple attackers.
250 2014-12-08 17:47:34 <b-itcoinssg> I see
251 2014-12-08 17:48:45 <b-itcoinssg> I also heard that the private keys were broadcasted? that did'nt make much sense to me. Wondering if the experts here could enlighten me.
252 2014-12-08 17:49:59 <gmaxwell> b-itcoinssg: They replaced their RNG with folgers crystals. As a result newly generated wallets had predictable private keys, and older wallets signed transactions with predictable DSA nonces, which -- with a bit of algebra-- allows recovering the private keys.
253 2014-12-08 17:52:30 <b-itcoinssg> gmaxwell: thanks
254 2014-12-08 18:13:02 <paveljanik> github down?
255 2014-12-08 18:14:01 <tdlfbx> looks like it to me.
256 2014-12-08 18:15:07 <b-itcoinssg> same here
257 2014-12-08 18:15:12 <paveljanik> too many people reading rng.js 8)
258 2014-12-08 18:15:20 <b-itcoinssg> lol
259 2014-12-08 18:16:59 <jgarzik> WFM
260 2014-12-08 18:17:23 <hearn> http://www.downforeveryoneorjustme.com/github.com
261 2014-12-08 18:18:24 <paveljanik> WFM now
262 2014-12-08 18:18:44 <b-itcoinssg> same here
263 2014-12-08 18:24:14 <phantomcircuit> probably a ddos
264 2014-12-08 18:24:34 <phantomcircuit> they recently published a bunch of stuff the were the russian gov asked them to censor things
265 2014-12-08 18:24:36 <phantomcircuit> https://status.github.com/
266 2014-12-08 18:30:22 <phantomcircuit> hearn, that's hilarious
267 2014-12-08 18:30:26 <phantomcircuit> if im reading this correctly
268 2014-12-08 18:30:41 <phantomcircuit> they changed the seeding function such that it only works correctly in IE 11
269 2014-12-08 18:30:44 <phantomcircuit> and nowhere else
270 2014-12-08 18:32:08 <hearn> phantomcircuit: i wasn't able to spot the exact problem but i didn't look very hard
271 2014-12-08 18:32:52 <phantomcircuit> hearn, if you look at the commit paveljanik linked to above you can see they commented out the window.crypto stuff and replaced it with window.msCrypto
272 2014-12-08 18:33:16 <phantomcircuit> and they played with the actual seeding function to make it a bunch more complicated for apparently no readon
273 2014-12-08 18:33:19 <phantomcircuit> reason*
274 2014-12-08 18:34:04 <phantomcircuit> so they removed secure entropy from everything except ie 11 and replaced it with Math.random and then did a bunch of other stuff which doesn't immediately appear broken but probably is
275 2014-12-08 18:34:49 <hearn> that's not what i see in the patch. var crypto became var mCrypto but contains the same value and is used in the same place
276 2014-12-08 18:35:37 <hearn> it looks like the other way around - previously IE users did *not* get the secure rng and afterwards it looks like they should have done
277 2014-12-08 18:37:03 <phantomcircuit> hearn, yeah you're right
278 2014-12-08 18:39:18 <hearn> like i said, whatever the issue is, it doesn't exactly leap out at me. the changes to the rng_seed_int function look suspicious but following the code through it seems equivalent
279 2014-12-08 18:40:30 <hearn> knowing the history of js rng failures i suspect some bizarre typing issue
280 2014-12-08 18:40:56 <hearn> the old code did this
281 2014-12-08 18:40:57 <hearn> + rng_seed_int(65536 * Math.random(), 16);
282 2014-12-08 18:41:03 <hearn> sorry the new code
283 2014-12-08 18:41:08 <hearn> the old code did
284 2014-12-08 18:41:08 <hearn> t = Math.floor(65536 * Math.random());
285 2014-12-08 18:41:17 <hearn> i suspect there is something weird going on with bit shifting a double vs an int
286 2014-12-08 18:41:40 <hearn> javascript for anything where correctness matters scares the crap out of me. heck, so do C and java.
287 2014-12-08 18:42:43 <jgarzik> the latter two are at least typed ;p
288 2014-12-08 18:43:02 <hearn> trying it in the chrome console though, that construct does seem to behave ok
289 2014-12-08 18:43:05 <hearn> so ..... not sure. am stumped.
290 2014-12-08 18:43:44 <paveljanik> the question is if it is the right commit...
291 2014-12-08 18:44:29 <hearn> could also be this one
292 2014-12-08 18:44:29 <hearn> https://github.com/blockchain/My-Wallet/commit/5dd04757d5012d545abd2309b4e970978322f4ac
293 2014-12-08 18:45:31 <phantomcircuit> hearn, yeah
294 2014-12-08 18:46:29 <phantomcircuit> hearn, oh and their change to rng_seed_int seems like it has a risk of never reseeding the start of the pool
295 2014-12-08 18:46:37 <phantomcircuit> but i'd have to look at it more to be sure
296 2014-12-08 18:48:51 <phantomcircuit> (there is a small bug there in that they never accept zero values to reseed the pool)
297 2014-12-08 18:48:56 <phantomcircuit> but i guess that's intentional
298 2014-12-08 18:50:12 <hearn> another possibility is that if (x >> i) does not behave the way i expect
299 2014-12-08 18:50:28 <hearn> it's casting a bit shifted integer to a boolean. if that evaluates to false unexpectedly the seeding just wouldn't happen
300 2014-12-08 18:51:19 <phantomcircuit> hearn, in chrome/ff that ends up being the same as Math.floor(65536 * Math.random())
301 2014-12-08 18:54:16 <phantomcircuit> hearn, oh i bet it's if (x >> i) does not imply if( (x >> i) & 255)
302 2014-12-08 18:59:38 <op_null> r
303 2014-12-08 19:01:18 <hearn> phantomcircuit: i think if any byte in the generated random 32 bit value ends up being zero somehow, the buffer gets unaligned
304 2014-12-08 19:01:25 <lechuga_> is libsecp256k1 doing determinstic DSA in any form
305 2014-12-08 19:02:08 <lechuga_> if it is i didnt notice it
306 2014-12-08 19:02:26 <lechuga_> just seea user supplied nonce
307 2014-12-08 19:03:08 <phantomcircuit> lechuga_, user of the library is responsible for selecting the nonce
308 2014-12-08 19:03:40 <phantomcircuit> it's relatively easy to use a deterministic nonce though simply H(m|k)
309 2014-12-08 19:03:54 <lechuga_> hmm
310 2014-12-08 19:04:01 <lechuga_> it doesnt look like core does tho
311 2014-12-08 19:04:02 <phantomcircuit> (or maybe safer...? HMAC(m, k))
312 2014-12-08 19:04:16 <phantomcircuit> lechuga_, core relies on having a good source of entropy
313 2014-12-08 19:04:22 <lechuga_> nm
314 2014-12-08 19:04:22 <lechuga_> oops
315 2014-12-08 19:04:36 <phantomcircuit> afaik there has never been an issue with entropy and bitcoin core
316 2014-12-08 19:04:38 <lechuga_> https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp#L79
317 2014-12-08 19:04:39 <lechuga_> it does
318 2014-12-08 19:04:48 <lechuga_> not really the point
319 2014-12-08 19:04:54 <op_null> phantomcircuit: follow RFC6979 properly though, then we can verify your software's sigs are good.
320 2014-12-08 19:04:58 <lechuga_> the mechanism should be robust enough to deal with crap entropy
321 2014-12-08 19:05:14 <op_null> the mechanism being ECDSA?
322 2014-12-08 19:05:29 <phantomcircuit> that seems relatively new
323 2014-12-08 19:05:36 <lechuga_> the signing code implementation
324 2014-12-08 19:05:53 <phantomcircuit> yeah sipa added that on nov 6th
325 2014-12-08 19:05:57 <phantomcircuit> https://github.com/bitcoin/bitcoin/commit/a53fd4148596f5814409e15647714bdd2a71468b
326 2014-12-08 19:06:09 <lechuga_> timely
327 2014-12-08 19:06:40 <phantomcircuit> but again if your rng is broken you're probably in trouble regardless since your private keys will have sucky entropy
328 2014-12-08 19:06:56 <phantomcircuit> deterministic nonces is certainly an improvement though
329 2014-12-08 19:07:07 <lechuga_> nod
330 2014-12-08 19:09:31 <hearn> phantomcircuit: the additional checks that were added at the bottom are interesting
331 2014-12-08 19:09:37 <hearn> the first one checks that the rng pool size is what is expected
332 2014-12-08 19:09:46 <hearn> the second one checks that there aren't continuous runs of zeros
333 2014-12-08 19:09:52 <hearn> presumably those checks were added for a reason.
334 2014-12-08 19:10:44 <phantomcircuit> 12 bytes of 0 in a row should be effectively impossible
335 2014-12-08 19:10:57 <phantomcircuit> so yeah that implies there is something horribly wrong somewhere
336 2014-12-08 19:11:55 <hearn> the first check is the most interesting
337 2014-12-08 19:13:17 <phantomcircuit> hearn, i wonder if they're just screwing up setting rng_psize
338 2014-12-08 19:13:54 <hearn> that is what i'm thinking too. i'm wondering if we're seeing the whole story here though. they were pushing code to production that wasn't in git
339 2014-12-08 19:14:03 <hearn> there are people on reddit saying their git/source verifier tool was flagging
340 2014-12-08 19:14:25 <phantomcircuit> it was
341 2014-12-08 19:14:39 <hearn> if rng_psize were to not be initialised somehow or end up as being undefined, then ....
342 2014-12-08 19:15:03 <hearn> >
343 2014-12-08 19:15:07 <hearn> < []
344 2014-12-08 19:15:47 <phantomcircuit> hearn, yeah
345 2014-12-08 19:15:51 <hearn> javascript does exactly what you would LEAST expect. apparently undefined++ == NaN and indexing an array with NaN just silently does nothing
346 2014-12-08 19:16:11 <phantomcircuit> that would explain the 0 runs check
347 2014-12-08 19:16:27 <hearn> and (rng_pool.length != rng_psize)
348 2014-12-08 19:16:42 <hearn> if the rng_pool[x] = y; line were to be silently ignored, the length would end up not matching the expected size
349 2014-12-08 19:17:19 <phantomcircuit> actually
350 2014-12-08 19:17:39 <phantomcircuit> is rng.js even being used??
351 2014-12-08 19:18:52 <hearn> someone who is watching the conversation just messaged me this link
352 2014-12-08 19:18:54 <hearn> https://github.com/blockchain/My-Wallet/commit/97e04aaacc9e15879666412053e277ee9a8647e8#diff-915df67ab1da101fb02555f80213831fL31
353 2014-12-08 19:19:07 <hearn> seems this was force pushed over?
354 2014-12-08 19:19:17 <hearn> and if so then we are correct. that commit deletes the initialisation of rng_pptr to zero
355 2014-12-08 19:19:47 <phantomcircuit> hearn, hahah
356 2014-12-08 19:19:55 <phantomcircuit> oh boy
357 2014-12-08 19:20:17 <hearn> jesus. what kind of language doesn't throw an exception when you index an int array with NaN?
358 2014-12-08 19:20:44 <hearn> this is the second time now javascripts useless type system has caused critical RNG failure :( counterparty shipped a buggy bitcoinjs that also had a broken RNG and it was also a type safety failure
359 2014-12-08 19:20:55 <phantomcircuit> hearn, it does throw an exception
360 2014-12-08 19:21:07 <hearn> it does?
361 2014-12-08 19:21:10 <phantomcircuit> yeah
362 2014-12-08 19:21:11 <hearn> it didn't when i tried it in the chrome console
363 2014-12-08 19:21:23 <phantomcircuit> it does in ff
364 2014-12-08 19:21:31 <phantomcircuit> but that doesn't matter
365 2014-12-08 19:21:38 <hearn> ah
366 2014-12-08 19:21:46 <phantomcircuit> because the exception doesn't prevent calling rng_get_byte
367 2014-12-08 19:24:12 <hearn> i'm having a hard time following the code
368 2014-12-08 19:24:26 <hearn> the exception gets thrown to top level console, swallowed by the browser and the app can continue obliviously?
369 2014-12-08 19:24:58 <phantomcircuit> the exact behaviour in an exception case is pretty hard to nail down in js especially when you consider that it very likely changes between browser versions
370 2014-12-08 19:25:07 <hearn> programmers so easily forget that program termination on crash is actually a deliberate design decision
371 2014-12-08 19:25:18 <hearn> ACTION glares at objective-c
372 2014-12-08 19:25:37 <phantomcircuit> also we're ot for -dev :P
373 2014-12-08 19:27:47 <hearn> i think studying how RNGs fail in practice is pretty on topic given their importance. but so far the only lesson i can see from this is "don't use a scripting language to implement software that must work"
374 2014-12-08 19:27:57 <hearn> which is hardly news, but people do it en-masse anyway.
375 2014-12-08 19:28:03 <hearn> makes me want to go refresh my haskell .... :)
376 2014-12-08 19:28:38 <hearn> also looking down the my wallet commit list ..... what is this?!
377 2014-12-08 19:28:39 <hearn> https://github.com/blockchain/My-Wallet/commit/98d48a0b5765c6cb42f10c3d07f8b33bef6c5404
378 2014-12-08 19:30:23 <paveljanik> it removes the fallback to http? ;-) Good, fixes MITM...
379 2014-12-08 19:30:40 <hearn> i'm surprised such a fallback ever existed
380 2014-12-08 19:30:43 <hearn> i wonder what it was trying to work around
381 2014-12-08 19:30:53 <hearn> i'm happy they have an EV cert now though
382 2014-12-08 19:31:01 <hearn> interesting that they chose to register in luxembourg
383 2014-12-08 19:32:56 <phantomcircuit> hearn, tax avoidance
384 2014-12-08 19:32:59 <phantomcircuit> for sur
385 2014-12-08 19:33:00 <phantomcircuit> e
386 2014-12-08 19:34:00 <hearn> the EU VAT rules are changing in january so won't help them much
387 2014-12-08 19:34:36 <phantomcircuit> except that virtually all of their revenue can legitimately be declared essentially anywhere
388 2014-12-08 19:34:50 <phantomcircuit> no country has a particularly strong tax nexus
389 2014-12-08 19:34:55 <hearn> right
390 2014-12-08 19:35:11 <hearn> but the new rule says you have to charge VAT at customer origin not company origin
391 2014-12-08 19:35:27 <hearn> PAIN! at least for people who would like to sell things directly and not via a middleman
392 2014-12-08 19:35:35 <phantomcircuit> hearn, how are they even going to know that?
393 2014-12-08 19:35:59 <hearn> you have to collect two pieces of non-conflicting "evidence" though apparently at the last minute they decided to let a customer self declaration be evidence
394 2014-12-08 19:36:00 <phantomcircuit> gotta love tax rules which completely ignore situations in which you dont have a clue were the customer is
395 2014-12-08 19:36:08 <hearn> it's only for some kinds of online/digital services
396 2014-12-08 19:36:24 <hearn> they even have a rule for what to do if the customer is travelling between countries at the time of purchase!
397 2014-12-08 19:36:43 <hearn> it's annoying that when bitcoin at least makes it theoretically possible to sell directly to the custome, stupid eu countries trying to avoid tax competition step in and impose rules so complicated you almost have to outsource billing
398 2014-12-08 19:37:38 <hearn> there's an open source PHP library that tries to calculate the right rate of tax, it's maintained by a professional payment services company
399 2014-12-08 19:37:40 <hearn> i forgot what it's called
400 2014-12-08 19:39:56 <cfields> wumpus: around?
401 2014-12-08 19:41:56 <cfields> or anyone who might be interested in filling me in on what i've missed wrt 0.10 in the last ~10 days? I'm back from vacation and back to work :)
402 2014-12-08 19:47:17 <jonasschnelli> cfields i think that ones for you https://github.com/bitcoin/bitcoin/pull/5395
403 2014-12-08 19:48:05 <jonasschnelli> and probably #5428
404 2014-12-08 19:48:36 <cfields> jonasschnelli: thanks. having a look now. I'm just starting through my backlog of PRs/tickets, just making sure I didn't miss anything high-level first
405 2014-12-08 19:51:01 <jonasschnelli> cfields no nothing high-level as far as i know...
406 2014-12-08 19:53:57 <cfields> cool, thanks
407 2014-12-08 21:21:52 <michagogo> Is there a document anywhere with the procedure Gavin uses to sign Windows installers?
408 2014-12-08 21:22:11 <michagogo> What command line, which tool (signtool or signcode or something else?), etc
409 2014-12-08 21:23:10 <michagogo> Ah, release-process.md specifies signtool
410 2014-12-08 21:24:44 <michagogo> But are the details/command line published anywhere?
411 2014-12-08 21:27:35 <phantomcircuit> michagogo, try getting for sigtool in the docs
412 2014-12-08 21:27:43 <phantomcircuit> er signtool
413 2014-12-08 21:29:13 <michagogo> doc/release-process.md: - Code-sign Windows -setup.exe (in a Windows virtual
414 2014-12-08 21:29:13 <michagogo> (END)
415 2014-12-08 21:29:13 <michagogo> $ git grep -i signtool
416 2014-12-08 21:29:27 <michagogo> (in the root)
417 2014-12-08 21:32:56 <hearn> michagogo: you can use a variety of tools. i use the gui from digicert
418 2014-12-08 21:32:59 <hearn> it works for any certificate
419 2014-12-08 21:33:06 <michagogo> hearn: yeah, I know
420 2014-12-08 21:33:14 <michagogo> MS alone has two tools
421 2014-12-08 21:33:21 <michagogo> so my question is, what do we do?
422 2014-12-08 21:33:26 <michagogo> (or, what does Gavin do?)
423 2014-12-08 21:39:34 <hearn> does it matter?
424 2014-12-08 21:41:08 <michagogo> hearn: I'm just curious
425 2014-12-08 21:41:19 <michagogo> And that kind of stuff is probably good to have public, anyway...
426 2014-12-08 21:55:01 <sipa> cfields: welcome back :)
427 2014-12-08 21:55:29 <cfields> thanks :)
428 2014-12-08 21:55:54 <cfields> sipa: thanks for ripping out all of secp256k1's deps and not letting me enjoy it :p
429 2014-12-08 21:56:15 <sipa> cfields: getting rid of both yasm and gmp was fun :p
430 2014-12-08 21:56:34 <cfields> hehe
431 2014-12-08 21:56:58 <cfields> sipa: speaking of which, probably a good time to add clang to secp256k1's travis build matrix
432 2014-12-08 21:57:04 <sipa> cfields: ack
433 2014-12-08 21:57:06 <cfields> unless i missed that
434 2014-12-08 21:57:11 <sipa> go ahead
435 2014-12-08 21:57:23 <cfields> ok, that one's trivial. doing now
436 2014-12-08 21:57:41 <sipa> i had to convert the intel assembly code to att syntax, because it seems clang on darwin doesn't support the intel syntax
437 2014-12-08 21:59:11 <cfields> i saw. annoying. also the other asm bug that bitcoin's osx clang build found
438 2014-12-08 21:59:45 <sipa> there's one more i'm working on now
439 2014-12-08 22:01:59 <cfields> in addition to #142 ?
440 2014-12-08 22:02:24 <sipa> no, #14
441 2014-12-08 22:02:28 <sipa> no, #142
442 2014-12-08 22:03:11 <cfields> sipa: see https://github.com/bitcoin/secp256k1/pull/144. probably worth rebasing 142 on top of that to verify
443 2014-12-08 22:03:48 <sipa> will do
444 2014-12-08 22:04:12 <sipa> done
445 2014-12-08 22:05:36 <cfields> also now that there's a possible dep-less build, it's possible to have travis build for mingw/arm if you want
446 2014-12-08 22:05:55 <sipa> that would be nice
447 2014-12-08 22:06:08 <cfields> not sure how necessary since bitcoin's doing that anyway, though
448 2014-12-08 22:06:29 <sipa> not a priority in any case
449 2014-12-08 22:06:51 <cfields> sure
450 2014-12-08 22:07:20 <cfields> well, great work on the lib. looks like you were very busy while i was gone :)
451 2014-12-08 22:07:22 <sipa> and many travis combinations is pretty expensive
452 2014-12-08 22:37:56 <sipa> cfields: gah, adding clang really seems to make things slower
453 2014-12-08 22:38:07 <sipa> (travis slower i mean)
454 2014-12-08 22:38:26 <cfields> sipa: we could selectively use it for a build or two, if you'd prefer
455 2014-12-08 22:38:38 <sipa> it's fine
456 2014-12-08 22:44:52 <sipa> cfields: aaargh
457 2014-12-08 22:45:06 <sipa> and it seems clang generates broken code at -O0 with that inline asm block
458 2014-12-08 22:45:25 <sipa> (it uses a register that gets clobbered to refer to memory variables...)
459 2014-12-08 22:47:45 <cfields> mm, known issue?
460 2014-12-08 22:47:49 <sipa> no clue
461 2014-12-08 22:49:03 <sipa> gcc behaves exactly the same way, but produces an error if it can't vacate %rbp