1 2014-11-21 00:13:40 <Luke-Jr> sipa: libsecp256k1's "32bit" options are really "generic C", right?
  2 2014-11-21 00:18:16 <gmaxwell> Luke-Jr: assuming you have a uint32 type. Really the whole library could be made to work where int is 16 bits (so long as there is a 32 bit type available) though I think it's very likely broken in that case right now.
  3 2014-11-21 00:18:52 <Luke-Jr> gmaxwell: uint32_t is required by C :p
  4 2014-11-21 00:19:23 <gmaxwell> C89 doesn't give that type any particular name.
  5 2014-11-21 00:19:56 <gmaxwell> (e.g. it may be unsigned long)
  6 2014-11-21 00:20:52 <sipa> Luke-Jr: "32bit" also requires uint64_t
  7 2014-11-21 00:20:56 <gmaxwell> oh actually I'm wrong, actualy the 32 bit fields need access to a long long; which is only guarenteed by C99. (though pretty widely available even in c89 compilers)
  8 2014-11-21 00:21:15 <sipa> 64bit requires __int128
  9 2014-11-21 00:21:46 <Luke-Jr> 
ACTION pretends C < C99 doesn't exist ☺

 10 2014-11-21 00:22:06 <gmaxwell> now I'm wondering if comparisons of long long on 32bit x86 produce the brancy mess that comparisons of int128 do on x86_64.
 11 2014-11-21 00:22:29 <sipa> gmaxwell: they do
 12 2014-11-21 00:23:32 <gmaxwell> Luke-Jr: you can do that, but you can also predent that non-gcc non-clang systems don't exist... mostly it's the same as pretending the same thing. (well, I guess the very latest MSVC finally picked up some more of C99)
 13 2014-11-21 00:24:45 <sipa> some guy made an MSVC build env for it, so i'm sure it forks
 14 2014-11-21 00:24:46 <sipa> eh
 15 2014-11-21 00:24:48 <sipa> works
 16 2014-11-21 00:24:54 <sipa> that was a genuine typo!
 17 2014-11-21 00:41:13 <gmaxwell> sipa: only in the very latest visual studio which can be a problem for existing projects.  (only the very latest version added var arrays)
 18 2014-11-21 00:47:31 <Luke-Jr> gmaxwell: I explicitly ignore MSVC :P
 19 2014-11-21 00:47:42 <Luke-Jr> sipa: is that even possible? :o
 20 2014-11-21 00:47:57 <Luke-Jr> didn't know they finally got var arrays
 21 2014-11-21 00:47:57 <sipa> what possible?
 22 2014-11-21 00:48:17 <Luke-Jr> sipa: (apparently until recently) MSVC has never supported variable-size arrays
 23 2014-11-21 00:51:58 <gmaxwell> yea, the very latest version got them. I was surprised. God knows how they're implemented, they might malloc. :P
 24 2014-11-21 00:53:00 <Luke-Jr> sipa: did libsecp256k1 drop OpenSSL bignum support?
 25 2014-11-21 00:53:07 <Luke-Jr> gmaxwell: >_<
 26 2014-11-21 00:53:12 <gmaxwell> Luke-Jr: yes.
 27 2014-11-21 00:53:24 <sipa> yes, it was a pain to maintain
 28 2014-11-21 00:53:26 <Luke-Jr> configure.ac still has a check for it
 29 2014-11-21 00:53:26 <sipa> and slow
 30 2014-11-21 00:53:37 <gmaxwell> we do use openssl in the tests.
 31 2014-11-21 00:53:37 <sipa> there are still unit tests that compare with openssl
 32 2014-11-21 00:53:56 <sipa> the library itself should never require openssl
 33 2014-11-21 00:54:31 <gmaxwell> Luke-Jr: ultimately I believe the gmp req will also go away.
 34 2014-11-21 00:56:55 <sipa> also, i'd like to get rid of vararrays nonetheless
 35 2014-11-21 00:57:11 <sipa> (and gmaxwell even more, i guess)
 36 2014-11-21 00:59:22 <gmaxwell> yea, I'll do that too. I wasn't going to stop with the comments, var arrays is probably next.
 37 2014-11-21 00:59:49 <gmaxwell> then non-block allocations, which will be an ugly patch (or probably several ugly patches).
 38 2014-11-21 01:00:27 <sipa> 
