06:07:29	shinybro__:	shinybro__ is now known as shinybro
07:01:49	phantomcircuit:	gmaxwell, tripping dem 220 amp breakers
07:01:51	phantomcircuit:	is hilarious
07:02:43	gmaxwell:	* gmaxwell loans phantomcircuit an amp meter
07:03:02	phantomcircuit:	gmaxwell, it's all 3 phase
07:03:09	phantomcircuit:	it's unpossible to get them to balance right
07:03:13	phantomcircuit:	shit is super annoying
07:03:36	phantomcircuit:	and of course all the plugs are ac so the meter has to be inline
07:05:39	phantomcircuit:	gmaxwell, i wish i could buy split ac cables in bulk
07:05:44	gmaxwell:	you're running the gear @208 right? rotating pairs should get them balanced so long as the number in the rack is a multiple of 3.
07:05:47	phantomcircuit:	but they cost like 4x as much as a normal cable
07:06:20	phantomcircuit:	gmaxwell, sure except the two psu's dont pull the same for all the boxes
07:06:26	gmaxwell:	ugh
07:06:42	phantomcircuit:	im probably going to end up having to measure each individual box and match them up
07:06:46	phantomcircuit:	it's gonna be terrrible
07:07:16	gmaxwell:	phantomcircuit: on my avalons and ants I was balancing the power on my two legs (I have some problem with my neutral here— it has high resistance or something)— by twiddling the clockrates.
07:07:54	phantomcircuit:	gmaxwell, yeah except on the cointerra stuff the frequency scaling stuff is for both boards
07:08:08	phantomcircuit:	(they can actually be controlled individually but not easily yet)
07:08:20	gmaxwell:	(If I put too much load on one leg the voltage on it sags, and the voltage on the other side goes up ... 130v uhhh no thanks)
07:08:37	phantomcircuit:	hehehe
07:09:12	phantomcircuit:	at least for right now im just going to try and spread them out
07:09:22	phantomcircuit:	at least we have the space ...
07:09:38	gmaxwell:	one miner per rack.. :P
07:10:01	phantomcircuit:	you jest but i actually do have 3 racks with 1 miner
07:10:11	phantomcircuit:	was just to measure them but... well i left them there
12:08:26	fanquake:	fanquake has left #bitcoin-wizards
13:18:46	grazs:	grazs is now known as grzs
13:45:45	jgarzik:	jgarzik is now known as home_jg
13:54:50	mike4:	mike4 is now known as c--O-O
14:06:35	gavinandresen:	Hey wizards: Question: if we change bitcoind's change creation algorithm so that, if there is enough change, it produces two change outputs: one matching the payment amount, and one with the rest… would that help, hurt, or have no effect on privacy, assuming "typical" payment patterns, later payment of transaction fees, etc. If it hurts, is there a simple variation that would help?
14:06:56	gavinandresen:	The goal for creating more change outputs is to make it more likely there are confirmed inputs to use in subsequent transactions.
14:07:18	sipa:	to make sure sufficient outputs exist, i would suggest splitting the change in two (approximately) rather than matching the input
14:07:57	sipa:	though matching the actual output is interesting for privacy
14:12:18	gavinandresen:	Oh, and a meta-question: are any of you plugged into the academic work being done on bitcoin transaction privacy? Would any academics be interested in helping with this kind of "small ball" incremental improvements, as opposed to coming up with Theoretically Perfect solutions?
14:28:11	CodeShark:	hey, sipa, what's the status of secp256k1?
14:28:28	CodeShark:	any hope of merging it into bitcoind? or perhaps getting those optimizations implemented in popular crypto libs?
14:29:26	sipa:	CodeShark: yes, it may be merged after 0.9
14:29:32	sipa:	as an experimental mode
14:30:18	CodeShark:	so a compile-time switch? or a runtime-switch?
14:30:28	sipa:	compile time
14:33:06	CodeShark:	apparently someone tried using boost::multiprecision as a backend for it
14:33:14	CodeShark:	are you aware of it?
14:33:17	sipa:	no
14:33:24	keus:	blockchain is down :S
14:33:52	sipa:	good, learn to deal with not being able to rely on a centralized service
14:34:12	keus:	just wondering why it's down
14:34:37	CodeShark:	try asking them - not sure anyone here will have the answer :)
14:38:25	keus:	just thought you would be interested in the situation
14:40:24	CodeShark:	depends on whether the situation is caused by routine web server maintenance or by a coordinated attack
14:40:55	CodeShark:	the former is more likely :)
14:41:49	CodeShark:	there's a very good chance it's the type of problem that goes away as soon as the web server gets restarted :)
15:24:38	roidster:	roidster is now known as Guest45917
16:26:45	oleganza:	hey guys. I have a proposal for blind ECDSA signatures compatible with Bitcoin txs http://oleganza.com/blind-ecdsa-draft-v1.pdf
16:27:01	oleganza:	the idea is to lock your valuable stash with 5-of-9 multisig tx with your friends.
16:27:30	oleganza:	and when need to sign it, use blind signatures, so your friends do not find out which transaction they signed and how much money you have
16:28:28	oleganza:	unlike SSSS or DH-like tricks, there's never a point in time when all precious secrets are stored on a single machine (because it may be compromised).
16:29:02	oleganza:	i opened a discussion on bitcointalk too: https://bitcointalk.org/index.php?topic=440572.0
16:41:26	andytoshi:	oleganza: exciting, i will review this
16:41:54	oleganza:	andytoshi: thanks
16:52:21	oleganza:	andytoshi: i'm not often online in IRC. Feel free to comment via email oleganza@gmail.com or twitter @oleganza
16:53:33	andytoshi:	oleganza: cool, i'll send you an email
17:26:23	OneFixt_:	OneFixt_ is now known as OneFixt
17:34:12	fract4l:	anyone here familiar with openCL and PoW's? I'd like to pay a $1500 bounty for a some work
17:34:24	fract4l:	msg me
19:37:51	roconnor_:	what are people's thought on how large/complex scripts ought to be paid for in principle with flexable scripting mechanism?
19:46:24	helo:	everyone pays for them :/
19:52:15	sipa:	imho, the only way that aligns miner's incentives with relaying, is by enforcing a consensus-rule limit on the expensive part
19:52:52	sipa:	so if CPU time is to be limited, define some unit for measuring it, and put a limit on per-block computations
19:53:09	sipa:	so miners have an incentive to optimize for fee per operation
19:53:21	maaku:	roconnor_: miners dont incur the costs of expensive scripting
19:58:54	roconnor_:	I feel a little uncomfortable with an arbitrary per-block limit
20:01:40	roconnor_:	Though I suppose if scripts are made only an ephemeral part of the block chain (by not letting them influence hashes) most nodes can eventually discard them, and only archive nodes need to keep them around.
20:04:18	gmaxwell:	roconnor_: though its useful to think carefully about the security and incentive model change that implies... it suggests you won't validate past a certian depth, so a moderate sized reorg can be rewarded with stolen funds.
20:05:55	roconnor_:	sipa: I'm thinking of designing a scripting system based on the linear (or rather affine) lamba calculus without exponentials with the script hash being a merkle hashing of the abstract syntax. I believe the affine lambda calculus brings code side and execution time together.
20:06:16	roconnor_:	gmaxwell: why does it suggest I won't validate past a certain depth (any more than bitcoin suggests).
20:07:13	roconnor_:	*code size and execution time
20:07:18	gmaxwell:	roconnor_: because if you don't never have the data you can't verify it. Unless I misunderstood you. Not having it influence the hashes sounded like you intended to never fetch it.
20:08:22	gmaxwell:	In bitcoin we support that as a reduced security model— SPV— but just for end clients (and you don't need to prevent it from influencing hashes to get that). having the whole system have SPV security past some depth may well be a worthwhile tradeoff, but its not one to take likely.
20:08:27	gmaxwell:	er lightly.
20:08:31	roconnor_:	gmaxwell: my thinking is that a transaction is not valid without *some* signature but that signature doesn't influce the the hash of the transaction, block, or blockchain in any way.
20:09:32	roconnor_:	(my type theory hat says the type of signatures is squashed)
20:10:47	roconnor_:	as in all valid signatures are considered equivalent and can be substituted for each other in any context.
20:11:08	roconnor_:	which in turn implies that hashing cannot depend on the exact nature of the signature.
20:16:37	sipa:	roconnor_: you may or may not know, people have been discussing merjleized abstract syntax here for a while (which were your idea, iirc) :)
20:18:16	sipa:	*merkleized
20:18:46	nsh:	has anyone made notes on merkel AST ideas that you know of?
20:19:07	andytoshi:	i read through the paper oleganza posted here earlier, it looks legit
20:19:21	nsh:	blind-ecdsa-draft?
20:19:22	andytoshi:	(re blind ecdsa sigs, completely unrelated to this convo, sorry)
20:19:52	oleganza:	andytoshi: thanks. I'm reading through your email
20:20:02	gmaxwell:	oh
20:20:09	gmaxwell:	oleganza: did you solve the distingushable nonce problem?
20:20:14	oleganza:	yep
20:20:18	gmaxwell:	\O/
20:20:34	oleganza:	gmaxwell: i've also posted link here: https://bitcointalk.org/index.php?topic=440572.0
20:20:39	oleganza:	http://oleganza.com/blind-ecdsa-draft-v1.pdf
20:20:55	nsh:	could someone summarize the distinguishable nonce problem?
20:20:59	oleganza:	the solution is pretty bruteforce: just linearly transform everything and then deduce none and public key from there
20:20:59	nsh:	* nsh starts reading the paper
20:21:18	andytoshi:	gmaxwell: the blind signer doesn't use ecdsa proper, it's pretty slick
20:21:29	oleganza:	nsh: "distinguishable nonce" comes from my first incorrect idea: https://bitcointalk.org/index.php?topic=440572.0
20:21:44	andytoshi:	but the result (after the message owner does a bit of manipulation) is a valid ecdsa signature
20:21:59	oleganza:	s/none/nonce/
20:22:44	nsh:	does this demonstrate ecdsa malleability?
20:22:53	oleganza:	nsh: it proves that ECDSA is broken
20:22:56	sipa:	nsh: please don't confuse one of the founders of public-key cryptography with the prime minister of germany
20:23:01	maaku:	nsh: i'm working with some of the guys on #concatenative to put together a merkelized forth/joyscript proposal
20:23:10	maaku:	heh
20:23:27	nsh:	maaku, cool. thanks
20:23:58	maaku:	i don't know, I think Ralph Merkle could do a better job as chancellor
20:24:01	nsh:	sipa, oops :)
20:24:42	sipa:	maaku: who knows!
20:25:00	sipa:	unsure about making Angela Merkel design cryptographic constructs, though...
20:26:08	nsh:	i think she has a quantum physics/chemistry background, so her math might not be that bad, relatively speaking...
20:26:13	maaku:	nsh: it has kinda been low priority though, but I have gotten a lot of people interested in it at least
20:26:22	nsh:	* nsh nods
20:26:23	gmaxwell:	oleganza: oh. hm! this achieves a somewhat different notion of blinding than typical, I think. I don't think I could convince the public that bob was a blindsigner on this without revealing data that would allow bob to know exactly which instance of his signing that we're talking about.
20:26:52	sipa:	oleganza: sorry, i won
20:26:59	sipa:	oleganza: sorry, i won't have time to read it today
20:27:02	maaku:	really? heh that's what Merkle does these days (quantum chemistry simulations)
20:27:32	sipa:	it's a conspiracy!
20:27:36	andytoshi:	gmaxwell: that's a good point. what's neat here is that with bitcoin you don't need to convince the public that bob is the signer, you just have to trust bob (because in oleganza's usecase you hope he'll be an escrow agent for you)
20:27:40	nsh:	( "Investigation of the mechanism of decay reactions with single bond breaking and calculation of their velocity constants on the basis of quantum chemical and statistical methods" - http://en.wikipedia.org/wiki/Angela_Merkel#cite_note-22 )
20:27:44	sipa:	angela merkel and ralph merkle are like Jekyll and Hide
20:28:09	gmaxwell:	andytoshi: well I have usecases too, my friend!
20:28:21	gmaxwell:	I want blind signing in bitcoin for anti-doublespend oracles for instant payments.
20:28:25	gmaxwell:	:P
20:28:27	oleganza:	gmaxwell: yep, it's more specific to my use case.
20:28:33	andytoshi:	:P ok that's a better one
20:28:34	oleganza:	gmaxwell: tell us more about your use cases
20:28:43	andytoshi:	oleganza: maybe we can figure out how to get public verifiability
20:29:01	gmaxwell:	well, good to have things in any case even if you don't get full blind signing.
20:29:38	oleganza:	andytoshi: do you have a concrete example of when it might be useful?
20:30:04	andytoshi:	oleganza: sure, in the chaum bank example you cited you want the public to be able to verify that your token is signed by the bank
20:30:42	andytoshi:	without having to ask the bank to reveal any secret key material
20:33:22	andytoshi:	it's also not clear to me what the danger of revealing or reusing some parameters, though i'll do some analysis on that. this is part of why i mentioned in the email that you should simplify the protocol discription, i think you could get it to a point where you can just "see" what the security requirements for each parameter are
22:18:02	oleganza:	andytoshi: thanks for your comments, will improve and send you draft 2 soon.
22:18:57	oleganza:	andytoshi: yes, some parameters I think could be reused. As I said, my approach wasn't very elegant, so I probably have too many parameters floating around.
22:25:22	gmaxwell:	http://www.coindesk.com/mt-gox-may-headed-bankruptcy/ < wow someone pointed out that solvency can be proven in an article addressed to a general audience!
22:27:07	oleganza:	gmaxwell: i get when bitcoiners get sarcastic about perceived weakness in the protocol (because they can prove that it's not broken), but when it's about opaque third party with shitty PR and a big history of problems, then I don't get sarcasm
22:27:21	oleganza:	disclosure: was never user of mtgox and don't really care what's going on there.
22:27:33	gmaxwell:	I'm not being sarcastic.
22:27:42	gmaxwell:	I think its great that it was pointed out there.
22:27:55	oleganza:	ah, ok
22:28:06	gmaxwell:	I think we _should_ be demanding cryptographic proof from these providers.
22:28:11	oleganza:	gmaxwell: i just remembered that your were buying goxcoins
22:28:16	gmaxwell:	They won't provide it unless the public demands it.
22:28:28	oleganza:	so i wonder how you know that they are alright
22:28:30	gmaxwell:	oleganza: yea, well I totally regret that now. I feel like I was mislead by magicaltux.
22:29:20	oleganza:	i thought it was less than a week ago you were buying goxbtc? what did change?
22:30:16	gmaxwell:	over a week ago— their press release. As I wrote about publically I understood their original issues (having brought some of them to their attention!)
22:31:03	oleganza:	gmaxwell: I myself was shocked when I discovered that some long-time bitcoiners who studied it pretty deep, were keeping all of their BTC on Gox.
22:31:12	gmaxwell:	I believed their losses were small, since /obviously/ it wouldn't have been people like phantomcircuit and myself telling them they had problems if they were really hemorrhaging coin. Right ??? ...
22:31:31	gmaxwell:	oleganza: well I never keep my coin in third party hands beyond what is strictly needed.
22:31:51	oleganza:	gmaxwell: i think so. I meant other guys
22:32:26	oleganza:	a friend of mine has a little bit of BTC and stores on bitcoin-central. But he is not willing to study it deep and thinks it's a toy. So i don't blame him.
22:32:35	phantomcircuit:	gmaxwell, i would be very *very* surprised if they were insolvent
22:32:47	oleganza:	What I don't understand is how other guys, who study BTC quite deep, still hold coins in one exchange
22:32:48	gmaxwell:	well obviously they aren't broke.
22:32:50	phantomcircuit:	(not the least of which is the technical definition of solvency requires written demands...)
22:33:26	gmaxwell:	I went and bought some goxcoin undercutting the market in part because I was a bit pissed that other people buying it were going around spreading FUD out of one side of their mouth and then buying up the coins with the other. oh well. The press release caught me completely off guard, I didn't anticipate it so, obviously my initial assesments were all off.
22:33:56	gmaxwell:	fortunately I don't have most of my coins there now or anything insane like that, but I do have wwwayyyyy more than I'm comfortable with having there.
22:34:46	oleganza:	gmaxwell: funny. To me Gox was always so incredibly complicated to get into, I waited till December 2012 to do wire transfers directly to Bitcoin-Central. Was fast, easy and simple.
22:34:58	oleganza:	so never touched gox in my life
22:35:06	sipa:	oleganza: i have a significant amount on mtgox... why? it was once a tiny amount (~2 years ago), and i had never bothered to get verified (at the time that wasn't necessary)
22:35:13	phantomcircuit:	oleganza, december 2012 is a long time ago
22:35:14	gmaxwell:	sipa: doh!
22:35:21	gmaxwell:	(didn't realize you hadn't gotten verified)
22:36:22	gmaxwell:	oleganza: I've periodicaly sold coin for USD there, simply because the prices were quite high— enough that the quiet 5% manual processing fee to actually get USD out still left me ahead.
22:36:59	gmaxwell:	e.g. I sold some coin there for over $1000/btc a few weeks ago.
22:40:11	oleganza:	phantomcircuit: I learned about BTC (second time) in August 2012 and purchased some coins through a friend with paypal leftovers in October 2012 (because mtgox was impossibly complicated to get into)
22:40:34	oleganza:	then I learned about super-kosher Bitcoin-Central (about that time there were news about it having all licenses and stuff)
22:40:51	phantomcircuit:	lol
22:40:54	oleganza:	since I'm in Paris with french bank account, it was very easy just to make a wire transfer
22:41:21	phantomcircuit:	they were an agent of a a payment services directive authorized company, which is in turn an agent of a bank, which in turn operates under a charter from the french central bank
22:41:42	sipa:	heh, when i last actually used mtgox, the exchange rate was like $6, and fees + withdraw fee + conversion to euro altogether was at most a few % loss
22:41:47	phantomcircuit:	oleganza, that is quite literally the lowest form of authorization to operate that it's even possible to obtain
22:42:00	phantomcircuit:	(an agent of a psd cannot allow another party to act as their agent)
22:43:20	oleganza:	phantomcircuit: well, I was only studying btc that time and didn't really care about these details - i was never going to have long-term relationship with their vaults
22:44:50	phantomcircuit:	blargh
22:44:56	phantomcircuit:	ovh has yet another new control panel
22:45:04	phantomcircuit:	and about 50% of it isn't translated
22:56:00	oleganza:	gmaxwell: where can i read more about "anti-doublespend oracles for instant payments"
22:58:00	gmaxwell:	oleganza: I dunno, I've pointed out in a couple places. The idea is similar to your multisignature. Except the 'friend' is trusted by the world to never sign with a key more than twice. The first signature you use to get them to sign a timelocked refund. When you go to buy something from someone you pay them using the other signature, and show them the refund— they're happy that the refund doesn't unlock for a couple weeks, and ...
22:58:06	gmaxwell:	... thus its impossible for you to double spend them. If the oracle cheats, the extra signatures can be made public, etc.
22:58:31	gmaxwell:	Now, it's best if the oracle is maximally blinded otherwise— so that it can't selectively deny service or be easily ordered not to serve some people.. and can't track people's transactions.
22:59:12	oleganza:	gmaxwell: good point
22:59:33	oleganza:	gmaxwell: i had such idea for a "template server" to fix the problem with storing unencrypted keys on the server
22:59:43	oleganza:	for micro-transactions used to pay for API usage to other servers
23:00:33	oleganza:	the problem is: if you want to put some cash on your web 2.0 app server, so it pays Amazon or Yahoo, that cash can be stolen by someone sneaking in the datacenter
23:02:35	oleganza:	so you can lock your cash in 2-of-3 multisig tx. One key will unencrypted on your webserver, another one - on 3rd party "template signer" server and 3rd key - emergency key for yourself (in case 3rd party disappears)
23:03:16	oleganza:	normally, your webserver will sign txs with its key and using "template server" which will be allowed to automatically sign txs matching predefined rules ("templates")
23:03:40	oleganza:	so you can say "only authorize txs to these addresses and not more than X BTC per 24h"
23:03:52	oleganza:	then, the cryptographic part is cool
23:03:58	oleganza:	you take the file with those rules
23:03:59	oleganza:	hash it
23:04:28	gmaxwell:	right and the rules give you the key.
23:04:37	oleganza:	multiply hash(rules) by a single well-known pubkey of the template server
23:04:37	oleganza:	and use it as your pubkey for these rules
23:04:40	gmaxwell:	H(rules) + oracle_key = real key.
23:04:51	oleganza:	so you can prove if the server signed some tx incorrectly
23:05:08	oleganza:	and their single pubkey will become invalid in the eyes of everyone
23:05:10	gmaxwell:	yea, I think every oracle idea I've talked about has done that kind of pay to contract approach. I'm fond of it too— no ambiguity. Though also no denyability which is a little unfortunate.
23:05:14	gmaxwell:	(at times)
23:05:35	oleganza:	but here, by design, signatures should not be blind - because server matches tx with the rules
23:06:02	oleganza:	i doubt you can have rule-matching and deniability at the same time :)
23:06:21	gmaxwell:	although, even there it would be _nice_ if only the rules were proven, not the txn content. Implementing that requires fancier things, however.
23:06:26	gmaxwell:	You absolutely can.
23:06:35	gmaxwell:	it's just Fancy(tm).
23:06:43	oleganza:	like homomorphic encryption?
23:06:51	gmaxwell:	not that fancy. :)
23:06:58	oleganza:	then i'm curious
23:07:01	oleganza:	how fancy?
23:07:15	gmaxwell:	You have the signee do a (potentially) interactive zero-knoweldge proof with the signer that convinces them the thing you want blindly signed meets the rules.
23:07:46	oleganza:	ah, i heard about that
23:07:54	oleganza:	idea: if you want blind signatures for oracle only to disallow selected censorship, then it's easy to fix
23:08:27	oleganza:	ask oracle to "accept" a tx hash first, so you can prove to anyone that they were "ready to sign it", then ask to sign the tx itself with all its content open.
23:08:48	gmaxwell:	systems that can do this with basically pratical performance have been implemented now, see the pinocchio paper. It's not as crazy as fully homomorphic encryption, but its still rocket sciency.
23:09:06	gmaxwell:	oleganza: yes, thoug thats only after the fact which is a little annyoing, and they can still track.
23:09:07	oleganza:	so if they decline signing tx based on its content, you can show that they are censoring
23:09:20	oleganza:	gotta go
23:09:24	gmaxwell:	TTYL.
23:09:29	oleganza:	was great chatting with you guys
23:12:17	gmaxwell:	interestingly, if you have scalable threshold signatures, ZKP for script acceptance, and blind signing you can damn near completely outsource script... which is kinda interesting.
23:21:02	oleganza:	gmaxwell: so you can have ethereum on bitcoin right away
23:21:53	gmaxwell:	oh sure, well oracles can give you that _now_ (after all ethereum isn't ZK) ... this is one of the reasons that I'm skeptical about claims of ethereum's value. people are hardly using whats already internal, and you can already do turing complete external scripts with oracle multisignature.
23:22:07	gmaxwell:	e.g. 3 of 5 oracles to control a spend, or what have you.
23:22:40	gmaxwell:	It would be _better_ with scalable threshold crypto though, so then you could have 51 of 100 oracles or what have you. ... but it's certantly possible now.
23:27:04	jarpiain:	jarpiain is now known as Guest17836
23:45:21	c0rw1n:	c0rw1n is now known as c0rw|zZz
23:56:39	lnovy:	lnovy is now known as `
23:56:48	`:	` is now known as lnovy