1 2014-11-24 00:30:49 <rgenito_> op_null, ty
  2 2014-11-24 00:58:19 <jlopp> has anyone reported disk space issues while running master recently? I've experienced 3 cases on two machines in the past month where the chainstate directory became filled with thousands of .sst files until bitcoind crashed due to running out of disk space
  3 2014-11-24 00:59:02 <jlopp> restarting bitcoind cleans up the chainstate directory and frees up disk usage
  4 2014-11-24 01:02:25 <phillipsjk> 
ACTION always gets sweaty palms playing with raw transactions.

  5 2014-11-24 01:04:19 <phantomcircuit> jlopp, total directory sizes?
  6 2014-11-24 01:04:30 <phantomcircuit> how close to full were the disks?
  7 2014-11-24 01:06:13 <jlopp> a month ago on my home desktop IIRC the directory exceeded 80 GB on a 120 GB disk
  8 2014-11-24 01:07:07 <jlopp> more recently it was 38 GB on a small 50 GB VPS
  9 2014-11-24 01:10:40 <phantomcircuit> jlopp, check the debug.log file size
 10 2014-11-24 01:14:47 <jlopp> phantomcircuit debug.log was negligible because I had restarted bitcoind earlier today; the disk usage was all from /chainstate
 11 2014-11-24 01:15:03 <phantomcircuit> jlopp, is this about an altcoin
 12 2014-11-24 01:17:01 <jlopp> nope, I'm running my fork of bitcoind that has no functional changes, just additional stats logging
 13 2014-11-24 01:19:21 <bassguitarman> anyone know where cwallettx is defined?
 14 2014-11-24 01:19:46 <bassguitarman> “Field has incomplete type ‘CWalletTx’"
 15 2014-11-24 01:20:14 <phantomcircuit> jlopp, sounds like you broked something
 16 2014-11-24 01:20:23 <phantomcircuit> chainstate shouldn't exceed a few hundred MB
 17 2014-11-24 01:24:13 <jlopp> I hope you're right, though I don't know how that could have happened unless a bad merge from upstream occurred. Guess I'll run a comparison against it to be sure. Seems like a bad merge would have caused a bigger, more obvious issue rather than such an intermittent one. Based upon my machine's stats, it seems to sometimes go into bursts of disk writes which I'm assuming result in the thousands of .sst files https://i.imgur.com/7GtJF
 18 2014-11-24 07:19:35 <arowser> If the Jenkins test have been replace by travis-ci now, I'm not seen BitcoinPullTester in github commit after oct 1.
 19 2014-11-24 07:30:35 <Luke-Jr> was there a question there? :x
 20 2014-11-24 07:33:14 <wumpus> jlopp: that sounds like a leveldb iterator leak - there was one in gettxoutsetinfo solved recently https://github.com/bitcoin/bitcoin/pull/5115
 21 2014-11-24 07:36:08 <wumpus> keeping reference to a snapshot locks a copy of the database on disk so that it can't be cleaned up
 22 2014-11-24 07:36:49 <wumpus> until the next restart
 23 2014-11-24 07:37:50 <Luke-Jr> 