ACTION does not look forward to having to predeclare loop variables

 39 2014-11-21 01:17:53 <Luke-Jr> var arrays are useful
 40 2014-11-21 01:32:11 <gmaxwell> Luke-Jr: they actually make writing reliable code harder though. Since if you don't know in advance what the maximums are, then potentially some input can smash the stack irrecoverably.  If you do know in advance what the maximums are... no need for variability.  Of course, sometimes you might only care to optimizes for the average case instead of the worst case; but in an adversarial setting its usually the worst case that matters.
 41 2014-11-21 01:32:34 <gmaxwell> there are some rare cases where they can truly reduce the worst case usage, but they're rare.
 42 2014-11-21 01:33:26 <gmaxwell> (e.g. say you have a recursive function of bounded maximum depth where the total allocated is constant, but the allocations could happen at any mixture of depths; without var arrays each call would always have to allocate the maximum)
 43 2014-11-21 01:34:22 <Luke-Jr> I think GCC can generate stack smashing protections
 44 2014-11-21 01:34:27 <Luke-Jr> probably LLVM too
 45 2014-11-21 01:34:42 <gmaxwell> yea, sure great, but when they trigger you're still crashed.
 46 2014-11-21 01:34:59 <gmaxwell> (and assuming nothing bad happened before they trigger, the canaries are only checked on return.
 47 2014-11-21 01:35:02 <gmaxwell> )
 48 2014-11-21 01:35:25 <Luke-Jr> if you don't check explicitly, you crash anyway.
 49 2014-11-21 01:35:52 <Luke-Jr> and when you don't check, the worst-case outcome is more dangerous (something else gets corrupted)
 50 2014-11-21 01:36:05 <Luke-Jr> var length arrays, the worst case is going beyond the stack size and crashing I think?
 51 2014-11-21 01:36:34 <gmaxwell> no the worst case is that you corrupt the stack and in doing so give a bad guy control of the instruction pointer. :(
 52 2014-11-21 01:37:04 <Luke-Jr> var length arrays shouldn't make corrupting the stack possible..
 53 2014-11-21 01:37:45 <gmaxwell> they do, go try to do long long foo[2097152] and start writing to foo and see what happens.
 54 2014-11-21 01:38:38 <Luke-Jr> oh, the pointer overflows? :/
 55 2014-11-21 01:39:01 <Luke-Jr> though that example would only be ~16 MB
 56 2014-11-21 01:39:18 <Luke-Jr> but I guess if it's non-sequential access, that could be something else
 57 2014-11-21 01:39:43 <Luke-Jr> lame :<
 58 2014-11-21 01:40:09 <Luke-Jr> oh well, either way, you need to check lengths explicitly
 59 2014-11-21 01:40:19 <gmaxwell> stacks on x86_64/linux are 8mb normally. (IIRC 2MB on windows)
 60 2014-11-21 01:40:52 <gmaxwell> yea, sure but if you do that then you could have avoided the var array and just used the limit.  (don't get me wrong, I love var arrays and use them in all my throw away code)
 61 2014-11-21 01:41:22 <gmaxwell> I just don't think they're a good tool in high reliablity software.
 62 2014-11-21 01:42:24 <Luke-Jr> using the limit wastes memory needlessly
 63 2014-11-21 01:43:37 <Luke-Jr> virtually all hex printing in BFGMiner uses { char hex[(sizevar * 2) + 1]; bin2hex(hex, var, sizevar); }
 64 2014-11-21 01:47:45 <Luke-Jr> gmaxwell: btw, Mac stack is like 512k
 65 2014-11-21 01:48:10 <Luke-Jr> that bit me when I was assigning a big struct :/
 66 2014-11-21 01:48:29 <Luke-Jr> (for some reason, LLVM seems to initialise the struct on the stack then copy it :| )
 67 2014-11-21 01:57:51 <Diablo-D3> [08:40:20] <gmaxwell> stacks on x86_64/linux are 8mb normally. (IIRC 2MB on windows)
 68 2014-11-21 01:57:58 <Diablo-D3> I will confirm that stacks on linux are absolutely huge
 69 2014-11-21 01:58:16 <Diablo-D3> having small stacks on modern machines makes zero sense tbh
 70 2014-11-21 02:10:33 <Luke-Jr> cfields: utiltime.cpp:57:2: error: #error missing boost sleep implementation
 71 2014-11-21 02:10:41 <Luke-Jr> for now, it seems libbitcoinconsensus does in fact need boost
 72 2014-11-21 02:12:29 <fanquake> I’ve got a boost issue with it as well.
 73 2014-11-21 02:13:33 <fanquake> Also noticed that configure wont find boost HEAD installed via brew.
 74 2014-11-21 02:37:44 <Luke-Jr> not sure if anyone cares at this point, but if USE_SECP256K1 somehow gets defined (bitcoin-config.h is never included in the relevant file), it won't build with current libsecp256k1 *shrug*
 75 2014-11-21 02:37:52 <Luke-Jr> uses old functions that are gone
 76 2014-11-21 02:42:41 <lechuga_> Luke-Jr: are u working on gbt template mixing as part of your new effort?
 77 2014-11-21 02:44:07 <Luke-Jr> lechuga_: if nobody else does, yes
 78 2014-11-21 02:44:33 <Luke-Jr> (very likely from the past year)
 79 2014-11-21 02:46:06 <lechuga_> is gbt work part of your immediate focus?
 80 2014-11-21 02:47:26 <Luke-Jr> lechuga_: yes
 81 2014-11-21 02:48:21 <lechuga_> what are u doing first?
 82 2014-11-21 02:48:38 <lechuga_> (if u dont mind me prying)
 83 2014-11-21 02:49:06 <Luke-Jr> lechuga_: probably rewriting the BFGMiner side so it can handle the concept of work from multiple servers
 84 2014-11-21 02:49:48 <Luke-Jr> but I might have to do the pool side first so I can test that
 85 2014-11-21 02:50:14 <Luke-Jr> realitically, that needs the client for testing too
 86 2014-11-21 02:50:24 <Luke-Jr> so I'm in practice doing both concurrently XD
 87 2014-11-21 02:51:34 <lechuga_> ic
 88 2014-11-21 02:51:37 <lechuga_> makes sense
 89 2014-11-21 02:52:11 <Luke-Jr> s/both/all three/
 90 2014-11-21 02:52:58 <lechuga_> why is BFGminer all C
 91 2014-11-21 02:53:09 <Luke-Jr> lechuga_: why would it be anything but C?
 92 2014-11-21 02:53:13 <lechuga_> C++
 93 2014-11-21 02:53:19 <Luke-Jr> C++ is heavy
 94 2014-11-21 02:53:25 <rodo_> hello room
 95 2014-11-21 02:56:44 <Luke-Jr> lechuga_: some platforms running BFGMiner don't even have room for BFGMiner (uncompressed) - adding libstdc++ would overflow compressed
 96 2014-11-21 02:57:06 <lechuga_> heh
 97 2014-11-21 02:57:51 <lechuga_> awesome that you're getting funding to do this work
 98 2014-11-21 02:58:02 <lechuga_> it really needs to get done
 99 2014-11-21 03:38:01 <Luke-Jr> anyone opposed to increasing default RPC threads high enough for solo mining testnet? probably like 20 or so I'm guessing
100 2014-11-21 03:38:10 <Luke-Jr> testnet-in-a-box*
101 2014-11-21 03:38:20 <Luke-Jr> although now that I think of it, it's going to vary by hashrate, so maybe a bad idea
102 2014-11-21 03:38:30 <Luke-Jr> (most of it is submitting blocks found "at the same time"..
103 2014-11-21 03:47:50 <cfields> Luke-Jr: libbitcoinconsensus does not build that file.
104 2014-11-21 03:49:00 <cfields> Luke-Jr: and yes, the USE_SECP256K1 stuff is stale, it's not intended to be used now.
105 2014-11-21 03:49:36 <Luke-Jr> cfields: libbitcoinconsensus does include that file somehow.. --without-daemon --without-utils --without-gui - am I missing something?
106 2014-11-21 03:49:56 <cfields> sipa: ping re ^^. What do you want to do about the old USE_SECP256K1 for verification stuff? I'd prefer that it not be there if it's not supposed to work yet. maybe remove it until that stuff comes in later?
107 2014-11-21 03:50:09 <cfields> Luke-Jr: make libbitcoinconsensus.la
108 2014-11-21 03:50:19 <cfields> Luke-Jr: there should be no way that file is included
109 2014-11-21 03:51:18 <cfields> and yes... --disable-tests --disable-wallet
110 2014-11-21 04:03:47 <cfields> fanquake: what problem are you having with boost?
111 2014-11-21 04:16:49 <netg> Could an switch from LevelDB to LMDB be reasonable for Bitcoin (anytime)?
112 2014-11-21 04:20:46 <Luke-Jr> netg: switching db engines usually needs a reason
113 2014-11-21 04:23:07 <netg> i am an ordinary person, i read in other cryptocurrency channels that developers stated lmdb is superiror to leveldb for blockchain-storing
114 2014-11-21 04:23:22 <netg> i so try to find out its true by asking this question :)
115 2014-11-21 04:29:47 <gmaxwell> netg: if you'd like to switch it out in bitcoin-qt and provide benchmark results, I'd love to see it.  Database code is consensus critical so it has to be considered quite carefully. ... and in profiles leveldb isn't showing up as a huge bottleneck (though profiles are sometimes misleading)
116 2014-11-21 04:29:50 <fanquake> cfields having trouble compiling master after the libconsensus merge. See https://gist.github.com/fanquake/cfae6837fc73f1f63456
117 2014-11-21 04:30:41 <cfields> fanquake: mm, that's missing libstdc++
118 2014-11-21 04:31:09 <cfields> libtool: ignoring unknown tag CXX
119 2014-11-21 04:31:13 <cfields> did you see that before?
120 2014-11-21 04:31:30 <netg> tnx gmaxwell
121 2014-11-21 04:31:33 <fanquake> Yes, thats been around for a while
122 2014-11-21 04:31:59 <cfields> fanquake: are you doing anything odd with configure? It's trying to link with clang rather than clang++
123 2014-11-21 04:32:24 <gmaxwell> netg: the benchmarks on the lmdb site are not helpful, in that they focus on workloads which are unlike ours (e.g. highly concurrent)
124 2014-11-21 04:32:42 <cfields> the fact that it's using "clang" rather than some symlink from gcc leads me to believe that you're specifying it explicitly
125 2014-11-21 04:32:43 <fanquake> Nope. Only —with-gui=qt5 and —enable-debug
126 2014-11-21 04:33:45 <cfields> fanquake: do gcc/g++ not exist as symlinks to clang/clang++ for you?
127 2014-11-21 04:34:26 <fanquake> What’s the easisest way to check?
128 2014-11-21 04:34:32 <cfields> which gcc
129 2014-11-21 04:34:52 <fanquake> usr/bin/gcc
130 2014-11-21 04:35:06 <cfields> which g++
131 2014-11-21 04:35:19 <fanquake> usr/bin/g++
132 2014-11-21 04:35:40 <cfields> mm, so why is it using clang by default? do you have CC/CXX exported in your env?
133 2014-11-21 04:36:03 <fanquake> hmm, not that I know of.
134 2014-11-21 04:36:14 <cfields> echo $CC; echo $CXX
135 2014-11-21 04:37:00 <fanquake> That doesn’t echo anything.
136 2014-11-21 04:37:18 <cfields> odd. can you pastebin your config.log?
137 2014-11-21 04:38:25 <fanquake> https://gist.github.com/fanquake/bd9f2d4429cf1b830dc3 That is with just plain ./configure
138 2014-11-21 04:39:30 <cfields> oh ok, it's running gcc, but output says clang
139 2014-11-21 04:39:43 <cfields> (duh)
140 2014-11-21 04:40:53 <fanquake> This is the old issue I was thinking of https://github.com/bitcoin/bitcoin/issues/3228 quite a bit of discussion
141 2014-11-21 04:42:13 <cfields> fanquake: this one's not boost related. libbitcoinconsensus doesn't use boost
142 2014-11-21 04:42:38 <cfields> rather, it appears to be trying to link with the c linker
143 2014-11-21 04:42:46 <cfields> please do "make V=1" and pastebin
144 2014-11-21 04:45:04 <fanquake> https://gist.github.com/fanquake/bb44d7b3616577a7cf44
145 2014-11-21 04:47:25 <cfields> fanquake: http://pastebin.com/raw.php?i=Q7dPfKKW
146 2014-11-21 04:47:29 <cfields> run that, please. it should work.
147 2014-11-21 04:49:17 <fanquake> clang: error: no such file or directory: 'core/.libs/libbitcoinconsensus_la-transaction.o'
148 2014-11-21 04:49:28 <cfields> cd src first :)
149 2014-11-21 04:49:36 <fanquake> ugh
150 2014-11-21 04:49:43 <fanquake> haven’t turned my brain on yet
151 2014-11-21 04:50:29 <fanquake> done that now, and then ran make but still have the same error
152 2014-11-21 04:50:48 <cfields> no, don't run make. that line does the same thing that make does, but fixed
153 2014-11-21 04:50:52 <cfields> it runs without error?
154 2014-11-21 04:51:07 <fanquake> yes that runs without error
155 2014-11-21 04:51:25 <cfields> ok, so the issue is just the libtool tag thing
156 2014-11-21 04:51:37 <cfields> (i'm starting to _really_ dislike libtool)
157 2014-11-21 04:52:02 <fanquake> I’m starting to get sick of osx
158 2014-11-21 04:52:05 <cfields> fanquake: for now, you can ./configure --without-libs
159 2014-11-21 04:52:28 <fanquake> cheers, will do
160 2014-11-21 04:52:29 <cfields> fanquake: ok to poke at it tomorrow? I need to get to bed before too long
161 2014-11-21 04:52:45 <fanquake> Yea no worries.
162 2014-11-21 04:53:02 <cfields> that's a 100% workaround, it just avoids the actual problem
163 2014-11-21 04:53:12 <cfields> though, i'm surprised you don't have other problems because of the root cause
164 2014-11-21 04:53:14 <fanquake> Yep
165 2014-11-21 04:53:35 <fanquake> There probably lurking somewhere
166 2014-11-21 04:53:40 <fanquake> One unrelated issue, I’ve noticed configure wont pickup boost if you’ve installed HEAD
167 2014-11-21 04:54:31 <cfields> that sounds likely related... it relies on c++ for tests
168 2014-11-21 04:54:41 <cfields> not related for sure, but enough to be suspicious
169 2014-11-21 04:55:05 <fanquake> hmm ok. Can debug later.
170 2014-11-21 04:55:17 <fanquake> One thing I’m starting to wonder is if my XCode is somehow borked
171 2014-11-21 04:55:18 <cfields> well, what's your work-around there?
172 2014-11-21 04:55:51 <fanquake> Just using boost 1.56.0
173 2014-11-21 04:56:09 <cfields> wait. you meant boost HEAD ?
174 2014-11-21 04:56:16 <fanquake> Yea
175 2014-11-21 04:56:22 <cfields> are you a madman? :)
176 2014-11-21 04:56:46 <fanquake> Well I am australian
177 2014-11-21 04:57:34 <fanquake> I don’t try and use HEAD specifically, just had it installed and linked, and noticed configure wasn’t seeing it
178 2014-11-21 04:57:36 <cfields> i thought that just made you an asshole? you can still be clever :)
179 2014-11-21 04:58:19 <cfields> mm, i'm not touching that one. stable boost is enough to deal with.
180 2014-11-21 04:58:23 <fanquake> ahah
181 2014-11-21 04:58:33 <fanquake> I try to be clever.
182 2014-11-21 04:58:50 <fanquake> I’ll leave being really smart ot the experts ;)
183 2014-11-21 05:00:36 <cfields> heh, nice cop-out
184 2014-11-21 05:00:43 <cfields> i'll build on my osx box first thing tomorrow
185 2014-11-21 05:01:13 <cfields> actually.. just did. finished faster than i thought. no problem here. You're on 10.10, i'd guess?
186 2014-11-21 05:01:20 <fanquake> Just keeping up AUS US relations
187 2014-11-21 05:01:25 <fanquake> nah 10.9.5
188 2014-11-21 05:02:15 <cfields> mm, same
189 2014-11-21 05:03:11 <fanquake> I’’l play around a bit this arvo
190 2014-11-21 05:03:30 <cfields> ok
191 2014-11-21 05:03:38 <fanquake> Might actually have to install the entire Xcode app
192 2014-11-21 05:05:53 <cfields> do you know when you started seeing that tag warning?
193 2014-11-21 05:07:29 <fanquake> I’m fairly certain it was before we added the CXX tag to the makefile
194 2014-11-21 05:08:42 <fanquake> https://github.com/bitcoin/bitcoin/commit/6f155bdb80f045f8542550a5a9b97a00201fa0c5
195 2014-11-21 05:10:03 <cfields> grep -m 1 available_tags ./libtool
196 2014-11-21 05:10:05 <cfields> from srcroot
197 2014-11-21 05:12:08 <fanquake> Seeing No such file or directory
198 2014-11-21 05:12:34 <cfields> from the bitcoin/ dir?
199 2014-11-21 05:12:41 <fanquake> mm
200 2014-11-21 05:14:14 <fanquake> I can see libtool though
201 2014-11-21 05:14:27 <cfields> ok, no worries
202 2014-11-21 05:19:03 <cfields> fanquake: try one quick thing?
203 2014-11-21 05:20:13 <fanquake> sure
204 2014-11-21 05:20:49 <cfields> http://pastebin.com/raw.php?i=pBwF2Wb0
205 2014-11-21 05:20:55 <cfields> then ./autogen && ./configure
206 2014-11-21 05:21:18 <cfields> that _should_ be redundant. but since your config isn't picking up on it, shouldn't hurt to be explicit
207 2014-11-21 05:23:23 <fanquake> http://pastebin.com/raw.php?i=DR1NBYB9
208 2014-11-21 05:24:45 <cfields> see if it builds without that tag warning now, and without the libbitcoinconsensus error
209 2014-11-21 05:32:54 <fanquake> cfields Same error
210 2014-11-21 05:33:13 <cfields> ok. will look into it some more tomrrow. thanks for testing
211 2014-11-21 05:33:31 <fanquake> No trouble
212 2014-11-21 05:38:36 <gmaxwell> sipa: there is an unrelated travis timeout on https://github.com/bitcoin/bitcoin/pull/5316  we should probably change run_ge to only run 1000 or 500 times, and perhaps insert some printfs in between tests in the secp256k1 tests since travis seems to care about output.
213 2014-11-21 07:18:43 <bitname> Are there any projects to create a coin that's blockchain is dedicated to a marketplace?
214 2014-11-21 07:22:43 <Luke-Jr> bitname: yes, but it doesn't require "a coin", it works fine with bitcoin
215 2014-11-21 07:23:48 <bitname> Luke-Jr, do you know where would I find more info
216 2014-11-21 07:24:43 <Luke-Jr> not sure - maybe #freicoin is appropriate, but maaku would know where is best
217 2014-11-21 07:25:04 <bitname> Thanks Luke-Jr
218 2014-11-21 08:10:06 <xperia> hi all. i am having problem building bitcoin master. i am getting this compile error message here:
219 2014-11-21 08:11:00 <xperia> protocol.cpp: In member function 'std::string CMessageHeader::GetCommand() const': protocol.cpp:43:81: error: 'strnlen' was not declared in this scope
220 2014-11-21 08:11:02 <xperia>      return std::string(pchCommand, pchCommand + strnlen(pchCommand, COMMAND_SIZE));
221 2014-11-21 08:11:03 <xperia> make[2]: *** [libbitcoin_common_a-protocol.o] Error 1 make[2]: Leaving directory `/bitcoin/src'  make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/bitcoin/src' make: *** [all-recursive] Error 1
222 2014-11-21 08:12:38 <jonasschnelli> xperia, on which plattform do you build?
223 2014-11-21 08:13:08 <xperia> mingw windows. i had no problem with building bitcoin v0.9.3
224 2014-11-21 08:15:55 <paveljanik> had the same problem on a very old Mac OS X machine
225 2014-11-21 08:20:28 <xperia> paveljanik: your patch worked. compiles great here with your changes.
226 2014-11-21 08:27:16 <paveljanik> but I still didn't dfound the time to investigate when strnlen was standardized or if systems without it are already deprecated, sorry for that.
227 2014-11-21 08:27:59 <paveljanik> looks like it is POSIX.1-2008
228 2014-11-21 08:28:01 <wumpus> xperia: you need to use a newer version of mingw
229 2014-11-21 08:29:20 <wumpus> the one that we use for gitian does support strnlen
230 2014-11-21 08:29:45 <paveljanik> yes. I think it is not worth to add any workaround to the repo...
231 2014-11-21 08:32:19 <xperia> wumpus: thanks for the suggestion. it should be the newest version if i am not wrong. installed it a few days back. also updated all packages using aptitude like gui. looking to find version.
232 2014-11-21 08:33:23 <xperia> as said i had no problems with building compiling bitcoin v0.9.3 with the same mingw version but maybe master has some big changes and this is why it breaks now.
233 2014-11-21 08:33:38 <wumpus> master has *lots* of changes since
234 2014-11-21 08:33:55 <wumpus> thanks for trying though
235 2014-11-21 08:35:11 <wumpus> must be possible to find a workaround for strnlen, although I'd prefer not ot
236 2014-11-21 08:38:13 <paveljanik> but it would be nice to have it in the issues so people can find the solution.
237 2014-11-21 08:38:34 <wumpus> well if he's already using the newest mingw then there isn't a solution
238 2014-11-21 08:38:38 <paveljanik> xperia: do you care enough to file an issue for it? I'll add the patch I have used locally (hack)..
239 2014-11-21 08:39:37 <wumpus> apart from changing the code, ie use AC_CHECK_FUNC([strnlen]) in the build system, then provide a helper function if it doesn't exist...
240 2014-11-21 08:39:39 <xperia> paveljanik: i will be glad to do anything but i have absolute no clue what you mean with filing an issue. do you mean making a bug report ? if yes where ?
241 2014-11-21 08:39:56 <wumpus> mingw at least http://sourceforge.net/p/mingw/bugs/1912/
242 2014-11-21 08:42:06 <paveljanik> xperia: https://github.com/bitcoin/bitcoin/issues, New issue
243 2014-11-21 08:46:13 <xperia> paveljanik: => https://github.com/bitcoin/bitcoin/issues/5338
244 2014-11-21 08:48:33 <xperia> wumpus: so it looks like the bug report is still open in mingw. so installing newest version will not help if i am not wrong as mingw does not have any strnlen function while bitcoin is using one. so without a patch bitcoin could not be compiled anymore with mingw ?
245 2014-11-21 08:48:55 <wumpus> xperia: the curious thing is that it works with the mingw used by gitian, which is used to build releases
246 2014-11-21 08:49:02 <paveljanik> xperia: thanks. I'll take care of it because I do have an old machine where I can reproduce it.
247 2014-11-21 08:49:22 <wumpus> xperia: so there must be some way to coerce your mingw to have it as well
248 2014-11-21 08:50:03 <wumpus> damnit, cannot even build ARM depends anymore
249 2014-11-21 08:54:24 <wumpus> oh, forgot to provide NO_QT and NO_WALLET
250 2014-11-21 09:25:51 <xperia> wumpus: paveljanik: i checked the mingw version and i can confirm that it is that ltest availble for download that i have installed => http://sourceforge.net/projects/mingw/files/?source=navbar
251 2014-11-21 09:26:12 <wumpus> ok
252 2014-11-21 09:26:47 <xperia> i got another build breaking error. this time with the database itself.
253 2014-11-21 09:27:56 <xperia> Building LevelDB ...
254 2014-11-21 09:27:58 <xperia> from helpers/memenv/memenv.cc:7:
255 2014-11-21 09:27:59 <xperia> helpers/memenv/memenv.cc: In member function 'leveldb::Status leveldb::{anonymous}::FileState::Read(uint64_t, size_t, leveldb::Slice*, char*) const':
256 2014-11-21 09:28:01 <xperia> helpers/memenv/memenv.cc:65:35: error: 'SIZE_MAX' was not declared in this scope
257 2014-11-21 09:28:02 <xperia>      assert(offset / kBlockSize <= SIZE_MAX);
258 2014-11-21 09:28:04 <xperia> make[3]: *** [helpers/memenv/memenv.o] Error 1
259 2014-11-21 09:28:13 <wumpus> please don't paste all that stuff here, use a pastebin
260 2014-11-21 09:28:25 <paveljanik> maybe the strnlen depends on the base OS. But I wonder how it could be connected...
261 2014-11-21 09:31:05 <sipa> cfields: yes, we should remove the USE_SECP256K1 stuff... it's easy enough to merge it back in again i guess
262 2014-11-21 09:39:12 <wumpus> paveljanik: my guess is that it's some -Dsomething that needs to be passed
263 2014-11-21 09:39:47 <paveljanik> on my old system, there is no string strnlen in the headers at all.
264 2014-11-21 09:40:03 <wumpus> but are you using a recent mingw like xperia?
265 2014-11-21 09:40:18 <paveljanik> nono, I have the strneln issue on other system...
266 2014-11-21 09:40:34 <paveljanik> I do not use Windows at all
267 2014-11-21 09:40:35 <wumpus> 'old system' could mean mingw 4.4 or so, we don't support that
268 2014-11-21 09:40:53 <paveljanik> I can reproduce the bug on Mac OS X 10.6.8 IIRC
269 2014-11-21 09:41:45 <wumpus> xperia: I think I know the issue - we use ming-w64 to build, not mingw, http://sourceforge.net/projects/mingw-w64/?source=directory
270 2014-11-21 09:41:54 <paveljanik> hmm, but the current master introduced too many new dependencies taht I first have to tackle them :-((
271 2014-11-21 09:42:15 <wumpus> paveljanik: only libgmp
272 2014-11-21 09:42:43 <paveljanik> yes
273 2014-11-21 09:43:07 <paveljanik> on such old systems, this could mean something else as well
274 2014-11-21 09:43:41 <xperia> wumpus: ahh yeah that could be. i use ming32 the 32 Bit version. still strange that a function like strnlen is missing in a 32 Bit version but availble in a 64 Bit Version
275 2014-11-21 09:43:59 <sipa> mingw-w64 also does 32bit
276 2014-11-21 09:44:01 <wumpus> xperia: no, mingw-w64 is *not* the 64 bit version, it's just a fork of mingw that supports both 32 and 64 bit
277 2014-11-21 09:44:33 <wumpus> I really wish they had chosen a different name, everyone gets that confusion
278 2014-11-21 09:45:03 <xperia> ahhh okey well fork say it all then.
279 2014-11-21 09:46:01 <Diablo-D3> the important part to understand is
280 2014-11-21 09:46:09 <Diablo-D3> msys2 uses mingw-w64 instead of mingw
281 2014-11-21 09:46:22 <Diablo-D3> ALL GLORY TO MSYS2
282 2014-11-21 09:46:33 <wumpus> hehe
283 2014-11-21 09:48:22 <Diablo-D3> seriously, if it wernt for msys2, I would ahve driven to the microsoft campus in washington, and burned the whole motherfucker down by now
284 2014-11-21 09:50:22 <wumpus> that would be like kicking a dead horse
285 2014-11-21 09:51:04 <phantomcircuit> wumpus, people do that
286 2014-11-21 09:51:08 <phantomcircuit> 
ACTION flees

287 2014-11-21 09:51:12 <Diablo-D3> no, it would be safely disposing of its corpse as to prevent the spread of disease
288 2014-11-21 09:58:42 <xperia> wumpus: ahh okey i got it. i thinked the mingw-w64 is the same package like mingw64 the 64 Bit mingw version. indeed confusing.
289 2014-11-21 09:58:43 <xperia> btw. what LevelDB version works with bitcoin 0.9.99 ? I have "db-4.8.30.NC" and it breaks bitcoin compilation with this line here
290 2014-11-21 09:58:45 <xperia> helpers/memenv/memenv.cc: In member function 'leveldb::Status leveldb::{anonymous}::FileState::Read(uint64_t, size_t, leveldb::Slice*, char*) const': helpers/memenv/memenv.cc:65:35: error: 'SIZE_MAX' was not declared in this scope
291 2014-11-21 09:58:46 <xperia> this need to be solved. any suggestions ?
292 2014-11-21 09:59:33 <sipa> xperia: the one in the bitcoin source code should work
293 2014-11-21 09:59:47 <sipa> src/leveldb
294 2014-11-21 10:00:20 <Belxjander> is there any limitations on using other DB systems instead of bdb and leveldb?
295 2014-11-21 10:00:39 <sipa> if you implement the changes to use another, sure
296 2014-11-21 10:01:07 <sipa> they're really just key-value stores with atomic batch writes
297 2014-11-21 10:01:51 <Belxjander> Then MongoDB should have little or no issue then?
298 2014-11-21 10:02:46 <sipa> why the hell would you want to use that?
299 2014-11-21 10:04:37 <sipa> we don't need indexes, the data is not useful to other applications, we don't support multiple processes accessing the same data, and it's only a few 100 MB
300 2014-11-21 10:06:35 <xperia> sipa. okey thanks for the tip related LevelDB. checked my configuration settings to see if i changed anything to DB related stuff and it appears it was nothing changed. i expected bitcoin works with BDB is this not anymore the case for 0.9.99 ? sorry to ask such question i just started studying bitcoin.
301 2014-11-21 10:07:01 <sipa> xperia: the wallet (still) uses BDB; everything else uses LevelDB
302 2014-11-21 10:07:10 <sipa> since 0.8.0
303 2014-11-21 10:07:36 <gmaxwell> how can travis be kicked if its had a spurrious timeout?
304 2014-11-21 10:07:57 <wumpus> you can go to the travis page, and click the reload/refresh icon
305 2014-11-21 10:08:03 <sipa> oh really?!
306 2014-11-21 10:08:14 <wumpus> yes
307 2014-11-21 10:08:22 <sipa> wait, does that rerun the test?
308 2014-11-21 10:08:25 <wumpus> yes
309 2014-11-21 10:08:47 <wumpus> or may be something special that I have because I'm logged in?
310 2014-11-21 10:09:03 <gmaxwell> yea, I don't see it.
311 2014-11-21 10:09:29 <wumpus> ok, which one do you need restarted?
312 2014-11-21 10:11:21 <xperia> sipa: ahhh okey thanks for the info. good to know. any suggestion why then the bitcoin LevelDB fails/breaks to compile in master branch? is this a known issue?
313 2014-11-21 10:11:42 <sipa> seems to work here, and in mingw-w64
314 2014-11-21 10:11:49 <wumpus> xperia: you're having mingw specific issues, please upgrade to mingw-w64
315 2014-11-21 10:12:17 <xperia> wumpus: okey thanks will do it then.
316 2014-11-21 10:14:52 <Belxjander> sipa: using mongodb is overkill then? if I wanted multiple nodes to run a common blockchain but local wallets?
317 2014-11-21 10:15:07 <wumpus> there is no 'known issue' because no one else builds with your specific compiler/environment
318 2014-11-21 10:15:12 <sipa> Belxjander: use one node, plus several SPV wallets
319 2014-11-21 10:16:00 <sipa> Belxjander: as i said, multiple nodes using the same blockchain is not supported - the database is not intended to be shared with other processes
320 2014-11-21 10:19:12 <Belxjander> sipa well I have a lot to learn then
321 2014-11-21 10:21:31 <jonasschnelli> sipa: is there a reason why the wallet still uses BDB?
322 2014-11-21 10:21:41 <sipa> jonasschnelli: nobody did the work to change it
323 2014-11-21 10:21:52 <wumpus> jonasschnelli: backwards compatibility
324 2014-11-21 10:22:12 <jonasschnelli> is there any discussion about a standard wallet format? or what would be appropriate?
325 2014-11-21 10:22:36 <sipa> plus, even though technically we could pretty much switch to LevelDB as a drop-in replacement, that would be very inconvenient, because a database in leveldb is a whole directory
326 2014-11-21 10:23:08 <sipa> jonasschnelli: i suggested/worked on a very simple append-only checksummed key-value store file format for a while (and had it somewhat working in bitcoin core)
327 2014-11-21 10:23:48 <sipa> jonasschnelli: regarding 'standard format': i don't believe in that - i don't think people agree what wallet best practices are, or even what exactly a wallet is in terms of database structure
328 2014-11-21 10:24:56 <jonasschnelli> sipa: is there any significant performance situations why you suggest append only?
329 2014-11-21 10:25:18 <sipa> performance is utterly irrelevant; the whole wallet in loaded into memory anyway
330 2014-11-21 10:25:36 <sipa> it's just for consistency
331 2014-11-21 10:26:15 <sipa> read in a bunch of checksummed records; if you reach the end, or read an incorrect checksum, stop
332 2014-11-21 10:26:16 <jonasschnelli> sipa just thinking with my humble brain: can it not be a human readable format like json or something?
333 2014-11-21 10:26:37 <sipa> jonasschnelli: can you read transactions? hashes?
334 2014-11-21 10:26:39 <sipa> what's the point
335 2014-11-21 10:27:03 <sipa> a text format could be used, sure, and even be append-only
336 2014-11-21 10:27:13 <sipa> with long sequences of hex in it
337 2014-11-21 10:27:52 <jonasschnelli> of course the wallet file size would be double or even more... but still more convenient for most users and developers
338 2014-11-21 10:28:07 <sipa> it's not like you could edit it manually
339 2014-11-21 10:28:12 <sipa> or use much of what is inside
340 2014-11-21 10:28:18 <sipa> without breaking consistency
341 2014-11-21 10:28:33 <jonasschnelli> Yes. sure. But it would be better understandable for other devs
342 2014-11-21 10:28:44 <sipa> perhaps
343 2014-11-21 10:28:46 <jonasschnelli> And at least some experience users could have "a look at it"
344 2014-11-21 10:32:24 <gmaxwell> wumpus: can you kick https://travis-ci.org/bitcoin/bitcoin/builds/41664968 for rebuild in travis?
345 2014-11-21 10:32:58 <btcdrak> has anyone noticed bitcoin compile is borked?
346 2014-11-21 10:33:30 <btcdrak> I get make[3]: *** No rule to make target `libsecp256k1.la'. Stop.
347 2014-11-21 10:33:30 <btcdrak>  on the latest master
348 2014-11-21 10:33:42 <wumpus> btcdrak: re-run ./autogen.sh
349 2014-11-21 10:33:54 <wumpus> gmaxwell: done
350 2014-11-21 10:34:09 <gmaxwell> jonasschnelli: making the file many times larger via encoding does make it more vulnerable to corruption.  Also there are internal references between data in the file, just going in and editing it will result in corruption... which then means more code to deal with non-sensible wallets, or more users bumping their heads into sharp corners when those cases aren't handled.
351 2014-11-21 10:34:42 <gmaxwell> having diagnostic tools for dumping and inspecting all sound reasonable to me.
352 2014-11-21 10:35:57 <jonasschnelli> okay. larger files = more corruption risks. That's right.
353 2014-11-21 10:36:11 <jonasschnelli> But i'm still thinking if the file backend is the only thing.
354 2014-11-21 10:36:21 <jonasschnelli> I would love to see my keys in my OS keychain.
355 2014-11-21 10:36:39 <jonasschnelli> metadata could still be kept in a file.
356 2014-11-21 10:36:57 <wumpus> aren't there wallets that do that yet?
357 2014-11-21 10:37:02 <btcdrak> wumpus I get the same error after rerunning autogen
358 2014-11-21 10:37:17 <wumpus> btcdrak: have you also re-run configure?
359 2014-11-21 10:37:19 <jonasschnelli> wumpus not that i know of. I once tried that with "MacWallet".
360 2014-11-21 10:37:21 <gmaxwell> jonasschnelli: it's very important that the wallet be _consistent_. Seperating parts out isn't helpful ... now, putting e.g. wallet encryption keys in the OS keyring seems reasonable to me.
361 2014-11-21 10:37:46 <wumpus> or the wallet seed in case of a deterministic wallet
362 2014-11-21 10:37:51 <jonasschnelli> gmaxwall okay. i see.
363 2014-11-21 10:37:56 <btcdrak> wumpus: yes
364 2014-11-21 10:38:02 <jonasschnelli> wumpus, that's another storry.
365 2014-11-21 10:38:28 <jonasschnelli> I would love to help implementing BIP32... but it just seams to be complex for me.
366 2014-11-21 10:38:39 <wumpus> btcdrak: hm, try wiping the entire build directory and starting from scratch
367 2014-11-21 10:38:50 <sipa> btcdrak: which commit are you at?
368 2014-11-21 10:39:02 <wumpus> jonasschnelli: it really doesn't have to be within the scope of bitcoin core
369 2014-11-21 10:39:39 <jonasschnelli> you mean a separate wallet wich uses bitcoin-core as full node backend?
370 2014-11-21 10:39:49 <sipa> jonasschnelli: which is like every single spv wallet :)
371 2014-11-21 10:40:02 <wumpus> jonasschnelli: yes, like any SPV wallet
372 2014-11-21 10:40:11 <wumpus> just tell it to only connect to your node
373 2014-11-21 10:40:28 <btcdrak> wumpus: same result
374 2014-11-21 10:40:36 <wumpus> btcdrak: no clue then
375 2014-11-21 10:40:48 <jonasschnelli> Does normal endusers have one VPS/roots with a node running?
376 2014-11-21 10:41:43 <sipa> do they need to?
377 2014-11-21 10:41:46 <netg> most people and irc or BCT have
378 2014-11-21 10:41:57 <netg> the others not so much
379 2014-11-21 10:42:54 <btcdrak> btw wumpus there is something odd in the build logs: https://travis-ci.org/bitcoin/bitcoin/jobs/41664969#L1310 it's a git command being run which is obviously wrong
380 2014-11-21 10:43:25 <sipa> btcdrak: known but harmless
381 2014-11-21 10:43:32 <wumpus> jonasschnelli: what are 'normal endusers'?
382 2014-11-21 10:43:44 <sipa> jonasschnelli: i expect normal endusers to just run an SPV client
383 2014-11-21 10:43:59 <sipa> (or more centralized things :'( )
384 2014-11-21 10:44:15 <wumpus> the lowest denomination would be using one of the android SPV wallets, probably
385 2014-11-21 10:44:45 <wumpus> not pointed at a specific node
386 2014-11-21 11:08:46 <btcdrak> wumpus solved, i was missing a new dependency libgmp-dev
387 2014-11-21 11:09:38 <sipa> btcdrak: it should tell you that it couldn't find a num implementation then... not that there is no libsecp256k1.la
388 2014-11-21 11:09:44 <sipa> during configure
389 2014-11-21 11:10:25 <btcdrak> sipa: dunno, it just works now.
390 2014-11-21 11:10:35 <sipa> ok!
391 2014-11-21 11:12:31 <wumpus> yes, the conifigure would have shown that
392 2014-11-21 11:12:44 <wumpus> it is easy to ignore if you're used to configure succeeding
393 2014-11-21 11:12:49 <sipa> we should rename our configure to coinfigure, i guess
394 2014-11-21 11:12:56 <wumpus> hehe
395 2014-11-21 14:35:37 <sipa> how are those python tests supposed to work?
396 2014-11-21 14:36:19 <sipa> i always get method not found
397 2014-11-21 14:36:35 <jtimon> ping #5111
398 2014-11-21 14:37:48 <sipa> jtimon: not really a priority now :)
399 2014-11-21 14:38:08 <sipa> jtimon: also, seems to need rebase
400 2014-11-21 14:38:48 <jtimon> I know, but I mean the only reason it was separated from #5100 was to keep the former move-only
401 2014-11-21 14:39:01 <jtimon> oh, yes, I should rebase it
402 2014-11-21 14:46:51 <wumpus> sipa: you should just be able to run them
403 2014-11-21 14:47:35 <wumpus> if it doesn't guess the srcdir right you can provide that, see qa/pull-tester/rpc-tests.sh
404 2014-11-21 14:49:06 <sipa> same
405 2014-11-21 14:49:14 <sipa> https://0bin.zertrin.org/paste/b527e5d0711fa2467334de22e9b19086c771d3fc#EpD1IwdxeKFmQtYx/M8XjUvnyZA5kO+BuC10+GHj9AQ=
406 2014-11-21 14:49:16 <gavinandresen> sipa: what version of python are you running?
407 2014-11-21 14:49:17 <wumpus> for *all* of them?
408 2014-11-21 14:49:27 <sipa> yes
409 2014-11-21 14:49:35 <sipa> 2.7.6
410 2014-11-21 14:49:50 <wumpus> are you running it against the right version of bitcoind?
411 2014-11-21 14:50:09 <gavinandresen> sipa: try ./smartfees.py —tracerpc
412 2014-11-21 14:50:20 <wumpus> seems it can't find the RPC method, maybe some new RPC method was added in between?
413 2014-11-21 14:50:33 <sipa> wumpus: all scripts give that
414 2014-11-21 14:50:38 <wumpus> shouldn't happen as it spins up its own bitcoind
415 2014-11-21 14:50:41 <wumpus> but stil.
416 2014-11-21 14:50:46 <gavinandresen> they all setup a cache directory, and use setmocktime.....
417 2014-11-21 14:50:47 <sipa> let me reconfigure etc
418 2014-11-21 14:51:25 <wumpus> travis also runs them succesfully so it must be a local problem
419 2014-11-21 14:51:54 <sipa> oh
420 2014-11-21 14:52:04 <sipa> i likely was using a build without wallet support
421 2014-11-21 14:52:20 <wumpus> ah, yes then at least the wallet-related tests won't work
422 2014-11-21 14:52:30 <sipa> the other ones fail too
423 2014-11-21 14:52:40 <sipa> sec, rebuilding
424 2014-11-21 14:52:43 <gavinandresen> that’d do it.  the test framework should probably test for that and give a good error
425 2014-11-21 14:53:46 <wumpus> I don't think all of them require a wallet, but most do
426 2014-11-21 14:53:58 <sipa> chaintips fails too
427 2014-11-21 14:54:26 <wumpus> oh wait... probably all of them do; they use regtest and the internal miner
428 2014-11-21 14:54:32 <sipa> ha
429 2014-11-21 14:54:35 <sipa> of course
430 2014-11-21 14:58:27 <sipa> seems to continue further now at least :)
431 2014-11-21 18:54:11 <Luke-Jr> sipa: cfields: http://dpaste.com/0SZ5N6Q any ideas?
432 2014-11-21 18:55:41 <cfields> Luke-Jr: first guess would be the hand-rolled asm isn't pic friendly
433 2014-11-21 18:55:48 <cfields> Luke-Jr: i can have a look in a min
434 2014-11-21 18:56:18 <Luke-Jr> cfields: different issue I think
435 2014-11-21 18:56:58 <Luke-Jr> I think we need to add something liek this to the yasm: http://codepad.org/3qcjNsiX
436 2014-11-21 18:57:13 <Luke-Jr> this is outside my scope of testing, since I'm 32-bit :x
437 2014-11-21 18:57:46 <cfields> Luke-Jr: throw scanelf at it and see what the exact problem is?
438 2014-11-21 18:58:17 <Luke-Jr> cfields: isn't that last line of the first paste from scanelf?
439 2014-11-21 19:00:26 <cfields> yea, i see
440 2014-11-21 19:01:16 <cfields> looks like you're right. testing now.
441 2014-11-21 19:06:48 <cfields> Luke-Jr: confirmed fixed with that
442 2014-11-21 19:07:05 <Luke-Jr> might check if x32 has a different elf thing there
443 2014-11-21 19:07:12 <Luke-Jr> not sure if there's a one check we can use
444 2014-11-21 19:08:39 <cfields> gentoo says there's elf32. no idea what that implies
445 2014-11-21 19:09:10 <Luke-Jr> hm
446 2014-11-21 19:09:12 <Luke-Jr> 
ACTION looks up docs

