--- Log opened Tue Jan 28 00:00:05 2014
05:30 < TD> good morning
05:34 < super3> TD, morning
10:11 < andytoshi> here is a cool paper suggesting a category-theoretic view of crypto: http://arxiv.org/pdf/1401.6488v1.pdf
10:11 < andytoshi> maybe nobody here wants that :}
10:16 < gmaxwell> I giggle at the abstract, in that the cryptographic functions whos defintions (rather than proofs) span pages are often the things that get not actual applications. :P
10:58 < jtimon> oh, "maxcoin uses a faster and more secure hashing algorithm for proof of work"
10:58 < optimator> in theory, if you wanted to send 10,000 outputs, would you send it in 1 transaction or split it into multiple transactions?
11:00 < jtimon> optimator: I'm not sure I understand the question, depends on what you want to achive?
11:02 < optimator> say I want to send to 10,000 different addresses using 10 inputs. Is there an advantage in splitting the send into multiple transactions rather than sending it as 1 large transaction?
11:02 < adam3us3> optimator: there is a practical limit n txouts 32 is it?
11:03 < optimator> oh
11:04 < optimator> is that limit detailed somewhere? I don't see it here - https://en.bitcoin.it/wiki/Transactions
11:04 < stonecoldpat> anyone body read the mixcoin paper?
11:05 < stonecoldpat> im going to read it this week - just want a heads up on quality
11:05 < gmaxwell> jtimon: faster?
11:07 < gmaxwell> jtimon: they should get on the horn with NIST, — nist wanted something faster and more secure than sha2 for sha3 and basically no one achieved that. They mostly got equally fast and differently secure. :P
11:10 < adam3us3> optimator: maybe ask on #bitcoin-dev someone will know offhand it maybe in terms of isStandard which is a different limit to the msg format
11:11 < jtimon> gmaxwell: yes, it uses Keccak, but he said SHA256 is slower (sorry flash) https://www.youtube.com/watch?v=_Q684UxfDSU#t=907
11:12 < gmaxwell> jtimon: thats not true, SHA256 is faster than Keccak.
11:13 < gmaxwell> well it depends on your hardware, I'm sure on some things Keccak is faster.
11:13 < gmaxwell> They're nearly tied. It depends on how muc hdata you're hashing.
11:14 < jtimon> I imagined it was simply false, "it's a more fair hasing algorithm" isn't true either
11:14 < andytoshi> gmaxwell: i really like the first half of that arxiv paper actually, it has clear explanations of a lot of basic security ideas and their history. probably the category theory is obtuse if you haven't seen it before, but there isn't much of it. there's more in the second half and it goes over my head.
11:15 < gmaxwell> jtimon: lol they claim that too? 0_o
11:15 < andytoshi> as you say the really obtuse definitions that this work help are not anything that anybody would implement. but having a conceptual framework for this stuff could lead to existence/nonexistence proofs that would be good to have independent of any implementation
11:15 < wumpus> Keccak is supposed to be really fast when implemeted directly in hardware
11:15 < gmaxwell> wumpus: yes, though thats also true of sha256.
11:16 < optimator> adam3us3: thanks
11:16 < gavinandresen> optimator: No limit on number of transaction outputs, but transactions larger than 100Kbytes are non-standard, and larger than 1MB cannot get into a block.
11:18 < optimator> gavinandresen: is there any benefit to structuring the transactions smaller? Say in 10K chunks
11:19 < optimator> versus say a 50k transaction
11:19 < adam3us3> optimator: maybe re-ask that prev bit gavinandresen dropped & rejoined either side of it
11:19 < gmaxwell> optimator: I can't think of any benefit to chunking to 10k instead of 50k.
11:19 < gmaxwell> Other than if you're right on the edge of being included in a block some smaller lower fee paying transactions might scoot in where you don't fit.
11:24 < phantomcircuit> i do txs in 500 output chunks
11:24 < phantomcircuit> i doubt it helps much, but it doesn't reduce the overhead much to do larger chunks
11:25 < gmaxwell> yea, arguably once you get above 100 outputs optimizing for change size makes more sense.
11:38 < jgarzik> Did anybody ever work on background wallet defragmentation?  And perhaps changing the priority calculations to somehow reward shrinking UTXO?
11:38 < jgarzik> We are interested in that </vendor hat>
11:39 < gmaxwell> jgarzik: I believed we merged the priority change that made shrinking the utxo better, though we also capped free transactions to 1000 bytes so it probably matters less.
11:39 < jgarzik> oh, hearing time
11:40 < gmaxwell> (the change was to not count the size of scriptsigs in the size used for computing the priority)
11:40 < jgarzik> ah!
11:41 < jgarzik> http://www.totalwebcasting.com/view/?id=nysdfs
11:46 < gmaxwell> would be nice if someone could figure out how to download the file for later playback.
11:54 < jgarzik> indeed.  I also hit "pause".  The video stopped.  When unpaused... jumped forward in time, missing whatever had been said during the pause.  no buffering :/
11:58 < gmaxwell> okay I'm grabbing it now, but i missed the beginning.
11:58 < gmaxwell> and I may get cut off because I'll be too busy to supervise it.
11:58 < phantomcircuit> it should be available in the future
11:58 < phantomcircuit> it'll be expensive though
12:00 < sipa> the winkelvi!
12:00 < phantomcircuit> sipa, dat statement written by their lawyers
12:00 < sipa> of course
12:00 < sipa> i found their talk in san jose very unimpressive too :)
12:01 < jgarzik> you want the statement written by lawyers... it's on the record
12:01  * jgarzik helped in the US Senate hearing prep
12:02 < phantomcircuit> jgarzik, sure... but usually you'd at least try to pretend like you wrote it
12:02 < phantomcircuit> it seems like he hasn't even read the statement before
12:04 < phantomcircuit> lol question is lol
12:10 < TD> jgarzik: bitpay question for you. feel free to take it private if answers are sensitive in any way. how do you guys handle exchange rates for thinly traded currencies? it seems like CHF local trading has kind of broken today, because some wallets are showing  the bitcoinaverage global cross-rate and others are showing the rate they calculate from actual trading data
12:11 < TD> and the spreads are enormous, mind-bogglingly huge
12:11 < jgarzik> TD, my answer: dunno :)
12:11 < TD> that answer is pretty sensitive :)
12:15 < phantomcircuit> so what im hearing is
12:15 < phantomcircuit> i should start a company that does exotic transaction types
12:28 < phantomcircuit> these guys are silly
12:37 < michagogo|cloud> phantomcircuit: exotic? Like what?
12:37 < phantomcircuit> ahah
12:37 < phantomcircuit> he cant pronounce nascent
12:59 < gmaxwell> is it over yet?
13:05 < jgarzik> gmaxwell, no
13:05 < jgarzik> gmaxwell, and it's fucking fantastic
13:05 < jgarzik> a must-watch
13:05 < TD> it is ?
13:05 < TD> damn. wish i was watching it now :)
13:05 < TD> what makes it so fantastic?
13:05 < gmaxwell> I've captured it.
13:06 < c0rw1n> jgarzik is this one better than the senate hearing?
13:06 < jgarzik> much better
13:06 < gmaxwell> should probably get someone to transcribe.
13:06 < jgarzik> a very, very in-depth, smart discussion
13:06 < jgarzik> ++
13:08 < gmaxwell> As soon as its done I'll upload it so people can transcribe.
13:08 < TD> thanks guys!
13:08 < jgarzik> well, OK, in depth and part an opportunity for these guys to pump their bitcoin stuffs
13:08  * TD has to run
13:09 < nsh> what's being discussed, where?
13:10 < nsh> Department of Financial Services?
13:10  * nsh tunes in
13:10 < jgarzik> it is a loose, free-wheeling discussion
13:11 < jgarzik> IMO the first True Bitcoin Hearing, with people asking tough questions
13:12 < nsh> good
13:16 < andytoshi> is BPP != P open?
13:19 < nsh> the entire hierarchy is up for grabs
13:20 < nsh> (specifically, everything collapses to P if the universe is really silly)
13:20 < gmaxwell> damnit, my battery went dead, and so I missed a bit most likely. :(
13:20 < nsh> :(
13:22 < nsh> i like this line of argument
13:22 < nsh> (not sure it'll be as well received by others listening though)
13:23 < nsh> andytoshi: these talks look interesting http://terrytao.wordpress.com/2008/01/10/distinguished-lecture-series-i-avi-wigderson-the-power-and-weakness-of-randomness-in-computation/
13:23 < nsh> (regarding BPP=?=P)
13:26 < andytoshi> thx nsh. i'm putting together a talk of my own and trying to figure out how to briefly discuss complexity..
13:27 < nsh> oh, cool. for what purpose?
13:28 < nsh> (i'd like to hear that talk if you get a chance to record it. or see the notes at least)
13:28 < andytoshi> it's just a first-year "everyone gives talks to each other" thing at my school. so i want to explain my public-fhe problem..and snarks, because that's the coolest application i can think of
13:29 < andytoshi> but i only have an hour and these people are pure math folks. so i'm having a tough time compressing material :P
13:30 < andytoshi> if i think it'll work out i'll try to record it
13:33  * nsh nods
13:37 < jtimon> later charlee lee? let's see if he says things like "freicoin is like the usd" and "merged mining would destroy your alt because miners would mine it for free" again
13:41 < jtimon> I guess he won't be asked about that, but I'm always eager to hear new "sentences to remember" from him
13:42  * nsh smiles
13:42 < andytoshi> nsh: current plan is to run through complexity, "hard" problems, security models, several examples of cryptosystems which move information in weird ways with respect to the data flows, turing machines and arithmetic circuits, FHE, PCP and verifiable computing, SNARKs  public-FHE
13:42 < jgarzik> Some of the questions and some of the answers were silly or off
13:42 < jgarzik> but overall, pretty good
13:43 < jtimon> I can't see anything, did it finished already?
13:43 < jgarzik> yes. resumes at 2:30pm
13:43 < nsh> andytoshi, sounds good
13:44 < jtimon> jgarzik what time is it for you now?
13:47 < gmaxwell> https://people.xiph.org/~greg/bitcoin_ny_hearing_1.ts https://people.xiph.org/~greg/bitcoin_ny_hearing_2.ts
13:47 < gmaxwell> second file has about :30 left in the upload
13:48 < gmaxwell> maybe it didn't actually miss anything— since the streams would start a bit before realtime and I was probably only offline for two minutes, it's possible. I'm not sure.
13:48 < gmaxwell> I missed a bit at the beginning for sure.
13:49 < jgarzik> 1:49pm
13:49 < jgarzik> jtimon, ^
13:49 < jtimon> thank you both
14:01 < andytoshi> nsh: thx much for that terry tao link. it covers a bunch of what i want to talk about, and has a zk proof of graph 3-colorability which (a) simple and (b) can be fiat-shamir transformed
14:02 < nsh> ah, great
14:03 < nsh> yeah, tao seems to be quite a mathematical legend
14:04 < gmaxwell> andytoshi: is it one where you give the labels or the edges?
14:04 < andytoshi> :P he is indeed.
14:04 < andytoshi> gmaxwell: you give the labels
14:04 < gmaxwell> if you only give the labels how do you know the graph is isomorphic to the query graph?
14:05 < nsh> i watched this talk by tao the other day -- very interesting:
14:05 < nsh> http://www.youtube.com/watch?v=PtsrAw1LR3E
14:05 < andytoshi> gmaxwell: there is no isomorphism involved, the graph and its edges are common knowledge
14:05 < gmaxwell> The classic ZK graph proof is that you commit to a bunch of permuted solutions and then the verifier challenges you to reveal either the labels or the edges.
14:05 < gmaxwell> (but not both, since that would give away the solution)
14:06 < andytoshi> yeah, i'm familiar with that one, that's why i was surprised to see this one
14:06 < andytoshi> i need to think about this, my first impression is that its OK because the verifier knows the graph under consideration
14:07 < gmaxwell> oh interesting.
14:07 < andytoshi> you don't use an isomorphic graph, you use an 'isomorphic' coloring
14:07 < gmaxwell> you randomly pick an edge and only reveal that the two colors are equal.
14:08 < andytoshi> for proving more structural things, eg the existence of hamilton cycles, you need an isomorphic graph..i'll be glad if i can avoid that because mathematicians never get that "isomorphic" does not mean "obviously the same"
14:10 < gmaxwell> well it's nice because you can just wave your hands and say "3-coloring is NP complete"
14:10 < andytoshi> yep :)
14:11 < justanotheruser> Given a network with topology like bitcoins, is it possible to send a message directly (not broadcasted to everyone else) in a zero-knowledge manner (your message somehow finds a path to him, but no one knows that path).
14:12 < andytoshi> justanotheruser: if you have a view of the network you can do onion routing. though it's a bit hard to do without timing side channels
14:12 < gmaxwell> andytoshi: Why can't you just paint everything blue?
14:12 < andytoshi> by 'a bit' i mean in the limit it's impossible, eg if you're the only one doing it everyone can see that it's you
14:13 < andytoshi> gmaxwell: are you talking about the graph problem?
14:14 < gmaxwell> andytoshi: the 3 coloring zk proof. Why can't I just commit to everything blue (e.g. all the edges at a vertex the same color). As it was described there appears to be no test for this.
14:15 < andytoshi> gmaxwell: you are coloring the vertices
14:16 < andytoshi> ..i'm having trouble in that i don't understand how you can commit to one of three colors that can't be forged with roughly 3 tries
14:16 < gmaxwell> oh derp, right, the test should be that they're not the same not that they are the same.
14:17 < andytoshi> :P. it seems to me that if you are doing SHA256(color + secret) or something, you can easily change your secret so you have no commitment. but if there is no secret then the verifier can see right through the commitment so it is not zk
14:18 < andytoshi> wait, i'm an idiot, never mind
14:20 < andytoshi> somehow i was thinking the colors were the commitment and the hashes were what you were proving you had :P
14:22 < justanotheruser> andytoshi: I had an idea to stop timing side channel attacks. But the real question was how to I get my message to someone without knowing their IP
14:24 < andytoshi> if all messages are broadcast, you can 'identify' people by their public keys. just broadcast a message that only your target can encrypt. but this is probably very easy to sybil.
14:25 < andytoshi> you need to have some information about the nodes your are hopping between to avoid sybils
14:25 < andytoshi> decrypt*
14:27 < justanotheruser> andytoshi: yes, nodes would have to have some PoW or PoS to prevent sybil
14:55 < nsh> gmaxwell, did you and/or andytoshi classify/specify the graph problem you were working out from coinjoin transactions
14:55 < nsh> iirc to give an estimate of the number of participants
14:56 < nsh> there were some brief notes or something, i last remember
15:58 < michagogo|cloud> Hmm, what plays .ts files?
15:59 < michagogo|cloud> (also, Chrome is trying to render those two files as text, rather than downloading them...)
15:59 < nsh> vlc generally plays anything that can be decoded into audio/video
16:00 < michagogo|cloud> Ah, I think I have that installed
16:00 < michagogo|cloud> Thanks
16:00 < nsh> np
16:03 < gmaxwell> michagogo|cloud: VLC, mplayer, ffmpeg
16:05 < andytoshi> nsh: not sure if somebody answered you about the coinjoin graph problem
16:05 < nsh> wb, not yet
16:05 < nsh> was interested because a problem in tahoe-lafs looked quite (superficially) similar
16:06 < andytoshi> we were able to specify it, then my girlfriend rosemary found a reduction to the partition problem, which means that it's NP-hard in general to detect whether a transaction might be a cj
16:06 < nsh> (well, it was a maximal-matching over bipartite graph)
16:06 < andytoshi> which is bad, because we wanted to know "how much" of a coinjoin the transaction might be
16:06 < nsh> right
16:07 < andytoshi> so we settled on just looking at the most popular output size and counting the outputs of that size to estimate the maximum possible # of participants, which is an awful estimate
16:07 < nsh> so was the intuition that there is a measure of coinjoin-iness unfounded?
16:07 < gmaxwell> hm? there is a measure. It's just potentially hard to compute.
16:07 < andytoshi> nsh: no, we were able to make the intuition pretty solid. we wanted to measure the amount of information an attacker gains by knowing the exact form of the join
16:07 < nsh> ah, right
16:07 < gmaxwell> though I assume that it's trivial in pratically all cases.
16:08 < gmaxwell> I think though we also realize that if you relax the form slightly and allow one coinjoiner to be paying another then the amount of information gained is far far lower.
16:08 < nsh> hmm
16:08 < andytoshi> yeah, i think we landed on that destroying pretty-much all information since your output owner-set could be completely unrelated to your input owner-set
16:09 < andytoshi> well, that's not quite true
16:10 < andytoshi> i guess in general it is because some participants could be paying several people at once.
16:11 < gmaxwell> if you have some sparsity requirement you still gain information, but its far less... I didn't bother thinking about a formal statement of the sparsity requirement in order to figure out how much less.
16:11 < nsh> is there a practical way to allow participants to negotiate paying for each other to decrease the derivable information?
16:12 < helo> ~ripple?
16:12 < nsh> hmm
16:12 < andytoshi> but otoh, for the joins that we've been doing with my client, everybody is just paying themselves and we have a ton of round outputs alongside N ragged ones. obviously the ragged ones are the change outs and this tells the attacker how many participants there are. and then you can guess which inputs are owned by the same people, and this makes your analysis way easier
16:13 < gmaxwell> (sparsity: each person is paying either 1 or 2 people (potentially but not necessarily including themselves), each output is being paid by 1 or 2 people (again), etc)
16:14 < nsh> i wonder how much correspondence there'll be between this and the zerocash "pouring" dynamics
16:20 < michagogo|cloud> gmaxwell: How far in does ..._1.ts start?
16:20 < gmaxwell> I'm not sure, basically as long as it took me to figure out how to save the data!
16:20 < gmaxwell> someone who actually saw it might be able to tell you.
16:20 < gmaxwell> looks like it's over?
16:25 < c0rw1n> you have the capture gmaxwell?
16:26 < gmaxwell> https://people.xiph.org/~greg/bitcoin_ny_hearing_3.ts is the afternoon session, and this one is complete from start to end.
16:26 < c0rw1n> ok thx :)
16:27 < michagogo|cloud> gmaxwell: So you don't know how much is missing prior to the start of the first file?
16:29 < gmaxwell> No, but for the sake of improving my communications skills, can you help me understand what ambiguity I left in my initial answer to that question?
16:30 < gmaxwell> phantomcircuit: so you say there is archived footage someplace?
16:30 < phantomcircuit> gmaxwell, it's available at the same link as the live video
16:30 < phantomcircuit> http://www.totalwebcasting.com/view/?id=nysdfs
16:33 < jtimon> wget + vlc seems to work just fine, thanks again gmaxwell
16:34 < andytoshi> +1 jtimon, thanks gmaxwell!
16:35 < jtimon> justanotheruser andytoshi I think retroshare does what you want by establishing a F2F network
16:35 < andytoshi> what does f2f stand for?
16:36 < c0rw1n> frined-to-friend
16:36 < jtimon> yep, it's basically a pgp web of trust
16:37 < jtimon> with chat, messages and file sharing
16:37 < gmaxwell> foe to foe network.
16:37 < c0rw1n> foe to foe, that's botnets ddos'ing each other?
16:38 < nsh> ("Old English gefa 'foe, enemy, adversary in a blood feud' (the prefix denotes 'mutuality'), from fah 'at feud, hostile,' from Proto-Germanic *fakhaz)
16:39 < phantomcircuit> retroshare seems like a reasonably good idea
16:39 < phantomcircuit> except i haven't seen anybody break anything on it yet
16:39 < phantomcircuit> which probably means nobody has looked very hard
16:40 < maaku> phantomcircuit: would be even better if they had a group of strong cryptographers looking at it
16:40 < maaku> they're mostly reusing PGP, so if they're even reasonably competent it's probably not horribly broken
16:40 < jtimon> I think the worse part is getting people using it so you're actually not a island in that f2f network...
16:41 < maaku> but that said, I'm not sure PGP is the right construct to use...
16:42 < jtimon> gpg ?
16:43 < phantomcircuit> maaku, doesn't provide for forward secrecy
16:43 < phantomcircuit> there's no reason for a f2f network not to have pfs
16:43 < maaku> jtimon: what phantomcircuit said
16:43 < maaku> deniability, perfect forward secrecy, etc.
16:44 < maaku> PGP is ideal for on-the-record, or point-to-point encrypted email
16:44 < maaku> not really designed for social networks...
16:44 < maaku> which is unfortunate - i wish there was an active #retroshare-wizards community
16:44  * jtimon si reading wikipedia's article on forward secrecy
16:45 < gmaxwell> maaku: I use PGP more than most people, and I can only think of three or four times when the non-repudiation it creates was desirable, and a bunch of other times where it was a liability.
16:46 < maaku> gmaxwell: is it possible to do non-repudiation over store-and-forward, non-interactive medium?
16:46 < gmaxwell> yes. sure.
16:47 < gmaxwell> you mean non-non-repudiation and the answer is still sure.
16:47 < maaku> er, yeah
16:47 < gmaxwell> e.g. just do ECDH with your pubkey and mine, and we have a encryption key which authenticates the channel but in a non-transferable way.
16:47 < gmaxwell> forward secrecy is a bit harder, but can be done.
16:49 < andytoshi> gmaxwell: how is that ECDH auth nontransferable?
16:49 < gmaxwell> E.g. the dumbest way to get forward secrecy is I just generate one pubkey for each month from now till my key expired 10 years from now, and concat them... and then as each month goes by I destroy more of the private key... this is functional but kinda daft.
16:49 < gmaxwell> andytoshi: because you can simulate it without my cooperation.
16:50 < gmaxwell> andytoshi: e.g. I give you my private key and a message encrypted with a session key generated with my private key and maaku's public key.  How do you know maaku wrote it and I didn't just make itup?
16:50 < andytoshi> oh, thx, i gotcha
16:51 < andytoshi> i was just being daft. my brain is not working properly today it seems..
16:52 < gmaxwell> Smarter non-interactive forward secrecy can be done using identity based encryption.  E.g. you make an IBE master key and use it to generate your zillion future private keys, but then your public key is juse the IBE master public key. You destroy the IBE master private key... and the ephemerical IBE keys as you go. This has the advantage of making the public key the same size as a regular ECC public key.
16:52 < gmaxwell> (though your private data is large)
16:53 < gmaxwell> There are some IBE based schemes that eliminate the requirement to do precomputation of the ephemerial private keys, but I dunno how they work, just saw papers on them. (sadly most of these papers are not written in comprehensible english... so actually sorting out what they're doing takes more work than justfied unless you need the result…)
17:06 < phantomcircuit> andytoshi, the key is that you know maaku wrote it because you didn't forge the message, but anybody else cant prove that he did because you could have forged the signature
17:23 < maaku> in other words, you can only prove authorship is maaku OR andytoshi
17:24 < gmaxwell> maaku: not even— you prove that the author had help from maaku or andytoshi (or anyone who has one of their private keys, which anyone who verifies it need to have)
17:24 < andytoshi> nice! i'm passingly familiar with the concept but i've never seen a simple example
17:25 < gmaxwell> a ring signature lets you do the actually do "authorship is maaku OR andytoshi" in a publically verifyable way, which can be useful in that space too.
17:25 < maaku> doesn't OTR also have some sort of construction such that after the fact some secret is revealed letting anyone construct fake transcripts?
17:26 < gmaxwell> maaku: yea, so what OTR does is uses seperate keys for authentication and encryption, and intentionally leaks the auth keys once they're used. Then it includes a tool to let you create forged transcripts.
17:27 < gmaxwell> But really, thats kinda unnecessary, the security properties are achieved even without it. But it does make it easy to make demonstrations that transcripts prove nothing.
17:29 < michagogo|cloud> 23:50:29 <gmaxwell> andytoshi: e.g. I give you my private key and a message encrypted with a session key generated with my private key and maaku's public key.  How do you know maaku wrote it and I didn't just make itup?
17:29 < michagogo|cloud> gmaxwell: is that what you meant to say?
17:30 < michagogo|cloud> ("give you my private key")
17:30 < gmaxwell> yes.
17:30 < michagogo|cloud> okay
17:31 < gmaxwell> If I don't give you my private key, even telling if the session key is a result of a maaku+me key agreement is the decisional DH problem and is believed to be intractable in a suitable group.
17:37  * michagogo|cloud assumes that in such a case you'd be using disposable privkeys?
17:37 < gmaxwell> no— I mean, you're not supposted to give away any keys at all. and its pointless to do so, and I was pointing out that it was pointless to do so.
17:40 < michagogo|cloud> Oh
17:40 < michagogo|cloud> Ah, I see.
17:41 < michagogo|cloud> You were saying that the channel is non-transferable because even if you did give me your private key it wouldn't prove anything?
17:42 < gmaxwell> right, the _authentication_ is non-transferable. It convinces me, but not anyone else even if I give them everything I know.
17:42 < michagogo|cloud> Right, since you can't prove that you didn't create this message, only you can know for a fact that that's the case
17:43 < gmaxwell> yea, it's even stronger than that though— a ring signature gets you that too. e.g. either X or Y created the message (assuming X and Y kept their private keys private)
17:43 < michagogo|cloud> (well, I guess you could if you get into the realm of trusted hardware, e.g. a device that generates a key and logs everything done with it)
17:43 < michagogo|cloud> Or is that not the case?
17:44 < gmaxwell> with a auth via ECDH  the message is the same as plaintext.
17:44 < andytoshi> i think this notion of "non-transitive information" is one of the weirder things to come out of modern cryptography
17:45 < gmaxwell> even with trusted hardware because you can't even verify anything at all without one of the private keys.
17:45 < michagogo|cloud> (As you may have noticed, I know ~nothing-very little about cryptography
17:45 < michagogo|cloud> )
17:51 < gmaxwell> andytoshi: well it's usually the color of the bits which is non-transitive rather than the information itself.
17:53 < andytoshi> gmaxwell: well, i can prove to you in zero knowledge that (say) i have a 3-coloring of a graph, and therefore that such a coloring exists
17:53 < andytoshi> and the existence of a coloring is a "solid" bit of information
17:53 < gmaxwell> different definition of 'color'.
17:54 < gmaxwell> required reading if you have not read: http://ansuz.sooke.bc.ca/entry/23
17:54 < andytoshi> hmm, yeah.
17:54 < andytoshi> i have indeed, a very useful article
18:00 < andytoshi> i'm not convinced that the existence of a 3-coloring is merely color though. it is a color on the bits of the actual coloring, sure, but the original graph is public knowledge and the fact of whether or not it is 3-colorable constitutes real context-independent information about it.
18:01 < gmaxwell> hm. you're right.
18:01 < gmaxwell> if we have a NIZK proof that the 3-coloring exists we clearly have information (1 bit, if your prior was uniform!)
18:02 < gmaxwell> and if we are the verifier in an interactive protocol, then we clearly have 1 bit too, because its exactly the same as the prior case.
18:02 < gmaxwell> but if we are not the designated verifier, then we know nothing at all.
18:02 < gmaxwell> And thats weird.
18:04 < andytoshi> very. and we are deriving this bit of real information (the graph has a coloring) from the color of the 3-coloring (which the prover has but verifier doesn't). so there is also a sort of level-crossing between meta-information and information, and we see in eg the goedel theorem that this level-crossing leads into all sorts of Weird Things happening
18:05 < andytoshi> ordinarily these kind of comments are just philosophical masturbation but with bitcoin we are assigning actual value to information and this blurring of categorical boundaries might have actual implications for how we ought to think about it
18:06 < gmaxwell> warning wank field detected.
18:06 < andytoshi> that's a really vague thing to say, sorry, i'm just spitballing
18:06 < gmaxwell> ;P
18:06 < gmaxwell> hehe
18:06 < andytoshi> :P
18:07 < gmaxwell> nah no need to apologize, I find myself contemplating interesthing things like that often and thinking "hm this really should have some deeper consequence" but it often doesn't have any I can find.
18:07 < jron> gmaxwell: thank you for posting the hearing cap.
18:07 < nsh> and cloak of comprehension
18:19 < helo> gmaxwell: you're going to be one of the panelists tomorrow in NY, right?
18:20 < helo> otherwise there's no way we can make up for the litecoin "creator"
18:22 < jtimon> I read he said in miami that some people call him "satoshi lite"...still eager to watch his intervention...
18:23  * andytoshi would never be so vain as to take satoshi's name..
18:24 < sipa> recently a colleague asked me whether i was satoshi
18:24 < sipa> perhaps i shouldn't have answered in japanese
18:25 < brisque> andytoshi: that your nick is an anagram of satoshi is not a coincidence?
18:25 < sipa> anagram?
18:25 < c0rw1n> magarna
18:25 < gmaxwell> Ohayou asadimaska
18:26 < sipa> hajimemashite, satoshidesu
18:26 < gmaxwell> helo: they are doing more of this tomorrow?  And no— while I'm comfortable with public speaking I generally have the good sense to stay the heck away from official proceedings.
18:29 < helo> gmaxwell: yeah, there are three sessions tomorrow
18:30 < maaku> sipa: "If I was Satoshi with $1bn to my name, would I still be working here?"
18:30 < helo> the litecoin guy couldn't really even stay on topic... seemed like he just wanted to impress them with info overload
18:33 < Luke-Jr> sigh
18:34 < sipa> maaku: ha
18:35 < midnightmagic> maaku: I would. :)
18:35 < maaku> midnightmagic: wish I had your job :)
18:35 < midnightmagic> maaku: Oh, I don't mean my official job. I meant *in here*.
18:36 < maaku> oh heh, yeah
18:36 < midnightmagic> :-D
18:36  * michagogo|cloud wonders if there'll be recordings of the streams tomorrow as well
18:37 < jtimon> but sipa's colleague is from his official job, no?
18:37 < sipa> yes
18:38  * Luke-Jr thinks it's obvious who Satoshi really is, but *shrug*
18:38 < michagogo|cloud> Luke-Jr: o_O
18:38 < c0rw1n> obvious, really
18:38 < sipa> really?
18:39 < maaku> Al Gore, obviously
18:39 < tacotime_> I always knew he was a time travelling Japanese cat from the 42nd century.
18:39 < sipa> oh, right
18:39 < Luke-Jr> well, Sirius was the only developer "besides" Satoshi for a long time, and he was committing from the start of the git history..
18:39 < Luke-Jr> and left at the same time
18:40 < gmaxwell> please don't speculate about that kind of stuff.
18:40 < c0rw1n> gwern has an interesting, abandoned investigation on satoshi
18:40 < gmaxwell> if someone convinces people that you are satoshi, then you get the security costs of shithead nutbags thinking that kidnapping your family might be a great way to get an anonymous billion dollars.
18:40 < Luke-Jr> at all? this channel is still private, right? O.o
18:41 < maaku> Luke-Jr: this channel is now logged
18:41 < gmaxwell> and If you are _not_ actually satoshi, then the cost of security against that threat is really intolerable.
18:41 < Luke-Jr> meh
18:41 < Luke-Jr> maaku: I don't see that in the topic
18:41 < gmaxwell> Besides, we all know Satoshi was a time travelling Japanese cat from the 42nd century
18:41 < Luke-Jr> so it shouldn't be
18:41 < andytoshi> the logs are non-nonrepudiable fwiw
18:41 < Luke-Jr> gmaxwell: s/cat/doge/
18:42 < gmaxwell> Luke-Jr: though fwiw, the bitcoin history started on sourceforge and was imported into git.
18:42 < andytoshi> to Luke-Jr's point, the logs really should be mentioned in the topic
18:42 < andytoshi> i'm happy to strike anything that people request but people should be aware of it
18:42 < gmaxwell> so put them there, most of you are ops here.
18:43  * Luke-Jr kicks ChanServ
18:43 < Luke-Jr> :p
18:43 < gmaxwell> (I took the top N people by number of messages sent and made all of you ops, for N=10 or something)
18:43 < c0rw1n> if there are public logs i'd love to read them indeed, this being the most interesting #bitcoin-* i've found
18:44 < tacotime_> http://download.wpsoftware.net/bitcoin/wizards/
18:44 < c0rw1n> ok thx :)
18:44 < tacotime_> I would prefer it continue to be logged, as I read these regularly when my VPS dies.
18:45 < tacotime_> It's a lot of the more interesting Bitcoin related discussion.
18:48 < justanotheruser> jtimon: not really what I was looking for. A f2f network doesn't do much in terms of lack timing attacks and lack of knowledge of the network
18:50 < maaku> justanotheruser: it's probably the closest thing out there though ... as I said earlier, I wish there was a community of cryptographers & security people willing to work on adding those features to retroshare-like apps
18:50 < maaku> (hint hint)
18:52 < justanotheruser> maaku: Basically what I'm looking for is a network that is resistant to timing attacks (RS fails), doesn't require full network broadcasting (RS passes), doesn't give info about who you know (RS fails), and doesn't require the trust of your peers (RS fails somewhat)
18:52 < justanotheruser> I believe those criteria would make the ultimate anonymity layer
18:55 < maaku> justanotheruser: I think if you swapped out the retroshare crypto for stuff with forward secrecy, added pond-like random message delays, and use Tor with fixed message sizes you could get most of the way there
18:57 < justanotheruser> maaku: I was thinking everyone just sends 1kb out every 3 seconds. Most of the time your node should have something useful to broadcast, if not then you can temporarily leave the network (or maybe theres a better solution)
19:04 < andytoshi> justanotheruser: probably you want to broadcast random data so that even if there is no traffic it is hard to do analysis
19:06 < brisque> andytoshi: chaffing your connection would be difficult though. if you limited yourself to 0.3kb/s that's a ceiling you can't easily go past. as soon as you go above that it's fairly apparent that you're doing /something/. same issue as before.
19:06 < brisque> andytoshi: if you ramp up the chaff data to a useful level, you're suddenly burning terabytes a month for no real purpose.
19:07 < andytoshi> yeah, maybe there is a way to have chaff based on a rolling average of actual data usage
19:08 < c0rw1n> do ty _have_ to send your message in full? or could you be sending it .3kbps at a time?
19:08 < jron> after a over an hour, the most interesting quote to come out of the hearing has been: "...I think the level of engagement and the positive reception that bitcoin companies are now getting from certain banks has lead us all to believe that we're very very close to the banking industry opening up to bitcoin. I think we're probably 2 or 3 months away from some well known banks coming out with kind of clear procedures on how to work with them as a bitc
19:10 < sipa> with them as a bitc[...]
19:11 < jron> with them as a bitcoin company and they'll position themselves as a bitcoin friendly bank." - Barry Silbert
19:11 < andytoshi> brisque: there is an example of the uncertainty principle for fourier transforms involving water waves, where you can't simultaneously determine the waves' frequency and breadth or something like that. using that idea you can smear out the actual changes in traffic volume
19:11 < andytoshi> i'll see if i can find that..
19:16 < jron> oh, and that someone is trying to remake e-gold\goldmoney.
19:28 < andytoshi> brisque: i can't find it, but i did find a paper by folland called "uncertainty: a mathematical survey" which gave the formulation that i wanted: there exists some number (1/16pi or something) which bounds below the product of your variance and your fourier transform's variance. for waves this means you can measure the water height arbitrarily well, or the wave frequency arbitrarily well, but not
19:28 < andytoshi> both
19:28 < andytoshi> (though ofc you can just do two measurements)
19:29 < andytoshi> so the better you keep your chaff quantity following a sine wave, the worse time an attacker will have determining the actual data level
19:30 < andytoshi> since the attacker can only measure frequency in that case, he can't measure actual bandwidth without knowing what's real and what's not
19:32 < andytoshi> then for example if you can always keep your bandwidth uncertain within +/- 10kb/s, and don't increase the amount of chaff by more than 10kb/s/day, an attacker can only see changes in bandwidth usage with granularity of one day, thus defeating timing analysis
19:33 < brisque> hm. I've never believed that random timings and fake data really help to secure a service. if you're running something like RetroShare you're probably going to need to be attracting a lot of attention to yourself for anybody to bother doing traffic analysis. if they are, you can assume they're probably just going to get a warrant and bust your door down.
19:34 < jrmithdobbs> andytoshi: the shorter way of saying that is "run a bandwidth restricted tor relay on the same link"
19:35 < andytoshi> jrmithdobbs: yeah :} and randomly change the bandwidth cap
19:35 < jrmithdobbs> but i'm with brisque, I'm not so sure I buy shamir/etc's arguments on this topic
19:36 < jrmithdobbs> there's analysis to be done there but it's kind of like plugging the whole in a rowboat with your finger whene there's 500million more holes
19:36 < jrmithdobbs> s/whole/hole/
19:37 < super3> my question is what is the minimal amount of fake data you can throw around without just wasting bandwidth
19:37 < super3> i like the idea of just using it in random brusts rather than continual data usage.
19:37 < jrmithdobbs> and I don't think we really have a correct answer yet but i've not specifically read the paper andytoshi mentioned :)
19:38 < brisque> even a kilobyte a second adds up, especially over multiple peers.
19:38 < super3> where is this paper?
19:38 < super3> brisque, also makes you stand out on a network.
19:39 < justanotheruser> andytoshi: yes, every N seconds you broadcast data
19:39 < justanotheruser> to all your peers
19:39 < jrmithdobbs> super3: in fact, i'm not sure anyone's actually looked for *generic* traffic, the only stuff I'm recalling specifically involve using spam/smtp as transport
19:40 < andytoshi> jrmithdobbs: yeah, that's an example of what i'm saying about using periodicity to hide actual volume. so if you burst every second, and increase traffic whenever you need it, your attacker can see your volume changing with 1-second granularity
19:41 < andytoshi> i guess that's way way simpler than trying to shape continuous traffic to have decently periodic features..
19:41 < brisque> super3: like the guy who puts way too many locks on his door.
19:42 < super3> brisque, im that guy
19:42 < super3> brisque, rather too many locks than not enough
19:42 < jrmithdobbs> andytoshi: if anything normalizing like that may obscure the original intent but has the side effect of calling attention to the traffic because NOTHING is that normal
19:43 < brisque> super3: locks seem a little silly when people have glass windows.
19:43 < jrmithdobbs> heh
19:43 < jrmithdobbs> tbqh, having the lock makes the lock do it's job
19:43 < jrmithdobbs> don't even have to lock it
19:44 < jron> here is the e-gold like company the lawyer refered to: http://www.coeptis.com/
19:44 < jrmithdobbs> (in fact, i rarely do, lol)
19:46 < jrmithdobbs> super3: it's actually quite a fitting analogy
19:46 < jrmithdobbs> super3: you do realize that 98% of locks on the market can be opened in <15s with basically a week's worth of effort, right?
19:47 < jrmithdobbs> and said effort isn't salted so effort on one core of a similar type equates to effort on another core of the same design with different keying
19:47 < super3> jrmithdobbs, i agree with you
19:48 < brisque> locksport is great fun.
19:48 < jrmithdobbs> great party trick if nothing else
19:49 < jrmithdobbs> (and the "week's worth of effort" was from zero knowledge of how they work, not per core, to be clear ;p)
19:49 < brisque> I enjoyed the opening contests at defcon too, they even had casascius coins (to keep the comment on topic)
19:50 < jrmithdobbs> i like freaking out locksmiths
19:51 < jrmithdobbs> had one try and upsell me on some padlocks towing something recently, "Ya see this, this is so thieves can't get a pick in here" "what? yes you can, look: <opens lock>" ...
19:51 < jrmithdobbs> he almost called the cops, lol
19:51 < jrmithdobbs> (because said tools are illegal in tx unless licensed)
19:52 < brisque> well, be careful. fine line between a party trick and freaking people out.
19:53 < jrmithdobbs> it's more fun not to pick the locks and show people the releases on filing cabinets/etc instead ;p
19:53 < jrmithdobbs> *that* freaks people out .. noone thinks about this stuff, ha
19:55 < maaku> there's a great story about feynman 'picking' the combinations of his colleages safes in the manhatten project
19:55 < gmaxwell> where he went and precomputed the combinations and then appared to be able to do it instantly? :P
19:56 < gmaxwell> or was that where there was some bypass?
19:56 < brisque> combination locks are usually the easiest ones, all you need is a drink can and a pair of scissors.
19:58 < jrmithdobbs> gmaxwell: that sounds like a fun story hadn't heard it
20:00 < gmaxwell> one of the puzzles in this years MIT mystery hunt, part of the runaround at the end, was a pin-tumbler lock in the form of a pool-table sized 'bed'. (you had the manipulate slats on the sides of the bed to pick the lock, after first solving some nested trick with a magnetic trigger)
20:01 < gmaxwell> people in my team were kinda mobbing the bed and preventing effective work on it— someone called out "who here has picked a lock before" and 3/4 of the room, including everyone within 10 feet of the bed raised their hands... so that wasn't a good distinguisher on who should be taking the lead...
20:01 < maaku> gmaxwell: correct, iirc he was able to feel the last two (of three) numbers on an opened safe, and most people kept their safes opened while they were in the office
20:01 < maaku> jrmithdobbs: it's in "surely your joking?" i think
20:12 < Emcy> anyone ever picked those eletronic dongle locks
20:12 < Emcy> the ones where the key sort of looks like a coin cell
20:21 < gmaxwell> Emcy: I believe I've seen those in the form of the 'keys' used for segways.
20:21 < gmaxwell> I'd _assume_ they're cryptographic.
20:22 < brisque> I wouldn't. I expected the one for my car to, but it just uses rolling codes like all the rest.
20:23 < brisque> if you really want to piss somebody off, go out of range of the car and punch the unlock button a few hundred times. once the keyfob rolls past the acceptable window for the car, it's useless.
20:24 < Emcy> therye rfid
20:24 < Emcy> i used to have one for my dorm door.....the lock seemed to have a nifty internal power source
20:24 < brisque> oh wait, there's stock standard RFID tags probably. I saw a store stocking them.
20:25 < gmaxwell> brisque: I know that some of the car ones are actually cryptographic because they've used snakeoil crypto that people have successfully attacked! (doh!)
20:25 < Emcy> and i once read something about those lock systems being able to form thier own sneakernet via a writable area of the rfid and keep logs of when and who opens doors etc
20:25 < sipa> gmaxwell: a friend of mine at university did :)
20:25 < sipa> (keeloq)
20:26 < gmaxwell> Emcy: I like the electronic locks that look like dial combination locks where spinning the dial powers it.
20:27 < Emcy> never seen that
20:27 < gmaxwell> They're pretty insanely secure because the only connection between the outside and inside is a couple wires, and all the locking is on the inside.
20:27 < brisque> gmaxwell: wonder how big a mechanical lock that used EC would be. it's presumably possible to make a mechanical computer that could do it, just it would be a little on the large side.
20:27 < gmaxwell> about the best attacks on a well built one are bugging the dial.
20:29 < brisque> bombe style with electromechanical calculation?
20:32 < Emcy> yep locks are pretty interesting
20:32 < brisque> likely impossible, but I'd pay big money to see a purely mechanical computer doing a SHA256 hash.
20:33 < gmaxwell> does it have to do the whole hash? :P
20:33 < sipa> i think being able to find 32 bits of it is not significantly easier
20:34 < sipa> well, even 1 bit
20:34 < gmaxwell> well I meant the whole function.
20:34 < sipa> you mean just a single compression function?
20:34 < gmaxwell> making a mechnical computer to compute one round wouldn't be that terrible.
20:35 < brisque> wouldn't be very impressive though
20:41 < Emcy> people make stuff like that in minecraft
20:41 < Emcy> it probably counts as emulation, but you can see the signal travelling in the 'data lines' so its close enough
20:41 < gmaxwell> I think we're not exposing people to enough really awesome ideas such that they think spending their time making ALUs in minecraft is a good way to have fun. :P
20:41 < Emcy> i think someone made a full 16 bit FLU+ALU+registers and etc out of blocks
20:42 < Emcy> how is that not fun
20:43 < brisque> fairly time consuming for the result
20:46 < Emcy> either ALUs or this http://www.youtube.com/watch?v=afcudstM9zA
20:46 < Emcy> also fairly time consuming
20:46 < brisque> gmaxwell: \o/ https://pay.reddit.com/r/Bitcoin/comments/1wfbjn/get_your_coins_out_right_away_alleged_weakness/
20:50 < brisque> gmaxwell: oh, and a bigger one https://pay.reddit.com/r/Bitcoin/comments/1wf5qb/possible_warning_btc_addresses_with_known_public/
20:55 < andytoshi> EnronIsHere helpfully explains "In cryptography, there is always a shortcut. Often very difficult to find but it's always there somewhere. That point really can not be stressed enough.
20:57 < andytoshi> i assume by "cannot be stressed enough" he means that his stressing program won't halt.... but he has no clue why since he doesn't believe in nonhalting programs :)
21:06 < Emcy> "stressing program wont halt"
21:06 < Emcy> life.exe
21:17 < brisque> andytoshi: this is a nice explanation too https://bitcointalk.org/index.php?topic=437220.msg4809894#msg4809894
21:17 < andytoshi> ohh thx brisque i was wondering wth a "rendezvous point" was
21:18 < brisque> basically his precomputed keys, heh.
21:45 < brisque> I'm sure everybody has seen the person joining #bitcoin and spamming obscenities at the OPs. they're all listed on bitnodes.io as having been seen running a node at some point.
21:45 < brisque> is somebody seriously running a bitcoin-related botnet and spamming the channel with it?
21:50 < brisque> oh, actually. they're shared VPN addresses rather than a botnet. that's comforting.
22:11 < super3> is Luke-Jr around? i'm just about done with proof-of-pizz
22:11 < super3> proof-of-pizza*
22:46 < Luke-Jr> we should all plan to plan out proof-of-steak at the Texas conference
22:47 < Luke-Jr> and announce it right at the end of the month
22:47 < Luke-Jr> maybe late by a day
22:47 < justanotheruser> Luke-Jr: have you heard of cyruscoin?
22:47 < Luke-Jr> no
22:47 < justanotheruser> It's based on proof of twerk
22:49 < tacotime_> I'll be at the Texas conference, but I can't get behind proof-of-steak because I'm a pescetarian. :/
22:50 < Luke-Jr> tacotime_: surely there is a seafood steak?
22:52 < tacotime_> I could do a salmon steak, I suppose. :D
22:53 < tacotime_> https://bitcointalk.org/index.php?topic=421842.msg4800547#msg4800547
22:53 < tacotime_> He actually cracked a brainwallet privkey, heh.
22:53 < Luke-Jr> not hard, brainwallets are stupidly insecure
22:55 < brisque> tacotime_: brain wallet? it was probably created with his "weak key generator", which only generates keys of which he has the rainbow tables for.
22:56 < super3> ha ha. cyruscoin thats a new one
22:56 < tacotime_> Heh.
22:58 < super3> once its a little closer to the confrence ill find a good steakhouse(with some non-meat options too) and we can all go there
22:58 < super3> perhaps we can even pre plan and have them accept Bitcoin
--- Log closed Wed Jan 29 00:00:07 2014