00:17:13	Quanttek:	Quanttek is now known as Quanttek_sleepin
00:44:27	ghtdak:	ghtdak has left #bitcoin-wizards
01:15:28	qwertyoruiop:	the nothing-at-stake problem is interesting
01:15:41	qwertyoruiop:	and nxt has no checkpointing? hmm
01:20:09	stqism:	stqism is now known as stal[KEK]
01:20:15	stal[KEK]:	stal[KEK] is now known as stqism
03:04:55	andytoshi:	qwertyoruiop: i don't think anyone here knows how NXT works, a long time ago they were trivially broken, so they responded by becoming closed-source and sending marketing people to technical bitcoin conferences..
03:12:11	justanotheruser:	andytoshi: source?
03:23:40	zack1:	andytoshi: I like your pos article. It explains the problems very clearly, and succinctly. The "master private key" idea might be worth exploring a little further. I made a currency where any number of people can control "master private keys", unfortunately, this ability is non-transferable. If any 1/3rd of these people worked together, they could break the chain. If the chain is broken, there are
03:23:42	zack1:	still 1000 blocks left to POB the value into a different blockchain. At the end of the 1000 blocks, the chain is frozen in a state from which new chains can easily be born. The new chain has everyone controlling money in the same proportions as the frozen chain. My first implementation: https://github.com/zack-bitcoin/slasher
03:29:28	justanotheruser:	zack1: so the people in the original chain control the currency?
03:30:20	justanotheruser:	relative to their stake in the original currency?
03:51:37	maaku:	justanotheruser: source on what? andytoshi accurate described what happened
03:52:14	maaku:	i had a laughable conversation with the NXT booth at the amsterdam conference
03:52:58	maaku:	qwertyoruiop: no block chain should have checkpoints
04:50:35	andytoshi:	hey, when i say 'distributed consensus is impossible' what is a good citation for that?
05:04:05	jgarzik_:	jgarzik_ is now known as jgarzik
06:03:12	sipa:	Eliel, andytoshi: the concept 'monad' is so vague that your purpose should never be to learn monads themself; instead, learn how I/O in haskell works, and ignore that fancy people call it a monad for now
06:26:21	qwertyoruiop:	maaku: I agree, however PoS without checkpoints is bad news
06:31:25	gmaxwell:	"without checkpoints" ... if 'checkpoints' are doing anything to the system consensus the system is not a decentralized system at all.
06:32:30	gmaxwell:	You also should clarify what you mean by 'checkpoints', because PPC has confused the term by using it for their single party controlled block signing.
06:33:02	gmaxwell:	(not that not decenteralized == automatically bad; but lets be clear on what the things actually are.)
06:41:26	qwertyoruiop:	gmaxwell: Aware of that, but N@S seems worse than checkpoints. I am certainly not going to use PoS coins anytime soon
06:42:23	qwertyoruiop:	checkpoints are "the lesser evil" compared to the possibility of performing such an attack
06:43:05	qwertyoruiop:	(checkpoints as in a PPC-like system, btc-like checkpoints w/ hardcoded block hashes updated on each version seem a good idea)
06:44:32	gmaxwell:	I don't think handing a single anonymous party a attack-for-free card is ever a grand idea. If thats a lesser evil then perhaps the system is too insecure to use— but worse than that, there are obvious alternatives which are better and fit within the same tradeoff matrix.
06:44:49	gmaxwell:	e.g. why is the block signer a single anonymous person instead of some more robust process?
11:49:54	fanquake:	fanquake has left #bitcoin-wizards
13:38:01	posita:	andytoshi, If someone else hasn't pointed this out, on p.1 of your paper, I think you meant:
13:38:17	posita:	… not only prove ownership of a precise amount of currency, but also *PROVE* that this currency satisfies …
13:38:21	posita:	(Not "proof".)
13:39:54	posita:	Also, to maaku's point regarding confusing $100m with $100, I think $200m or $50m (or even $96m) probably work as well if you want something in the same ballpark.
13:57:23	Vitalik:	Vitalik is now known as Vitalik__
14:05:59	stonecoldpat:	andytoshi: reading it now, id avoid phrases like 'much more' and "very" as much/very doesnt really add anything - for example "proof-of-stake is a simple idea"- but thats probably me being over critical
14:24:41	andytoshi:	thx stonecoldpat, posita, i'll make those changes
14:26:20	posita:	It's an interesting read. It kept me up for an hour or so trying to design into a PoS system enough mandated (and verifiable) entropy to keep it from migrating to a centralized PoW system, but I don't think I was able to convince myself it could be done.
14:27:57	posita:	For example, if part of the selection of the signers is (e.g.) a hash of the current signers, then it becomes PoW to generate enough keys to maximize (or guarantee) one's chance of being selected.
14:28:46	posita:	I thought of having it be a function of the transactions included with the block (since those are difficult to predict), but that's defeated by selectively adding your own transactions to the block until the calculation comes out in your favor.
14:29:12	tromp:	or selectively ignoring other ppl's txs
14:29:23	posita:	Right.
14:30:34	posita:	Then I thought about trying to put a time requirement on it (i.e., you have n seconds to come up with a new block that contains at least x % of the transactions that other participants have seen), but this is defeated by collusion (and probably other techniques).
14:31:04	posita:	I'm sure others have all thought about these things before. I'm certainly not the smartest guy the room.
14:32:00	epscy:	is it possible for peercoins "checkpointing" to be replaced by PoW, so almost like having two blockchains, one that finds blocks every 10 minutes using PoS and one that finds a checkpoint block every day/week/month etc?
14:33:07	gmaxwell:	"n seconds" usually fails because there is no consistent universal defintion of time (and if you have one, you can probably dispense with everything else and use it directly), "transactions that other participants" it's usually a box of trivial attacks, the view of the network isn't universal. I can flood you with txn while flooding everyone else with conflicting ones. Laughs on you when you produce blocks that no one else has seen.
14:33:12	stonecoldpat:	found a typo "Andrew Miller calles nothing at stake" - but very interesting so far...
14:34:07	posita:	gmaxwell: Yeah, I am aware of that (andytoshi even brings it up in his paper), but I was just trying to see whether that would help solve the problem if I could conveniently ignore that constraint. :-)
14:37:01	stonecoldpat:	epscy: i think the problem would then be, your transactions are only as secure as the last checkpoint... which isn't as good as what we have now
14:37:33	andytoshi:	i had toyed with the idea of putting a sequential proof-of-work or something on the signers, the idea being that if you have a small fixed (per block) set of stakeholders then you don't need progress-freeness, and maybe that'd quell the runaway entropy production by preventing massive parallellism
14:38:27	andytoshi:	but there are a lot of fiddly problems with that idea, e.g. how can you incentivize difficulty to keep going up?
14:39:48	epscy:	ah i see
14:41:16	andytoshi:	thx stonecoldpat, fixed 'calles'. i ran a spellchecker (got a lot of stuff) and also checked every instance of 'much' or 'very' to see if it was necessary
14:42:51	stonecoldpat:	i suppose a proof of work system has a continuous expense... where a proof-of-stake doesnt.
14:43:12	stonecoldpat:	didn't mean to enter that right away :/ - but i guess, the stake would need to be devalued over-time, and the miner rewarded - like it is now
14:44:11	stonecoldpat:	your stake is the mining rig, but the cost of running it is devalues your investment until your rewarded, a proof of stake still needs that, perhaps a bit like a stock market bounce?
14:45:41	andytoshi:	the problem i talked about in the paper is your word 'until' is begging the question if your costs and rewards are entirely in the system
14:46:22	andytoshi:	because you can take your reward, redeem it for $$ or something, then go back to the block you stake-mined and sell your key material to an attacker for even more $$
14:47:32	andytoshi:	then the attacker forks the network at whatever point he has enough key material, and changes history from that point forward. it's basically the plot of back to the future, in consensus time rather than physical time
14:49:58	andytoshi:	in back to the future 2, the 'nothing at stake' problem was seen because biff was able to pick up the sports almanac from the trash (since it held no value or danger at that point in real time) and use it in the past to select a new history which caused him to own hill valley. the analogy is imperfect because with PoS there are two times, real time and consensus (blockheight measured) time, in BTTF
14:50:00	andytoshi:	it was all in real time
14:50:16	pigeons:	i love the analogy
14:51:28	stonecoldpat:	the missing ingredient as youve pointed out is a secure timestamp server pretty much.. so it would work fine ontop of bitcoin as an altcoin... and +1 for analogy, your paper should be written that way ;)
14:51:28	gmaxwell:	plus biff sounds like a great name for an alice/bob attacker who is stupid but breaks the world anyways. :)
14:56:16	stonecoldpat:	andytoshi: when you say sell their key, do you mean they sell their entire stake? or just access to their stake
14:58:03	gmaxwell:	stonecoldpat: their stake is long gone— if you're talking about what I assume you're talking about.
14:58:04	andytoshi:	stonecoldpat: whatever's needed to grind the specific block the attacker is targeting, just access i guess
14:58:27	andytoshi:	but yeah, i wouldn't call any of that 'stake' at that point
14:59:07	gmaxwell:	stonecoldpat: the point is that long after your past ownership of coins matters anymore the history where it did still remains, so with those keys you can rewind and play the history again from that point.
14:59:22	andytoshi:	as for "fine on top of bitcoin", i hinted at that with my general "burn something outside the system" commentary, i considered pointing out that you can basically make a 1-way peg but i don't wanna encourage that as an idea for people just coming off of proof-of-stake :)
15:07:15	stonecoldpat:	you could work from epscy's point of checkpoints, stakes were a fixed-size (small blocks) and each reward must be claimed using a proof of work (stake devalues overtime and disappears when reward is claimed) - but normal transactions can be signed. Something in this line may reduce the total proof of work required by a network, but prevent such an attack as described very clearly by
15:07:16	stonecoldpat:	gmaxwell - but of course then this isnt a pure proof-of-stake system, just more environmentally friendly
15:09:17	andytoshi:	the problem you have is that stake-miners then only need their proof-of-work hardware for a short time, so an attacker running it full-time will have a huge advantage over them. and also you need a way to push difficulty up as hardware improves, and you don't have a difficulty feedback loop since miners will always do the minimum of work
15:10:01	gmaxwell:	stonecoldpat: and still there the security reduces to proof of work plus an armwave. Maybe the armwave has value, its hard to reason about.
15:39:43	dsnrk:	andytoshi: you're talking about hybrid PoS/PoW yes?
15:39:56	Eliel:	gmaxwell: procuring old stake keys also takes some effort. It increases the costs of an attack to have the "armwave".
15:40:56	andytoshi:	dsnrk: one form of it, anyway, where only the stake-voters are mining
15:41:24	andytoshi:	i think typical hybrids have everyone mining and then stake-voting on top of that to prevent "bad behaviour" from miners
15:41:43	gmaxwell:	Eliel: Perhaps it decreases the cost of the attack massively, because in the common case there is no reason to have non-trivial POW.
15:41:53	dsnrk:	andytoshi: anyway, you don't need to even have hardware for the most part. nicehash.com sells stratum-proxy-as-a-service which is interesting in itself. people pay more than the hash power is worth to get "in" first in hybrid pos/pow scamcoins. I might have made a lot of money with that recently.
15:42:08	gmaxwell:	(thats mostly what I mean by being hard to analyize, you can't consider it in isolation as there are interactions)
15:42:49	andytoshi:	dsnrk: yikes, you definitely want to prevent that because then the hosted-mining providers are in a perfect position to pull off the kind of attacks you could do on ordinary PoS
15:43:14	gmaxwell:	Eliel: in particular I think it results in more brittleness, but maybe it's an increase. You also have to consider what badness results from making mining non-anonymous. E.g. does the system become easier to censor.
15:43:44	dsnrk:	andytoshi: I think it's hilarious personally. you can pay a little more than the value of it mining litecoin, and you instantly have many gigahash a second of scrypt PoW power.
15:43:45	gmaxwell:	dsnrk: do keep in mind the first formal service to do that was run by … pirate40.
15:43:53	Eliel:	gmaxwell: yes, that's one thing I've been a bit worried of.
15:44:33	dsnrk:	gmaxwell: huh? it's not a ponzi, it's a dumb pipe for stratum
15:45:09	andytoshi:	dsnrk: it's possible to rip people off as a hosted miner tho, so it's relevant that pirate40 had no scruples
15:45:20	gmaxwell:	in any case, I'm glad people are thinking about it. I suspect it will never be free of ugly compromises, but if Bitcoin's POWness gets broken someday a well analyized ugly compromise might be an obvious "better than giving up"
15:45:52	dsnrk:	andytoshi: of course it's dangerous to be able to point huge quantities of hashpower around
15:45:54	gmaxwell:	dsnrk: it's not just a dumb pipe, the site intermediates payments. :)
15:46:53	dsnrk:	gmaxwell: naturally. I wouldn't have touched it except that I know having 20TH/s to throw around doesn't mean anything at the current difficulty.
15:48:14	dsnrk:	you'd be better off paying somebody to compromise a pool server than buying it through a stratum proxy
15:48:54	dsnrk:	er better off as in, you're doing something that's not morally sound, why not do something illegal for the same cost
15:49:16	dsnrk:	is it illegal to orphan other people's blocks?
15:49:38	dsnrk:	I don't think that actually breaks any laws, they mostly pertain to access or destroying data
15:50:14	gmaxwell:	Anything you intentionally do that 'wrongs' another is a tort. I certantly wouldn't want to be doing anything that invited someone to sue me.
15:50:27	Eliel:	if it was illegal to orphan other people's blocks, it'd become illegal to mine bitcoin whenever there's a one block fork situation
15:50:49	gmaxwell:	Eliel: zomg finite speed of light outlawed!
15:50:50	dsnrk:	that would be unintentional though, not a premeditated crime
15:50:53	sipa:	which would mean it becomes a legal gamble to mine at all
15:50:54	stonecoldpat:	Eliel: i think he may mean intentionally 'corrupting' a block someone is mining
15:51:06	stonecoldpat:	as opposed to out-performing them
15:51:08	dsnrk:	gmaxwell: does law follow the speed of light?
15:51:39	gmaxwell:	dsnrk: well it certantly doesn't lead the speed of light— thats precluded by physical law! :P
15:53:31	dsnrk:	started thinking about how changes in law might have to compensate for time dilation. my head hurts.
15:53:56	dsnrk:	you could have somebody observed to have broken a law without them having broken it, right?
15:55:06	andytoshi:	nope, just the other way around
15:55:08	Eliel:	you mean, at the time of observation, the act seen is illegal, but when it was done, it wasn't?
15:55:22	andytoshi:	oh, that's definitely possible
15:56:16	Eliel:	I suspect spaceships will be treated like naval vessels on earth as far as law goes though
15:58:12	jcorgan:	andytoshi: link to your PoS paper?
15:58:21	dsnrk:	Eliel: yes
15:58:37	gmaxwell:	dsnrk: ordering is position-relative without any relativistic effects.
15:59:57	dsnrk:	gmaxwell: we might need some law reforms to address this
16:00:08	andytoshi:	jcorgan: https://download.wpsoftware.net/bitcoin/pos.pdf
16:00:14	gmaxwell:	dsnrk: doubtful.
16:00:20	jcorgan:	tks
16:05:43	gmaxwell:	andytoshi: are any of the deployed POS systems using more than a single stakeholder for their sampling?
16:06:17	andytoshi:	gmaxwell: idk, i had thought they were doing 3-of-5 but i don't recall who told me that
16:06:25	gmaxwell:	I didn't believe any were (and I'd previously regarded that as one more piece of evidence that they're not yet very well considered)
16:07:01	gmaxwell:	PPC did not last I looked, and NXT's original code was not. Maybe there is something that does or one of those has changed.
16:08:01	andytoshi:	i haven't evaluated a released PoS currency myself, just papers like tacotime's, because once i see "developer-based consensus" i'm not so curious about the exact rules the developers make the others obey..
16:08:42	gmaxwell:	has anything implemente the locked up stake stuff? The idea of bonding stake into the future is a relatively recent one. I like to credit Zooko for it but it appears to have been proposed independantly by a bunch of people.
16:08:53	andytoshi:	i'll grab a copy of blackcoin and check it out, there's one i think none of us have looked at
16:09:20	gmaxwell:	I think tacotime diverted himself onto one of the bytecoin forks. :)
16:09:27	andytoshi:	not that i know of, that one i have definitely only heard of in a context of "but we can make PoS work!, what if we did this?"
16:09:28	Eliel:	gmaxwell: at least during the conference, Nxt only had a single signer per block.
16:10:14	gmaxwell:	the logistics of multiple is hard, .. I mean just from a protcol perspective... but on the other hand, in the limit it has some nice security properties I think.
16:10:41	dsnrk:	NXT is the one that is reasonably broken right?
16:11:00	andytoshi:	yeah, the closer you get to 'every stakeholder signs' the harder you make (a) collusion and (b) a 'find all the keys after the fact' attack
16:11:01	dsnrk:	in a security sense, I saw their original source that was one huge .jar file
16:11:56	gmaxwell:	dsnrk: yea their level of closeness seems to be variable depending on a cryptographic hash of the phase of the moon.
16:12:08	Eliel:	Nxt is being remodeled still, so it's difficult to speak, but it seems like they're trying to make the system such that it's feasible to predict with reasonable certainty who will make the next block up to 20 blocks ahead but not more than that.
16:14:24	coke0_:	has anyone considered making PoS rewards inflation adjusted perpetuities? I think this actually solves the "nothing at stake" problem
16:15:01	Eliel:	what is inflation adjusted perpetuity?
16:15:40	coke0_:	a contract that pays you a fixed sum (adjusted for inflation) every N blocks
16:15:51	gmaxwell:	Eliel: your stake would be locked forever, but it would pay you forever.
16:15:56	coke0_:	yes
16:16:11	gmaxwell:	(unless someone mines a proof that you cheated, in which case it stops paying you)
16:16:26	coke0_:	you could sell it only if you could convince the buyer that you are never going to attempt double signing retroactively
16:16:38	Eliel:	oh, that sounds clever.
16:16:44	gmaxwell:	and that no prior buyer and so on.
16:16:53	coke0_:	thing is
16:16:55	Eliel:	but...
16:17:01	andytoshi:	it wouldn't be hard to have stake-transfer transactions
16:17:11	andytoshi:	but as soon as you transfer it you have lost your incentive to not go back in time
16:17:22	coke0_:	who would buy it!
16:17:38	Eliel:	but, would an attacker care?
16:17:59	coke0_:	you can't really sell your stake
16:18:01	gmaxwell:	It still isn't a complete answer to nothing at stake, because the attacker can deny the admission of the counterproofs into their chain. If they're isolating you, this is effective. I guess there needs to be some language there about absolute and relative costs.
16:18:13	gmaxwell:	coke0_: people do lots of insecure things.
16:18:21	gmaxwell:	like buying cloud hashing.
16:18:41	coke0_:	they could sent the counterproof in their chain indeed
16:18:47	coke0_:	I mean deny
16:18:52	dsnrk:	insecure? it's just a bit silly on the money side.
16:19:09	coke0_:	honestly main obstacle is education
16:19:39	coke0_:	you have intelligent looking people who day "ooh PoS makes the rich richer
16:19:42	gmaxwell:	dsnrk: the host can be skimming you to the tune of several percent without it being detectable, more like 10% if they can also manage to convince you that your particular hardware is slower (e.g. pay per chip instead of pay per rate).
16:20:07	coke0_:	expecting them to understand perpetuities is a bit much
16:20:40	gmaxwell:	well, and it's difficult to value one, since people have a huge time preference in this space.
16:21:01	gmaxwell:	as far as transfer goes— put your key in remote attest hardware... easier to convince someone you can't cheat.
16:21:02	Eliel:	I have to say that I'm not too hot on the perpetuity idea from economics perspective.
16:21:13	coke0_:	even if your key is stolen, it's still more profitable for the thief to steal your money than attempt to double sign retroactively
16:21:35	dsnrk:	gmaxwell: don't doubt that. I should state that I only messed with that site for a bit before one of my antminers PCI-e cables melted and I had to go buy new ones. I know the dangers of using central pools, which is why I'm using p2pool normally.
16:21:50	dsnrk:	also thin PCI-e cables. don't use them.
16:21:56	gmaxwell:	coke0_: they'd do both.
16:22:07	stonecoldpat:	coke0_ not if they sell everything, then go back in time and reverse history
16:22:08	coke0_:	they can't
16:22:22	coke0_:	then they lose the future income stream
16:22:33	Eliel:	coke0_: they only scenario they can't do both is if they fail at attacking.
16:22:49	Eliel:	and they obviously won't publish a failed attack chain
16:22:53	andytoshi:	coke0_: the idea is, they sell the future income stream, and then it's gone, they are free to go back and reverse history
16:23:01	coke0_:	to whom!
16:23:34	gmaxwell:	coke0_: to whomever they can buy it for, keep in mind the time preference— the future income stream which is hard to sell is almost worthless to the attacker anyways.
16:23:51	andytoshi:	i dunno, it has a value so it'll be salable
16:24:02	coke0_:	no
16:24:08	andytoshi:	for example there's an incentive toward using trusted hardware for this stuff exactly because it makes it salable
16:24:18	gmaxwell:	more salable
16:24:24	stonecoldpat:	:)
16:24:32	gmaxwell:	people on OTC have successfully sold private keys to unspent old bitcoin blocks.
16:24:39	coke0_:	you can't prove that you're not going to screw your buyer
16:24:46	Eliel:	yep, it's salable at a low price no matter what
16:24:58	gmaxwell:	so we have an existance proof (and people paid a premium for those)
16:25:03	coke0_:	OK so you sell it
16:25:08	coke0_:	but then you still own it
16:25:20	gmaxwell:	Not to mention the remote attest which would make it much more sallable.
16:25:30	coke0_:	so you are still incentived to keep it
16:26:25	gmaxwell:	in any case, this hasn't addressed the absolute vs relative value. I'm not sure how best to frame that clearly.
16:26:37	coke0_:	regarding time preference: yes that a bigger issue
16:26:59	coke0_:	especially for a very speculative asset
16:27:01	gmaxwell:	The point I'm making there is that forging a POW chain has an absolute real cost, vs the perpetuity is free if you believe the future value of the coin is 0.
16:27:28	coke0_:	not free
16:27:38	coke0_:	still has value, but potentially low
16:27:51	dsnrk:	I'd say the tenebrix block chain is worth 0
16:28:03	gmaxwell:	Right it's not an absolute value— referenced to something external, its 'relative to the system'.
16:28:04	coke0_:	but then what does attacking get you?
16:28:30	gmaxwell:	So you can't have a 'min difficulty' or a 'retarget interval' where the cost of attack can't fall too fast.
16:31:45	coke0_:	the usual attack model is that someone will sign a fork because they might as well, in case it succeeds
16:32:15	dsnrk:	you'd be stupid not too
16:32:33	coke0_:	in doing so they would lose their perpetuities... to win perpetuities
16:32:57	coke0_:	so granted they could possibly end up with more
16:33:14	coke0_:	since they may have spent part of the stream
16:33:43	coke0_:	but that's "perhaps more if attack succeeds" vs "certainty of losing something valuable *now*"
16:34:28	gmaxwell:	I do like the perputity thing, in that it creates an economic incentive to put your keys in something like an othercoin.
16:34:31	coke0_:	the casual selfish signer doesn't have much incentive
16:35:01	maaku:	my childhood obsession with back to the future has real world use!
16:35:06	gmaxwell:	Though the lack of an absolute reference still stinks.
16:35:25	coke0_:	now it's still possible for people intent on attacking for attack sake to do it, at a loss
16:35:37	coke0_:	gmaxwell: the absolute reference exists
16:35:53	coke0_:	it's the future value of the coin in the real world
16:36:07	coke0_:	it's something that has value now
16:36:24	andytoshi:	so then you've got a prediction market denominated in attacks :P
16:36:47	coke0_:	and not how knowledge of they key and value are forever entangled
16:37:31	andytoshi:	i also like this idea, but i really do think people would try to transfer the perpetuities
16:37:37	coke0_:	andytoshi: indeed, but as long as the portability isn't 1, then the value isn't 0, then attacks are hard
16:37:43	gmaxwell:	coke0_: That value can flicker and flash in an instant, we have many very intentional design criteria in bitcoin to protect the difficulty against that.
16:37:50	andytoshi:	(and the attacker is the old perpetuity holder, not the new one)
16:38:04	coke0_:	it doesn't matter if they try to transfer them to a crook
16:38:06	gmaxwell:	whats part of why the difficulty updates only infrequently and is clamped to only decrease at most a factor of 4 per retarget.
16:38:29	coke0_:	it does matter if they try to sell it to the NSA
16:40:09	coke0_:	their may also be a devil in the inflation adjusted details
16:40:50	coke0_:	in the real world, an inflation adjusted perpetuity has value because there are borrowers out there
16:41:21	coke0_:	but if you fund the perpetuity with inflation, then you may end up with a quadratic growth in inflation
16:41:44	gmaxwell:	andytoshi: yea, actually you need to make it so that it doesn't have any transfer in the system.
16:41:58	gmaxwell:	andytoshi: so that holding the old signing key always lets you steal the perputity income.
16:42:08	coke0_:	yep
16:42:28	coke0_:	so even if you sell it to a patsi
16:42:36	coke0_:	it's still valuable to you
16:42:52	gmaxwell:	coke0_: so one challenge there is that once someone breaks a perpeutity (for whatever reason) it can't lose any more value, but it can still be used in more attacks.
16:43:15	Eliel:	coke0_: I think you'd have to just decide on an inflation percentage and make the perpetuity amount dependant on the number of perpetuities in existence.
16:43:17	coke0_:	ah true...
16:43:43	tacotime:	andytoshi, gmaxwell, I'm still working on PoS stuff but I'll be the first to admit my system is heavily nerfed to being very reliant on PoW.
16:43:49	coke0_:	gmaxwell: indeed if your perpetuity becomes the village bicycle
16:43:53	gmaxwell:	so lets say the coin becomes nearly worthless for a week and people rush to sell off their bonds. Then its valuable again and the old owners start stealing.. eventually someone spites by creating a conflict, and now you can attack for no more cost.
16:44:05	coke0_:	it's worthless
16:44:09	coke0_:	buuut
16:44:22	andytoshi:	tacotime: an idea is, can you weaken the PoW to discourage it from taking over all the comptronium in the world? e.g. use a sequential PoW or something?
16:44:27	coke0_:	it's also worthless to use it to sign anything in the past
16:44:32	gmaxwell:	tacotime: yea if you make it rely on POW it may work, but at that point maybe the security is just weak POW.
16:44:45	andytoshi:	i suspect the answer is no btw, but it's worth thinking about
16:44:57	gmaxwell:	coke0_: hm? it's not worthless to replace history.
16:45:21	coke0_:	eliel: precisely, but I think you might end up with runaway inflation (quadratic rate of extension)
16:45:42	tacotime:	andytoshi, do you mean from an energy efficiency standpoint?
16:46:12	coke0_:	gmaxwell: it is if you're after signing rewards
16:46:33	andytoshi:	tacotime: yeah
16:46:52	coke0_:	it isn't if you're after double spending
16:47:00	coke0_:	but the same is true for PoW
16:47:21	tacotime:	yeah, i'm not entirely sure that's possible either. vitalik and obviously sunny king seem to think so, but i don't know really... i feel like the best you can do is use PoS to discourage bad PoW actors.
16:47:21	coke0_:	if you're after double spending, there are lots of cost that you may be willing to undertake
16:47:27	andytoshi:	but it's always extremely costly to overwrite PoW, so you need a big reward
16:47:46	andytoshi:	here you only need a small one, maybe you're spiteful or after notority or winning a bet
16:47:55	coke0_:	in practice of course that's really a theoretical problem
16:47:59	andytoshi:	or just think, wellll, there's a chance i'll get in-chain rewards or something
16:48:09	coke0_:	what you need to achieve is medium run, short run consensus
16:48:37	andytoshi:	you need consensus forever because your transactions chain back to their coinbases
16:48:39	coke0_:	achieving consensus on very low frequency checkpoints is easy
16:48:48	gmaxwell:	coke0_: no, you can't rewrite pow history for free.
16:48:49	andytoshi:	maybe demurrage would help with this..
16:49:12	coke0_:	not for free indeed
16:49:23	andytoshi:	tacotime: i think a better line of research is to limit the ways that "bad PoW" actors can exist, e.g. can we use blinding to prevent censorshi?
16:49:25	coke0_:	but you can't rewrite pos with perpetuities for free either
16:49:26	Eliel:	coke0_: no, you misunderstood what I meant. The system decides the amount it's creating first and _then_ allocates it to the perpetuities. In other words, New perpetuities being created lowers the value of the older ones.
16:49:43	coke0_:	eliel: right but then
16:49:59	coke0_:	at one point your perpetuity becomes almost worthless
16:50:18	coke0_:	it's value decays with time
16:50:41	coke0_:	so you could be interested in signing another chain
16:51:10	coke0_:	this is theoretical anyway
16:52:00	coke0_:	bitcoin still requires a consensus on what the Genesis hash is for new users
16:52:25	tacotime:	andytoshi, yeah, hard cryptography is always better than any user-based consensus system.
16:52:47	coke0_:	tacotime: where can I download the bitcoin client?
16:52:51	andytoshi:	coke0_: wth are you talking about, the genesis hash is a system parameter, you automatically have consensus because if you change it you aren't using bitcoin
16:52:57	sipa:	coke0_: #bitcoin
16:52:58	coke0_:	do I have to rely on... user consensus?
16:53:11	andytoshi:	no
16:53:13	coke0_:	sipa: I know I'm making a point about consensus
16:53:31	sipa:	bitcoin's consensus rules were set when the software was first released
16:53:43	sipa:	the genesis hash is part of that
16:53:58	coke0_:	how do I know which one is the original software?
16:54:37	coke0_:	there's a different client with a different hash at http://the real bitcointrustme.ru/
16:55:06	coke0_:	it I'm a new user, how do I know which one is bitcoin?
16:55:40	coke0_:	I'm being facetious of course, there are millions of social cues and trust relationships which allow me to find the right one
16:55:49	sipa:	right
16:55:56	coke0_:	but it's ultimately based on a trust based consensus for a new user
16:55:58	dsnrk:	I guess it doesn't matter with a HSM like the trezor
16:56:13	sipa:	but say we adopt a policy that no part of the blockchain will even be locked in
16:56:20	coke0_:	so if you can maintain the trust over the URL of the official client
16:56:31	sipa:	if a checkpoint gets added, anyone can shout "you're violating the policy!"
16:56:49	sipa:	not having it means it's just fuzzier to judge
16:56:54	coke0_:	you can probably use the same mechanism to do checkpoints
16:57:11	coke0_:	which is precisely what bitcoin does
16:57:15	coke0_:	and which is fine really
16:57:40	coke0_:	but that also means that attacks on PoS based on very old rewrites are theoretical
16:58:08	sipa:	well, we want to get rid of checkpoints in bitcoin
16:58:31	coke0_:	they do add safety
16:58:35	sipa:	they don't
16:58:51	coke0_:	but they should use something like a web of trust
16:58:54	sipa:	if they ever have an effect, bitcoin and its consensus mechanism have utterly failed, and we'll need intervention anyway
16:59:09	coke0_:	true
16:59:16	coke0_:	but in the long run
16:59:23	coke0_:	if bitcoin succeeds
16:59:36	dsnrk:	you see checkpoints having to be used by altcoins quite a lot as a security feature
16:59:42	coke0_:	the amount of money spent on mining goes to 0
16:59:51	michagogo:	coke0_: uh?
16:59:55	michagogo:	No...
16:59:58	coke0_:	yes
17:00:08	michagogo:	Explain?
17:00:15	coke0_:	gladly
17:00:18	sipa:	if the subsidy dwindles, maybe
17:00:45	dsnrk:	after the next halving we get to the point where the fees are actually a major part of the reward
17:00:46	michagogo:	s/if/when/
17:00:56	coke0_:	amount spent on mining = amount earned by mining = amount spent on txfee (in the long run)
17:01:07	sipa:	yup
17:01:13	michagogo:	dsnrk: do we? What's the current average (or median?) fee per block?
17:01:33	sipa:	i think it will take a few more halvings before they actually become relevant
17:01:38	michagogo:	sipa: sane
17:01:39	coke0_:	amount spent on txfee depends on supply (fixed) and demand
17:01:41	michagogo:	Same*
17:01:43	sipa:	and the future then is very uncertain
17:01:53	dsnrk:	does anybody have the stats anywhere? I've just been looking at them manually
17:01:58	michagogo:	coke0_: well, sort of fixed
17:02:15	coke0_:	third party payment providers, sidechains, etc can make that fall below supply
17:02:32	michagogo:	Many miners limit block size, artificially limiting supply
17:02:32	gmaxwell:	* gmaxwell presses ctrl-r some
17:02:35	coke0_:	why pay a transaction fee and wait
17:02:35	gmaxwell:	(for i in {269647..268647} ; do export bh=`./bitcoind getblockhash $i` ; for tx in `./bitcoind getblock $bh | grep ' "' | head -1 |cut -d'"' -f2` ; do ./bitcoind getrawtransaction $tx 1 | grep value | cut -d':' -f2 | cut -d ',' -f1 | sed -e 's/\.//' | awk '{aa+=$1} END {print aa}' ; done ; done)
17:02:47	sipa:	coke0_: but that too is supply and demand
17:02:56	dsnrk:	gmaxwell: old script
17:02:56	sipa:	coke0_: the blockchain offers trustless money transfers
17:03:04	coke0_:	yes
17:03:05	sipa:	coke0_: not every payment in the world needs that
17:03:20	sipa:	not can it support every payment in the world
17:03:34	coke0_:	which is very valuable between large payment providers for clearing
17:03:46	sipa:	but in the end, mining income - subsidy or fee or bonds or oob payments - will provide security to the chain
17:03:52	coke0_:	not so valuable at a low level
17:04:05	sipa:	maybe the blockchain only gets used for low-value payments with low-value security requirements, and that's fine
17:04:06	coke0_:	good luck with subsidies
17:04:40	sipa:	or maybe it ends up being a high-value settlement system between offchain providers
17:04:41	gmaxwell:	in the last 100 blocks the mean fee per block is 0.0783946
17:04:47	coke0_:	if the network has to rely on charity to run it has a problem
17:04:59	sipa:	maybe
17:05:02	michagogo:	How about the last thousand or two?
17:05:09	gmaxwell:	coke0_: you've misunderstood the word subsidy.
17:05:21	sipa:	by subsidy i mean the current 25 BTC payout
17:05:21	michagogo:	(And is the median hard to get?)
17:05:26	coke0_:	network safety is ultimately a commons
17:05:50	coke0_:	and there is going to be a big free rider problem
17:06:08	coke0_:	where you benefit from the value of bitcoin as an asset
17:06:21	coke0_:	without making use of the transfer abilities
17:06:34	coke0_:	I know I would
17:06:39	sipa:	well, one problem with bitcoin is that you can; t choose your security level
17:06:51	sipa:	every transaction (that gets included) has the same security
17:06:58	sipa:	whether you pay little or much
17:07:05	gmaxwell:	if you're not transfering it, you don't need very strong network security... since the reorg to effect your funds would be huge.
17:07:15	gmaxwell:	yea, a bigger concern is the one size fits all.
17:07:25	coke0_:	if I were a shop accepting bitcoins using Coinbase
17:07:43	sipa:	which inherently limits it to a certain range of values for transfer
17:07:49	coke0_:	and clients payed using Coinbase
17:08:06	gmaxwell:	michagogo:
17:08:07	gmaxwell:	Read 1992 items Min. 1st Qu. Median Mean 3rd Qu. Max.
17:08:07	gmaxwell:	0.00000 0.03047 0.06952 0.09828 0.13060 2.36000
17:08:08	sipa:	too valuable things would incentivize miners to reorg and double spend your transactions
17:08:11	coke0_:	I'd be happy to only transfer funds to an address I control one a month
17:08:14	Eliel:	I think ripple-like debt-routing systems will be what most bitcoin denominated transactions are done through in the future.
17:08:15	sipa:	too invaluable is unscalable
17:08:18	coke0_:	to minute tx costs
17:08:26	coke0_:	eliel: exactly
17:08:36	coke0_:	and it's fine and great economically
17:08:36	Apocalyptic:	Eliel, I hope not
17:08:38	coke0_:	buuut
17:08:41	michagogo:	gmaxwell: that's fee per block? Over how many blocks?
17:08:44	Apocalyptic:	debt is a flawed system
17:08:50	gmaxwell:	michagogo: 1992 blocks.
17:08:50	coke0_:	it doesn't subsidize network safety
17:09:00	michagogo:	Oh
17:09:07	michagogo:	Right. Sorry.
17:09:11	dsnrk:	gmaxwell: damn, you beat me too it
17:09:22	Eliel:	Apocalyptic: I'm only convinced that centralized debt is flawed, myself.
17:09:30	Eliel:	ripple decentralizes it
17:09:32	coke0_:	yep
17:09:41	michagogo:	(Yeah, that was a bit of a stupid question...)
17:09:43	Apocalyptic:	doesn't change the underlying principle
17:09:46	coke0_:	ripple or chaumian mints
17:09:47	michagogo:	;;blocks
17:09:47	gribble:	303191
17:09:48	coke0_:	whichever
17:10:16	Apocalyptic:	nor concept, nor any sociological implications that stem from it
17:11:19	coke0_:	bitcoin in the long run is a bullion sitting in a very safe vault that you can redeem certificates for
17:11:40	Eliel:	Apocalyptic: it can work entirely with debts that could be paid back on a moments notice if need be.
17:11:58	Eliel:	in other words, debts of convenience.
17:12:15	Apocalyptic:	the fact it can work is not the point of discussion
17:12:21	Apocalyptic:	the fact it does work badly is
17:12:26	coke0_:	trustless transfers are used between vaults for occasional clearing
17:12:31	coke0_:	or for very large purchases
17:12:32	dsnrk:	a trustless system doesn't work with debt, at least I can't see how it would work
17:12:46	coke0_:	dsnrk: it's not trust less
17:12:52	Eliel:	Apocalyptic: in other words, you think no-one should owe anything to anyone, ever?
17:12:55	coke0_:	but decentralized trust is good enough
17:12:56	Apocalyptic:	dsnrk, it doesn't obviously
17:12:59	gmaxwell:	careful to distinguish spherical ideal ripple, from ripple labs ripple, which I don't believe qualifies as a decenteralized system.
17:13:06	coke0_:	indeed
17:13:24	coke0_:	spherical ripple is indeed a fantastic
17:13:26	gmaxwell:	but yea, I think that w/ instant clearing it could be pretty useful stuff.
17:13:28	coke0_:	idea
17:13:29	dsnrk:	gmaxwell: it's pretty much dead anyway, didn't one of the founders sell all of their stuff and bottom out the market?
17:13:52	coke0_:	the soft ware is available
17:14:01	coke0_:	I'm waiting for freeple
17:14:18	coke0_:	it'll happen at some point
17:14:24	coke0_:	which is why I don't hold xrp
17:14:33	Eliel:	Apocalyptic: because to call the ripple model unworkable is just that. A statement that debt shouldn't exist.
17:15:06	Apocalyptic:	where did I call it unworkable ?
17:15:28	coke0_:	in a world without any trust
17:15:38	dsnrk:	debt only works with trust
17:15:41	coke0_:	you cannot reliably download the bitcoin client
17:15:50	coke0_:	so bitcoin works with trust
17:15:59	coke0_:	so does crossing the street
17:16:00	Apocalyptic:	only to a very limited extent
17:16:03	dsnrk:	minimal trust
17:16:03	Eliel:	Apocalyptic: I'm not interested in wordgames. you're outright rejecting the model. That's all I'm saying.
17:16:13	dsnrk:	loaning money to somebody does not work minimal trust
17:16:17	sipa:	coke0_: sure, there is some social trust involved there, unfortunately
17:16:26	coke0_:	heck bitcoin requires you to trust that two people aren't collufing
17:16:30	Apocalyptic:	Eliel, i'm rejecting the basis of debt as a way to settle economic matters yes
17:16:36	coke0_:	the heads of two mining pools
17:16:37	sipa:	coke0_: git merges are signed
17:16:47	sipa:	coke0_: and the binaries are built deterministically from it
17:16:52	sipa:	which you can verify yourself if you want to
17:16:53	coke0_:	so?
17:16:53	Apocalyptic:	because it's been shown it does stand the prove of time in a large scale
17:16:54	dsnrk:	coke0_: mining pools aren't ideal. p2pool needs no trust.
17:17:05	coke0_:	how do I know which github account to go to!
17:17:06	gmaxwell:	he's pointing out that it takes two miners to be >50% hashpower right now
17:17:21	Apocalyptic:	Eliel, and no wordgames here, you have to be clear and precise about what you're talking about
17:17:22	Eliel:	Apocalyptic: that's just the thing. In ripple there's no large scale debt.
17:17:29	sipa:	coke0_: fair point, there is always some minimal trust involved
17:17:33	coke0_:	indeed
17:17:36	coke0_:	and that's fine
17:17:48	sipa:	we can only avoid trust where possible
17:17:48	gmaxwell:	Eliel: hm? in ripplelabs ripple that gateways have zillions of dollars in debt.
17:18:06	Apocalyptic:	i'm with gmax on this
17:18:09	coke0_:	same for small debts of convenience between parties that have decided to mutually trust each other
17:18:16	Apocalyptic:	if you don't call it large scale I don't know what is
17:18:25	gmaxwell:	But in spherical instant settlement ripple there wouldn't be, or at least what large scale debt there was could be cryptographically proven to be backed by assets.
17:18:27	Eliel:	gmaxwell: that's ripplelabs model and a useful transition model into the ripple ideal.
17:19:01	Eliel:	in ideal ripple model, there is no need for gateways
17:19:11	Eliel:	nor any money besides the ripple system.
17:19:27	coke0_:	why not?
17:19:29	gmaxwell:	Eliel: thats not clear to me. (that its a useful transition model, since the system basically has none of the properties you'd want)
17:19:37	coke0_:	you mean no xrp or no USD?
17:20:16	Eliel:	coke0_: The currency units themselves are irrelevant to what I'm saying.
17:20:16	coke0_:	and why not have a currency, after all if you have distributed consensus technology
17:21:01	coke0_:	note that you could do debt in the bitcoin ledger like you have in ripple
17:21:11	coke0_:	so the main difference isn't actually debt
17:21:15	Eliel:	gmaxwell: ripple needs users to flourish. It's much more dependent on network effects than bitcoin is.
17:21:19	coke0_:	but the cost of maintaining consensus
17:21:39	Eliel:	gmaxwell: the trust network ripple needs to function as it was envisioned needs to be there, otherwise it's not useful.
17:22:03	coke0_:	you could use the ripplelabs consensus tech could be used to power a debt less currency
17:22:14	Eliel:	coke0_: ripple system does not intrinsically need distributed consensus.
17:22:25	coke0_:	and the bitcoin blockchain could be used to track a network of credit lines
17:22:49	coke0_:	eliel: true, but it really helps to find credit line paths
17:23:12	Eliel:	it's enough that the individual users agree on what each one owes to the others
17:23:18	coke0_:	without having to arrange that privately with intermediary nodes
17:23:24	coke0_:	agreed
17:23:30	coke0_:	just more convenient
17:23:43	Eliel:	but the routing becomes harder without a public database of the trust links.
17:23:48	coke0_:	you can do min-cost flow on the graph
17:23:53	Eliel:	(although, privacy improves a lot)
17:24:02	coke0_:	and that's a very big selling point to me
17:24:37	coke0_:	that means if there is a smuggler getting yuan's out of China on a Yack's back
17:24:49	coke0_:	and he's on ripple
17:24:56	coke0_:	ripple will route through him
17:28:16	coke0_:	at any tastes TBC
17:28:20	coke0_:	at any rate
17:29:29	dsnrk:	andytoshi: did you ever look at Bytecoin's PoW? that's yet another absolutely insane one to ass to your list
17:29:40	coke0_:	the guarantees made by PoW are more theoretical than commonly thought and the problems with PoS more theoretical than commonly thought
17:29:41	dsnrk:	ass, I meant add to your list.
17:32:00	tromp:	Bytecoin's PoW suffers from very slow verification
17:32:03	andytoshi:	dsnrk: nope, i think it's been recommended to me tho
17:32:23	dsnrk:	yeah, well it's extremely slow. so slow that pools get swamped just verifying single shares
17:32:31	dsnrk:	and obfsucated.
17:32:57	andytoshi:	coke0_: … bitcoin has been working for 5 years with no attacks while every "pure PoS" coin is actually a centralized consensus
17:33:44	caedes:	hi!
17:34:13	gmaxwell:	PPC was attacked basically instantly when POS mining became possible there. The attack was only stopped by the systems (centeralized) requirement for network broadcast block signatures by the developer.
17:34:35	dsnrk:	andytoshi: just to point out, it's taken me hours just to research what all the different hash functions Bytecoin uses actually do.
17:35:21	coke0_:	andytoshi: workable PoS is harder to make work than PoW
17:35:48	coke0_:	ppc has many large issues
17:36:45	coke0_:	chief of which is that you can't rule out big reorgs if someone has a lot of coin age
17:36:55	coke0_:	same problem with tapos
17:37:08	coke0_:	you need time entanglement
17:37:42	andytoshi:	coke0_: well, that directly contradicts your above claim about PoS's problems being "more theoretical than commonly thought", and i'd prefer if you are going to fill the scrollback here that you hold yourself to a higher standard of consistency.. furthermore we have spent probably hundreds of hours here on PoS and literally nobody has come up with a satisfactory response to the problems listed in my
17:37:44	andytoshi:	pos.pdf, let alone a counter to the intuition that it's impossible
17:37:50	coke0_:	because you want security to depend on waiting a reasonable amount of time
17:38:47	coke0_:	I've spent hundreds of hours thinking about it too
17:39:02	andytoshi:	i can tell, sorry to be snippy
17:39:20	coke0_:	and yes it is theoretically unworkable
17:39:22	coke0_:	I agree
17:39:50	coke0_:	I'm saying it probably can be made to work in practice, using checkpoints
17:40:02	andytoshi:	"using checkpoints" means centralized consensus, agreed?
17:40:02	gmaxwell:	it was in practice unworkable, in the case of PPC, and was replaced with centeralization
17:40:13	coke0_:	no
17:40:23	gmaxwell:	coke0_: thats what it means in ppc.
17:40:32	coke0_:	it can be decentralized
17:40:32	pigeons:	as mentioned many times, when you trade in a little trust/centralization, you get lots of new powers
17:40:36	gmaxwell:	if you're happy to use a centeralized solution you can do something much more efficient than having any kind of blockchain at all.
17:40:37	coke0_:	but not trust less
17:41:27	andytoshi:	coke0_: can you clarify what you mean by "decentralized"?
17:41:38	coke0_:	sure
17:41:44	andytoshi:	in bitcoin that means anyone can join, anyone can participate, there is no such thing as decentralized trust in that context
17:42:02	coke0_:	so you have a predicable checkpoint bock height
17:42:37	sipa:	the only unambiguous definition for decentralized is "without central point of failure", and it is something that is often conflated (and imho to and extent orthogonal to) trustlessness
17:42:42	coke0_:	you wait for 10,000 in days
17:43:07	coke0_:	I mean 10000 blocks
17:43:11	andytoshi:	ok, good :P
17:43:18	coke0_:	then many many people publish the hash
17:43:21	Apocalyptic:	sipa, isn't that the definition of distributed ?
17:43:26	coke0_:	on the bitcoin website
17:43:33	sipa:	Apocalyptic: DNS is distributed, not decentralized
17:43:34	coke0_:	in the NYT and the WSJ
17:43:39	Apocalyptic:	correct
17:44:02	coke0_:	by carving it in fresh cement
17:44:21	sipa:	ok, assume we do
17:44:22	coke0_:	by making it a lyric in a pop song
17:44:25	sipa:	and there's a 10000 deep reorg
17:44:25	coke0_:	then
17:44:27	sipa:	now what?
17:44:50	andytoshi:	i believe in this context the reorg is simply rejected
17:44:54	gmaxwell:	if that works you can just get rid of the insanly inefficent blockchain stuff. Just publish your first spends what way.
17:45:00	coke0_:	no
17:45:09	gmaxwell:	yes
17:45:13	coke0_:	because this works well at large timescales
17:45:22	coke0_:	and not well at short timescale
17:45:28	gmaxwell:	then someone just attacks on that boundary.
17:45:34	sipa:	if a 10000 deep reorg is possible, it means the idea of blockchain-based consensus has failed
17:45:51	coke0_:	we're taking PoS
17:45:51	sipa:	and there's no reason to expect that it can keep functioning
17:45:55	sipa:	Oh.
17:46:13	dsnrk:	wouldn't anything more than a 500 block reorg break bitcoin today?
17:46:17	coke0_:	a lot of the theoretical problems with it really boil down to the possibility of arbitrary long reorgs
17:46:20	dsnrk:	regressions and all that.
17:46:49	gmaxwell:	coke0_: the attack on PPC when it became POS minable was not "arbitrary long reorgs"
17:47:01	gmaxwell:	it was someone grinding right at the tip to give themselves every block.
17:47:02	coke0_:	ppc isn't the only pos system
17:47:38	gmaxwell:	Yes, but I'm invoking it as an example. If a consensus system works at one timescale it probably works at all timescales (and the converse)
17:47:39	coke0_:	yes
17:48:07	coke0_:	but we're not talking about ppc
17:48:28	coke0_:	we're talking about the silver bullet argument against all pos schemes
17:48:44	coke0_:	that you can always stimulate a different history
17:49:27	coke0_:	and that argument doesn't really hold if you can cap the longest possible reorg
17:49:27	gmaxwell:	'history' starts instantly, haven't you read that asimov story?
17:49:43	coke0_:	I know what you mean
17:50:04	coke0_:	but the checkpoint is history
17:50:06	andytoshi:	coke0_: near the end of my document i talk about this, how actually all these arguments translate into incentive failures at the tip
17:50:18	sipa:	the only reasonable way of capping the longest possible reorg imho is "if (reorg_depth > CONSTANT) { die("System has failed."); }"
17:50:19	gmaxwell:	(and generally 'cap reorg' is anyother way of saying 'introduce attacks' :P )
17:50:25	coke0_:	ah that I disagree with
17:50:52	coke0_:	capping reorgs with cementing can't work
17:51:03	coke0_:	for obvious reasons
17:51:14	coke0_:	like you said, history starts now
17:51:35	coke0_:	real world checkpoints are different
17:51:46	sipa:	fair enough, they are
17:52:13	coke0_:	andytoshi: conflict at the tip is only a property of competitive system, not cooperative ones
17:52:27	sipa:	but needing to rely on such checkpoints makes the whole system totally uninteresting to me :)
17:52:35	gmaxwell:	(The asimov story I was referring to is "The Dead Past")
17:52:54	coke0_:	you can have purity or functionality
17:53:15	sipa:	i think you can have both
17:53:27	sipa:	use a system that does not rely on such trust where you can
17:53:44	sipa:	and use a different system that entirely drops the assumption of trustlessness where you can't
17:53:56	sipa:	(and make it a few orders of magnitude more efficient in the process)
17:54:10	coke0_:	there's nothing pure about burning a billion dollars of CPU power to pretend to have a trust less consensus when in reality two people can collude to double spend
17:55:02	coke0_:	so perhaps the answer is indeed a decentralized trust system at every point in time (like ripple)
17:55:47	wallet42:	wallet42 is now known as Guest44494
17:55:47	wallet421:	wallet421 is now known as wallet42
17:55:48	coke0_:	but it could be that the answer is that trustlessness shines in the short run and trust in the long run
17:55:56	andytoshi:	i think a better thing would be to work against that type of centralization, e.g. with non-outsourceable puzzles
17:56:16	andytoshi:	generally i don't like trust because it's too human chauvinistic
17:56:38	andytoshi:	you are really limiting your ability to progress if you are systematically excluding robots from participating in the economy
17:56:50	coke0_:	you can trust robots
17:57:01	andytoshi:	sure, but robots can't trust us
17:57:12	coke0_:	yeah they can
17:57:25	andytoshi:	i think that's general-AI-complete
17:57:55	coke0_:	your bank has many robots deciding whether to trust you or not
17:57:59	coke0_:	they're flawed
17:58:07	coke0_:	but they do useful work
17:58:19	andytoshi:	the robots aren't in charge of trust tho, that's why i have to show up in person with a bunch of ID whenever i do stuff
17:58:26	coke0_:	so even limited AI can build some useful amount io trust
17:58:32	andytoshi:	and the bank gives me a chip with a signing key which the humans make sure is associated to my account
17:58:40	coke0_:	andytoshi: not so
17:59:15	coke0_:	there are many automated authentication methods based on asking you personal questions
17:59:29	coke0_:	the guarantees aren't great
17:59:38	coke0_:	but it beats guessing
18:01:09	andytoshi:	the guarantees aren't sufficient for autonomous transactions. before bitcoin a robot could not run a hosting service because the humans could take its money away
18:01:33	andytoshi:	eg call up the CC company and chargeback a transaction from months ago. the CC company will always take your side and the robot can't go to court because it has no rights
18:01:45	coke0_:	true enough
18:02:32	andytoshi:	plus i think there is a growing animosity toward robots because they are taking a lot of menial jobs..
18:02:47	coke0_:	but you could set one up accepting egold
18:02:50	tromp:	and kicking my butt playing go:(
18:03:03	coke0_:	so it's not about trust
18:03:26	andytoshi:	sure it is, then the robots are trusting the egold guy
18:03:32	coke0_:	yes
18:03:37	coke0_:	and in practice
18:03:41	coke0_:	it would have worked
18:03:42	andytoshi:	and what happens when the villagers storm him for enabling a robocracy?
18:04:05	coke0_:	what happens when the villager storm ghash.io?
18:04:12	helo:	math is robocracy, good luck storming that
18:04:19	andytoshi:	then i'd hope they lose a lot of hashpower
18:04:48	andytoshi:	but to be clear, i'm not claiming that bitcoin today achieves the kind of decentralization that i want
18:05:20	andytoshi:	i am claiming that it is necessary unless you want all the robots to be beholder to the Robot Masters who are the ones controlling the currency
18:05:50	andytoshi:	actually that is a situation we have had with humans and Human Masters for a long time and it is not good for humanity
18:05:52	coke0_:	bitcoin isn't math based, it's based on game theory
18:06:48	coke0_:	the balance of incentives is the part that really makes it tick
18:07:00	coke0_:	the crypto in it is relatively trivial
18:07:25	coke0_:	at least for 2008 of course
18:08:53	helo:	both ofc
18:10:26	wumpus:	game theory is part of math
18:10:34	sipa:	sure
18:10:55	coke0_:	yeah but then you can call any corporation "math based"
18:11:13	coke0_:	it's a silly monicker
18:11:14	maaku:	pretty sure the underlying physics of the universe is "math based"
18:11:16	sipa:	but the point is valid: bitcoin ultimately does not rely on infeasible-to-break-despite-the-cost assumptions, which is what crypto usually does
18:11:18	wumpus:	you actually can, math is everywhere -- not sure what you're really arguing
18:11:39	sipa:	and it does rely on it being too costly (directly or indirectly) to perform certain attacks
18:11:46	coke0_:	yep
18:12:59	coke0_:	math doesn't like mutable variables
18:13:13	coke0_:	they belong in the physical world
18:13:19	coke0_:	currency is mutable
18:13:30	coke0_:	information isn't
18:13:40	maaku:	coke0_: model differences. the map is not the territory
18:14:06	wumpus:	I don't think a consensus problem can ever be infeasible-to-break-despite-the-cost, I mean if a significant part of the stakeholders wants something else, than your assumptions are broken, not so much the algorithm
18:15:01	coke0_:	well consensus is ultimately needed because of statefulness
18:15:32	coke0_:	you could have statefulness without consensus using centralization
18:15:42	coke0_:	but of course that's prone to a lot of issues
18:16:14	wumpus:	in centralization the consensus is 'trust a single actor'
18:16:25	coke0_:	but in the end, money requires maintaining a Singleton, which i strongly suspect is not something math can do
18:16:39	wumpus:	if people suddenly don't trust that actor anymore, it falls apart, as we've seen...
18:17:07	coke0_:	not a fair comparison
18:17:24	coke0_:	you're confusing consensus about the algorithm
18:17:29	coke0_:	and within the algorithm
18:17:30	sipa:	there are still various degrees of trustlessness in between
18:17:51	wumpus:	I'm not confusing anything, I just don't see them separate
18:17:55	coke0_:	in the centralized solution the algo is : trust that guy
18:18:04	coke0_:	there is no consensus needed
18:18:16	wumpus:	trusting that guy *is* a consensus between people
18:18:19	coke0_:	and you have hard guarantees conditional on
18:18:27	coke0_:	honesty of trusted party
18:19:02	coke0_:	wumpus: you always need to bootstrap consensus for any kind of communication
18:21:58	whatever:	whatever is now known as Guest38711
18:24:19	ebfull:	question regarding amiller's non-outsourceable puzzles: can't the pool _prove_ they are not stealing from the miner, and thus solicit miners to the pool with that trust?
18:24:22	diesel_:	diesel_ is now known as Dizzle
18:25:39	ebfull:	i understand the block doesn't encode this information but couldn't it be constructed separately by the pool?
18:26:00	coke0_:	couldn't you detect a dishonest host statistically?
18:26:16	coke0_:	if the pool doesn't pay the market average it's fishy
18:26:59	ebfull:	coke0_: talking about https://bitcointalk.org/index.php?topic=309073.0
18:27:09	coke0_:	yes
18:27:29	ebfull:	oh i see what you mean, yeah i think gmaxwell touched on that in his response
18:27:30	coke0_:	it's very elegant
18:27:42	coke0_:	but in practice...
18:27:49	ebfull:	however i think even if that wasn't possible, there'd still be a problem in that one party can prove they're not being dishonest
18:28:01	ebfull:	even with a ZKP if they have to
18:29:20	coke0_:	more and more CPU power is moving to the cloud anyway, not just mining q
18:29:46	coke0_:	when dumb terminals are the norm, then what
18:29:54	ebfull:	the hope is that is a temporary phenomena
18:30:44	coke0_:	you could have a captcha proof of work by the way, using some weird crypto
18:31:20	gmaxwell:	Not without additional assumptions beyond "weird crypto"
18:31:41	gmaxwell:	I'm not aware of any way to achieve it in the anonymous model.
18:31:47	coke0_:	cryptographic obfuscation
18:31:54	gmaxwell:	No, that doesn't do it.
18:32:53	gmaxwell:	(with enumerated members you can use members-MPC to generate the challenge image..., but I'm not aware of any way to do the MPC without membership)
18:33:21	coke0_:	you need trusted setup
18:33:27	coke0_:	but basically
18:33:30	gmaxwell:	coke0_: obfuscation has a trusted party that knows the secret too, even though the secret is hidden from the user.
18:33:50	coke0_:	well just like zerocash
18:33:57	coke0_:	but it's a one off
18:34:00	gmaxwell:	not at all like zerocash.
18:34:14	coke0_:	hear me out then
18:35:08	gmaxwell:	yea you'd make a capcha generator circuit that H(secret||input) to form the captcha and it outputs the captcha.. and a sister circuit that checks answers.
18:35:17	coke0_:	you write a function that takes a number, forms a hmac out of it and then outputs: a diformed image of the hmac
18:35:23	coke0_:	a hash of the answer
18:35:35	coke0_:	and the next number to be used
18:35:43	coke0_:	you obfuscate that function
18:35:46	coke0_:	and there you go
18:35:54	gmaxwell:	right you can't give a hash of the answer, or it's just a POW problem grinding that hash.
18:35:54	coke0_:	captcha based pow
18:36:02	coke0_:	yeah
18:36:13	coke0_:	but can be ridiculously hard
18:36:31	coke0_:	make the captcha 256 bits long
18:36:36	hearn:	captchas are broken for a long time already
18:36:50	coke0_:	yeah that's an issue
18:36:50	gmaxwell:	coke0_: man I can't even solve short ones half the time myself.
18:37:05	andytoshi:	i should maybe interject that you can't just obfuscate things, virtual black-box obfuscation is impossible and indistinguishability obfuscation is a PITA to prove with
18:37:20	hearn:	at google they were used only as a fallback throttle in case the "real" systems failed
18:37:33	andytoshi:	the nasty captchas that go to tor users i gat get maybe 10% of the time. the easy ones about 2/3 of the time
18:37:54	coke0_:	andytoshi: uh there is crypto obfuscation as of a short while
18:37:55	andytoshi:	google's google.com captchas i have a good time with actually
18:37:59	gmaxwell:	also the only id-obf suggested that is known to me uses FHE as an inner step. So you'll need some spare universes to run it.
18:38:12	andytoshi:	coke0_: yes, i am doing phd work on that
18:38:21	coke0_:	oh my bad then
18:38:33	hearn:	coke0_: it's a long way from being a nice c++ toolkit you can download and play with
18:38:40	coke0_:	but imagine the mining farms in China
18:38:42	coke0_:	brutal
18:38:45	andytoshi:	np, there is a huge temptation to assume you can bolt obfuscation onto stuff
18:38:47	gmaxwell:	though yea, I was too harsh in my example, assuming IDOBF was usable you could do a captcha pow.
18:39:13	andytoshi:	(probably. it would take a lot of work to design and prove.)
18:39:18	gmaxwell:	(assuming you could make the captcha big enough to prevent grinding)
18:39:44	gmaxwell:	and that you also invoke a ZKP in the block finder to avoid rebinding.
18:40:11	coke0_:	are there any other problems hard for computer to solve but easy to human to solve
18:40:13	hearn:	modern captchas are all OCRable anyway, pretty much. even the hard ones.
18:40:25	hearn:	so it'd just turn into a complicated way of burning cpu time again
18:41:04	andytoshi:	coke0_: i think playing go is still on the edge. and then there's things like building trust, love, etc, but those are really expensive to verify
18:41:05	hearn:	coke0_: well .... there have been many such examples, classicly. the problem is we keep building kickass software that can do as well as humans.
18:41:37	hearn:	coke0_: i have toyed with the idea of using ZKPOPs and streams of signatures as a different way to do consensus in the past. that's almost like what you're asking for.
18:42:14	hearn:	coke0_: the idea is you create a ZKP using SCIP that verifies you have a valid e-Passport certificate that hashes to the given value, and binds it to a public key. now you can use that public key to sign in an anonymous way, but it's still "one key one person"
18:42:30	wumpus:	and then? you'd get human-based mining in huge sweatshops?
18:42:40	gmaxwell:	yea, chinese baby farms
18:42:55	coke0_:	mice
18:43:00	wumpus:	I mean, there are already huge capcha solving operationg in India and such
18:43:02	hearn:	wumpus: well, if you can afford to pay them off i guess
18:43:24	wumpus:	so it's not something out of science fiction...
18:43:31	hearn:	if you want to be brutal about it, you can selectively reveal the country
18:43:38	coke0_:	hearn: nice
18:43:38	hearn:	and then exclude countries where people are easily bought :)
18:43:51	gmaxwell:	I like the usenix paper where they figure out the lanaguge of the captcha solvers.
18:44:01	hearn:	wumpus: actually Pakistan is where the big captcha farms used to be, when i worked on it
18:44:02	gmaxwell:	(by sending captchas in varrious languages)
18:44:18	gmaxwell:	.. and then they tried klingon and one of the services solved that too.
18:44:19	hearn:	captcha solving is a really shitty business. the going rate was $1 per thousand captchas
18:44:26	coke0_:	but
18:44:28	wumpus:	gmaxwell: I remember that paper :)
18:44:41	coke0_:	you need a static passport db no?
18:44:52	hearn:	no. e-Passports contain an SSL-like certificate chain
18:45:05	hearn:	any passport dump can be proven valid in isolation, if you know each countries public key
18:45:08	gmaxwell:	coke0_: the idea is to give a per service ID which is one ID per user. but without the service ever learning the ID<>user mapping.
18:45:12	coke0_:	so still need to trust the country of course
18:45:22	hearn:	which are available in various lists on the internet (though oddly there doesn't seem to be a canonical db - the lists are incomplete)
18:45:49	hearn:	coke0_: yes if a country decides to start creating fake passports in bulk then you lose. revealing the countries could potentially help detect that.
18:46:19	hearn:	though almost by definition fixing that kind of thing is hard without going outside the consensus mechanism. it's like if a country decided to start fabbing ASIC hardware in bulk. even if it could be detected, how do you come to the decision to exclude them?
18:46:33	hearn:	(ignoring that miners can't be excluded in bitcoin)
18:46:41	coke0_:	they can though
18:46:56	hearn:	how?
18:47:12	coke0_:	you start signing blocks
18:47:19	coke0_:	I know it's not bitcoin anymore
18:47:23	hearn:	when i said, "in bitcoin" i meant the existing bitcoin :)
18:47:31	coke0_:	just thinking of what wild happen in practice
18:47:38	hearn:	* hearn shrugs
18:47:53	hearn:	let's say the country is revealed as a public input to the ZKP
18:48:16	hearn:	now if there's a sudden, unbelievable spike in the number of miners from a certain country, we can at least strongly suspect they're trying to interfere with the consensus
18:48:35	hearn:	worst case: that country could be excluded entirely, via everyone choosing to upgrade to a version that ignored them
18:48:50	coke0_:	are there competitions for reverse Turing tests?
18:49:03	coke0_:	machine trying to out opponent as machine or human
18:49:04	hearn:	this is better than what bitcoin allows. in bitcoin, if a country starts screwing with the consensus, it's basically game over: most countries can outspend the global mining community
18:49:27	hearn:	in practice national governments overwhelmingly prefer to screw with bitcoin and other cryptocurrencies via the banking system
18:49:36	hearn:	they're run by politicians, not crypto geeks. so that sort of thing doesn't worry me a whole lot.
18:49:39	coke0_:	could you get something like that based on lag?
18:49:49	wumpus:	right, social engineering is so much cheaper
18:49:59	hearn:	coke0_: there are no such competitions AFAIK, however writing a system that does that used to be my job
18:50:18	coke0_:	what was your job?
18:50:31	hearn:	coke0_: i spent a couple of years at google designing and building something called botguard. it was an automated system that detected spambots abusing our web apps. trying to sign up for gmail accounts automatically, create spam blogs, click on adsense links etc
18:50:47	coke0_:	oh right
19:25:01	hobana.freenode.net:	topic is: This channel is not about Bitcoin today | "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi."
19:25:01	hobana.freenode.net:	Users on #bitcoin-wizards: andytoshi-logbot Vitalik_ Ursium gonedrk andyqwebi MoALTz mr_burdell quickcoin tjopper gloriusAgain Dizzle wallet42 edulix licnep_ caedes digitalmagus posita gavinandresen Hunger- jaekwon DougieBot5000 mappum _ingsoc altoz zack1 WalterA ghtdak hearn george_p Burrito dexX7 coke0_ Quanttek prepost torsthaldo OneFixt roconnor__ stonecoldpat samson_ LarsLarsen eristisk arubi rdponticelli TheSeven melvster spinza_ a5m0 ebfull shinybro Sangheili
19:25:01	hobana.freenode.net:	Users on #bitcoin-wizards: qwertyoruiop bobke nsh jchp Fundraise espes__ Emcy davidlatapie johndriscoll pajarillo burcin c0rw1n realz ericp4 emsid ewust Eliel [Derek] pigeons maaku tacotime Cory justusranvier nikitab Luke-Jr jcorgan dsnrk d34th lnovy wumpus ageis forrestv Logicwax [Tristan] lechuga_ petertodd Apocalyptic lianj heakins roasbeef comboy LaptopZZ_ keus ryan-c midnightmagic @ChanServ epscy iddo copumpkin sl01 justanotheruser BCB Muis UukGoblin optimator
19:25:01	hobana.freenode.net:	Users on #bitcoin-wizards: otoburb mhanne lenticulis quackgyver phantomcircuit rs0 poggy BlueMatt EasyAt weex flammit zenojis [\\\] coryfields Fistful_of_Coins harrow warren mumu gribble stqism waxwing artifexd Graet kinlo so stephenreed DoctorBTC tromp amiller michagogo kiddouk Mikalv mmozeiko hno zibbo jaromil kanzure HM Dyaheon- helo K1773R Anduck gmaxwell go1111111 sipa Kretchfoop Alanius coyo nanotube Krellan crescendo dgenr8 asoltys dansmith_btc nickler alferz
19:25:01	hobana.freenode.net:	Users on #bitcoin-wizards: cajg
19:46:25	maaku:	coke0_: isn't that what proof of stake is?
19:46:46	maaku:	there is no concept of chain length
19:47:01	coke0_:	there is a concept of best chain
19:47:14	maaku:	no, there isn't, which is the problem
19:47:25	coke0_:	uh yeah there is?
19:47:30	maaku:	given two alternate histories, which one is valid?
19:47:45	coke0_:	the one with the most signatures for instance
19:47:57	maaku:	but signatures are ~zero cost
19:48:02	coke0_:	whether you can enforce no double signing is another story
19:49:19	coke0_:	the question is whether there is a way to compactly prove the chain's weight
19:49:51	coke0_:	as in: here's a proof that if you follow that chain from the Genesis block you'll count X signatures
19:50:49	andytoshi:	fwiw it's easy to construct a system where double-signing exposes the key
19:51:20	andytoshi:	i don't recall where we landed on preventing stake-grinding
19:51:30	andytoshi:	i guess, the more miners you need to participate, the harder that gets
19:52:33	andytoshi:	(and the harder it is to keep control, since, you need to own a majority of required signing keys for every block)
19:53:41	coke0_:	you could cut any chain dominated by another chain over a period of N blocks
19:53:53	andytoshi:	so say, you have 1% of the stake, if there's only one sig needed you just have to grind through 100 candidates for every block to keep control. but if you need 3 of 5 now that spikes to a 1000000 candidates
19:54:46	andytoshi:	coke0_: that's dangerous because you can wind up with two forks, neither of which dominates the other, and to maintain this state you only need to make up the difference between their strength
19:55:01	andytoshi:	whatever "strength" means, in PoW it'd be hashpower
19:55:03	coke0_:	no not dominate completely, just by sum
19:56:09	coke0_:	makes the grind impossible if you can maintain randomness for N bock
19:56:33	andytoshi:	you only need one blocks' worth of input to the random seed
19:56:41	andytoshi:	djb had a blog post recently about poisoned entropy
19:56:43	coke0_:	in some models yes
19:56:54	coke0_:	in others no
19:57:01	coke0_:	slasher for instance
19:57:32	coke0_:	still bounded to a fixed number of blocks
19:57:45	coke0_:	but not just 1
19:59:02	maaku:	coke0_: the point is you only need control over 1 block
19:59:12	maaku:	that is sufficient to grind
19:59:23	andytoshi:	if you don't mix entropy this can be avoided.. say if each of the last ten blocks determine one of ten required signers
20:01:56	andytoshi:	if you did that, and also had double-signing-reveal-key, and your stake rewards were perpetuities, that would be an interesting proposal
20:03:47	andytoshi:	oh, derp, you can still grind your blocks so that you have control over every tenth block
20:04:01	andytoshi:	and then you wind up with an oligarchy of ten
20:04:03	coke0_:	you can make it 10,000 blocks
20:04:33	andytoshi:	sure, but the point is that the stake rewards will be taken over
20:04:40	coke0_:	and make the seed depend on a series of bocks in the past
20:04:49	coke0_:	look up slasher
20:06:11	andytoshi:	where is the signer-choosing code?
20:06:38	coke0_:	or even use some agreed upon real world events to add entropy
20:06:50	coke0_:	you could get by with a couple bits a day
20:08:45	andytoshi:	to be clear, this is the reason i'm saying one block is sufficient to grind: http://blog.cr.yp.to/20140205-entropy.html
20:09:01	coke0_:	I don't see the point of revealing the key on double sign
20:09:31	coke0_:	andytoshi: slasher takes care of this pb
20:09:38	coke0_:	entropy is added in two stages
20:09:42	coke0_:	with precommit
20:10:04	andytoshi:	that doesn't address my concern
20:12:46	andytoshi:	also the point of preventing double-spends is to discourage rewriting history even in the case that a single attacker gets ahold of all the keys he needs to do so
20:13:28	andytoshi:	but i guess, if we can keep miners honest at the tip, that'll cover that
20:13:51	andytoshi:	because if they weren't able to cheat the first time around, they won't be able to cheat long after the fact
20:21:37	maaku:	there's still the problem of knowing which chain to trust on synchronization
20:50:14	coke0_:	there's basically two problems which seem related but are sightly distinct
20:51:39	coke0_:	one is short chain double spending, trying to get signers at the tip to start signing your new fork
20:52:05	coke0_:	the other is history rewriting in secret, a long time after the fact
20:52:39	coke0_:	similar problems but in practice different actors, different incentives and different mitigations
21:17:15	jgarzik:	andytoshi, maaku: NXT appears to be open source?
21:17:21	jgarzik:	(RE conversation from many hours ago)
21:22:11	andytoshi:	oh?
21:23:05	justanotheruser:	maaku: why? What did the NXT people have to say at the booth?
21:24:35	andytoshi:	coke0: an important distinction, i'd expect the mechanism to be the same for both cases though.
21:28:05	andytoshi:	that is, i wouldn't expect the mitigations to be that different
21:30:13	nsh:	andytoshi-logbot, pointer?
21:30:13	nsh:	See http://download.wpsoftware.net/bitcoin/wizards/2014-05-29.txt
21:32:12	nsh:	oh, you applied geocitie^Whtml
21:32:20	nsh:	will have to change the pointer url template again :)
21:39:50	maaku:	justanotheruser: they had zero knowledge of any of the issues involved with proof of stake, and weren't technical people anyway
21:41:15	maaku:	jgarzik: yes, I think they open-sourced a few months ago. the construction is extremely review-hostile, however, and hasn't been worth me spending the time to look at
21:43:11	justanotheruser:	maaku: That's weird.
21:46:34	wilhelm.freenode.net:	topic is: This channel is not about Bitcoin today | "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi."
21:46:34	wilhelm.freenode.net:	Users on #bitcoin-wizards: andytoshi-logbot tacotime jgarzik nessence andytoshi Vitalik_ Ursium gonedrk MoALTz mr_burdell quickcoin tjopper Dizzle wallet42 edulix caedes digitalmagus posita Hunger- jaekwon DougieBot5000 mappum zack1 WalterA ghtdak george_p Burrito dexX7 Quanttek prepost torsthaldo OneFixt roconnor__ stonecoldpat samson_ LarsLarsen eristisk arubi rdponticelli TheSeven melvster spinza_ a5m0 ebfull shinybro Sangheili qwertyoruiop bobke nsh jchp
21:46:34	wilhelm.freenode.net:	Users on #bitcoin-wizards: Fundraise espes__ Emcy davidlatapie johndriscoll pajarillo burcin c0rw1n realz ericp4 emsid ewust Eliel [Derek] pigeons maaku Cory justusranvier nikitab Luke-Jr jcorgan dsnrk d34th lnovy wumpus ageis forrestv cajg alferz nickler dansmith_btc asoltys dgenr8 crescendo Krellan nanotube coyo Alanius Kretchfoop sipa go1111111 gmaxwell Anduck K1773R helo Dyaheon- HM kanzure jaromil zibbo hno mmozeiko Mikalv kiddouk michagogo amiller tromp
21:46:34	wilhelm.freenode.net:	Users on #bitcoin-wizards: DoctorBTC stephenreed so kinlo Graet artifexd waxwing stqism gribble mumu warren harrow Fistful_of_Coins coryfields [\\\] zenojis flammit weex EasyAt BlueMatt poggy rs0 phantomcircuit quackgyver lenticulis mhanne otoburb optimator UukGoblin Muis BCB justanotheruser sl01 copumpkin iddo epscy @ChanServ midnightmagic ryan-c keus LaptopZZ_ comboy roasbeef Logicwax [Tristan] lechuga_ petertodd Apocalyptic heakins lianj
21:46:38	andytoshi:	andytoshi-logbot, pointer?
21:46:38	andytoshi:	See http://download.wpsoftware.net/bitcoin/wizards/2014-05-29.html
21:59:12	maaku:	justanotheruser: the stuff that andotoshi just wrote up, I mean (nothing at stake, costless simulation, etc.)
22:27:05	whatever:	whatever is now known as Guest7340
22:31:14	Eliel:	The understanding I got from NXT forging algo is that it's not possible to use brute force to find block that gives you an advantage.
22:35:17	maaku:	Eliel: is there a proof of that?
22:35:57	Eliel:	you first make a transaction, then you wait ~1400 blocks and after that you have a chance at making a block.
22:36:20	Eliel:	you then form a block signing key from your private key + some data in transaction
22:36:21	justanotheruser:	Eliel: so you need 1400 different outputs you can redeem
22:36:26	Eliel:	that you made 1400+ blocks ago
22:36:54	maaku:	that doesn't sound impossible
22:37:01	Eliel:	there's nothing that works as a nonce you can keep changing
22:37:28	Eliel:	they call it transparent forging
22:37:49	Eliel:	you can basically tell in advance which transaction can make the next block and when
22:38:08	justanotheruser:	Eliel: you can make a tx that keeps spending to a different hash until the block evaluating it makes you win
22:38:48	Eliel:	justanotheruser: by the time you have a chance at forging, that transaction will be 1400+ blocks deep
22:38:58	Eliel:	no changing it anymore at that point
22:39:19	maaku:	Eliel: perfect. so i buy or otherwise aquire the signing keys to 1400 consecutive blocks in the past, and now I am able to reorg from then while keeping control of all future blocks
22:39:21	justanotheruser:	Eliel: It doesn't have to be the tx you use to forge the stake
22:40:40	Eliel:	I mean, everything that affects the selection of who forges the next block is decided at least 1400 blocks before the forging happens.
22:41:09	maaku:	Eliel: you don't seem to be grasping that an attacker can go back and rewrite history
22:41:14	Eliel:	after that, the only thing the forgers can do that affects who can forge the next block is to choose whether to forge the block or not
22:42:04	Eliel:	maaku: I don't fully understand NXT yet. I'm not arguing, I'm trying to explain how it works since people here didn't seem to know.
22:42:53	Eliel:	maaku: but yes, if you can get keys for enough consecutive blocks, you can basically rewrite the chain after that.
22:43:22	Eliel:	it's probably much more than 1400 on average though
22:48:14	Eliel:	I think that for an unquestionably workable PoS, the private keys need to be protecting something valuable outside the system as well. Something that'd make it expensive if they key got to wrong hands.
22:48:57	justanotheruser:	proof of blackmail?
22:49:03	maaku:	which is basically saying that stake (in the system) isn't protecting it, that external thing is
22:49:09	coke0:	perpetuities :)
22:50:31	coke0:	the point of stake is deciding who makes gets to sign, at that time. the mechanism protecting the signature may itself be different
22:50:35	Eliel:	maaku: still, it's much harder to acquire a certain strict set of keys than just simply enough stake.
22:51:30	Eliel:	just one person in the mix who makes it a habit to "burn" the keys after use each time and it'll be impossible.
22:52:06	Eliel:	well, ok, depending on how much stake that person has
22:52:29	coke0:	and even if there's a long reorg
22:52:38	coke0:	it's going to show
22:53:09	Eliel:	NXT refuses to reorg more than 700 blocks IIRC
22:54:38	coke0:	real people are going to react, hopefully sanely. When you come online for the first time, you should double check to make sure you're on the same chain as everyone else. If you've been online for a while and you see a long reorg
22:54:43	coke0:	you don't accept it
22:55:10	nsh:	--
22:55:11	nsh:	We are all familiar with the economic activity enabled by secure
22:55:11	nsh:	communication: negotiations, contracts, transactions, sales and commands can be sent on the
22:55:11	nsh:	public Internet with no fear of forgery or interception. We are also familiar with the financial
22:55:11	nsh:	consequences when key material is lost, or stolen.
22:55:17	nsh:	-- andytoshi, optimist...
22:55:19	nsh:	:)
22:55:27	coke0:	or even safer, you stop accepting payments until the situation resolves
22:55:38	nsh:	(sorry, only meant to quote up to "no fear of forgery or interception".)
22:56:17	coke0:	only incentive for long reorgs is vandalism really
22:56:37	coke0:	not dbl spending
22:57:26	justanotheruser:	Eliel: if it refuses to reorg, then consensus can be broken
22:57:43	justanotheruser:	anyone offline during those 700 blocks will have a different chain
22:58:09	justanotheruser:	or at least those given that different 700 fork will be
22:58:57	maaku:	"rules" against reorgs don't work
22:59:24	maaku:	now you can network attack someone coming online for the first time or after a long while, and get them on your fork
22:59:37	maaku:	now they are isolated -- they will alway reject the "real" chain
23:00:37	justanotheruser:	The cost of attacking NXT seems to be 1400*(dust tx size) + cost of grinding 1400 blocks + cost of a few EC2 instances with a ton of peers running NXT
23:11:49	coke0:	very, very theoretically the cost of attacking a PoS system can always be 0
23:13:28	coke0_:	so people are likely to sell to you now at a low price
23:13:43	coke0_:	so your chance of success increases
23:13:52	coke0_:	etc
23:14:48	coke0_:	with purely rational economic actors the price drops to 0 on the expectation that someone might do that
23:16:07	Eliel:	NXT system is a bit too complex to my liking. The last time I tried to get my head around it I had to give up midway because my mind couldn't take any more info in.
23:20:39	Eliel:	justanotheruser: I don't think dust tx will do. Your chance to use a tx to forge a block begins after around 1400 blocks but getting the chance is not automatic.
23:21:14	Eliel:	it could well take tens of thousands if not hundreds of thousands of blocks before you'll get that chance with your average dust tx
23:21:49	Eliel:	Also, I'm not sure why you think tons of nodes are needed.
23:36:12	justanotheruser:	Eliel: it isn't automatic, that's why it has to be grinded for
23:36:41	justanotheruser:	Eliel: I think a ton of nodes are needed if I want to convince new members of the network to use my fork :)
23:38:05	Eliel:	justanotheruser: you're missing that you need at least 1400 consecutive blocks to be yours to even be able to begin grinding.
23:38:49	justanotheruser:	Eliel: no, I need one block to grind the block 1400 after it
23:39:08	justanotheruser:	then I can continue to accumulate blocks until I have 1400
23:40:06	Eliel:	oh, you're right. I missed that.
23:40:41	justanotheruser:	Also, I am only grinding for having a high chance of winning the block. I can win any block given that I wait an infinite amount of time.
23:40:51	justanotheruser:	infinite amount of time between blocks I mean
23:41:17	phantomcircuit:	justanotheruser, both ways are correct technically
23:41:39	phantomcircuit:	if you can wait an infinite amount of time 1 Gh/s is enough to reverse an infinitely old transaction
23:42:01	phantomcircuit:	(or is it? I'm too lazy to check if it converges...)
23:42:54	Eliel:	phantomcircuit: well, no, the target will keep going further and further away.
23:43:12	Eliel:	because other hashers will be hashing with much more power
23:43:25	phantomcircuit:	Eliel, well yeah, but if it converges then even one hash per second is enough if you can literally wait forever
23:44:12	phantomcircuit:	in a few 2^1024 years you'll get lucky and find 1m blocks in a row
23:53:08	Eliel:	justanotheruser: it's not quite that simple though. The Nxt forging path is deterministic assuming the most likely forger always forges, but from time to time that doesn't happen. There's unpredictable branching in the mix due to that.
23:54:06	Eliel:	in case that forger doesn't forge, then the next in line gets to forge.
23:55:25	justanotheruser:	Eliel: when you're rewriting history you don't let the next in line forge
23:55:39	Eliel:	justanotheruser: you don't have a choice here
23:55:48	Eliel:	unless you're alreay rewriting everything
23:55:57	Eliel:	but you first need to get there
23:57:14	justanotheruser:	Eliel: To get my first 1400 I only need to wait until an output I own is "next in line" to forge