447 2014-11-21 19:10:10 <cfields> but either way, that asm obviously only builds for 64bit, so it wouldn't be in there for a real 32bit elf anyway
448 2014-11-21 19:10:10 <helo> what's up docs?
449 2014-11-21 19:10:34 <Luke-Jr> cfields: the asm builds for x32 too
450 2014-11-21 19:11:34 <cfields> Luke-Jr: i know. my point is that even if elf32 means only a native 32bit elf, it would be harmless since it couldn't be reached anyway
451 2014-11-21 19:12:19 <Luke-Jr> right
452 2014-11-21 19:12:31 <Luke-Jr> docs suggest 'elf' == 'elf32'
453 2014-11-21 19:12:38 <Luke-Jr> so we want 'elf64' and 'elfx32' I guess
454 2014-11-21 19:13:30 <cfields> i defer to you on the details. just confirming that 64bit is fixed :)
455 2014-11-21 19:13:34 <Luke-Jr> added to my fixups branch
456 2014-11-21 19:13:39 <cfields> thanks for finding
457 2014-11-21 19:15:06 <Luke-Jr> blueness found it ;)
458 2014-11-21 19:17:25 <cfields> Luke-Jr: may be worth grabbing some of bitcoin's other hardening flags
459 2014-11-21 19:18:09 <cfields> relro/binding/etc
460 2014-11-21 19:20:14 <Luke-Jr> cfields: not sure relro makes sense here - but I'm no expert on x86 assembly stuffs
461 2014-11-21 19:24:51 <cfields> Luke-Jr: admittedly i'm not either
462 2014-11-21 19:25:23 <Luke-Jr> what was the reason for not just using inline asm again? :P
463 2014-11-21 21:48:00 <BlueMatt> isnt https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L925 duplicate code?
464 2014-11-21 21:48:00 <BlueMatt> sipa: ^
465 2014-11-21 21:48:27 <BlueMatt> (ie we move on to check that coins are available via viewMemPool in the next step, so why do we have to check it previously)
466 2014-11-21 21:48:59 <BlueMatt> (also, if its not, there should be a race around the pool.cs lock, no?)
467 2014-11-21 22:11:30 <BlueMatt> actually, nvm, CTxMemPoolView doesnt filter out spent-in-mempool
468 2014-11-21 22:12:27 <sipa> not yet
469 2014-11-21 22:12:37 <sipa> andytoshi has a patch that does that
470 2014-11-21 22:13:10 <sipa> and the reason it wasn't done is because we used to be able to distinguish between existed-but-already-spent and doesnt-exist
471 2014-11-21 22:13:31 <sipa> but since 0.8 that became harder, and with the various utxo cache optimizations even hardere
472 2014-11-21 22:32:29 <cfields> gavinandresen: around?
473 2014-11-21 22:33:15 <Luke-Jr> weird, libbitcoinconsensus seems to not build without libsecp256k1 code
474 2014-11-21 22:33:42 <cfields> gavinandresen: i've managed to cobble together a successful detached dmg signer. let me know when you've got ~10min to give it a try
475 2014-11-21 22:34:39 <cfields> Luke-Jr: huh?
476 2014-11-21 22:35:11 <Luke-Jr> cfields: trying to build it with src/secp256k1 gone (and the autotools requirements for it removed)
477 2014-11-21 22:35:22 <Luke-Jr> seems it still gets #included
478 2014-11-21 22:35:48 <cfields> Luke-Jr: i don't see how, unless something slipped in in the last day or two
479 2014-11-21 22:36:09 <cfields> Luke-Jr: i built on wed, i think, completely out of tree
480 2014-11-21 22:36:13 <Luke-Jr> in key.cpp
481 2014-11-21 22:36:39 <cfields> it doesn't require key.cpp
482 2014-11-21 22:37:28 <Luke-Jr> well, building only the lib tries to compile it
483 2014-11-21 22:38:18 <cfields> Luke-Jr: the required files are completely explicit in the makefile
484 2014-11-21 22:38:26 <cfields> Makefile.am:343
485 2014-11-21 22:39:07 <sipa> are you somehow building with USE_LIBSECP256K1?
486 2014-11-21 22:39:57 <Luke-Jr> sipa: pretty sure not
487 2014-11-21 22:40:22 <Luke-Jr> I didn't see any possible way for that to get set
488 2014-11-21 22:40:32 <sipa> there shouldn't be
489 2014-11-21 22:41:46 <Luke-Jr> hm, it's possible --enable-tests is being used
490 2014-11-21 22:41:52 <cfields> Luke-Jr: make libbitcoinconsensus.la
491 2014-11-21 22:42:08 <cfields> afaik, no matter what, ^^ should only build the lib
492 2014-11-21 22:42:26 <cfields> (for testing, just to verify that you don't need other libs)
493 2014-11-21 22:43:40 <sipa> works correctly here
494 2014-11-21 22:48:31 <Luke-Jr> cfields: that make works, but it shouldn't be necessary IMO
495 2014-11-21 22:48:59 <sipa> was it a make check?
496 2014-11-21 22:49:04 <cfields> Luke-Jr: sure, i'm not saying that by any means. only that i haven't gotten around to making the 'build the lib only' case work yet
497 2014-11-21 22:49:14 <Luke-Jr> sipa: no, just a normal make
498 2014-11-21 22:49:16 <cfields> (i assume that's what you're doing now, though?)
499 2014-11-21 22:49:21 <Luke-Jr> cfields: yes
500 2014-11-21 22:58:03 <cfields> Luke-Jr: i believe convenience libs are always built, so you'll need to be sure those are all properly hidden behind if's
501 2014-11-21 23:02:05 <Luke-Jr> cfields: ah