00:00:11	lechuga_:	(or thought about doing so)
00:05:16	bsm117532:	bsm117532 has left #bitcoin-wizards
00:22:42	Muis:	I always played with the thought of 'human proof of work', where mining can only be done by humans
00:23:20	kanzure:	humans are not magic. they are just machines.
00:23:35	Muis:	Now suppose you have a chain where each miner can have only hash
00:24:10	Muis:	That is: the hash of the last block combined with your openid signature from google or facebook
00:24:54	Muis:	And anyone can verify the openid 2.0 signatures without contacting google servers, so its foolproof
00:26:26	Muis:	Wouldnt that be the fairest chain ever (assumed no one can create thousands of fake google or facebook accounts)
00:26:42	zooko:	zooko has left #bitcoin-wizards
00:26:48	Muis:	And the technology is just as decentral as Bitcoin is?
00:26:57	kanzure:	um, except that in practice i do have thousands of gmail accounts
00:27:03	kanzure:	because their account system *is* broken
00:27:22	Muis:	Then pick Facebook
00:27:29	kanzure:	haha
00:27:39	Muis:	There must be an openid provider who is not broken?
00:28:05	moa:	Eliel: mining the tailings so to speak
00:29:14	Eliel:	Muis: that'd just be a centralized system in control of the openid providers.
00:29:42	Muis:	Its not centralized from a technical point of view
00:30:15	kanzure:	perhaps you should tell us what you think centralized means
00:30:46	Muis:	Centralized means some nodes have more jobs than others
00:30:59	Muis:	In this case Google isnt even a node
00:31:01	kanzure:	can you elaborate please?
00:31:20	Muis:	Or do you call Bitcoin centralized because Gavin holds the alertskey?
00:31:43	kanzure:	yes, alertskey is broken
00:31:47	kanzure:	what of it?
00:32:05	Muis:	Anyway
00:32:20	Eliel:	Muis: fine, it's not centralized in it's operation. However, it _is_ centralized in control aspect and that's the part that's most critical to decentralize.
00:32:45	Muis:	Depends on how you look at it
00:33:12	Muis:	With Bitcoin, every block is mined by 1 out of 10 pools
00:33:46	Muis:	With this coin, every block is mined by a completely random citizen on earth, and never the same one twice
00:35:21	jcorgan:	Muis: "Wouldnt that be the fairest chain ever" wat?
00:37:15	Muis:	*Fairest distribution
00:37:36	phantomcircuit:	Eliel, people dont like probabilistic payments heh
00:38:12	jcorgan:	Muis: what does "fairness" have to do with anything?
00:38:48	phantomcircuit:	Muis, if you can solve the identity problem sufficiently that you can actually build an automated system around it
00:38:51	phantomcircuit:	then by all means
00:39:05	phantomcircuit:	but that problem is far more difficult than most people think
00:39:11	phantomcircuit:	read: nearly impossible
00:40:49	kanzure:	phantomcircuit: there's probably an impossibility proof somewhere?
00:41:03	kanzure:	i haven't looked for one yet
00:41:13	kanzure:	i wouldn't be surprised
00:42:13	gmaxwell:	Muis went after me in PM on the above, my responses here: http://0bin.net/paste/agpHHItRpSrS1Yk9#4FsCG+t1TLSxcGNMEHJLCYqP-omGvyC4mPFeC1Y8wql
00:56:35	Eliel:	phantomcircuit: Many use cases for micropayments would have them coming in in high enough volume that the volatility due to the random element would be negligible.
00:57:26	brisque:	kanzure: I don't think I would call the alert key broken really. if someone was to go rogue and make an alert that points to malware or something of that nature, all it takes is another alert key owner pushing a maximum sequence alert to permanently ruin the system. and display an "alert key compromised" message. of all the designs, this one is pretty safe.
00:57:37	Eliel:	of course, actually doing that might get participating miners with licensing requirements though.
00:57:40	phantomcircuit:	Eliel, try integrating that into an accounting system
00:57:55	phantomcircuit:	"yes well once every ten million years we will lose our shirts"
00:58:08	phantomcircuit:	"oh and the books will never quite 100% balance"
00:58:44	gmaxwell:	phantomcircuit: then more business to competition who figures out how to deal with that?
00:58:57	Eliel:	phantomcircuit: I think bookkeeping wise you could just pretend the service was free for the cases where you don't actually receive anything.
00:59:01	gmaxwell:	presumably these can be addressed by parties basically buying your probablistic payment liability.
00:59:17	Eliel:	and only count the cases where you actually get something
00:59:48	Eliel:	that fixes the "problem" of books not balancing
01:00:38	phantomcircuit:	gmaxwell, possibly this could be made to work with an insurance scheme integrated into some sort of payments processor
01:01:09	phantomcircuit:	but getting all the edge cases with "normal" systems ironed out seems like a non trivial task
04:19:16	kanzure:	.title https://rjlipton.wordpress.com/2015/03/08/lint-for-math/
04:19:17	yoleaux:	Lint For Math | Gödel's Lost Letter and P=NP
05:12:21	dc17523be3:	[OT] gmaxwell, that subnormality was a super insightful share :)
08:05:19	rajaniemi.freenode.net:	topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
08:05:19	rajaniemi.freenode.net:	Users on #bitcoin-wizards: andy-logbot dc17523be3 wallet42 arubi Dr-G2 justanotheruser moa p15 kobud coiner Cory otoburb grandmaster spinza HaltingState adam3us1 rusty prodatalab__ binaryatrocity copumpkin embicoin d1ggy_ Emcy_ vmatekole SubCreative bosma Burrito RoboTeddy wumpus waxwing GAit jaekwon Starduster_ jcorgan sneak kinlo huseby GreenIsMyPepper phantomcircuit jgarzik cryptowest BlueMatt Pan0ram1x luny mkarrer melvster jaromil espes__ x98gvyn fanquake tromp_
08:05:19	rajaniemi.freenode.net:	Users on #bitcoin-wizards: dgenr8 Apocalyptic PaulCapestany gwillen dasource alferz bbrittain fenn nuke1989 gribble hashtag_ amincd HM2 prepost shesek tromp ahmed_ eordano Logicwax nickler Alanius face PRab BananaLotus guruvan ryan-c MoALTz lnovy DoctorBTC adlai sipa harrow Luke-Jr OneFixt amiller ebfull cluckj brisque cfields sdaftuar veorq coryfields devrandom helo Hunger- xabbix burcin runeks null_radix bedeho gmaxwell SwedFTP LarsLarsen epscy nanotube andytoshi
08:05:19	rajaniemi.freenode.net:	Users on #bitcoin-wizards: bliljerk101 wizkid057 starsoccer comboy nsh Taek iddo EasyAt maaku btcdrak NikolaiToryzin s1w Visheate livegnik optimator fluffypony Meeh cursive yoleaux dansmith_btc [d__d] berndj morcos Fistful_of_Coins dardasaba isis airbreather smooth ajweiss Xzibit17 yrashk artifexd Zouppen kumavis mariorz catcow Krellan michagogo Muis platinuum Oizopower catlasshrugged Keefe JonTitor petertodd kanzure eric mappum jbenet wiz midnightmagic heath gnusha
08:05:19	rajaniemi.freenode.net:	Users on #bitcoin-wizards: warren Adrian_G Iriez lechuga_ dignork jessepollak Graet Eliel veox warptangent indolering K1773R TD-Linux leakypat CryptOprah Anduck a5m0 d9b4bef9 mr_burdell NeatBasis davout brand0 @ChanServ throughnothing btc___ BrainOverfl0w roasbeef phedny so hguux__ MRL-Relay azariah
10:14:28	embicoin_:	embicoin_ is now known as embicoin
10:29:06	FA1qNNKDQF:	FA1qNNKDQF has left #bitcoin-wizards
10:47:03	embicoin_:	embicoin_ is now known as embicoin
10:59:52	oakpacific:	oakpacific has left #bitcoin-wizards
13:24:30	Kawhi_desu:	Kawhi_desu has left #bitcoin-wizards
14:07:10	kanzure:	amiller: petertodd seems to think he heard MPC too,
14:07:16	kanzure:	.tw https://twitter.com/petertoddbtc/status/574633652535033856
14:07:16	yoleaux:	Zerocash will soon have a MPC protocol to make the trusted setup a distributed calc where just one participant needs to be honest. #MITBTC15 (@petertoddbtc)
14:07:53	amiller:	kanzure, you're confused :o petertodd is right but there's no conflcit
14:08:10	amiller:	madars said both PCP and MPC, at different times, in different contexts!
14:09:19	amiller:	Zerocash *will* soon have an MPC setup protocol where one participant needs to be honest..... another theoretically possible approach is to use PCP, but thats infeasible for now its a research horizon topic
14:11:17	kanzure:	"madars said both PCP and MPC, at different times, in different contexts!" oh man, hard mode... geeze. alright.
14:26:43	prodatalab__:	prodatalab__ is now known as prodatalab
15:06:00	instagibbs:	is the implication that all n-on-n would have to collude to break the MPC solution?
15:07:09	instagibbs:	slash compromised, whatever
15:18:41	MRL-Relay:	[tacotime] that's what they said, yeah. if only one party destroys all their contribution, it's supposedly secure.
15:19:24	MRL-Relay:	[tacotime] of course you still have the other ZRC problems with obscurity (if there's a bug in the system being exploited to create/steal coins, no one else is able to see that).
15:23:35	fluffypony:	yeah that's the problem with bleeding-edge cryptography, some 15 year old kid comes along and finds an implementation exploit...except with this nobody would (ostensibly) ever know
15:24:01	instagibbs:	fluffypony: if they're smart they won't inflate the money too bad :P
15:24:31	fluffypony:	so just a slow, comfortable retirement on their yacht instead :-P
15:24:53	instagibbs:	Assuming a large enough economy, yeah, no one would be able to tell.
15:25:19	fluffypony:	still, I think it's fascinating research
15:25:29	instagibbs:	I think it's a decent tradeoff tbh
15:25:49	fluffypony:	what, the exploit risk?
15:25:55	sipa:	fascinating != useful != production ready
15:26:08	fluffypony:	sipa: agreed
15:26:15	instagibbs:	no one said otherwise
15:28:14	instagibbs:	the other big issue, from what I understand, when you want to soft/hard fork you have to regenerate the secret again. So fixing anything would require a centralized genesis-block-like event.
15:28:32	fluffypony:	ouch
15:30:01	instagibbs:	Which again, people may put up with for sidechain/embedded consensus side-system, but makes it quite unlikely as a Bitcoin-proper solution ever.
16:54:16	fluffypony:	https://darkcointalk.org/threads/rebranding-and-scalability.4254/
16:54:45	fluffypony:	"Eventually Gavin Andresen sees blocks getting to 100MB+, with tens of thousands of transactions per block. After giving it some thought, I came up with a scalable architecture that supports billions of transactions per day."
16:54:47	fluffypony:	"This strategy is just too good to let sit for very long and I need to do some exploratory coding to prove it works."
16:55:43	fluffypony:	that's it guys, it's over, we can all go home
16:58:32	instagibbs:	not even worth making fun of
17:00:05	skittylx:	fluffypony: after some thought I came up with an invention that turns farts into gold dust. Can't promise it will work though.
17:00:21	petertodd:	instagibbs: "soft/hard fork" <- only types of forks that change the ZK proofs; *lots* of stuff doesn't change them and lets you reuse the trusted setup, so much so you can take that single trusted setup and re-use it for multiple different purposes
17:00:43	fluffypony:	skittylx: do some exploratory dusting and let us know how it goes
17:00:48	instagibbs:	peter
17:01:00	justanotheruser:	this darkcoin guy is a genius
17:01:07	instagibbs:	petertodd: thanks for the correction.
17:01:16	petertodd:	fluffypony: it would be awesome if they implement that so we can make it explode
17:01:30	fluffypony:	justanotheruser: it's time for his last pump before he cashes out
17:01:33	instagibbs:	I don't know the snarks enough to know what rulechanges would change the snark structure
17:02:00	fluffypony:	petertodd: seconded
17:02:10	petertodd:	instagibbs: I surprised matt green last year when I pointed out that a much better strategy politically speaking would have been do make zerocash be initially a ZK credentials or something project that Just Happened(TM) to be reusable for currency
17:02:28	justanotheruser:	in the entire history of civilization, we have only had distributed consensus for 6 years. In those 6 years he has obsoleted bitcoins consensus system with his system that has instant confirmations. He even has video proof of his client saying 6 confirmations after less than 2 seconds. Now he can make it scale infinitely? Geeze
17:02:50	instagibbs:	what are the extend of soft/hard forks possible without re-doing the secret? Give a ballpark idea?
17:02:59	petertodd:	fluffypony: reading that post makes me think we need to make a combination markov chain generator that combines alt-coin pumps with audiophile crap
17:03:06	fluffypony:	LOL
17:03:14	sipa:	petertodd: we need a coingengen for that
17:03:23	instagibbs:	did you read the "specs"?
17:03:24	petertodd:	sipa: coingen^n
17:03:47	instagibbs:	"Zero-centralization" <--- there ya go
17:03:52	petertodd:	instagibbs: for instance, you can fork the entire coin and make a whole new one...
17:04:18	fluffypony:	https://bitcointalk.org/index.php?topic=421615.msg10310458#msg10310458
17:04:27	fluffypony:	clearly there are no incentives for masternodes to attack each other
17:04:40	petertodd:	fluffypony: not when they're all run by the same people!
17:04:45	fluffypony:	lol!
17:04:59	instagibbs:	petertodd: let me ask the reverse: what can't be done :P
17:05:34	petertodd:	instagibbs: changing the basic ZK primative; notable that probably *doesn't* include changes to how you authorize a ZK transaction
17:05:40	justanotheruser:	petertodd: speaking of, haven't you consulted for a lot of altcoins?
17:06:08	petertodd:	justanotheruser: that's actually a myth - lots *want* me to consult for them, but nailing down acceptable contracts has proven to be tough
17:06:36	justanotheruser:	what is acceptable, a matter of money or a lack of scamminess?
17:06:56	petertodd:	justanotheruser: my standard contract lets me publish the results of any reviews...
17:07:16	justanotheruser:	I mean, it is reasonable that you did an audit of litecoin since it is probably better that they fail organically than through a bug..
17:07:26	sipa:	petertodd: i assume you also demand payment in something else than the altcoin currency? :p
17:07:30	justanotheruser:	thats a smart way to do it I suppose
17:07:40	petertodd:	sipa: yeah, some try to pull that stunt too
17:07:52	instagibbs:	sipa: how do you think ICO's work? :P
17:09:30	petertodd:	sipa: litecoin was very clever about it: paid me in bitcoin, then gave me an unexpected bonus in litecoin, with the condition that I not spend it until a few months later to incentivise me not to attack litecoin :)
17:11:02	sipa:	heh
17:11:04	sipa:	nice one
18:53:06	gmaxwell:	http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html "Exploiting the DRAM rowhammer bug to gain kernel privileges"
18:53:19	sipa:	... that looks like a hardware bug
18:54:50	gmaxwell:	Yep. Though a common one. I note that some of the more recent server atom stuff has very fine control of dram behavior in bios, and you can back of the timings to make them super conservative, which should help defend against this sort of thing.
19:17:41	hearn:	hello
19:18:11	hearn:	"“Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows"
19:18:15	hearn:	boggle
19:18:55	jcorgan:	didn't we first hear about this a few months ago?
19:19:14	sipa:	i definitely never heard about it
19:19:34	hearn:	right, this is news to me as well
19:19:40	sipa:	i remember attacks with data remaining available in DRAM chips after poweroff
19:20:22	hearn:	it seems the most interesting sandbox to escape out of would be Xen
19:25:53	jcorgan:	i'll have to search, but i thought I had heard of the bit flipping issue a while back. maybe this is just the first published exploit.
19:41:51	sipa:	apparently rowhammer was indeed public before; i hadn't heard about it
19:42:28	gwillen:	there was a paper about it some time ago, but without any proof of concept exploit
19:42:53	gwillen:	less than a year ago, I think
19:43:15	gmaxwell:	yea, it was public before but the paper only measured their ability to cause errors, not actually applying it for escilation.
19:43:22	gmaxwell:	(I linked to that paper in here too)
19:45:48	gmaxwell:	14:51 <@gmaxwell> On today's expisode of eveything is broken and we're doomed. http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf
19:49:16	jcorgan:	that was the one
19:57:50	maaku:	so rowhammer has been out a year, and for me this is the first I've heard of it too. is there any mitigation techniques?
19:58:01	hearn:	they discuss some at the end of the blog post
19:58:24	hearn:	tl;dr yes, if you happen to be a DRAM manufacturer. if not then there are BIOS updates that make it slower to exploit but don't fix it
19:58:27	hearn:	(sometimes)
19:59:06	hearn:	it seems that some DRAM makers are already advertising that their chips don't have this problem. but i guess there's not much that can be done now except wait years for the previous bad chips to fail and be replaced.
20:01:03	MRL-Relay:	[tacotime] yeah i was going to say, this was most recently fixed in DDR4.
20:02:08	gwillen:	I've seen it suggested that linux could mitigate this by limiting the ability of user allocations to end up too close to kernel allocations in the relevant metric
20:02:34	gwillen:	but I don't know if that works out to be possible
20:02:42	gmaxwell:	as I mentioned, on some of the newer server boards there are extensive timing controls and you can back off the settings to really conservative values.
20:03:18	gmaxwell:	otherwise: don't run code from mixed security domains on the same hardware
20:03:19	MRL-Relay:	[tacotime] well... they do have to get the user to run some arbitrary code that does this in the first place. and if you've failed that test, it's all over even in the simplest case.
20:04:51	MRL-Relay:	[tacotime] hrm. i wonder, can you VM escape on a VPS then too with this, for any general VPS?
20:05:44	MRL-Relay:	[tacotime] because that's actually pretty bad.
20:06:49	Luke-Jr:	what is MRL-Relay?
20:07:06	sipa:	Monero Research Labs relay
20:07:18	MRL-Relay:	[tacotime] yeah. freenode is anal about tor connections.
20:19:28	MRL-Relay:	[tacotime] gmaxwell: figure 4 from the paper is pretty ugly. it looks like you can't get down to 0 errors without decreasing the refresh interval to 16 ms (four fold), and that won't solve it for 100% of manufacturers even. i guess if you're running a server you could crank the refresh timing and memtest to make sure it's not doing anything crazy.
20:20:25	MRL-Relay:	[tacotime] if i'm reading it correctly.
21:47:02	gmaxwell:	tacotime: IIRC ECC memory is largely protective.
21:47:43	gmaxwell:	I think we're all crazy whenever we use non-ECC systems for anything important. Bitflips are absolutely observable at current memory densities, if you're actually looking.
21:57:52	hearn:	tacotime: yes i would imagine you can break out of Xen and other hypervisors with such an attack
21:59:00	hearn:	assuming you can run native code
21:59:10	hearn:	if you can't generate the clflush instruction it probably is a lot harder to do that
22:26:07	petertodd:	gmaxwell: is there a ECC ram laptop on the market?
22:29:00	BlueMatt:	petertodd: macbook pro
22:29:07	sipa:	orly?
22:29:18	petertodd:	BlueMatt: oh nice
22:29:34	brisque:	I don't think that's right
22:29:38	BlueMatt:	orrrr....I think so?
22:29:42	BlueMatt:	https://support.apple.com/en-us/HT202892
22:29:57	brisque:	the mac pro does, the macbook pro doesn't
22:30:04	sipa:	mac pro, not macbook pro
22:30:05	BlueMatt:	oh, I'm tripping
22:30:06	BlueMatt:	nvm
22:30:06	BlueMatt:	yea
22:30:12	BlueMatt:	somehow i thought it did :(
22:30:16	sipa:	you know, the trashcan
22:30:20	BlueMatt:	lol
22:30:24	brisque:	it's a pretty trash can though
22:30:25	sipa:	not the tin foil
22:30:26	petertodd:	too bad
22:42:16	gmaxwell:	petertodd: that was part of how I phrased the statement "we're all crazy whenever we use"
22:43:07	gmaxwell:	Apparently someone is holding a "blockchain workshop" at stanford later in this month. Have any of you been invited to it?
22:43:19	petertodd:	gmaxwell: I'm going
22:43:59	brisque:	that would be fun. a linux distro designed to run simultaneously on multiple computers and diff the results, NASA redundancy style.
22:44:03	petertodd:	gmaxwell: probably going to go to sf this friday actually
22:44:11	gmaxwell:	Cool.
22:44:44	gmaxwell:	I'm a bit irritated that some people holding workshops in this space seem to do a bad job reaching out into the bitcoin ecosystem, and I'm trying to calibrate my level of irritation.
22:45:00	jcorgan:	"blockchain workshop" sounds awfully...backwards
22:45:05	petertodd:	gmaxwell: it's a legal-focused workshop, not tech the way you're thinking
22:45:16	brisque:	jcorgan: it's all about the blockchain technology.
22:45:17	petertodd:	gmaxwell: they reached out to me because they know I'm familiar with that side of the ecosystem
22:45:41	amiller:	im not going but elaine shi is
22:46:10	gmaxwell:	jcorgan: well so, some people doing this stuff have already been flamed for holding "bitcoin workshops" and then having 9/10 people be bitcoin competing systems; so now it's blockchain workshops. :)
22:46:26	brisque:	ouch
22:46:31	petertodd:	yeah, the workshop agenda is not bitcoin focused
22:46:38	petertodd:	saying "blockchain" is very accurate
22:46:58	petertodd:	hell - "crypto finance" might be more accurate
22:47:08	brisque:	petertodd: sort of playing into the hands of "decentralise everything with a blockchain" though
22:47:27	jcorgan:	be sure to bring your hip waders
22:47:38	petertodd:	brisque: like I say, it's a legal workshop - that's completely appropriate and what they're trying to explore - it's all researchers after all
22:47:48	brisque:	jcorgan: those things you use to walk into swamps?
22:47:57	moa:	so what kind of work do they do at workshops?
22:47:58	petertodd:	brisque: it's the kind of thing where inviting a sci-fi author *would* be 100% reasonable
22:48:31	gmaxwell:	brisque: in this case 'research' is mostly the 'disconnected from reality' sense of the word. :)
22:49:20	petertodd:	gmaxwell: nah, actually a lot of this stuff is very connected to reality, and ends up using the tech in very realistic and actually kinda boring ways
22:55:01	skittylx:	How does a double spend attempt even happen 30 hours later? https://blockchain.info/tx-index/79946788
22:55:29	brisque:	skittylx: OT #bitcoin
23:53:33	bramc:	Can people see me here?
23:53:39	bsm117532:	yes
23:54:01	bsm117532:	Read something by you yesterday...can't remember what it was...
23:55:22	bramc:	Oh good. I'm being ghetto and getting on using monero's irc web client because freenode won't let me join directly because I'm on cellular because it's better than the net connection here in the cafe
23:56:26	hearn:	they ban cell phone connections?
23:56:30	bramc:	* bramc shaves a yak for good measure
23:56:59	brisque:	hearn: I know hurricane electric bans IRC :<
23:57:10	bramc:	hearn, freenode in general has some policy about you having to use somethingorother from a 'suspicious' IP, which apparently includes my mobile carrier
23:58:01	bramc:	I'm not willing to sign up for a new account on freenode at this point, so web gateway it is
23:59:05	bsm117532:	Lots of ISP's ban irc.
23:59:10	bramc:	Although I have to say, this web interface is entirely usable, and this channel doesn't seem to have any problems with needing to ban people and the like, or at least it's not my problem.
23:59:12	bsm117532:	It's how you control your botnet, we know bram.
23:59:43	bramc:	bsm117532, this is a freenode policy, nothing about my net