00:02:24	Fistful_1f_Coins:	Fistful_1f_Coins is now known as Fistful_of_Coins
00:18:58	adam3us3:	gmaxwell, andytoshi: i think an interesting rule for fiat coins would be to encode the monetary policy into a smart issuance policy. eg 2%/yr QE cap, things like that. then they cant exceed it without a super majority vote of clients
00:20:19	adam3us3:	gmaxwell, andytoshi: cryptographic assurance against moral-hazard :) ie cant panic bend the formal rules because a monetary policy committee cant withstand political pressure even though they know its a bad idea.
00:58:44	roidster:	roidster is now known as Guest34518
01:26:11	Guest44977:	Guest44977 is now known as rdymac
03:32:25	Luke-Jr:	new proof-of- system to be announced soon based on the efforts of BlueMatt, myself, and others!
03:37:08	petertodd:	Luke-Jr: curious
03:39:19	Luke-Jr:	petertodd: another guy is writing up the announcement post now
03:39:40	petertodd:	Luke-Jr: oh nice, you guys are serious?
03:39:51	brisque:	Luke-Jr: a serious POW, not like proof-of-twerk?
03:39:53	Luke-Jr:	petertodd: <.<
03:39:56	brisque:	well, proof of something.
03:40:02	Luke-Jr:	>.>
03:40:05	brisque:	oh.
03:40:40	brisque:	still interested.
03:47:19	andytoshi:	by 'writing up' you mean that if i stay up another hour i'll see it?
03:48:58	Luke-Jr:	andytoshi: not sure what the schedule is on it
03:49:14	Luke-Jr:	he said by this weekend :<
03:50:17	Luke-Jr:	.. but he might have a draft for me to look over in a few mins
04:29:32	brisque:	has somebody tried poking ghash.io and asking them to change their default block size?
04:30:50	Luke-Jr:	brisque: they intentionally have it set low because they can't afford a decent internet connection apparently -.-
04:31:17	Luke-Jr:	(and can't figure out how to run a pool with the block broadcasts colo'd)
04:31:48	brisque:	that's awful. I've seen them orphan their own blocks quite a few times too.
04:33:56	brisque:	it would be nice for them to make decent sized blocks though. surely they can manage the small influx of data they need to broadcast them properly.
07:37:42	roidster:	roidster is now known as Guest56441
08:32:23	cymanon:	cymanon is now known as cymanon-zzzz
10:30:12	TD[away]:	TD[away] is now known as TD
10:30:15	TD:	good morning
10:32:20	frankbutt:	frankbutt has left #bitcoin-wizards
10:34:42	super3:	TD, morning
14:25:01	mr_burde_:	mr_burde_ is now known as mr_burdell
15:11:50	andytoshi:	here is a cool paper suggesting a category-theoretic view of crypto: http://arxiv.org/pdf/1401.6488v1.pdf
15:11:54	andytoshi:	maybe nobody here wants that :}
15:16:47	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
15:41:03	HInfoForIRC:	HInfoForIRC has left #bitcoin-wizards
15:51:07	krl:	krl has left #bitcoin-wizards
15:58:33	jtimon:	oh, "maxcoin uses a faster and more secure hashing algorithm for proof of work"
15:58:48	optimator:	in theory, if you wanted to send 10,000 outputs, would you send it in 1 transaction or split it into multiple transactions?
16:00:54	jtimon:	optimator: I'm not sure I understand the question, depends on what you want to achive?
16:02:15	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?
16:02:40	adam3us3:	optimator: there is a practical limit n txouts 32 is it?
16:03:13	optimator:	oh
16:04:23	optimator:	is that limit detailed somewhere? I don't see it here - https://en.bitcoin.it/wiki/Transactions
16:04:57	stonecoldpat:	anyone body read the mixcoin paper?
16:05:04	stonecoldpat:	im going to read it this week - just want a heads up on quality
16:05:36	gmaxwell:	jtimon: faster?
16:07:25	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
16:10:05	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
16:11:45	jtimon:	gmaxwell: yes, it uses Keccak, but he said SHA256 is slower (sorry flash) https://www.youtube.com/watch?v=_Q684UxfDSU#t=907
16:12:45	gmaxwell:	jtimon: thats not true, SHA256 is faster than Keccak.
16:13:16	gmaxwell:	well it depends on your hardware, I'm sure on some things Keccak is faster.
16:13:26	gmaxwell:	They're nearly tied. It depends on how muc hdata you're hashing.
16:14:31	jtimon:	I imagined it was simply false, "it's a more fair hasing algorithm" isn't true either
16:14:44	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.
16:15:14	gmaxwell:	jtimon: lol they claim that too? 0_o
16:15:18	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
16:15:24	wumpus:	Keccak is supposed to be really fast when implemeted directly in hardware
16:15:57	gmaxwell:	wumpus: yes, though thats also true of sha256.
16:16:17	optimator:	adam3us3: thanks
16:16:34	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.
16:17:57	gavinandresen:	gavinandresen has left #bitcoin-wizards
16:18:05	optimator:	gavinandresen: is there any benefit to structuring the transactions smaller? Say in 10K chunks
16:19:07	optimator:	versus say a 50k transaction
16:19:17	adam3us3:	optimator: maybe re-ask that prev bit gavinandresen dropped & rejoined either side of it
16:19:37	gmaxwell:	optimator: I can't think of any benefit to chunking to 10k instead of 50k.
16:19:59	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.
16:24:05	phantomcircuit:	i do txs in 500 output chunks
16:24:21	phantomcircuit:	i doubt it helps much, but it doesn't reduce the overhead much to do larger chunks
16:25:25	gmaxwell:	yea, arguably once you get above 100 outputs optimizing for change size makes more sense.
16:38:21	jgarzik:	Did anybody ever work on background wallet defragmentation? And perhaps changing the priority calculations to somehow reward shrinking UTXO?
16:38:53	jgarzik:	We are interested in that
16:39:05	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.
16:39:32	jgarzik:	oh, hearing time
16:40:01	gmaxwell:	(the change was to not count the size of scriptsigs in the size used for computing the priority)
16:40:46	jgarzik:	ah!
16:41:50	jgarzik:	http://www.totalwebcasting.com/view/?id=nysdfs
16:46:39	gmaxwell:	would be nice if someone could figure out how to download the file for later playback.
16:54:03	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 :/
16:58:17	gmaxwell:	okay I'm grabbing it now, but i missed the beginning.
16:58:29	gmaxwell:	and I may get cut off because I'll be too busy to supervise it.
16:58:46	phantomcircuit:	it should be available in the future
16:58:50	phantomcircuit:	it'll be expensive though
17:00:05	sipa:	the winkelvi!
17:00:30	phantomcircuit:	sipa, dat statement written by their lawyers
17:00:40	sipa:	of course
17:00:59	sipa:	i found their talk in san jose very unimpressive too :)
17:01:30	jgarzik:	you want the statement written by lawyers... it's on the record
17:01:38	jgarzik:	* jgarzik helped in the US Senate hearing prep
17:02:35	phantomcircuit:	jgarzik, sure... but usually you'd at least try to pretend like you wrote it
17:02:44	phantomcircuit:	it seems like he hasn't even read the statement before
17:04:57	phantomcircuit:	lol question is lol
17:10:56	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
17:11:05	TD:	and the spreads are enormous, mind-bogglingly huge
17:11:21	jgarzik:	TD, my answer: dunno :)
17:11:45	TD:	that answer is pretty sensitive :)
17:15:35	phantomcircuit:	so what im hearing is
17:15:50	phantomcircuit:	i should start a company that does exotic transaction types
17:28:09	phantomcircuit:	these guys are silly
17:37:33	michagogo|cloud:	phantomcircuit: exotic? Like what?
17:37:48	phantomcircuit:	ahah
17:37:57	phantomcircuit:	he cant pronounce nascent
17:59:07	gmaxwell:	is it over yet?
18:05:22	jgarzik:	gmaxwell, no
18:05:26	jgarzik:	gmaxwell, and it's fucking fantastic
18:05:29	jgarzik:	a must-watch
18:05:30	TD:	it is ?
18:05:35	TD:	damn. wish i was watching it now :)
18:05:40	TD:	what makes it so fantastic?
18:05:55	gmaxwell:	I've captured it.
18:06:17	c0rw1n:	jgarzik is this one better than the senate hearing?
18:06:22	jgarzik:	much better
18:06:27	gmaxwell:	should probably get someone to transcribe.
18:06:29	jgarzik:	a very, very in-depth, smart discussion
18:06:32	jgarzik:	++
18:08:26	gmaxwell:	As soon as its done I'll upload it so people can transcribe.
18:08:38	TD:	thanks guys!
18:08:38	jgarzik:	well, OK, in depth and part an opportunity for these guys to pump their bitcoin stuffs
18:08:42	TD:	* TD has to run
18:09:49	nsh:	what's being discussed, where?
18:10:13	nsh:	Department of Financial Services?
18:10:48	nsh:	* nsh tunes in
18:10:52	jgarzik:	it is a loose, free-wheeling discussion
18:11:09	jgarzik:	IMO the first True Bitcoin Hearing, with people asking tough questions
18:12:03	nsh:	good
18:16:54	andytoshi:	is BPP != P open?
18:19:26	nsh:	the entire hierarchy is up for grabs
18:20:11	nsh:	(specifically, everything collapses to P if the universe is really silly)
18:20:31	gmaxwell:	damnit, my battery went dead, and so I missed a bit most likely. :(
18:20:37	nsh:	:(
18:22:01	nsh:	i like this line of argument
18:22:13	nsh:	(not sure it'll be as well received by others listening though)
18:23:50	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/
18:23:59	nsh:	(regarding BPP=?=P)
18:26:05	andytoshi:	thx nsh. i'm putting together a talk of my own and trying to figure out how to briefly discuss complexity..
18:27:50	nsh:	oh, cool. for what purpose?
18:28:15	nsh:	(i'd like to hear that talk if you get a chance to record it. or see the notes at least)
18:28:53	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
18:29:15	andytoshi:	but i only have an hour and these people are pure math folks. so i'm having a tough time compressing material :P
18:30:25	andytoshi:	if i think it'll work out i'll try to record it
18:33:35	nsh:	* nsh nods
18:37:41	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
18:41:28	jtimon:	I guess he won't be asked about that, but I'm always eager to hear new "sentences to remember" from him
18:42:30	nsh:	* nsh smiles
18:42:52	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
18:42:52	jgarzik:	Some of the questions and some of the answers were silly or off
18:42:57	jgarzik:	but overall, pretty good
18:43:20	jtimon:	I can't see anything, did it finished already?
18:43:31	jgarzik:	yes. resumes at 2:30pm
18:43:52	nsh:	andytoshi, sounds good
18:44:41	jtimon:	jgarzik what time is it for you now?
18:47:32	gmaxwell:	https://people.xiph.org/~greg/bitcoin_ny_hearing_1.ts https://people.xiph.org/~greg/bitcoin_ny_hearing_2.ts
18:47:39	gmaxwell:	second file has about :30 left in the upload
18:48:14	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.
18:48:22	gmaxwell:	I missed a bit at the beginning for sure.
18:49:18	jgarzik:	1:49pm
18:49:22	jgarzik:	jtimon, ^
18:49:33	jtimon:	thank you both
19:01:44	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
19:02:26	nsh:	ah, great
19:03:14	nsh:	yeah, tao seems to be quite a mathematical legend
19:03:58	gmaxwell:	andytoshi: is it one where you give the labels or the edges?
19:03:59	andytoshi:	:P he is indeed.
19:04:08	andytoshi:	gmaxwell: you give the labels
19:04:52	gmaxwell:	if you only give the labels how do you know the graph is isomorphic to the query graph?
19:05:13	nsh:	i watched this talk by tao the other day -- very interesting:
19:05:18	nsh:	http://www.youtube.com/watch?v=PtsrAw1LR3E
19:05:34	andytoshi:	gmaxwell: there is no isomorphism involved, the graph and its edges are common knowledge
19:05:40	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.
19:05:53	gmaxwell:	(but not both, since that would give away the solution)
19:06:02	andytoshi:	yeah, i'm familiar with that one, that's why i was surprised to see this one
19:06:44	andytoshi:	i need to think about this, my first impression is that its OK because the verifier knows the graph under consideration
19:07:02	gmaxwell:	oh interesting.
19:07:04	andytoshi:	you don't use an isomorphic graph, you use an 'isomorphic' coloring
19:07:20	gmaxwell:	you randomly pick an edge and only reveal that the two colors are equal.
19:08:31	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"
19:10:26	gmaxwell:	well it's nice because you can just wave your hands and say "3-coloring is NP complete"
19:10:41	andytoshi:	yep :)
19:11:25	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).
19:12:13	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
19:12:47	gmaxwell:	andytoshi: Why can't you just paint everything blue?
19:12:49	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
19:13:24	andytoshi:	gmaxwell: are you talking about the graph problem?
19:13:29	cymanon-zzzz:	cymanon-zzzz is now known as cymanon
19:14:47	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.
19:15:11	andytoshi:	gmaxwell: you are coloring the vertices
19:16:30	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
19:16:52	gmaxwell:	oh derp, right, the test should be that they're not the same not that they are the same.
19:17:46	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
19:18:52	andytoshi:	wait, i'm an idiot, never mind
19:20:38	andytoshi:	somehow i was thinking the colors were the commitment and the hashes were what you were proving you had :P
19:22:40	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
19:24:51	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.
19:25:08	andytoshi:	you need to have some information about the nodes your are hopping between to avoid sybils
19:25:17	andytoshi:	decrypt*
19:27:12	justanotheruser:	andytoshi: yes, nodes would have to have some PoW or PoS to prevent sybil
19:55:09	nsh:	gmaxwell, did you and/or andytoshi classify/specify the graph problem you were working out from coinjoin transactions
19:55:18	nsh:	iirc to give an estimate of the number of participants
19:56:28	nsh:	there were some brief notes or something, i last remember
20:58:58	michagogo|cloud:	Hmm, what plays .ts files?
20:59:33	michagogo|cloud:	(also, Chrome is trying to render those two files as text, rather than downloading them...)
20:59:48	nsh:	vlc generally plays anything that can be decoded into audio/video
21:00:01	michagogo|cloud:	Ah, I think I have that installed
21:00:06	enodios:	enodios has left #bitcoin-wizards
21:00:09	michagogo|cloud:	Thanks
21:00:11	nsh:	np
21:03:06	gmaxwell:	michagogo|cloud: VLC, mplayer, ffmpeg
21:05:19	andytoshi:	nsh: not sure if somebody answered you about the coinjoin graph problem
21:05:43	nsh:	wb, not yet
21:05:59	nsh:	was interested because a problem in tahoe-lafs looked quite (superficially) similar
21:06:07	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
21:06:15	nsh:	(well, it was a maximal-matching over bipartite graph)
21:06:18	andytoshi:	which is bad, because we wanted to know "how much" of a coinjoin the transaction might be
21:06:28	nsh:	right
21:07:05	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
21:07:10	nsh:	so was the intuition that there is a measure of coinjoin-iness unfounded?
21:07:38	gmaxwell:	hm? there is a measure. It's just potentially hard to compute.
21:07:47	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
21:07:47	nsh:	ah, right
21:07:57	gmaxwell:	though I assume that it's trivial in pratically all cases.
21:08:20	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.
21:08:43	nsh:	hmm
21:08:58	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
21:09:13	andytoshi:	well, that's not quite true
21:10:23	andytoshi:	i guess in general it is because some participants could be paying several people at once.
21:11:15	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.
21:11:50	nsh:	is there a practical way to allow participants to negotiate paying for each other to decrease the derivable information?
21:12:03	helo:	~ripple?
21:12:30	nsh:	hmm
21:12:43	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
21:13:20	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)
21:14:34	nsh:	i wonder how much correspondence there'll be between this and the zerocash "pouring" dynamics
21:20:08	michagogo|cloud:	gmaxwell: How far in does ..._1.ts start?
21:20:26	gmaxwell:	I'm not sure, basically as long as it took me to figure out how to save the data!
21:20:36	gmaxwell:	someone who actually saw it might be able to tell you.
21:20:43	gmaxwell:	looks like it's over?
21:25:17	c0rw1n:	you have the capture gmaxwell?
21:26:19	gmaxwell:	https://people.xiph.org/~greg/bitcoin_ny_hearing_3.ts is the afternoon session, and this one is complete from start to end.
21:26:30	c0rw1n:	ok thx :)
21:27:17	michagogo|cloud:	gmaxwell: So you don't know how much is missing prior to the start of the first file?
21:29:53	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?
21:30:15	gmaxwell:	phantomcircuit: so you say there is archived footage someplace?
21:30:39	phantomcircuit:	gmaxwell, it's available at the same link as the live video
21:30:41	phantomcircuit:	http://www.totalwebcasting.com/view/?id=nysdfs
21:33:38	jtimon:	wget + vlc seems to work just fine, thanks again gmaxwell
21:34:28	andytoshi:	+1 jtimon, thanks gmaxwell!
21:35:18	jtimon:	justanotheruser andytoshi I think retroshare does what you want by establishing a F2F network
21:35:59	andytoshi:	what does f2f stand for?
21:36:07	c0rw1n:	frined-to-friend
21:36:37	jtimon:	yep, it's basically a pgp web of trust
21:37:03	jtimon:	with chat, messages and file sharing
21:37:18	gmaxwell:	foe to foe network.
21:37:40	c0rw1n:	foe to foe, that's botnets ddos'ing each other?
21:38:55	nsh:	("Old English gefa 'foe, enemy, adversary in a blood feud' (the prefix denotes 'mutuality'), from fah 'at feud, hostile,' from Proto-Germanic *fakhaz)
21:39:38	phantomcircuit:	retroshare seems like a reasonably good idea
21:39:48	phantomcircuit:	except i haven't seen anybody break anything on it yet
21:39:55	phantomcircuit:	which probably means nobody has looked very hard
21:40:03	maaku:	phantomcircuit: would be even better if they had a group of strong cryptographers looking at it
21:40:38	maaku:	they're mostly reusing PGP, so if they're even reasonably competent it's probably not horribly broken
21:40:51	jtimon:	I think the worse part is getting people using it so you're actually not a island in that f2f network...
21:41:29	maaku:	but that said, I'm not sure PGP is the right construct to use...
21:42:45	jtimon:	gpg ?
21:43:12	phantomcircuit:	maaku, doesn't provide for forward secrecy
21:43:25	phantomcircuit:	there's no reason for a f2f network not to have pfs
21:43:35	maaku:	jtimon: what phantomcircuit said
21:43:51	maaku:	deniability, perfect forward secrecy, etc.
21:44:12	maaku:	PGP is ideal for on-the-record, or point-to-point encrypted email
21:44:19	maaku:	not really designed for social networks...
21:44:36	maaku:	which is unfortunate - i wish there was an active #retroshare-wizards community
21:44:46	jtimon:	* jtimon si reading wikipedia's article on forward secrecy
21:45:38	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.
21:46:29	maaku:	gmaxwell: is it possible to do non-repudiation over store-and-forward, non-interactive medium?
21:46:38	gmaxwell:	yes. sure.
21:47:05	gmaxwell:	you mean non-non-repudiation and the answer is still sure.
21:47:21	maaku:	er, yeah
21:47:33	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.
21:47:53	gmaxwell:	forward secrecy is a bit harder, but can be done.
21:49:20	andytoshi:	gmaxwell: how is that ECDH auth nontransferable?
21:49:20	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.
21:49:50	gmaxwell:	andytoshi: because you can simulate it without my cooperation.
21:50:28	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?
21:50:41	andytoshi:	oh, thx, i gotcha
21:51:53	andytoshi:	i was just being daft. my brain is not working properly today it seems..
21:52:22	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.
21:52:29	gmaxwell:	(though your private data is large)
21:53:24	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…)
22:06:10	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
22:23:34	maaku:	in other words, you can only prove authorship is maaku OR andytoshi
22:24:28	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)
22:24:49	andytoshi:	nice! i'm passingly familiar with the concept but i've never seen a simple example
22:25:15	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.
22:25:21	maaku:	doesn't OTR also have some sort of construction such that after the fact some secret is revealed letting anyone construct fake transcripts?
22:26:06	WhaleHunter:	WhaleHunter is now known as WhaleHunter-Away
22:26:28	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.
22:27:01	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.
22:29:41	michagogo|cloud:	23:50:29 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?
22:29:49	michagogo|cloud:	gmaxwell: is that what you meant to say?
22:30:15	michagogo|cloud:	("give you my private key")
22:30:20	gmaxwell:	yes.
22:30:28	michagogo|cloud:	okay
22:31:28	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.
22:37:13	michagogo|cloud:	* michagogo|cloud assumes that in such a case you'd be using disposable privkeys?
22:37:51	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.
22:40:12	michagogo|cloud:	Oh
22:40:20	michagogo|cloud:	Ah, I see.
22:41:12	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?
22:42:04	gmaxwell:	right, the _authentication_ is non-transferable. It convinces me, but not anyone else even if I give them everything I know.
22:42:58	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
22:43:39	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)
22:43:50	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)
22:43:59	michagogo|cloud:	Or is that not the case?
22:44:11	gmaxwell:	with a auth via ECDH the message is the same as plaintext.
22:44:55	andytoshi:	i think this notion of "non-transitive information" is one of the weirder things to come out of modern cryptography
22:45:07	gmaxwell:	even with trusted hardware because you can't even verify anything at all without one of the private keys.
22:45:16	michagogo|cloud:	(As you may have noticed, I know ~nothing-very little about cryptography
22:45:19	michagogo|cloud:	)
22:51:01	gmaxwell:	andytoshi: well it's usually the color of the bits which is non-transitive rather than the information itself.
22:53:16	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
22:53:31	andytoshi:	and the existence of a coloring is a "solid" bit of information
22:53:51	gmaxwell:	different definition of 'color'.
22:54:06	gmaxwell:	required reading if you have not read: http://ansuz.sooke.bc.ca/entry/23
22:54:07	andytoshi:	hmm, yeah.
22:54:45	andytoshi:	i have indeed, a very useful article
23:00:42	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.
23:01:15	gmaxwell:	hm. you're right.
23:01:36	gmaxwell:	if we have a NIZK proof that the 3-coloring exists we clearly have information (1 bit, if your prior was uniform!)
23:02: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.
23:02:26	gmaxwell:	but if we are not the designated verifier, then we know nothing at all.
23:02:29	gmaxwell:	And thats weird.
23:04:29	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
23:05:24	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
23:06:32	gmaxwell:	warning wank field detected.
23:06:32	andytoshi:	that's a really vague thing to say, sorry, i'm just spitballing
23:06:33	gmaxwell:	;P
23:06:35	gmaxwell:	hehe
23:06:35	andytoshi:	:P
23:07:17	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.
23:07:17	jron:	gmaxwell: thank you for posting the hearing cap.
23:07:40	nsh:	and cloak of comprehension
23:19:40	helo:	gmaxwell: you're going to be one of the panelists tomorrow in NY, right?
23:20:28	helo:	otherwise there's no way we can make up for the litecoin "creator"
23:22:07	jtimon:	I read he said in miami that some people call him "satoshi lite"...still eager to watch his intervention...
23:23:32	andytoshi:	* andytoshi would never be so vain as to take satoshi's name..
23:24:43	sipa:	recently a colleague asked me whether i was satoshi
23:24:53	sipa:	perhaps i shouldn't have answered in japanese
23:25:06	brisque:	andytoshi: that your nick is an anagram of satoshi is not a coincidence?
23:25:17	sipa:	anagram?
23:25:30	c0rw1n:	magarna
23:25:47	gmaxwell:	Ohayou asadimaska
23:26:37	sipa:	hajimemashite, satoshidesu
23:26:44	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.
23:29:35	helo:	gmaxwell: yeah, there are three sessions tomorrow
23:30:10	maaku:	sipa: "If I was Satoshi with $1bn to my name, would I still be working here?"
23:30:45	helo:	the litecoin guy couldn't really even stay on topic... seemed like he just wanted to impress them with info overload
23:33:37	Luke-Jr:	sigh
23:34:48	sipa:	maaku: ha
23:35:32	midnightmagic:	maaku: I would. :)
23:35:44	maaku:	midnightmagic: wish I had your job :)
23:35:57	midnightmagic:	maaku: Oh, I don't mean my official job. I meant *in here*.
23:36:06	maaku:	oh heh, yeah
23:36:11	midnightmagic:	:-D
23:36:46	michagogo|cloud:	* michagogo|cloud wonders if there'll be recordings of the streams tomorrow as well
23:37:07	jtimon:	but sipa's colleague is from his official job, no?
23:37:20	sipa:	yes
23:38:33	Luke-Jr:	* Luke-Jr thinks it's obvious who Satoshi really is, but *shrug*
23:38:40	michagogo|cloud:	Luke-Jr: o_O
23:38:43	c0rw1n:	obvious, really
23:38:46	sipa:	really?
23:39:01	maaku:	Al Gore, obviously
23:39:05	tacotime_:	I always knew he was a time travelling Japanese cat from the 42nd century.
23:39:08	sipa:	oh, right
23:39:40	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..
23:39:58	Luke-Jr:	and left at the same time
23:40:03	gmaxwell:	please don't speculate about that kind of stuff.
23:40:48	c0rw1n:	gwern has an interesting, abandoned investigation on satoshi
23:40:48	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.
23:40:49	Luke-Jr:	at all? this channel is still private, right? O.o
23:41:08	maaku:	Luke-Jr: this channel is now logged
23:41:13	gmaxwell:	and If you are _not_ actually satoshi, then the cost of security against that threat is really intolerable.
23:41:13	Luke-Jr:	meh
23:41:29	Luke-Jr:	maaku: I don't see that in the topic
23:41:39	gmaxwell:	Besides, we all know Satoshi was a time travelling Japanese cat from the 42nd century
23:41:40	Luke-Jr:	so it shouldn't be
23:41:41	andytoshi:	the logs are non-nonrepudiable fwiw
23:41:47	Luke-Jr:	gmaxwell: s/cat/doge/
23:42:17	gmaxwell:	Luke-Jr: though fwiw, the bitcoin history started on sourceforge and was imported into git.
23:42:32	andytoshi:	to Luke-Jr's point, the logs really should be mentioned in the topic
23:42:42	andytoshi:	i'm happy to strike anything that people request but people should be aware of it
23:42:43	gmaxwell:	so put them there, most of you are ops here.
23:43:09	Luke-Jr:	* Luke-Jr kicks ChanServ
23:43:14	Luke-Jr:	:p
23:43:28	gmaxwell:	(I took the top N people by number of messages sent and made all of you ops, for N=10 or something)
23:43:29	c0rw1n:	if there are public logs i'd love to read them indeed, this being the most interesting #bitcoin-* i've found
23:44:07	andytoshi:	andytoshi has changed the topic to: "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi."
23:44:07	tacotime_:	http://download.wpsoftware.net/bitcoin/wizards/
23:44:21	c0rw1n:	ok thx :)
23:44:29	tacotime_:	I would prefer it continue to be logged, as I read these regularly when my VPS dies.
23:45:18	tacotime_:	It's a lot of the more interesting Bitcoin related discussion.
23:48: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
23:49:15	WhaleHunter-Away:	WhaleHunter-Away is now known as WhaleHunter
23:50:24	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
23:50:28	maaku:	(hint hint)
23:52:12	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)
23:52:42	justanotheruser:	I believe those criteria would make the ultimate anonymity layer
23:55:19	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
23:57:15	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)