1 2015-01-20 07:20:34 <midnightmagic> ;;later tell gdm85 I managed to get the equivalent of the hashes, and then, using KVM, build a conforming build. There were few if any meaningful diffs. uname, etc..
  2 2015-01-20 07:20:35 <gribble> The operation succeeded.
  3 2015-01-20 08:16:41 <jonasschnelli> cfields, arround?
  4 2015-01-20 08:23:06 <cfields> jonasschnelli: just for a min
  5 2015-01-20 08:23:26 <jonasschnelli> cfields, okay.... but worked it out. :)
  6 2015-01-20 08:23:38 <cfields> jonasschnelli: heh, sure?
  7 2015-01-20 08:23:53 <jonasschnelli> cfields, i first tough we need a DS_Store update..
  8 2015-01-20 08:25:03 <cfields> jonasschnelli: we do, but only after your changes
  9 2015-01-20 08:25:57 <jonasschnelli> cfields, but i saw that you updated DS_Store to make use of the new tiff
 10 2015-01-20 08:25:59 <jonasschnelli> nice!
 11 2015-01-20 08:26:28 <cfields> jonasschnelli: right, those commits are meant to go on top of your changes
 12 2015-01-20 08:26:43 <jonasschnelli> cfields, so then i pull those in
 13 2015-01-20 08:28:06 <cfields> jonasschnelli: yep. they don't necessarily have to go in the same PR, but after the change to .tiff, gitian builds will be broken until the DS_Store changes that go with it
 14 2015-01-20 08:29:22 <jonasschnelli> cfields do you know why there is a merge commit?
 15 2015-01-20 08:29:23 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/5683/commits
 16 2015-01-20 08:30:17 <cfields> jonasschnelli: because we didn't branch from the same point. easiest thing would just be to cherry-pick em
 17 2015-01-20 08:30:43 <jonasschnelli> cfields, okay, will cherry pick and force push again
 18 2015-01-20 08:31:09 <jonasschnelli> cfields, sdks 10.9 fails on my gitian: https://bitcoin.jonasschnelli.ch/pulls/5684/build-osx.log
 19 2015-01-20 08:32:24 <cfields> jonasschnelli: unsure. your sdk is good? It passes travis and builds fine in gitian for me
 20 2015-01-20 08:32:57 <jonasschnelli> cfields, hmm.. just forged the 10.9 sdk but will do again and report in the PR as comment.
 21 2015-01-20 08:35:20 <cfields> jonasschnelli: your packages didn't rebuild. Something's not right. Sure you're building from current master?
 22 2015-01-20 08:35:44 <jonasschnelli> cfields, will check
 23 2015-01-20 08:36:03 <cfields> the SDK bump should cause all packages to rebuild
 24 2015-01-20 08:37:08 <jonasschnelli> cfields, i do a 'git checkout master; git reset --hard origin/master; before building.
 25 2015-01-20 08:38:56 <cfields> jonasschnelli: but you're doing "./gbuild -c bitcoin=f0172bf9 ..." or so?
 26 2015-01-20 08:39:31 <jonasschnelli> ./bin/gbuild --commit bitcoin=master ...
 27 2015-01-20 08:39:34 <jonasschnelli> cfields,
 28 2015-01-20 08:40:08 <cfields> and master is what's currently checked out?
 29 2015-01-20 08:40:39 <jonasschnelli> cfields, hmm,... no i pulled the PR also
 30 2015-01-20 08:40:43 <cfields> (not what HEAD is reset to, i mean the active local branch)
 31 2015-01-20 08:40:47 <jonasschnelli> cfields, thats probably the issue!
 32 2015-01-20 08:41:21 <jonasschnelli> cfields so should i get the git HEAD sha after pulling the pull-request and use this for gbuild --commit=?
 33 2015-01-20 08:41:49 <cfields> jonasschnelli: i prefer to do that, yes, so i'm 100% sure of what commit it's building
 34 2015-01-20 08:42:08 <jonasschnelli> cfields, okay, will try now
 35 2015-01-20 08:42:59 <cfields> jonasschnelli: i'll fix up the osx build to work with proper SDKs tomorrow, so you won't have to use gitian for your auto builds anymore
 36 2015-01-20 08:43:18 <cfields> (unless you'd just prefer to, of course)
 37 2015-01-20 08:47:37 <cfields> nnite
 38 2015-01-20 08:47:49 <wumpus> nn cfields
 39 2015-01-20 08:48:15 <cfields> wumpus: that ssl error is a head-scratcher
 40 2015-01-20 08:48:45 <wumpus> cfields: yes, very weird. Must be an interaction between bitcoin's built-in openssl and qt's/the systems
 41 2015-01-20 08:48:49 <cfields> i'm a bit nervous that it will point out something stupid we've been doing all along
 42 2015-01-20 08:48:52 <wumpus> cfields: but I don't see how I introduced it.
 43 2015-01-20 08:48:55 <jonasschnelli> cfields, hmm.. get `block in <main>': error looking up commit for tag f0172bf91ef521a0155cf1f0ae9fde1ab02157b3 (RuntimeError)
 44 2015-01-20 08:49:05 <jonasschnelli> but will work it out.. have some rest.
 45 2015-01-20 08:49:18 <wumpus>   are the tests built with reduced visibility for symbols?
 46 2015-01-20 08:49:41 <wumpus> anyhow, get some sleep, I'll do some testing here
 47 2015-01-20 08:49:44 <cfields> wumpus: yes. did you see my latest comment? more data points
 48 2015-01-20 08:50:16 <wumpus> yep I saw, now trying to reproduce locally
 49 2015-01-20 08:51:54 <cfields> wumpus: oh, i bet i know... openssl is disabled in our qt4 build
 50 2015-01-20 08:52:09 <cfields> enabled in qt5 and system qt, though
 51 2015-01-20 08:52:55 <wumpus> cfields: but we don't actually use our qt4 build; but it may reflect in the headers somehow
 52 2015-01-20 08:54:55 <cfields> wumpus: right. well, i insisted on that, so i'll hunt it down. Don't burn your time on it :)
 53 2015-01-20 08:54:58 <wumpus> ah, after doing a 32-bit build w/ depends I get it locally now
 54 2015-01-20 08:55:43 <cfields> wumpus: it happens on 64bit too. the 32bit travis build is the only one that runs against qt4
 55 2015-01-20 08:56:13 <wumpus> ok, yes I was just replicating the travis build, at least good  to see that it's not some vague issue that only happens on travis
 56 2015-01-20 08:56:33 <wumpus> but indeed I saw in your post that it happens on 64-bit too
 57 2015-01-20 08:56:49 <cfields> yes. also, travis does an LD_PRELOAD to use our self-built libs, but the issue still happens when using the system libs at runtime
 58 2015-01-20 08:57:17 <cfields> so it seems it has to do with compile/link rather than runtime loading
 59 2015-01-20 08:58:05 <wumpus> yes
 60 2015-01-20 09:00:31 <wumpus> cfields: how can that LD_PRELOAD ever have worked, if our built qt4 has no openssl support
 61 2015-01-20 09:01:12 <cfields> wumpus: ah, i lied, it does use our openssl
 62 2015-01-20 09:02:34 <cfields> wumpus: really, i'll track it down tomorrow. it must be a stupid build thing :)
 63 2015-01-20 09:03:08 <wumpus> ldd against src/qt/test/test_bitcoin doesn't show any linking against libssl/libcrypto
 64 2015-01-20 09:04:23 <cfields> depends builds static, so qt's network lib is linked against static libssl
 65 2015-01-20 09:05:03 <wumpus> that can't be - this is *dynamic* qt
 66 2015-01-20 09:05:29 <cfields> at runtime, yes
 67 2015-01-20 09:06:07 <wumpus> ldd shows the run-time shared library dependencies (including dependencies of dependencies)
 68 2015-01-20 09:06:11 <cfields> oh i see what you mean. yes, that's strange
 69 2015-01-20 09:06:31 <wumpus> unless, of course, the dl API is used to load at runtime, but that's not what I mean (and I doubt qt does that for ssl?)
 70 2015-01-20 09:07:39 <cfields> i don't believe so, otherwise they wouldn't require a link against -lssl
 71 2015-01-20 09:11:17 <wumpus> meh, readelf -a /usr/lib/i386-linux-gnu/libQtNetwork.so.4|grep NEEDED   doesn't show an openssl or crypto dependency either. So this may be a false track.
 72 2015-01-20 09:13:10 <wumpus> anyhow, I'll leave this to you tomorrow, nn
 73 2015-01-20 09:14:10 <cfields> nnite
 74 2015-01-20 09:14:38 <cfields> wumpus: feel free ofc, i'm just trying to take the time-sink off your hands
 75 2015-01-20 10:41:16 <cfields> wumpus: heh, got it
 76 2015-01-20 10:41:49 <cfields> wumpus: boost was the real culprit. qt was fixing by accident...
 77 2015-01-20 10:42:26 <cfields> wumpus: http://pastebin.com/raw.php?i=L3LPnGwr
 78 2015-01-20 10:42:28 <wumpus> cfields: hah
 79 2015-01-20 10:42:58 <cfields> boost inits openssl statically as soon as you include asio
 80 2015-01-20 10:43:02 <wumpus> yes, that makes sense.
 81 2015-01-20 10:43:33 <wumpus> nice catch!
 82 2015-01-20 10:44:34 <cfields> we'll need to be careful about how we handle that, if we're switching openssl around
 83 2015-01-20 10:44:41 <cfields> now i can sleep in peace :). nnite
 84 2015-01-20 10:45:23 <wumpus> right - it's kinda strange though, you'd assume qt initializes openssl too
 85 2015-01-20 10:45:48 <wumpus> but we also use openssl directly, which probably is inadvance of qt's use
 86 2015-01-20 10:46:37 <wumpus> well anyhow, thanks for chasing this down, nnite
 87 2015-01-20 11:32:20 <aschildbach_> ;;help
 88 2015-01-20 11:32:20 <gribble> The bot responds when you start a line with the ! character. A good starting point for exploring the bot is the !facts command. You can also visit the bot's website for a list of help topics and documentation: http://gribble.sourceforge.net/
 89 2015-01-20 11:32:34 <aschildbach_> !facts
 90 2015-01-20 11:32:35 <gribble> To see a nice sortable web view of all factoids, click here: http://gribble.dreamhosters.com/viewfactoids.php?db=%23bitcoin-dev || To see a list of the most popular factoids, run !rank || To search factoids, run !factoids search <yoursearchterm>
 91 2015-01-20 11:33:03 <aschildbach_> !factoids search aschildbach
 92 2015-01-20 11:33:04 <gribble> No keys matched that query.
 93 2015-01-20 11:33:16 <hearn> :(
 94 2015-01-20 11:33:22 <hearn> we need some aschildbach facts!
 95 2015-01-20 11:33:36 <aschildbach_> hearn: I was search for a search function
 96 2015-01-20 11:33:58 <aschildbach_> because my irc client told me somebody has said something to me but it already scrolled away
 97 2015-01-20 11:34:27 <hearn> i think you can search google for this:     site:bitcoinstats.com/irc/bitcoin-dev/logs/2015/01 aschildbach
 98 2015-01-20 11:36:58 <aschildbach_> If Dekker3D happens to come back, tell him/her to mail me I have some info for him regarding wallet integration on Android.
 99 2015-01-20 11:44:14 <aschildbach_> hearn: congrats for the public beta!
100 2015-01-20 11:44:24 <hearn> thanks!
101 2015-01-20 11:44:32 <hearn> it took .... longer than expected. but that's software for you :)
102 2015-01-20 11:44:57 <hearn> once the bug reports from public beta slow down and are fixed, i plan to spend a bit of time on sync time optimisation for bitcoinj
103 2015-01-20 11:45:03 <hearn> what have you been up to lately?
104 2015-01-20 11:49:17 <bedeho> hearn: yeah, it looks amazing, I will definitively use it for my project (assuming you are ok with that)
105 2015-01-20 11:49:45 <hearn> bedeho: of course! it's an app, do what you like with it
106 2015-01-20 11:51:54 <bedeho> hearn: great, Im going to do a traditinal crowdfunding campaign on indiegogo as well, and then use lighthouse as a BitCoin complement, which is perfect, since indiegogo does not support BitCoin.
107 2015-01-20 11:52:34 <hearn> sure.
108 2015-01-20 11:56:42 <michagogo> hearn: did you end up finding a solution for the "excess contributions go to fees" problem?
109 2015-01-20 11:57:04 <michagogo> (I seem to remember that being brought up at some early point in the discussion)
110 2015-01-20 11:57:24 <hearn> the app doesn't let you over-pledge.
111 2015-01-20 11:57:52 <michagogo> But how can you know that it's fully pledged?
112 2015-01-20 11:58:08 <michagogo> (if pledges aren't immediately being uploaded to a server that maintains them)
113 2015-01-20 12:00:16 <hearn> for server-assisted projects, they are being uploaded immediately to a server that maintains them. for serverless project the app will tell you to delete pledges if you gather too many. you are responsible for making sure the jigsaw pieces fit, at the moment, though a feature to constrain pledges to multiples of a certain amount is certainly an important feature for improving usability of this mode
114 2015-01-20 12:01:43 <michagogo> 
ACTION wonders if there's any case where deliberately including too many pledges would be incentivized

115 2015-01-20 12:02:15 <michagogo> Also, I kinda feel like that's a flaw of the system, not allowing you to exceed the target
116 2015-01-20 12:02:23 <michagogo> I mean, I understand why that has to be the case
117 2015-01-20 12:03:07 <hearn> well, it's arguable. if projects can exceed the target you can end up with kickstarter potato salad type fiascos
118 2015-01-20 12:03:10 <hearn> not sure if you saw that one
119 2015-01-20 12:03:17 <michagogo> I did :P
120 2015-01-20 12:03:27 <michagogo> And yeah, it's true
121 2015-01-20 12:03:34 <michagogo> Too much success can also be a bad thing
122 2015-01-20 12:04:04 <michagogo> Besides silly ones like the potato salad, I think I've heard ofprojects that made e.g. production plans
123 2015-01-20 12:04:13 <hearn> there is a feature request open to switch from pledging to donations, once a project is fully funded
124 2015-01-20 12:04:43 <michagogo> But then they got much more popular than they expected, and then they ended up having to figure out from scratch how to do production at a much bigger scale
125 2015-01-20 12:05:13 <hearn> yeah
126 2015-01-20 12:05:13 <michagogo> I guess one somewhat-solution could be to define a bunch of different increments, and have each pledge signed in several versions, one to each output
127 2015-01-20 12:05:28 <hearn> i think it's better to keep the project owner in control. they can always do a second round of crowdfunding if they blow through their first
128 2015-01-20 12:05:36 <fanquake> cfields Will you merge trivial pulls made against your repo? Or rather still have them come through the main one?
129 2015-01-20 12:05:45 <hearn> a nice enhancement would be to make the server programmable, so it can automatically create a second round, for example
130 2015-01-20 12:05:46 <jonasschnelli> hearn, lighthouse looks good. Bravo. UX is pretty seamless (for a java app *duck*).
131 2015-01-20 12:05:50 <fanquake> Also, nice work with the SDK  bump.
132 2015-01-20 12:05:51 <michagogo> and then you can redeem whichever one is the highest you've hit
133 2015-01-20 12:06:08 <jonasschnelli> cfields is in bed.... :)
134 2015-01-20 12:06:12 <hearn> jonasschnelli: i know! i was surprised at what you can do with the new java ui stuff these days.
135 2015-01-20 12:06:35 <fanquake> jonasschnelli ah ok. I’ll ask him tomorrow
136 2015-01-20 12:06:38 <jonasschnelli> hearn, yeah. I was surprised with all these snappy "swooshes", etc.
137 2015-01-20 12:06:39 <hearn> jonasschnelli: i hope it raises the bar a bit for desktop wallets
138 2015-01-20 12:06:48 <hearn> yeah, the entire thing is a 3D accelerated scene graph
139 2015-01-20 12:06:58 <hearn> you can actually put UI panes on the side of cubes and spin them around, etc
140 2015-01-20 12:07:03 <hearn> though .... i resisted doing that
141 2015-01-20 12:07:06 <hearn> (just)
142 2015-01-20 12:07:17 <michagogo> hearn: heh, like OS X?
143 2015-01-20 12:07:22 <michagogo> (or, at least old OS X)
144 2015-01-20 12:07:47 <hearn> yes like cocoa. all UI is compiled down to GL/D3D command buffers and textures.
145 2015-01-20 12:07:50 <jonasschnelli> hearn, the only problem with this UX is: the lighthouse app is listed right under VMWare in the cpu/battery consumption-list.
146 2015-01-20 12:07:55 <hearn> yeah
147 2015-01-20 12:08:06 <hearn> because it switches the laptop onto the fast 3D card instead of the slow/low power one
148 2015-01-20 12:08:26 <michagogo> hearn: I mean the fast user switching on OS X
149 2015-01-20 12:08:37 <hearn> michagogo: oh i see, yeah :)
150 2015-01-20 12:08:47 <hearn> michagogo: love these sorts of stupid visual effects. it's like stuffing myself with chocolate :)
151 2015-01-20 12:09:12 <hearn> jonasschnelli: at some point i might experiment with forcing the app onto integrated graphics and see how badly the frame rate suffers
152 2015-01-20 12:09:14 <jonasschnelli> hearn, do you do your web-design/web-stuff and the app designing by your own?
153 2015-01-20 12:10:00 <jonasschnelli> hearn, the cost of multiplatfrom and multiplatform-opengl-ui-frameworks is always cpu/battery usage... even with Qt you loose a lot of ticks
154 2015-01-20 12:10:02 <hearn> jonasschnelli: if the hit isn't too bad then i'll mark the app as able to handle i3d and we get the battery life win. it used to suffer quite badly when i used to test this on my old 2013 retina macbook. that's one reason the app doesn't start maximised. but i optimised the effects code since then
155 2015-01-20 12:10:02 <michagogo> hearn: the window is too big
156 2015-01-20 12:10:38 <hearn> jonasschnelli: yes i do it all myself. olivier donated a visual designer at one point who photoshopped my old screenshots and made them look better, then i matched that design in the ui.
157 2015-01-20 12:10:51 <hearn> jonasschnelli: web design is all me though. it probably sucks on iphones and such though. i'm not a professional web designer.
158 2015-01-20 12:10:52 <jonasschnelli> hearn, because i once though (and still do in some way) a wallet should/can run in background all the time, i've started macwallet.org (which is totally unusable right now)
159 2015-01-20 12:11:04 <hearn> yeah i remember macwallet :)
160 2015-01-20 12:11:11 <michagogo> hearn: this is the full height of my screen: http://i.imgur.com/zLO6mB4.png
161 2015-01-20 12:11:25 <hearn> michagogo: yeah i should make the app maximise itself at startup
162 2015-01-20 12:11:30 <hearn> michagogo: the idea was, the UI would look like a  web app
163 2015-01-20 12:11:34 <michagogo> Ah
164 2015-01-20 12:11:42 <jonasschnelli> hearn, it's not dead yet... :) i still have the goal of a minimalistic osx wallet with a mim. mem/cpu footprint
165 2015-01-20 12:11:49 <michagogo> At least, make the default a bit smaller
166 2015-01-20 12:11:53 <hearn> but then i ended up making kind of bloaty UIs and needed lots of screen space
167 2015-01-20 12:12:00 <hearn> michagogo: noted, thanks. i'll file a bug.
168 2015-01-20 12:12:00 <ziggy909> hello #bitcoin-dev, i was wondering if anyone here knew what, if anything, is being planned to fix mining/the upcoming difficulty oscillations due to price
169 2015-01-20 12:12:08 <michagogo> 1366 x 768 is pretty common.
170 2015-01-20 12:12:14 <fanquake> jonasschnelli Let me know whan you start working on that :)
171 2015-01-20 12:12:32 <jonasschnelli> fanquake, is up and running... http://macwallet.org
172 2015-01-20 12:12:37 <ziggy909> jgarzik, would you maybe care to weigh in on this?
173 2015-01-20 12:12:44 <michagogo> hearn: Also, the hamburger menu looks weird
174 2015-01-20 12:12:45 <jonasschnelli> fanquake, but needs update and a c++ backend
175 2015-01-20 12:12:57 <hearn> michagogo: you mean the ui that appears when you click it?
176 2015-01-20 12:13:15 <fanquake> jonasschnelli no commits for nearly a year? Don’t have time to work on it?
177 2015-01-20 12:13:24 <hearn> michagogo: https://github.com/vinumeris/lighthouse/issues/122
178 2015-01-20 12:13:33 <hearn> michagogo: the hamburger menu will show software updates once some have been pushed
179 2015-01-20 12:13:33 <michagogo> hearn: no, the menu icon itself
180 2015-01-20 12:13:38 <hearn> michagogo: oh, yeah. it sucks.
181 2015-01-20 12:13:45 <hearn> michagogo: the plan is/was that it actually pops up a menu
182 2015-01-20 12:13:46 <michagogo> The spacing, mainly
183 2015-01-20 12:14:00 <hearn> yes that is odd. i don't see that on my machine. the spacing is even.
184 2015-01-20 12:14:10 <jonasschnelli> fanquake, time is constraint 24/7. My priorities and more at bitcoin core level currently...
185 2015-01-20 12:14:15 <hearn> it looks like an issue with font rendering. this is windows 7?
186 2015-01-20 12:14:20 <michagogo> BTW, are there any options?
187 2015-01-20 12:14:25 <michagogo> testnet mode, etc?
188 2015-01-20 12:14:29 <fanquake> jonasschnelli yea assumed so.
189 2015-01-20 12:14:35 <hearn> michagogo: currently, no. you can put it into testnet mode or force it to use tor via the command line.
190 2015-01-20 12:14:36 <michagogo> Yeah, Windown 7 Home Premium 64-bit English
191 2015-01-20 12:14:38 <jonasschnelli> fanquake, people first has to trust bitcoin and bitcoin wallets,... when trust is built, small wallets can survive
192 2015-01-20 12:14:40 <hearn> but no ui options
193 2015-01-20 12:14:56 <michagogo> ?
194 2015-01-20 12:14:56 <michagogo> lighthouse.exe -testnet
195 2015-01-20 12:15:05 <hearn> michagogo: i noticed some other issues with FontAwesome on windows. not sure why.
196 2015-01-20 12:15:14 <hearn> michagogo: --help to see what's available
197 2015-01-20 12:15:20 <michagogo> Ah, thanks
198 2015-01-20 12:15:29 <jonasschnelli> hearn, lighthouse misses a about screen
199 2015-01-20 12:15:47 <michagogo> erm, --help just returned
200 2015-01-20 12:15:56 <jonasschnelli> hearn, osx: and copyright (currently it is "Copyright (C) 2015")
201 2015-01-20 12:16:31 <michagogo> hearn: to see what's available in what form?
202 2015-01-20 12:16:40 <hearn> jonasschnelli: yes, you're right. i'll probably build an about screen if people crowdfund an upgrade to it. one of the "rewards" planned is that you get your name in the about box
203 2015-01-20 12:16:48 <hearn> michagogo: --help doesn't work on windows?
204 2015-01-20 12:16:53 <hearn> michagogo: ok try --net=test
205 2015-01-20 12:16:53 <michagogo> Apparently not?
206 2015-01-20 12:17:01 <michagogo> Is it supposed to return on the command line?
207 2015-01-20 12:17:07 <hearn> ok i haven't tested command line stuff on windows
208 2015-01-20 12:17:16 <hearn> oh, is the app already running?
209 2015-01-20 12:17:21 <hearn> if so try shutting it down first and waiting a few seconds
210 2015-01-20 12:17:24 <fanquake> I know it’s been said quite a few times already. but the Lighthouse UI is really slick.
211 2015-01-20 12:17:28 <michagogo> No, not running
212 2015-01-20 12:17:44 <michagogo> (unless it runs in the background when closed, in which case that's bad because there's no tray icon)
213 2015-01-20 12:17:45 <hearn> hm ok. i'll boot up my windows vm and fiddle later. perhaps there's a bug on that platform. or maybe the library i'm using expects windows style flags
214 2015-01-20 12:17:55 <hearn> fanquake: thanks!
215 2015-01-20 12:17:57 <michagogo> http://i.imgur.com/zumilig.png
216 2015-01-20 12:18:27 <michagogo> --net=test worked
217 2015-01-20 12:18:37 <michagogo> I assume it's SPV?
218 2015-01-20 12:18:39 <hearn> yes
219 2015-01-20 12:18:53 <hearn> you might see very variable sync performance at the moment
220 2015-01-20 12:19:02 <hearn> BreadWallet on iOS sees it too. something has changed with the network
221 2015-01-20 12:19:41 <michagogo> heh, if you enlarge the window with the create project view open the blur doesn't expand
222 2015-01-20 12:20:44 <hearn> yeah, i know. was wondering when someone would notice that
223 2015-01-20 12:20:54 <hearn> https://github.com/vinumeris/lighthouse/issues/104
224 2015-01-20 12:21:06 <hearn> i punted it post beta because, well, i wanted to launch :)
225 2015-01-20 12:21:08 <michagogo> aaaaand it crashes
226 2015-01-20 12:21:14 <hearn> doh
227 2015-01-20 12:21:17 <michagogo> when trying to add an image
228 2015-01-20 12:21:28 <hearn> can you restart the app to let it submit the crash report please
229 2015-01-20 12:21:34 <michagogo> You should now have a crashlog, if the uploading thing is working :P
230 2015-01-20 12:21:41 <hearn> it uploads when the app is restarted
231 2015-01-20 12:21:49 <michagogo> It's running again
232 2015-01-20 12:21:52 <hearn> yep i see it
233 2015-01-20 12:22:27 <hearn> oh, that's a pain in the ass. looks like  crash inside javafx
234 2015-01-20 12:22:49 <hearn> can you explain what you did in the file picker?
235 2015-01-20 12:22:50 <jonasschnelli> gitian: is there a way to build a branch not available in a remote repository? I like to build the master with a pulled PR. But the --commit arg does somehow require the --url arg... any ideas?
236 2015-01-20 12:22:57 <michagogo> hearn: pasted in an http url
237 2015-01-20 12:23:06 <hearn> ....
238 2015-01-20 12:23:08 <hearn> into the file picker?
239 2015-01-20 12:23:10 <michagogo> yes
240 2015-01-20 12:23:11 <hearn> you can do that on widnows?
241 2015-01-20 12:23:15 <michagogo> Yep
242 2015-01-20 12:23:19 <michagogo> Usually works, ime
243 2015-01-20 12:23:22 <hearn> since when? i didn't know windows could do that
244 2015-01-20 12:23:33 <michagogo> It goes gray for a bit, presumably as it fetches it
245 2015-01-20 12:23:42 <hearn> windows downloads the file for you? are you sure that's not some extension you installed?
246 2015-01-20 12:23:52 <michagogo> hearn: definitely not
247 2015-01-20 12:23:56 <michagogo> I don't know exactly how it works
248 2015-01-20 12:24:04 <hearn> btw you can drag the image from your browser onto the cover image in the create project screen
249 2015-01-20 12:24:07 <michagogo> but it does work, at least in Chrome
250 2015-01-20 12:24:13 <hearn> and then lighthouse will download it for you
251 2015-01-20 12:24:31 <hearn> ok, interesting, well it looks like maybe the people who wrote the file picker code didn't know about that feature either. i will file a bug.
252 2015-01-20 12:26:48 <hearn> 
ACTION learns something new every day

253 2015-01-20 12:35:17 <michagogo> Cool, I think it worked: https://www.dropbox.com/s/oel996zny5r2szs/steal-your-bitcoins.lighthouse-project?dl=0
254 2015-01-20 12:36:17 <michagogo> Um, crashed again
255 2015-01-20 12:36:24 <michagogo> This time it was when saving a pledge
256 2015-01-20 12:36:28 <michagogo> (to a file)
257 2015-01-20 12:36:40 <wumpus> jonasschnelli: you want to have gitian build from a local repo?
258 2015-01-20 12:36:48 <jonasschnelli> wumpus, yes.
259 2015-01-20 12:37:02 <michagogo> Uh, WTF?
260 2015-01-20 12:37:07 <michagogo> hearn: http://i.imgur.com/Z7ovi4r.png
261 2015-01-20 12:37:08 <jonasschnelli> wumpus, i saw that gbuild is always loading from a remote
262 2015-01-20 12:37:25 <hearn> michagogo: see the faq
263 2015-01-20 12:37:27 <michagogo> What is that talking about?
264 2015-01-20 12:37:41 <wumpus> jonasschnelli:  --url bitcoin=${URI} --commit bitcoin=${COMMIT}   for URI, use the local directory name
265 2015-01-20 12:37:55 <michagogo> wumpus: That works?
266 2015-01-20 12:38:02 <wumpus> michagogo: I use it all the time
267 2015-01-20 12:38:04 <michagogo> I thought I tried that at some point and failed
268 2015-01-20 12:38:11 <jonasschnelli> wumpus, hmm... so easy? :) you mean a file:// scheme? or just the path /home/...
269 2015-01-20 12:38:19 <wumpus> jonasschnelli: no schemed needed, just a path
270 2015-01-20 12:38:24 <michagogo> (I ended up going into inputs/bitcoin and just fetching from the repo)
271 2015-01-20 12:38:54 <jonasschnelli> wumpus, ha. I started implementing a include of a possible pull request in ./gbuild. :)
272 2015-01-20 12:38:54 <wumpus> michagogo: well it was broken at one point, but it was fixed again also quite soon because I noticed
273 2015-01-20 12:38:56 <jonasschnelli> wumpus, thanks
274 2015-01-20 12:40:11 <wumpus> michagogo: (also I was the one to originally implement the --url option)
275 2015-01-20 12:40:20 <michagogo> hearn[lunch]: what feature is the one in question?
276 2015-01-20 12:40:58 <michagogo> Oh, getutxos?
277 2015-01-20 12:41:01 <jonasschnelli> wumpus, local file path works. thanks!
278 2015-01-20 12:59:40 <michagogo> hearn[lunch]: also, the uninstaller is broken
279 2015-01-20 13:00:18 <michagogo> It said "some components couldn't be removed" or something and that they can be removed manually, with no indication of what it's talking about
280 2015-01-20 13:32:19 <hearn> michagogo: i've uninstalled lots of times, not seen that. but i've only been testing on a clean win 8.1 install
281 2015-01-20 13:32:25 <hearn> michagogo: will try and reproduce, thanks for the report
282 2015-01-20 13:33:05 <michagogo> hearn: if it helps, somehow I ended up with a lighthouse.exe in the background, no GUI or tray icon
283 2015-01-20 13:33:13 <hearn> ah, hmm
284 2015-01-20 13:33:17 <michagogo> Maybe it's because that was running
285 2015-01-20 13:33:18 <hearn> perhaps it failed to uninstall because the app is running
286 2015-01-20 13:33:19 <hearn> yeah
287 2015-01-20 13:33:36 <hearn> that would make sense
288 2015-01-20 13:33:46 <hearn> i've seen one case where it can be slow to shut down the networking code
289 2015-01-20 14:52:30 <aschildbach_> hearn: I worked a lot on Öffi, and still am.
290 2015-01-20 14:53:12 <aschildbach_> I had the feeling it rots away slowly so had an urge to refresh it a bit.
291 2015-01-20 14:55:24 <hearn> yeah, makes sense
292 2015-01-20 15:16:30 <jonasschnelli> wumpus, IMO this can be merged: https://github.com/bitcoin/bitcoin/pull/5651
293 2015-01-20 15:22:12 <wumpus> jonasschnelli: ack
294 2015-01-20 15:22:29 <jonasschnelli> wumpus, i also would see this going in: https://github.com/bitcoin/bitcoin/pull/5628
295 2015-01-20 15:22:46 <jonasschnelli> maybe i'm a little bit a margin/pixel freak
296 2015-01-20 15:30:04 <wumpus> jonasschnelli: I'm not actually convinced that it looks better with the icons tightly against the right border
297 2015-01-20 15:31:29 <jonasschnelli> wumpus, maybe a matter of taste. :) it always buged me, the right padding.
298 2015-01-20 15:33:34 <dgenr8> michagogo: interesting that you had the urge to paste the project URL somewhere inside the app <nudges hearn>
299 2015-01-20 15:33:52 <michagogo> dgenr8: hm?
300 2015-01-20 15:33:56 <hearn> i think he was pasting a url into the cover image picker
301 2015-01-20 15:34:04 <hearn> like a jpg file or something
302 2015-01-20 15:34:05 <michagogo> Yeah, I was
303 2015-01-20 15:34:36 <hearn> "import by url" could be a nice simple feature for a contributor to add, but duplicating the browsers download ui isn't super high on my list of tasks
304 2015-01-20 15:34:45 <michagogo> That's an interesting question, though, what happens if you paste the URL to a project file into the file picker
305 2015-01-20 15:35:07 <hearn> probably also crashes. i think it can't handle this windows url-in-file-picker trick
306 2015-01-20 15:36:27 <michagogo> 
ACTION wonders what actually happens when you put a URL into a file picker

307 2015-01-20 15:37:09 <wumpus> does anyone know if it is possible on github to search pulls that touch a certain file?
308 2015-01-20 15:37:39 <michagogo> I guess I assumed Windows, in the background, downloaded it to a temp dir or something and gave the path to the temp file to the program
309 2015-01-20 15:37:42 <michagogo> But maybe not
310 2015-01-20 15:37:45 <wumpus> michagogo: as you've seen the application crashes :)
311 2015-01-20 15:38:00 <michagogo> wumpus: eh?
312 2015-01-20 15:38:11 <michagogo> I mean more generally, what happens on the backend
313 2015-01-20 15:38:25 <wumpus> michagogo: that's be too convenient for the developer, as it would be handled transparently. I suppose it just returns a URL to the application.
314 2015-01-20 15:38:27 <michagogo> Because in at least some cases, it works as expected, with that file opening up
315 2015-01-20 15:38:48 <michagogo> wumpus: well, there's a short period where the buttons gray out
316 2015-01-20 15:39:00 <michagogo> I assumed that when that happens the file's being fetched
317 2015-01-20 15:39:03 <michagogo> 
ACTION shrugs

318 2015-01-20 15:39:28 <hearn> michagogo: dunno what happens but the crash was a null pointer dereference inside the file picker code. it expected a File object and got back a null
319 2015-01-20 15:39:33 <hearn> so i guess it's not entirely transparent
320 2015-01-20 15:40:30 <wumpus> not entirely :)
321 2015-01-20 15:42:44 <michagogo> hm, I wonder if Windows has the equivalent of lsof
322 2015-01-20 15:43:47 <wumpus> sysinternals
323 2015-01-20 15:44:32 <michagogo> 
ACTION googles

324 2015-01-20 15:49:26 <midnightmagic> all the sysinternals mechanisms are *excellent*, even though they were purchasd by microsoft a while back.
325 2015-01-20 16:00:06 <gdm85> attended a speech by mark russinovich about future of C++, bright guy
326 2015-01-20 16:28:21 <wumpus> gdm85: what's the future of C++ according to him?
327 2015-01-20 16:37:48 <gdm85> wumpus: sorry, it was like 2013.. I don't remember much :)
328 2015-01-20 16:40:49 <jakl> Hi! I'm trying to create bootstrap file using linearize-data.py project in github, but I when I specify min_height>1 it tells me that genesis block not found
329 2015-01-20 16:43:57 <wumpus> gdm85: so yesterday's future of c++ ;) yes I interpreted your text as 'I *just* attended'
330 2015-01-20 16:53:50 <Luke-Jr> btcd folk: I notice a lot of your discussions on github around the account system - do you plan to support that beyond bitcoind's eventual removal of it? Have you had the foresight, I hope, to make it not conflict with the labelling of transactions?
331 2015-01-20 16:53:55 <michagogo> jakl: yeah, it's a little bit broken like that
332 2015-01-20 16:54:02 <michagogo> I'm not sure why that check is there
333 2015-01-20 16:54:15 <michagogo> You can just comment it out
334 2015-01-20 16:55:35 <michagogo> Looks like it's right before the end
335 2015-01-20 16:58:47 <jrick> Luke-Jr: we are moving towards a hd wallet where accounts are groups of addresses each sharing the same account path
336 2015-01-20 16:59:10 <Luke-Jr> jrick: eck :/
337 2015-01-20 16:59:18 <jrick> and balances are counted by utxos, not arbitrary numbers
338 2015-01-20 16:59:58 <Luke-Jr> jrick: basically sub-wallets then, not really accounts
339 2015-01-20 17:00:20 <jrick> sure
340 2015-01-20 17:00:35 <jrick> we know that's not compatible with how bitcoind implements accounts
341 2015-01-20 17:00:43 <jrick> but then again I'm not sure why anyone would want that...
342 2015-01-20 17:01:09 <Jouke> I always liked the accounts implementation, but I'll survive without it :P
343 2015-01-20 17:01:27 <Luke-Jr> jrick: it's much more useful than sub-wallets IMO :p
344 2015-01-20 17:01:38 <jrick> it's very non-intuitive
345 2015-01-20 17:02:01 <Luke-Jr> only because of n00b-confusers like blockchain.info, which confuse people even regardless of it
346 2015-01-20 17:02:17 <Luke-Jr> it's intuitive to people who understand bitcoin
347 2015-01-20 17:02:26 <Luke-Jr> there's no benefit to tying UTXOs to specific accounts
348 2015-01-20 17:02:53 <op_mul> (and a lot of downsides to doing it)
349 2015-01-20 17:03:14 <op_mul> (not least of all, you reveal a lot about the internal state of your system needlessly.
350 2015-01-20 17:03:21 <Jouke> op_mul: to subwallets?
351 2015-01-20 17:03:33 <op_mul> to tying UTXO to accounts.
352 2015-01-20 17:03:40 <justanotheruser> whats a subwallet, just an account in bitcoin core?
353 2015-01-20 17:03:41 <Jouke> yeah, exactly
354 2015-01-20 17:03:54 <Luke-Jr> no
355 2015-01-20 17:04:12 <justanotheruser> a subwallet is where they call an address a wallet?
356 2015-01-20 17:04:12 <Luke-Jr> justanotheruser: a subwallet is just multiple wallets, but with a common HD seed tying them together
357 2015-01-20 17:04:16 <jrick> if I 'getnewaddress someaccount' and someone sends to it, and I want to spend from that account, I want it to spend only those utxos
358 2015-01-20 17:04:27 <op_mul> 
ACTION rolls eyes

359 2015-01-20 17:04:28 <justanotheruser> oh
360 2015-01-20 17:04:29 <Luke-Jr> jrick: that's bad design, though
361 2015-01-20 17:04:30 <op_mul> why?
362 2015-01-20 17:04:37 <op_mul> that's *terrible* on so many fronts.
363 2015-01-20 17:04:57 <jrick> if I don't care about that, I can select many accounts to select utxos from
364 2015-01-20 17:05:09 <justanotheruser> jrick: the only reason your software would want to spend specific UTXOs is because it's broken so utxos are accounts
365 2015-01-20 17:05:17 <wumpus> well it can make sense in some cases, if you don't want to bind together UTXOs from different subwallets
366 2015-01-20 17:05:22 <justanotheruser> s/so/in the way that/
367 2015-01-20 17:05:26 <wumpus> e.g. the same reason people use coin control
368 2015-01-20 17:05:38 <jrick> justanotheruser: no, it's more for privacy reasons
369 2015-01-20 17:05:55 <jrick> I don't want to be mixing unreleated utxos
370 2015-01-20 17:06:18 <justanotheruser> actually that makes some sense.
371 2015-01-20 17:06:28 <Jouke> I would want to mix unrelated utxos for privacy reasons
372 2015-01-20 17:06:57 <justanotheruser> Jouke: in a world where almost no one coinjoins, that correlates two payments to you together
373 2015-01-20 17:07:14 <wumpus> Jouke: but mixing with other utxo's from yourself doesn't increase privacy, you'd want to mix them with other people's utxos of course :)
374 2015-01-20 17:07:27 <wumpus> justanotheruser: yeah...
375 2015-01-20 17:07:38 <Jouke> wumpus: who would I don't do that?
376 2015-01-20 17:07:46 <Jouke> Most of the txes are sendmany anyway
377 2015-01-20 17:07:59 <Luke-Jr> jrick: UTXOs are all unrelated in that aspect
378 2015-01-20 17:08:00 <Jouke> *know if
379 2015-01-20 17:08:57 <wumpus> Jouke: that's a different case. But say two people are paying you for different reasons, and you merge together their utxos as inputs, it can be correlated that both destinations correlate to the same person (in absence of enough people using coinjoin)
380 2015-01-20 17:09:21 <op_mul> wumpus: well, I would mark that as the services wallet not a particular users.
381 2015-01-20 17:10:19 <Luke-Jr> wumpus: not accurately
382 2015-01-20 17:10:21 <wumpus> e.g. to name a silly case, you may bind donations to your anti-employer blog to salary payments from said employer
383 2015-01-20 17:10:59 <wumpus> op_mul: but it's a valid use of subwallets.
384 2015-01-20 17:11:06 <jrick> the point is not to make mixing input selection impossible, but to make it explicit
385 2015-01-20 17:11:38 <wumpus> right
386 2015-01-20 17:11:41 <Jouke> I get what you are saying. Anyway, having a broader range of utxos will probably create more efficient transactions.
387 2015-01-20 17:11:52 <wumpus> it's the same idea as coin controll
388 2015-01-20 17:12:08 <Luke-Jr> jrick: making it explicit *encourages* people to try to assume UTXOs consumed are some kind of "from"
389 2015-01-20 17:12:14 <Luke-Jr> jrick: it actually makes the problem you want to solve worse
390 2015-01-20 17:12:49 <wumpus> Jouke: sure. It all depends on what you want
391 2015-01-20 17:12:53 <jrick> they are consumed "from" a some set
392 2015-01-20 17:13:01 <jrick> they are placed in that set by the address they were received from
393 2015-01-20 17:13:09 <jrick> but they are not sent from those addresses
394 2015-01-20 17:13:35 <jrick> in fact we want to discourage address reuse as much as possible
395 2015-01-20 17:13:38 <wumpus> jrick: by the address they're sent *to* I hope?
396 2015-01-20 17:13:40 <jrick> so one time receiving addresses
397 2015-01-20 17:13:43 <jrick> wumpus: yeah
398 2015-01-20 17:14:32 <op_mul> keep in mind that one time receiving addresses won't give you service level privacy.
399 2015-01-20 17:14:32 <wumpus> Jouke: in the case of e.g. an exchange it makes little sense to have accounts as subwallets
400 2015-01-20 17:14:34 <jrick> but you don't have to convince me that there is no from address :p
401 2015-01-20 17:14:44 <jakl> I'm getting "error genesis block not found" when I try to create a bootstrap.dat starting with min_height>1
402 2015-01-20 17:15:03 <wumpus> Jouke: it'd be extremely inefficient, as every internal transaction would have to be on the blockchain
403 2015-01-20 17:15:20 <op_mul> wumpus: and that in itself would be very revealing.
404 2015-01-20 17:15:22 <Luke-Jr> jrick: my point is that by limiting UTXOs by default, you are making it easier for people to assume UTXOs consumed together are related and/or indicate "from"
405 2015-01-20 17:15:27 <Jouke> jrick: you wouldn't know how many calls and support messages we receive regarding "from" addresses :)
406 2015-01-20 17:15:36 <wumpus> jakl: you have to start at the genesis block
407 2015-01-20 17:15:49 <Luke-Jr> jrick: also, what wumpus points out: you lose off-chain transaction capability
408 2015-01-20 17:16:02 <wumpus> Luke-Jr: more like 'choose not to have'
409 2015-01-20 17:16:03 <davec> speaking of the one-time use topic.  Our plan is to make it so that, by default, all addressess are one-use only unless you specifically request otherwise.  Then whenever and address receives a payment, it is marked as "inactive"
410 2015-01-20 17:16:13 <jrick> Luke-Jr: but they are related. the addresses you received to belong to the same account
411 2015-01-20 17:16:14 <Jouke> wumpus: good point :)
412 2015-01-20 17:16:24 <jakl> wumpus: I'm using linearize-data.py, there is an option where you can set min_height and max_height to create a bootstrap file just for the blocks
413 2015-01-20 17:16:29 <jrick> how you use those groups are up to you
414 2015-01-20 17:16:48 <helo> does it handle the case when an address receives a payment in multiple parts?
415 2015-01-20 17:16:56 <davec> so wallet no longer has to spend resources looking for pyaments to it, loading it from the db, etc
416 2015-01-20 17:17:10 <helo> (of course it wouldn't lose the funds, but for UI cohesiveness)
417 2015-01-20 17:17:34 <Luke-Jr> wumpus: a software decision is not necessarily a user decision
418 2015-01-20 17:17:44 <davec> and since it'l be HD, you don't even really have to keep any data about it other than the "index" and it was used since you can just rederive the private key on the fly
419 2015-01-20 17:17:52 <Luke-Jr> jrick: the addresses you received to have nothing to do with the UTXOs
420 2015-01-20 17:18:12 <jrick> yes they are
421 2015-01-20 17:18:15 <wumpus> jakl: yes, but as it is implemented right now you need to start at the genesis block
422 2015-01-20 17:18:27 <Luke-Jr> jrick: no, otherwise you have from addresses
423 2015-01-20 17:18:30 <wumpus> jakl: I guess you could remove that check or make it optional
424 2015-01-20 17:18:31 <jrick> the output script is specific to that address
425 2015-01-20 17:19:29 <Luke-Jr> jrick: it isn't.
426 2015-01-20 17:19:38 <jrick> the address is just a means to easily receive payments, but you still need that key to sign a transaction with spends it
427 2015-01-20 17:19:46 <jrick> *which
428 2015-01-20 17:19:47 <Luke-Jr> jrick: the keys are independent from the address
429 2015-01-20 17:20:05 <jrick> the address is derived from the key
430 2015-01-20 17:20:15 <Luke-Jr> technically, but that's just an implementation detail
431 2015-01-20 17:20:16 <helo> that sits in the house
432 2015-01-20 17:20:25 <Luke-Jr> the association with the address ends when the transaction is received
433 2015-01-20 17:21:32 <jakl> wumpus: when I remove the check it produce the bootstrap file but I keep getting skipping unknown block, I think it start from the genesis block whether min_height set or not. How do I alter this behaviour and force it to start from min_height?
434 2015-01-20 17:22:26 <Luke-Jr> jrick: anyhow, the reason I asked initially was that if btcd supported accounts (which I guess it won't, from the sounds of it), then it could have served as an alternative to point people to, so the mess in bitcoind might be removed sooner)
435 2015-01-20 17:22:43 <jrick> oh don't let us stop you from removing it
436 2015-01-20 17:22:47 <Luke-Jr> (I sure hope you'll call them sub-wallets or some term that indicates they are not accounts, btw)
437 2015-01-20 17:22:48 <jrick> please kill it
438 2015-01-20 17:22:50 <jrick> kill it dead
439 2015-01-20 17:23:05 <Luke-Jr> jrick: no, my point is that people currently using it need a migration path, before they can be removed nicely
440 2015-01-20 17:23:06 <jrick> we can do that
441 2015-01-20 17:23:20 <Luke-Jr> not unless you add account support :p
442 2015-01-20 17:23:21 <jrick> since the behavior is different from bitcoind accounts
443 2015-01-20 17:23:30 <jrick> oh
444 2015-01-20 17:23:39 <jrick> you're saying to shift bitcoind wallet users to our wallet?
445 2015-01-20 17:23:39 <petertodd> Luke-Jr: was talking to an exchange the other day, who may be willing to fund the creation of a totally stand-alone wallet implementation
446 2015-01-20 17:23:44 <jrick> as a migration path?
447 2015-01-20 17:24:01 <Luke-Jr> jrick: yes, if btcd's wallet supported accounts
448 2015-01-20 17:24:06 <wumpus> petertodd: why not fund one of the existing wallets?
449 2015-01-20 17:24:28 <justanotheruser> Luke-Jr: I think you need to be more specific when you say stuff like "jrick: the addresses you received to have nothing to do with the UTXOs" since the address is related to the UTXO in that the outputs script since there is a 1-to-1 mapping of addresses to p2pkh scripts.
450 2015-01-20 17:24:30 <jrick> yeah that won't work, sorry
451 2015-01-20 17:24:31 <Luke-Jr> petertodd: what wumpus said
452 2015-01-20 17:24:50 <op_mul>  make a new wallet. in javascript.
453 2015-01-20 17:24:52 <Luke-Jr> justanotheruser: I don't know a better way to explain that
454 2015-01-20 17:24:56 <wumpus> I'm not sure another project is what we need, better auditing and improvement of the current wallet projects would be a better use of money IMO
455 2015-01-20 17:24:58 <Luke-Jr> 
ACTION stabs op_mul

456 2015-01-20 17:25:23 <op_mul> Luke-Jr: everything's a float!
457 2015-01-20 17:25:27 <petertodd> wumpus: they need a backend wallet; the current wallet projects are all "client-side" targetted, not useful for an exchange with thousands of users to track
458 2015-01-20 17:25:39 <jrick> I'm pretty sure the current accounts behavior can be simulated using an external ledger
459 2015-01-20 17:25:47 <jrick> but then you still break api compatibility
460 2015-01-20 17:25:50 <op_mul> of course they can.
461 2015-01-20 17:25:52 <Luke-Jr> petertodd: Bitcoin Core's wallet isn't client-side targetted. Funding could be put to split it out and improve it.
462 2015-01-20 17:26:03 <petertodd> wumpus: very different target audience unfortunately, though possibly starting with an existing wallet might help
463 2015-01-20 17:26:06 <Luke-Jr> jrick: yes, mostly. that's the goal.
464 2015-01-20 17:26:10 <justanotheruser> petertodd: ask them to fix bit-c please
465 2015-01-20 17:26:11 <wumpus> petertodd: that could change though, with funding
466 2015-01-20 17:26:30 <Luke-Jr> jrick: although you'd want to use a HD chain to generate the addresses still IMO
467 2015-01-20 17:26:48 <petertodd> Luke-Jr: I suggested that - it'd depend on what changing Bitcoin Core to scale better ended up looking like; may be so many changes that starting from scratch is a better way to go about the problem
468 2015-01-20 17:27:16 <Luke-Jr> petertodd: possibly
469 2015-01-20 17:27:27 <Luke-Jr> in fact.. probably
470 2015-01-20 17:27:51 <Luke-Jr> could reuse the new logdb stuff though ;)
471 2015-01-20 17:28:10 <petertodd> one issue is that auditing/proof-of-solvency requirements can end up changing how the wallet fundementally must work in ways that are incomatible with other wallet uses; we'll see as the first design doc gets done up...
472 2015-01-20 17:28:35 <op_mul> petertodd: please have it written in something sane :<
473 2015-01-20 17:28:55 <wumpus> petertodd: codeshark's coinvault project may also be interesting there, his goal is to make a standalone wallet for large-scale usage.I can't vouch for its security or robustness thoough.
474 2015-01-20 17:29:25 <justanotheruser> Luke-Jr: what do you think of proof of solvency? Isn't it just as bad as address reuse for security?
475 2015-01-20 17:29:42 <Luke-Jr> justanotheruser: I don't think so, but I didn't look over the specs
476 2015-01-20 17:30:06 <petertodd> justanotheruser: I may end up being paid to come up with a practical proof-of-solvency scheme that's as close to zero-knowledge as feasible; pretty sure it's possible
477 2015-01-20 17:31:00 <justanotheruser> petertodd: does it use some fancy math to prevent your pubkey from being revealed?
478 2015-01-20 17:32:05 <petertodd> justanotheruser: basically, you should be able to take all your customer obligations, put it into a tree, make it possible for customers to know they're in that tree, and then use some kind of fiat-shamir transform type technique to prove a subset of the actual coins committed too; I wrote up a way to do this minus the fiat-shamir transform part a few months ago
479 2015-01-20 17:32:29 <justanotheruser> link?
480 2015-01-20 17:32:48 <petertodd> justanotheruser: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04404.html
481 2015-01-20 17:32:51 <justanotheruser> thanks
482 2015-01-20 17:34:46 <petertodd> justanotheruser: sorry that I did such a shit job writing it up there; very unclearly written
483 2015-01-20 17:36:47 <justanotheruser> if you're talking about what you said in IRC, I don't think I would understand it withuot reading the writeup anyways
484 2015-01-20 17:37:05 <wumpus> cfields: btw, we need a way to ignore the stuff under arch-dependent subdirs under depends from git. git gui e.g. tries to read all the files under depends/i686-pc-linux-gnu
485 2015-01-20 17:37:27 <justanotheruser> First I'm reading the pre-req "From Identification to Signatures via the Fiat-Shamir Transform: Minimizing Assumptions for Security and Forward-Security"
486 2015-01-20 17:37:42 <cfields> wumpus: agreed. I've kicked myself a hundred times for not doing that to start with :\
487 2015-01-20 17:38:19 <wumpus> cfields: it's hard to come up with a rule though. We'd need a whitelist instead of a blacklist :)
488 2015-01-20 17:38:52 <cfields> wumpus: hmm, that's a decent idea, actually. you can use */ and !packages, for example
489 2015-01-20 17:39:07 <cfields> wumpus: though the correct fix would be to just move them to a subdir in a one-time breaking move
490 2015-01-20 17:39:09 <wumpus> cfields: ncie!
491 2015-01-20 17:39:43 <wumpus> cfields: yes, though I do kind of like the flat structure
492 2015-01-20 17:39:51 <cfields> wumpus: if the whitelist would work, i'd much rather do that for now, though. I've never really tried em, but i've seen em in the docs
493 2015-01-20 17:40:17 <wumpus> yep
494 2015-01-20 17:40:44 <cfields> great idea. I'll give it a shot
495 2015-01-20 17:40:44 <op_mul> petertodd: don't a large number of people already use bitcoinj based wallets for their services? I've seen a few that do now.
496 2015-01-20 17:41:20 <wumpus> btw, README.usage has a "make HOST=host-platform-triplet && make HOST=host-platform-triplet" line but I've yet been too lazy to fix it :)
497 2015-01-20 17:41:29 <petertodd> op_mul: yes, although I don't know of any bitcoinj-based wallets that have a bitcoind compatible RPC interface
498 2015-01-20 17:41:34 <cfields> wumpus: btw, i realize the openssl init patch i posted last night is just a quick fix. I'm sure there's a better place for it. Don't worry about taking mine if you'd rather move it around
499 2015-01-20 17:41:55 <cfields> wumpus: ah, heh. at one point the process was make && make install, but i removed that. probably botched the docs cleanup
500 2015-01-20 17:42:13 <op_mul> petertodd: I would be pretty upset if the barrier to large companies using some software was some minor changes to their interface. this is the whole reason for the insanity that is blockchain.info's RPC API
501 2015-01-20 17:42:14 <petertodd> op_mul: equally, it's almost certain none support the proof-of-solvency scheme that exchange wants, because they'll end up paying me to refine/develop it :P
502 2015-01-20 17:42:29 <op_mul> petertodd: you wouldn't believe how many people use that. to tears man, it beings me to tears.
503 2015-01-20 17:42:58 <wumpus> cfields: I also thought about that; best would be in some top-level initialization function. But I just wanted it to pass travis for now and your patch did fine for that
504 2015-01-20 17:43:24 <petertodd> op_mul: using something else costs money... even for a "responsible" company the dev environment to use bitcoinj is kinda nuts, and the software is suspect (e.g. bad code-signing practices)
505 2015-01-20 17:43:50 <cfields> ok
506 2015-01-20 17:44:54 <wumpus> cfields: will move it to src/qt/test_main.cpp
507 2015-01-20 17:45:05 <op_mul> petertodd: yes, I think most wallet software is insane in the EC department. relying on a third party to do it for you is even more insane though, especially the one I'm talking about.
508 2015-01-20 17:46:15 <petertodd> op_mul: yup, which leads to the conclusion that trusting Bitcoin Core to do it all isn't crazy - certainly makes for a "no-one got fired for buying IBM' argument
509 2015-01-20 17:47:24 <wumpus> op_mul: that's the problem isn't it. Lots of wallet software, but which one can you trust? That's also why I discouraged petertodd from starting yet another project. Better to improve security and such of the current ones, make sure lots of eyes look at the code versus lots of projects that have only few eyes.
510 2015-01-20 17:49:14 <op_mul> wumpus: in my mind that's probably the best option. I found one of the most popular libraries used for signing makes invalid signatures a certain amount of the time.. and that's somehow gone totally unnoticed by everybody else.
511 2015-01-20 17:50:15 <op_mul> wumpus: people parrot the line about oh it's open source someone is looking over it, but as far as I can see nobody has ever audited any of the most popular javascript based stuff. there's a few different types and they're all on the ludicrous scale somewhere.
512 2015-01-20 17:50:30 <petertodd> wumpus: lol, don't worry, you don't have to discourage me... I've already told said exchange I don't have the time to presonally write that SW, which means the obvious thing to do is hire someone who already has experience writing a wallet at the very least
513 2015-01-20 17:51:27 <petertodd> op_mul: meh, you know, just it being *possible* to audit an open source project's code is a huge step forward; strong discouragement to putting delibrate backdoors in
514 2015-01-20 17:51:32 <wumpus> op_mul: yes, the state of javascript libraries is the most sad of all, and unfortunately those get used a lot
515 2015-01-20 17:51:37 <petertodd> op_mul: that's why non-deterministic builds are scary...
516 2015-01-20 17:52:42 <wumpus> op_mul: javascript is also the exception to ''use a proven library" as it doesn't have any binding possibilities
517 2015-01-20 18:49:34 <jtimon> Luke-Jr #5648 has been merged with a small commit from your policy branch
518 2015-01-20 19:40:15 <gavinandresen> “Will It Scale?”  results are in:   http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html
519 2015-01-20 20:00:14 <akstunt600> Thanks gavinandresen
520 2015-01-20 20:00:25 <akstunt600> You answered actually everyone of my questions.
521 2015-01-20 20:00:31 <akstunt600> answered*
522 2015-01-20 20:04:33 <cfields> wumpus: what are the blockers for rc4?
523 2015-01-20 20:36:12 <Luke-Jr> hm, bad_alloc with 512 MB RAM :x
524 2015-01-20 20:37:03 <paveljanik> 1G works though ;-)
525 2015-01-20 20:38:36 <paveljanik> I'm running a testnode at home on banana pi.
526 2015-01-20 20:42:33 <wumpus> cfields: I don't think there are any
527 2015-01-20 20:43:06 <wumpus> cfields: there have been no problems with rc3 that I know of
528 2015-01-20 20:45:18 <Luke-Jr> paveljanik: mine is on a USB Armory stick
529 2015-01-20 20:45:28 <cfields> wumpus: the qt unicode problem was the only thing that i've seen. Any reason to delay tagging rc4?
530 2015-01-20 20:46:08 <wumpus> cfields: well I don't know how much time you want to give people to test a rc
531 2015-01-20 20:46:47 <cfields> wumpus: no rush, just curious
532 2015-01-20 20:47:29 <wumpus> I'm fine with tagging rc4 right now, but you'll see that 5 minutes later someone comes with an issue 'oh this should make it into 0.10 too!'
533 2015-01-20 20:47:46 <cfields> wumpus: well hurry up and do that so we can tag rc5 in 10 min :)
534 2015-01-20 20:48:50 <cfields> joking ofc. was really just a matter of curiosity
535 2015-01-20 20:49:10 <wumpus> cfields: lol
536 2015-01-20 20:49:55 <cfields> maybe set a fixed time for tag in X days, though? Then nobody can act surprised if they don't make it in time
537 2015-01-20 20:50:01 <wumpus> cfields: but you know no other pulls that should still be backported into 0.10 either?
538 2015-01-20 20:50:25 <wumpus> well from experience these are not usually the things people work on beforehand
539 2015-01-20 20:50:29 <cfields> wumpus: none on my radar
540 2015-01-20 20:50:57 <cfields> wumpus: the only thing i've considered is maybe backporting some of the big (trivial) refactors, to keep backport conflicts lower in the future
541 2015-01-20 20:51:02 <wumpus> meh
542 2015-01-20 20:51:10 <cfields> but i never brought it up because i'm not convinced it's worth the trouble
543 2015-01-20 20:52:07 <wumpus> it isn't; usually easy enough to backport things if it's needed, refactors or not
544 2015-01-20 20:52:30 <wumpus> (at least, over the trivial refactors, and the less trivial stuff you don't really want to backport i nthe first place)
545 2015-01-20 20:53:57 <op_mul> cfields: luke still gets surprised about things that were merged months ago
546 2015-01-20 20:54:39 <cfields> op_mul: well i kinda like to see him worked up, so that's fine by me :)
547 2015-01-20 20:55:01 <Luke-Jr> ?
548 2015-01-20 20:56:26 <Luke-Jr> gavinandresen: re blog proposal, I presume you don't need to be reminded that even 100% of miners do not form a hardfork consensus, much less 80%, but just in case..
549 2015-01-20 20:56:26 <wumpus> but good point about warning in advance: I'm going to tag rc4 tomorrow morning GMT, so anyone that still wants anything merged let me know before then
550 2015-01-20 20:56:45 <cfields> wumpus: sounds good
551 2015-01-20 20:57:31 <wumpus> that does mean that the strict DER softfork won't make it into 0.10.0, but we could do a 0.10.1 for that
552 2015-01-20 20:58:08 <Luke-Jr> hm
553 2015-01-20 20:58:16 <Luke-Jr> 0.10 will be a popular release, maybe we should wait for it
554 2015-01-20 20:58:22 <wumpus> it's already slipping too much
555 2015-01-20 20:58:23 <gavinandresen> Luke-Jr: sure, I’m assuming merchants/exchanges go along. (almost all I’ve spoken with are all for more tranasctions)
556 2015-01-20 20:58:46 <op_mul> Luke-Jr: I think .0 releases get a lot more poeple updating to them than .x releases.
557 2015-01-20 20:58:55 <wumpus> also it would be a last-minute hack to add anything substantial in rc4
558 2015-01-20 20:59:15 <cfields> wumpus: yea, that's a really scary time to be making policy changes
559 2015-01-20 20:59:22 <Luke-Jr> gavinandresen: hm, okay.
560 2015-01-20 20:59:39 <Luke-Jr> op_mul: that was my point
561 2015-01-20 20:59:46 <wumpus> well, then we'll just do 0.11
562 2015-01-20 20:59:51 <op_mul> Luke-Jr: I was agreeing with you.
563 2015-01-20 21:00:10 <sipa> wumpus: i'm very nearly done with thre DERSIG bip