00:25:50	justanotheruser:	Could a zero coin type system be applied to WoTs?
00:28:57	nsh:	expand on "could.. be applied" if you can
00:29:39	justanotheruser:	nsh: could I find out what my trust is for an individual without knowing anyone else's ratings?
00:30:39	nsh:	in principle, i think
00:30:40	gmaxwell:	someone should go find the link I did about using them for credit risk analysis.
00:31:04	nsh:	cryptographic accumulators, or something more specific?
00:31:10	gmaxwell:	justanotheruser: generally no, because what you need is secrecy of distributed data. MPC could permit that.
00:31:11	nsh:	or WoTs?
00:31:27	gmaxwell:	justanotheruser: On that subject I posted this: https://bitcointalk.org/index.php?topic=398041.0
00:32:44	jcorgan:	has anyone compiled the Gregory Maxwell Concordance?
00:33:53	gmaxwell:	justanotheruser: with MPC it would be 'easy'. Everyone has their own ratings, the MPC does the route finding to return an encrypted raiting result in response to a query.
00:39:02	andytoshi:	jcorgan: organizing the information which streams through here would be a cool narrow AI problem, and i don't know that anything less would suffice
00:39:49	gmaxwell:	elsewhere this AI is deployed under the moniker 'grad students'.
00:40:10	Emcy:	nsh root your android they said
00:40:16	Emcy:	its fun, they said
00:40:24	gmaxwell:	I wish the forum had something to just list my top level posts.
00:40:35	andytoshi:	in fact we have an AI researcher — stephenreed — here, though he's got his own projects which are sexier than "irc librarian" :)
00:41:12	gmaxwell:	Wading through all my posts to find ones like that is too much work. If nsh hadn't mentioned "accumulators" I probably wouldn't have found it.
00:41:43	nsh:	yay, i achieved something today!
00:41:51	nsh:	* nsh takes rest of week off
00:42:11	gmaxwell:	andytoshi: but isn't it the case that you can take any AI problem and convert into an instance of any AI complete problem that you know how to solve? :P ("First it cataloged conversation on IRC", "Then we converted self-optimization into an IRC cagaloging problem…")
00:42:39	nsh:	ah, scholastics...
00:46:45	andytoshi:	gmaxwell: hahaha
00:49:55	kanzure:	ah the cycorp person
01:08:26	Guest76181:	Guest76181 is now known as ageis
01:49:54	OneFixt_:	OneFixt_ is now known as OneFixt
05:49:38	stephenreed:	andytoshi: I finished my whitepaper - https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE for Bitcoin a proof-of-stake version which uses a single nomadic verifiable mint agent and distributed replication of a single blockchain by compensated full nodes to achieve 6-hop, sub-second transaction acknowledgement times. Plus it pays dividends to holders instead of wasting it on miners. Subsi
05:49:39	stephenreed:	dized transaction fees are thus lower. My first coding objective are Szabo's tamper-evident logs. Comments appreciated. stephenreed@yahoo.com or https://bitcointalk.org/index.php?topic=584719.0
06:59:51	michagogo:	Bricking stuff isn't fun :-(
07:01:32	phantomcircuit:	michagogo, whatcha brick
07:01:40	michagogo:	One thing iOS has going for it: it's just about impossible to brick an iOS device beyond repair just through soft/firmware (through the connector port) -- worst case, press a certain button combo and plug it into a computer to restore
07:01:52	michagogo:	phantomcircuit: nothing, just sympathizing with the backlog
07:02:32	phantomcircuit:	ah nsh did
07:02:34	phantomcircuit:	heh
07:02:48	phantomcircuit:	and emcy
07:02:48	phantomcircuit:	lol
07:02:56	jctb_:	jctb_ is now known as jctb
07:03:22	phantomcircuit:	michagogo, you definitely can brick an ios device if you hack the bootloader, but nearly all ios jailbreaks are via kernel exploits
07:03:26	phantomcircuit:	so nobody does that
07:05:07	michagogo:	phantomcircuit: eh? Pretty sure that the ROM is all you need to get into dfu
07:05:46	michagogo:	With somewhat recent devices, anyway
07:06:02	michagogo:	(~4 years or newer?)
07:06:32	phantomcircuit:	michagogo, right, but you cant even get into that if the bootloader is truly hosed
07:08:08	michagogo:	phantomcircuit: bootrom is under the bootloader...
07:09:09	phantomcircuit:	michagogo, possibly im misinformed, but i believe that the bootrom is dumb and just loads the bootloader no matter what
07:09:17	michagogo:	You may be right. I'm pretty sure I read that it can't be done, but I may be misremembering or what I read could be wrong.
07:09:22	michagogo:	*shrug*
07:09:40	phantomcircuit:	michagogo, "it's impossible to brick an iPhone" -- fanboi
07:37:53	jps_:	jps_ is now known as jps
11:24:17	jaromil:	hi all :^) thanks sipa for inviting me
11:24:44	jaromil:	hier interessant Bernard Lietaer (big shot in EU monetary policy) speaks in favor of "Bitcoin architecture" http://debitcoin.org/professor-bernard-lietaer-de-architectuur-van-bitcoin-kan-een-belangrijke-toekomst-hebben/
11:25:49	jaromil:	* jaromil spent a whole day talking to him, worthed
11:28:16	hearn:	nice
11:28:26	hearn:	his book on the future of moeny is what started me on this whole adventure many years ago
11:36:31	nsh:	neat
12:43:42	jgarzik:	jgarzik is now known as home_jg
13:42:51	jaromil:	at dyne.org we have some leverage with this project http://DCENTproject.eu whose main focus is not really crypto-currency systems, however the research track its in there
13:43:51	jaromil:	so we hired Bernard to pick his brain and the yeld is good for everyone. just these days we're starting the design phase of more hypothetical crypto-currencies
13:45:03	helo:	proof-by-elephant-art
13:47:22	jgarzik:	huh. Ethereum Project snagged neal koblitz as an advisor.
13:49:43	jgarzik:	"[Ethereum's] current [proof of work] strategy takes a much more rigorous track: make the proof of work involve executing random contracts from the blockchain. Because the Ethereum scripting language is Turing-complete, an ASIC that can execute Ethereum scripts is by definition an ASIC for general computation, ie. a CPU – a much more elegant argument than “this is memory-hard so you can’t parallelize as much”."
13:51:50	helo:	who chooses which contracts are used in the PoW for a particular block?
13:52:15	helo:	i.e. what determines "random contracts"
13:52:27	sipa:	presumably some deterministic formula
14:14:58	jgarzik:	amiller, what is the link to that bounty for simulator thing?
14:48:46	amiller:	http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/5279D49D.5050807%40jerviss.org/#msg31604911 jgarzik this is the mailing list thread
15:15:37	andytoshi:	stephenreed: on the mailing list today you said that "proof of stake is the reason that peercoin is so popular", but peercoin is centralized, it has a developer-defined consensus. there is still no known way to get a consensus system out of proof-of-stake years after 2011 when "proof-of-stake was immediately recognized as a very attractive idea"
15:16:32	andytoshi:	the first section of your paper talks about bitcoin wasting heat and uses the usual rhetoric about hashing being "single purpose". would you say cell respiration is single-purpose because all it does is bind oxygen to carbon?
15:17:11	andytoshi:	the purpose of mining is to translate physically scarce resources into cryptographically scarce ones
15:17:39	jgarzik:	amiller, posted on forum saying it satisfied conditions
15:17:49	jgarzik:	amiller, and emailed a request for payment addr
15:17:51	ebfull:	hey jgarzik thank you very much
15:17:54	ebfull:	i replied
15:17:55	ebfull:	:)
15:18:25	jgarzik:	ebfull, indeed, thanks
15:18:55	andytoshi:	stephenreed: aaaah, checkpoints have nothing to do with consensus!!
15:19:00	ebfull:	and thanks amiller as well for advice/encouragement
15:19:57	andytoshi:	:s i'll move to the message board for this
15:21:00	OneFixt_:	OneFixt_ is now known as OneFixt
15:38:11	stephenreed:	andytoshi: I posted a link on the Reddit bitcoin subform and am busy answering every comment there. Regarding PPC and proof-of-stake, Sunny King created PrimeCoin first and it is not as popular as PPC. I believe that is because PrimeCoin is PoW and PPC is PoS. Agreed that PPC has the problems you mention. At this point there is no code to prove that PoS works for me. I think by this fall there will be. The referenc
15:38:11	stephenreed:	ed papers give me confidence that proof-of-stake can be used in a stake-weighted peer voting quorum to ban misbehaving nodes.
15:39:21	kanzure:	* kanzure mumbles something about sybil
15:39:44	andytoshi:	stephenreed: ok, i'm typing up a reply on bitcointalk, i won't badger you here while you're on another near-realtime forem
15:40:20	andytoshi:	but i really really don't believe there will be working PoS by the end of this year, such a thing has been promised forever and the people promising it do not even seem to understand the issues
15:43:07	stephenreed:	andytoshi: the test plan comes first. You might suggest a case involving a testable number of nodes that would break the system as you see it.
15:45:32	andytoshi:	sure, i'm confident that your dev processes will detect these kind of problems. but PoS i think is actually impossible so you can save yourself some time by stepping back and trying to fix it until you also believe it's impossible
15:45:35	andytoshi:	or until you find a way it works..
16:30:40	wallet42:	wallet42 is now known as Guest3349
16:30:40	wallet421:	wallet421 is now known as wallet42
16:45:51	wallet421:	wallet421 is now known as wallet42
17:00:01	gmaxwell:	stephenreed: I'm afraid your solution may be 'overfit' — you've produced a large amount of complexity with lots of specific parameters (100 super peers 8000 full nodes each, 'checkpoints') but no clear statement of how this system is not vulnerable to the "nothing at stake" class of problems that arise from costless simulation.
17:01:27	gmaxwell:	I'm afraid you may have misunderstood 'checkpoints' in the BCT thread. PPC has deceptively called what it does checkpoints but what it does is entirely distinct from the oft-misunderstood functionality in Bitcoin by the same name.
17:02:14	gmaxwell:	What PPC does is that it requires that the developer of the software cryptographically sign the proof of work blocks and broadcasts these signatures to the network. The network will not reorg out a signed block, and will stop working if the signatures stop.
17:03:23	gmaxwell:	This functionality is needed to prevent (without the developer's cooperation) someone from cheaply replacing the PPC state, of course the developer himself could still do this.
17:06:11	gmaxwell:	This mechenism is part of what stopped a simulation-powered attacker who started mining forks to produce a chain where he was selected as miner for every block (the rest of the solution is to use POW blocks exclusively to chose which stakeholders will mine, forever requiring POW as part of PPC's security). These mechenisms address the nothing at stake problem in PPC— at least to some extent— but they come at the cost of requiring ...
17:06:17	gmaxwell:	... POW and handing control to the holder of a special private key.
17:07:32	gmaxwell:	By comparsion what we have in the reference bitcoin software which is called checkpoints is something entirely different— the software comes preprogrammed with the identity of the old best chain known to it... there is no broadcasting, different software has different checkpoints, and the network continues working even if there are never any more checkpoints.
17:10:26	gmaxwell:	They can also be disabled with a commandline switch, and doing so doesn't harm the operation of the network (as doing so would in PPC). The motivation is entirely different: The implementation of the reference software is vulnerable to a number of pedestrian denial of service attacks— for example, a new node starts up and connects to some potentially malicious peers because the minimum difficult of 1 is low by the standards of ...
17:10:32	gmaxwell:	... modern hardware an attacker could feed you hundreds of gigabytes of bogus chain data, which you'd accept and store... Eventually you'd converge on the real network once you connect to it, however.
17:11:53	gmaxwell:	Another example is that if the newly started node starts up partitioned by a network attacker, he could be denied access to the best chain (a less often remarked on assumption in the bitcoin security model is that the users can't be partitioned from the honest network on an ongoing basis). By having some notion of the identity of the honest chain in the software you couldn't partition someone without them detecting it without also ...
17:12:00	gmaxwell:	... replacing their software (at which point all bets are off).
17:12:23	helo:	(much gratitude for your persistence in repeatedly detailing the problems with PoS)
17:12:38	maaku:	maaku is now known as Guest74946
17:13:18	gmaxwell:	When sipa's headers first code is merged in the reference software we'll have a better solution to most of these DOS attacks and checkpoints in Bitcoin-QT will likely be removed and be replaced with something more limited that is primarily helping with the initial paritioning attacks.
17:13:27	andytoshi:	what is interesting to me is that aside from PoS, i think all of stephenreed's ideas are workable (though i do think they're an engineering challenge and i do think they change the trust model because there is dependence on TPMs for some of the trusted-computing stuff)
17:13:43	andytoshi:	so i wonder if there's a weaker primitive than PoS-based consensus that could be slotted in
17:15:01	gmaxwell:	(We also use the checkpoints for a few other things, like turning off ECDSA for the far history as a rather ugly performance optimization... with new ECDSA code that is 6x faster in the pipeline this is less needed, but even here, headers first offers a less centralized way to choose to optimize signature validation)
17:17:06	nsh:	* nsh just wants to be able to grok these things with via formal models and neat diagrams and the like
17:17:12	gmaxwell:	To further highlight the differences between what PPC calls checkpoints (what I think ought to be called "block signing") and what bitcoin core has, ... the PPC block signatures are transmitted in realtime and the nodes stop working if the latest one is >2 weeks old. By contrast, bitcoin core checkpoints only come in new updates (which must be audited by users or they could do _anything_) and as a matter of procedure do not include ...
17:17:18	gmaxwell:	... checkpoints shallower than 2016 blocks deep, just to be extra sure that the checkpoint is not arbritrating the consensus.
17:17:44	nsh:	ideally something i can play with interactively that shows how consensus is broken when various mechanisms or parameters are changed
17:18:05	nsh:	SimConsensus
17:19:10	gmaxwell:	nsh: one of the challenges with "overfit designs" is that I can keep throwing on tweaks that stop any particular attack you propose ("Don't accept block X or Y") without actually achieving a fundimental security improvement... I can just make the cost of analysis so high that it's not worth attacking the proposal anymore.
17:19:25	gmaxwell:	(but might well be worth attacking the system in production)
17:19:29	nsh:	right
17:20:39	gmaxwell:	nsh: I think we don't have a really good umbrella description as to why nothing at stake is such a hard problem. The way I put it above, that nothing at stake is the problem of costless simulation, is a stab in that direction.
17:21:11	nsh:	* nsh nods
17:21:25	andytoshi:	i noticed that new phrase above, i'll chew on it
17:22:08	gmaxwell:	I think it covers all the issues we normally group under nothing-at-stake, but I'm unsure— maybe there are others I'm not thinking of.
17:22:49	gmaxwell:	e.g. the "grind to find the network where you mine all the blocks" attacks are just running simulations privately to find ones you like.
17:23:15	gmaxwell:	and the replace history attacks are making a simulation public, and people can't distinguish it (because the simulations are completely faithful).
17:24:41	nsh:	i was just trying to think of the problem in terms of a bunch of point-particle moving along an abstract vector space with the ability to influence the trajectory of each other through publication, withholding, partition of mutation actions
17:25:39	nsh:	the goal is to prevent any group being able to divert the entire set of points from a cohering random walk
17:26:05	andytoshi:	an interesting idea, you'd need an "incentive potential" or something to model the economics, and hopefully the details of this potential are not so important
17:26:46	nsh:	right, you might be able to abstract out various things, and one ones you can't are the essential factors
17:27:05	nsh:	then i could have a better handle on what exactly the resource of work is converted into, dynamically
17:28:46	nsh:	for example the lottery aspect of PoW distributes the turns evenly between the point, which means that the forces of each turn's action have a tendency to cancel out
17:28:54	nsh:	as long as there are not long-range correlations
17:29:04	nsh:	*the points
17:29:58	nsh:	oh, so it might be analogous to the temperature above which coherence does not manifested in condensed matter systems
17:30:18	nsh:	*furious handwaving*
17:30:57	nsh:	(but it might be nice to have that idea of having to keep putting heat in...)
17:40:23	amiller:	ebfull, make sure to collect from kjj too!!
17:40:25	amiller:	also i sorta hope you're able to collaborate with those barcelona scientists who won a bitcoin foundation grant to build similar things, maybe this street credit will help introduce you
18:31:02	Guest74946:	Guest74946 is now known as maaku
18:48:13	stephenreed:	gmaxwell: andytoshi: The comment flood at Reddit has passed. The overfit point is a good one. But the Satoshi mesh network does not make sense to a conventional global network architect. If people were assigned to perform the tasks that bitcoins do now, and they had a caluculator to perform the proof-of-work caluculation. I suppose that it would not take very long for them to figure out a round robin system whereb
18:48:13	stephenreed:	y they took terms creating the new block with no effort. Cheaters would be observed and banned by their peers.
18:57:19	jtimon:	someone is asking this to me: is there a link with a formal critique of proof of stake as a replacement for proof of work?
19:03:33	davidlatapie:	Interested too
19:03:56	jtimon:	I know andytoshi's paper will cover it but didn't got to that part yet
19:04:26	andytoshi:	jtimon: what's in my paper is really brief, i don't know if there's a formal critique out there
19:05:21	andytoshi:	stephenreed: i get that intuition that bitcoin has a really weirdly-inefficient-seeming design, and i think the weirdness is focused squarely on the distributed consensus mechanism
19:05:29	jtimon:	andytoshi is this the best link or you have another more complete? https://en.bitcoin.it/wiki/User:Andytoshi/A_Treatise_on_Altcoins
19:05:58	andytoshi:	jtimon: the pdf link is more recently updated, https://download.wpsoftware.net/bitcoin/alts.pdf but it doesn't talk about PoS yet
19:06:04	andytoshi:	https://download.wpsoftware.net/bitcoin/asic-faq.pdf has a blurb
19:06:38	andytoshi:	i am planning by end of summer than alts.pdf will be finished, then i'll migrate it to the wiki for good, since a lot of people have complained to me about pdfs
19:06:56	andytoshi:	apparently there is a popular OS out there which routinely gets hosed by document formats..
19:08:04	andytoshi:	stephenreed: but the reason for that is that distributed consensus seemed impossible until bitcoin (which evaded an impossibility proof by patching in economics in ways that we haven't gotten our heads around yet), so it is a really hard problem
19:08:49	jtimon:	why not having both pdf and html?
19:11:23	andytoshi:	jtimon: my build is not automatic enough and i forget, that's all. it's a todo
19:12:24	jtimon:	humm, I produce my pdfs from emacs org-mode, which can produce other formats like html as well
19:13:24	andytoshi:	i type pdflatex at the prompt..
19:14:17	andytoshi:	should be 'make', which does pdflatex, latex2html, scp, etc for me
19:15:31	jtimon:	I see, I just write less latex now thanks to org-mode I guess
19:18:59	nsh:	* nsh puts down andytoshi's name in the list entitled "facilitators of continued makescript tyranny"
19:22:58	jtimon_:	* jtimon_ wonders if nsh has replaced make with grunt or something
19:26:54	sipa:	E: Unable to locate package grunt
19:27:59	nsh:	i've just replaced programming with grunting
19:34:42	jtimon_:	sipa: it's a javacript thing, you install it with "npm install -g grunt-cli"
19:35:19	sipa:	oh ok :D
19:40:41	phantomcircuit:	jgarzik, were you referring to https://github.com/jgarzik/bitcoin/compare/udp on the ml?
19:41:37	jgarzik:	phantomcircuit, yes
19:41:59	phantomcircuit:	seems like it requires a cookie setup over tcp
19:42:16	jgarzik:	phantomcircuit, yes
19:42:31	phantomcircuit:	simple rDoS prevention?
19:42:37	jgarzik:	phantomcircuit, it is intended to be paired with a TCP connection, rather than being a full alternative
19:42:41	jgarzik:	phantomcircuit, and that
19:43:00	jgarzik:	phantomcircuit, you elect to receive high volume, low latency, ok-to-drop messages via UDP
19:43:05	jgarzik:	after connecting via TCP
19:43:10	phantomcircuit:	jgarzik, it's just that the entire protocol is stateless with the exception of bloomfilters
19:43:13	jgarzik:	phantomcircuit, i.e. sending blocks makes more sense over TCP
19:43:26	jgarzik:	phantomcircuit, yes, but nevertheless... blocks
19:43:37	jgarzik:	phantomcircuit, you otherwise wind up reinventing TCP over UDP
19:43:46	phantomcircuit:	not necessarilly
19:44:00	phantomcircuit:	block headers + merkle tree pieces
19:44:08	phantomcircuit:	except a tx can be > 64kib so i guess you do
19:44:09	phantomcircuit:	nvm
19:44:29	phantomcircuit:	just received some knc jupiters from knc's mining operation
19:44:42	phantomcircuit:	amazingly they work about 40% better than the ones they shipped us in october
19:44:54	phantomcircuit:	it's almost like they shipped us broken units on purpose
19:44:57	phantomcircuit:	>.>
19:45:26	phantomcircuit:	jgarzik, i guess block headers over udp and maybe merkle tree would work, but the tx ultimately has to come over tcp due to size
19:46:30	jgarzik:	phantomcircuit, perhaps... big TXs can take another path. it's another incentive in the mix...
19:46:43	jgarzik:	similar to big blocks, which might lose races to smaller blocks, even without my help.
19:46:55	jtimon_:	* jtimon_ wonders how stupid would it be to connect peers using zeromq or nanomsg, their sockets are so simple to use...
19:47:47	nsh:	jgarzik, you make it sound like tcp was already invented right
19:47:53	nsh:	:)
19:48:05	phantomcircuit:	the last i checked zmq isn't robust enough for use on the open internet
19:48:14	phantomcircuit:	although that could have changed more recently
19:49:36	jtimon_:	phantomcircuit: I don't think it's about robsutness but about security "in the open internet" you will probably need to encrypt the stuff yoursef as zeromq doesn't do it for you but, do we care in this context?
19:50:16	phantomcircuit:	jtimon_, uh no
19:50:32	phantomcircuit:	i mean you used to be able to send zmq special packets and it would trigger an assert
19:50:39	phantomcircuit:	iirc it just took lying about the packets size
19:51:43	jtimon_:	mhmm I see, seems related to security as well, but maybe it does matter in this context
19:52:42	jtimon_:	since here you don't necessarily trust other peers
19:53:15	sipa:	i thought we wanted to get rid of dependencies for core functionality :)
19:53:38	jtimon_:	probably I should just ask on #zeromq and #nanomsg
19:54:50	jtimon_:	well, these things serve for both networking and concurrency (apart from being language agnostic) so they're very attractive to me
19:55:01	jtimon_:	as dependencies
19:55:20	jtimon_:	of course it would be either one or the other
19:55:23	sipa:	i really don't like things that increase attack surface
19:55:59	jtimon_:	yeah, I mean, I was just thinking out loud to see what people said against it
19:56:24	adam3us:	did anyone take a look at Chris Okupski ~30 page bitcoin summary? quite nice level of detail for things i think are hard to find outside of source, or heads of people here who write bitcoin core code. http://enetium.com/resources/Bitcoin.pdf
19:57:22	sipa:	didn't look yet
19:57:27	adam3us:	he's looking for feedback on errors or omissions. (he acks sipa helping him with questions in the paper)
19:57:54	adam3us:	sipa: it looks rather useful level of detail from the bits i read. mostly skimmed so far.
19:58:20	sipa:	it should be "Protocol version 70002", not "0.8.6"
19:59:26	nsh:	btw, andytoshi "However, shortly after the turn of the 21st century, Adam Back discovered a novel type of cryptography" <-- I would use another phrasing for "type of cryptography"
19:59:39	nsh:	concept in cryptography or equivalent maybe
19:59:47	nsh:	or principle
20:00:37	adam3us:	nsh: thats a bit grandiose. y'know technically i reinvented the broad idea of a PoW, it turned out later. there's a ref on hashcash.org/papers/ to a paper by Naor & Dwork that while based on public key crypto (bigger, slower, uglier) is the same effect
20:01:17	nsh:	ah, interesting
20:01:18	nsh:	thanks
20:01:34	sipa:	adam3us: you remember his nickname?
20:02:34	adam3us:	sipa: i dont know if he's on irc, i emailed him and suggested i'd post a link here and infer maybe he'd like to join.
20:02:48	sipa:	he first asked on irc for comments
20:02:50	sipa:	a few times
20:02:55	cbeams:	adam3us: have only just glanced at this point, but it makes me wonder whether Krystof is aware of the developer-guide effort (http://bitcoindev.us.to/en/developer-guide). May be some overlap here.
20:04:07	adam3us:	sipa: oh. i sent him an email asking for his irc nick. maybe he'll come online. he just replied to an email.
20:05:44	adam3us:	nsh: there is some truncated version of the clarification (i edited it but someone else pointed it out) https://en.bitcoin.it/wiki/Factual_inaccuracies_in_videos
20:05:59	nsh:	ty
20:06:32	adam3us:	nsh: "- It was incorrectly claimed that Adam Back invented the concept of proof of work. Bitcoin does use Back's hashcash proof-of-work because bitcoin needs specific properties and hashcash is the simplest (and so far only) proof of work with these required properties (primecoin maybe the new exception). But the PoW concept is older, and due to Dwork & Naor in their crypto 1992 paper."
20:07:05	shinybro__:	shinybro__ is now known as shinybro
20:07:08	nsh:	* nsh nods
20:07:14	coryfields:	hmm, who's the author of that paper?
20:07:18	coryfields:	his nick, i mean
20:07:29	coryfields:	pretty sure i've seen him around asking questions lately
20:07:29	sipa:	chichov
20:08:22	coryfields:	hmm, not the one i was thinking of
20:08:58	nsh:	Dwork & Noar paper has linux-unfriendly fonts (or evince fails)
20:08:58	sipa:	minium too, i think
20:10:01	adam3us:	cbeams: one advantage can be we've seen academic people want to read papers in that format and reference them. and then academic papers get written with non-trivial misunderstandings of bitcoin. so while Chris has less detail than the docu effort, its a self-contained citable work which seemingly is what it takes for the academic audience to read & cite.
20:11:12	cbeams:	good point. I'll refer the primary authors of the guide to this doc so they can compare notes.
20:11:37	adam3us:	cbeams: or it could be. he probably needs to finish getting review of the details, and put it on arxiv eprints or his university's tech report publishing location
20:12:46	adam3us:	cbeams: or a web site url is somewhat frowned on also (they tolerate bitcoin paper & hashcash paper also because they got cited enough already to overcome the "no standard publication" issue)
20:13:50	cbeams:	adam3us: yeah, if only there were some kind of widely agreed on universal resource locator that we could use for this kind of thing..
20:15:15	adam3us:	cbeams: we could do with a web2.0 (only that term has been taken now) ie decentralized immutable publication with versions. like tahoeLAFS with hash based URLs
20:16:26	adam3us:	cbeams: ross anderson had some similar ideas with eternity and a system for authenticating links and contents via self-authenticating urls (sort of merkle tree of web pages) so you have hash of hash including hash of content in link recursively for snapshots and signatures for changes, to make referable multi-page works
20:17:16	cbeams:	nah. I'm sure JSTOR is enough, right? ;)
20:17:18	zzyzx:	zzyzx is now known as roidster
20:17:49	roidster:	roidster is now known as Guest89031
20:19:53	pigeons:	cite a freenet key
20:22:40	zooko:	Tahoe-LAFS also has public-key-based URLs (a la Freenet SSKs or the Self-Certifying File System's links) in addition to hash-based (a la Freenet CHKs).
20:24:36	adam3us:	zooko: do those have the option to provide links to immutable versions of a document?
20:25:37	sipa:	^ chichov is the author of the paper we were just discussing :)
20:25:48	zooko:	adam3us: no, mutable documents can be destructively updated by an authorized writer, and the only way to keep a reference to the previous version would be to make a copy before that destructive update happened.
20:26:09	zooko:	There is nice convergent encryption so that multiple people with minimal coordination can do that make-an-immutable-copy efficeintly.
20:26:44	zooko:	adam3us: also a writer could optionally publish a series of immutable documents, along with a destructive update to a different, mutable, object, pointing to the archive of immutable versions.
20:26:59	zooko:	adam3us: that's what the "tahoe backup" command does, so that you can navigate back through snapshots of your backup history,
20:27:07	zooko:	where each file and directory in each snapshot is an immutable object.
20:27:30	adam3us:	zooko: do u have no variant that is immutable by design. publish and destroy key is immutable only by author intent. eternity aimed for rather immutable against all interests (like no one can change, no how)
20:28:29	zooko:	adam3us: yes, the content-hash-based ones can't be mutated even by the original publisher.
20:28:31	adam3us:	zooko: it sounds like you do have such a feature, but that it gets complicated to explain as it involves tahoe terminology
20:28:53	zooko:	Also the original publisher can't create two immutables with the same URL pointing to them (collidiing).
20:28:55	adam3us:	zooko: thats one way. cant argue with full hash-collisions
20:29:01	zooko:	(For that we rely on the collision-resistance of SHA256.)_
20:29:56	zooko:	* zooko looks for good summary docs about LAFS's file semantics.
20:31:42	zooko:	Here's the two-sentence version: https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/about.rst#access-control
20:33:31	zooko:	Here are more details: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Capabilities
20:39:13	gmaxwell:	stephenreed: Yes, bitcoin is ugly in many ways. I spent a decade working for a company building huge routers for internet backbones and working with big providers... I'm well familar with big communications infrastructure. Bitcoin uses non-scalable mechnimes in a way which "can't work" to achieve an end— an anonymous decenteralized consensus— which "isn't possible" by conventional thinking. In practice, so far, it does work. ...
20:39:19	gmaxwell:	... And I'd love to see something that achieved the same ends, but wishing it doesn't make it so... The uglyness in Bitcoin is not an accident, not a result of ignorance... the problem space truly is hard.
20:42:19	cbeams:	zooko: anyone on or around the Tahoe-LAFS team done a comparison with Maidsafe and the other distributed datastore contenders? I see the names mentioned together in a few places, but haven't yet seen something detailed.
20:44:11	gmaxwell:	At one point I wrote long winded essays that what bitcoin achieves— a decenteralized consensus— was precluded by physical law. I was wrong, because I didn't consider the right relaxations of the requirements (the the consensus could be eventual and only so under certian economic assumptions, that a vote could be sufficiently sybil resources through the provable expendature of physically finite resources and at the same time ...
20:44:17	gmaxwell:	... create the incentives the first required). There might be similar alterations of the assumptions or requirements that yield alternative solutions. I certantly hope so. But I'd expect the presentation any successful attempt to start with a very clear statement of what the assumptions and limitations are, and how it addresses the hard problems that arise in this space.
20:47:12	gmaxwell:	(well to be clear, I'm already aware of some different designs with different assumptions— e.g. there are some proposals which achieve awesome properties— fast, secure, and scalable— that depend on a simple majority of non-anonymous signing registrars being honest. E.g. the compromise decenteralization to get basically every other property you could ask for)
20:47:44	stephenreed:	adam3us: I saw the link to Chris' paper on the dev mail list, read it, and asked him for permission to use it as a reference in my paper. He gave it.
20:50:51	gmaxwell:	adam3us: Amiller, jbonneau and others have been working on a systemizing bitcoin knoweldge paper: https://github.com/citp/bitcoin-sok
20:51:30	gmaxwell:	(I'd held off nagging people to review and contribute because it had gone some months without an update; but it seems to have had updates recently)
20:51:59	amiller:	you're welcome to direct all complaints to me about updates lagging a while, sorry!
20:52:42	amiller:	i'm going to spend a lot more time on it in the next month or so
20:53:01	gmaxwell:	amiller: well I said I'd review it and such but had been holding off because it hadn't been updated. I don't mind the lag, but I will ask that when you update it and think it could use some eyes, please prod me (+ the channel, or I'll prod the channel)
20:53:17	amiller:	understood! :)
20:53:37	amiller:	the current backlog is to process a bunch of merge requests from sdlerner
20:56:36	stephenreed:	gmaxwell: this is a key paper that I referenced - http://iris.csail.mit.edu/irisbib/papers/aaom:sosp21/paper.pdf Attested Append-Only Memory: Making Adversaries Stick to their Word, Chun et al. Their math says it is byzantine fault tolerant with respect to relicas less than 50% faulty. Then I use timeline entanglement to make the logs tamper-evident. Also a reference from my paper.
20:57:29	stephenreed:	gmaxwell: Nick Szabo explained the benefit of unforgeable logs as you probably alreadky know.
20:58:35	gmaxwell:	stephenreed: I believe I've read this before? Will check... but generally the problem the clasical approaches have is they do not work in the model of anonymous membership. You have have agreed in advance the identity of the members of the participants in the system. (and have some method to be confident that they are not mostly sybils of a single party)
20:58:59	stephenreed:	gmaxwell: given your network architecture experience, superior to my own, would you say that such a network could indeed handle all the world's transactions?
21:00:02	stephenreed:	gmaxwell: in my system the peers provide a controlled bitcoin address both for identity and for signing their non-transaction messages. That is the audit trail peers can easily verify.
21:00:26	gmaxwell:	stephenreed: Bitcoin the payment network? of course not, but it doesn't need to for bitcoin the currency to handle all the worlds transactions (if the world wished it so). With a sold, throughly secure and decenteralized base we can run additional payment systems on top of bitcoin to achieve additional features and scale.
21:00:26	stephenreed:	gmaxwell: Sybils are prevented by the need to sufficient stake them.
21:02:30	stephenreed:	gmaxwell: I mean is the super peer network truly capable of handling all the worlds transactions? I think so based on what I read about VisaNet and SwiftNet.
21:03:09	gmaxwell:	stephenreed: If the identity is a propery inside the system how do you prevent simulation? An example of simulation attacks: past participants leave the system, someone obtains their keys, recovers a snapshot from when they were still a quorum, then plays forward creating a new alternative history. A new entrant joins the system, he can tell that someone cheated (by the conflicting signatures) but how can he distinguish which state ...
21:03:15	gmaxwell:	... is the 'real one'?
21:04:17	stephenreed:	gmaxwell: the point is weakened if the peer behaves correctly. A thief to the original owner - but that is same in the current system with regard to hacking a hot wallet.
21:05:00	andytoshi:	stephenreed: the problem is that you have humans determining which transactions go where, so there is no canonical "behaves correctly" in this case
21:05:13	stephenreed:	The orginal history was created by a very carefully single nomadic mint. Did you get that point? All full nodes replicate the single version blockchain.
21:05:14	gmaxwell:	Those thefts happen all the time, even when there is something significant at stake— in my example though they keys could be stolen after the peer has no involvement with bitcoin at all and will lose nothing in an attack (and in fact, may gain handsomly by facilitating an attack)
21:06:03	stephenreed:	gmaxwell: created by a very carefully watched single nomadic mint agent ...
21:06:17	gmaxwell:	stephenreed: I'm not sure I follow your question wrt super peer network. My own prior comment was that I believe the bitcoin ecosystem in total would be able to handle all the worlds transactions, if we wished it to.
21:06:31	adam3us:	gmaxwell: i think the scale question should be with the caveat that to interestingly scale, the main bitcoin properties should still be available to all users (unseizable, unfreezable, user control) for that to be an interesting scaling architecture. its less interesting if we have a $100k min transaction clearing network with unseizability for them, but trust me for users. (less but still interesting, viz international banking freezes and spats)
21:07:18	stephenreed:	gmaxwell: Indeed a mesh network could have preferred connections and that is how I intend to modify the core to become a super peer network.
21:07:38	jgarzik:	noooo
21:07:43	andytoshi:	stephenreed: to a newcomer, the original history and a forked history may be indistinguishable as far as legitimacy goes. it's hard to verify things like "carefully watched" even if you are forcing your superpeers to basically be visible economic entities (since they need so much space and bandwidth)
21:07:46	gmaxwell:	stephenreed: There are a great many things you can do if you have a centeral point of trust. And lots of ways to achieve audiability where misconduct of that agent is visible... Thats a viable approach but _very_ philosophically different from Bitcoin, because that agent is still trusted. (I wonder if you've seen the original p2pfoundation announcement of bitcoin? http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source )
21:07:55	jgarzik:	somebody else proposed a super node network at the AMS conference
21:08:56	jgarzik:	how many variants of "but, if we just TRUST these guys over here a little bit more" do we need?
21:08:57	stephenreed:	jgarzik: my ideas are not new. The super peer idea evolved out of the p2p stuff back when Satoshi was looking at napster.
21:09:58	stephenreed:	gmaxwell: My software agents are trustless as Szabo suggests. The unforgeable log enables peers to validate.
21:10:55	stephenreed:	jgarzik: Super peers have superior network/server capability but run the same code base.
21:11:45	jgarzik:	same code base or not is immaterial
21:12:07	stephenreed:	andytoshi: yes visible so that cooperation is assumed but cheating quickly detected. The network reengineering can easily handle the increased traffic - point to point, not mesh.
21:12:41	andytoshi:	detecting cheating is easy, determining who is/isn't cheating is not
21:12:45	andytoshi:	stephenreed: even if you get trustless software agents (e.g. by auditing their behavior or somehow TPM-verifying that they are clean VMs running only your software) you still have (a) random coins, e.g. for peer selection, and (b) user decisions, e.g. transactions, which are inputs from the real world and therefore can be used to introduce distortions and/or forks
21:12:56	stephenreed:	jgarzik: material because tamper-evident logs record every action, inputs and outputs of a peer.
21:13:39	stephenreed:	andytoshi: that point addressed in the paper linked above - less than 50% faulty agents can be tolerated.
21:13:48	adam3us:	stephenreed: how can i audit a network entities tamper-evident logs? TPM remote attestation?
21:14:15	jgarzik:	andytoshi, indeed. And RE detecting cheating, Sybil'd views can make you particularly vulnerable
21:15:21	stephenreed:	adam3us: yes, but I omitted TPM attestation from the paper because current implementations are too proprietary. I want a TPM enabled stack that says your current release of bitcoind is running and nothing else - no keyloggers etc.
21:16:48	stephenreed:	adam3us: here is the paper on TPM attestation that I studied - http://www.mysmu.edu/faculty/xhding/publications/stc08.pdf
21:17:24	Guest89031:	Guest89031 is now known as roidster
21:17:50	gmaxwell:	stephenreed: These are all neat technologies that we've talked about in here and ought to exist as part of the greater bitcoin ecosystem... but they are really not a replacement for what Bitcoin provides. E.g. the TPM hardware maker can trivially compromise those systems.
21:17:59	stephenreed:	adam3us: For TPM I was looking at a bare metal implementation not a hypervisor.
21:18:43	gmaxwell:	(I happen to have an IBM cryptocard myself— which is basically the pinnical of remote attest technology right now— ... and I've been playing around with the nexus operating system, which is a hypervisory OS that facilitates remote attest)
21:18:52	stephenreed:	gmaxwell: right about TPM. I understand you need a license to use it in China for example. So remote attestation of unforgeable logs per Szablo works too.
21:20:07	stephenreed:	gmaxwell: They are not a replacement for proof-of-work. They are a replacement that preserves the Satoshi Social Contract between developers and users. My ideas are half-baked now. The code to be written will speak for itself.
21:21:03	gmaxwell:	Traditional reserve currencies are backed by power and authority of natition states— entities with the power to extinguish all life on earth (well, at least all human life)— and yet they do not behave in a way that many people consider trustworthy— they are rules by politics and personalities not by Law. Some of them have apparently strong social contracts, and yet they do not prevent mission drift.
21:21:31	gmaxwell:	Well I look forward to seeing some neat stuff!
21:21:35	stephenreed:	I wish the Barcelona test harness was done. I need to orchestrate lots of peers to meet your challenges.
21:21:42	gmaxwell:	(don't take my cycnism for dislike)
21:22:19	stephenreed:	gmaxwell: according to Gavin's videos you are the core developer that I need to convince first - Thanks and wait for code.
21:24:31	stephenreed:	Thanks for observing while I write the code of a lifetime.
21:25:41	adam3us:	stephenreed: i would encourage generally to explain algo before coding it because its many orders of magnitude faster to explain an algo than to code it; that way you get feedback early if there are problems that'd need a rewrite
21:26:36	gmaxwell:	Right well in particular make sure the high level objectives of the algorithim are clear before the details. It's a lot of work to sort out the limitations in the architecture of an idea starting at the 'molecular level'.
21:30:08	jgarzik:	Yes, gmaxwell is the gateway to a new universe ;p
21:31:36	gmaxwell:	Hopefully not in the sense of some volcano-involving rital sacrifice.
21:43:13	gmaxwell:	In other news, the bytecoin-derrived cryptocurrencies ecosystem is now using merged mining, there is now a fork that is merged mined against and of the 3 (or more?) prior bytecoin-derrived cryptocurrencies. (this isn't super news its a few weeks old, but its news to me)
21:43:47	stephenreed:	adam3us: After making or reusing a test harness, the first bit of work is the tamper evident log, which should be easy to document since I will look closely at the current debug log of bitcoind. The step beyond that would be timeline entanglement which makes the logs tamper-evident. I need to be able to digitally sign a peers log. The functions I need should already be in the core, provided I can capture the key p
21:43:47	stephenreed:	air somehow.
21:44:27	sipa:	"the keypair", which?
21:47:01	stephenreed:	sipa: If you have been following the conversation, then Szabo style unforgeable logs can be created if peers sign each others logs. I propose for a peer operating a full node to provide a key pair for that purpose, e.g. a bitcoin address public/private key pair.
21:47:51	sipa:	you say "capture the keypair somehow" -> which keypair?
21:49:16	gmaxwell:	stephenreed: in bitcoin the blockchain itself is the unforgable log, but because the system is anonymous (there are no enumerated identities) they are signed via cumulative proof of work instead of a traditional digital signature. Debug.log is orthorgonal, it's just for software QA, and very little of it is about information which is interesting to other parties.
21:51:00	stephenreed:	sipa: Well the QT wallet securely stores private keys so I suppose I would reuse that method.
21:51:09	sipa:	nodes have nothing to do with wallets
21:51:25	sipa:	it's a historical accident that satoshi's software does both
21:51:46	gmaxwell:	stephenreed: normally bitcoin keys in wallets are intended to be single use, one transaction. As sipa notes we've been slowy working towards seperating the functionality.
21:54:25	stephenreed:	separation is great. My purposes require that a peer sign another peers log to make it tamper-evident. I need for the node operator to provide the private key to bitcoind. The wallet has a method to input and securely store private keys. I may need the wallet in order to received daily dividends from the "reward agent".
21:54:50	sipa:	sounds like you just need something like a host key
21:54:58	sipa:	independent of the wallet
21:55:05	stephenreed:	sipa: how would you store it?
21:55:15	sipa:	oh, you also use it to receive coins?
21:55:48	stephenreed:	sipa: I need to receive bitcoins yes but that may be orthogonal
21:56:06	sipa:	you get rewards for running a full node?
21:56:55	stephenreed:	sipa: I hope that you will read my whitepaper ... https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE
21:57:20	andytoshi:	sipa: as i understand it, that is part of stephenreed's proposal because he has mechanisms by which peers enter and leave the system (which include proving some amount of dedicated resources as a sybil prevention)
21:58:06	stephenreed:	sipa: I also have a good set of extended references on the bitcointalk thread OP - https://bitcointalk.org/index.php?topic=584719.0
21:58:40	andytoshi:	stephenreed: you want to separate bitcoin addresses from authentication, you can attach addresses (for receiving funds) to your ID by signing them with your auth key, but because addresses are supposed to be ephemeral they are not well-suited to auth on their own
22:00:07	stephenreed:	sipa: The whitepaper describes - a proof-of-stake version which uses a single nomadic verifiable mint agent and distributed replication of a single blockchain by compensated full nodes to achieve 6-hop, sub-second transaction acknowledgement times. Plus it pays dividends to holders instead of paying miners. Subsidized transaction fees are thus lower.
22:00:25	sipa:	sounds like a very different trust model than bitcoin
22:01:03	sipa:	(which is not a bad thing, but suggesting it as a replacement seems strange)
22:01:35	stephenreed:	sipa: a different trustless model yes. Cooperate to save effort, and verify peers to ban cheaters.
22:02:29	sipa:	bitcoin isn't fully trustless, and neither is this :)
22:03:44	stephenreed:	andytoshi: I will note your comment.
22:05:37	stephenreed:	andytoshi: compared to todays bitcoin, I strongly desire permanent full nodes and would allocate sufficient reward to them to make that happen. SPV nodes can come and go.
22:07:49	andytoshi:	i guess you mean quasi-permanent, like tor, and that's another hard problem (though i don't believe it's impossible) to incentivize in a sybil-resistant way
22:09:03	stephenreed:	andytoshi: You must think that there is a hard problem that I am missing. I appears simple to me to keep track of peer uptime. I would create another agent to perform that duty.
22:09:55	andytoshi:	stephenreed: the hard problem is getting people to stay up when it's costing them resources and maintenance
22:11:03	stephenreed:	andytoshi: the peer would be identified by IP address and offered public bitcoin address. I would pay them to stay up. The current reward is $1.6 million per day divided by say 10000 full nodes!
22:11:40	andytoshi:	right, but it's easy to farm IP addresses and route them to a single box, it's hard to prove that every IP corresponds to disparate physical resources
22:12:42	stephenreed:	andytoshi: That is true of the current system where full nodes are hosted for $19 per month in a data center sharing a portion of some server. Replication of the blockchain is very important.
22:13:47	andytoshi:	it's true but why would anyone bother? it doesn't improve the decentralization or value of the network (which is the only incentive to run a full node today, besides goodwill and geek cred, which are also not helped by standing up sybils)
22:13:56	stephenreed:	andytoshi: Identity is supported by the controlled bitcoin address offered by each full node. The more stake, then more likely they are to be Sybil resistant.
22:14:56	stephenreed:	andytoshi: If there was a way for a software probe to determine, and to ensure, dispersed geographical locations - then I would use that.
22:17:40	andytoshi:	we had a recent discussion on ##crypto (or was it here?) about cryptographic proof of location, and i think we landed on "it's probably impossible" at least on earth since attackers can use fast airborne radio waves while honest parties have to use slow quantum signals in fiber optics
22:18:25	andytoshi:	regarding sybil resistance, if i have a lot of stake i'll get more reward but that still doesn't incentivize me to start more physical nodes. i'll open as many fake ones as my stake allows
22:18:53	andytoshi:	if anything using stake as a gatekeeping mechanism will cause your system to tend to oligarchy
22:19:42	stephenreed:	andytoshi: have to go, but I think online wallet hosting will be the largest stake holders.
22:21:22	andytoshi:	alright, ttyl, but as sipa says this is a large philosophical shift away from bitcoin
22:26:04	maaku:	gmaxwell adam3us: i would be very interested in a generic schnorr + brands + ring signature primitive
22:26:27	maaku:	if anyone has done work on or can summarize how such a system would work, i might be able to make it happen
22:27:44	nsh:	(andytoshi, i still think proof-of-location is possible, but it requires some special-sauce from e.g. GPSsats or moonmath)
22:28:04	nsh:	(and bounded-storage-type assumptions)
22:28:42	maaku:	or significant relativistic distances
22:28:51	nsh:	mmm
22:29:34	gmaxwell:	maaku: The bytecoin paper shows a schnorr like EC ring signature. The signature itself is nothing special. if libsecp256k1 had a schnorr signature (e.g. signing which took a hash function) it would probably only take an hour to add the bytecoin style signatures to it.
22:30:03	maaku:	you expressed reservations with what bytecoin was doing however?
22:31:09	gmaxwell:	hm? I mean the non-ring signature stuff is all altcoin derpy. The ring signature seems fine. I have not worked through the algebra to decide if I'm concerned about the snazzy thing they do for double spending is okay or not.
22:32:34	gmaxwell:	maaku: "significant relativistic distances" would be bitcoin in Strouss' Neptune's Brood.
22:35:01	zooko:	Too bad cbeams isn't connected now, because he asked about comparing Tahoe-LAFS to Maidsafe.
22:35:24	zooko:	But my answer is that I don't understand much about Maidsafe, and does anyone have a nice specific and succinct document about Maidsafe's technical design?
22:36:05	nsh:	Maidsafe doesn't understand much about Maidsafe
22:36:35	nsh:	no technical paper last i checked
22:37:30	gmaxwell:	there was kinda of a glossy marketing sheet that had a long list of features and technical jargon. Some of the features sounded likely impossible to me, which happens— but its usually a bad sign when the speaker doesn't seem to even think that they're hard problems. :)
22:40:03	zooko:	nsh: thanks.
22:40:06	zooko:	gmaxwell: thanks.
22:40:40	zooko:	I was rather reeling when I learned that they'd taken in $5M in their crowdfunding campaign.
22:41:15	maaku:	zooko: most of that was mastercoins
22:41:33	maaku:	i'm not sure that really counts when it greatly exceeds the entire market depth
22:42:05	zooko:	maaku: hm? Maybe I took something I shouldn't have at face value.
22:42:11	nsh:	you mean the mastercoin may be uncollateralised or something?
22:42:29	zooko:	So, a lot mastercoin got given to the Maidsafe folks in return for Maidsafecoins?
22:42:37	maaku:	zooko: yes
22:42:39	zooko:	Ah, thanks.
22:42:44	kanzure:	i was not impressed by maidsafe's response to my proposed attack (basically, sybil + collusion with others to route queries to just one copy of the file, gain large amount of their coins/tokens)
22:42:57	zooko:	I have a lot more sympathy, nowadays, for people who read shallowly and miss a lot of details and nuance... :-/
22:43:19	zooko:	Howdy, kanzure. I met you in the aaronsw IRC channel about a year ago I guess.
22:43:36	nsh:	* nsh smiles
22:43:56	kanzure:	we met 2013-02-13, but i think we interacted earlier
22:44:16	kanzure:	or, i would be disappointed if it was really 2013-02-13, because i've seen you around for longer than that..
22:45:08	zooko:	Heh heh.
22:45:14	zooko:	Oh, cbeams *hadn't* disconnected. Oh well.
22:45:26	kanzure:	gmaxwell: cost of proving crazy bitcoin-related proposals wrong is lower than the possible reward of attacking a bad system once it's deployed and worth actual money. plus, attacking proposals doesn't always stop someone from implementing a terrible idea. this means a lot of terrible things are going to happen, i think.
22:46:06	maaku:	*a lot of terrible things have already happened
22:46:10	maaku:	fixed that for you
22:46:10	kanzure:	actually, one possible reward for preventing terrible ideas is that it might potentially stop resources flowing into terrible ideas, and reserve them for better ideas, but that's more of a temporary sort of reserve..
22:47:01	gmaxwell:	kanzure: that is kind of thinking is something that matters to me— or even more abstractly: ... too much junk might make the entire field less interesting to people.
22:47:19	kanzure:	i would like it if "there are many things that are possible if you relax the constraints to bitcoin, including centralized trust stuff" became a more common respones to most proposals etc
22:47:39	gmaxwell:	The challenge however is that the kind of marketing required to hype something up from a technical perspective is basically obfscuation that maximizes the review cost.
22:48:04	gmaxwell:	I guess maidsafe has published more details if you were actually able to present an attack— what I saw was too vague to even respond to.
22:48:05	zooko:	gmaxwell: I actually have the opposite emotional bias: the chaos, cacophony, and crime make a great bed of bullshit in which new ideas can grow.
22:48:15	kanzure:	what if you auto-generated dud ideas with maximal review cost, just to keep people trapped, but you're in control of the crap so that you can redirect people to more useful ideas
22:48:22	gmaxwell:	zooko: I think there is probably some optimal point of interest.
22:48:28	zooko:	* zooko nods.
22:48:47	gmaxwell:	kanzure: you could call it "coingen.io"
22:49:24	kanzure:	oh, has that taken up a lot of the volume? i haven't checked
22:49:43	gmaxwell:	(which very much was created with making the supply of totally trivial altcoins _infinite_ in order to wear out that space and send people off on more useful ventures)
22:49:45	kanzure:	s/volume/traffic
22:50:04	kanzure:	hm, but the problem isn't going to be just altcoins, but all sorts of poorly considered crypto-whatzits
22:50:04	gmaxwell:	er created with the goal of*
22:50:21	kanzure:	i'm okay with poorly implemented cryptosystems, but i'm not okay with wasting everyone's time
22:50:41	kanzure:	your poorly implemented cryptosystem can sit in a .tar.gz somewhere for all i care
22:50:48	gmaxwell:	sure well in general, the altcoins are highly visible because they have a braindead monetization model, which encourages lots of interest there even in totally pointless ones.
22:51:36	gmaxwell:	Basically cryptocoins have broken the old truce that most thoughtful people didn't inflict speculative cryptosystems on the public without a darn good need and a lot of review... because it seems to have made a way of turning a profit from inflicting bad cryptography on people.
22:51:52	gmaxwell:	Or at least people think they'll earn a profit, how sustainable that is remains to be seen.
22:52:46	zooko:	Bye for now, wizards!
22:53:41	kanzure:	i've deflected a number of "just use a blockchain" ideas with "well, there are other architectures that are relevant here" and it makes me look uncooperative, heh
22:55:10	kanzure:	is there a market-based solution to the problem of independent review? what about an auditor model, where projects raise funds to hire auditors first, and then auditors have a reputation in cryptosystem design stuff.
22:56:11	kanzure:	hmm that would have the same problem that current credit agencies have (specifically, you pay them and they give you whatever rating you ask for)
22:57:04	maaku:	involving money in any way is very likely to decrease quality
22:58:59	pigeons:	yeah there are firms doing "security" code auditing and a big issue is lazy auditors can make a lot of money and reputation for years before the incentives and opportunities to prove them wrong pan out, and by that time the damage is done and they've moved on
23:00:12	gmaxwell:	in business in general you just have a sybil attack problem, where the market rewards those who rush in. The incompetent ones fail, eventually, but there is an endless supply of more fools.
23:07:23	gmaxwell:	Death and taxes is kicking butt and taking names on the forum today: https://bitcointalk.org/index.php?topic=609457.msg6839195#msg6839195
23:20:05	andytoshi:	i love that guy. i keep meaning to message him with a "you are going to burn out" warning
23:21:48	nsh:	goodplan
23:22:17	nsh:	i wonder if the bitcoin community would have more... something if it were nominally wrapped around a wiki, rather than an awful forum
23:22:39	nsh:	then there could be wikiholidays and all that other cultural stuff
23:22:49	gmaxwell:	Funny you say that, I did that last week. He and someone else were doing a saints job correcting misinformation on some POS thread, and I sent a message thanking them and pointing out that they were probably expirencing xkcd-386 and suggesting they just let the debate die.