ACTION wonders if there would be any problems with disabling JSON-RPC HTTP keepalive until we can properly balance idle connections

 24 2014-11-24 07:44:42 <gmaxwell> Next time someone has a weird problem with their patched up copy of bitcoind, you should ask how they're patching it specifically.
 25 2014-11-24 08:11:29 <wumpus> agreed
 26 2014-11-24 13:11:00 <hearn> good afternoon
 27 2014-11-24 13:26:04 <gavinandresen> Anybody else having trouble configuring secp256k1 on on OSX 10.10.1? What’s the trick?
 28 2014-11-24 13:26:31 <gavinandresen> I get:  error: no working bignum implementation found  … but I did a brew install gmp and definitely have a /usr/local/include/gmp.h
 29 2014-11-24 13:28:50 <paveljanik> Do you have /usr/local/include in CPPFLAGS?
 30 2014-11-24 13:29:12 <paveljanik> what is in config.log?
 31 2014-11-24 13:29:42 <op_null> gavinandresen: I've no problem configuring and building master from bitcoin/secp256k1 on 10.10
 32 2014-11-24 13:30:21 <gavinandresen> config.log here: https://gist.github.com/gavinandresen/b0be5686eab2ef0f13c3
 33 2014-11-24 13:31:02 <gavinandresen> I’ve done a git clean -xf, re-ran autogen and configure....
 34 2014-11-24 13:32:13 <sipa> gavinandresen: does it work if you configure/build secp256k1 directly?
 35 2014-11-24 13:32:20 <paveljanik> gavinandresen: can you paste secp*/config.log?
 36 2014-11-24 13:32:30 <sipa> (go to src/secp256k1 and run ./autogen.sh and ./configure there?)
 37 2014-11-24 13:33:47 <gavinandresen> same result running autogen/configure in secp*, config.log for that here: https://gist.github.com/gavinandresen/fefc511cb40676820b54
 38 2014-11-24 13:34:39 <paveljanik> configure:12678: gcc -c -g -O2 -W -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes -Wno-unused-function  -I/opt/local/include conftest.c >&5
 39 2014-11-24 13:34:39 <paveljanik> conftest.c:57:10: fatal error: 'gmp.h' file not found
 40 2014-11-24 13:34:47 <sipa> seems like gcc by default doesn't look in /usr/local/include
 41 2014-11-24 13:34:59 <paveljanik> Try adding /usr/local/include in the -I...
 42 2014-11-24 13:35:31 <paveljanik> CPPFLAGS="-I..." LDFLASG="-L..." ./configure
 43 2014-11-24 13:35:54 <gavinandresen> paveljanik: mmm.  configure is supposed to figure that out for me…. does on my other machine....
 44 2014-11-24 13:35:55 <paveljanik> FLAGS
 45 2014-11-24 13:36:32 <paveljanik> configure doesn't look for gmp.h in /usr/local/include. Maybe on the other system, you have gmp installed in the default location.
 46 2014-11-24 13:37:26 <fanquake> Wouldn’t it find it if it’s also finding boost, protobut etc in the same path?
 47 2014-11-24 13:37:49 <sipa> the libsecp256k1 configure is separate, so maybe not
 48 2014-11-24 13:37:53 <paveljanik> this is "inner" configure.
 49 2014-11-24 13:37:54 <paveljanik> yes
 50 2014-11-24 13:38:02 <gavinandresen> I’ve got an old /opt/local64… wonder if configure gets confused because I have an /opt....
 51 2014-11-24 13:38:27 <sipa> configure doesn't try anything special afaics
 52 2014-11-24 13:38:37 <sipa> it just tries to compile with #include <gmp.h>
 53 2014-11-24 13:38:45 <sipa> but cfields likely knows better
 54 2014-11-24 13:39:29 <sipa> oh it does try /opt/local/include, nvm
 55 2014-11-24 13:41:17 <gavinandresen> coryfields: why is libsecp256 looking for my brew gmp in /opt/local ?
 56 2014-11-24 13:41:53 <sipa> cfields AND coryfields? :o
 57 2014-11-24 13:42:03 <op_null> for what it's worth, I have no /opt/local and it doesn't fail for me.
 58 2014-11-24 13:42:11 <fanquake> I thought he was theuni ?
 59 2014-11-24 13:42:22 <gavinandresen> am I remembering correctly?  brew installs into /usr/local by default?
 60 2014-11-24 13:42:28 <gavinandresen> (and macports is /opt....)
 61 2014-11-24 13:42:46 <op_null> that's correct
 62 2014-11-24 13:43:15 <op_null> homebrews GMP is in /usr/local/Cellar/gmp/{version}
 63 2014-11-24 13:43:36 <gavinandresen> op_null: yup, with symlink /usr/local/include/gmp.h -> ../Cellar/gmp/6.0.0a/include/gmp.h
 64 2014-11-24 13:44:50 <op_null> gavinandresen: yes, that's how mine is configured exactly.
 65 2014-11-24 13:44:58 <paveljanik> I think that configure should not autotest every possible location out there, but leave that on 1. compiler and if it fails, on 2. the user...
 66 2014-11-24 13:45:59 <gavinandresen> paveljanik: whatever the main Bitcoin configure is doing works properly, finding boost/bdb/etc in /usr/local
 67 2014-11-24 13:46:42 <paveljanik> hmm, but that doesn't mean it is correct. It makes bitcoin devs happy, but that is not correct ;-)
 68 2014-11-24 13:46:51 <null> is the genesis block considered height 0 or 1?
 69 2014-11-24 13:47:02 <wumpus> 0
 70 2014-11-24 13:47:52 <paveljanik> imagine you have two gmp's installed and want bitcoind to compile with the second one not the first one in configure's "guess" list..
 71 2014-11-24 13:48:52 <wumpus> paveljanik: well if the user overrides then it shouldn't autodetect of course
 72 2014-11-24 13:49:07 <null> wumpus: thanks
 73 2014-11-24 13:49:32 <paveljanik> wumpus: yes, how does it detect "override"? it is almost impossible...
 74 2014-11-24 13:49:35 <wumpus> lots of trouble with this gmp dependency :/
 75 2014-11-24 13:49:59 <sipa> wumpus: i *can* get rid of it
 76 2014-11-24 13:50:07 <wumpus> paveljanik: usually something like configure --with-gmp-include=/bla/bla --with-gmp-lib=/bla/bla
 77 2014-11-24 13:50:10 <sipa> (for signing)
 78 2014-11-24 13:50:22 <paveljanik> wumpus: usually yes ;-)
 79 2014-11-24 13:50:25 <wumpus> sipa: yes, temporarily
 80 2014-11-24 13:50:33 <sipa> maybe
 81 2014-11-24 13:50:37 <sipa> but yes, most likely
 82 2014-11-24 13:50:54 <sipa> (though i would actually prefer the consensus code not to depend on gmp...)
 83 2014-11-24 13:51:17 <paveljanik> --with-gmp=.... to the toplevel configure, passing to the inner one.
 84 2014-11-24 13:52:22 <wumpus> sipa: indeed
 85 2014-11-24 13:52:46 <wumpus> we get rid of openssl but gain libgmp
 86 2014-11-24 13:53:20 <paveljanik> from the security PoV, that sounds like a huge win! ;-)
 87 2014-11-24 13:53:24 <wumpus> well it's a step forward, numerical functions are better defined at least
 88 2014-11-24 13:53:29 <wumpus> yes
 89 2014-11-24 13:54:48 <sipa> i expect that we'll end up using libgmp only for modular inverses in libsecp256k1, as it's the only performance-critical thing where it beats anything else i've seen massively
 90 2014-11-24 13:54:51 <wumpus> maybe it does make sense to drop the dependency for 0.10, if we can do signing without it, that would delay the build system pain
 91 2014-11-24 13:55:14 <sipa> and at least a modular inverse is trivial to verify
 92 2014-11-24 13:55:28 <sipa> (multiply with the original, and check whether you get 1)
 93 2014-11-24 13:56:28 <wumpus> can't we just take the modular inverse code from libgmp? oh I suppose there's a license issue
 94 2014-11-24 13:57:08 <sipa> wumpus: it's not exactly trivial :)
 95 2014-11-24 13:57:21 <kinlo> does it make sense to copy paste the one function from libgmp?
 96 2014-11-24 13:57:33 <sipa> ... which probably depends on half the codebase
 97 2014-11-24 13:57:45 <hearn> wumpus: are sergio's unit test changes stuck in limbo now?
 98 2014-11-24 13:57:55 <sipa> including several platform-dependent assembly implementations
 99 2014-11-24 13:58:28 <kadoban> Usually that's not a win for eliminating dependencies. You're then rather stuck maintaining the code forever, or going through the pain of ripping it out again from a more up-to-date version down the road (over and over).
