--- Log opened Fri Nov 22 00:00:56 2013
04:54 < warren> NMC is now $2.65 ...
04:54 < TD> back from the dead, huh
04:58 < warren> undead
04:58 < warren> TD: somehow BBQCoin is still alive
04:59 < TD> even the name of that coin makes me smirk
04:59 < TD> lol. BQC Foundation
04:59 < TD> given how controversial the creation of the foundation was, alt coins sure love the idea
05:11 < petertodd> warren: interesting, namecoin diff is 471M, btc diff 695M, so it is 51% attack secure as a merge-mined coin
05:11 < petertodd> warren: IIRc for a while it was looking a fair bit worse than that
05:34 < michagogo|cloud> Um, BBQCoin?!?
05:34 < michagogo|cloud> ;;google bbqcoin
05:34 < michagogo|cloud> Oh, no gribble
06:02 < sipa> we are gribbless
06:03 < michagogo|cloud> Any specific reason?
06:03  * michagogo|cloud wonders if there's an altcoin called altcoin yet
06:26 < wumpus> not according to this list http://coinchoose.com/
06:27 < warren> I've come to realize all the scrypt clones are actually useful for something.
06:28 < warren> although I can't tell them what that is.
06:28 < wumpus> there are HoboNickels though, does that come close enough? :p
06:29 < warren> I can't imagine why anyone wouldn't want to use it with that name.
06:30 < wumpus> right, I can't imagine bitcoin would have taken off with that name
06:31 < warren> wumpus: http://coinchoose.com/charts.php  this is a more interesting chart
06:31 < warren> Pac Man
06:33 < wumpus> like a pacman eating all the other coins
06:42 < warren> heh
06:57 < Emcy> percentage of chart that looks like pacman: 85.80
07:46 < michagogo|cloud> 13:28:02 <warren> although I can't tell them what that is.
07:46 < michagogo|cloud> Why not?
09:11 < adam3us> michagogo|cloud: suspecting its like evolution in action and he doesnt want to disrupt the process by renting them a clue ;)
09:12 < michagogo|cloud> Now I'm curious :-/
09:13 < gmaxwell> "Prime directive"
09:14 < michagogo|cloud> okay, I need to go get dressed -- Shabbat Shalom and I'll see you tomorrow night
09:25 < n0g> Good morning, everyone. *hugs*
09:42 < adam3us> y'know i've been musing about subliminal channels and smart-card wallet with observer protocols from Brands and others for eg the trezor.  some people opined that well why should i trust a trezor wallet.  well indeed - trust no one - thats the point of crypto currency
09:43 < adam3us> so with these observer protocol the smart card subliminal channels are 100% plugged its only "communication" is logical level one-bit at a time by failing with an error msg instead of signing, which you're going to notice
09:45 < adam3us> the idea is the observer (your desktop/latop/smartphone computer) sends a zkp that the blind protocoin (not yet signed coin) has the given input txids, vales etc whatever you need the signature on.  the trezor displays that info for the user to cross check, signs it, the observer unblinds the signed coin, and then has an extended ECSchnorr sig which is transferably verifiable to anyone
09:46 < adam3us> and yet there is no effective subliminal channel - the only way for the trezor to squeal is to have malware on your observer, or have an unadvertised bluetooth or something in it (maybe want to make it a mini faraday cage:)
09:54 < gmaxwell> adam3us: so, it would be simpler to just use the device in a multisignature manner with the observer as another signer, no? then it could squeal but if the observe was strong, it wouldn't matter.
09:55 < adam3us> yes i think u certainly could stop it squeeling via a multisig
09:56 < adam3us> gmaxwell: however your primary issue is the insecurity of your observer.  this is the most corrosive driving force for security attacks ever invented by several orders of magnitude
09:57 < adam3us> gmaxwell: certainly doesnt hurt to multisig it, but 99.9% of your security is in the trezor, so it would be nice if it's subliminal channel is blocked.  i think lack of end2end secure, mutually airgapped finance built on to of bitcoin may start to erode its value and potential
09:58 < gmaxwell> right, but if your observer is compromised then the blinding procedure won't stop it either.
09:59 < adam3us> gmaxwell: address authenticity is the other problem, you cant trust anything your online computer is telling you.  eg exchanges should be end2end airgapped at both ends with a chain code shared by the exchange trezor and the user trezor
09:59 < gmaxwell> And sure, if you'll note, I wanted them to switch it to determinstic DSA so it was more easily auditable against side channels.
09:59 < adam3us> gmaxwell: this is true, but if the observer is not compromised you dot
10:00 < gmaxwell> if you use dice to come up with your master key and load it into the tresor, then everything that comes out should be deterministic and reproducable by a simulator.
10:01 < adam3us> gmaxwell: yes the deterministic DSA is verifiable with a paper backup and an offline computer and ec calcultor, which is nice; the observer allows you automatically and safely online prevent the subliminal channel (ie yes if your observer is compromised you have a problme, but the observer doesnt have secrets)
10:01 < adam3us> gmaxwell: agreed.  i was wondering if you could make a dsa variant, or another way to compute a dsa that can be publicly verified as subliminal channel free.  ie against the public key.
10:03 < gmaxwell> adam3us: you could probably have the signer produce a zkp that the r is (g*H(message||private key))
10:03 < adam3us> gmaxwell: the deterministic DSA requires the private key to verify, maybe there's another way to do it where you get a dsa sig an something that proves it was generated fairly.  eg proof of concept SCIP.  provide also a proof that you know k and k was chosen as H(d,m) via scip and auxilliary proof
10:03 < adam3us> gmaxwell: yes exactly
10:04 < gmaxwell> now the problem is that the signer is a 40 mhz cortex-m3 with 256k of ram. :P
10:04 < adam3us> gmaxwell: you know it would be even better if its compact and publicly auditable so the miners check it and reject htem
10:04 < adam3us> gmaxwell: if they are non-deterministically signed... then your hw has no power to abuse a subliminal channel
10:05 < gmaxwell> adam3us: meh, that would just make the transaction bigger. if it gets into the network even if it doesn't get mined a badguy can see it.
10:05 < gmaxwell> adam3us: huh? it's easily possible to have a working subliminal channel with non-deterministic signatures.
10:06 < gmaxwell> E.g. keep drawing random numbers until r encodes some bits for you.
10:06 < adam3us> gmaxwell: it was split across to ims.  i meant to say if you can prove its deterministic (to the observer) then your hw cant cheat you
10:06 < gmaxwell> oh indeed.
10:08 < adam3us> gmaxwell: see eg you can have an optically isolated observer.  mini tablet with no network, point it at screen qr code, it displays msg and green check box that yes this coin has no subliminal channel
10:08 < adam3us> gmaxwell: could be the new era analog of the paper note counterfeit detectors
10:08 < gmaxwell> So a proof would work nicely for this, but making it pratical would be hard. (such a proof could also inhibit people storing other garbage in the blockchain)
10:09 < gmaxwell> "digital iodine pen, now with 100% less snake oil"
10:10 < adam3us> gmaxwell: a nice side effect to be sure (garbage stuff on the block) that seems like it needs nother step tho eg prove the receiving address as a private key known to someone- we could already do that at the cost of some bloat (eg selfsigned public keys as addresses)
10:10 < gmaxwell> adam3us: you could have a optically isolated tresor' with the same private key loaded in it (but you don't need to trust it much because its isolated) and it just checks signatures.
10:11 < gmaxwell> adam3us: you don't even need the bloat in the history because you'd throw the proof out and only check it in for the most recent block.
10:12 < adam3us> gmaxwell: broadcast but not stored, validated spv style by late joiner full nodes, yes
10:14 < adam3us> gmaxwell: the other mechanism direction was thinking maybe you can do a direct zkp, rather than fiat shamir transform, eg if you replace the hash H(m,d)=SHA-256(m,d) with like H(m,d)=mG+dH for some point H with unknown discrete log
10:15 < gmaxwell> ha ha
10:15 < adam3us> gmaxwell: then make a signature with that.  dH would be secret also.  that is broken no doubt, but maybe it can be fixed
10:17 < gmaxwell> I'm laughing due to my failed attempt to convince djb that we ought to have curve parameters selected so that strong nothing up my sleeve points exist.  Because we don't know how our generator was selected it's possible whomever picks it knows the discrete log of an apparently nothing up my sleeve point.
10:17 < adam3us> gmaxwell: yes that is a no no, thats what went wrong with EC_DRBG
10:18 < adam3us> gmaxwell: the base point needs to be proven.. eg by hash2curve on digits of pi or such things
10:18 < adam3us> gmaxwell: didnt he do that?
10:19 < gmaxwell> he doesn't agree, sadly. E.g. he has a definition of 'fully rigid' that doesn't include setting the base point: http://safecurves.cr.yp.to/rigid.html
10:19 < gmaxwell> I'll forward you email. one sec.
10:19 < adam3us> gmaxwell: i think we've got the same assumptions but to say it is easy to get two base points G & H which you can readily see no one knows the private key for (eg G=hash2curve(pi), H=hash2curve(e) for pi & e)
10:20 < adam3us> gmaxwell: i mean no one knows the discrete log of them to anything in particular, and certainly no one knows x st H=xG
10:21 < gmaxwell> adam3us: sure, but you have to pick your base point that way.. and it doesn't appear that anything anyone is likely to use right now does.
10:21 < adam3us> gmaxwell: i mean otherwie its a joke find H=hash2curve(pi), compute x=random, then set G=x^-1H => H=xG
10:21 < gmaxwell> adam3us: thats what I sent DJB.
10:21 < adam3us> gmaxwell: holy moly i am going to hit DJB! shame on twitter
10:22 < gmaxwell> (I mean I sent him an example sage notebook where I do exactly that, G=x^-1H )
10:25 < gmaxwell> I can agree with him that it's not the most important thing... but it's also so easily avoided as an issue.  I suspect he may have been disinclined to agree with me because his curves wouldn't meet the criteria (I have no clue where his base points came from).
10:27 < adam3us> gmaxwell: reading this bit now "What about rigid choices of base points?" from http://safecurves.cr.yp.to/rigid.html
10:28 < gmaxwell> Oh, wow, he must have added that after my email discussion with him!
10:30 < adam3us> gmaxwell: hmm he still disagrees however, he claims it doesnt matter however this maybe another one of those "depend what the use case is" things.  to me i think the base should be fairly chosen or even  a small set of fairly chosen base points should be presented
10:31 < adam3us> gmaxwell: thats rather narrow minded - if someone needs G & H then they cant use his G.  they have to ignore it and safely generate two more
10:32 < adam3us> gmaxwell: which is a big onus to put on the implementor now they have to get into complex EC math arguments and understand the curve generation and limitations.  big area for mistake or community rejection of their proposal
10:34 < gmaxwell> adam3us: I think the smallest possible x / y for performance reasons (makes a multiply easier) isn't /terrible/. I didn't realize thats what he'd done for his own curves.
10:34 < gmaxwell> But yea, I'm glad you agree that its stupid to not get this right.
10:35 < adam3us> gmaxwell: : oh thats not too bad.  u have to consider also that someone could adapt the curve params to have a known discrete log small x,y.  but as the curve params are chosen deterministically with rigid criteria and plausible seed
10:36 < adam3us> gmaxwell: then its probably ok
10:36 < gmaxwell> adam3us: yea, funny that I managed to not gather that from his emails. I only realized it after reading the update to the page and then looking at the values.
10:37 < adam3us> gmaxwell: he probably never said it - unstated assumption
10:42 < cfields> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=0cb112f7400187275da81a05a9ad0534f1430139
10:42 < cfields> all determinism problems in binutils (that i'm aware of) fixed.
10:42 < sipa> \o/
10:44 < adam3us> btw about bitcoin implies need for end2end airgap model, someone i talked to said they discovered an egress vpn tunnel via their custom firewall scripts (pretty hard core security geek to notice) within a few ays of talking to me.  seems like skype is a risk suggest not running it at all, running in vm (maybe there are people with skype & vm escape zerodays) or running it on a burner laptop on a different network literally
10:44 < adam3us> for people who seemingly are incapable of installing jabber client & otr because they want to do bitcoin stuff, but thats too complex :|
10:46 < adam3us> advice: paranoia *= 2 if you have bitcoins non airgapped, exchange accounts with bitcoins or doing bitcoin dev work.  my prediction this security attack to the level of being willing to burn 0days to get into suspected intersting places ramping up
10:48 < adam3us> even airgapped bitcoins are at risk if you spend them.  you need some better way to check the deposit address on exchanges.  they need to use unique per user chain codes
10:48 < K1773R> setup the honeypots!
10:54 < gmaxwell> I've been using canary coins for a long time, never had one trigger, so I don't know if they work.
10:55 < adam3us> probably IMO baseband processor hacked or other smart-phone vector to attack google authenticators are the next step.  it'll take the shine out of bitcoin if non-tech users get ripped (or even reasonably tech people who dont know how to setup hard core secure environments)
10:55 < gmaxwell> (canary coins = leave an easily found unencrypted wallet.dat on bastion hosts; hopefully someone who compromises the host moves the coins right away thus alerting you)
10:57 < adam3us> gmaxwell: yes.  there maybe different attacks tho - random ones, and targeted ones aimed at people with known early bitcoins or who might be suspected to have early bitcoins.  unfortunately i am in the suspected but actually not - have to tolerate the attacks, but without the coin hoard :)
10:58 < adam3us> and we saw jdillions pgp was compromise and his private decrypte msgs posted on the forum.  pgp on line computer is probably not good in this environment
10:58 < gmaxwell> adam3us: well thats true for lots of us. I worry about people following me home. It's not nice to fear that some idiot might think that mugging you might yield a hundred million dollars .. without actually having the hundred million dollars. :P
11:01 < adam3us> gmaxwell: precisely. you cant afford or dont want to spend 1/3 your salary in using 100-millionaire private security type setups (body guards). so its kind of a shitty situation.  you are exposed to the risks without the upside.
11:02 < adam3us> gmaxwell: this is why my bct sig line said for a long time "I am not satoshi" => i dont have many coins
11:03 < cfields> hmm, who should i ping about gitian stuff?
11:03 < gmaxwell> devrandom
11:03 < cfields> i need a raring builder
11:03 < cfields> ok. he comes around irc, right?
11:04 < cfields> nm, i see him in -dev
11:04 < adam3us> also OS upgrades are stupidly insecure.  they are checking signatures not hashes.  they cant check hashes because the new module wasnt coded at the time.  we need something like laurie's cert transparency for OS patch hash transparency; as is possibly a weak point is the ubuntu/fedora etc package builder, or for anything x509 code signed another hacked CA
11:05 < cfields> ping Luke-Jr
11:10 < adam3us> so what about end to end address security. if you and another user have a trezor.  say you need to pay someone 1btc or something non-trivial how do you know you have the recipients address, if you are using an online computer to create the offline signable transaction
11:11 < adam3us> seems like you need to use an address signed by the sender's base keypair (and encrypted with your base keypair) for end2end privacy and address authenticity
11:13 < adam3us> new armory feature I think  you could make it a non-transferable signature probably would be slightly better if the payment request receiver is airgapped.
11:13 < adam3us> maybe this could be done as a payment request extension
11:14 < petertodd> adam3us: addresses aren't useful; identities are
11:14 < petertodd> adam3us: people keep trying to re-invent PGP...
11:14 < adam3us> this bitcoin thing is getting ahead of its own operational security tools - trajectory could be disrupted, or stupid central trust solutions or static addresses used as a counter-measure
11:15 < adam3us> petertodd: right, but when you send someone address via an unsecured connection and online computer (which maybe subject to 0-day compromise even with best precautions as the bitcoin stakes increase)
11:16 < adam3us> petertodd: currently you make no attempt to prove the identity owning the address to the offline wallet abot to make thepayent.  yu just read if off the screen of a potentially compromised system which can put someone elses address on teh screeen
11:16 < petertodd> adam3us: yeah, but doing fancy crypto with addresses doesn't change a thing - the address still doesn't involve a human-meaningful identity
11:16 < petertodd> adam3us: well yeah, that's what the payment protocol is for, and for the decentralized case, add OpenPGP support and teach TREZOR about the WoT (have fun with that!)
11:17 < adam3us> petertodd: well there's no trust anchor.  in the same way we exchange pgp fingerprints, we need to exchange like static vanity/random encryption address, and use that for encryption
11:17 < adam3us> petertodd: pff payment protcool is signed by an online ssl signing key
11:18 < petertodd> adam3us: sure, but would you rather exchange a single purpose bitcoin addr or a actually using for stuff in general pgp fingerprint?
11:18 < adam3us> petertodd: i bet 99% of web servers will sign it with their existing SSL key
11:18 < petertodd> adam3us: that's the only way it could possibly work
11:18 < petertodd> adam3us: payment protocol doesn't do any good if the identity involved != the identity of the website the user just visited
11:18 < petertodd> adam3us: sad but true
11:18 < jgarzik_> adam3us, scrolling back a bit, what do you mean RE OS upgrades when you say "they cant check hashes because the new module wasnt coded at the time."
11:19 < adam3us> petertodd: what i mean is we have the infrastructure available, but just lack the tools.  offline wallet use base address as identity, but hash on biz card, pgp sign as attribute etc
11:19 < jgarzik_> adam3us, RPMs sign file hashes
11:19 < adam3us> jgarzik_: sure they do, but what i mean is i want a compact representation for the entirety of a snapshot of an OS (like a merkleroot for the OS at that point in time) so tthat it is safe to dowload modules
11:20 < petertodd> adam3us: right, but don't teach your offline wallet about base addrs, because then users will do dumb things like verify the base addr via PGP on a compromised computer - stick to matching the identity of the person they are transacting with and how they established that identity
11:20 < adam3us> jgarzik_: even if the signer does a poor job of managing his rpm signing key
11:20 < adam3us> jgarzik_: like you get an ISO checksum, but then most of these isos wont even install without a network connection!! (nutters if you ask me)
11:20 < jgarzik_> adam3us, interestingly, with some filesystems, that automatically happens at the filesystem level
11:21 < adam3us> petertodd: i a sayng lets at least make it work conveniently for the people who are trying to do things securely.  eg an exchange has a airgappe backoffice for enrollment.  users get a trezor in the snail as part of their exchange setup.  that prevents misdirecting deposit addresses
11:22 < petertodd> adam3us: right, which is a totally different tech than anything I was thinking about
11:23 < adam3us> jgarzik_: yeah.  you know zach brown?  btrfs, zfs have what you said  but thats about file system integrity.  you want that on the base iso and the merkle tree of all point in time snapshot of packages available for it.  then i can write the checksum down and I know for sure even if someone holds a gun to the head of the package signer he cant tamper with code post-hoc or in a targetted way against me
11:23 < K1773R> why does bitcoin use /dev/urandom and not /dev/random?
11:24 < jgarzik_> K1773R, /dev/random takes forever for questionable additional security gain
11:24 < adam3us> K1773R: probably because /dev/random can block and /dev/urandom is good enough.  but there could be an argument for /dev/random for keygen only
11:24 < K1773R> jgarzik_: what about ppls whith HWRNG?
11:25  * jgarzik_ isn't familiar with the PPLS method of mining pool payouts
11:25 < adam3us> petertodd: point is even the tech users have no bitcoin internal tools short of calling the sender, per transaction, or scripting some pgp sigs on the offline machine (trezor wont do that as its not part of the protocol at present)
11:26 < K1773R> adam3us: well, i just had to debug something (ie, with strace) and saw it used /dev/urandom . which operations depend on /dev/urandom and how much bits/bytes are needed?
11:28 < petertodd> adam3us: indeed they don't, but lets not encourage tools that turn into extremely specific things...
11:28 < petertodd> adam3us: the fundemental issue is you have to verify against the identity that the other party communicated to you with in the first place - the example of a physically loaded key is an exception
11:29 < adam3us> petertodd: thing is airgap doesnt really fix the problem for people who actually do tranactions (biz, customers) it just moves it on to the insecure computer and hoping there's no malware on it - we know thats a lose even for revocable credit card payments
11:30 < adam3us> petertodd: what use is a payment request x509 sig against a malware loaded machine with installed malware fake CA, address replacing code, and at the high end stolen CA private keys (not like that didnt happen before)
11:36 < petertodd> adam3us: yes, but if the CA system is secure, then only thing that really helps is to verify the destination *on the offline wallet* against a payment protocol request
11:36 < petertodd> adam3us: equally, if PGP WoT is secure
11:36 < petertodd> adam3us: anything else means you can do attacks where you trick the user into accepting an identity for the key that had nothing to do with the identity of the person they thought they were transacting with
11:36 < petertodd> adam3us: (modulo entire CA systems meant to track other CA systems... ugh)
11:37 < adam3us> petertodd: right.  but people know how to do fact checking, due diligence and biz people do it al the time for high stakes decisions
11:38 < petertodd> adam3us: so what? there's no better alternative
11:38 < adam3us> petertodd: they'll research the company, call them up, go visit them, look at their paper work.  expect courier documents.   etc this can work for crypto currency exchanges also
11:38 < adam3us> petertodd: yes my assertion is you need the trust to be rooted in the financial identity because its the most critical and most secured part
11:38 < petertodd> adam3us: and yeah, I'm not saying that's a bad thing to do, I'm just saying if you *aren't* doing some fancy physical protocol, we have no other alternative
11:39 < adam3us> petertodd: ok, yes so then i'm saying so we need this signed addresses generated & validated by hw airgapped 'puters and trezor devices as a min bar as part of any bitcoin related transaction
11:39 < petertodd> adam3us: besides, mail has it's own set of security risks too... a SSL cert/PGP key + being told to verify a fingerprint isn't crazy (or make it that getting the fingerprint is the only way they can get the key)
11:40 < petertodd> adam3us: indeed, and the payment protocol is meant to solve exactly that!
11:41 < adam3us> petertodd: well except it is probably not the right flow as it needs the recipient key also, plus its so far (right?) tied to X.509 which is a sideways step
11:42 < petertodd> adam3us: no it's not tied to X.509 at all, look at the spec
11:42 < petertodd> adam3us: and what do you mean by flow anyway? you want to just select a recipient in your offline wallet as step one?
11:45 < adam3us> petertodd: i mean you are proving to the world (or giving a transferable proof) that this address belongs to this recipient maybe ok for a merchant, but the user doesnt have an SSL cert to issue a payment request with.  i wa meaning you could have a payment request request, where you said this is my public key, i want to buy one of those, and then the payment request sends you an encrypted non-transferable signature (or encrypted signature i
--- Log closed Fri Nov 22 11:59:44 2013
--- Log opened Fri Nov 22 12:00:02 2013
12:07 < petertodd> adam3us: sorry, server crapped out, repeat that?
12:10 < adam3us> petertodd: seems like payment request does 90% of it, except you need the signature on the payment request to come from an airgapped key, or the key to carry its own proof it was originally generatd with the airgapped key before upload to the server.  the thing is if the server is handing out keys from a pool, you dont know if someone broke into the server and re-served you with an address associated with their exchange account
12:11 < adam3us> petertodd: i mean having the server hand out signed requests but composed of an unsigned address from a pool in server ram or server disk is just inviting trouble mid-term though a short term improvement
12:12 < petertodd> adam3us: right, but if your website is insecure they can already redirect where the money goes anyway
12:12 < adam3us> petertodd: its not like people cnt break into servers, just that its not that interesting with credit cards because you the consumer pays the 3-5% fraud cost and the merchant lives with the chargeback
12:12 < petertodd> adam3us: the only way to improve upon that is to create a whole new CA system of bitcoin addresses + identities
12:13 < petertodd> adam3us: yeah, well, get better security for your keys: e.g. put the SSL keys on a HSM
12:13 < petertodd> adam3us: or, if it's with PGP, same idea
12:15 < adam3us> petertodd: yes thats what i'm saying.  i think bitcoin should form its own payment security based identification system
12:16 < adam3us> petertodd: preferably without trusted third parties (CAs) being trusted too much, or prominently displaying the static  merchant identity fingerprint (with airgapped private key) so you can check it manually
12:18 < petertodd> adam3us: check it manually how?
12:19 < petertodd> adam3us: I don't think we know what we should be doing in this space yet actually; get the payment protocol out there and start learning about how it works in practice
12:19 < petertodd> adam3us: what you're talking about, especially re: manual checking, really sounds like a job for PGP...
12:19 < adam3us> petertodd: yes.  but its quite predictable where the next week point is
12:20 < petertodd> adam3us: and again, what good is that vs. adding *manually checkable* OpenPGP to the payment protocol?
12:20 < adam3us> petertodd: i think it ideally should be soething simple, concise and built in.  the authenticity of addresses a core bitcoin internal critical requirement
12:21 < petertodd> adam3us: and simple and concise just isn't. The closest thing to simple and concise is a friggin address book with manually entered addresses (+HD wallet seeds if you want to get fancy)
12:21 < petertodd> adam3us: we've already got that
12:21 < adam3us> petertodd: and if we promote one-use addresses, whih we do for fungibility/privacy, then we have to somehow fix up the user experience and user comprehension and out of the box secruity of doing it (even if it means all users nee to use hw wallets for non toy amounts of spare change)
12:22 < petertodd> adam3us: yeah, and as I say, we've already got the single address thing covered, and adding derivation isn't rocket surgery
12:22 < petertodd> adam3us: anything beyond that and you're talking about identities, which are not simple or concise, (and frankly I doubt the trade-off is worth it - more people will lose coins due to malware than bad CA's)
12:22 < adam3us> petertodd: right.  i proposed another way to get fungibility by using a static address, that can be randomly derived from by senders without your chain code for this kind of reason.
12:23 < adam3us> petertodd: "single address thing covered" you mean one use address as transaction number (but not really address in name)!
12:23 < petertodd> adam3us: and I proposed just mixing in the previous block hash for the same reason
12:24 < petertodd> adam3us: no, I mean an address book on your offline wallet that you enter in manually by a manually verified process (letter in the mail) simple and easy
12:24 < petertodd> adam3us: people *do* do that
12:24 < adam3us> petertodd: yes so the problem is its one use, you have to enter a new one each time
12:24 < petertodd> adam3us: yes, and add some trivial bit of derivation and you're done.
12:25 < adam3us> petertodd: sounds like a sub-wallet and chain code
12:25 < petertodd> adam3us: my point is anything *beyond* that, say you want to verify a payment request, is better handled by a PGP extension tot he payment protocol
12:25 < petertodd> adam3us: exactly, as I say, it's not hard
12:29 < adam3us> petertodd: see i the mid-term, once the bad-actors jump up over the next speed bump of payment request + client side trezor/offline wallet, some exchange or bitcoin processor is going to go under or lose its entire hot wallet, or have attackes redirectiong payments because they assume a web server is not remotely compromizable
12:29 < adam3us> petertodd: we know thats just-not-true, and as the biz level increases and the bitcoin price increases, people will happily burn a collectio of 0-days to disabuse them of that notion
12:30 < adam3us> petertodd: then the answer 'oh well they should've secured their site better' is no a clever answer - its a systemic risk from irrevocability and if we dont fix it the merchants will by adding revocability...
12:31 < petertodd> adam3us: so? put your payment protocol SSL key elsewhere - IIRC Gavin specifically made it use a subdomain for that reason
12:31 < petertodd> adam3us: the thing is we *can't* fix this for people in a sane way
12:33 < adam3us> petertodd: my argument is you can :) just assume (longer term) everyone is using some hardware wallet/token.  now what do you do to help people authenticate one-use addresses in a simple native way. to say oh just make an HD sub-wallet and chain-code per recipient isnt fantastic as I dont think you can introduce them
12:34 < adam3us> petertodd: like i cant refer that to you, because its a point to point shared secret
12:34 < petertodd> adam3us: so is a HD sub-wallet and chain code
12:34 < petertodd> adam3us: sorry misread that
12:35 < petertodd> adam3us: right, but anything you try to do to refer someone else to me has you as a MITM... and OpenPGP WoT already puts tonnes of effort into solving that
12:35 < adam3us> petertodd: so if we replace shared secrets with identities i can tell you offline, yes look this is the static payment identity for this vendor
12:36 < adam3us> petertodd: but sub-wallet and chain code doesnt even help us if we're sitting side by side (in the end 2 end payment security view)
12:36 < petertodd> adam3us: yes, and a OpenPGP key is a static payment identity... don't re-invent the wheel
12:37 < petertodd> adam3us: it's also *way* more useful, because the infrastructure already exists to use it for other stuff, like send a PGP-signed email to customers
12:37 < adam3us> petertodd: i dont think you want to import pgp or x509 into bitcoin
12:37 < adam3us> petertodd: your trezor doesnt understand pgp wot nor x509
12:37 < petertodd> adam3us: we're not importing anything "into bitcoin" - we're using stuff for it's intended purpose
12:37 < petertodd> adam3us: why not? they're moderately high-end arm processors
12:38 < petertodd> adam3us: *not* supporting it just means that users are going to fuck up on the manual verification bit
12:38 < adam3us> petertodd: i am not even talking about wot even, just that there ought to be a published static address (payment identifier) and one-use payment addresses can then be signed by them
12:38 < petertodd> adam3us: published where? how?
12:39 < petertodd> adam3us: signed by what?
12:39 < adam3us> petertodd: but if you call that the recipient account number, its no more complex to understand than a credit card check digit
12:39 < adam3us> petertodd: the underlying one-use addresses no longer need to be displayed to the user
12:39 < petertodd> adam3us: add a new type of UID to OpenPGP called your bitcoin chain-thingy-whatever
12:40 < adam3us> petertodd: app-level signatures from the app context can sign their stuff, and leave the basic is this a valid one-use address (transactio number) from this merchant to en2en
12:41 < petertodd> adam3us: sign where? how?
12:41 < adam3us> petertodd: i think what you're saying is the architectural equivalent of having sendmail sign your key fingerprint
12:42 < petertodd> adam3us: somehow the verification has to happen *on the trezor* and you have to get a fingerprint of a key securely *to that trezor*. If you don't use CA's, people will validate fingerprints on their compromised box, if you don't use PGP, same deal.
12:42 < petertodd> adam3us: if you do use CA's or PGP, then you've made the whole ecosystem more useful for everyone, especially the PGP option
12:42 < petertodd> adam3us: signing stuff is easy, verifying keys is what's hard
12:43 < adam3us> petertodd: i claim its a layering violation to think of the payment request msg as a proof that the address is owned by the merchant, so in the app context there is a payment request say, it signs a one-use address, and some informtion abot what you're buying; but the underlying one-use address is signed by the merchant identity address (the base public key of the offline HD wallet)
12:44 < adam3us> petertodd: i am not saying dont use CAs i am just saying the architectural equivalent of dont use ssl transport on SMTP as an argument for not using PGP (end to end vs app level transport)
12:45 < adam3us> petertodd: the web app level and browser level is the payment request, x509 or other sig; the payment level uses differrent transport and has more secure key management
12:45 < petertodd> adam3us: and I'm saying the concept of a separate "merchant identity address" just introduces a whose new layer of exploits because users can't and won't have any way to verify that identity address other than CA's and PGP, so don't create separate systems.
12:45 < adam3us> petertodd: and no online app or client to attack
12:46 < petertodd> adam3us: yeah, and the payment protocol already supports separate keys by how it expects a cert for a subdomain
12:46 < adam3us> petertodd: the point is right now you have no way at the payent layer to validate the address is owned by the merchant.  the payment request doesnt prove its owned by the merchant: it proves the merchants web scripting language signed it, but maybe from time to time compromised.
12:46 < petertodd> adam3us: now if you want to strengthen that, maybe make a third subdomain to sign for a long-term root or something, but don't make it a separate "merchant identity address" that the user will ever see (except in paranoid situations where they enter fingerpritns in manually)
12:47 < adam3us> petertodd: i dont think its unreasonble to see an account number and check its correct off your last paper bill or whatever
12:47 < petertodd> adam3us: you don't deal with users...
12:47 < adam3us> petertodd: pretty much all credit card bill pyment, online banking etc works tht way
12:48 < petertodd> adam3us: *could* work - no-one actually does that.
12:48 < adam3us> petertodd: the payent identifier is a simpler concept that more closely matches their banking understanding - it is the merchants ACCOUNT NUMBER
12:48 < adam3us> petertodd: err when you set up a payment ivia online banking you probably either type of cross check the account number
12:49 < adam3us> petertodd: this just slightly tweaks the bitcoin concept to more closely match user expectation, and improve verifiability
12:49 < petertodd> adam3us: yeah, and it always gets back to how did you get that account number... which in turn ges back to *you need to make the trezor support CA's and/or OpenPGP anyway* so use that mechanism rather than writing yet more code
12:49 < adam3us> petertodd: i am not saying dont do those parts, but i am saying they are best effort app level/browser level things.
12:50 < adam3us> petertodd: to avoid paying the wrong person you need a stable account number analog and this is it
12:50 < petertodd> adam3us: no, for the average user they are absolutely critical to support directly in the trezor
12:50 < petertodd> adam3us: the majority if transactions aren't going to be done by checking account numbers
12:50 < petertodd> adam3us: you *must* do as good a job as possible on that common case in a way that users actually use
12:51 < petertodd> adam3us: since you must do that work, re-use the end result for the paranoid case...
12:52 < adam3us> petertodd: thing is if you look at eg armory or bitcoin-qt there is a list of one-use adresses, these are transaction numbers, but users confuse them for addresses, all i am saying, and i dont see why its controversial, is the address should be signed by the hd wallet root that generated them
12:52 < adam3us> petertodd: then that thing - the hd wallet root address is the account number, nd you can display in conventional accounting format: account number, transaction number, merchant deescription, product description, units, cost
12:53 < petertodd> adam3us: it's controversial because it's useless :)
12:53 < adam3us> petertodd: foo youre just not appreciating the difference between layering it seems to me:|
12:53 < petertodd> adam3us: ok, account number == pgp fingerprint
12:53 < petertodd> adam3us: now you've re-used useful code and have a chance of getting better overall integration
12:54 < petertodd> adam3us: rather than Yet Another Signing System
12:54 < adam3us> petertodd: es but what use is a pgp fingerprint to a trezor or offline wallet, dont tell me you want to add that to the bitcoin source code
12:54 < petertodd> adam3us: damn right I do, because you have to for the common case
12:54 < adam3us> petertodd: bitcoin already has a signing system, and a key to do the signing, i am just saying use it
12:55 < petertodd> adam3us: anything less means users who *don't* have any reason to dick around manually checking bullshit just because they want to buy a tee-shirt will end up with a less secure system
12:55 < petertodd> adam3us: and a signing system is useless without gobs of infrastructure
12:55 < adam3us> petertodd: the web app level is far less dangerous if the worst you can do is pay money ot the wrong merchant address (as opposed to the attacker direct)
12:56 < petertodd> adam3us: huh? the attacker swaps out the addresses after crackng the site and steals a million bucks from 10,000 users
12:56 < adam3us> petertodd: i am not saying people who are buying t-shirts will care to check it
12:56 < petertodd> adam3us: right, which means you have to have that code in the trezor... so use it
12:56 < adam3us> petertodd: no because the addresses are signed, and users who bother to check, can see hey something is wrong with tshirtsrus
12:56 < petertodd> adam3us: paranoid level gets to have the PGP fingerprints displayed prominently
12:56 < adam3us> petertodd: their TOFU account number just changed??
12:57 < adam3us> petertodd: even a browser plugin handling payment requests could check that
12:57 < petertodd> adam3us: there is no difference between checking "signed addresses" and "CA fingerprint matches up", zero.
12:57 < adam3us> petertodd: you realize how tricky it is to get any sense out of pgp wot? latest version of gpg is all but unintelligible to me
12:58 < adam3us> petertodd: screw wot, i just mean a self-certified tofu hd wallet base key and expecting transaction numbers (one-use addresses) to be signed with it
12:58 < petertodd> adam3us: where did I say you'd be using WoT for this? most paranoid users would want to verify fingerprints with manual mechanisms, some could use WoT, but we're *much better* if we encourage an ecosystem that doesn't fragment things
12:59 < petertodd> adam3us: and like I keep sayng, making it PGP lets you do useful things like have known ways to send your merchant an encrypted email
12:59 < petertodd> adam3us: you are *not* thinking about second order effects here
12:59 < adam3us> petertodd: i just think its more useful to the careful user to have a tofu account number to read off and compare. than a string of (to him) uncorrelated random one-use addresses - that tell shim precisely nothing
13:00 < adam3us> petertodd: and the web level browser level and client machines are like swiss cheese and will get rampantly exploited
13:00 < petertodd> adam3us: yes, and using a PGP code-path for that use-case is better and encourages good practices across the board, rather than a bunch of highly specific shit that doesn't do anyone any good
13:00 < adam3us> petertodd: there are no second order effects - if you're buying t-shirts and you dont care dont look at the account number alright
13:01 < adam3us> petertodd: bullshit - how is throwing pgp at the poor user going to help anything
13:01 < petertodd> adam3us: damn right there is, now there's no transition path between low, medium, and high security, that's very bad
13:01 < adam3us> petertodd: so i think the low to medium level is done via payment request as is
13:02 < petertodd> adam3us: we want a system where the average user goes and gets the green CA-certified box saying "TeeShirt Company", then when they become a distributor of said company is told "Hey, go check that the fingerprint matched up ok? Just to be safe." now you've gone from low to high security seemlessly.
13:02 < adam3us> petertodd: problem is if the server is compromised someone can undetectably to users swap out the pool of one-use addresses
13:02 < gmaxwell> petertodd: so what we need to do is introduce the things pgp lacks to pgp and to fix it, rather than go off seperately or pretend that pgp as is .. is a solution.
13:02 < petertodd> adam3us: No, as I said before, you add a mechanism *to the payment protocol* to have a separate CA key (as a subdomain) sign a root address under the hood
13:02 < adam3us> petertodd: the web site will happily sign them with its SSL key (or subdomain key) and facilitate robbing itself
13:03 < petertodd> adam3us: and that's why it's a fucking subdomain, so you *don't* need to keep it online!
13:04 < petertodd> adam3us: you're not getting the payment request from that subdomain, the software just expects the request to be signed by that magic subdomain, and shows the user the address one level up
13:04 < adam3us> petertodd: well wait the payment request includes a description of what ou're buying and amount it cant be offline
13:05 < adam3us> petertodd: whereas one use addresses in the hd wallet derivation method can be pre-generated offline and uploaded as a batch, they could be signed offline, but there is currently a missing part to do that (thats basically all i was trying to say)
13:05 < petertodd> adam3us: sure it can, as I said before, you have two payment protocol-related certs here: one to sign requests semi-online, another to sign long-term root keys
13:06 < petertodd> adam3us: now you have a system that has pretty good security in the default case, *and* can be easily upgraded to paranoid level by a manual check
13:06 < adam3us> petertodd: but the message to be signed is different: one is a one-use address (offline) and the other is a description of your order (online)
13:06 < petertodd> adam3us: rather than creating balkanized shit
13:07 < petertodd> adam3us: yes, and what's wrong with that? users wallet is programmed to expect both, and barfs if it doesn't see what it expects
13:07 < adam3us> petertodd: so then you're saying teh same thing except ou like x509 and i dont.  i think for something as compact, simple, direct nd bitcion meaningful as a proof of hd wallet ownership should be a 64 byte thing on the one use address, not a few KB of asn1
13:07 < petertodd> adam3us: if not all merchants use this, just make the UI in the wallets have a silly golden shield or something for the extra-high-security version, and make it easy to check fingerprints manually
13:08 < petertodd> adam3us: sure, but the code *has to be implemented on the wallet anyway*, so use a mechanism that allows for nice user-friendly transparent upgrades
13:08 < adam3us> petertodd: yeah i think e have some ux and naming to fix up, but i would call the merchant HD wallet base address the merchant account number, and the one-use address the invoice number
13:09 < adam3us> petertodd: seems a bit ugly to say oh yeah, and that account number, bitcion has a key, but it chose to delegate that to a web app, a untrusted third party (CA) and browser to tinker with
13:09 < petertodd> adam3us: heck, you see what I'm doing here? what I'm really doing is extending the merchant's identity that you usually transact with to verify a HD wallet base - you're strongly arguing to only do the latter which is silly
13:10 < petertodd> adam3us: we're not delegating it to anything - hardware wallets and offline wallet software *has* to implement CA certs for the 95% use-case
13:11 < adam3us> petertodd: i dont think CA are good model, ca infrastructure is rooted, 100s of dodgy CAs, hacked CAs, hostile govt operated CAs by govts of various shades .  that way lies account seizure
13:11 < petertodd> adam3us: who cares? CAs are a better model than nothing. Reality is 95% of users will outsouce their security - there is nothing we can do about that.
13:11 < adam3us> petertodd: you can sign extra stuff with x509 while you're signing the payent request - why not, but i think its simpler to also independently and natively sign the one-use addresses
13:12 < adam3us> petertodd: its not either or.  sign the account numbers with the hd wallet master.  and sign everything best effort on the web app layer with the payment request
13:12 < adam3us> petertodd: what i am saying is like a checksum on a credit card digit
13:13 < petertodd> adam3us: no it's not - a hd wallet seed signed once by a long-term identity cert means that some theif can't do anything more interesting than blackhole funds in the worst case - in the better case you use a derivation system that's deterministic enough to always recreate the key(s)
13:13 < adam3us> petertodd: what you are saying is like maybe SET (doomed credit card web security protocol)
13:14 < petertodd> adam3us: nah, it's silly to be signing shit, remind yourself how HD wallets work... you don't need to sign addresses derived from them, spendability only with the HD seed is guaranteed anyway
13:14 < adam3us> petertodd: i think this is an instructive analog: banks do not use third party auth (openid, CA issued certs without pinning, or site enrolment) becaus tehy want to control their own security
13:15 < petertodd> also if you are signing stuff, then that encourages you to keep your keys online, which is bad...
13:15 < petertodd> adam3us: yes, and then they can tell their customers their PGP fingerprint and do it that way...
13:15 < adam3us> petertodd: not signing data just the one-use address
13:15 < petertodd> adam3us: yes, and given HD seed S and nonce n S+n is a one-use address that only S' can spend
13:22 < adam3us> petertodd: yes this is true, but only if the site and user share a sub-wallet & chain code (which they can do, and maybe should do for recurring biz)
13:22 < adam3us> petertodd: but i was thinking maybe with a signature on the one-use address, whch the user can strip before using on the network, you get that kind of spender simple tofu verification
13:25 < petertodd> adam3us: timo's pay-to-contract makes a lot of sense there you know... yeah, now maybe you really do what a address that can't be proven to have anything to do with the hd seed, but why not extend that initial thing to sign a bunch in advance? again, you don't want to encourage keeping that long-term-id key online often
13:31 < adam3us> petertodd: i was thinking you could sign them offline and upload them as a batch airgap/usb.  there is some consideration about giving users signed proof that this is your address, users can get to gether or publish those proofs and the servers payment privacy (which they want for commerical sensitivity of eg their trade volume) is blown and provably so, payment request has the same issue
13:43 < petertodd> adam3us: indeed, but, what it comes down to is all this stuff is better done by leveraging existing systems so UI's can be seemless
13:44 < petertodd> telling users about some "account number" is something that doesn't lead to good understanding in the long run too
13:46 < adam3us> petertodd: yes its not an ideal world.  i am thinking that even low value storage like $10, $100 may not last on windows machines.  people will lose interest if their wallet keeps getting emptied by bitcoin thieving malware, so then you're on to tpms (which dont help much without trusted path IO, and dedicated display) or hardware wallets with display (trezor)
13:48 < petertodd> if bitcoin does anything good for the world it might be to improve computer security...
13:48 < petertodd> anyway, even if windows boxes turn out to be hopeless, CA's have a chance of improving
14:04 < jgarzik_> Relevant dumb question... how happy are people with HD wallets, from a math/crypto standpoint?  We love them, but having this emotional, unreasoned fear of having a lot of mathematically-connected addresses
14:05 < jgarzik_> We wind up coming up with schemes like "new seed per month" + new derived public key seeds for merchants etc.
14:05 < jgarzik_> trying to avoid too much math derivation links, and limit the damage caused by a seed compromise
14:06 < petertodd> jgarzik_: well, I will say apparently the Tor project is adopting the underlying idea for something to do with hidden services; but IANAC...
14:06 < jgarzik_> IANAC -- storing that one for later use
14:07 < HM2> I can't believe the tight git behind that whopping transaction didn't pay a fee for his his cpu cycles ;)
14:16 < warren> where are we on 0.8.6?
14:20 < gmaxwell> jgarzik_: If HMAC-SHA512 is broken in a way and with a severity that makes this matter at all we are fucked on so many different levels that 'related keys' wouldn't be on the radar.  It's also a bit cargocultish: openssl reads from /dev/urandom only on startup... All your keys generated during an execution session are already related by a CSPRNG scheme not unlike the BIP32 private derivation.
14:20 < phantomcircuit> gmaxwell, weird
14:21 < phantomcircuit> is there any good reason for openssl not to continuously rekey with /dev/urandom
14:22 < gmaxwell> jgarzik_: my personal allowance to paranoia on this front is using a 512 bit state inside the derrivation, which makes it very likely that the keys are indistinguishable from each other without the full state in a information theoretically sound way (e.g. there probably exists some unknown state that would make any two randomly selected keys 'related')
14:22 < gmaxwell> phantomcircuit: just software engineering reasons... esp considering multithreaded programs.
14:23 < jgarzik_> gmaxwell, not claiming it is rational (note the "emotional" qualifier)
14:23 < jgarzik_> Just encountering multiple programmers with the same sentiment
14:23 < gmaxwell> jgarzik_: I know. I hope I added to your ability to discuss it: e.g. that most random generation schemes have hidden relationships.
14:24 < gmaxwell> Non-paranoia based: Key management is a real issue, rotating keys periodically is prudent not for cryptospeculation reasons but just because forward security may reduce exposure.
14:45 < gmaxwell> adam3us: so... in the past I've whined that we have no utxo expiration on the basis of an economic concern:  Eventually lots of coin will be lost and bitcoin will deflate. Thats not bad.  But we don't know how much is lost... and thats potentially bad. E.g. say all but 10 BTC is lost and 1 BTC now buys you a nice planet. etc. This is exacerbated in that a lost coin can't be upgraded to better crypto, so eventually ecdsa secured coins ...
14:45 < gmaxwell> ... may suddenly become unlost in vast numbers, which might disrupt the economy.
14:45 < gmaxwell> adam3us: if we had committed coins with totally hidden values, wouldn't this be even worse? e.g. we wouldn't even know the value of the coin in circulation?
14:46 < warren> I implemented a hack to test expiration.
14:46 < warren> just to get some numbers of how big the chainstate and memory use would be
14:47 < warren> the existing remove unspendable txo patch only works on reindex, not too useful for getting rid of old TXO
14:49 < warren> gmaxwell: hmm, so MMR to spend old "forgotten" coins wouldn't be any better for the forward security reason
14:51 < gmaxwell> warren: Right, you'd only get increased economic certanty if the coins actually become unspendable.
14:52 < gmaxwell> I don't know how much the certanty matters absent cryptographic breaks. But with breaks its probably pretty concerning, but it could be addressed differently. E.g. when replacement crypto is deployed you add a new rule that after date xyz ecdsa will be unspendable.
14:52 < warren> not just crypto breaks
14:52 < warren> old backups
15:05 < adam3us> gmaxwell, jgarzik: i think HD crypto is fine.  its also very important for backup.
15:06 < adam3us> gmaxwell: committed coins recicrulating in hidden form i guess yes you have no idea what has even moved (unless there is early decommit).  (re estimating proportion of spendable utxo)
15:09 < phantomcircuit> gmaxwell, im guessing that the hmac-sha512 wont be broken for a long time after sha512 is broken
15:09 < phantomcircuit> which should provide for a fairly significant security warning
15:09 < adam3us> gmaxwell, warren: there are people who explored about digital archiving signed info, with like multiple sig algos, time-stamping, re-signing entities.  maybe you can say during a phase out period, which hopefully isnt too sudden you get to replace a ecdsa256 with something else
15:10 < adam3us> phantomcircuit: yes hmac makes limited assumptions even hmac-md5 is non-stupid (where md5 is now a dud)
15:16 < adam3us> erm saw something funny armory online generated an address with 121okABVjfk6QSV1pAZeVZdoU7utpp6jxd but when pasted it views 121okABVjfk6QSV1pAZeVZdoU7utpp6Jxd (capital J) i noticed so put a small sacrificial payment to it
15:30 < adam3us> seems like armory anomaly bc.i thinks its uppercase
16:49 < adam3us> hmm its a font issue some of those linux fonts are dodgy and j looks like J except for one pixel pretty much, doh!
17:40 < jgarzik> adam3us, gmaxwell: thanks (re HD wallets)
18:29 < Luke-Jr> cfields:
18:30 < cfields> Luke-Jr: will a non-gitian dmg suffice, until i can get in touch with devrandom to fix up a few things?
18:30 < cfields> scripts to build it ofc, not just the result
18:33 < Luke-Jr> suffice for what?
18:33 < Luke-Jr> and what needs fixing? :o
18:33 < cfields> deterministic dmg bounty
18:34 < cfields> mainly, need a raring vm
18:34 < cfields> very possible i just don't know enough about gitian to set one up properly
18:34 < Luke-Jr> well, let's see if I can help with that first
18:35 < cfields> when i try to create a raring image, it says its unsupported
18:35 < cfields> (running on native raring)
18:36 < Luke-Jr> what arch?
18:36 < cfields> but i believe the dmg should be deterministic without gitian already
18:36 < Luke-Jr> yes, but gitian deals w/ the signatures :/
18:36 < cfields> native is x86_64. gitian should start there, since that's where i've tested so far
18:37 < cfields> ok, well don't worry about it then, i'll get gitian up first
18:37 < cfields> actually, i'll probably start with precise and just use a ppa for clang
18:38 < Luke-Jr> I mean what arch do we need the image for?
18:39 < cfields> x64 would be closest to what i've been testing with
18:42 < Luke-Jr> amd64 you mean..
18:42 < cfields> we've done this before, can we just skip it this time? :)
18:43 < cfields> yes, amd64
18:43 < Luke-Jr> what version of vmbuilder?
18:43 < cfields> but don't worry about it, precise is probably a saner choice anyway
18:43 < Luke-Jr> cfields: you're aware there is a distinction between x86 and x32? ;)
18:43 < Luke-Jr> precise+PPA is not necessarily saner
18:44 < Luke-Jr> since we're then trusting not just Canonical, but also <random PPA maintainer>
18:44 < Luke-Jr> the ideal solution would be to build a clang deb in a gitian instance
18:45 < Luke-Jr> but not sure if that's practical for you or not
18:47 < cfields> Luke-Jr: well for now, I just want something that works. There are a dozen things that will need to be reworked, I don't want to spend too much time on work that will be thrown out anyway
18:47 < Luke-Jr> ?
18:47 < cfields> just POC stage for now
19:05 < Luke-Jr> cfields: fwiw, raring works after I upgrade vmbuilder
19:05 < Luke-Jr> but I don't know how easy it is to do that on Ubuntu
19:14 < cfields> hmm, interesting
19:14 < cfields> will have a look, thanks
20:23 < midnightmagic> gmaxwell: Hey man, you're not using the account:password IRC server password or something, we saw your host.
20:25 < Luke-Jr> cfields: I maybe spoke too soon - it errored out later
20:26 < gmaxwell> midnightmagic: stupid ircness.
20:26 < midnightmagic> +1
20:30 < K1773R> midnightmagic: you can auth by passing accout:password as server password?
20:38 < cfields> Luke-Jr: same. I'm trying it on precise just for shits. 99% clang is too old there, but it gets me started with gitian
20:43 < phantomcircuit> K1773R, yes
22:03 < warren> Who is going to the Vegas conference?  I arrive in the afternoon of Dec 8th.
22:35 < gmaxwell> Sadly it overlaps with the picture coding symposium, so it seems I can't go.
22:55 < cfields> anyone know where gitian sets the image size limit (lxc) ?
22:55 < cfields> seems i've outgrown mine
23:32 < Luke-Jr> I wasn't aware LXC had limits O.o
23:42 < cfields> could be because it was a 32bit image
23:43 < cfields> it hit about 3.4 gits and was 100% full
23:43 < cfields> *gigs
23:46 < maaku> Luke-Jr: you can use cgroups to set limits on lxc boxen
23:47 < Luke-Jr> sure, I just didn't see why gitian would do that
23:48 < cfields> no matter, i just split qt out
--- Log closed Sat Nov 23 00:00:01 2013