| 07:20 | 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.. |
| 07:20 | gribble | The operation succeeded. |
| 08:16 | jonasschnelli | cfields, arround? |
| 08:23 | cfields | jonasschnelli: just for a min |
| 08:23 | jonasschnelli | cfields, okay.... but worked it out. :) |
| 08:23 | cfields | jonasschnelli: heh, sure? |
| 08:23 | jonasschnelli | cfields, i first tough we need a DS_Store update.. |
| 08:25 | cfields | jonasschnelli: we do, but only after your changes |
| 08:25 | jonasschnelli | cfields, but i saw that you updated DS_Store to make use of the new tiff |
| 08:25 | jonasschnelli | nice! |
| 08:26 | cfields | jonasschnelli: right, those commits are meant to go on top of your changes |
| 08:26 | jonasschnelli | cfields, so then i pull those in |
| 08:28 | 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 |
| 08:29 | jonasschnelli | cfields do you know why there is a merge commit? |
| 08:29 | jonasschnelli | https://github.com/bitcoin/bitcoin/pull/5683/commits |
| 08:30 | cfields | jonasschnelli: because we didn't branch from the same point. easiest thing would just be to cherry-pick em |
| 08:30 | jonasschnelli | cfields, okay, will cherry pick and force push again |
| 08:31 | jonasschnelli | cfields, sdks 10.9 fails on my gitian: https://bitcoin.jonasschnelli.ch/pulls/5684/build-osx.log |
| 08:32 | cfields | jonasschnelli: unsure. your sdk is good? It passes travis and builds fine in gitian for me |
| 08:32 | jonasschnelli | cfields, hmm.. just forged the 10.9 sdk but will do again and report in the PR as comment. |
| 08:35 | cfields | jonasschnelli: your packages didn't rebuild. Something's not right. Sure you're building from current master? |
| 08:35 | jonasschnelli | cfields, will check |
| 08:36 | cfields | the SDK bump should cause all packages to rebuild |
| 08:37 | jonasschnelli | cfields, i do a 'git checkout master; git reset --hard origin/master; before building. |
| 08:38 | cfields | jonasschnelli: but you're doing "./gbuild -c bitcoin=f0172bf9 ..." or so? |
| 08:39 | jonasschnelli | ./bin/gbuild --commit bitcoin=master ... |
| 08:39 | jonasschnelli | cfields, |
| 08:40 | cfields | and master is what's currently checked out? |
| 08:40 | jonasschnelli | cfields, hmm,... no i pulled the PR also |
| 08:40 | cfields | (not what HEAD is reset to, i mean the active local branch) |
| 08:40 | jonasschnelli | cfields, thats probably the issue! |
| 08:41 | jonasschnelli | cfields so should i get the git HEAD sha after pulling the pull-request and use this for gbuild --commit=? |
| 08:41 | cfields | jonasschnelli: i prefer to do that, yes, so i'm 100% sure of what commit it's building |
| 08:42 | jonasschnelli | cfields, okay, will try now |
| 08:42 | 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 |
| 08:43 | cfields | (unless you'd just prefer to, of course) |
| 08:47 | cfields | nnite |
| 08:47 | wumpus | nn cfields |
| 08:48 | cfields | wumpus: that ssl error is a head-scratcher |
| 08:48 | wumpus | cfields: yes, very weird. Must be an interaction between bitcoin's built-in openssl and qt's/the systems |
| 08:48 | cfields | i'm a bit nervous that it will point out something stupid we've been doing all along |
| 08:48 | wumpus | cfields: but I don't see how I introduced it. |
| 08:48 | jonasschnelli | cfields, hmm.. get `block in <main>': error looking up commit for tag f0172bf91ef521a0155cf1f0ae9fde1ab02157b3 (RuntimeError) |
| 08:49 | jonasschnelli | but will work it out.. have some rest. |
| 08:49 | wumpus | are the tests built with reduced visibility for symbols? |
| 08:49 | wumpus | anyhow, get some sleep, I'll do some testing here |
| 08:49 | cfields | wumpus: yes. did you see my latest comment? more data points |
| 08:50 | wumpus | yep I saw, now trying to reproduce locally |
| 08:51 | cfields | wumpus: oh, i bet i know... openssl is disabled in our qt4 build |
| 08:52 | cfields | enabled in qt5 and system qt, though |
| 08:52 | wumpus | cfields: but we don't actually use our qt4 build; but it may reflect in the headers somehow |
| 08:54 | cfields | wumpus: right. well, i insisted on that, so i'll hunt it down. Don't burn your time on it :) |
| 08:54 | wumpus | ah, after doing a 32-bit build w/ depends I get it locally now |
| 08:55 | cfields | wumpus: it happens on 64bit too. the 32bit travis build is the only one that runs against qt4 |
| 08:56 | 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 |
| 08:56 | wumpus | but indeed I saw in your post that it happens on 64-bit too |
| 08:56 | 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 |
| 08:57 | cfields | so it seems it has to do with compile/link rather than runtime loading |
| 08:58 | wumpus | yes |
| 09:00 | wumpus | cfields: how can that LD_PRELOAD ever have worked, if our built qt4 has no openssl support |
| 09:01 | cfields | wumpus: ah, i lied, it does use our openssl |
| 09:02 | cfields | wumpus: really, i'll track it down tomorrow. it must be a stupid build thing :) |
| 09:03 | wumpus | ldd against src/qt/test/test_bitcoin doesn't show any linking against libssl/libcrypto |
| 09:04 | cfields | depends builds static, so qt's network lib is linked against static libssl |
| 09:05 | wumpus | that can't be - this is *dynamic* qt |
| 09:05 | cfields | at runtime, yes |
| 09:06 | wumpus | ldd shows the run-time shared library dependencies (including dependencies of dependencies) |
| 09:06 | cfields | oh i see what you mean. yes, that's strange |
| 09:06 | 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?) |
| 09:07 | cfields | i don't believe so, otherwise they wouldn't require a link against -lssl |
| 09:11 | 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. |
| 09:13 | wumpus | anyhow, I'll leave this to you tomorrow, nn |
| 09:14 | cfields | nnite |
| 09:14 | cfields | wumpus: feel free ofc, i'm just trying to take the time-sink off your hands |
| 10:41 | cfields | wumpus: heh, got it |
| 10:41 | cfields | wumpus: boost was the real culprit. qt was fixing by accident... |
| 10:42 | cfields | wumpus: http://pastebin.com/raw.php?i=L3LPnGwr |
| 10:42 | wumpus | cfields: hah |
| 10:42 | cfields | boost inits openssl statically as soon as you include asio |
| 10:43 | wumpus | yes, that makes sense. |
| 10:43 | wumpus | nice catch! |
| 10:44 | cfields | we'll need to be careful about how we handle that, if we're switching openssl around |
| 10:44 | cfields | now i can sleep in peace :). nnite |
| 10:45 | wumpus | right - it's kinda strange though, you'd assume qt initializes openssl too |
| 10:45 | wumpus | but we also use openssl directly, which probably is inadvance of qt's use |
| 10:46 | wumpus | well anyhow, thanks for chasing this down, nnite |
| 11:32 | aschildbach_ | ;;help |
| 11:32 | 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/ |
| 11:32 | aschildbach_ | !facts |
| 11:32 | 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> |
| 11:33 | aschildbach_ | !factoids search aschildbach |
| 11:33 | gribble | No keys matched that query. |
| 11:33 | hearn | :( |
| 11:33 | hearn | we need some aschildbach facts! |
| 11:33 | aschildbach_ | hearn: I was search for a search function |
| 11:33 | aschildbach_ | because my irc client told me somebody has said something to me but it already scrolled away |
| 11:34 | hearn | i think you can search google for this: site:bitcoinstats.com/irc/bitcoin-dev/logs/2015/01 aschildbach |
| 11:36 | aschildbach_ | If Dekker3D happens to come back, tell him/her to mail me I have some info for him regarding wallet integration on Android. |
| 11:44 | aschildbach_ | hearn: congrats for the public beta! |
| 11:44 | hearn | thanks! |
| 11:44 | hearn | it took .... longer than expected. but that's software for you :) |
| 11:44 | 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 |
| 11:45 | hearn | what have you been up to lately? |
| 11:49 | bedeho | hearn: yeah, it looks amazing, I will definitively use it for my project (assuming you are ok with that) |
| 11:49 | hearn | bedeho: of course! it's an app, do what you like with it |
| 11:51 | 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. |
| 11:52 | hearn | sure. |
| 11:56 | michagogo | hearn: did you end up finding a solution for the "excess contributions go to fees" problem? |
| 11:57 | michagogo | (I seem to remember that being brought up at some early point in the discussion) |
| 11:57 | hearn | the app doesn't let you over-pledge. |
| 11:57 | michagogo | But how can you know that it's fully pledged? |
| 11:58 | michagogo | (if pledges aren't immediately being uploaded to a server that maintains them) |
| 12:00 | 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 |
| 12:01 | michagogo | ACTION wonders if there's any case where deliberately including too many pledges would be incentivized |
| 12:02 | michagogo | Also, I kinda feel like that's a flaw of the system, not allowing you to exceed the target |
| 12:02 | michagogo | I mean, I understand why that has to be the case |
| 12:03 | hearn | well, it's arguable. if projects can exceed the target you can end up with kickstarter potato salad type fiascos |
| 12:03 | hearn | not sure if you saw that one |
| 12:03 | michagogo | I did :P |
| 12:03 | michagogo | And yeah, it's true |
| 12:03 | michagogo | Too much success can also be a bad thing |
| 12:04 | michagogo | Besides silly ones like the potato salad, I think I've heard ofprojects that made e.g. production plans |
| 12:04 | hearn | there is a feature request open to switch from pledging to donations, once a project is fully funded |
| 12:04 | 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 |
| 12:05 | hearn | yeah |
| 12:05 | 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 |
| 12:05 | 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 |
| 12:05 | fanquake | cfields Will you merge trivial pulls made against your repo? Or rather still have them come through the main one? |
| 12:05 | hearn | a nice enhancement would be to make the server programmable, so it can automatically create a second round, for example |
| 12:05 | jonasschnelli | hearn, lighthouse looks good. Bravo. UX is pretty seamless (for a java app *duck*). |
| 12:05 | fanquake | Also, nice work with the SDK bump. |
| 12:05 | michagogo | and then you can redeem whichever one is the highest you've hit |
| 12:06 | jonasschnelli | cfields is in bed.... :) |
| 12:06 | hearn | jonasschnelli: i know! i was surprised at what you can do with the new java ui stuff these days. |
| 12:06 | fanquake | |
| 12:06 | jonasschnelli | hearn, yeah. I was surprised with all these snappy "swooshes", etc. |
| 12:06 | hearn | jonasschnelli: i hope it raises the bar a bit for desktop wallets |
| 12:06 | hearn | yeah, the entire thing is a 3D accelerated scene graph |
| 12:06 | hearn | you can actually put UI panes on the side of cubes and spin them around, etc |
| 12:07 | hearn | though .... i resisted doing that |
| 12:07 | hearn | (just) |
| 12:07 | michagogo | hearn: heh, like OS X? |
| 12:07 | michagogo | (or, at least old OS X) |
| 12:07 | hearn | yes like cocoa. all UI is compiled down to GL/D3D command buffers and textures. |
| 12:07 | jonasschnelli | hearn, the only problem with this UX is: the lighthouse app is listed right under VMWare in the cpu/battery consumption-list. |
| 12:07 | hearn | yeah |
| 12:08 | hearn | because it switches the laptop onto the fast 3D card instead of the slow/low power one |
| 12:08 | michagogo | hearn: I mean the fast user switching on OS X |
| 12:08 | hearn | michagogo: oh i see, yeah :) |
| 12:08 | hearn | michagogo: love these sorts of stupid visual effects. it's like stuffing myself with chocolate :) |
| 12:09 | hearn | jonasschnelli: at some point i might experiment with forcing the app onto integrated graphics and see how badly the frame rate suffers |
| 12:09 | jonasschnelli | hearn, do you do your web-design/web-stuff and the app designing by your own? |
| 12:10 | 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 |
| 12:10 | 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 |
| 12:10 | michagogo | hearn: the window is too big |
| 12:10 | 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. |
| 12:10 | hearn | jonasschnelli: web design is all me though. it probably sucks on iphones and such though. i'm not a professional web designer. |
| 12:10 | 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) |
| 12:11 | hearn | yeah i remember macwallet :) |
| 12:11 | michagogo | hearn: this is the full height of my screen: http://i.imgur.com/zLO6mB4.png |
| 12:11 | hearn | michagogo: yeah i should make the app maximise itself at startup |
| 12:11 | hearn | michagogo: the idea was, the UI would look like a web app |
| 12:11 | michagogo | Ah |
| 12:11 | jonasschnelli | hearn, it's not dead yet... :) i still have the goal of a minimalistic osx wallet with a mim. mem/cpu footprint |
| 12:11 | michagogo | At least, make the default a bit smaller |
| 12:11 | hearn | but then i ended up making kind of bloaty UIs and needed lots of screen space |
| 12:12 | hearn | michagogo: noted, thanks. i'll file a bug. |
| 12:12 | 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 |
| 12:12 | michagogo | 1366 x 768 is pretty common. |
| 12:12 | fanquake | jonasschnelli Let me know whan you start working on that :) |
| 12:12 | jonasschnelli | fanquake, is up and running... http://macwallet.org |
| 12:12 | ziggy909 | jgarzik, would you maybe care to weigh in on this? |
| 12:12 | michagogo | hearn: Also, the hamburger menu looks weird |
| 12:12 | jonasschnelli | fanquake, but needs update and a c++ backend |
| 12:12 | hearn | michagogo: you mean the ui that appears when you click it? |
| 12:13 | fanquake | |
| 12:13 | hearn | michagogo: https://github.com/vinumeris/lighthouse/issues/122 |
| 12:13 | hearn | michagogo: the hamburger menu will show software updates once some have been pushed |
| 12:13 | michagogo | hearn: no, the menu icon itself |
| 12:13 | hearn | michagogo: oh, yeah. it sucks. |
| 12:13 | hearn | michagogo: the plan is/was that it actually pops up a menu |
| 12:13 | michagogo | The spacing, mainly |
| 12:14 | hearn | yes that is odd. i don't see that on my machine. the spacing is even. |
| 12:14 | jonasschnelli | fanquake, time is constraint 24/7. My priorities and more at bitcoin core level currently... |
| 12:14 | hearn | it looks like an issue with font rendering. this is windows 7? |
| 12:14 | michagogo | BTW, are there any options? |
| 12:14 | michagogo | testnet mode, etc? |
| 12:14 | fanquake | jonasschnelli yea assumed so. |
| 12:14 | hearn | michagogo: currently, no. you can put it into testnet mode or force it to use tor via the command line. |
| 12:14 | michagogo | Yeah, Windown 7 Home Premium 64-bit English |
| 12:14 | jonasschnelli | fanquake, people first has to trust bitcoin and bitcoin wallets,... when trust is built, small wallets can survive |
| 12:14 | hearn | but no ui options |
| 12:14 | michagogo | ? |
| 12:14 | michagogo | lighthouse.exe -testnet |
| 12:15 | hearn | michagogo: i noticed some other issues with FontAwesome on windows. not sure why. |
| 12:15 | hearn | michagogo: --help to see what's available |
| 12:15 | michagogo | Ah, thanks |
| 12:15 | jonasschnelli | hearn, lighthouse misses a about screen |
| 12:15 | michagogo | erm, --help just returned |
| 12:15 | jonasschnelli | hearn, osx: and copyright (currently it is "Copyright (C) 2015") |
| 12:16 | michagogo | hearn: to see what's available in what form? |
| 12:16 | 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 |
| 12:16 | hearn | michagogo: --help doesn't work on windows? |
| 12:16 | hearn | michagogo: ok try --net=test |
| 12:16 | michagogo | Apparently not? |
| 12:17 | michagogo | Is it supposed to return on the command line? |
| 12:17 | hearn | ok i haven't tested command line stuff on windows |
| 12:17 | hearn | oh, is the app already running? |
| 12:17 | hearn | if so try shutting it down first and waiting a few seconds |
| 12:17 | fanquake | |
| 12:17 | michagogo | No, not running |
| 12:17 | michagogo | (unless it runs in the background when closed, in which case that's bad because there's no tray icon) |
| 12:17 | 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 |
| 12:17 | hearn | fanquake: thanks! |
| 12:17 | michagogo | http://i.imgur.com/zumilig.png |
| 12:18 | michagogo | --net=test worked |
| 12:18 | michagogo | I assume it's SPV? |
| 12:18 | hearn | yes |
| 12:18 | hearn | you might see very variable sync performance at the moment |
| 12:19 | hearn | BreadWallet on iOS sees it too. something has changed with the network |
| 12:19 | michagogo | heh, if you enlarge the window with the create project view open the blur doesn't expand |
| 12:20 | hearn | yeah, i know. was wondering when someone would notice that |
| 12:20 | hearn | https://github.com/vinumeris/lighthouse/issues/104 |
| 12:21 | hearn | i punted it post beta because, well, i wanted to launch :) |
| 12:21 | michagogo | aaaaand it crashes |
| 12:21 | hearn | doh |
| 12:21 | michagogo | when trying to add an image |
| 12:21 | hearn | can you restart the app to let it submit the crash report please |
| 12:21 | michagogo | You should now have a crashlog, if the uploading thing is working :P |
| 12:21 | hearn | it uploads when the app is restarted |
| 12:21 | michagogo | It's running again |
| 12:21 | hearn | yep i see it |
| 12:22 | hearn | oh, that's a pain in the ass. looks like crash inside javafx |
| 12:22 | hearn | can you explain what you did in the file picker? |
| 12:22 | 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? |
| 12:22 | michagogo | hearn: pasted in an http url |
| 12:23 | hearn | .... |
| 12:23 | hearn | into the file picker? |
| 12:23 | michagogo | yes |
| 12:23 | hearn | you can do that on widnows? |
| 12:23 | michagogo | Yep |
| 12:23 | michagogo | Usually works, ime |
| 12:23 | hearn | since when? i didn't know windows could do that |
| 12:23 | michagogo | It goes gray for a bit, presumably as it fetches it |
| 12:23 | hearn | windows downloads the file for you? are you sure that's not some extension you installed? |
| 12:23 | michagogo | hearn: definitely not |
| 12:23 | michagogo | I don't know exactly how it works |
| 12:24 | hearn | btw you can drag the image from your browser onto the cover image in the create project screen |
| 12:24 | michagogo | but it does work, at least in Chrome |
| 12:24 | hearn | and then lighthouse will download it for you |
| 12:24 | 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. |
| 12:26 | hearn | ACTION learns something new every day |
| 12:35 | michagogo | Cool, I think it worked: https://www.dropbox.com/s/oel996zny5r2szs/steal-your-bitcoins.lighthouse-project?dl=0 |
| 12:36 | michagogo | Um, crashed again |
| 12:36 | michagogo | This time it was when saving a pledge |
| 12:36 | michagogo | (to a file) |
| 12:36 | wumpus | jonasschnelli: you want to have gitian build from a local repo? |
| 12:36 | jonasschnelli | wumpus, yes. |
| 12:37 | michagogo | Uh, WTF? |
| 12:37 | michagogo | hearn: http://i.imgur.com/Z7ovi4r.png |
| 12:37 | jonasschnelli | wumpus, i saw that gbuild is always loading from a remote |
| 12:37 | hearn | michagogo: see the faq |
| 12:37 | michagogo | What is that talking about? |
| 12:37 | wumpus | jonasschnelli: --url bitcoin=${URI} --commit bitcoin=${COMMIT} for URI, use the local directory name |
| 12:37 | michagogo | wumpus: That works? |
| 12:38 | wumpus | michagogo: I use it all the time |
| 12:38 | michagogo | I thought I tried that at some point and failed |
| 12:38 | jonasschnelli | wumpus, hmm... so easy? :) you mean a file:// scheme? or just the path /home/... |
| 12:38 | wumpus | jonasschnelli: no schemed needed, just a path |
| 12:38 | michagogo | (I ended up going into inputs/bitcoin and just fetching from the repo) |
| 12:38 | jonasschnelli | wumpus, ha. I started implementing a include of a possible pull request in ./gbuild. :) |
| 12:38 | wumpus | michagogo: well it was broken at one point, but it was fixed again also quite soon because I noticed |
| 12:38 | jonasschnelli | wumpus, thanks |
| 12:40 | wumpus | michagogo: (also I was the one to originally implement the --url option) |
| 12:40 | michagogo | hearn[lunch]: what feature is the one in question? |
| 12:40 | michagogo | Oh, getutxos? |
| 12:41 | jonasschnelli | wumpus, local file path works. thanks! |
| 12:59 | michagogo | hearn[lunch]: also, the uninstaller is broken |
| 13:00 | 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 |
| 13:32 | hearn | michagogo: i've uninstalled lots of times, not seen that. but i've only been testing on a clean win 8.1 install |
| 13:32 | hearn | michagogo: will try and reproduce, thanks for the report |
| 13:33 | michagogo | hearn: if it helps, somehow I ended up with a lighthouse.exe in the background, no GUI or tray icon |
| 13:33 | hearn | ah, hmm |
| 13:33 | michagogo | Maybe it's because that was running |
| 13:33 | hearn | perhaps it failed to uninstall because the app is running |
| 13:33 | hearn | yeah |
| 13:33 | hearn | that would make sense |
| 13:33 | hearn | i've seen one case where it can be slow to shut down the networking code |
| 14:52 | aschildbach_ | |
| 14:53 | aschildbach_ | I had the feeling it rots away slowly so had an urge to refresh it a bit. |
| 14:55 | hearn | yeah, makes sense |
| 15:16 | jonasschnelli | wumpus, IMO this can be merged: https://github.com/bitcoin/bitcoin/pull/5651 |
| 15:22 | wumpus | jonasschnelli: ack |
| 15:22 | jonasschnelli | wumpus, i also would see this going in: https://github.com/bitcoin/bitcoin/pull/5628 |
| 15:22 | jonasschnelli | maybe i'm a little bit a margin/pixel freak |
| 15:30 | wumpus | jonasschnelli: I'm not actually convinced that it looks better with the icons tightly against the right border |
| 15:31 | jonasschnelli | wumpus, maybe a matter of taste. :) it always buged me, the right padding. |
| 15:33 | dgenr8 | michagogo: interesting that you had the urge to paste the project URL somewhere inside the app <nudges hearn> |
| 15:33 | michagogo | dgenr8: hm? |
| 15:33 | hearn | i think he was pasting a url into the cover image picker |
| 15:34 | hearn | like a jpg file or something |
| 15:34 | michagogo | Yeah, I was |
| 15:34 | 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 |
| 15:34 | michagogo | That's an interesting question, though, what happens if you paste the URL to a project file into the file picker |
| 15:35 | hearn | probably also crashes. i think it can't handle this windows url-in-file-picker trick |
| 15:36 | michagogo | ACTION wonders what actually happens when you put a URL into a file picker |
| 15:37 | wumpus | does anyone know if it is possible on github to search pulls that touch a certain file? |
| 15:37 | 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 |
| 15:37 | michagogo | But maybe not |
| 15:37 | wumpus | michagogo: as you've seen the application crashes :) |
| 15:38 | michagogo | wumpus: eh? |
| 15:38 | michagogo | I mean more generally, what happens on the backend |
| 15:38 | 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. |
| 15:38 | michagogo | Because in at least some cases, it works as expected, with that file opening up |
| 15:38 | michagogo | wumpus: well, there's a short period where the buttons gray out |
| 15:39 | michagogo | I assumed that when that happens the file's being fetched |
| 15:39 | michagogo | ACTION shrugs |
| 15:39 | 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 |
| 15:39 | hearn | so i guess it's not entirely transparent |
| 15:40 | wumpus | not entirely :) |
| 15:42 | michagogo | hm, I wonder if Windows has the equivalent of lsof |
| 15:43 | wumpus | sysinternals |
| 15:44 | michagogo | ACTION googles |
| 15:49 | midnightmagic | all the sysinternals mechanisms are *excellent*, even though they were purchasd by microsoft a while back. |
| 16:00 | gdm85 | attended a speech by mark russinovich about future of C++, bright guy |
| 16:28 | wumpus | gdm85: what's the future of C++ according to him? |
| 16:37 | gdm85 | wumpus: sorry, it was like 2013.. I don't remember much :) |
| 16:40 | 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 |
| 16:43 | wumpus | gdm85: so yesterday's future of c++ ;) yes I interpreted your text as 'I *just* attended' |
| 16:53 | 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? |
| 16:53 | michagogo | jakl: yeah, it's a little bit broken like that |
| 16:54 | michagogo | I'm not sure why that check is there |
| 16:54 | michagogo | You can just comment it out |
| 16:55 | michagogo | Looks like it's right before the end |
| 16:58 | jrick | Luke-Jr: we are moving towards a hd wallet where accounts are groups of addresses each sharing the same account path |
| 16:59 | Luke-Jr | jrick: eck :/ |
| 16:59 | jrick | and balances are counted by utxos, not arbitrary numbers |
| 16:59 | Luke-Jr | jrick: basically sub-wallets then, not really accounts |
| 17:00 | jrick | sure |
| 17:00 | jrick | we know that's not compatible with how bitcoind implements accounts |
| 17:00 | jrick | but then again I'm not sure why anyone would want that... |
| 17:01 | Jouke | I always liked the accounts implementation, but I'll survive without it :P |
| 17:01 | Luke-Jr | jrick: it's much more useful than sub-wallets IMO :p |
| 17:01 | jrick | it's very non-intuitive |
| 17:02 | Luke-Jr | only because of n00b-confusers like blockchain.info, which confuse people even regardless of it |
| 17:02 | Luke-Jr | it's intuitive to people who understand bitcoin |
| 17:02 | Luke-Jr | there's no benefit to tying UTXOs to specific accounts |
| 17:02 | op_mul | (and a lot of downsides to doing it) |
| 17:03 | op_mul | (not least of all, you reveal a lot about the internal state of your system needlessly. |
| 17:03 | Jouke | op_mul: to subwallets? |
| 17:03 | op_mul | to tying UTXO to accounts. |
| 17:03 | justanotheruser | whats a subwallet, just an account in bitcoin core? |
| 17:03 | Jouke | yeah, exactly |
| 17:03 | Luke-Jr | no |
| 17:04 | justanotheruser | a subwallet is where they call an address a wallet? |
| 17:04 | Luke-Jr | justanotheruser: a subwallet is just multiple wallets, but with a common HD seed tying them together |
| 17:04 | 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 |
| 17:04 | op_mul | ACTION rolls eyes |
| 17:04 | justanotheruser | oh |
| 17:04 | Luke-Jr | jrick: that's bad design, though |
| 17:04 | op_mul | why? |
| 17:04 | op_mul | that's *terrible* on so many fronts. |
| 17:04 | jrick | if I don't care about that, I can select many accounts to select utxos from |
| 17:05 | justanotheruser | jrick: the only reason your software would want to spend specific UTXOs is because it's broken so utxos are accounts |
| 17:05 | wumpus | well it can make sense in some cases, if you don't want to bind together UTXOs from different subwallets |
| 17:05 | justanotheruser | s/so/in the way that/ |
| 17:05 | wumpus | e.g. the same reason people use coin control |
| 17:05 | jrick | justanotheruser: no, it's more for privacy reasons |
| 17:05 | jrick | I don't want to be mixing unreleated utxos |
| 17:06 | justanotheruser | actually that makes some sense. |
| 17:06 | Jouke | I would want to mix unrelated utxos for privacy reasons |
| 17:06 | justanotheruser | Jouke: in a world where almost no one coinjoins, that correlates two payments to you together |
| 17:07 | 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 :) |
| 17:07 | wumpus | justanotheruser: yeah... |
| 17:07 | Jouke | wumpus: who would I don't do that? |
| 17:07 | Jouke | Most of the txes are sendmany anyway |
| 17:07 | Luke-Jr | jrick: UTXOs are all unrelated in that aspect |
| 17:08 | Jouke | *know if |
| 17:08 | 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) |
| 17:09 | op_mul | wumpus: well, I would mark that as the services wallet not a particular users. |
| 17:10 | Luke-Jr | wumpus: not accurately |
| 17:10 | wumpus | e.g. to name a silly case, you may bind donations to your anti-employer blog to salary payments from said employer |
| 17:10 | wumpus | op_mul: but it's a valid use of subwallets. |
| 17:11 | jrick | the point is not to make mixing input selection impossible, but to make it explicit |
| 17:11 | wumpus | right |
| 17:11 | Jouke | I get what you are saying. Anyway, having a broader range of utxos will probably create more efficient transactions. |
| 17:11 | wumpus | it's the same idea as coin controll |
| 17:12 | Luke-Jr | jrick: making it explicit *encourages* people to try to assume UTXOs consumed are some kind of "from" |
| 17:12 | Luke-Jr | jrick: it actually makes the problem you want to solve worse |
| 17:12 | wumpus | Jouke: sure. It all depends on what you want |
| 17:12 | jrick | they are consumed "from" a some set |
| 17:13 | jrick | they are placed in that set by the address they were received from |
| 17:13 | jrick | but they are not sent from those addresses |
| 17:13 | jrick | in fact we want to discourage address reuse as much as possible |
| 17:13 | wumpus | jrick: by the address they're sent *to* I hope? |
| 17:13 | jrick | so one time receiving addresses |
| 17:13 | jrick | wumpus: yeah |
| 17:14 | op_mul | keep in mind that one time receiving addresses won't give you service level privacy. |
| 17:14 | wumpus | Jouke: in the case of e.g. an exchange it makes little sense to have accounts as subwallets |
| 17:14 | jrick | but you don't have to convince me that there is no from address :p |
| 17:14 | jakl | I'm getting "error genesis block not found" when I try to create a bootstrap.dat starting with min_height>1 |
| 17:15 | wumpus | Jouke: it'd be extremely inefficient, as every internal transaction would have to be on the blockchain |
| 17:15 | op_mul | wumpus: and that in itself would be very revealing. |
| 17:15 | 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" |
| 17:15 | Jouke | jrick: you wouldn't know how many calls and support messages we receive regarding "from" addresses :) |
| 17:15 | wumpus | jakl: you have to start at the genesis block |
| 17:15 | Luke-Jr | jrick: also, what wumpus points out: you lose off-chain transaction capability |
| 17:16 | wumpus | Luke-Jr: more like 'choose not to have' |
| 17:16 | 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" |
| 17:16 | jrick | Luke-Jr: but they are related. the addresses you received to belong to the same account |
| 17:16 | Jouke | wumpus: good point :) |
| 17:16 | 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 |
| 17:16 | jrick | how you use those groups are up to you |
| 17:16 | helo | does it handle the case when an address receives a payment in multiple parts? |
| 17:16 | davec | so wallet no longer has to spend resources looking for pyaments to it, loading it from the db, etc |
| 17:17 | helo | (of course it wouldn't lose the funds, but for UI cohesiveness) |
| 17:17 | Luke-Jr | wumpus: a software decision is not necessarily a user decision |
| 17:17 | 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 |
| 17:17 | Luke-Jr | jrick: the addresses you received to have nothing to do with the UTXOs |
| 17:18 | jrick | yes they are |
| 17:18 | wumpus | jakl: yes, but as it is implemented right now you need to start at the genesis block |
| 17:18 | Luke-Jr | jrick: no, otherwise you have from addresses |
| 17:18 | wumpus | jakl: I guess you could remove that check or make it optional |
| 17:18 | jrick | the output script is specific to that address |
| 17:19 | Luke-Jr | jrick: it isn't. |
| 17:19 | jrick | the address is just a means to easily receive payments, but you still need that key to sign a transaction with spends it |
| 17:19 | jrick | *which |
| 17:19 | Luke-Jr | jrick: the keys are independent from the address |
| 17:20 | jrick | the address is derived from the key |
| 17:20 | Luke-Jr | technically, but that's just an implementation detail |
| 17:20 | helo | that sits in the house |
| 17:20 | Luke-Jr | the association with the address ends when the transaction is received |
| 17:21 | 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? |
| 17:22 | 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) |
| 17:22 | jrick | oh don't let us stop you from removing it |
| 17:22 | Luke-Jr | (I sure hope you'll call them sub-wallets or some term that indicates they are not accounts, btw) |
| 17:22 | jrick | please kill it |
| 17:22 | jrick | kill it dead |
| 17:23 | Luke-Jr | jrick: no, my point is that people currently using it need a migration path, before they can be removed nicely |
| 17:23 | jrick | we can do that |
| 17:23 | Luke-Jr | not unless you add account support :p |
| 17:23 | jrick | since the behavior is different from bitcoind accounts |
| 17:23 | jrick | oh |
| 17:23 | jrick | you're saying to shift bitcoind wallet users to our wallet? |
| 17:23 | 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 |
| 17:23 | jrick | as a migration path? |
| 17:24 | Luke-Jr | jrick: yes, if btcd's wallet supported accounts |
| 17:24 | wumpus | petertodd: why not fund one of the existing wallets? |
| 17:24 | 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. |
| 17:24 | jrick | yeah that won't work, sorry |
| 17:24 | Luke-Jr | petertodd: what wumpus said |
| 17:24 | op_mul | make a new wallet. in javascript. |
| 17:24 | Luke-Jr | justanotheruser: I don't know a better way to explain that |
| 17:24 | 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 |
| 17:24 | Luke-Jr | ACTION stabs op_mul |
| 17:25 | op_mul | Luke-Jr: everything's a float! |
| 17:25 | 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 |
| 17:25 | jrick | I'm pretty sure the current accounts behavior can be simulated using an external ledger |
| 17:25 | jrick | but then you still break api compatibility |
| 17:25 | op_mul | of course they can. |
| 17:25 | Luke-Jr | petertodd: Bitcoin Core's wallet isn't client-side targetted. Funding could be put to split it out and improve it. |
| 17:26 | petertodd | wumpus: very different target audience unfortunately, though possibly starting with an existing wallet might help |
| 17:26 | Luke-Jr | jrick: yes, mostly. that's the goal. |
| 17:26 | justanotheruser | petertodd: ask them to fix bit-c please |
| 17:26 | wumpus | petertodd: that could change though, with funding |
| 17:26 | Luke-Jr | jrick: although you'd want to use a HD chain to generate the addresses still IMO |
| 17:26 | 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 |
| 17:27 | Luke-Jr | petertodd: possibly |
| 17:27 | Luke-Jr | in fact.. probably |
| 17:27 | Luke-Jr | could reuse the new logdb stuff though ;) |
| 17:28 | 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... |
| 17:28 | op_mul | petertodd: please have it written in something sane :< |
| 17:28 | 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. |
| 17:29 | justanotheruser | Luke-Jr: what do you think of proof of solvency? Isn't it just as bad as address reuse for security? |
| 17:29 | Luke-Jr | justanotheruser: I don't think so, but I didn't look over the specs |
| 17:30 | 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 |
| 17:31 | justanotheruser | petertodd: does it use some fancy math to prevent your pubkey from being revealed? |
| 17:32 | 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 |
| 17:32 | justanotheruser | link? |
| 17:32 | petertodd | justanotheruser: http://www.mail-archive.com/[email protected]/msg04404.html |
| 17:32 | justanotheruser | thanks |
| 17:34 | petertodd | justanotheruser: sorry that I did such a shit job writing it up there; very unclearly written |
| 17:36 | justanotheruser | if you're talking about what you said in IRC, I don't think I would understand it withuot reading the writeup anyways |
| 17:37 | 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 |
| 17:37 | justanotheruser | First I'm reading the pre-req "From Identification to Signatures via the Fiat-Shamir Transform: Minimizing Assumptions for Security and Forward-Security" |
| 17:37 | cfields | wumpus: agreed. I've kicked myself a hundred times for not doing that to start with :\ |
| 17:38 | wumpus | cfields: it's hard to come up with a rule though. We'd need a whitelist instead of a blacklist :) |
| 17:38 | cfields | wumpus: hmm, that's a decent idea, actually. you can use */ and !packages, for example |
| 17:39 | cfields | wumpus: though the correct fix would be to just move them to a subdir in a one-time breaking move |
| 17:39 | wumpus | cfields: ncie! |
| 17:39 | wumpus | cfields: yes, though I do kind of like the flat structure |
| 17:39 | 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 |
| 17:40 | wumpus | yep |
| 17:40 | cfields | great idea. I'll give it a shot |
| 17:40 | 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. |
| 17:41 | 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 :) |
| 17:41 | petertodd | op_mul: yes, although I don't know of any bitcoinj-based wallets that have a bitcoind compatible RPC interface |
| 17:41 | 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 |
| 17:41 | cfields | wumpus: ah, heh. at one point the process was make && make install, but i removed that. probably botched the docs cleanup |
| 17:42 | 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 |
| 17:42 | 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 |
| 17:42 | op_mul | petertodd: you wouldn't believe how many people use that. to tears man, it beings me to tears. |
| 17:42 | 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 |
| 17:43 | 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) |
| 17:43 | cfields | ok |
| 17:44 | wumpus | cfields: will move it to src/qt/test_main.cpp |
| 17:45 | 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. |
| 17:46 | 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 |
| 17:47 | 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. |
| 17:49 | 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. |
| 17:50 | 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. |
| 17:50 | 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 |
| 17:51 | 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 |
| 17:51 | wumpus | op_mul: yes, the state of javascript libraries is the most sad of all, and unfortunately those get used a lot |
| 17:51 | petertodd | op_mul: that's why non-deterministic builds are scary... |
| 17:52 | wumpus | op_mul: javascript is also the exception to ''use a proven library" as it doesn't have any binding possibilities |
| 18:49 | jtimon | Luke-Jr #5648 has been merged with a small commit from your policy branch |
| 19:40 | gavinandresen | |
| 20:00 | akstunt600 | Thanks gavinandresen |
| 20:00 | akstunt600 | You answered actually everyone of my questions. |
| 20:00 | akstunt600 | answered* |
| 20:04 | cfields | wumpus: what are the blockers for rc4? |
| 20:36 | Luke-Jr | hm, bad_alloc with 512 MB RAM :x |
| 20:37 | paveljanik | 1G works though ;-) |
| 20:38 | paveljanik | I'm running a testnode at home on banana pi. |
| 20:42 | wumpus | cfields: I don't think there are any |
| 20:43 | wumpus | cfields: there have been no problems with rc3 that I know of |
| 20:45 | Luke-Jr | paveljanik: mine is on a USB Armory stick |
| 20:45 | cfields | wumpus: the qt unicode problem was the only thing that i've seen. Any reason to delay tagging rc4? |
| 20:46 | wumpus | cfields: well I don't know how much time you want to give people to test a rc |
| 20:46 | cfields | wumpus: no rush, just curious |
| 20:47 | 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!' |
| 20:47 | cfields | wumpus: well hurry up and do that so we can tag rc5 in 10 min :) |
| 20:48 | cfields | joking ofc. was really just a matter of curiosity |
| 20:49 | wumpus | cfields: lol |
| 20:49 | 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 |
| 20:50 | wumpus | cfields: but you know no other pulls that should still be backported into 0.10 either? |
| 20:50 | wumpus | well from experience these are not usually the things people work on beforehand |
| 20:50 | cfields | wumpus: none on my radar |
| 20:50 | 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 |
| 20:51 | wumpus | meh |
| 20:51 | cfields | but i never brought it up because i'm not convinced it's worth the trouble |
| 20:52 | wumpus | it isn't; usually easy enough to backport things if it's needed, refactors or not |
| 20:52 | wumpus | (at least, over the trivial refactors, and the less trivial stuff you don't really want to backport i nthe first place) |
| 20:53 | op_mul | cfields: luke still gets surprised about things that were merged months ago |
| 20:54 | cfields | op_mul: well i kinda like to see him worked up, so that's fine by me :) |
| 20:55 | Luke-Jr | ? |
| 20:56 | 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.. |
| 20:56 | 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 |
| 20:56 | cfields | wumpus: sounds good |
| 20:57 | 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 |
| 20:58 | Luke-Jr | hm |
| 20:58 | Luke-Jr | 0.10 will be a popular release, maybe we should wait for it |
| 20:58 | wumpus | it's already slipping too much |
| 20:58 | gavinandresen | |
| 20:58 | op_mul | Luke-Jr: I think .0 releases get a lot more poeple updating to them than .x releases. |
| 20:58 | wumpus | also it would be a last-minute hack to add anything substantial in rc4 |
| 20:59 | cfields | wumpus: yea, that's a really scary time to be making policy changes |
| 20:59 | Luke-Jr | gavinandresen: hm, okay. |
| 20:59 | Luke-Jr | op_mul: that was my point |
| 20:59 | wumpus | well, then we'll just do 0.11 |
| 20:59 | op_mul | Luke-Jr: I was agreeing with you. |
| 21:00 | sipa | wumpus: i'm very nearly done with thre DERSIG bip |
