01:44:58	gmaxwell:	Man. Someone needs to redo The Producers for modern times. It should be about developer and a trader duo that due to some crazy futures contract have to make their altcoin become worthless.
01:45:03	gmaxwell:	And they make it scammier and scammer but the price keeps going up.
01:57:14	sipa:	haha
02:08:31	nsh:	(wikipedia and imdb disagree on 'the' year of that film -- '67 and '68, respectively -- i wonder if they define it differently or just errorism...)
02:31:14	LarsLarsen:	gmaxwell: LOL!
02:50:44	tt_texas:	tt_texas is now known as tacotime_
03:23:45	Guest42545:	Guest42545 is now known as weex
03:54:17	Luke-Jr:	gmaxwell: ROFL
05:52:40	andytoshi:	gmaxwell: classic!
06:03:33	roasbeef_:	roasbeef_ is now known as roasbeef
07:00:43	maaku:	gmaxwell: brilliant
07:03:40	maaku:	for someone who knows SNARKs better than I do, it is possible to have a generic, circuit-independent verificaiton routine which takes a verification key and a proof and validates it for any input program, correct?
07:48:57	maaku:	n/m, reading the pinocchio paper...
08:03:41	gmaxwell:	sure, a universal circut. thats what the tinyram stuff is about. they define a circuit for a load/store processor that runs N steps (e.g. verifies any program that completes in at least N step)
08:05:05	maaku:	gmaxwell: but you could write a generic function that takes vk,input,output,proof as returns true/false, and works for any circuit, right?
08:05:46	maaku:	i mean, using tinyram is not necessary, right?
08:07:05	maaku:	i'm trying to see if I can get two-way pegging down to one SNARK verfication opcode and a single protocol rule
08:07:11	gmaxwell:	yes. assuming that vk is different for different circuits OR vk is a vk for a universal circut (like tinyram) which you've used and input includes the config.
08:07:47	maaku:	ok cool, that means i'm starting to get an intuitive grasp for this :)
08:07:50	gmaxwell:	maaku: yes. well not quite one opcode, you'll need extra opcodes to push the right data onto the stack for the input.
08:08:32	maaku:	yes of course, i meant just one new opcode extension, as a soft-fork
08:08:42	gmaxwell:	but thats exactly what I imagined in the coinwitness post. That there would just be an OP_SNARK.
08:10:53	maaku:	plus either one more opcode or a pattern matching rule to make sure the quieting output is of a specific form, also a soft fork change
08:11:06	maaku:	i'm much more confident about this now that I'm reasonably certain it can be done as a soft-fork
08:11:48	gmaxwell:	actually you don't necessarily need an op code that does anything about the outputs!
08:12:20	gmaxwell:	you make either the snark opcode act like a checksig and gets a hash of the transaction or you add an opcode to push a hash of the transaction onto the stack
08:12:28	gmaxwell:	and thats all you need.
08:12:52	gmaxwell:	because you make the hash of the transaction a public input to the snark, and then as a private input to the snark you give it the whole transaction.
08:13:08	gmaxwell:	and the snark checks the outputs and runs the hash and checks agreement!
08:13:44	gmaxwell:	(this is the coin covenants post where I'm mostly pointing out that if a snark signs the transaction at all, you can have output restrictions even if you never intended to enable them.
08:13:47	maaku:	sneaky
08:13:48	gmaxwell:	)
08:14:32	maaku:	that is suitably evil
08:15:53	maaku:	ok given that this enables covenants, how confident are you that it could get adopted?
08:16:53	maaku:	imho an evil-covenanted coin is no worse than a lost coin, but i realize that isn't the popular opinion when the topic comes up...
08:17:32	gmaxwell:	I think covenants are too useful (as PT pointed out they can give you compactly verifyable colored coins)
08:17:45	gmaxwell:	you can always choose to refuse to accept them.
08:18:00	maaku:	yeah that's my argument
08:18:06	gmaxwell:	since you choose what scriptpubkeys you reconize as yours.
08:18:09	maaku:	besides, I don't know how you'd recognize them in the first place
08:18:14	maaku:	-yeah
08:19:03	gmaxwell:	right, they're not something that would surprise you. I think in general they are bad and can be misused and people should be cautioned against them.. but I don't think thats enough reason to deny a very powerful feature esp removing them is quite difficult.
08:19:57	gmaxwell:	you can even have them today, if you have n/m signing oracles .. e.g. that can insist you provide the tx they're signing for inspection for agreement with rules.
08:25:06	gmaxwell:	I do in any case think we should have an opcode that takes a masking setting and pushes tag,h(mask_setting,mask(mask_setting,transaction)) onto a special signing stack or the like so that you can control what you're signing from within the script.
08:30:44	maaku:	what is tag in this context?
08:32:35	sipa:	you mean a generalization of the sighash flags?
08:32:42	gmaxwell:	a description of which opcode was used to push the data. it must be tagged so that you can't use a data push instead of a mask_transaction push
08:33:35	gmaxwell:	otherwise you can take a transaction save its masked hash and replace the OP_MASKTX_TO_SIGSTACK with a OP_PUSHTOSIGSTACK
08:33:50	gmaxwell:	and thereby steal coins.
08:36:39	maaku:	ok. it's nothing special though, just the byte/opcode index perhaps?
08:37:20	gmaxwell:	yea, just the opcode you're using I think is fine, just to prevent emulation of a transaction push with a data push.
08:37:37	gmaxwell:	in any case you could construct complicated masking schemes just by making multiple OP_MASKTX_TO_SIGSTACK pushes.
08:38:32	gmaxwell:	e.g. if one of the settings for OP_MASKTX_TO_SIGSTACK is a lets you pick txouts one at a time.
08:40:02	maaku:	OP_MASKTX & SIGSTACK is something I need to contemplate. is this written up anywhere?
08:42:26	gmaxwell:	I might discussed it in passing but I'm not sure which post. I'm not entirely sure if it's worth it of if some point it just becomes 'screw it' use a snark. though if you want malleability you can't really do snark masking, since the snark would need to be recomputed.
08:43:16	gmaxwell:	mostly all this stemming from the in ability to do a SIGHASH SINGLE that obligates two txouts, or even just a different tx out than your current index.
08:46:14	maaku:	wait, if the snark accepts as input the full (unsigned) transaction, then ignores some parts of it, if those ignored parts are changed the snark proof becomes invalid?
08:46:21	maaku:	even though the output doesn't change?
08:47:04	gmaxwell:	yes, because the hash input to the snark proof changes.
08:47:12	maaku:	i see
08:47:17	gmaxwell:	so someone needs to rerun the proof to make sure it still likes it
08:47:38	gmaxwell:	this is one reason why flexible masking is still useful even though in theory you can do all masking inside the snark
08:48:23	gmaxwell:	another reason is because doing any masking inside the snark requires proving that the transaction and the hash agree, and that means running the hash in the snark.. and thats a bunch of extra work for the prover.
08:49:26	maaku:	have you thought about the format for the configuration of this masker? are bitfields specifying inputs & outputs to include sufficient?
08:50:17	gmaxwell:	I have, and I think something like that is acceptable, figuring out what the most efficient way to encode the masks seems like an interesting problem.
08:51:17	gmaxwell:	basically I think you want some cases to be efficient: for each data type (inputs, outputs): all, none, a few at random, some range contigiously to all be reasonably efficient to encode.
08:51:43	maaku:	yeah last time I thought about this I got hung up on figuring out how to make these masking modes composable
08:51:53	maaku:	without requring equal numbers of inputs & outputs
08:52:23	maaku:	hence the freimarkets sub-transactions which punts the problem to a hard fork
08:52:31	gmaxwell:	there is also a question of wanting to do masking like outputx, clamping the bitcoin amount it pays to min(actual,2 btc). but maybe you just say if you want masking that complicated, get a snark.
08:52:42	gmaxwell:	though it's actually a very useful thing to do.
08:53:50	gmaxwell:	e.g. say you're going to do a kickstarter thing, output 0 pays to the project, you put in 2 btc using a 3 btc coin. You want to sign output 0 clamped to min(actual,2), and sign output N (completely)
08:54:14	gmaxwell:	I sign any txn spending my coin, such that at least 2 btc go here, and 1 btc go to me.
08:55:00	gmaxwell:	I waver on the use: the problem is that you can eliminate the need by using a multiple round protocol where the users agree on the values first.
08:55:31	gmaxwell:	the problem with that solution, however, is that multiple round protocols are actually really hard to implement and create a bunch of obnoxious failure modes, including accidental ones.
08:56:12	gmaxwell:	"oh, bob went offline, we need to start over. oh bob came back. oh bob is gone again. oh bob is back. oh crap we werent smart enough to write code to deal with bob flapping"
08:56:23	gmaxwell:	darnit freenode
08:56:24	maaku:	hrm, the mask specification could be relative to an encoded offset to the other side, which is intentionally malleable
08:56:31	maaku:	i think i may have just eliminated the need for sub-transactions
08:57:16	maaku:	yeah
08:57:34	gmaxwell:	yea I had assumed at one point basically leaving the mask specifier out of the hash (though I see I fucked that up above) for that reason.
08:58:06	gmaxwell:	basically if you haven't covered the whole tx someone should be able to add/reorder outputs and fixup your masks.
08:58:43	maaku:	well, yes, but is there a way for them to exploit that?
08:58:58	gmaxwell:	and I figured with a sigstack if you just had optcodes for PUSH1, PUSHall, PUSHrange you could cover the cases I thought need to be efficient.
08:59:17	gmaxwell:	it's malleability but if you leave in a way to sign all I think its a non issue.
08:59:38	gmaxwell:	also malleability can be a non-issue if you leave a way out of including the f@#$@# vin:index out of the signature.
09:00:04	gmaxwell:	(and use a refusal to reuse pubkeys as a way to make sure the right coin gets spent)
09:00:31	gmaxwell:	which is really how I think you should handle protocols that need precomputed refunds.
09:08:18	maaku:	well this has been an enlightening discussion. thank you, gregory
09:08:31	maaku:	i need to get some sleep so my SO doesn't kill me in the morning :)
09:13:57	gmaxwell:	goood night!
10:38:12	dansmith_btc:	I think it would a good idea to make introduce a proof-of-stake blockchain in bitcoin, so that there would be 2 blockchains simultaneously running - pow and pos. Neither blockchain will allow the inputs spend on the other blockchain. Putting aside the complexity of implementation, is this a sound idea?
10:39:57	nsh__:	nsh__ is now known as nsh
10:40:41	nsh:	how would that be different from bitcoin + a PoS altcoin?
10:41:38	dansmith_btc:	nsh, it will allow bitcoin to peacefully make a transision to pos without cause a revolt from the pow miners.
10:44:37	dansmith_btc:	also the diff with an altcoin is that the pos coins are already distributed and there is no need to start from scratch
10:45:07	dansmith_btc:	I mean, when bitcoin makes a transision to pos, the coins are already distributed fairly
10:45:16	nsh:	okay, it's not a good idea.
11:46:40	airbreather:	dansmith_btc: yeah, uhh... I'm with nsh here. since there are two separate blockchains, you've essentially just created an altcoin
12:15:43	crowex:	crowex has left #bitcoin-wizards
13:48:54	Luke-Jr:	dansmith_btc: you mix "Neither blockchain will allow the inputs spend on the other blockchain." with "when bitcoin makes a transision to pos, the coins are already distributed fairly"
13:48:58	Luke-Jr:	this does not make sense
13:49:02	Luke-Jr:	please xplain
13:49:27	Luke-Jr:	also keep in mind that nobody has demonstrated the viability of any proof-of-stake system yet
14:10:40	MrUtuber:	MrUtuber has left #bitcoin-wizards
14:21:29	dansmith_btc:	Luke-Jr, what I meant is if you introduce a new PoS altcoin right now, people will see it as "not fair" if the early adopters get all the coins (like what nextcoin did). But since the current distribution of bitcoins is perceived to be fair as it is, then it is much easier to make a gradual transition to PoS.
14:23:00	dansmith_btc:	Of course I wasn't going to discuss the merits of PoS vs PoW, I just assumed for the sake of simplicity that PoS is more secure than PoW.
14:25:27	dansmith_btc:	I'm not gonna reiterate the theoretical benefits of Pos, they are covered in the wiki, I was just exploring whether it is a technologically feasible idea of having 2 blockchains Pow and PoS.
14:26:04	dansmith_btc:	The PoW blockchain can still be used by miners until we get the 21 mil promise, but the PoS will be there for the transactions.
14:27:41	andytoshi:	dansmith_btc: ..."the theoretical benefits of PoS" are not covered anywhere because it is not known whether PoS consensus is possible
14:30:44	andytoshi:	also the suggestion that you can just snapshot the bitcoin utxo set at some random height to get a 'fair' distribution of coins doesn't really make sense, that's a very arbitrary distribution
14:35:32	dansmith_btc:	andytoshi, what I have in mind is PoS which randomly chooses the next miner based on their btc balance. So, starting at some agreed-upon point there will have to be a utxo snapshot. What exactly "doesn't make sense"?
14:39:21	andytoshi:	what doesn't make sense is that it's completely unfair, you are assigning coins to people who are probably not even aware of it in a random fashion. then i don't get what "randomly" means, how does everyone agree on the random selection of miner, and why would they agree? what if the chosen miner does not respond?
14:40:56	tacotime_:	andytoshi: the follow the satoshi scheme like that usually uses an exponentially rolling difficulty for the chosen miner.
14:41:24	tacotime_:	so that for the chosen miner, the difficulty is n, for the next miner, n*2, then n*4, etc
14:41:57	tacotime_:	in this way it's difficult to get "stuck", but you can also miss your turn i guess.
14:42:03	pigeons:	and if you don't agree, you're overruled out by the broadcast checkpoint ;)
14:42:11	andytoshi:	tacotime_: if the miner is chosen anyway, what does the difficulty accomplish?
14:42:33	andytoshi:	and what does it mean to 'miss your turn', you'd need some sort of distributed timestamp mechanism to detect that
14:42:41	MoALTz:	as for the random number picked by finding a block... you can pick most of the non-leading bits (a little past the zeros) iirc
14:42:57	tacotime_:	andytoshi: preventing burn-through (rapid consumption of blocks) and the problem of a non-responsive miner.
14:43:01	MoALTz:	of the hash i mean
14:43:21	dansmith_btc:	andytoshi, what I was suggestng is that new coins continue to be mined by PoW miners, it is only new transactions that will be accepted into a block by the PoS miner. You are right, I shouldnt have used the word "randomly chosen", because the PoS miner gets chosen based on their btc stake - the larger their stake, the more frequently the miner gets chosen.
14:43:25	tacotime_:	andytoshi: yeah, that's an issue too.
14:44:01	tacotime_:	dansmith: that's what my fork and iddo's fork does, although they're both not totally functional yet.
14:44:10	andytoshi:	dansmith_btc: i'm not worried about the specific distribution, i'm worried about consensus. as MoALTz says you can just use bitcoin blockhashes (and i guess tie your blocktimes to bitcoin's)
14:44:43	andytoshi:	tacotime_: unless your difficulty scales like bitcoin's, you're going to have rapid blocks, and if you are choosing the next miner based on PoS blocks then that can obviously be gamed by a fast miner
14:44:57	andytoshi:	tacotime_: otoh if you are choosing the next miner based on bitcoin blocks, you have a natural throttle already
14:45:09	tacotime_:	andytoshi, right
14:46:35	tacotime_:	all the pos mechanisms that make the most sense to me require pow too. but, yeah, these are in the works and will probably be released in the near future.
14:47:24	tacotime_:	bitcoin kind of already has a built in pos mechanism through the nodes though, and if someone forks the network the major players are going to see it and select a single fork to work on anyway. :P
14:48:13	tacotime_:	I feel like it's less of a problem than people make it out to be.
14:48:59	tacotime_:	I just want to do my PoS mechanism because it seems interesting, and I'm curious what security/consensus it affords (or doesn't).
14:49:01	andytoshi:	istm that if you have pow anyway then you have accomplished nothing environmentally, but you've made your consensus code way more complicated and introduced a ton of incentive hacks, esp. if the txes you choose to mine affect your future chances of being a voter
14:50:49	andytoshi:	tacotime_: cool, sounds like a fun experiment. but i don't think it'll work out for a currency
14:51:19	andytoshi:	if you can tie it to the bitcoin PoW for consensus/throttling maybe there are other applications which are compatible with the screwy incentives, def something to think about
14:54:33	andytoshi:	eg there have been political ideas to the effect of replacing voting with simply conscripting congressmen at random from the population. if you made the choice based on bitcoin blockhashes every 100000 blocks (and included 100000 hashes in the calc) or whatever that's globally visible and impossible to game
14:54:39	tacotime_:	Yeah, one theoretical application was voting consensus among stakeholders and PoW miners for what they think the rewards should be, and see how they interact. You would think PoW would always vote PoW reward up and PoS down, and then vice versa.
14:55:03	tacotime_:	andytoshi: that's sorta how it works
14:55:18	tacotime_:	http://mc2.xwebnetwork.com/storage/mc2_0.05.pdf
14:55:39	MoALTz:	also note that what is said about the hash only applies if you're doing competitive PoW (where you want to post your solution as soon as you find one). it doesn't work if the miner gets to find multiple solutions to pick the one that favors him (where PoS mostly replaces PoW that might be the case)
14:55:51	tacotime_:	Forgive any lame/nontechnical ideas in the paper, I don't have a heavy math bg.
14:56:11	andytoshi:	you said at the conference you used to be a grad student? what in?
14:56:20	tacotime_:	Biochemistry
14:57:00	andytoshi:	ohhh it's so long
14:57:04	andytoshi:	cool, i'll check it out :)
14:57:35	tacotime_:	A lot in there is "technical specifications", there's a bug in the chain selection method too in that version.
14:58:54	tacotime_:	I try to keep the "how this works in a nutshell" stuff in the beginning.
15:26:13	Fistful_of_LTC:	Fistful_of_LTC is now known as Fistful_of_Coins
15:37:57	Luke-Jr:	dansmith_btc: my point is that if PoS and PoW blockchains don't mix, they can't provide any benefit to each other. also, like 10% of bitcoins are *stolen* - I doubt many would consider it "fair" distribution
15:41:29	dansmith_btc:	Luke-Jr, I agree they don't mix. I am proposing to use the two so that the current pow miners would not feel cheated when the transision is made. As I mentioned earlier, why not let the existing miners mine their 25 reward blocks and at the same time use PoS blockchain to confirm transactions.
15:42:39	Luke-Jr:	IMO the PoW distribution is *only* fair because of the value miners provide the network..
15:42:48	dansmith_btc:	My initial supposition was that PoS blobkchain is superior, i.e. lesser fees, higher attack cost, so people would naturally gravitate towards PoS if given an option.
15:42:55	Luke-Jr:	if not for that, it would be retarded
15:44:23	Luke-Jr:	if PoW mining is non-existent, I would think the obvious initial distribution would be to simply put a tiny amount at every possible scriptPubKey :p
15:46:15	Luke-Jr:	(eg, allow outputs to be +.000000000001 BTC more than inputs)
15:46:46	dansmith_btc:	Luke-Jr, sorry but I have a hard time understanding your responses. It seems like we are not on the same page or maybe I'm not following.
15:47:16	Luke-Jr:	dansmith_btc: perhaps the problem is you are working with a fixed set of assumptions that I find almost entirely wrong ;)
15:50:03	wallet42:	wallet42 is now known as Guest31878
15:50:03	wallet421:	wallet421 is now known as wallet42
15:50:17	dansmith_btc:	Luke-Jr, do you think if a point in the future is chosen and from that point on users will choose whether to send their txs to PoW miners or to PoS miners (while PoW miners continue to mint btc until 21 mil is reached), do you think there is some unfairness in that?
15:51:26	Luke-Jr:	dansmith_btc: yes. but perhaps tolerable unfairness.
15:52:17	dansmith_btc:	Luke-Jr, I would love to hear your opinion on what exactly the unfairness is? Is it the breaking of the initial promise that PoW miners get all the tx fees?
15:54:22	Luke-Jr:	dansmith_btc: miners are rewarded for providing a value to the network. if they no longer provide that value, it makes no sense for them to get the subsidy even
15:54:59	Luke-Jr:	note miners were never guaranteed the PoW algo would remain fixed either (although they have a voice in that as community members of course
15:57:52	dansmith_btc:	Luke-Jr, are you trying to say that if the switch to PoS is made, there is no point in continuing to give block rewards to PoW miners because they dont provide any value anymore?
16:07:12	dansmith_btc:	If yes, then I agree, but I suggest that they continue to get their block reward in order to avoid PoW miners' revolt. Because if we set a date in the future when the transision to PoS will be made, the PoW miners sensing their impending demise can collude and attack the system. So, unless the exixting PoW miners are guaranteed their continuing block rewards even after transitioning to PoS, they won't cooperate.
16:14:41	mike4:	mike4 is now known as c--O-O
16:36:07	super3:	this is why peercoin uses a hybrid model
16:36:42	super3:	PoW is simply a better model for fair distribution of the coins, while PoS is a better model for securing the chain
16:37:25	Luke-Jr:	hypocrite! I was witness to you failing proof-of-steak!
16:38:16	Luke-Jr:	:p
16:38:57	super3:	Luke-Jr, I was tricked. I used the wrong algo because I didn't read the menu.
16:39:27	tacotime_:	awww what proof of steak actually happened and i missed it!?
16:39:38	Luke-Jr:	tacotime_: nah, not really
16:39:46	Luke-Jr:	tacotime_: super3 had the option the night before we met
16:39:54	tacotime_:	ah okay haha
16:40:06	Luke-Jr:	he ordered ssomething else
16:40:08	Luke-Jr:	lol
16:40:11	gmaxwell:	super3: uhhh wtf.
16:40:28	gmaxwell:	super3: It doesn't even appear that PoS is actually viable at all for securing the chain. :(
16:42:09	super3:	if I was to implement this on Bitcoin I would do a hybrid system. you would gradually increase the PoS until the day when the block reward runs out. that way you have a secure chain and the miners are happy.
16:42:22	super3:	gmaxwell, explain
16:42:34	dansmith_btc:	super3, that's exactly what I had in mind
16:42:40	super3:	i
16:42:58	gmaxwell:	What do you mean ... explain? this isn't some remarkable new position.
16:43:21	super3:	i'm not convinced that he fees can sustain the miners after the block reward runs out
16:43:24	gmaxwell:	I'm basically blown away to see you expressing a view that it was better when I think the overall view is that it's not clear that its workable _at all_
16:43:42	gmaxwell:	yea, perhaps PoW is not workable a long time in the future for bitcoin either.
16:44:08	gmaxwell:	But PoS doesn't work immediately due to the nothing at stake problem.
16:44:47	Luke-Jr:	I wonder if it would work to just accept a pubkeyhash signature to do blocks, with the accepted range of hashes doubling every 0x1000th of a day
16:44:54	gmaxwell:	(which is why peercoin had mandatory developer signed blocks, and mandatory POW to select the randomness for PoS)
16:44:55	super3:	let me read your bitcointalk post about this
16:45:01	Luke-Jr:	(so after ~5 mins, any key works)
16:45:10	Luke-Jr:	or maybe 0x100th (90 mins)
16:46:41	Luke-Jr:	well, I guess it'd need to adjust for difficulty perhaps
16:47:03	Luke-Jr:	which is probaably non-linear already
16:49:58	super3:	gmaxwell, did a little reading and i agree with your position
16:50:31	dansmith_btc:	super3, what thread is that?
16:50:38	Luke-Jr:	super3: wow! what does that mean for Peercoin? XD
16:50:44	super3:	dansmith_btc, found it via google here https://bitcointalk.org/index.php?topic=430683.0
16:51:16	gmaxwell:	super3: it's been discussed in a bunch of places... it's really irritating I can't tell you how many hours I've spent trying to think up solutions.
16:51:27	tacotime_:	gmaxwell: it's a hard problem.
16:51:45	tacotime_:	my solution was simply "use PoW as tiebreaker". but it's not very elegant.
16:52:05	gmaxwell:	that just reduces to PoW I think, with some constant factors shuffled around.
16:52:23	tacotime_:	Well, yeah, PoW with random stakeholder verification.
16:52:38	gmaxwell:	I've carefully considered several specific variations of that, at least and convinced myself that they were really just PoW with some constant factors.
16:52:55	super3:	gmaxwell, i think PoS + another algoritm to get you that last mile might work
16:53:06	super3:	i like that people are playing around with other algoritms though
16:53:06	Luke-Jr:	(re my idea on a gradual acceptance of a keyhash: obvious flaw is that it allows a "miner" to build up a database of keyhashes and keep using it over and over :/)
16:53:53	super3:	someone might come up with something we could have never thought of
16:56:05	gmaxwell:	oh absolutely.
16:56:24	Luke-Jr:	hmm, I guess that proposal actually simplifies to a straight PoW still
16:57:13	tacotime_:	gmaxwell: When you say "constant factor", what do you mean?
16:58:33	super3:	Luke-Jr, nothing really. still remains a valid experiment and seems to still be alive.
16:58:53	gmaxwell:	in the sense that it doesn't really change the security model, an attacker who can substantailly overpower the network can rewrite the history... maybe it changes the details of the attacks or shifts the costs around a bit.
16:59:05	Luke-Jr:	gmaxwell: what if proof-of-stake was done by including a transaction in your block paying a UTXO as a large "stake fee", that could only be included in that exact block or a higher height (so essentially, you lose it if the block isn't accepted)
16:59:25	tacotime_:	Okay, right, I would say that is true.
16:59:26	Luke-Jr:	(and can only put it at stake in that one blockchain)
17:01:02	gmaxwell:	you need a consensus mechenism to register your proposed 'bond' in the first place, and so the people in charge of the consensus then (not you) can deny you membership by refusing to publish your intent to mine.
17:01:41	Luke-Jr:	why does it need to be registered?
17:01:42	gmaxwell:	(also you need to do some other things to prevent things like mining 1000 different blocks at that height and getting a free one confirm double spend, though at least that much I know how to solve)
17:02:16	gmaxwell:	because otherwise you effectively claw it back if you're not successful.
17:02:47	Luke-Jr:	not if any other miner can take it from your attempt, and mine it to themselves
17:03:04	gmaxwell:	e.g. you take the same bond and you double spend it 1000 times in different forks. only one spend of it can get gobbled by another miner.
17:03:17	Luke-Jr:	ah, hm
17:05:15	gmaxwell:	POS works totally fine if you have _another_ external perfect consensus mechenism to prevent doublespending of the stake. :P
17:07:04	super3:	gmaxwell, daniel larimer was considering using Ripple's consensus algoritm to achive that
17:07:14	andytoshi:	is anyone here familiar with what (if anything) nxt has actually done?
17:08:14	super3:	andytoshi, i know their people, but i haven't actually looked at it deeply
17:08:21	Luke-Jr:	super3: LOL
17:08:24	tacotime_:	I think nxt went "follow-the-satoshi" with transparent mining, where as I mentioned earlier, there's a queue of miners with rolling exponential difficulty
17:08:59	andytoshi:	there was an NXT guy at the altcoin panel, he was very loud and kept talking over people and kept making fantastical airy claims
17:09:14	andytoshi:	so my impression today is that it's 100% vapour
17:09:42	maaku:	super3: but ripple fails at being decentralized...
17:10:08	fanquake:	fanquake has left #bitcoin-wizards
17:10:22	super3:	maaku, to be clear i really don't like Ripple
17:10:27	andytoshi:	tacotime_: ok, but then the voters can't be unpredictable and non-manipulable because as we discussed the satoshi chain can't support that
17:10:43	gmaxwell:	maaku: or secure/reliable, or it can be decenteralized. Depends on exactly how the ecosystem plays out because the unl process isn't specified.
17:10:52	tacotime_:	andytoshi: right. but it wouldn't surprise me if nxt disregarded this realm of sanity.
17:11:26	gmaxwell:	andytoshi: I haven't looked at the nxt code since they released all of it, but the original version could be nothing-at-staked to death trivially with ~two lines of code.
17:11:33	Guest5445:	.
17:11:36	andytoshi:	tacotime_: sure. so the reason i'm asking is that we've had an increasing number of people here who inexplicably believe you can create a distributed consensus from PoS and i think it's because of NXT's claims
17:11:42	andytoshi:	gmaxwell: ...
17:11:43	gmaxwell:	(adding a while loop around the mining code and making it pick a difference nonce each time)
17:11:56	andytoshi:	gmaxwell: how could they have possibly missed that?
17:12:25	tacotime_:	my favourite thing about nxt is that they made the account trees with 64-bit security and brainwallet style passwords, then claimed that being able to mine for accounts and steal other people's money if they had weak passwords was a "feature"
17:12:30	gmaxwell:	basically the massive exploit on peercoin was stopped by the block signing, so I think most people don't know about it.
17:12:30	maaku:	gmaxwell: it can't. it's common knowledge among the Ripple Labs engineers I talked to that disagreement over the UNL results in partitions which shutdown the network, requiring manual intervention
17:12:49	andytoshi:	gmaxwell: right, but if anybody does it should be NXT >.>
17:12:52	maaku:	this is an intrinsic property of the consensus mechanism they are using...
17:13:38	gmaxwell:	maaku: I know, I mean I pointed this out in the WTF? thread. It can work, or it can be decenteralized. Not both. :P This was obvious enough to me from the high level description before they published it.
17:13:53	gmaxwell:	I think there is a place for classical consensuses ...
17:14:04	gmaxwell:	but not as global systems.
17:14:43	Luke-Jr:	some Ripple guy gave an interview I was witness to
17:14:53	Luke-Jr:	when it was over, I told him he forgot to mention it was centralised
17:15:10	tacotime_:	hahaha ah man i skipped the ripple talk and missed that
17:15:17	Luke-Jr:	he argued that everything was "centralised"…
17:15:24	maaku:	ripple is distributed, not decentralized. i wish they would come out and say that
17:15:53	maaku:	there are situations where that make sense, e.g. replacing SWIFT interchange between banks
17:15:56	Luke-Jr:	oh, and he said they wouldn't make me a validating node because individuals cannot be trusted, only big companies…
17:16:05	maaku:	but it's a distinctly different problem then what bitcoin solves
17:16:13	maaku:	Luke-Jr: hah
17:16:51	Luke-Jr:	I was too dumbfounded to make the case it was no better than PayPal :/
17:17:10	gmaxwell:	might be fun to find someone who had ripple stolen and get a court order for the ripple to be returned. :P
17:17:40	maaku:	Luke-Jr: well, it's marginally better. it requires heavy-handed intervention to actually take coins
17:18:01	gmaxwell:	maaku: not really: they have unilateral control of the UNL
17:18:20	gmaxwell:	so it just requires one of them to swap out the nodes.
17:18:56	maaku:	gmaxwell: yes, but balance movements are still signed, right?
17:19:08	gmaxwell:	sure but the history isn't validated.
17:19:13	gmaxwell:	just changes.
17:19:20	super3:	gmaxwell, oh did glance over the storj email?
17:19:20	maaku:	ah
17:19:26	gmaxwell:	so switch out the nodes for nodes with an adjusted history.
17:21:17	gmaxwell:	super3: somehow I'd missed it was you! I did, I just haven't had a ton of time to give it attention.
17:23:37	super3:	if you had just a few minutes to talk about it when you get some time that would be great
17:24:06	super3:	i kind of need your permission if i want to continue using the storj name
17:24:33	Emcy:	can i get a bit of help? My nick is banned on -dev and i dont know when or why
17:24:51	super3:	now that there is a basic decentralized storage engine, can actually implement your bitcoin agents in a weekend
17:25:01	super3:	rudimentary, but working
17:25:05	gmaxwell:	K. And yes, you can use the name, though I'd ask that you keep a link lurking around somplace for the writeup I did, and I have a domain that might be useful.
17:25:40	Emcy:	sorry for the OT the only -dec opers i know are you guys
17:25:49	gmaxwell:	Emcy: looking
17:26:02	Emcy:	thanks
17:26:07	gmaxwell:	Emcy: dude, you're not banned
17:26:12	gmaxwell:	register with nickserv.
17:26:24	Emcy:	i am logged in
17:26:59	Emcy:	hang on
17:27:07	gmaxwell:	^ nanotube see +r is failsauce
17:27:26	super3:	gmaxwell, yeah ive cited it in the papers, and there will be a link to it on the front page of the website
17:27:50	nanotube:	gmaxwell: -dev is not set to +r presently...
17:28:36	gmaxwell:	0_o
17:28:47	gmaxwell:	Emcy: are you fixed yet?
17:29:11	Emcy:	ok i cant find the log but i had a guest nick and i tried to /nick emcy adn the server windows said "cannot change nick while banned on channel bitcoin-dev" or similar
17:29:25	Emcy:	that was 5 minutes ago
17:29:54	maaku:	Emcy: leave #bitcoin-dev, authenticate, join back
17:30:09	Emcy:	i restarted hexchat and it seems ok now
17:30:13	gmaxwell:	nanotube: it's +r indirectly.
17:30:15	Luke-Jr:	http://maidsafe.net/ sounded interesting, but poorly presented (it sounded technically unfeasable)
17:30:21	gmaxwell:	there is a +q ~$a set
17:30:21	Emcy:	You are now identified for MC1984.
17:30:21	Emcy:	-NickServ- 2 failed logins since last login.
17:30:21	Emcy:	-NickServ- Last failed attempt from: Emcy_!~Emcy@h-123-170-52.a336.priv.bahnhof.se on Mar 07 05:25:58 2014.
17:30:21	Emcy:	* unaffiliated/mc1984 :is now your hidden host (set by services.)
17:30:28	Emcy:	oh shit thats not me
17:30:55	nanotube:	don't see any bans on you in the dev banlist
17:30:59	gmaxwell:	nanotube: +q
17:31:07	gmaxwell:	it's +q for non-registered.
17:31:13	Emcy:	it definitely said there was a channel ban
17:31:24	gmaxwell:	Luke-Jr: they're claiming a bunch of stuff which appears not possible, loudly, with nothing but handwaving.
17:31:33	Emcy:	^does that mean someone is trying to impersonate me thru bahnhof
17:31:41	Luke-Jr:	supposedly there's code now, I think
17:31:42	nanotube:	gmaxwell: dunno if that'd cause inability to change nicks... but hey, could be.
17:32:13	gmaxwell:	Luke-Jr: someone at the tx conference (? i think) told me they tried talking to the maidsafe person— who was apparently there— and got a literal armwave.
17:32:34	maaku:	if you wave hands fast enough you can fly!
17:32:39	gmaxwell:	nanotube: I think it does, to prevent people from talking via nick changes.
17:32:44	nanotube:	haha, 'tx conference' i read that as 'transaction conference' >_>
17:32:59	nanotube:	yea could be. though talking via nickchange is fun >_> :)
17:33:02	Luke-Jr:	gmaxwell: lol
17:33:11	gmaxwell:	Luke-Jr: are you in california yet?
17:33:17	Luke-Jr:	gmaxwell: not until tonight
17:33:41	gmaxwell:	Also, do any of you have phonelines in the US and a modem? backup network block UUCP relay anyone?
17:33:52	super3:	gmaxwell, yeah i've been talking to the maidsafe guys as a part of storj
17:33:54	tacotime_:	the maidsafe people said they were going to release their bitcoin-style token system in april.
17:34:05	Luke-Jr:	gmaxwell: I have VoIP!
17:34:14	Luke-Jr:	got a VoIP modem software? :P
17:34:29	tacotime_:	http://blog.maidsafe.net/2014/02/18/token-on-maidsafe-network/
17:34:32	Emcy:	nanotube, re. the failed login message above, is someone trying to mess with my nick?
17:34:42	gmaxwell:	Luke-Jr: data works really really poorly over voip, also doesn't actually get you robustness to internet partitioning. :P
17:34:51	gmaxwell:	Emcy: they might have just thought it was theirs
17:34:55	Luke-Jr:	gmaxwell: it gets partial :P
17:35:00	gmaxwell:	if your password is good, don't worry about it.
17:35:10	Luke-Jr:	gmaxwell: I used to do faxes over VoIP fine with ulaw
17:35:50	maaku:	only two attempts seems pretty odd
17:35:55	gmaxwell:	actually a lot of voip stuff has special magic for fax that actually pushes down the modem.
17:36:04	Luke-Jr:	now it does :P
17:36:05	super3:	yes, i've been working with bitangels to get maidsafe to use bitcoin-like tokens
17:36:09	Emcy:	ok
17:36:14	Emcy:	thanks
17:36:20	super3:	they are drinking the bitcoin koolaid
17:36:25	Luke-Jr:	I'm very sure when I was faxing, it was just ulaw though
17:36:26	nanotube:	Emcy: well, seems someone tried and failed to log in to your nick.
17:36:53	Luke-Jr:	* Luke-Jr notes failures do not imply no-success
17:36:59	Emcy:	yeah from a bahnhof vpn prob
17:37:12	Emcy:	what do they want with me, i have no enemies lol
17:37:30	Luke-Jr:	Emcy: maybe they want to scam with your OTC rep
17:37:43	Emcy:	dont have an OTC
17:39:45	Emcy:	Emcy is now known as Emcy_
17:40:00	Emcy_:	Emcy_ is now known as Emcy
17:40:18	maaku:	Luke-Jr: well, a success would have reset the failure count, no?
17:40:40	maaku:	but Emcy, I would change my password anyway
17:40:49	Luke-Jr:	maaku: dunno
17:41:28	Emcy:	if they tried and didnt get in then they dont have it
17:44:04	maaku:	as Luke-Jr said, how sure can you be they didn't get in?
17:44:26	Emcy:	2 failed login attempts?
17:44:45	Emcy:	i assume they eaither have it or they dont. They dont try to crack against nickserv or something
17:45:06	Emcy:	someone tell me if im seen scamming or something around here lol
17:46:58	Emcy:	no reported failed logins on the associated email account
17:53:00	tacotime_:	tacotime_ is now known as tt_away
17:59:33	Emcy:	oh i worked it out. The guest nick i had been assigned was previously banned on dev so it wouldnt let me do anything while on it. I think that sounds plausible right
17:59:46	Emcy:	there must be lots of guest*** on the banlist
18:01:27	gmaxwell:	I already explained it: the channel is +q ~$A
18:01:48	gmaxwell:	I don't think you can change nicks when quieted.
18:02:04	Emcy:	oh right that makes sense
18:04:14	Emcy:	lol assange just said bitcoin is not interesting
18:04:23	gmaxwell:	Good.
18:04:54	Emcy:	im quoting a bit out of context
18:05:39	Emcy:	gmaxwell dont want wikileaks talkiong about bitcoin or something?
18:05:42	gmaxwell:	He's a great lightning rod, I am glad for nothing I'm working on to be in his path to ground. :)
18:06:02	Emcy:	understandable
18:06:33	nanotube:	nice analogy :)
18:06:58	Emcy:	but wthout lightning robs the building gets blown up instead
18:07:04	Emcy:	i dont know where im going with this
18:07:35	nanotube:	heh
18:07:43	Emcy:	snowden is speaking soon i think
18:07:46	Emcy:	live to sxsw
18:08:39	Emcy:	oh no its on monday
18:10:10	gmaxwell:	oh I wasn't attempting to complain about him, just that the attention he couldn't bring isn't the sort we would want.
18:11:02	Emcy:	nothing anyone does with bitcoin should affect your roles as developers
18:11:16	Emcy:	or course that assumes the people with the big sticks are rational about it
18:11:24	gmaxwell:	'we' wasn't developer, really it was everyone who uses bitcoin.
18:11:48	gmaxwell:	People trying to advance civil rights and political equality by undermining large systems— to the extent that bitcoin is useful to them, they already know about it and will use it. They don't need a figure head to tell them to, the applicability suggests itself.
18:12:22	gmaxwell:	What someone like that advancing bitcoin does is suggests bitcoin as a weakness to attack to their enemies.
18:13:04	Emcy:	good stress test though
18:13:12	Luke-Jr:	hardly
18:13:57	gmaxwell:	attacks are not 'stress tests' thank you very much.
18:14:19	Emcy:	bitcoin isnt good for much if it gets fucked up the first time it enables someone to mightily piss off some established player
18:14:49	Emcy:	im not saying theres any need to have your arse hanging out the window though
18:14:57	gmaxwell:	gmaxwell has left #bitcoin-wizards
18:16:10	nanotube:	anyway, this conversation probably best belongs in #bitcoin-politics or #bitcoin-economics, rather than -wizards, Emcy
18:16:40	Emcy:	youre right
18:17:03	Emcy:	done now anyway sry
18:24:02	just[dead]:	just[dead] is now known as justanotheruser
18:40:08	jtimon:	super3 not a new position either but just in case...the simplest solution to the potential tragedy of the commons on future mining incentives is...
18:40:19	jtimon:	adding demurrage fees
18:41:45	sipa_:	sipa_ is now known as sipa
18:43:56	maaku:	heresay!
18:43:57	super3:	heh. something something... scamcoins.
18:44:13	sipa:	maaku: heresy or hearsay?
18:46:01	maaku:	heh, oops
18:46:14	maaku:	super3: you can do demurrage in bitcoin
18:46:20	maaku:	using a pegged side-chain
18:46:24	Luke-Jr:	maaku: no, you can't. :P
18:46:31	maaku:	Luke-Jr: yes you can :)
18:46:39	Luke-Jr:	maaku: adding demurrage to bitcoin is a violation of the social contract
18:47:28	maaku:	Luke-Jr: you don't need anybody's permission. i'd be opt-in with friction to get out, a side chain pegged 1:1 in and 1:<1 out
18:48:01	Luke-Jr:	O.o
18:48:07	Luke-Jr:	why would anyone opt in
18:48:29	jtimon:	another social contract?
18:48:35	Emcy:	that will never happen
18:49:03	Luke-Jr:	"I want to make my bitcoins less valuable!" O.o;;
18:49:10	jtimon:	I don't think it's particularly interseting either
18:49:27	maaku:	Luke-Jr: doesn't matter. once they're in they're less expensive to keep in than to take out
18:49:45	Emcy:	i bet you could get lots of occupy hipsters to opt in
18:49:55	Luke-Jr:	maaku: maybe, but I wouldn't accept them as payment if I want bitcoins
18:50:07	Luke-Jr:	it'd essentially be an altcoin
18:50:21	maaku:	Emcy: yes, and once they do their side-chain bitcoins trade at less than 1 bitcoin, but greater than the cost of bringing them out
18:50:54	Luke-Jr:	might as well just cross-chain trade Freicoins
18:51:12	Emcy:	you cant cross chain coins
18:51:40	maaku:	Luke-Jr: no, the pegging means that every side-chain coin is worth, say 0.95 btc. guaranteed.
18:51:41	jtimon:	Luke-Jr you're right, they would be different currencies just like the euro and the chiemgauer, but why wouldn't you accept them, not even at a discount?
18:52:10	maaku:	Emcy: you can, it just requires a OP_SNARK opcode (soft-fork change, which will probably happen anyway for other reasons)
18:52:44	jtimon:	there's existing ways to cross-chain trade, the old contract example and coinswap
18:52:47	Luke-Jr:	maaku: how can you make it opt-in, if full nodes now need to prove transfers from the side chain?
18:53:03	Emcy:	wait so you could destroy a coin in one chain and create some sort of antimatter counterpart in another different chain
18:53:10	Luke-Jr:	jtimon: why won't people accept TBC? ;)
18:53:13	maaku:	Luke-Jr: SNARK two-way pegs
18:53:16	Emcy:	in the same trustless manner as coin melting within one chain?
18:53:25	maaku:	Emcy: yes
18:53:25	jtimon:	Luke-Jr 2way peg
18:53:44	jtimon:	TBC and BTC are the same currency, just different denominations
18:53:54	Emcy:	well ok then
18:53:59	Luke-Jr:	jtimon: doesn't change my point
18:54:11	Luke-Jr:	jtimon: people don't want to deal with multiple systems
18:54:16	sipa:	two&way pegging can certainly be done in a way that is safe for bitcoin
18:54:19	Emcy:	still sounds far fetched
18:54:25	Luke-Jr:	just getting BTC added to prices is hard enough
18:54:31	sipa:	whether it can be done safely for the sidechain i'm not convinced
18:54:33	jtimon:	mine either, it is irrational for people accepting btc not to accept TBC
18:54:47	jtimon:	well, maybe laziness...
18:55:29	Emcy:	yes im sure people will give up 10,000 years of base 10 maths indoctrination soon
18:55:32	Luke-Jr:	it's the "communication" part of currency
18:55:45	Luke-Jr:	Emcy: more like 1000
18:56:04	jtimon:	fair enough, anyway, I don't like the chiemgauer-like-coin, if you believe demurrage provides greater stability, why would you want to peg to btc?
18:56:17	Emcy:	romans at least were base 10
18:56:41	Emcy:	the numerals changed every decenary or whatever
18:56:49	sipa:	can we keep number base discussions outnof here please
18:57:02	Emcy:	oh fuck it im not going to pretend to be a numeracy historian
18:57:34	maaku:	sipa: it's symmetrical to both chains
18:58:14	Luke-Jr:	Emcy: #tonal
18:58:42	Emcy:	maaku could this snark thing be done with something like namecoin? Or a chain dedicated to coloured coins/contract records
18:58:42	sipa:	maaku: i'll explain tomorrow :)
18:58:53	sipa:	Emcy: yes
18:58:59	maaku:	sipa: on the side chain you pre-mine some coins and then send them to the peg-pool
18:59:06	maaku:	sipa: ok
18:59:06	Emcy:	could be useful
18:59:45	maaku:	Emcy: that's what we're transforming Freicoin into
19:01:31	Emcy:	what? a token chain?
19:01:50	maaku:	pretty much
19:02:21	Emcy:	but it has demurrage
19:03:24	maaku:	a chain for asset issuance, smart property contracts, expanded scripting language, etc.
19:03:28	Luke-Jr:	what does that imply for my freicoins? :P
19:03:36	maaku:	the demurrage keeps the host coin (freicoin) from competing with bitcoin as a store of value
19:04:24	justanotheruser:	justanotheruser is now known as just[dead]
19:05:32	maaku:	Luke-Jr: I would think this establishes a desireable use case for freicoins as the trustless host currency for smart contracts and therefore is a value-adding proposition
19:05:42	maaku:	but we've wandered into #freicoin territory and I'll drop the discussion here
19:16:52	just[dead]:	just[dead] is now known as justanotheruser
20:04:21	justanotheruser:	justanotheruser is now known as just[dead]
20:56:33	rastapopuloto:	rastapopuloto has left #bitcoin-wizards
23:30:31	execut3:	execut3 is now known as shesek