00:32:31	home_jg:	ebfull, amiller, kjj: bounty payment sent, txid 97257558d7402033ba41fd671fdfdde23b77918a64664523f1415fe246b06a6c
00:32:38	home_jg:	home_jg is now known as jgarzik
03:24:41	jcrubino:	is nlock time reinstated into the standard client protocol?
04:29:55	jps_:	jps_ is now known as jps
05:14:03	maaku:	jcrubino: nlocktime has always been part of the protocol
05:14:09	maaku:	also, #bitcoin-dev
06:47:13	ericp5:	ericp5 is now known as ericp4
08:02:43	hearn_:	hearn_ is now known as hearn
08:13:35	quickcoin23j23j:	quickcoin23j23j is now known as quickcoin
15:38:07	sl01:	screen -x
16:34:31	ajweiss_:	ajweiss_ is now known as ajweiss
17:34:35	mapppum:	mapppum is now known as mappum
20:04:30	ghtdak:	ghtdak has left #bitcoin-wizards
21:10:22	zack-bitcoin:	im bad at irc. this might be repost. I am trying to make a secure cryptocurrency without any proof-of-work https://github.com/zack-bitcoin/slasher It is based off of slasher to solve the nothing-at-stake problem. http://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/ It can run 5 nodes on your computer and maintain consensus between them.
21:11:54	maaku:	zack-bitcoin: slasher doesn't solve the nothing-at-stake problem btw
21:13:53	zack-bitcoin:	I realize that slasher as stated in the blog post does not solve nothing-at-stake. My implementation has a census block every 2000th block which requires 40% of all coin-holders to sign. This is one of the ways to fix slasher.
21:15:50	Eliel:	zack-bitcoin: that sounds somewhat dangerous... what happens when the amount of lost coins approaches 60% or goes over it?
21:16:42	gmaxwell:	zack-bitcoin: That doesn't sound like it stops simulation. Imagine at time 10 maaku and I have >50% stake. We mine. Then by time 15 we sell off or stake and leave the network. At time 1000 our keys fall into evil hands, and the evil party goes back to time 10 and constructs a new complete network history? (really, I think the costlessness of creating an indistinguishable simulation is the most fundimental example of nothing at stake)
21:19:54	Eliel:	reading stephen reed's cooperative proof of stake reminds me of what my own half baked idea. It was essentially a massively entangled authenticated tamper-proof log.
21:20:11	zack-bitcoin:	We could distribute the initial coins evenly to 100+ people, and do our collective best to make sure no individual gains more than 50% stake at any time in the last 2000 blocks. (about 2 weeks)
21:20:35	zack-bitcoin:	s/50% stake/40% stake
21:21:32	gmaxwell:	zack-bitcoin: but no individual had in my example, I fear you missed the point.
21:21:36	Eliel:	I'm slowly starting to understand the nothing at stake problem...
21:23:55	gmaxwell:	zack-bitcoin: you see after maaku and I left the system there was no incentive for us to protect our old keys— perhaps even someone bought them from us. If an attacker can amass keys that controlled a lot of stake in the past but don't anymore (not even 50% but whatever is needed to make the network go, sounds like 40% in your case) then they can just create an alternative history that a new peer couldn't distinguish.
21:25:57	maaku:	and if signer selection is done by deterministic algorithm over the block history (what else is available to delegate the problem to?), then the attack works for smaller sets of keys and grinding blocks to name yourself as a signer
21:27:03	Eliel:	gmaxwell: do you think PoS is at least useful to improve the 51% attack resistance of a PoW system?
21:27:09	zack-bitcoin:	There is a 2 week time period between census blocks, and the attacker needs to purchase keys from 51% of all coins holders, which will be dozens of people. It is very improbable to collect all these secrets.
21:27:38	gmaxwell:	zack-bitcoin: they have forever to do it— and why would it be hard? the keys are worthless after people left the system.
21:28:42	zack-bitcoin:	you deterministically elect accounts based upon how much money they had 2000 blocks ago. you cannot grind blocks to make yourself signer. census blocks are too close together to make it profitable. The earliest secret you don't know about is from 900 blocks ago.
21:28:44	gmaxwell:	maaku: what zack was saying sounded like it invoked a large quourum signature, which would limit the boost you can get from simulation mining. (otoh, it creates a vulnerability to obstruction)
21:29:12	zack-bitcoin:	the census blocks are a limitation. the census block is every 2000th block. 40% of all coin-holders have to sign it.
21:29:38	gmaxwell:	zack-bitcoin: you keep repeat this but you have yet to address my very simple example.
21:29:42	maaku:	zack-bitcoin: and if 61% of coins are offline/lost?
21:30:34	gmaxwell:	Eliel: maybe, the issue is that is seems every attempt to that end (including my own) creates new attacks. Obviously if there were actual majority hashpower attacks happening then they'd be more justified, but absent them so far none have sounded to me like a great tradeoff.
21:31:23	zack-bitcoin:	gmaxwell, I am trying very hard to answer your simple example... you are worried that old keys will not be protected, correct? That you can get 60% stake from a long time ago, and build a chain from that point?
21:32:11	Eliel:	so the root of the problem is that you can keep trying to rebuild the history without any real cost until you manage to do it...
21:32:15	gmaxwell:	zack-bitcoin: yes (well whatever stake is required to continue the network, in plain POS proposals you would only need a tiny amount, but hey— just assume I could get >half for the purpose of dicussion)
21:33:08	gmaxwell:	I could even, for example, buy up lots of coins myself at the point in time, and later rid myself of them, while stealing or buying up old keys from other people who have also since left the system.
21:33:52	Eliel:	(you could also run an exchange)
21:34:03	gmaxwell:	or hack one, or buy out the wallet of a defunct one.
21:34:03	Eliel:	and then later use those keys for the attack
21:34:08	zack-bitcoin:	census blocks could be hard-coded into the sourcecode as they happen, to ensure they are never re-produced?
21:34:35	sipa:	yup, centralization will solve all these problems
21:34:42	gmaxwell:	zack-bitcoin: then you haven't built a decenteralized consensus system. Why not dispense with the blockchain entirely?
21:35:07	jaekwon1:	gmaxwell: you're right, i believe there's nothing stopping a group from creating an alternative chain that is indistinguishable from the "correct" chain, in a pure PoS algorithm. but it is possible to ensure that such a fork doesn't happen within the past X blocks from now. Practically, this means users are responsible for reconnecting to the network every X blocks, or placing trust in nodes that are persistently connected.
21:35:16	jaekwon1:	zack-bitcoin: have you seen this? http://tendermint.com
21:35:41	gmaxwell:	jaekwon1: how are you repsonsible for connecting evey X blocks when you haven't even been born yet? :P
21:36:02	jaekwon1:	How does a new Bitcoin user even know that he's actually connected to the bitcoin network, and not some sham network?
21:36:44	gmaxwell:	jaekwon1: because they can keep connecting to more and more hosts, and if they _do_ ever connect, they'll reconize it. Information being hard to suppress is an explicit security assumption in Bitcoin.
21:37:04	gmaxwell:	(which all other systems have too)
21:37:05	jaekwon1:	that's only true if the sham network isn't disconnected from the true one.
21:37:41	gmaxwell:	the sham network can be disconnected but the user can't be persistantly partitioned from the honest network.
21:37:58	jaekwon1:	user can, if the client has been modified.
21:38:17	jaekwon1:	a new user has to trust.
21:38:21	gmaxwell:	if the client has been modified it might well just by a GUI on paypal. No promises of behavior can be made in that case.
21:38:28	gmaxwell:	No, a new user can audit their software.
21:38:44	jaekwon1:	lol.
21:39:00	gmaxwell:	Really?
21:39:19	jaekwon1:	a user who can audit his software also has the ability to find out what the "correct" chain is in a good PoS system
21:40:05	gmaxwell:	jaekwon1: There is no 'correct' chain within the defintion of the system, which is why its an example that that class of approach is broken.
21:40:15	jaekwon1:	there is, actually, in tendermint.
21:40:59	jaekwon1:	forks are possible, but one who always reconnects within X blocks in tendermint will always know what the "correct" chain is.
21:41:45	gmaxwell:	Under what assumptions?
21:43:34	gmaxwell:	Are you still using Zooko's bonded mining approach? It fails if the reorg just goes deeper the the bond duration.
21:43:41	maaku:	* maaku wishes we had a separate channel for proof-of-x discussions
21:43:52	jaekwon1:	practical assumptions, that validators are incentivized by coins, and that 1/2 or 2/3 of validators remain online, from one block to the next. 1/2 in the synchronous case, 2/3 for partially synchronous.
21:44:13	jaekwon1:	reorgs? there are no reorgs in the bitcoin sense.
21:44:35	gmaxwell:	gmaxwell has left #bitcoin-wizards
21:46:08	andytoshi:	maaku: i'd write an article about this but people consistently ignore the arguments presented, so i have no idea where the misunderstanding might be
21:46:35	jaekwon1:	what arguments?
21:47:23	jaekwon1:	anyways, jesus, i feel like others are ignoring my arguments. i'm telling you, pos consensus is practical, even in cryptocurrencies.
21:47:28	andytoshi:	the costless-simulation argument and specifically the "no 'correct' chain" argument
21:47:44	andytoshi:	jaekwon1: and you're wrong, and this has been explained to you over and over
21:47:56	jaekwon1:	have you actually read my paper?
21:48:02	andytoshi:	yes.
21:48:08	ebfull:	how are there no reorgs in tendermint?
21:48:15	ebfull:	if there are multiple paths to consensus, there has to be reorgs
21:48:17	jaekwon1:	define reorg, ebfull. then i can answer.
21:48:20	ebfull:	if forks are possible
21:48:39	jaekwon1:	right. no forks are possible given the assumptions about byzantine control of voting power.
21:48:43	jaekwon1:	you solve costless simulation with bonding.
21:49:03	maaku:	jaekwon1: your assumptions will fail. then what happen?
21:49:04	jaekwon1:	that gives you X blocks (unbonding period), like a bubble in time in which there is definitely consensus happening.
21:49:09	andytoshi:	andytoshi has left #bitcoin-wizards
21:49:32	jaekwon1:	anyone can identify the correct chain by staying in the bubble.
21:50:41	jaekwon1:	maaku: practically, human intervention should happen. same thing as when say, bitcoin's mining gets attacked by a 51% pool.
21:51:20	sipa:	it was human intervention that created bitcoin in the first place, and the choice to value it as well
21:51:30	sipa:	of course human intervention will happen if things go badly
21:51:49	helo:	does turning and running in the opposite direction of the algorithm count?
21:51:52	jaekwon1:	unlike as in mining, it's easy to identify who's attacking consensus in a PoS system. so in that sense maybe it's easier to recover from than bitcoin.
21:52:04	sipa:	but the exercise that i think many in this channel try to do is designing a system that doesn't need such interventions
21:52:35	jaekwon1:	yeah, well, it's probably not possible at all, even with mining.
21:53:27	sipa:	indeed
21:54:51	maaku:	jaekwon1: there is a difference between your system and bitcoin in this scenario
21:55:19	maaku:	with proof-of-work, the honest miners would stay on the old chain and eventually overtake the attacker, and all nodes will reorg back
21:55:35	maaku:	which sortof describes what happened in 2013
21:56:05	maaku:	that is to say that your average node will automatically get back on track with the correct consensus once the situation is resolved
21:56:09	maaku:	that is a very, very important property
21:56:23	jaekwon1:	eh, honest miners would switch to a new chain if it were longer. the only reason why they didn't in 2013 is because the "new" fork was invalid due to a bug, or something.
21:56:38	maaku:	jaekwon1: no, the "new" fork was not invalid in 2013
21:56:49	maaku:	it was actually more valid in a strict sense
21:58:33	jaekwon1:	https://bitcoin.org/en/alert/2013-03-11-chain-fork
21:59:08	jaekwon1:	the reason why the "old chain" remained and won out is because the other chain was invalid for them.
21:59:28	sipa:	the rule is that the longest valid chain wins
21:59:39	sipa:	if the software works correctly, no nodes disagree about which chain is valid
22:00:03	sipa:	non-resolving forks only appear due to bugs (or partitioning the network through other means)
22:00:35	maaku:	jaekwon1: i was here when that happened. we had a debate in #bitcoin-dev and aggreed to build off the pre-leveldb chain, even though the majority of the network had updated and it exhibited undocumented restrictions
22:02:02	jaekwon1:	i think you're arguing that pow mining is superior to pos in some sense because who "wins" is determinable post-facto by measuring the work done on each chain.
22:02:32	nsh:	* nsh frowns
22:02:59	jaekwon1:	* jaekwon1 grimaces
22:04:23	jaekwon1:	yet it's possible to construct the protocol such that forks don't happen in the first place.
22:04:45	jaekwon1:	given sane assumptions.
22:04:46	nsh:	a partitioned network is forked by definition
22:04:56	sipa:	i'm sure it is possible under some assumptions
22:05:00	nsh:	(and the network is always partitioned)
22:05:04	sipa:	i'm unsure about how sane they will be :)
22:05:10	nsh:	it just has very tiny tears most of the time
22:05:26	jaekwon1:	you always require 2/3 of votes on a block for it to be a "valid" block.
22:05:39	jaekwon1:	and you punish signers who sign twice at the same height.
22:05:51	jaekwon1:	now how do you get a fork, unless 1/3 or more get punished?
22:06:03	jaekwon1:	and, the punishment is pretty severe.
22:06:42	jaekwon1:	e.g. they lose all of their bonded coins.
22:07:06	jaekwon1:	so, assuming more than 1/3 never commits suicide, forks aren't possible.
22:07:35	sipa:	how will you be certain to learn about signers signing twice?
22:07:46	sipa:	or rather, how will everyone agree on which signers have signed twice
22:07:53	sipa:	actually, i should read the paper first :)
22:07:53	jaekwon1:	read the paper. http://tendermint.com
22:08:58	zack-bitcoin:	the tendermint paper is really long, and it uses language I am unfamiliar with. If it is so good, how come no one has made a simpler description?
22:09:14	jaekwon1:	hmm, what's confusing?
22:09:34	sipa:	sipa has left #bitcoin-wizards
22:09:41	stephenreed:	jaekwon1: I just skimmed your paper. I too reference the BFT survey. It looks like you modify the blockchain.
22:09:42	jaekwon1:	the language is partially motivated by literature in byzantine consensus protocols.
22:10:10	jaekwon1:	stephenreed: modify the blockchain? as in, it's different than bitcoin? yeah.
22:10:55	zack-bitcoin:	oh! tendermint is the pos bonds idea
22:11:05	jaekwon1:	yeah.
22:11:10	zack-bitcoin:	you want to let people puchase the ability to vote on future blocks?
22:11:40	jaekwon1:	as it is in the paper, that's what happens. other schemes are possible.
22:12:01	zack-bitcoin:	What if I buy a massive amount of bonds for a couple blocks, and on those exact couple blocks, I spend a ton of money, and then I use my massive amount of stake to double-spend?
22:12:33	jaekwon1:	if it's so massive that you actually cause a fork, you'd lose your massive bond.
22:13:00	jaekwon1:	as it is in the paper, human intervention would be required to recover from that, but your coins are lost either way.
22:13:33	zack-bitcoin:	I think that selecting pos signers at random is kind of like having everyone 100% invested in bonds all the time. It is more secure.
22:13:39	stephenreed:	jaekwon1: I need to go now, but I would like your critique of my whitepaper at https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE . I use peer attestation of tamper-evident logs to get BTF with less than 50% faulty peers.
22:14:20	jaekwon1:	ok, i'll read it. also, come to #tendermint if you want to discuss more of tendermint. seems like some people don't like PoS discussion here.
22:14:52	justanotheruser:	jaekwon1: scamcoins are off topic
22:14:55	jaekwon1:	zack-bitcoin: if you only require a small set of signers to sign at every block, then you end up with a chain that can be forked.
22:15:09	stephenreed:	jaekwon1: read this first - it has math http://iris.csail.mit.edu/irisbib/papers/aaom:sosp21/paper.pdf
22:15:16	jaekwon1:	justanotheruser: i agree that all existing PoS coins suck.
22:15:46	zack-bitcoin:	I think value units and stake units should be seperated. there should be only like 1000 units of stake. Each unit should be traceable.
22:16:02	stephenreed:	jaekwon1: Code will speak for itself - with enough good test cases.
22:16:52	jaekwon1:	zack-bitcoin: i've been thinking about that. that might be better, yeah. either way, i need to decide the *rest* of the coin, e.g. whether it has a turning complete language, a market, multiple coins, debt instruments, etc.
22:17:05	jaekwon1:	zack-bitcoin: please come to #tendermint later :)
22:17:44	sl01:	anyone understand what vitalik means by this "solution" for the proof of stake problem? One solution, for example, is to note that every block must have a timestamp, and users reject chains with timestamps that are far ahead of their own. A long-range attack will thus have to fit into the same length of time, but because it involves a much smaller quantity of currency units its score will be much lower
22:18:00	sl01:	from: http://blog.ethereum.org/2014/05/15/long-range-attacks-the-serious-problem-with-adaptive-proof-of-work/
22:18:13	jaekwon1:	yeah.
22:18:28	jaekwon1:	vitalik's PoS system still involves an element of PoW.
22:18:42	jaekwon1:	and that PoW, he's thinking, should involve data on teh blockchain.
22:18:43	sl01:	no i dont think this proposed solutin included pow at all
22:18:50	jaekwon1:	read slasher. it does.
22:19:16	sl01:	read that post, starting at Proof of Stake
22:19:35	sl01:	pretty sure those 2 solutions he porposes are for pure PoS
22:19:50	sl01:	he goes on later to mention hybrid
22:20:15	jaekwon1:	oh
22:20:20	jaekwon1:	gotcha.
22:20:27	arubi:	sl01, I think it's because coin age is absolute in a certain X time
22:20:50	sl01:	ah, so timestamp is something derived from coin age?
22:21:01	arubi:	even if you generate X10 more blocks in a certain time, those blocks would still have the same coin days destroyed in them
22:21:19	sl01:	yea ok i think that makes sense
22:21:22	arubi:	and more fees are being wasted
22:21:58	arubi:	yea, it's a kinda "guard" against honest parties that want to generate more blocks, but it doesn't solve malicious parties
22:22:17	arubi:	(who don't care about the value of their stake)
22:22:24	jaekwon1:	you're right. if you try to measure blockchain "score" or "fitness" by adding up the amount of stake votes, then you have a problem because blocks are easy to create. e.g. such a "score" or "fitness" of the blockchain is gameable. the solution is to make blocks "precious", and vitalik's idea is to limit them by time.
22:22:58	zack-bitcoin:	If block-reward is negative, we don't need to worry about blocktimes or difficulty or POW. People wont make blocks until it is economically viable.
22:23:40	jaekwon1:	that's still tricky. you need to prevent double spends to really make it economically unviable.
22:24:29	arubi:	I think the hardest problem with a consensus network (such as pos scheme coins) is censorship.. can't think of one implementation that addresses that
22:24:47	zack-bitcoin:	censorship?
22:24:55	jaekwon1:	lets say i send Bob 1 million bitcoins, and then I incentivize > 50% of miners to start mining on a fork where I send 0.8M to myself and 0.2M to the miners who help out. How do you stop that?
22:25:02	arubi:	yea, not relaying, or not inserting certain tx's into blocks
22:25:32	arubi:	jaekwon1, there are rules as to which tx came first
22:25:47	jaekwon1:	arubi: i mean, fork from many blocks ago.
22:25:52	arubi:	if you're artificially sending tx's to miners, then that's outside the rules and anything can happen
22:26:04	arubi:	many blocks ago in pow?
22:26:07	jaekwon1:	yup.
22:26:32	arubi:	you can't change just one block in the past
22:26:51	arubi:	you'd have to re-mine the blockchain from that point on, and still be further away from the real chain
22:27:10	arubi:	I mean, have a larger chain
22:27:17	arubi:	that's impossible with a good pow
22:28:02	jaekwon1:	my point is, it's possible to incentivize a majority of miners to fork the blockchain in bitcoin.
22:28:09	amiller:	zack-bitcoin, that's assuming people are expected utility maximizers which is empirically not true and besides that based on suspect axioms IMO
22:28:44	arubi:	jaekwon1, miners can mine whatever they want, nodes will either accept the block or not
22:28:55	arubi:	depends on the rules
22:29:37	michagogo_:	michagogo_ is now known as michagogo
22:30:29	jaekwon1:	arubi. sure. my point is, you can't in tendermint. the only way to create a fork or to double spend is to incentivize miners to lose all of their junk.
22:31:04	arubi:	how does a miner decide which tx's get into a block?
22:31:19	justanotheruser:	jaekwon1: sorry for that earlier comment, I thought this was #bitcoin
22:31:29	jaekwon1:	justanotheruser: no problem :)
22:32:13	arubi:	I'm not trying to be hostile either. I haven't read the pdf about tendermint
22:32:45	jaekwon1:	arubi: at each block, a sequence of proposers is determined based on the existing blockchain. proposers are chosen in proportion to the amount of coins bonded, and "grinding" isn't possible.
22:33:11	arubi:	whoa, way over my head.
22:33:16	arubi:	don't know the terms :)
22:34:05	arubi:	link me to the pdf, I'll read up
22:37:18	jaekwon1:	arubi: http://tendermint.com
22:37:42	arubi:	thanks
23:11:01	cbeams:	adam3us: Perhaps of interest wrt yesterday's conversation about academics and referenceability of traditional papers vs. (git-backed) docs published on the web: https://guides.github.com/activities/citable-code/
23:45:36	zooko`:	zooko` is now known as zooko