01:23:05	c0rw1n_:	c0rw1n_ is now known as c0rw1n
01:40:04	kanzure_:	kanzure_ is now known as kanzure
07:55:15	OneFixt_:	OneFixt_ is now known as OneFixt
10:52:31	wallet421:	wallet421 is now known as wallet42
10:54:42	OneFixt_:	OneFixt_ is now known as OneFixt
11:11:15	fanquake:	fanquake has left #bitcoin-wizards
12:19:14	HM:	Suppose I had something I had encrypted, and I wanted it to be decryptable by someone at some point within the next 10 years, could be tomorrow but upperbound almost guaranteed. Without putting anything in to the blockchain, is there anyway to utilise the hashing power of the network to achieve that?
12:20:07	HM:	The idea would be, the bitcoin network having more hashing power than most self-funded crackers, the secret would become known to a broad audience all at once, essentially equal access
12:22:15	HM:	just a thought i had doing some dishes
12:29:53	e4xit:	I guess you encrypt it using a randomly generated password of a set length/difficulty for the algorithm chosen to encrypt it, so that it will intersect with predicted computing power at a certain point in time...
12:30:46	HM:	right, but you can't actually use the computing power of the network for arbitrary sha256 hashing
12:31:39	HM:	i don't think its possible myself
12:32:29	e4xit:	oh i just thought you meant that "at time 'x' in the future, 'someone' will have a computer powerful enough to brute force encryption of 'y' difficulty"
12:32:48	HM:	nah that would be easy
12:32:48	e4xit:	it sounds like you would need an alt coin
12:33:46	e4xit:	there are coins which search for prime numbers and proteins and such
12:36:20	HM:	right, but that defeats the point ;) you'd have to get everyone using it and there's no incentive except the public good. the idea was an ancillary use to the existing cpu cycles being burned
12:36:33	HM:	I can't see how the current pow can be useful though
12:43:50	edulix:	edulix is now known as eduli
12:43:51	eduli:	eduli is now known as edulix
15:29:05	tacotime_:	tacotime_ is now known as tt_away
16:09:09	Emcy_:	Participating nodes would sample RF noise on some agreed band(s) being
16:09:09	Emcy_:	emitted by the Sun and continually record it, with their sampling clock
16:09:09	Emcy_:	being driven by their stable local oscillator. Nodes would then publish
16:09:09	Emcy_:	timestamped recent fragments of this signal.
16:09:37	Emcy_:	would this require nodes to know precisely their own postion on the surface of the earth
16:10:25	Emcy_:	cos a node at midday is about an earth radius closer to the sun asd one at dawn or dusk
16:35:06	coryfields:	coryfields is now known as cfields
16:59:24	maaku_:	Emcy_: plus atmospheric effects which may have larger effects
17:00:06	Emcy_:	i dont think even gps accounts for that
17:00:27	maaku_:	HM: gmaxwell has explored that idea of having (breaking) timelock encryption as the proof of work
17:01:28	maaku_:	Emcy_: good ones do, as it is a significant enough source of noise
17:02:17	maaku_:	although the situation is a little different there as there are multiple sources at different vectors
17:02:59	maaku_:	hrm can't seem to find a reference for the speed of light in atmosphere
17:03:08	Emcy_:	what exactly radio emissions does the sun give off that is good as a reference signal any way
17:03:10	maaku_:	obviously would depend on altitude too
17:03:32	maaku_:	Emcy_: random EM noise in just about every spectrum
17:03:41	Emcy_:	yeah but its random
17:04:06	maaku_:	that's exactly the point...
17:04:07	maaku_:	otherwise it could be predicted
17:04:16	maaku_:	the point is to provide a truly random oracle/beacon
17:04:31	Emcy_:	oh yeah
17:04:32	maaku_:	for which you can get global consensus
17:05:05	Emcy_:	i wonder is the albedo of the moon is good enough in those spectrums to work at night too
17:05:31	maaku_:	so besides accurate time consensus, you could do things like, say, have a source of randomness available to smart contracts
17:06:05	maaku_:	yeah, it is, but that's why you have to be careful about choosing the right spectra
17:07:06	maaku_:	i remember seeing a poster at one of the lunar science conferences about the amzing reflection properties of the moon in various spectra
17:07:12	maaku_:	wish i had a cite for it right now :(
17:08:29	maaku_:	but of course there are times neither the moon nor the sun are available
17:08:58	Emcy_:	cant the NSa just rock up and beam a few kw at your computer and fuck this scheme up
17:09:06	maaku_:	then you can use any large metallic satellite (ISS would be great, or some of the older GEO birds)
17:09:47	Emcy_:	well they can rocl up and shoot you i suppose so meh.
18:07:04	licnep_:	licnep_ is now known as licnep
19:31:24	gmaxwell:	"If you're around, would you have any idea why Zeitcoin would be stuck at block 500 for the entire network?" < (I bet half of you instantly make the same guess I made)
19:44:09	andytoshi:	block reward so high that something overflowed?
19:45:01	sipa:	block 500... that sounds like the getblocks limit
19:45:09	michagogo|cloud:	* michagogo|cloud checks checkpoints.cpp
19:45:30	michagogo|cloud:	nah
19:45:53	pigeons:	cause no one bothers to mine it
19:46:04	gmaxwell:	yea, I was assuming they forked code with a checkpoint at 500.
19:46:21	gmaxwell:	so michagogo|cloud gets the point for the same guess as me. (Dunno what their actual issue was)
19:46:22	andytoshi:	oh :P much simpler
19:46:37	sipa:	well, bitcoin doesn't have a checkpoint at 500
19:46:46	sipa:	but maybe they forked something else
19:46:51	andytoshi:	they use scrypt, probably they forked doge or osmething
19:46:51	michagogo|cloud:	sipa: Yeah, hence 21:45:30 nah
19:46:53	michagogo|cloud:	Ah, maybe
19:47:09	michagogo|cloud:	Do any other coins have a checkpoint at 500? o_O
19:47:41	gmaxwell:	testnet does IIRC.
19:47:55	gmaxwell:	oh these guys forked ppcoin
19:48:08	gmaxwell:	so actually their issue is probably that they aren't broadcasting checkpoints.
19:48:33	michagogo|cloud:	Uh, broadcasting checkpoints?
19:48:38	michagogo|cloud:	Wtf?
19:48:48	gmaxwell:	yep. exactly. hurray for ppcoin.
19:49:04	jcorgan:	consider it evolution in action
19:49:07	michagogo|cloud:	...wait, what?
19:49:09	michagogo|cloud:	Seriously?
19:49:19	gmaxwell:	michagogo|cloud: they hijacked the alert mechenism so that the developer has a key to broadcast checkpoints. Seriously. Most of the users don't even know it.
19:49:19	michagogo|cloud:	They... broadcast checkpoints?
19:49:25	michagogo|cloud:	How does that work?
19:49:30	michagogo|cloud:	uh.
19:49:30	gmaxwell:	The system stops working if the developer stops for >1 week.
19:49:41	nsh:	lol
19:49:57	michagogo|cloud:	http://itcafe.hu/dl/upc/2014-01/452339_95209a691a593b232722112a5fff265c.png
19:50:44	sipa:	hurray for decentralozation
19:50:59	gmaxwell:	michagogo|cloud: To be fair there are at least some limitations on it, the a node won't take a replacement at or below a height it already has one. So they can't conduct free reorgs, only one shot reorgs, and 'only' can reorg a week of blocks — or they can forever split the network.
19:51:16	gmaxwell:	(I am obviously not arguing that it isn't loltastic horrible)
19:51:19	andytoshi:	zeit is hilarious, 30 second blocks and difficulty retargets every blocks, block reward is 1mil
19:51:36	gmaxwell:	Worse, when you criticize peercoin's stuff here you get piled on by people saying bitcoin has the same thing. :(
19:51:45	michagogo|cloud:	heh
19:52:01	michagogo|cloud:	Are people really that dumb?
19:52:05	gmaxwell:	Yes.
19:52:07	Emcy_:	why would someone set retarget to every block
19:52:20	michagogo|cloud:	Emcy_: ikr
19:52:24	jcorgan:	http://i.imgur.com/uyVdb3w.jpg
19:52:25	pigeons:	same thin meaning the developer provided checkpoints?
19:52:33	gmaxwell:	Emcy_: because they like isolation attacks? and weird incentives to lie about the time?
19:52:36	michagogo|cloud:	pigeons: I think so, yeah
19:52:57	gmaxwell:	pigeons: who knows what they _mean_, but they dismiss this as being a criticial flaw.
19:52:57	Emcy_:	why do people fork coins at look at its fundamental parameters and just say "yeah lets just make all this faster"
19:53:12	andytoshi:	because they haven't read alts.pdf
19:53:15	gmaxwell:	Emcy_: shed painting.
19:53:17	andytoshi:	and because alts.pdf is not done :(
19:53:32	Emcy_:	shed painting?
19:54:00	gmaxwell:	Emcy_: http://bikeshed.com/
19:55:02	Emcy_:	bikeshed is a metaphor for....software development
19:55:05	Emcy_:	nerds
19:55:45	gmaxwell:	it's not just software development, it arises everywhere in engineering and design. People nitpitch the minutia because its the minutia they (think they) understand.
19:55:52	midnightmagic:	arguing at length about minor seemingly cosmetic details which have no basis in effectively pushing the state of the software forward, but mean an irrational lot to the people arguing about them.
19:55:58	Emcy_:	oh there was something about bikesheds on tha tmaximum tinfoil video with the swedish guy
19:55:59	Emcy_:	i remember
19:56:47	gmaxwell:	most people touching these altcoins have nary an idea how this stuff works, but some of these parameters like block times are figures users are all familar with and understand at least one effect of.
19:56:56	andytoshi:	it's weird here, it's not a normal bikeshed because they somehow do a -lot- of damage with these "trivial" changes
19:57:10	Emcy_:	midnightmagic why not jsut say politics. That word is still enough of a derogatory term to carry the meaning
19:57:17	andytoshi:	like if you said, "i want to paint the shed with radium so that it'll glow"
19:58:07	Emcy_:	heh
19:58:10	sipa:	give N people X amount of time to decide Y
19:58:27	gmaxwell:	andytoshi: well they mistake this stuff as color which has no other effects, but by paiting the shed black it gets too hot and the equipment inside all fails. The shed had to be white or near white for non-aesthetic engineering reasons.
19:58:30	sipa:	independent of N and Y, they will use X time to discuss
19:59:14	Emcy_:	andytoshi most of these alts have no intention of lasting a decent amount of time. Nakamoto chain currencies can be really, really pyramidy in the wrong hands
20:00:11	jcorgan:	it is rather telling that all of them "cash out" by getting the coin adopted on a crypto exchange and then trading with a greater fool for bitcoin
20:00:31	Emcy_:	gmaxwell we must calculate the exact shade of white to maintain an optimal operating temerature for the quipment inside a maximal amount of the time
20:00:51	Emcy_:	ill look up solar forecasts for the next ten years, you look up manufacturer infomation
20:18:09	antephialtic:	gmaxwell: since they retarget difficulty every block, could someone with a lot of hashpower essentially freeze the network by mining for a few blocks, then stopping, so the difficulty was left so high that the network would take way too long to mine a block without them? (regarding your previous question about Zeitcoin)
20:19:18	gmaxwell:	antephialtic: presumably they have a maximum change per block, if so that also means there is a nasty non-linearity in their difficulty change rules where you can earn more by mining in bursts (and riding against the rail).
20:19:39	gmaxwell:	(bitcoin has such a non-linearity, but it's do hard to hit— and never been hit on the network— that it doesn't matter)
20:20:01	gmaxwell:	s/do/so/
20:20:40	antephialtic:	yeah, if you had enough hashpower to do it with bitcoin, you probably would have enough to just do some double spends or selfish mine anyway
20:22:39	gmaxwell:	since it starts getting into miner incentives stuff it's hard to analyize, so I dunno how bad it really is... still— something I'd avoid.
20:35:26	nsh_:	nsh_ is now known as nsh
21:11:12	HM:	I'm finally getting Stefan brands blind signature scheme
21:11:22	HM:	i also rediscovered the page that i first read it on
21:11:48	HM:	which is nice
21:11:49	HM:	http://webcache.googleusercontent.com/search?q=cache:http://www.orlingrabbe.com/stefbrdc.htm&ie=utf-8&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&channel=sb&gws_rd=cr&ei=SvcRU8T2F6m62AWZ8YGgBA
21:12:21	HM:	It's taken me ages to boil down the concept
21:12:41	HM:	(rather than just follow the algebra, which isn't enlightening)
21:16:20	nsh:	can you synopsise?
21:17:30	HM:	not yet ;)
21:18:21	midnightmagic:	ehh.. I hate to ask here, but is there a summary document somewhere which describes in salient, short points all altcoins that have been analyzed by.. well anybody reputable anyway that can be used as a reference somewhere?
21:21:22	nsh:	no, but i'm sure there's something from the 18th century about the merits of buying tinctures and cure-alls from people in three-dollar suits on the back of touring wagons
21:21:32	nsh:	that might be still appropriate
21:23:43	HM:	nsh, the critical point seems to be using a DSA like construct to prove the result of a exponentiation is as promised
21:24:14	rdymac_:	rdymac_ is now known as rdymac
21:24:15	nsh:	HM, hmm, thanks. will investigate :)
21:24:39	comboy:	oh I want to join alt questions, is proof of stake actually proven to work? assuming most coins are in hands of rational actors that don't want to destroy the currency but are optimizing for personal profit? because I still don't know answer to that
21:24:39	HM:	nsh, so the bank has a secret for the withdrawal, w, and a secret key x. It returns xM and wM where M is an EC point (well it would be in EC terms)
21:25:09	HM:	normally you can't prove anything about those values
21:25:29	nsh:	right, a second spend fixes the line equation revealing the secret
21:25:41	HM:	but you combine them algebraicly and challenge the bank to prove it did it correctly
21:26:10	HM:	after more blinding you get a shadow line with an intercept the bank can't know
21:26:14	nsh:	"payment information may be efficiently stored (17 bytes per payment);" that seems very optimistic in retrospect
21:26:47	HM:	hmm yeah tis
21:27:05	HM:	I think you need at least 64 bytes and thensome
21:41:20	sipa:	comboy: afaik, (pure) proof of stake cannot work, and not because of economic reasons
21:42:47	michagogo|cloud:	With PoS, AIUI, a rational miner will mine every possible fork
21:44:03	michagogo|cloud:	The reason PoW works is that the miners are irreversibly expending valuable resources mining, so they had better put that effort into what they believe to be the most likely chain to survive
21:47:22	petertodd:	comboy: there's something almost, but not quite, proof-of-stake that I've taken to calling proof-of-internal-sacrifice, but it places very high and probably unrealistic demands on the flood-fill network required to broadcast new information about the state of consensus
21:51:09	HM:	lol
21:51:28	HM:	internal sacrifice sounds pretty hardcore
22:00:12	comboy:	sipa: it's hard for me to distinguish technical from economic reasons since it all seems to be about incentives, but you mean that even if majority of owners are not selfish it cannot work?
22:00:56	sipa:	comboy: well, up to a certain point, economics are always involved
22:01:21	sipa:	comboy: but there is no reason why any PoS miner wouldn't extend every fork he has ever seen, as it costs just as much as mining on one chain
22:01:41	sipa:	which means no convergence
22:04:44	comboy:	long story short we cannot avoid work :/
22:05:21	comboy:	petertodd: is there something to read about it?
22:06:25	nsh:	.wik IMT international
22:06:30	nsh:	(oops, wrong chan)
22:10:08	petertodd:	HM: for the love of god, please come up with a better name for it for me
22:10:46	tromp_:	in PoS, stake blocks must still meet a hash target. but this target is per unit coin age, so the more stake you have the easier it is to meet the target
22:10:48	petertodd:	comboy: sigh, not yet, it's on my mythical "I need to write a biook" todo list
22:10:59	HM:	petertodd, would if i could. no idea what you're talking about
22:11:08	petertodd:	(holy crap this airport wifi sucks)
22:11:32	petertodd:	HM: heh, so, proof-of-sacrifice means proving you sacrificed some digital asset, say, spending some bitcoins to an unspendable output
22:12:03	HM:	nsh, the 17 bytes might not be that unrealistic after all. i just discovered 3 of 4 EC points are redundant because you can regenerate them from the other (you just need to vertify the challenge hash)
22:12:12	tromp_:	if you make the unit hash target small (hard) enough, then it will be very hard for stake holders to work on many parallel chains
22:12:20	nsh:	hmm
22:12:23	petertodd:	proof-of-internal-sacrifice means the thing you sacrificed was a digital asset within the system itself, which means for it to be a true sacrifice the consensus of the system in the long run must include the fact you made that sacrifice - tricky!
22:12:39	HM:	petertodd, the mtgox method? :P
22:12:48	HM:	proof of stupidity
22:13:19	tromp_:	proof of karpeles tunnel syndrome
22:14:21	HM:	proof of pauperism
22:15:06	HM:	proof of philanthropy?
22:15:26	HM:	because discarding coins would make everyone elses worth more in real terms? :S
22:15:49	HM:	no idea
22:17:22	andytoshi:	midnightmagic: this is the plan for alts.pdf eventually. i was hoping some people more familiar with the history would contribute
22:17:57	petertodd:	HM: problem if, mtgox doesn't have any proof...
22:18:02	comboy:	petertodd: I mean for bootstrappnig it seems reasonable to do this proof-of-making-gods-happy, but what do you mean about this "places very high and probably unrealistic demands on the flood-fill network required to broadcast new information about the state of consensus"?
22:18:53	HM:	keeps ISPs happy perhaps, not sure about Zeus
22:19:07	petertodd:	comboy: well, basically since the sacrifice only happens if it gets incorporated into the consensus, you can play games by jamming the jam-free flood-fill network that all crypto-consensus schemes need to function
22:20:03	petertodd:	as it is, these schemes - bitcoin included - are really trying to achieve proof-of-publication, and they do that by bootstrapping on top of a really shitty proof-of-publication scheme - just broadcasting some data on a flood-fill network
22:20:04	comboy:	petertodd: but is this somehow different than what's present in PoW networks?
22:20:32	petertodd:	comboy: yes, because in pow you've sacrificed something valuable - energy - even if no-one ever hears about it
22:21:05	nsh:	*negentropy
22:21:11	nsh:	(you can't sacrifice energy :)
22:21:22	HM:	as far as we know
22:21:28	nsh:	* nsh nods
22:21:32	petertodd:	nsh: !@#$ pedants
22:21:36	comboy:	hehe
22:21:38	nsh:	* nsh smiles
22:22:46	nsh:	i'm in a position where pedantry is a survival skill, and worthy of practice :)
22:22:53	amiller:	petertodd, sipa, isn't the best idea to use a one-time-use-only signature, such that once you attempt to spend a coin on one block, if you attempt to publish a second one voting for a different block, you lose the coin altogether?
22:23:32	petertodd:	amiller: that's exactly the kind of thing I'm talking about - point is it depends on a jam free network for someone to find out about that other spend attempt
22:23:42	petertodd:	amiller: that's a seriously non-trivial requirement
22:24:10	amiller:	i kinda feel like all the other good stuff relies on this jam free network too
22:24:10	nsh:	what does 'jam' mean, technically-speaking?
22:24:28	HM:	50% fruit, 50% sugar, boil it down
22:24:31	nsh:	(it's slang for sex in glasgow. The More You Know (tm))
22:24:44	amiller:	once you pass a message to one member of the network
22:24:48	petertodd:	amiller: yes it does, hence why I keep saying the point of bitcoin is to take a shitty jam-free-network/proof-of-publication system and make it strong
22:24:48	amiller:	absolutely everyone hears about it in short order
22:25:09	petertodd:	nsh: jam == censor
22:25:15	nsh:	ah, gotcha
22:25:32	amiller:	or equivalently, if you pass one half of an interesting transaction to one person on the network, and the other half to any other person on the network, then the two halves will find each other and make it onto the blockchain
22:25:39	comboy:	isn't jamming problem solved in good part if everybody is using tor? I mean with some reasonable amount of connections it's really hard to do something
22:25:42	nsh:	so any viable incentive system must strongly discourage selective gossip...
22:26:00	petertodd:	nsh: yup
22:26:06	nsh:	* nsh nods
22:26:08	petertodd:	comboy: no! not at all! tor makes it worse
22:26:09	amiller:	the significance of the way i explain it is that the two halves of a transaction aren't necessarily themselves significant enough to get included in the public log
22:26:23	amiller:	it's only when they come together somehow that it's worth publishing
22:26:36	petertodd:	comboy: fortunately bitcoin is so strong that tor doesn't do it any harm, but lesser systems... ugh
22:26:38	amiller:	for example an "attempted green-address double spend"
22:26:51	amiller:	right now if someone attempts to double spend, the double spends are forgotten
22:27:08	amiller:	but if someone attempts to double spend a green address, it's Big Fucking News and sohuld probably trigger other things like insuarnce payouts
22:27:48	petertodd:	amiller: if you puruse chat logs from a year ago you'll notice how I was talking about proof-of-publication in everything but name w/ fidelity bonded banking for that kind of reason
22:28:02	comboy:	uh oh, but even if somebody creates a lot of "bad" nodes, he would have to have *much* more of them than the actual network to have any chance with you, no?
22:28:15	amiller:	petertodd, i guess, i think what i'm talking about is a little different
22:28:19	amiller:	but i dunno maybe
22:28:23	austinhill:	I offer you alll this gem of a short documentary on fractional reserves :) http://www.youtube.com/watch?v=ADv5-Pen1L4#aid=P-Z3ijodCiQ
22:28:25	amiller:	i've been pointing this out for over a year ago too
22:28:26	comboy:	I mean apart from the way addrs are currently propagated..
22:28:45	amiller:	for example in the differene between what you get with 'commitcoin' or whatever that other implementation is
22:29:02	amiller:	and how you can't use that to create a mastercoin-like overlay coin, because you get proof of timestamp but not proof of publication
22:29:23	amiller:	anyway yeah, the proof-of-publication == jam-free is really significant
22:30:14	amiller:	anyway the example i'm pointing out now is slightly stronger
22:30:15	petertodd:	comboy: the issue is how do you even know how big the actual network is? one way of thinking about bitcoin is that it helps solve that problem
22:30:50	petertodd:	comboy: that's why you can use bitcoin safely via tor provided your attacker isn't a large chunk of the hashing power: confirmations will be very slow and you'll be suspicious
22:30:51	amiller:	people with green addresses want to prove they aren't attempting double spends, that means a) every transaction needs to be published even if they aren't, and b) someone needs to keep an index so it's efficient to tel if there are conflicting ones
22:31:00	amiller:	proof of publication is close but not enough for that
22:31:18	petertodd:	comboy: or, the work-per-block will be low compared to your idea of what it should be (via third-party methods notably!)
22:31:58	petertodd:	amiller: ah, true, the index requirement is a real-world-consideration there
22:32:14	petertodd:	amiller: a flaw for any real proof-of-pub scheme
22:32:32	ens_:	proof of pub? ask any irishman
22:32:38	amiller:	but for sure we're narrowing in on the crucial abstractions over what bitcoin's already providing.
22:32:57	petertodd:	amiller: note how all my fidelity bonded banking discussion pretty much boiled down to "all these methods are imperfect, but together... hopefully!"
22:33:11	amiller:	petertodd, so, what's a shitty jam-free network?
22:33:19	amiller:	or a shitty index for that matter?
22:33:26	amiller:	how are we going to build a strong one out of the shitty parts?
22:33:49	petertodd:	amiller: well, bitcoin! ie, imagine if bitcoin had no pow, and was based purely on "hey look! I just published this tx to the jam free network, and no-one complained"
22:34:04	petertodd:	amiller: obviously it'd seem to work great until someone sybil attacked the network
22:34:25	petertodd:	amiller: bitcoin just makes sybil attacking the network have very well-defined costs - we call it the 51% attack
22:34:57	amiller:	in other words the pow blocks are the jam-free mechanism
22:35:01	petertodd:	amiller: as for a shitty index, the existing bloom filter implementation is a perfect example as nods can get away with lying
22:35:20	petertodd:	amiller: well, they're what makes the underlying jam-free mechanism feasible
22:35:35	petertodd:	amiller: you could say pow makes measuring the degree of jam feasible
22:35:44	petertodd:	* petertodd mmm... degree of jam
22:35:59	amiller:	proof of pudding
22:36:27	petertodd:	lol
22:36:40	petertodd:	does it involve eating? i hope so
22:37:13	amiller:	proof of pudding would actually be a really good paper name because of bread-pudding protocols
22:37:20	comboy:	petertodd: of course jam free is not enough, but just talking about jam free I was expecting it to be easier achievable through tor, but maybe not indeed (although for attacker that has unlimited ipv4..)
22:37:54	comboy:	and I'm hungry
22:37:57	amiller:	does tor even provide any strong availability guarantees
22:38:07	amiller:	i guess by obscuring each link it makes it very hard to selectively jam
22:38:10	amiller:	that does seem pretty crucial
22:38:42	petertodd:	amiller: oh yeah? remind me again what is a bread-pudding protocol 
22:39:02	amiller:	it's basically merge mining from 20 years ago
22:39:22	petertodd:	(wtf, 35% packet loss...)
22:39:40	amiller:	http://link.springer.com/chapter/10.1007/978-0-387-35568-9_18
22:40:44	petertodd:	amiller: paywalled, email me a copy
22:41:11	amiller:	the .ps files are available on google scholar, i just felt like linking to a browser-readable version of the abstract
22:41:21	comboy:	http://www.hashcash.org/papers/bread-pudding.pdf
22:43:10	amiller:	thx
22:43:29	petertodd:	ah, yeah, I've read that one
22:53:52	ens_:	ens_ is now known as ens
22:57:09	petertodd:	from #ethereum: "I'm trying to build go client but it seems that it needs qt5, is it wise to put this kind of dependance" <- slapping a gui on it should be the last thing you do...
23:00:18	Luke-Jr:	lol
23:00:51	Luke-Jr:	ugh, I think I need to open 2 freenode connections so I don't have to keep picking which channels
23:01:44	austinhill:	:petertodd haha nice find. Anyone huffing ether should enjoy this :)
23:02:35	nsh:	Luke-Jr, just register yourself as a bot :)
23:02:57	Luke-Jr:	nsh: does that work?
23:03:21	nsh:	possibly
23:03:37	nsh:	otherwise you can probably syndicate channels with znc or some other more-advanced bouncer
23:08:18	petertodd:	austinhill: colored coins I think made the same mistake
23:08:40	petertodd:	austinhill: should have focused on getting a top-notch library working first with a simple CLI interface
23:09:09	petertodd:	austinhill: and mastercoin too...
23:42:33	adam3us:	amiller: one-use sig are technically easy and have the property you mentioned if i understand (spend twice and the private key leaks).
23:43:07	amiller:	right, so, one of those gets you the best-in-breed proof-of-burn consensus i think
23:43:18	adam3us:	amiller: Q'=H(r=kG,Q) where Q=dG as normal, Q' is the extended address. sig is r,s normal s=k^-1(H(m)+rd)
23:43:57	adam3us:	amiller: because r is fixed, you are forced to reuse k, which leaks the private key by simultaneous equation if you double spend
23:45:32	amiller:	ok great, so, how do you actually make it so that losing your private key is worse than trying and hoping no one cares
23:45:33	adam3us:	amiller: which is probably a reasonably plausible semantics for 0-confirm. either you get the money, or if its double-spent - a miner does. probably better than the money going to the double-spender!
23:46:39	adam3us:	amiller: you could probably escalate it ... use the same private key for a larger bond perhaps.
23:47:33	adam3us:	amiller: the main downside is this places transactional requirements on clients. eg if you send a payment to the network, then your client crashes, you reboot and are unsure so do it again. the client needs to be transactional to ensure it sends exactly the same message the second time. or you accidentally double spend
23:48:00	amiller:	well this just needs to be for mining
23:48:16	amiller:	i dont see a problem with that basiclaly
23:48:51	adam3us:	amiller: accidentally double spending could be painful for a user
23:49:00	adam3us:	amiller: or are you talking about a different use case?
23:49:13	amiller:	i'm talking about proof-of-burn consensus
23:49:30	amiller:	where instead pow mining, you spend coins into a dev null lottery kinda thing
23:49:36	amiller:	dedicate them to voting for a block
23:50:11	austinhill:	petertodd: was not the mistake of coloured coins SPV and a myopic view of how the blockchain worked?
23:51:32	adam3us:	amiller: so then what? highest burn dictates what is the valid block? (modulo validation by other voters who wont (you hope) vote on top of former invalid blocks)?
23:53:16	amiller:	adam3us, i don't know, tbh, i kinda don't understand how proof-of-stake works either
23:53:22	amiller:	but this at least addresses one immediate problem with it
23:54:15	adam3us:	amiller: vote on multiple branches, you lose your coin? (the nothing-at-stake issue do you mean?)
23:54:25	amiller:	yes
23:54:27	amiller:	exactly
23:55:08	petertodd:	austinhill: no, colored coins is fine with SPV
23:55:10	adam3us:	amiller: i think the nothing-at-stake is a way to turn proof of stake into proof of work, but you dont broadcast the failed ones. so i am not sure if it helps
23:55:23	petertodd:	austinhill: though I'm about to catch a flight, later
23:55:36	adam3us:	petertodd: colorcoins are non-spv compat, no. (ok later!)
23:55:37	petertodd:	see you all at financial crypto 2014!
23:55:58	Luke-Jr:	petertodd: nah, I'll be at the Bitcoin conference :P
23:56:03	petertodd:	adam3us: ask yourself what you mean by "non-spv" exactly, but anyway, later
23:56:27	adam3us:	petertodd: spv clients cant validate the colors (without bitcoin core changes)
23:59:33	adam3us:	amiller: it is a fun building block tho (one-use sig). if the transactional requirement could be made categorically safe somehow for clients. the problem is clients are cheap/unreliable hardware potentially. its also kind of separately interesting, another kind of use case, that a one-use sig is kind of non-malleable even by the signer. (ie no need to step 1 move the coin into a 2 of 2 address and have the counterpa
23:59:51	amiller:	adam3us, that is just not a real big problem here