--- Log opened Sun Nov 24 00:00:03 2013
03:20 < michagogo|cloud> cfields: have you tested with an LXC of precise with a rating host?
03:21 < michagogo|cloud> Luke-Jr: why not?
03:27 < cfields> michagogo|cloud: that's what i'm using now, yes
03:29 < michagogo|cloud> cfields: ah, okay
04:12 < Luke-Jr> michagogo|cloud: because without the ability to append data, it'll only produce a single block header (4 Gh)
04:30 < Luke-Jr> UGH, Electrum added a "send from" nonsense
04:33 < Luke-Jr> sigh, he doesn't even understand why there's a problem
04:34 < Luke-Jr> amazing how easy it is to write broken wallet software
04:35 < Emcy> send from is intuitive though
04:35 < Emcy> wrong but intuitive
04:38 < michagogo|cloud> uh.
04:38 < michagogo|cloud> seriously?
04:38 < michagogo|cloud> o_O
04:38 < michagogo|cloud> Luke-Jr: Well, I guess you could allow appending data but reject appended data that was another quote if you really wanted to :-P
04:38 < Emcy> 'from' is an abstraction of whats really going on that probably works for how most poeple are sending bitcoins right now
04:39 < Emcy> until they try to use it as a return path or something
04:39 < michagogo|cloud> Emcy: Right. And that happens all the time.
04:40 < Emcy> yeah well there are a LOT of bad practises going on in bitcoin that are going to cause major problems in future and could prove intractible with time
04:41 < Emcy> thats what happens when your little experiment project gets used in production for billions worth of value whether you like it or not
05:22 < sipa> yup
07:45 < warren> https://bitcointalk.org/index.php?topic=343901.0
07:45 < warren> "Bitcoin core Qt maintainer"
07:45 < warren> John Smith
07:45 < warren> never seen that name before
07:45 < sipa> warren: that's wumpus aka laanwj
07:46 < warren> hah
07:46 < sipa> he has always used that name on the forum, afaik
07:46 < wumpus> yes
07:51 < wumpus> I'd like to change it to wumpus but it's no longer possible to do it yourself and I don't feel like bothering admins and such, also becase I don't really like the forum much and don't intend to spend too much time there
08:20 < michagogo|cloud> wumpus: well, you could put that in your signature...
08:26 < gmaxwell> wumpus: just send theymos a message, it would take you like two seconds. :)
08:27 < gmaxwell> okay, 10 seconds since you might want to pgp sign it. :)
08:28 < warren> gmaxwell: I already did
08:29 < Emcy> i read about the name change thing
08:30 < Emcy> fwiw i support changing it to Bitcoin Core. It might go some way to explaining to people what the satishi client actually does that all the others dont, and why its caning the hell out of thier computer when the others dont
08:31 < wumpus> yes, agreed, it needs to change name, it's less important what name
08:31 < warren> split the consensus part from the wallet...
08:31 < Emcy> well like i said bitcoin core is about as explanitory as you can get whilst keeping it a title and not a synopsis
08:32 < Emcy> also people like cores and stuff, it sounds cool. And people like to be in the centre of things
08:32 < wumpus> warren: that's what we're working on (with nowallet mode and such)
08:33 < wumpus> would be nice to have the code in different directories as well
08:33 < michagogo|cloud> Hmm, I was going to write a post on bct to try and recruit gitian builders
08:34 < michagogo|cloud> I guess I never got around to it
08:34 < michagogo|cloud> Hmm, now that I think about it I'm not sure what I'd say in such a post
08:35  * michagogo|cloud is not very good at writing…
08:45 < petertodd> wumpus: I asked to s/retep/Peter Todd/ on the forum and theymos changed it literally within about 45 seconds
08:46 < warren> how recently?
08:46 < petertodd> warren: like 5 hours ago
08:48 < warren> I wonder if "warren" is taken
08:48 < warren> probably
08:49 < wumpus> petertodd: nice
09:36 < TD> it seems you can't set forum photos anymore either
09:36 < TD> i tried a few weeks ago and it just ignored me
09:36 < TD> it blows my mind that theymos is sitting on such a huge pile of bitcoins and does absolutely zip with it
09:37 < pigeons> yes i also treid a few days /weeks ago to set the photo and it idnt work
09:38 < gmaxwell> The photo stuff is disabled because it was custom code that was potentially vulnerable.
09:39 < gmaxwell> A bunch of stuff was disabled after the compromise was discovered and its been gradually getting re-enabled.
09:39 < gmaxwell> (a bunch of it is moderator tools, so the progress may not be generally visible to all users)
09:57 < michagogo|cloud> TD: what do you mean?
09:58 < TD> mean by what?
09:58 < michagogo|cloud> Your most recent message
09:59 < TD> a long time ago theymos asked for a lot of donations in order to raise money for writing a new forum, or making major upgrades
10:00 < TD> he got thousands of coins
10:01 < petertodd> enough money to hire a team of bitcoin people away from their dayjobs...
13:06 < michagogo|cloud> o_O
13:06 < michagogo|cloud> ...thousands?
13:06 < michagogo|cloud> That's a seriously huge bounty...
13:07 < michagogo|cloud> I suspect there are people who would be happy to write an entire forum system from scratch if it meant becoming a multimillionaire.
13:07 < TD> well, as the value went up it seems he lost interest in developing new forum software
13:08 < gmaxwell> The forum funds are used for more than just software though, e.g. moderators get paid a bit, it pays for hosting (which is non-trivial, as the bct forum is a highly trafficed site and gets DOS attacked a lot)
13:09 < gmaxwell> He's currently trying to negoiate with the SMF folks to get SMF 1.0 open sourced so he can opensource the whole forum. Dunno ho[D[D[Dw thats going.
13:09 < sipa> what? the forum code is not open source? :o
13:10 < gmaxwell> no, apparently the later versions of SMF are but the earlier (and more popular) versions are not or something.
13:10 < gmaxwell> And the one bct runs is heavily modified, including a lot of security fixes.
13:11 < gmaxwell> (like, uh, hashed and salted passwords 0_o)
13:13 < TD>  from what i know of SMF open sourcing it would probably be a security disaster ...
13:13 < TD> vanilla forum is nice
13:14  * sipa mumbles "security through obscurity"
13:20 < gmaxwell> adam3us: https://bitcointalk.org/index.php?topic=258678.msg3698304#msg3698304 < what are your thoughts on a simple delegation like this?
13:21 < gmaxwell> adam3us: it doesn't have the nifty information-theoretic blinding, so it makes the KDF weak to an attacker who has already performed the KDF for the user.
13:21 < gmaxwell> adam3us: but I think the prospect of getting people to implement the RSA blinding scheme is ~0, plus I think we really do want memory hard KDFs.
13:27 < gmaxwell> sipa: I dunno if you saw, but a while back adam3us pointed out that using a group that permits a trapdoor permutation you could have a delegatable blind KDF.  E.g. you pick a random blinding factor and blind your password, then give it to miners who crunch on it then give you the result, and then you unblind the password.
13:27 < gmaxwell> sipa: and the work they did is of no use to them trying to also crack your key, because they don't know the blinding factor.
13:28 < sipa> i'm not following
13:30 < gmaxwell> E.g. You can  Encrypt(password,nonce) -> Epwd    and give Epwd  to 'KDF miners' who do expensive computation on it and return Eresult   and then you can Decrypt(Eresult,nonce).
13:30 < sipa> right
13:30 < gmaxwell> But in doing so they learned nothing that would help them shortcut cracking your wallet.
13:30 < gmaxwell> e.g. if later they got a copy of your wallet.
13:30 < gmaxwell> (or even if they already had it, and simply wanted you to pay for the work of cracking it)
13:31 < gmaxwell> I think its neat though I dunno if its useful, simply because its complicated to implement, more complicated to explain, and we'd probably prefer memory hard KDFs.
13:32 < gmaxwell> Though the notion of delegation is probably a good one: any of these wallet encryption schemes should be setup so that you could ask a marginal trusted party to do the expensive KDF for you, without totally giving away your keys.
13:32 < gmaxwell> might make them easier to tolerate for things like hardware wallets.
13:33 < gmaxwell> Sadly the simple way of constructing these things means the party you delegate to at least no longer has to face the difficult kdf anymore.
20:32 < midnightmagic> what?!  smf isn't open source?
20:33 < theymos> 1.x uses a non-free license. 2.x is open source.
20:33 < theymos> I asked them for an exception to the 1.x license so I could distribute my modifications, and even offered to pay, but they never got back to me.
20:34 < sipa> that doesn
20:34 < midnightmagic> Ah. It's open source, but it's not licensed openly. You need permission to fork.
20:34 < sipa> wait, what meaning of open sourc... right, that
20:39 < midnightmagic> theymos: That's b-s man. They should've given you an answer.
20:39  * midnightmagic is grumpy now
20:41 < phantomcircuit> theymos, i guess they dont understand how much you could pay
20:41 < phantomcircuit> lol
20:41 < theymos> bitcointalk.org even has some small modifications by Satoshi. I might publish those in isolation for historical interest. I think that this is legal.
20:50 < cfields> https://github.com/theuni/bitcoin/tree/deterministic-dmg
20:51 < cfields> how do you guys recommend i start the discussion? RFC pull-request?
20:51 < cfields> dmg's are deterministic via gitian and verified working fine on 10.6 and 10.8
20:52 < Luke-Jr> Meetup at [or near] my place tomorrow, anyone? (Broooksville, Florida)
20:54 < cfields> in its current form it's not really reviewable. I'll need to break it up into chunks. But it'd be nice if I could convince someone to verify my gitian results
20:55 < Luke-Jr> cfields: throw the gitian files in a temp git repo somewhere?
20:55 < cfields> Luke-Jr: they're in there
20:55 < Luke-Jr> ah missed that
20:56 < cfields> osx-native -> osx-depends -> osx-qt -> osx
20:57 < Luke-Jr> I'd have split each depend out individually
20:57 < cfields> Luke-Jr: you'll need the sdk too. I can spare you the trouble of registering and extracting it if you'd like
20:57 < cfields> Luke-Jr: i did all the work native. Gitian was an afterthought
20:58 < Luke-Jr> what *is* osx-native? O.o
20:58 < cfields> Luke-Jr: https://github.com/theuni/bitcoin/commit/8a64fb98370ccc299d73111bbf97cdde23f681b1#diff-8
20:58 < Luke-Jr> yes, that's what I'm looking at
20:59 < cfields> osx-native builds the build-side tools
21:01 < cfields> er, i suppose osx-native is confusing, since that probably implies that they run on osx
21:01 < cfields> rather, it means the tools for the native arch to build osx binaries
21:03 < Luke-Jr> IMO everything except the final Bitcoin-Qt .yml file should probably live in its own git repo
21:03 < Luke-Jr> independent of any program
21:03 < cfields> Luke-Jr: it's just in one repo for convenience right now
21:03 < Luke-Jr> sure
21:04 < Luke-Jr> I presume you saw my cross-osx repo
21:04 < cfields> translation: don't bother pointing out how ugly it is, i already know :)
21:04 < cfields> i'd just like a little input as to what people want before i sit down to actually organize it
21:05 < Luke-Jr> any reason not to use CXXFLAGS for -target?
21:05 < cfields> for ex, to me, it's important to be able to build without gitian. Imo that's a nasty dependency
21:05 < cfields> but if i'm alone, i'll toss that out
21:05 < Luke-Jr> what if gitian produces archives usable by other OS?
21:06 < cfields> hmm?
21:06 < Luke-Jr> otoh, as long as it's outside the bitcoin repo, I guess it makes just as much sense to have it designed to build outside too
21:06 < Luke-Jr> cfields: I was thinking "let gitian build the cross development stuff, and make it usable without gitian"
21:07  * Ryan52 waves
21:07 < cfields> it can build anywhere, its location is arbitrary
21:07 < cfields> you can just cp -rf the folder wherever you want
21:07 < Luke-Jr> but it might make better sense to just have the new cross-osx git repo work without gitian to do the same, and just a few .yml files to utilise that
21:07 < warren> cfields: I have Ryan52 looking into the integrity of all your gitian mac inputs, comparing downloads from multiple Linux and ports distros, looking at diffs from previous versions to look for compromised source, then generating a list of identical download URL's  and sha256sums
21:08 < warren> cfields: https://github.com/bitcoin/bitcoin/pull/3191  that'll allow adding simple integrity checks like this.
21:09 < cfields> warren: yep, i'll add those
21:09 < cfields> warren: as a quick hack though, you saw this: https://github.com/theuni/bitcoin/blob/deterministic-dmg/contrib/macdepends/download.sh ?
21:10 < warren> cfields: ooh, ok, so Ryan52 should just verify that things match your checksums
21:11 < warren> Ryan52: sorry, didn't know he already had checksums.  This is just another sanity check.
21:11 < cfields> ./download.sh is all that's necessary, yes
21:11 < cfields> Ryan52: if you're going to verify sanity, the one you really need to target is the MacOSX10.6.pkg
21:12 < cfields> that's a pain in the ass to get. So i assume it will end up being passed around privately rather than being extracted from the source
21:12 < cfields> for ex, i was about to send Luke-Jr a link to it so he could avoid the hassle
21:12 < cfields> so if you could verify that, it'd be a big help
21:13 < warren> cfields: it's a good idea to have https://github.com/bitcoin/bitcoin/pull/3191 style build-time checks too.  When Litecoin began gitian I didn't give the team URL's to download inputs at all.  told them to find it from random locations.
21:13 < cfields> warren: sure. I just threw that together quickly. I agree with your approach
21:13 < warren> cfields: ok great, Ryan52 knows what to do.
21:14 < warren> Ryan52: please document all paranoid extra checks done, it will be part of the code review for that massive PR.
21:14 < cfields> i really can't stress it enough: It's not worth reviewing that commit. It's still very chaotic. Only worth ack'ing that it works, then discussing wtf to do with it
21:14 < cfields> at that point, i'll organize it into something more reasonable
21:16 < Ryan52> warren, cfields: will do, thanks for the advice.
21:19 < cfields> Ryan52: you have a mac at your disposal?
21:19 < warren> cfields: oh yeah, please ask Ryan52 for help with QA.  He's a good coder too.
21:19 < warren> cfields: we'll donate to him for specific goals that we think are important
21:19 < cfields> ok
21:20 < cfields> verifying that .pkg will be much easier in osx
21:21 < Ryan52> cfields: yes, I do, but I'm not too familiar with development on osx yet to be honest (mostly a linux dev historically)
21:22 < cfields> Ryan52: no worries. register for an app dev account at apple, grab the dmg, mount it, cd into it from a shell, and md5 it
21:22 < cfields> https://developer.apple.com/devcenter/download.action?path=/Developer_Tools/xcode_3.2.6_and_ios_sdk_4.3__final/xcode_3.2.6_and_ios_sdk_4.3.dmg
21:23 < Ryan52> cfields: thanks!
21:25 < Ryan52> cfields: sha256, or md5 too?
21:26 < cfields> Ryan52: sorry, i'm used to md5ing for quick verification. sha256.
21:26 < Ryan52> heh, thought so, me too :)
22:08 < warren>  https://bitcointalk.org/index.php?topic=337294.0;all  MacOS X corruption fix bounty now increased to 10 BTC + 200 LTC thanks to new a pledge from BitcoinTalk.
22:13 < cfields> Ryan52: i had to step away for a bit. having any luck?
22:13 < Ryan52> cfields: Yes, verified the MacOSX10.6.pkg in my downloaded .dmg matches.
22:14 < cfields> ok, great. So if anyone else want to try to build with gitian, i can provide that file to spare you the trouble
22:15 < warren> cfields: it's available to anyone with an apple dev account?
22:15 < Ryan52> cfields: I'm working my way through the rest of the list to verify, but will have to stop halfway through that and leave in a couple minutes. Can come back in ~5 hours to finish it, but I'll submit my work in progress.
22:15 < Ryan52> warren: if you're willing to download the 4GB .dmg it's a part of :)
22:15 < cfields> warren: yea, it's necessary to build. Anyone who's built bitcoin for osx has downloaded it at some point
22:15 < warren> 4GB!?
22:16 < cfields> warren: only one file is needed from it, and it's ~50mb iirc
22:16 < warren> cfields: so the gitian VM must be *much* larger, or you extract something from it?
22:16 < warren> ah
22:16 < cfields> which is why i'm offering to provide that file to anyone who needs it, rather than going through that mess
22:16 < warren> as long as Ryan52 verified it I want the 50MB file
22:16 < warren> I don't have much time
22:17 < Ryan52> Yep, I also recorded the sha256 of the .dmg it came from, in case somebody wants to compare notes on that, at some point.
22:18 < Ryan52> (tho as long as the 50MB file is fine, that doesn't make much difference)
22:18 < cfields> 2ad43957613642f29166dd452662a2adeecb8b69e01ca373f2cb47fbe42764fc  xcode_3.2.6_and_ios_sdk_4.3.dmg
22:19 < warren> oh, I have that
22:19 < Ryan52> 2e666a972c616a35fed5790265fb5aa61ef74ea7c36e4e5a11261df00008822c  Downloads/xcode_3.2.6_and_ios_sdk_4.3.dmg
22:19 < Ryan52> That is odd. I wonder if Apple embeds our developer ID, or if mounting it causes the checksum to change.
22:20 < warren> hmm, what macports has sha256sum?
22:20 < Ryan52> (mine is of a copy before mounting)
22:20 < warren> Ryan52: oh damn
22:20 < cfields> Ryan52: hmm, maybe. that's good to know
22:20 < cfields> so the dmg checksum is uninteresting, but the pkg counts.
22:21 < Ryan52> Right.
22:21 < warren> how do I get sha256sum on mac?
22:22 < cfields> shasum -a 256
22:23 < cfields> Ryan52: not sure what list you're verifying?
22:23 < warren> I wish macports gnupg worked.  it fails to build.
22:27 < Ryan52> cfields: the list of checksums in your download script.
22:28 < cfields> Ryan52: i'm not sure what there is to verify manually?
22:30 < warren> cfields: as noted earlier, check against download sources of various linux distros and ports to be sure it's exactly the same as what everyone else is shipping.  If something is very new and not widely distributed yet, then manually examining the diff from the old version.
22:31 < cfields> mm, ok
22:31 < warren> cfields: if we're giving people a download.sh and hard-coded checksums we better be damned sure we didn't accidentally pull in something bad
22:31 < cfields> fwiw, i reused the tarballs i already had laying around mostly
22:31 < warren> that's fine.  another paranoid check is worthwhile.
22:31 < cfields> meaning: existing win32/linux dependencies
22:31 < warren> oh?  I noticed you upgraded boost.
22:31 < warren> you upgraded nothing else?
22:31 < cfields> so before going to that trouble, might want to see if we're already using em
22:32 < cfields> for the more complicated ones i took the macports version
22:32 < warren> Ryan52: the checksums already in contrib/gitian-descriptors/*.yml have been verified by me and the entire litecoin team redundantly.
22:32 < cfields> so that i could more easily re-use their patches
22:32 < warren> cfields: did you upgrade qt?
22:32 < cfields> yes, x.y.5
22:33 < cfields> 4.8.5 i think?
22:33 < Ryan52> Here is my WIP "notebook": http://pastebin.ca/raw/2478933
22:33 < cfields> same reason. Notice it has about 30 patches in play. I didn't want to waste the macports work on that
22:33  * Ryan52 has to go do other things for some hours, but can continue looking at things in a long while
22:34 < warren> Ryan52: if we're satisfied with this, time to move on to the external ip review.
22:34 < warren> Ryan52: write a good report on what you reviewed, how and maybe debug print patches
22:34 < cfields> also worth noting that regardless of any investigation, these are the versions that have been in-play on osx due to their use in macports anyway
22:34 < warren> I did that myself but I might have missed something.
22:34 < Ryan52> I did try to see if there were gitian-descriptors already, but not many did have them.
22:35 < cfields> you guys are really getting a bit ahead here, anyway. First step is to have someone else verify that it builds and works, then discuss with the other devs whether the approach is reasonable for releases or not
22:36 < Ryan52> Hm, okay. So should I just document my verification of the MacOSX10.6.pkg then, since that's the only I was really "done" with? Where is best to do that?
22:37 < cfields> Ryan52: how bout commenting on my commit, so it's visible to anyone else looking over it?
22:38 < cfields> at github, that is
22:38 < Ryan52> cfields: Alright, wasn't sure if there would be a more relevant PR or BR, thanks!
22:39 < cfields> Ryan52: i'm still not quite sure how to handle it. need a recommendation from a veteran
22:39 < cfields> gavinandresen: ping
22:40 < warren> BR?
22:41 < Ryan52> warren: bug report, sorry I abbreviate too much sometimes :)
22:42  * Ryan52 isn't sure if that is proper github terminology, since it calls them issues, doesn't it?
22:45 < Ryan52> cfields: Here's your comment: https://github.com/theuni/bitcoin/commit/8a64fb98370ccc299d73111bbf97cdde23f681b1#commitcomment-4688671
22:45 < cfields> Ryan52: thanks
22:54 < warren> 9c5424e26fb10836ebfc602d61d5e4f984a9ce33d327877dd51405b08b977ac5  xcode_3.2.6_and_ios_sdk_4.3.dmg
22:54 < warren> looks like it does change it by mounting =(
22:55 < Ryan52> eh, as long as the pkg matches we have verification. that sure is annoying tho.
--- Log closed Mon Nov 25 00:00:06 2013