100 2014-11-24 13:58:41 <sipa> kadoban: indeed
101 2014-11-24 13:59:57 <wumpus> hearn: no clue, will take a look at that again when the pre-0.10 fuss is over
102 2014-11-24 14:00:02 <hearn> ok
103 2014-11-24 14:00:35 <wumpus> kadoban: agreed, if it means taking over half the codebase it's not a win
104 2014-11-24 14:00:40 <hearn> wumpus: last state seems to be that he broke out a small change that makes tests run as UNITTEST network instead of main, but that introduced an ordering dependency so it got reverted. but his larger changes which break the ordering dependencies and allow tests to be self contained, is stuck because it's too big :)
105 2014-11-24 14:00:42 <hearn> -> deadlock
106 2014-11-24 14:01:46 <wumpus> hearn: I wasn't aware there was an implementation that breaks the ordering dependency
107 2014-11-24 14:02:16 <wumpus> hearn: indeed, the issue was that it made the tests order dependend *or* it lumped tests together which shouldn't be
108 2014-11-24 14:02:52 <wumpus> but if he found a way to keep the unit tests unit tests, that's great
109 2014-11-24 14:03:31 <fanquake> wumpus That yosemite crashing issue isn’t a bitcoin issue. Many apps are having the same problem. Something todo with the trackpad.
110 2014-11-24 14:03:36 <sipa> well isn't there a way to do the setup/teardown before/after every test?
111 2014-11-24 14:03:47 <fanquake> 10.10.2 is only a beta release as well.
112 2014-11-24 14:04:08 <wumpus> fanquake: probably a qt issue at most
113 2014-11-24 14:04:35 <wumpus> fanquake: I also remember there was some guy that managed to crash bitcoin-qt by using a drawing tablet on it in MacOSX
114 2014-11-24 14:05:12 <hearn> sipa: c++ question for you - why is clang unhappy here?
115 2014-11-24 14:05:15 <hearn>         CCoinsViewCache view(fCheckMemPool ? &cvMemPool : pcoinsTip);
116 2014-11-24 14:05:15 <hearn> main.cpp:3527:44: error: incompatible operand types ('CCoinsViewMemPool *' and 'CCoinsViewCache *')
117 2014-11-24 14:05:29 <fanquake> Apparently apple have deprecated something from their NSTouch class. It’s crashing chrome and quite a few apps.
118 2014-11-24 14:05:35 <wumpus> fanquake: https://github.com/bitcoin/bitcoin/issues/4854
119 2014-11-24 14:05:38 <hearn> it seems to be upset because the types in the ternary operator are different, but the c'tor argument is CCoinsView* which is a supertype of both those types
120 2014-11-24 14:05:39 <wumpus> fanquake: okay
121 2014-11-24 14:05:52 <sipa> hearn: i believe that's it
122 2014-11-24 14:06:15 <sipa> hearn: the ternary operator may require both arguments to be the exact same type
123 2014-11-24 14:06:17 <hearn> sipa: why does it matter that the ternary operator has different output types? clang can't notice that they both satisfy the required type?
124 2014-11-24 14:06:23 <hearn> i'm pretty sure such code used to work
125 2014-11-24 14:06:35 <sipa> well both inner types satisfy the outer one
126 2014-11-24 14:06:55 <sipa> you could pass both a mempool or a cache as argument to view, so maybe it doesn't know whether to convert before or after?
127 2014-11-24 14:06:55 <wumpus> fanquake: maintaining a cross-platform gui has sadly nearly become impossible, there's always some new issue, be it macosx, windows or some linux distro....
128 2014-11-24 14:07:02 <sipa> hearn: no, that doesn't make sense
129 2014-11-24 14:07:12 <sipa> hearn: does adding a static_cast on the mempool work?
130 2014-11-24 14:07:34 <wumpus> hmm one of the travis builds compiles with clang; why isn't it a problem there?
131 2014-11-24 14:07:40 <hearn> this is a local patch
132 2014-11-24 14:07:43 <hearn> i'm rebasing getutxo
133 2014-11-24 14:07:44 <wumpus> okay
134 2014-11-24 14:08:05 <hearn> sipa: rewriting it to not use ?: works :(
135 2014-11-24 14:08:12 <hearn> probably casting would work too, yes
136 2014-11-24 14:08:27 <hearn> but then i lose a bit of type safety ... would prefer the more verbose code
137 2014-11-24 14:08:44 <wumpus> indeed
138 2014-11-24 14:09:04 <hearn> i wondered if this was some picky new c++ rule that wasn't previously enforced,but seems we are all equally confused by it :)
139 2014-11-24 14:10:41 <hearn> and we switched to a new qt?
140 2014-11-24 14:10:42 <hearn> ./qt/guiutil.h:199:42: error: no member named 'StyleAnimationUpdate' in 'QEvent'
141 2014-11-24 14:10:42 <hearn>             return (e->type() != QEvent::StyleAnimationUpdate) ? QProgressBar::event(e) : false;
142 2014-11-24 14:10:56 <hearn> docs/build-osx still suggests "brew install qt" is enough, which is what i have .... no pending upgrades, it seems
143 2014-11-24 14:13:08 <wumpus> hearn: https://github.com/bitcoin/bitcoin/pull/5344 solves that; it's a workaround for qt5, but there was no guard
144 2014-11-24 14:14:03 <hearn> ah ha, thanks.
145 2014-11-24 14:14:18 <fanquake> hearn curious, any reason for sticking with qt4? 5 Seems to look a bit better.
146 2014-11-24 14:14:37 <hearn> i was about to ask that. i'm just rebuilding my local Core after a while not doing it. it's not a conscious choice.
147 2014-11-24 14:14:43 <hearn> i just went with whatever my laptop happened to have
148 2014-11-24 14:14:56 <hearn> if the docs told me to upgrade to qt5 i would
149 2014-11-24 14:15:05 <wumpus> you don't need to upgrade to qt5
150 2014-11-24 14:15:14 <wumpus> or at least, you shouldn't have to, this is a build bug
151 2014-11-24 14:16:05 <hearn> heh, now i have the same issue as gavinandresen  with no working bignum
152 2014-11-24 14:16:12 <hearn> hmm. i might give up on this and try again in a few days :)
153 2014-11-24 14:16:17 <fanquake> Doesn’t have to. But as far as I can tell 5 looks nicer. I think hearn was the one who orignally opened the hdpi/retina tickets.
154 2014-11-24 14:16:24 <hearn> yeah probably
155 2014-11-24 14:16:32 <hearn> i don't use the bitcoin-qt gui, so don't really keep up with it
156 2014-11-24 14:16:59 <fanquake> btw, have we dropped 10.6 support?
157 2014-11-24 14:17:13 <wumpus> hearn: --without-gui?
158 2014-11-24 14:18:36 <hearn> yeah that's what i did :)
159 2014-11-24 14:18:40 <hearn> then hit the bignum issue
160 2014-11-24 14:19:27 <sipa> bignum issue?
161 2014-11-24 14:19:33 <wumpus> The Bignum Issue
162 2014-11-24 14:19:35 <sipa> ah, right
163 2014-11-24 14:19:41 <sipa> the gmp thing
164 2014-11-24 14:19:53 <hearn> yeah
165 2014-11-24 14:20:09 <sipa> let's see how hard it is to compile libsecp256k1 in no-gmp mode
166 2014-11-24 14:20:27 <sipa> or rather, be able to strip it down enough to not require gmp
167 2014-11-24 14:21:35 <jgarzik_> what's the issue?  gmp not available on all platforms?
168 2014-11-24 14:22:42 <wumpus> it is, but an additional dependency always gives a lot of build system fun
169 2014-11-24 14:23:17 <wumpus> people have it installed but it's just not using it
170 2014-11-24 14:33:58 <sipa> hmm, getting rid of gmp would be pretty ugly without replacement
171 2014-11-24 14:34:06 <sipa> as it also means removing most of the unit tests
172 2014-11-24 14:34:19 <hearn> probably easier to fix the build system :)
173 2014-11-24 14:34:27 <sipa> that needs to happen anyway
174 2014-11-24 14:34:38 <sipa> and is likely less work (but more edge cases to work through...)
175 2014-11-24 14:35:26 <hearn> i guess gavin is already on the case
176 2014-11-24 14:36:18 <gavinandresen> hearn: … no, I’m going to wait for cfields to chime in. In the meantime, I’m walking to my office to work for the rest of the day, my tree there works (or did on Friday)
177 2014-11-24 14:36:30 <hearn> ah ok
178 2014-11-24 14:36:40 <hearn> sounds like a plan :)
179 2014-11-24 14:36:42 <wumpus> gavinandresen: do you need the last commit id before the gmp merge?
180 2014-11-24 14:36:52 <gavinandresen> wumpus: nope
181 2014-11-24 14:36:53 <wumpus> s/gmp/secp256k1/
182 2014-11-24 14:37:33 <sipa> we can make libsecp256k1 optional of course... but that's added complexity on bitcoin's side of the configuration + options to test
183 2014-11-24 14:37:51 <wumpus> nah...
184 2014-11-24 14:37:53 <gavinandresen> fixing the build issue is the right answer.
185 2014-11-24 14:38:18 <gavinandresen> libsecp256k1 shouldn’t be looking for things in /opt …
186 2014-11-24 14:38:35 <jgarzik_>  /mining.bitcoinaffiliatenetwork.com awest1:0.9.99/
187 2014-11-24 14:38:37 <jgarzik_> that's a new one
188 2014-11-24 14:38:58 <jgarzik_> RE /opt, that's the default for some platforms
189 2014-11-24 14:38:58 <op_null> jgarzik_: I've seen them for a while now, not totally new.
190 2014-11-24 14:39:39 <op_null> not joking, they have a different user agent for every one of their nodes in different DCs.
191 2014-11-24 14:40:43 <op_null>  /mining.bitcoinaffiliatenetwork.com singapore:0.9.99/ /mining.bitcoinaffiliatenetwork.com amsterdam2:0.9.99/ /mining.bitcoinaffiliatenetwork.com - nyiix2:0.9.99/
192 2014-11-24 14:42:08 <op_null> 22 in total.
193 2014-11-24 14:42:44 <jgarzik_> sigh.  the p2p net will devolve to 200 mining nodes, each of which has 199 connections to the remainder
194 2014-11-24 14:46:55 <op_null> jgarzik_: and /Snoopy0.1/ connected to every single one of them in 100ms long bursts.
195 2014-11-24 14:47:17 <wumpus> I was about to say, plus 200 crawlers
196 2014-11-24 14:48:03 <op_null> and /BQS/ will connect, push another invalid signed transaction and get 100 DoS ban score, then panic when everybody on the network has them blacklisted.
197 2014-11-24 15:16:00 <cfields> eh? i'm all lit up this morning, that can't be good
198 2014-11-24 15:18:26 <cfields> ah. sipa: looks like we need a cleaned up version of this: https://github.com/bitcoin/secp256k1/pull/97#commitcomment-8544296
199 2014-11-24 15:19:11 <cfields> i'll clean up, test on my macbook, and PR
200 2014-11-24 15:22:54 <op_null> cfields: ping me when you do and I'll test it too.
201 2014-11-24 15:23:33 <cfields> ok
202 2014-11-24 15:37:11 <cfields> op_null: is your libgmp keg-only
203 2014-11-24 15:37:14 <cfields> ?
204 2014-11-24 15:37:54 <op_null> cfields: no.
205 2014-11-24 15:38:06 <cfields> nm, that was easy to force (assuming that did what i think it did)
206 2014-11-24 15:38:15 <cfields> i ran 'brew unlink gmp'
207 2014-11-24 15:38:39 <op_null> yes, I think that will do what you think.
208 2014-11-24 15:40:46 <wumpus> those macosx users with their bottles and kegs :)
209 2014-11-24 15:42:19 <cfields> yea :\
210 2014-11-24 15:43:54 <op_null> I don't have any problem with homebrew. I don't like that they package their binaries by default, but that's easy to change. I've had considerably more luck with homebrew than I ever did with macports, but mixing the two is asking for trouble.
211 2014-11-24 15:45:35 <wumpus> I don't have any problem with homebrew either, I've never used any of the macosx build systems, but the names are funny
212 2014-11-24 15:46:32 <cfields> as much of a pain as it is, i actually like the problems that it brings to the surface
213 2014-11-24 15:47:00 <cfields> if it works when every package is keg-only, then you know that all paths are accounted for
214 2014-11-24 15:47:10 <op_null> wumpus: I like Handbrake for the same reason. "put down that cocktail.."
215 2014-11-24 15:52:47 <wumpus> hehe
216 2014-11-24 16:14:34 <cfields> op_null: https://github.com/theuni/secp256k1/commit/5bd90439b1d3ec729d1f980ac57742b8e884a7b4
217 2014-11-24 16:16:06 <cfields> op_null: that worked for me to build, but the runtime tests weren
218 2014-11-24 16:16:27 <cfields> *weren't quite right. i'm hoping that's because the unlink didn't do exactly what i wanted
219 2014-11-24 16:16:31 <cfields> worked fine when linked, obviously
220 2014-11-24 16:18:12 <op_null> ?
221 2014-11-24 16:18:22 <op_null> seems fine to me.
222 2014-11-24 16:19:01 <cfields> thanks for testing
223 2014-11-24 16:23:23 <HM> the cryptocat guy is working on a new project and seems to have adopted a random pidge-podge of crypto, including use tweetnacl, and base58 encoded public keys using a 1 byte checksum
224 2014-11-24 16:23:32 <cfields> wumpus: note that #4727 doesn't change anything in the dmg related to bitcoind...
225 2014-11-24 16:24:15 <cfields> wumpus: so to get bitcoind in the wild, we'll need to tweak the release process a bit so that it makes it into the release dir structure somewhere
226 2014-11-24 16:24:20 <wumpus> cfields: I don't think bitcoind belongs in the dmg, most people want a separate bitcoind
227 2014-11-24 16:24:31 <wumpus> right
228 2014-11-24 16:24:59 <cfields> sure, agreed. just pointing out that the PR only dumps it outside of gitian, we'll still need to do something with it
229 2014-11-24 16:25:53 <cfields> gavinandresen: in case you missed the github ping: https://github.com/bitcoin/secp256k1/pull/115
230 2014-11-24 16:30:32 <gavinandresen> cfields: won’t be able to test until I’m back home
231 2014-11-24 16:31:15 <cfields> gavinandresen: ok. same for osx signing, i guess? I've got that ready for testing now
232 2014-11-24 16:32:01 <gavinandresen> cfields: code signing I can do, email me instructions
233 2014-11-24 16:33:05 <sipa> gavinandresen: i'll merge #115 if you ACK, and PR an updated secp256k1 to bitcoin
234 2014-11-24 16:33:15 <cfields> gavinandresen: ok. it requires osx mavericks+ (for signing) and linux/gitian (for applying). you have both at your disposal?
235 2014-11-24 16:33:48 <sipa> oh the irony:
236 2014-11-24 16:33:54 <sipa> cd depends && make
237 2014-11-24 16:33:57 <sipa> Fetching openssl...
238 2014-11-24 16:33:57 <sipa> Unable to establish SSL connection.
239 2014-11-24 16:34:14 <gavinandresen> cfields: mavericks is 10.9?  yosemite is 10.10?
240 2014-11-24 16:34:21 <cfields> sipa: heh, i saw that the other day, wasn't sure if it was a fluke
241 2014-11-24 16:34:26 <cfields> gavinandresen: yea
242 2014-11-24 16:34:37 <gavinandresen> cfields: yes, running 10.9 here at the office, 10.10 at home.
243 2014-11-24 16:34:38 <hearn> HM: yeah mean nadim / minilock?
244 2014-11-24 16:34:42 <cfields> sipa: bad cert, root vs www ?
245 2014-11-24 16:34:50 <sipa> no clue
246 2014-11-24 16:35:02 <cfields> sipa: looking into that now, i guess it's not a one-off thing
247 2014-11-24 16:35:07 <cfields> gavinandresen: ok, will mail you. thanks.
248 2014-11-24 16:35:25 <op_null> cfields: I still wish they stuck with OSX Rancho Cucamonga or OSX Weed as the codename. least I can pronounce them properly.
249 2014-11-24 16:35:39 <cfields> heh
250 2014-11-24 16:36:17 <sipa> wget --timeout=10 --tries=3 -nv -O /home/pw/git/bitcoin/depends/work/build/x86_64-unknown-linux-gnu/openssl/1.0.1j-d7442311b26/openssl-1.0.1j.tar.gz.temp https://www.openssl.org/source/openssl-1.0.1j.tar.gz
251 2014-11-24 16:36:21 <sipa> cfields: ^ cmdline
252 2014-11-24 16:37:54 <hearn> op_null: it's pronounced yo-sem-it-ee
253 2014-11-24 16:38:23 <cfields> sipa: hmm, working for me
254 2014-11-24 16:38:26 <op_null> hearn: in my head it'll always be yos-mite though :(
255 2014-11-24 16:38:31 <op_null> sipa: ditto.
256 2014-11-24 16:38:37 <cfields> sipa: a few days ago, the upstream site was down
257 2014-11-24 16:38:48 <sipa> hearn: yeah, it's as intuitive as arkansas
258 2014-11-24 16:38:57 <hearn> i *still* get that one wrong!
259 2014-11-24 16:38:59 <cfields> sipa: and at the same time, it looked like our ssl cert was misconfigured
260 2014-11-24 16:39:16 <cfields> but it seems both are working correctly on my end now
261 2014-11-24 16:39:29 <sipa> hearn: well, you're probably pronouncing it right if you're talking about the arkansas river in kansas
262 2014-11-24 16:41:15 <HM> hearn, yeah
263 2014-11-24 16:41:29 <HM> hearn, using BLAKE2 to output 1 byte for the base58 encoded public key
264 2014-11-24 16:41:35 <cfields> sipa: can you try again without the -nv and see if there's anything obvious?
265 2014-11-24 16:41:37 <hearn> HM: four bytes of checksum in bitcoin addresses is probably overkill though. so why is that a big deal?
266 2014-11-24 16:41:37 <HM> seems a bit...overkill
267 2014-11-24 16:42:14 <hearn> HM: and is there a known issue with tweetnacl? i'd think using nacl is the right thing to do, but nadim is constrained by his choice of chrome as the app platform
268 2014-11-24 16:42:20 <hearn> the UI is cool though. i tried it, it's pretty easy to use
269 2014-11-24 16:43:15 <HM> I feel bad for the guy, he was attacked a lot when cryptocat was shown to be terrible
270 2014-11-24 16:43:38 <sipa> cfields: uh, it just worked now
271 2014-11-24 16:43:47 <sipa> i even missed it
272 2014-11-24 16:44:15 <cfields> sipa: heh, ok. like i said, their site was down a few days ago (friday?), so maybe they're having some hosting issues still
273 2014-11-24 16:44:34 <sipa> still, having SSL errors on openssl.org is ironic...
274 2014-11-24 16:45:06 <cfields> heh
275 2014-11-24 16:45:27 <wumpus> heh yes
276 2014-11-24 16:46:09 <sipa> HM: it's just silly; it should be a CRC
277 2014-11-24 16:46:13 <HM> hearn, there are Damm groups for protecting transposition and single digit errors up to base 64 linked on Wikipedia. I think it'd be interesting to see which approach would catch the most typos
278 2014-11-24 16:46:23 <HM> *character, not digit
279 2014-11-24 16:46:44 <sipa> constructing a base 58 CRC would be nice :p
280 2014-11-24 16:47:02 <sipa> ... then again, why would you use base58 except for compatibility with bitcoin or flickr?
281 2014-11-24 16:47:18 <HM> that's something else that bothered me
282 2014-11-24 16:47:43 <HM> using tweetnacl because it's small, then having to ship bigint code to do base conversion anyway
283 2014-11-24 16:47:48 <op_null> sipa: I'll write up a BIP for Emoji encoded addresses. less characters!
284 2014-11-24 16:48:58 <sipa> we need a native encoding in PNGs
285 2014-11-24 16:49:39 <op_null> dialup modem v92 encoded addresses?
286 2014-11-24 16:50:00 <sipa> we're probably going a bit offtopic here - sorry :)
287 2014-11-24 16:50:11 <op_null> me too.
288 2014-11-24 17:04:34 <sipa> gah, git clean -dfx also wipes depends, of course...
289 2014-11-24 17:05:02 <wumpus> yes it does; I've linked that stuff from another directory because of that
290 2014-11-24 17:05:59 <cfields> sipa: it respects $BASE_CACHE if you want to run out-of-tree
291 2014-11-24 17:06:22 <sipa> setting the cache path out of tree probably makes sense, yes :)
292 2014-11-24 17:06:34 <cfields> $SOURCES_PATH as well
293 2014-11-24 17:06:54 <cfields> looking at those out of context, they would've been prefixed with DEPENDS_ or so :\
294 2014-11-24 17:07:01 <cfields> *should've
295 2014-11-24 18:35:36 <michagogo> cfields: https://github.com/bitcoin/bitcoin/issues/4854#issuecomment-54700554 <-- Uh, that means "run it in on a whole separate airgapped machine that you nuke afterwards"
296 2014-11-24 18:35:59 <michagogo> If you actually were doing that, it could be anything
297 2014-11-24 18:36:15 <cfields> hmm?
298 2014-11-24 18:36:22 <michagogo> including a new worm that exploits zero-days to spread across the globe, Stuxnet-like
299 2014-11-24 18:36:30 <michagogo> and steals bitcoins
300 2014-11-24 18:36:38 <sipa> a VM without network access may be enough :)
301 2014-11-24 18:37:05 <cfields> michagogo: i was only implying that he shouldn't be running random binaries, and should be aware of the implications
302 2014-11-24 18:37:13 <michagogo> cfields: I know :P
303 2014-11-24 18:38:09 <michagogo> Actually
304 2014-11-24 18:38:18 <michagogo> I suspect a VM might make it *easier* to test
305 2014-11-24 18:38:45 <michagogo> Since, at least last time I checked, Virtualbox gives the guest OS an emulated USB tablet by defaul
306 2014-11-24 18:38:45 <michagogo> t
307 2014-11-24 18:39:09 <michagogo> To avoid having to do cursor capture, even without the guest additions installed
308 2014-11-24 18:40:06 <kanzure> hmm, compare:
309 2014-11-24 18:40:07 <kanzure> https://github.com/bitcoin/bitcoin/blob/master/contrib/bitrpc/bitrpc.py
310 2014-11-24 18:40:10 <kanzure> https://github.com/petertodd/python-bitcoinlib/blob/master/bitcoin/rpc.py
311 2014-11-24 18:41:42 <sipa> kanzure: what should i notice when comparing?
312 2014-11-24 18:41:47 <kanzure> code quality
313 2014-11-24 18:41:59 <kanzure> prints everywhere
314 2014-11-24 18:42:04 <kanzure> hardcoded passwords
315 2014-11-24 18:42:51 <kanzure> and why not just use https://github.com/bitcoin/bitcoin/tree/master/qa/rpc-tests/python-bitcoinrpc
316 2014-11-24 18:43:08 <english-> hey folks..... newbie question here. Is there an example within the code that converts from a RIPEMD160 hash of the public key to the bitcoin address in standard format?
317 2014-11-24 18:43:31 <kanzure> does anyone even use bitrpc.py?
318 2014-11-24 18:43:38 <sipa> no clue
319 2014-11-24 18:43:56 <kanzure> python-bitconlib and python-bitcoinrpc are much better, and python-bitcoinrpc is even included already
320 2014-11-24 18:49:15 <gavinandresen> kanzure: I don’t think anybody is using contrib/bitrpc. Submit a pull request to fix it or get rid of it.
321 2014-11-24 18:50:19 <kanzure> is bitrpc something that is desirable to maintain in this repo
322 2014-11-24 18:50:31 <kanzure> i mean something that serves the same purpose as bitrpc
323 2014-11-24 18:57:48 <wumpus> we're pointing people at bitrpc if they want to enter the passphrase securely (ie, not on the command line)
324 2014-11-24 18:58:01 <wumpus> if there's an alternative solution for that I'm fine with getting rid of it
325 2014-11-24 19:06:49 <kanzure> oh interesting
326 2014-11-24 19:06:57 <kanzure> i'll have to think about that use case then.
327 2014-11-24 19:12:03 <wumpus> the biggest annoying about bitrpc is that it can't parse the bitcoin.conf, so you indeed have to edit it to provide the rpc user/password
328 2014-11-24 19:13:23 <kanzure> wumpus: approximately how bad would it be to tell people "just use python-bitcoinlib bitcoin.rpc.Proxy"? (python3 only)
329 2014-11-24 19:13:39 <kanzure> (which does parse the conf file)
330 2014-11-24 19:13:50 <wumpus> it needs to be usable from the command line
331 2014-11-24 19:14:07 <wumpus> and python-bitcoinlib is not part of our repository, so it's not really an option
332 2014-11-24 19:14:22 <kanzure> okay.
333 2014-11-24 19:15:04 <wumpus> it'd be quite trvial to write a python script that does just that, but I don't really have time to do it
334 2014-11-24 19:15:06 <kanzure> i suppose something can be added to python-bitcoinrpc
335 2014-11-24 19:15:28 <kanzure> and, if that is done, then python-bitcoinlib should probably move its own stuff into python-bitcoinrpc and just use that
336 2014-11-24 19:15:32 <kanzure> for non-code-duplication reasons
337 2014-11-24 19:15:51 <kanzure> (esp. since python-bitcoinrpc is already being included in bitcoin.git)
338 2014-11-24 19:16:30 <wumpus> meh
339 2014-11-24 19:16:34 <Luke-Jr> this really shouldn't be part of the master repository..
340 2014-11-24 19:17:02 <Luke-Jr> side note: I like that bitcoin-cli is C and not Python (but I wouldn't be upset if we dropped it)
341 2014-11-24 19:17:03 <kanzure> bitcoin-cli and bitcoin-tx cover this use case i think
342 2014-11-24 19:17:18 <kanzure> oh
343 2014-11-24 19:17:20 <wumpus> there's so much that shouldn't be part of the bitcoin repository, please move out the wallet first if you're going that way ...
344 2014-11-24 19:17:47 <wumpus> let's not make a fuss about a few silly python script
345 2014-11-24 19:17:48 <Luke-Jr> wumpus: that's more complex than simply not adding more ;)
346 2014-11-24 19:18:13 <wumpus> it can use the same bitcoinrpc as used by the tests, we need that anyway
347 2014-11-24 19:18:49 <wumpus> and no, we're not going to get rid of bitcoin-cli, that makes no sense
348 2014-11-24 19:23:09 <wumpus> you could also add an option to bitcon-cli to ask for the passphrase, that'd also satisfy the use case, but only if that can be done in a platform independent way without introducing extra dependencies or mountains of code
349 2014-11-24 19:28:35 <kanzure> what, can't vendorize the readline source tree?
350 2014-11-24 19:30:47 <wumpus> heh
351 2014-11-24 19:41:39 <cfields> gavinandresen: to test signing, do you have a linux box handy? or will you be using gitian?
352 2014-11-24 19:43:56 <gavinandresen> cfields: I can fire up a linux VM, I don’t have any native Linux boxes.
353 2014-11-24 19:44:12 <cfields> ok
354 2014-11-24 19:51:22 <kanzure> where in bitcoind are double spends or mutated transactions detected?
355 2014-11-24 19:51:59 <kanzure> er, specifically, the part about invalidating a prior-mempool-seen tx that spends some outputs, because a block has shown up that spends those outputs differently
356 2014-11-24 19:52:50 <dgenr8> txmempool::remove and similar
357 2014-11-24 19:55:22 <kanzure> thank you
358 2014-11-24 20:08:03 <paveljanik> reading compat.h, what is the login behind this:
359 2014-11-24 20:08:04 <paveljanik> #define _WIN32_WINNT 0x0501
360 2014-11-24 20:08:04 <paveljanik> #endif
361 2014-11-24 20:08:04 <paveljanik> #ifdef _WIN32_WINNT
362 2014-11-24 20:08:04 <paveljanik> #undef _WIN32_WINNT
363 2014-11-24 20:08:34 <paveljanik> why not undef it directly and define afterwards?
364 2014-11-24 20:09:02 <paveljanik> is there any preprocessor warning when undefining undefined?
365 2014-11-24 20:09:21 <paveljanik> s/login/logic/
366 2014-11-24 20:30:20 <wumpus> no, there is a preprocessor warnign when redefining defined
367 2014-11-24 20:31:50 <wumpus> not the other way around on gcc, but maybe on some compilers
368 2014-11-24 20:42:26 <cfields> erm: https://github.com/bitcoin/bitcoin/commit/225f222c9fba7a831e2e5f80ccbba34ed2bca532
369 2014-11-24 20:42:41 <cfields> is that some C trick that i've never seen, used to shut the compiler up?
370 2014-11-24 20:43:06 <cfields> or just busted code?
371 2014-11-24 20:46:13 <sipa> why would it be busted?
372 2014-11-24 20:46:25 <paveljanik> you have to evaluate all enums or have default, yes.
373 2014-11-24 20:47:38 <cfields> sipa: address of a c string won't ever evaluate to 0, no?
374 2014-11-24 20:48:02 <sipa> cfields: unless it's passed as a pointer, and that pointer is null
375 2014-11-24 20:48:13 <sipa> but the address of an array is never NULL
376 2014-11-24 20:48:53 <cfields> sipa: right. so that code looks to me to be: assert(true)
377 2014-11-24 20:49:09 <sipa> aaaah
378 2014-11-24 20:49:21 <sipa> see the ! in front
379 2014-11-24 20:49:56 <rnvk> Hi Guys, we've put together this python tool to sign a proposed multisig transaction (P2SH spend). Maybe it can be useful to others here, https://github.com/coinkite/offline-multisig-python
380 2014-11-24 20:51:48 <cfields> sipa: heh, not sure how i managed to reverse that in my head. still though, isn't that just logically assert(false) ?
381 2014-11-24 20:53:59 <sipa> yes, but it also prints a nicer message :)
382 2014-11-24 20:55:22 <cfields> ok, there's my answer, thanks
383 2014-11-24 21:30:42 <melvster> how many blocks must be mined before coinbase coins are spendable?
384 2014-11-24 21:30:50 <Luke-Jr> 100
385 2014-11-24 21:31:29 <melvster> Luke-Jr: thanks