02:04:48	Dr-G2:	Dr-G2 is now known as Dr-G
04:14:04	TrollsRoyce:	evening all
05:30:23	Meeh:	Meeh is now known as mikalv
07:29:18	Eliel:	< gmaxwell> I thought I was oh so smart brining relativity a distributed protocol argument; only to find out later that lamport did it first, before I was born. :) <- I don't get it. Why would it make the idea less smart (or not smart) that someone else has done it before? You obviously didn't know about it before.
07:33:25	Luke-Jr:	Eliel: well, it makes it non-groundbreaking I guess
07:34:30	Eliel:	at least for me, that does not reduce how smart you need to be to come up with the idea by yourself.
07:35:40	Luke-Jr:	sure, but some might consider an idea slightly less innovative if >X person thought of it in Y years
07:40:01	phantomcircuit:	Eliel, because everything he's been reading has known about it
07:40:17	phantomcircuit:	hell he might have read about it and just cant remember doing so consciously
07:40:37	phantomcircuit:	(even understanding most of this stuff requires that you be pretty damned smart)
07:42:36	Eliel:	no argument there :)
08:05:16	orwell.freenode.net:	topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
08:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: andy-logbot AaronvanW Guyver2 wallet42 bsm117532 moa RoboTeddy dgenr8 todaystomorrow super3 nsh TheSeven tacotime Dr-G altoz go1111111 mortale DougieBot5000 cym Dizzle e4xit Sangheili Transisto HaltingState jchp grubles MoALTz Graftec starsoccer Luke-Jr Krellan_ kanzure samson_ spinza mikalv EasyAt BigBitz rfreeman_w|off pajarillo melvster fanquake Starduster phantomcircuit gwillen mappum nuke1989 BrainOverfl0w Dyaheon SDCDev HM_ Graet
08:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: mr_burdell andytoshi otoburb realzies Adohgg Guest95624 DEREK| comboy postpre nsh- Alanius mkarrer_ CryptOprah_ DoctorBTC btc jgarzik Keefe waxwing tromp__ smooth koshii quackgyver michagogo warren throughnothing_ Muis artifexd Fistful_of_coins grishnakh__ azariah4 sipa jaromil Hunger- zibbo tromp_ fierbuq copumpkin pi07r wiretapp1d forrestv OneFixt harrow K1773R pigeons iddo cfields [\\\] bobke drawingthesun midnightmagic CodeShark Logicwax
08:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: maaku polyclef LarsLarsen1 Anduck xenogis zling_____ Eliel helo crescendo epscy mmozeiko Guest50253 asoltys berndj-blackout BlueMatt digitalmagus7 sl01 weex Iriez abc56889 espes__ lechuga_ SomeoneWeird bbrittain nanotube rs0 davidlatapie hollandais jbenet poggy_ TD-Linux gmaxwell a5m0 tjopper catcow amiller dansmith_btc danneu LaptopZZ_ burcin optimator_ jcorgan [d__d] ryan-c petertodd UukGoblin wizkid057 kinlo so @ChanServ Apocalyptic lianj
08:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: wumpus nkuttler roasbeef gribble phedny
09:28:16	wallet421:	wallet421 is now known as wallet42
09:44:57	sipa:	ha, i just wished we could redesign bitcoin and have merkleized commitments everywhere
09:44:59	petertodd:	sipa: basically you either add the last vout op_ret commitment, or you add a per block tx index commitment, the former is cheaper to prove than the latter
09:45:12	petertodd:	sipa: speaking of: https://github.com/petertodd/python-merbinnertree
09:46:20	petertodd:	sipa: does postfix path compression, so using it for small numbers of elements is very cheap, and the algorithm is still deterministic
11:44:58	nsh:	sipa / petertodd: what would be the main advantages to using merkleized commitments? (what would they replace or supplement?)
11:45:26	petertodd:	nsh: what type of merkleized commitment specifically?
11:45:42	nsh:	unsure, whichever you'd imagine implementing perhaps
11:46:24	nsh:	is it a case of reducing the redundant validation of transactions between nodes?
11:47:15	petertodd:	well, suppose everything was merklized in bitcoin: you could easily create compact fraud proofs by just evaluating whatever failed validation, recording what parts of the global consensus data structure were touched by that verification, pruning everything else and distributing it
11:48:06	petertodd:	nsh: e.g., see the unit tests for my merkle radix tree library: https://github.com/petertodd/python-merbinnertree/blob/master/merbinnertree/test/test.py#L156
11:48:29	petertodd:	that prove_contains() function is very primative, but basically it returns a tree with everything but a set of keys pruned away
11:48:43	nsh:	interesting
11:49:25	petertodd:	next I need to finish off my implementation of prove_put(key_value_pairs) which will return the minimum tree required to prove the addition/modification/removal of a set of keys/value pairs to a given tree
11:51:16	nsh:	can you compose proofs? (so they act kind of like diffs/commits to the tree, and nodes can dynamically repair/update each other's consensus data structures depending on what they don't know with some efficiency?)
11:51:53	petertodd:	sure can! I've got a untested implementation of that in the form of tree.merge(other_tree)
11:51:59	nsh:	awesome
11:52:53	petertodd:	merge() takes two trees and returns a tree capable of proving the union of all operations in both trees; tree.update(other_tree) updates one tree with the key/value pairs of another
11:53:14	petertodd:	both have efficient implementations - I think! haven't finished off that code yet
11:53:17	nsh:	i suppose you get the same relatively-subtle propagation deanonymisation side-channel gotchas with that as we have with block propagation currently (possible to from how nodes request their trees to be updated when they knew about transactions)
11:53:36	nsh:	*to know from how
11:53:40	petertodd:	oh, for sure, not surprising there
11:53:46	nsh:	right
11:55:12	nsh:	"closest() Return the key:value pair whose key is closest (rounding?) to a given key." - what does this mean if keys as supposed to be hash-like?
11:55:25	nsh:	*are
11:56:18	petertodd:	well, the algorithm assumes that keys() are randomly distributed and fixed length, IE the outputs of cryptographic hash functions. however I was thinking "closest()" might be useful if you want to treat it as a append-only tree instead, say for txo commitments
11:56:51	petertodd:	that README has a lot of "sketched out only" features :) I was trying to get a sense for what the requirements might be
11:56:57	nsh:	* nsh nods
11:58:41	petertodd:	for instance, having like, five different types of nodes is a requirement if you want the scheme to be both deterministic and be able to product very compact proofs for trees with small numbers of items in them
11:59:45	nsh:	interesting
12:00:12	petertodd:	relax any of those requirements and the complexity drops... but needing to do >160 rounds of hashing to calculate the path to the tip of the tree is a ugly real world issue
12:00:54	nsh:	* nsh nods
12:00:56	nsh:	can you assign an objective measure to the space of consensus states? i mean, certain sets of transactions will be equivalent in beginning and end state, i suppose, but with a different or more/less lengthy path
12:01:50	petertodd:	well, if your UTXO set was a merbinner tree, sure, it'd be dead easy to compare how different sets of transactions changed different parts of the keyspace
12:02:05	petertodd:	for instance, diffing two trees is fairly cheap
12:02:51	nsh:	but there's some value there being equivalent ways to traverse from one state to another (intuitively, anonymity is a function of this equivalence in some sense)
12:03:19	petertodd:	well, that's quickly becoming a very deep statement :)
12:03:26	nsh:	mmm :)
12:03:55	petertodd:	I mean, I'm writing that library to support a coloredcoins library I'm also writing - basically I want compact proofs of color
12:04:10	nsh:	* nsh nods
14:20:48	bsm117532:	petertodd: why a Merkle **radix** tree? Hashes are unlikely to have a substrings of sequential digits that are equal, so does the optimization of a Radix tree buy you anything? (Or perhaps you mean a Radix Trie instead of a Radix Tree?) http://en.wikipedia.org/wiki/Radix_tree http://en.wikipedia.org/wiki/Trie
14:44:16	Guest38567:	Guest38567 has left #bitcoin-wizards
15:35:57	zack-truthcoin:	Andrew Poelstra wrote a paper about how POS is impossible: https://download.wpsoftware.net/bitcoin/pos.pdf
15:35:59	zack-truthcoin:	I think his arguments rest upon a false assumption. He assumes that every node will download the longest blockchain, without doing any other checks to see if it could be a long-range attack.
15:36:01	zack-truthcoin:	If you take the assumption to be true, it is easy to show that long-range attack is always possible.
15:36:03	zack-truthcoin:	In my idea, these longer POS forks created from expired resources are distinguishable altcoins, because it is impossible for the same address to own money on multiple forks. Committing a long-range attack is identical with forking the code and launching an alt-coin.
15:36:05	zack-truthcoin:	implementation details below:
15:36:07	zack-truthcoin:	I start with this https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/ and make a couple changes.
15:36:09	zack-truthcoin:	1) The reward for mining a block should be negative. No one makes blocks until there are enough transaction fees to pay for a new block.
15:36:11	zack-truthcoin:	2) The POW for each block should be far lower. 5 seconds on a core 2 DUO doing CPU mining.
15:36:13	zack-truthcoin:	I deviate from Vitalik's Slasher in a couple more ways, but to explain them, I need to explain how Vitalik's Slasher is broken. This is called a "long-range attack". There is no incentive to protect old private keys after you spend the money. It is possible that someone could collect a lot of old private keys, and that person would own more than 50% of money at a time in history. With this they can
15:36:15	zack-truthcoin:	build a fork which is longer than the real fork. When new people download a client and join the network, they will download the wrong fork, and will be unable to receive funds.
15:36:17	zack-truthcoin:	To make this type of attack impossible, I make the following changes.
15:36:19	zack-truthcoin:	1) Everyone must periodically pledge to a fork, your money gets deleted in every other fork.
15:36:21	zack-truthcoin:	2) If anyone simultaneously pledges to completing forks, their money is erased in both forks.
15:36:23	zack-truthcoin:	3) Each node needs a list of public keys that have money. When a node boots up, it downloads the longest blockchain where at least one of the public keys from the list still has money.
15:37:54	andytoshi:	zack-truthcoin: addresses don't own money, so it's vacuously true that they cannot own money on multiple forks
15:39:00	bsm1175321:	"It is impossible for the same address to own money on multiple forks". This is demonstrably false. e.g. consider a fork from a double spend. ALL address and balances are the same on both forks. All addresses (except possibly one or two involved in the double-spend) have balances on both forks.
15:39:04	andytoshi:	also wtf is an "expired resource"
15:39:28	andytoshi:	zack-truthcoin: if you use the word expired in a derivation of distributed consensus, you are begging the question. this is addressed in the paper. read it again.
15:39:51	bsm1175321:	bsm1175321 is now known as bsm117532
15:40:34	andytoshi:	bsm117532 is correct (if you mean what i think you mean by "addresses owning money", i.e. there existing utxos labelled by the address)
15:44:35	bsm117532:	I think a huge flaw in the PoS thinking is that a blockchain is a representation of anything of value in the first place. It's just a list. A sort of distributed associative array. The PoS assumption revolves around the idea that all actors want to maximize their balance. To kill PoS you only need to have an actor for whom this is not true. e.g. discharge your balance through an exchange into another asset, an
15:44:47	zack-truthcoin:	For slasher to function, we need the ability to quickly verify how much money is associated to each address. "expired" in the context of a long-range attack. Where you purchase old expired private keys that no longer have value to their creators.
15:46:02	bsm117532:	zack-truthcoin: so you need to "expire" with every block. You have a centralized system, signing valid blocks, because 1 block back is enough to start an attack.
15:46:10	andytoshi:	zack-truthcoin: "old" is still begging the question
15:46:23	zack-truthcoin:	in response to bsm1175321: a double-spend fork is handled by the pos signers from slasher. It is impossible to own money on multiple forks created via long-range attack.
15:46:52	andytoshi:	you need to (a) stop begging the question, (b) actually address the costless simulation argument (which rests on basically no assumptions about network actors)
15:47:31	zack-truthcoin:	bsm117532: actually, attacks less than 3000 blocks back are protected by slasher. My new method is for defending from attacks from longer than 3000 blocks ago.
15:47:37	andytoshi:	(c) write it up rigorously. i'm tired of having this same old argument, that's why i wrote the stupid paper
15:47:40	andytoshi:	andytoshi has left #bitcoin-wizards
15:48:14	zack-truthcoin:	What does "begging the question" mean?
15:48:17	bsm117532:	andytoshi = Andrew Poelstra?
15:48:36	bsm117532:	Too bad he left, I read a draft of what you just posted last night. Apparently I missed the final version. :-/
15:48:46	bsm117532:	(what he posted)
15:50:50	dgenr8:	bsm117532: well said re PoS incentives
15:51:08	dgenr8:	bsm117532: there's also the ugly motivation - that those with money should control the system proportinally
15:52:02	bsm117532:	FWIW I'm paraphrasing Andrew's words there.
15:52:17	bsm117532:	(from his paper)
15:52:59	bsm117532:	But I'm also working on a talk/podcast titled "Where does crypto-coin value come from?" which touches a lot of this. I'll post it here when I'm done.
15:53:12	zack-truthcoin:	I read his paper multiple times before, I would have never realized this alternative type of consensus without andytoshi's help.
15:55:34	dgenr8:	bsm117532: all the same, well said. the words balance, asset, maximize or discharge don't appear in andytoshi's definitive pdf
15:55:50	bsm117532:	thanks
16:17:29	bsm117532:	So I've had it in my head for a while that if "Fair 2-Party Exchange" exists (where each party in a data transmission receives a non-repudiatable, verifiable receipt), solving something related to the byzantine generals problem may become a lot easier. In byzantine generals, messages can be forged or receipt not acknowledged, and it seems that both of those assumptions can be removed in the real crypto-world. Doe
16:18:50	sipa:	Doe?
16:19:12	bsm117532:	Fawn? Can you be more specific? ;-)
16:20:05	sipa:	Your line ends in "removed in the real crypto-world. Doe"
16:20:13	sipa:	(yes, IRC has a line length limit)
16:20:15	bsm117532:	boo to your IRC client.
16:20:21	sipa:	Not mine.
16:20:22	bsm117532:	Does anyone know of any literature attempting to solve byzantine generals (or a similar problem) under the assumption of fair exchange?
16:21:03	sipa:	The protocol specifies a line limit (510 characters, iirc) or it's at least a server-side option. Most clients don't bother splitting lines up and just truncate.
16:21:51	bsm117532:	https://developer.pidgin.im/ticket/4753 But it lets you type long messages...
16:21:56	bsm117532:	*sigh*
16:23:05	sipa:	bsm117532: so, the message may be lost or modified in transit, but if it received correctly, you're *guaranteed* to received a confirmation of that, and that confirmation itself is not subject to byzantine behavior?
16:23:20	sipa:	is there a bound on how long it takes to receive that confirmation?
16:23:40	bsm117532:	sipa: Yes. This is possible under "Secure Two-Party Confirmation", and it's time consuming. A better algorithm certainly exists.
16:23:55	bsm117532:	Sorry..."Secure Two-Party Computation" e.g. garbled circuits.
16:24:23	zack-truthcoin:	https://github.com/zack-bitcoin/slasher/blob/master/pos.pdf I wrote up a PDF about proof-of-stake, as andytoshi suggested
16:24:39	bsm117532:	But just imagine that both parties sign the transmitted data with their private key and send the signature. (This is obviously not "fair" but ends up with a receipt in the same way)
16:31:54	bsm117532:	zack-truthcoin: Thanks for the write up. Just some constructive criticism: could you try to provide some more background? Could you provide a brief description of Slasher? Can you give a complete description of your idea without making everyone read a blog post and fill in the blanks? A good argument will attempt to analyze all possible attack vectors you can think of to your new algorithm.
16:32:42	bsm117532:	Then as one of my colleagues used to say: put it in a drawer and wait a week. Then read it again and make improvements. You wrote this quickly and your arguments are not clearly presented.
16:33:27	bsm117532:	(Personally I'm not 100% convinced that PoS is impossible, and would be happy to read a good, well-presented idea)
16:43:49	zack-truthcoin:	If the person doesn't care enough to know how slasher works, then I doubt they would care to know how my version works either.
16:45:28	bsm117532:	I care, and there are 1000 things out there to read. Slasher is on my list but I haven't gotten to it yet. Be succinct: http://paulgraham.com/power.html
16:49:22	bsm117532:	In academia we have the referee process to cull some of the bad ideas. In bitcoin, everyone with a blog posts half-baked ideas, and they just feed off each other and make a mess. :-/ Separating the wheat from the chaff is hard. Make it easy on your reader. ;-)
16:54:46	zack-truthcoin:	I am a big fan of Paul Graham's essays. I could start by explaining the theory behind hashing algorithms, since that is necessary background too.
16:59:22	bsm117532:	I'm using your links against you. I got it from your github, but I agree with Paul Graham. ;-) I think assuming the reader knows Slasher is not reasonable background knowledge (one blog post does not common community knowledge make), but hashing is common knowledge here.
17:12:56	andytoshi:	zack-truthcoin: re https://github.com/zack-bitcoin/slasher/blob/master/pos.pdf you do not define "attack chain" or explain how it is different from any other chain
17:13:13	andytoshi:	it appears you are advocating refusing to reorg, this will obviously just create permanent forks
17:13:59	andytoshi:	"begging the question" means that you are assuming what you are trying to prove. in the case of distributed consensus it almost always means you are assuming a globally-recognized time ordering, when that is what distributed consensus tries to create
17:14:19	andytoshi:	bsm117532: i am indeed andrew poelstra
17:15:21	andytoshi:	"Everyone must periodically pledge to a fork, your money gets deleted in every other fork." <-- o.O so now consensus depends on every party being aware of every single fork?
17:15:34	bsm117532:	Cool, I read an earlier draft of that document last night. This one: http://download.wpsoftware.net/bitcoin/alts.pdf
17:15:56	andytoshi:	bsm117532: alts.pdf is actually the newer one, i should update pos.pdf to reflect that ..
17:15:57	bsm117532:	Ok maybe a later draft of something new that contains some of the same arguments. ;-)
17:16:05	andytoshi:	the actual PoS stuff is word for word identical for both docs
17:16:10	bsm117532:	Yeah
17:16:13	andytoshi:	but alts.pdf has some more context about what distributed consensus is
17:16:47	bsm117532:	There are lots of unfinished bits in alts.pdf.
17:18:51	andytoshi:	yeah :/ it slowly gets better
17:19:34	andytoshi:	i had somebody contact me in may saying he was citing it in his masters thesis, pls finish it, and i told him i would :(
17:19:52	andytoshi:	it roughly doubled in size since then but as you can see it probably needs to double again
17:20:59	zack-truthcoin:	I refuse to reorg when people disagree about stuff 100 blocks ago, they are treated as alt-coins. if it is less than 100 blocks, then the longer one is dominant and takes over. I agree that permanent forks will occur. on purpose. Just like litecoin and all the other alts.
17:21:09	zack-truthcoin:	In my scheme, if you leave your computer off for a long time, then all your money gets deleted.
17:21:24	andytoshi:	ok, you should state that explicitly
17:21:33	zack-truthcoin:	ill put it up top
17:23:05	andytoshi:	you should also check out #tendermint, it also has security model that depends on constant connectivity to maintain trustlessness, and fails into a trustful mode for new users and offline ones
17:23:43	andytoshi:	...not that jaekwon has updated his papers to reflect that...
17:24:04	Eliel:	zack-truthcoin: that scheme makes DoS attacks very dangerous. They can lose you your money.
17:25:17	zack-truthcoin:	Eliel, care to elaborate? You will be the first person to find a vulnerability in this new protocol.
17:25:42	andytoshi:	wat? "if you leave your computer off all your money gets deleted" is a vulnerability
17:25:58	Eliel:	zack-truthcoin: computer off for a long time is the same thing from network perspective as DoSed for a long time.
17:25:59	andytoshi:	as is the guaranteed existence permanent forks
17:27:07	zack-truthcoin:	I don't think the permanent forks are a vulnerability. it is healthy type of reproduction, like forking someone's codebase and launching a new alt.
17:27:20	zack-truthcoin:	Eliel: ok, I understand
17:27:41	andytoshi:	zack-truthcoin: then you need to stop using the word "consensus"
17:28:13	sipa:	If they're not a vulnerability, we're trying to solve the wrong problem.
17:28:15	zack-truthcoin:	do you ever accidentally boot up dogecoin, and think that all your bitcoins have gone missing?
17:28:26	zack-truthcoin:	Why is it not consensus if people can fork my codebase?
17:28:35	andytoshi:	zack-truthcoin: pls read alts.pdf
17:28:35	sipa:	Because it is intentional.
17:29:01	andytoshi:	section 6
17:29:10	sipa:	In case of an involuntary fork, you end up with two groups of people, and those aware of the fork are able to spend their pre-existing coins in both.
17:29:58	sipa:	In case of a voluntary fork, you're creating a new (probably initially worthless) currency that just bootstrapped with the same values assigned as some point in time of some other chain. Nobody in the original chain cares.
17:30:15	zack-truthcoin:	the only way to create forks in my scheme involves a lot of complex steps. Everyone it involves would have to voluntarily agree to be involved. It is the same as forking someone's code and launching an alt. You cannot trick people into thinking your fork is the one they are on.
17:30:42	zack-truthcoin:	because your fork would have different addresses entirely
17:30:54	zack-truthcoin:	none of the same people have money
17:31:48	zack-truthcoin:	it is like creating a new initially worthless currency where everyone who signed up has as much money as they had at that point in history.
17:32:03	zack-truthcoin:	but with new addresses
17:32:45	sipa:	If the fork is involuntary, you can't assume that people will be aware of it.
17:33:22	zack-truthcoin:	the fork is only valid if everyone signed on it every 100th block.
17:33:28	zack-truthcoin:	How could they be unaware of what they had signed?
17:33:31	andytoshi:	i'm curious how transactions are created which are forced to be in one fork or another before the fork has even happened
17:33:41	andytoshi:	literally every party signs every 100th block?
17:33:44	zack-truthcoin:	yes
17:33:53	andytoshi:	with what keys?
17:34:01	zack-truthcoin:	yes, that is why you need your ocmputer on
17:34:10	zack-truthcoin:	the private key
17:34:14	andytoshi:	what private keys?
17:34:19	zack-truthcoin:	the same that is used to spend coins
17:34:30	sipa:	sipa has left #bitcoin-wizards
17:34:39	andytoshi:	so when i make a tx, i have to sign every other tx in the block ... and then resign whenever a new tx comes in
17:34:57	zack-truthcoin:	if they are caught signing onto competing forks, then they lose all money.
17:35:20	andytoshi:	that is totally insane, you are O(n^2) signing in the number of signing keys, O(n) verifying, O(n) space per block, demand constant connectivity and you still have insane failure modes
17:35:21	zack-truthcoin:	you pledge 100 blocks into the past
17:35:26	andytoshi:	and what you are describing is not even consensus
17:35:38	zack-truthcoin:	so if we are on block 1000, everyone pledges to block 900
17:35:41	andytoshi:	andytoshi has left #bitcoin-wizards
17:36:52	andytoshi:	zack-truthcoin: https://download.wpsoftware.net/bitcoin/alts.pdf section 6
17:36:54	andytoshi:	andytoshi has left #bitcoin-wizards
17:43:54	zack-truthcoin:	"i'm curios how transactions are created which are forced to be in one fork or another before the fork has even happened." This is the beautiful central idea of slasher. If anyone can prove that someone else signed on 2 blockchains, then the accusor gets the money, and the criminal gets punished.
17:45:36	zack-truthcoin:	anything in particular I am looking for in these 7 pages? I feel comfortable with all these concepts already...
17:46:37	zack-truthcoin:	I can address your "non-fundamental flaw" in a cool way
17:48:32	zack-truthcoin:	it says "can I use stake to get more stake? if so then the above applies". I carefully designed the protocol to avoid this. It is impossible to use stake to get stake, in fact the block reward is negative. Usually no blocks are made until enough transaction fees are gathered to afford the block.
17:51:49	zack-truthcoin:	if the internet broke in half, there would be more bitcoin hash-power on one side than the other. When the internet re-connected, the larger side would survive, and transactions from the small side may get double-spent. my slasher has the same failure mode as bitcoin, if that were to happen.
18:25:37	devrandom:	oooh
18:26:47	devrandom:	here's a wizard meditation topic:
18:27:17	devrandom:	perform velocity control over an HD wallet using a third-party signer without losing privacy to the signer
18:27:47	devrandom:	i.e. without the signer being able to tie different transactions from the same wallet
18:29:37	devrandom:	I think this requires the third-party signer to perform an oblivious computation on an accumulator that the client maintains
18:30:32	devrandom:	(third party signer - as in multisig... say 2-of-2 or such)
18:39:55	andytoshi:	devrandom: oleganza's scheme http://oleganza.com/blind-ecdsa-draft-v2.pdf almost does this ... it also blinds the output values to the signer tho
18:40:08	andytoshi:	and presumably for velocity control you care about them
18:45:41	andytoshi:	oh, but if your outputs are all the same size, then velocity controlling the # of signatures would naturally velocity control the flow of funds
18:45:58	devrandom:	interesting
18:46:07	andytoshi:	this is neat, maybe the first concrete usecase of oleganza's scheme :)
18:46:25	devrandom:	hm... how would the signer be assured that the outputs are the desired size?
18:46:46	andytoshi:	the output sizes would be capped by the total input size, and the signer would have to sign each input
18:47:20	andytoshi:	with oleganza's scheme you create outputs that can be spent by the scheme ... if you do this so that every one has bounded size (how to do this safely idk) then you will get a bound on the total output size
18:47:59	devrandom:	ok.. I meant the latter... how does the signer know that the inputs are the right size?
18:48:09	andytoshi:	signer doesn't know
18:48:55	andytoshi:	when you create the outputs that need the signer's cooperation to enforce, that's when you'd enforce the sizes
18:49:17	andytoshi:	eg by receiving user funds to a hotwallet which immediately bundles up the funds into signer-required outputs of the right size
18:50:03	devrandom:	I see
18:50:53	andytoshi:	the story would be the same if you were using ordinary multisig somehow
18:51:17	devrandom:	maybe you could have sub-wallets for holding multiple denominations... one size is a bit cumbersome
18:51:21	andytoshi:	these are nice in that (a) they don't require homomorphic encryption or anything weird, just lin algebra and EC point multiply, (b) they look like regular single-signer txes
18:51:41	andytoshi:	in that in the end a single bog-standard ECDSA sig is produced
18:51:54	devrandom:	right
18:52:28	devrandom:	this actually fits well with the "don't merge coins" philosophy
18:52:50	andytoshi:	unfortunately that oleganza.com link is poorly written ... i had talked to him a long time ago about cleaning it up, latexing it, simplifying the algebra, but he broke contact
18:53:02	andytoshi:	so i have a 50%-done clean version and no permission to publish it
18:54:15	devrandom:	hmmm
18:55:07	andytoshi:	what he wrote is correct, it's just noisy and has this weird usecase of say, velocity-controlling a non-tech-savvy family member's wallet
18:55:27	andytoshi:	which doesn't work because a non-tech-savvy family member obvs cannot do output size control
18:56:06	andytoshi:	and velocity-control by itself is not very useful for an individual anyway. if you are being robbed by malware it doesn't matter how slowly it happens
18:57:19	devrandom:	velocity control is pretty good if you are informed out-of-band as funds trickle out
18:59:02	andytoshi:	yeah. again, not sensible for a home user. your poor family member tries to by a TV online for 1BTC, gets a call that 1BTC was transferred, but doesn't realize that some malware has replaced the destination address before the blindsigner could even get involved
18:59:40	andytoshi:	for a corp obvs you would have better auditing than that, and would detect the problem quickly, so the velocity control helps to stem the damage while it's happening
18:59:50	devrandom:	yeah, that's an issue with blinded sigs... you can't have out-of-band confirmation of the destination
19:01:05	devrandom:	you could have one signer that you trust with private info, such as destinations (and BIP-70 invoices)
19:01:09	Eliel:	funny, I was pondering about a velocity controlled by default altcoin and wondering how that sort of a coin would change economy. As in velocity controlled such that you can only reduce your holdings by 20% per year.
19:01:16	devrandom:	and one or more signers just doing velocity limits
19:01:44	Eliel:	ah, no, not by default. Just no transactions without velocity control.
19:02:16	devrandom:	sorry Eliel, that was part of my previous thread of thought
19:02:25	andytoshi:	devrandom: yeah, and you can do that with regular bitcoin multisig so the different systems wolud not need to be compatibly
19:02:59	andytoshi:	Eliel: it's very hard to distinguish the holdings of individual users ... i guess the movement of every coin would be restricted so that only 20% of the total supply could be spent each year?
19:03:11	Eliel:	andytoshi: yep
19:03:51	devrandom:	maybe you could have fast coins and slow coins...
19:04:04	andytoshi:	a neat idea for a "credit card in a block of ice"-analogous sidechain..
19:08:33	Eliel:	the thought came out of thinking about the economy and how unstable income makes living difficult. Then I remembered that the main function of money is a way to distribute limited resources to people and started wondering if there's any point in cutting your share to zero the moment you get laid off, for example.
19:09:35	Eliel:	and the first thing that came to mind on how to implement that was velocity controlled money.
19:09:43	gmaxwell:	zack-truthcoin: andytoshi's paper really does address the argument you're making. If you haven't read the whole thing, please set aside your skepticism and desire to believe otherwise and read it patiently.
19:10:51	andytoshi:	Eliel: so, as an employee who wants that, you could ask to receive money denominated in a velocity-controlled coin ... (or on a velocity-controlled sidechain rather ... what is neat about that is that you can give your employer a "bitcoin address" which is actually a sidechain-transfer address, so it all looks the same from their end)
19:10:58	Eliel:	so, velocity controlled money would basically work as a smoothing function for your income.
19:11:03	andytoshi:	yeah, cool
19:12:10	Eliel:	and it might even smooth out the ebbs and flows of the exchange rate as well.
19:12:37	Eliel:	as it's just not possible to liquidate it all
19:12:46	andytoshi:	well, with a sidechain there is no exchange rate, it's just 1-1 .. i think a free exchange of a velocity-controlled money would result in private keys being transferred offline
19:12:59	andytoshi:	or people depositing to a service which did instant intra-service transactions
19:13:40	Eliel:	andytoshi: yes, if it was anonymous, you could sidestep that.
19:14:55	andytoshi:	i also don't think that a free exchange for velocity-controlled money makes sense. the whole point of it is to enforce a savings plan, if you can always just sell out then it weakens that
19:15:40	gmaxwell:	zack-truthcoin: in particular that idea you're calling "slasher" is not a new one, and predates that name by some time... it's not a solution. Imagine, for discussion, say at one point I buy up 60% of a POS coin (60% isn't required but makes the example simpiler). I mine for a while but later- perhaps months later- I sell that coin and walk away. I have now completely exited the system. Then after that I lose control of my old ...
19:15:46	gmaxwell:	... keys. Someone evil (maybe me) uses those keys to form a fake chain. A new party joining the network cannot distinguish the two chains. He can, perhaps, tell someone was naughty. But I can't be "punished": I've exited completely, retired on my tropical island outside of the reach of the system. And even if I could be "punished" who says I'd care? It's funny money- esp now that the fork has broken the system with new hosts ...
19:15:52	gmaxwell:	... completely unable to figure out which of two equally attractive looking networks is the real one.
19:15:53	andytoshi:	it is analogous to CPP or social security, except it wouldn't be gov't enforced, it'd be 'voluntary' (though maybe recommented by credit counselors, etc)
19:17:07	Eliel:	andytoshi: precisely.
19:17:38	Eliel:	the main problem is that if your monetary situation is in the dumps, it's very difficult to start using it.
19:18:14	gmaxwell:	You might want to invoke some kind of external trusted party to decide which of these chains is real, okay, but thats a pretty huge security assumption, since there is some risk that party might conspire with the attacker and guarentee success. There are all kinds of corner cases around this, like attackers making two plausable forks and announcing them at once to the honest network... if hosts are unwilling to switch to a ...
19:18:21	gmaxwell:	... replacement the network will diverge because there are two partitions which saw mutually exclusive forks first. etc.
19:18:25	andytoshi:	Eliel: well, hopefully you would know that you are the sort of person who needs income stability and would be giving employers velocity-controlled-coin addresses from the start
19:18:38	andytoshi:	but yeah, it's a tough transition
19:18:47	andytoshi:	because your cash-on-hand immediately drops
19:21:13	Eliel:	it'd need to be enforceable to be really useful though. Might need to wait until we have decentralized networks that are actually able to limit people to at most a few identities.
19:22:07	andytoshi:	nah, if you had a balance-based rather than output-based ledger you would just have a uniform 20%/year (or whatever) limit across the board
19:22:11	andytoshi:	no need to track individual identities
19:22:28	gmaxwell:	Eliel: is anything like that actually helpful beyond very rare cases? I would imagine that if you have the understanding that you'd benefit from something like that... that you'd just change your behavior. If you're so impulsive that you can't control yourself even understanding that you need to, you're probably going to have many problems far worse than money.
19:24:16	andytoshi:	gmaxwell: it moves the impulse control from "not buying something when you really want to" to "giving your boss a certain kind of address" which i think is a lot easier for people
19:24:38	Eliel:	gmaxwell: no, I don't need that myself.
19:24:40	andytoshi:	esp if you are already in the mindframe where debit/credit is not "real money"
19:24:59	gmaxwell:	Eliel: sorry, the you in my text was the abstract you, not you personally.
19:25:55	andytoshi:	for example people IRL put their credit cards in ice and that is helpful for them to control spending
19:26:08	gmaxwell:	really? weird!
19:26:15	andytoshi:	well, i've heard it on tv..
19:26:55	andytoshi:	i know someone personally who put his/her driver's license in ice as a binge-drinking deterrent and that was effective (though ofc only worked because s/he only took the bus!)
19:26:55	Eliel:	gmaxwell: there are people who are fragmented mentally like that.
19:27:34	gmaxwell:	I'm well aware of the many folks with out of control consumer credit spending; I'd thought that to be more a result of a failure to do math non-understanding of the consequences; never having been there myself I'm clueless.
19:28:58	Eliel:	gmaxwell: most of the time they can actually manage things just fine. Just some things activate some kind of a mental fragment that is more powerful than their normal state and that fragment only cares about some specific things.
19:30:34	gmaxwell:	(I spent much of my adult life thinking that _all_ credit/loans were scams; because the first time I learned about it as a young teen was a result of reading the terms for some credit offering that was at 20% APR or something, then I did the math and saw that it doubled your debt in under 4 years.. concluded it was a terrible awful scam and ignored all debt thereafter. It's much harder to be fiscially irresponsible without debt, the ...
19:30:40	gmaxwell:	... control loop is much shorter)
19:31:37	andytoshi:	right, as did i (my dad has a finance degree and i read all his old textbooks as a teenager) ... but you see in the ads "$200 for $20" which gives a hint as to who they are selling to
19:31:46	Eliel:	I've always disliked debt myself too. It just felt like throwing money in the garbage in th end.
19:32:25	andytoshi:	i've also seen tv shows about consumer debt (my dad likes these because having a finance degree means that he winds up being the advice-giver for lots of bad money manager friends/family) where the host comes in and talks to people
19:32:31	andytoshi:	and they say things that agree with Eliel's comments
19:33:53	gmaxwell:	It seems in america most people don't talk about money at a personal level at all, and it sort of handicapps everyone. E.g. I was misinformed about the actual scammyness level of debt for a long time; my misunderstanding served me well, by chance, but it was still a misunderstanding.
19:33:57	andytoshi:	and recommend solutions like putting money in jars with fixed amounts written on them, etc., anything to add a visible structure to the money (which you do when it comes in, not when you're trying to spend it because then you are looking at the thing you're buying against some abstract numbers)
19:34:29	andytoshi:	yeah, there is a lot of moral lying (if not outright lying)
19:36:35	andytoshi:	the point is i think Eliel's idea would be really really useful for people, assuming we had the sidechain tech to implement it (i think it'd totally flop as an independent asset)
19:37:56	gmaxwell:	I suspect just a wallet functionality is likely good enough. The reasoning is that if there was a non-third-party-trusting version of that them you could just sell your rate limited asset to someone else. So there is an upper bound to how frozen it can really make you.
19:38:22	zack-truthcoin:	gmaxwell: I know about selling old private keys. I agree that it is possible for the attacker to build a chain that is longer. but it is impossible for any address that has ever owned money on the legit chain to later be used to hold money on a fake chain. If there are 10,000 other users that you know about, and at least 1 of them still has money, then you can tell which fork is real.
19:40:28	gmaxwell:	zack-truthcoin: thats not so the fake chain can send funds to all sorts of addresses simulating the real chain, one does not need the recipents cooperation to send them funds; so I suspect I'm not understanding what you specifically saying there.
19:41:06	gmaxwell:	zack-truthcoin: But even ignoring that, your security then reduces to "trust one person" if that works for you; dispense with the PoX entirely and just ask that guy which chain should I be using. :)
19:42:16	zack-truthcoin:	If there were funds in the same address on both chains, then you would send a punitive transaction to both chains, and the funds would get deleted on both chains, and you would get a prize on both chains (in different addresses). I don't get "trust one person"?
19:42:17	bsm117532:	Keep in mind that in PoS the "longest chain" rule is just that: a rule, that one can choose to follow, or not. In PoW there is economic incentive driving that choice.
19:43:30	gmaxwell:	zack-truthcoin: Uh. I suspect I've confused you but I don't know where. Consider what you're saying: If I go make a fake chain, and on it send funds to a particular person I can cause that person to lose their funds on the real chain? Thats a pretty horrifying attack.
19:45:05	gmaxwell:	With respect to 'trust one person'-- imagine you ask the attacker.
19:48:43	zack-truthcoin:	the person owns funds on both forks until they choose one fork to pledge to. At that point, the other money is deleted. I don't see why you say "trust one person". At what stage are we trusting a single person? If one person showed you a set of 100 valid bitcoin blocks to make the chain longer, would you ignore him because he is a single person?
19:49:50	gmaxwell:	zack-truthcoin: In Bitcoin the blocks are their own evidence, they are undenyable proof of energy being spent.
19:51:56	gmaxwell:	zack-truthcoin: "deleted" ... this again, seems to have weird causality issues. Under this argument the attacker's funds on the real chain should have been deleted when the apparent earlier mining of it on the fake chain happened, and yet it was transfered on to other addresses... do you imagine that all subsiquent transactions of their would be invalidated on the main chain? If not, what do you even mean by deleted?
19:53:10	zack-truthcoin:	in regard to "truting one person": you mean a man-in-the-middle attack? If one person controls your internet, then they can eventually mine a block for bitcoin, and trick you into double-spend. all crypto are weak against man-in-the-middle.
19:53:56	gmaxwell:	zack-truthcoin: please do not refer to cryptocurrency as "crypto".
19:54:00	gmaxwell:	zack-truthcoin: Say you talk to Alice. Alice also happens to be in cahoots with the attackers. Alice pledges on the attack chain. You are now forever on the attack chain. Was that your desired outcome?
19:55:04	zack-truthcoin:	If Alice was man-in-the-middle attacking you, then she could do this, yes
19:55:35	zack-truthcoin:	if not, then you would be aware of other possible forks
19:55:39	gmaxwell:	zack-truthcoin: bitcoin is not weak to network attackers- is has significant security, though not an exponential gap. Mining a single block- after days of no block- won't convince pratically anyone or anything to follow a high value transaction. And even to do that requires a significant resource expendature (of more than 25 btc in cost currently).
19:56:13	gmaxwell:	zack-truthcoin: say you are connected to alice and bob. Bob is honest. Both make similar, but conflicting claims. How do you know who is honest?
19:56:14	zack-truthcoin:	yes, bitcoin blocks are way too expensive for this attack now, I agree
19:56:41	gmaxwell:	zack-truthcoin: the cost isn't just due to lost subsidy, its due to lost transaction fees too.
19:56:45	zack-truthcoin:	Alice has a public key, right? Does she have the same key for both chains?
19:57:07	gmaxwell:	zack-truthcoin: sure, keys are free and can be used everywhere.
19:57:30	zack-truthcoin:	then I would do a punitive transaction on both chains, and she would lose her money on both chains.
19:57:32	gmaxwell:	(or not, alices call)
19:57:47	gmaxwell:	wtf what if alice was telling the truth!?
19:57:57	zack-truthcoin:	?
19:58:12	zack-truthcoin:	you can't use the same public key for both chains
19:58:20	zack-truthcoin:	because you have to pledge your public key
19:58:36	gmaxwell:	Alice only 'pledged' for the attack chain.
19:58:59	zack-truthcoin:	she has different pubkey for the real chain then?
19:59:06	gmaxwell:	Bob is talking to you too (bob may well be a sockpuppet of alice, if it suits alice, but you can't tell), and bob is pledging for the other chain. Their claims are indistinguishable to you.
19:59:37	gmaxwell:	zack-truthcoin: she may not be a willing participant in the other chain at all.
20:04:25	zack-truthcoin:	If the currency starts with several hundred invested individuals, each one could share their public keys early on in history. So long as a single one of these people continues owning money, then you can tell which one is real.
20:05:10	zack-truthcoin:	in the fake chains, all the hundreds of people will have zero money.
20:10:33	gmaxwell:	zack-truthcoin: why not dispense with all the mining, pos, etc. and just ask one of those people which ledger is accurate?
20:11:49	zack-truthcoin:	if I just asked them, they could lie.
20:11:51	gmaxwell:	You keep saying "has money" but this doesn't make any sense, e.g. In my fake chain I could assign one cent to each of those 100 people, even if otherwise they had no funds there. So when you say 'has money' I assume you mean provide some kind of signed statement about which chain is real.
20:12:14	gmaxwell:	zack-truthcoin: and why can't they lie otherwise?
20:12:29	zack-truthcoin:	because they need to sign the pledges with their private key
20:12:43	zack-truthcoin:	and they cannot sign on competing forks
20:13:09	gmaxwell:	Private keys are not truth serums. :)
20:13:15	zack-truthcoin:	Each and every person needs to sign within 1000 blocks
20:13:35	zack-truthcoin:	If they sign on competing forks, then they lose the money on both
20:13:54	gmaxwell:	zack-truthcoin: They most certantly can sign on competing forks. They may not care at all about the 'money', they may have lost control of their keys, for example.
20:14:21	gmaxwell:	So lets talk about that each and every person requirement. So you propose that if anyone loses their key then the network stops?
20:14:23	zack-truthcoin:	if they signed on competing forks, then they disappear on both, and don't matter at all.
20:15:01	zack-truthcoin:	If every single person decided to ditch their old address at the same time, it would be a problem.
20:15:23	zack-truthcoin:	but we can't spend that many tx in a single block, it can't happen.
20:15:36	gmaxwell:	zack-truthcoin: for example, on fork 0 key A has funds, transfer them all to key B. Now A and B make exclusive pledges, what do you imagine happening?
20:16:19	zack-truthcoin:	I agree that the pledges do not stop money from duplicating. It only stops pubkeys from duplicating
20:16:25	gmaxwell:	zack-truthcoin: you just said _each and every_ coin holder has to sign within 1000 blocks. What happens if someone is unavailable for 1000 blocks or loses their coins? If every person is required, does the network stop? what did you actually mean there?
20:16:35	zack-truthcoin:	they just lose their money
20:16:59	zack-truthcoin:	it is the same as if they decided to sign on a competing fork
20:17:38	gmaxwell:	okay, so the majority can freely revoke the funds of any minority group in this system then?
20:18:10	zack-truthcoin:	what?
20:18:14	gmaxwell:	(or to be clear, at any point a majority can perform a perpetual revoccation of the funds of any minority)
20:18:28	zack-truthcoin:	does revoke mean steal?
20:18:33	Eliel:	no, delete
20:19:02	zack-truthcoin:	I am not certain that it is safe from all attack vectors. In what way are you proposing they revoke?
20:19:06	gmaxwell:	zack-truthcoin: The majority refuses to sign any chain which you've signed. So you cannot get your pledge into the consensus chain within the 1000 block window.
20:19:20	zack-truthcoin:	oh, that is why you pledge 100 blocks into the past
20:19:27	gmaxwell:	zack-truthcoin: you're adding a lot of complexity, so I'm trying to see if I understand what you're actually suggesting.
20:20:00	zack-truthcoin:	so if everyone ignores a recent block with your transaction, that same transaction will be included in a different block, and you don't get punished
20:20:03	gmaxwell:	zack-truthcoin: sure, but the majority just ignores your pledge for 1000 blocks. This makes you lose your funds, no?
20:20:12	zack-truthcoin:	because that thransaction signs over a block from the past.
20:20:28	zack-truthcoin:	you have 900 blocks to include the transaction in
20:20:32	zack-truthcoin:	surly one of the miners would include it
20:20:42	zack-truthcoin:	they want the tx fee
20:20:51	gmaxwell:	right, so a majority of the participants decide they're not going to permit that. If someone produces a block which includes your transaction, they ignore that one.
20:21:19	gmaxwell:	after 900 blocks then your funds are eliminated from the system, and the scarcity increases.
20:21:39	zack-truthcoin:	i might need a a few minutes for that question, it is really good
20:23:03	gmaxwell:	Well, its a tangent. I just wanted to make sure I understood what you're describing. I don't think this is at all the only new attack added in what you've been talking about... which I'm still no more convinced actually results in a decenteralized consensus that reduces to anything more than trust (some) fixed trusted parties. Just things to consider.
20:24:28	Eliel:	zack-truthcoin: this is the flip side of being too trigger happy about deleting coins. You easily open up gaping holes.
20:25:45	Eliel:	gmaxwell: although, I'm not sure if it's worth the effort to make the network resistant towards big majorities. They don't need to abide by the rules anymore anyway, they can fork a new chain where the minority has no more coins.
20:27:41	gmaxwell:	Eliel: huh? ?!?
20:27:49	gmaxwell:	Eliel: in bitcoin a majority has no such ability.
20:28:12	gmaxwell:	Eliel: blocks must still be _valid_ there is no way to take away someone's coins without their help, in valid blocks.
20:28:30	gmaxwell:	I do think distinguishing between short term majorities and long term ones is interesting and important.
20:28:55	gmaxwell:	(esp in cases where there isn't a physical rate limit on the production of blocks)
20:29:33	Eliel:	gmaxwell: big enough of a majority can rewrite the network rules while keeping the value of the coin.
20:29:45	zack-truthcoin:	A lot of bitcoiners would have wanted to do an attack like this against the MtGox funds, or DPR money. The majority squeezing out a hated minority.
20:29:59	Eliel:	so, they just migrate to a new chain where the minority has no coins
20:30:26	Eliel:	the minority can keep using the next to worthless old chain.
20:30:37	Eliel:	but it won't do them much good
20:31:24	zack-truthcoin:	I think that when a majority destroys a minorities coins this way, the attackers waste at least as much money as they destroy. Any people who chose to not attack are the winners.
20:32:19	Eliel:	the only real defense against this kind of thing is if the majority can't tell which coins belong to the minority
20:32:57	gmaxwell:	Eliel: Okay, you're assuming an economic majority. What it actually means depends on the selection metric. (e.g. is someone owning 1 coin weighed 1/10th someone owing 10 coins)
20:33:17	Eliel:	yes, economic majority is more accurate
20:33:58	gmaxwell:	Eliel: sorry for my slow understanding there, too much bitcoin thinking where the economic majority and consensus majority are mutually distrusting partially overlapping sets.
20:35:11	Eliel:	although, it's highly likely that a consensus majority is also an economic majority.
20:36:04	gmaxwell:	Eliel: in bitcoin? No way, sadly.
20:36:10	gmaxwell:	At least not right now.
20:38:27	Eliel:	although, I can see how it could happen that if someone owned 90% of the coins, then the owners of 10% could band together to remove those 90% entirely and the 90% owner couldn't really do a thing.
20:39:17	gmaxwell:	Eliel: yea, That was I was getting at wrt weight above.
20:41:05	midnightmagic:	why "sadly"?
20:41:36	Eliel:	in fact, I suspect if someone really owned 90%, it might even be a sensible thing to at least cut that down by a significant percentage.
20:42:33	Eliel:	I think something quite close to that has happened with an altcoin somewhere :P
20:43:42	gmaxwell:	midnightmagic: because if the economic majority decides to break the rules you're already kinda screwed (though the distinct consensus majority may provide some slight fairness increase); and in bitcoin if the consensus (mining) majority is evil you're also pretty screwed.
20:43:58	gmaxwell:	Right now a mining majority in bitcoin is controlled by ~3 people or so. This is very bad.
20:44:45	gmaxwell:	because part of it is via pooling that 'control' might not be all that stable, if abused, which makes the risks hard to reason about.
20:46:43	midnightmagic:	gmaxwell: Are you talking about a technical limitation or just "all these people dumping their coins and wrecking the economy"?
20:47:24	Eliel:	midnightmagic: the pool operator has "control" over what the pools mines but the individual miners in the pool are free to point their miners elsewhere.
20:48:05	Eliel:	thus, the control has the potential to vaporize if the poolop starts abusing the control
20:48:32	midnightmagic:	Eliel: Yes, I grok that; I've been a fairly active miner since about November 2010. I was curious why gmaxwell said "sadly" as my brain was having trouble deciding on a most-likely implication from that.
20:49:21	zack-truthcoin:	If a block costs $100 to purchase, and there are 1000 blocks until users have to pledge by, an attacker would have to spend 1000*(however much money the victim has) or a max of $1,000,000 to stop the victim from spending a single transaction for that length of time.
20:49:23	midnightmagic:	Specifically, what the ideal would be and why.
20:50:39	zack-truthcoin:	It reminds me of when a majority of people decide that someone is a criminal, and deserves to have their money taken.
20:50:53	zack-truthcoin:	prisoners are expensive
20:52:19	Luke-Jr:	midnightmagic: sadly makes sense IMO since the economic majority is a slightly better situation than the mining majority atm
20:52:43	Luke-Jr:	so having the economic majority in place of the consensus majority would be an improvement
20:53:48	midnightmagic:	Who are the economic majority? The owners of the majority of coins right?
20:56:34	midnightmagic:	Because I would say that that capital is not as liquid as rich folks buying new mining datacentres and funding business ventures.
21:00:03	midnightmagic:	So power of one versus another I was presuming was technically-centred rather than influence-centred, which would mean holders of the majority of coins (minus all those early unspent blocks, whoever they belong to.)
21:02:30	midnightmagic:	I'm just not sure I'd want either of those groups afforded any more control over the system.
21:02:54	midnightmagic:	(Since rich people are more evil on average.)
21:36:27	zack-truthcoin:	A write-up of my POS protocol: https://github.com/zack-bitcoin/slasher/blob/master/pos.pdf
21:36:29	gmaxwell:	zack-truthcoin: in a non POW system blocks don't have an inherent cost, a majority could just make them at zero cost.
21:37:05	zack-truthcoin:	they still need to be valid blocks though, so we can limit them in some ways.
21:37:33	zack-truthcoin:	having them pay a fee to create a new block for example
21:37:51	andytoshi:	"A simple counter-example to the costless-simulation argument is the relationship between litecoin and
21:38:05	andytoshi:	bitcoin" <-- this betrays a serious misunderstanding of costless simulation
21:39:05	andytoshi:	litecoin blocks are not costless, and they cannot even be created with bitcoins or bitcoin-related equipment
21:40:30	andytoshi:	also, my argument does not rest on the assumption that the longest chain is the correct one ... you can use any metric you want and the argument still goes through
21:40:43	andytoshi:	you are the first person to complain that the written argument isn't general enough :)
21:41:34	zack-truthcoin:	aha, thanks for catching that typo andytoshi, I fixed it and updated the document on github
21:42:08	andytoshi:	basically what i claim is that you are required to use a metric which is positively proportional to some external cost
21:42:19	gmaxwell:	zack-truthcoin: a 'fee' inside the system is not the same as a real cost... because its meaningless unless the chain replaces the best chain, and may not be a concern to a true byzantine attacker (who attacks even at a cost to themselves)
21:42:34	andytoshi:	for PoW chains, length serves this purpose .. for PoS nothing does because the blocks are costless to create
21:43:20	gmaxwell:	But 'for example' isn't help, is that what you're proposing? If you suggest a differnet system for every argument then no real analysis can happen. A real system need to be secure against all attacks not just a single one per system. :)
21:43:20	andytoshi:	i'm curious if you can think of another metric, i haven't considered that line of thought at all
21:44:08	andytoshi:	you might say "blockchains have no hair" necessarily because they have to be ambivalent toward the transactions that go inside them
21:44:31	andytoshi:	so they are basically an ordered container and nothing more
21:45:37	zack-truthcoin:	consensus in my pos is based upon 2 metrics. Who has money, and the number of pos signatures. The pos signatures fix any forks that are smaller than 1000 blocks, who has money fixes forks longer than that.
21:46:12	andytoshi:	well, you can't measure money without begging the question, and "number of pos sigs" is vulnerable to costless simulation because signing is free
21:46:28	gmaxwell:	You've repeated this a few times, but it still not making basically any sense to me.
21:46:56	andytoshi:	and these "1000 block limits" are always bad ideas, if you have reorgs of that size then you are cementing in forks, if not then they're pointless
21:47:06	gmaxwell:	The examples you've given about how this helps all sounded precisely like trusting a single original owner to resolve a dispute.
21:48:01	gmaxwell:	I.e. it hasn't really answered the questions andytoshi's paper claims, rather it just sounds like you're steadfastly ignoring them.
21:48:17	zack-truthcoin:	which question?
21:49:47	zack-truthcoin:	how is the number of pos sigs vulnerable to costless simulation?
21:50:05	zack-truthcoin:	they were elected 3000 blocks ago
21:50:52	andytoshi:	well, all blocks are the same.....but for the sake of argument how are the first 3000 blocks decided?
21:50:55	gmaxwell:	How the system can eventually decide without trusted third parties or an external process on which of two otherwise indistinguishable compeating chains is the 'correct' one, and reach the same decision for all participants regardless of when they joined or left the system.
21:51:27	zack-truthcoin:	because only one of the two chains has addresses of people you know with non-zero amounts of money
21:52:23	andytoshi:	what if people i know have committed to different chains?
21:52:27	gmaxwell:	zack-truthcoin: That isn't logically sensible to me. Say you know the attacker. So now you're on the attack chain? It seems in that situation the system has failed.
21:52:45	gmaxwell:	(even before you consider that if you know multiple parties you might have a conflict)
21:52:45	andytoshi:	what if i don't know anybody on the system?
21:53:01	zack-truthcoin:	andytoshi: if they commit to multiple chains then they lose their money on both chains
21:53:21	gmaxwell:	That sounds like an assumption that everyone you "know" (ignoring how knowing works) is honest, which would be a very tall assumption.
21:53:23	zack-truthcoin:	even the attacker can't have money on both chains under the same pubkey
21:53:29	andytoshi:	ok, well i'm not sure what happens in that case either (how that is detected by consensus) but i didn't say that happened
21:53:48	andytoshi:	well, any person can have as many pubkeys as they like..
21:53:59	gmaxwell:	zack-truthcoin: just assume that there is no 'ownership' overlap. Keys are free and everyone has sensibly rotated their keys out many times.
21:54:08	zack-truthcoin:	but if they put money on the same pubkey on both chains, then they lose the money on both chains
21:55:00	gmaxwell:	gah, please stop saying that. It's irrelevant to this, and it just makes me go back to the tangent that if thats really your criteria then there are bunch of really awful attacks where I create a fake chain and pay unwilling people on it.
21:55:08	andytoshi:	ok, so it seems like the safest thing for me to do is to put my money on a different pubkey for each chain, and do so for every chain that i know about
21:55:16	andytoshi:	otherwise i might miss the "real" one
21:55:17	zack-truthcoin:	there is positive incentive for people to use the same address for a long time. if any one person maintains their address, then we can tell their chain is the right one.
21:55:27	andytoshi:	wat
21:55:36	zack-truthcoin:	andytoshi: you are correct. different pubkey on each chain
21:56:20	andytoshi:	zack-truthcoin: … i just described a total consensus failure, if i've got different coins on every chain then i can double spend trivially
21:56:20	zack-truthcoin:	similarly, if I launched a new alt-coin today where everyone has the same amount of money as they do on bitcoin, it is in your interest to claim the free money I give you, even though it is almost worthless
21:56:42	zack-truthcoin:	this is not a consensus failure
21:56:48	gmaxwell:	zack-truthcoin: there is no 'claiming' money in Bitcoin.
21:57:06	zack-truthcoin:	let me explain the same thing again: If I were to create a new blockchain called
21:57:26	gmaxwell:	please stop with the tangent, just assume the attack is not a total moron and will behave optimally for their agenda. If its in their interest to simply use different pubkeys, they will.
21:57:29	zack-truthcoin:	"zack-coin" and it took a snapshot of bitcoin, to give everyone the same money
21:57:54	zack-truthcoin:	If they use different pubkeys, then it is obvious that it is a different blockchain.
21:58:43	andytoshi:	that's not a consensus system.
21:58:55	zack-truthcoin:	because...
21:59:02	gmaxwell:	zack-truthcoin: yes, it's "obviously" a different blockchain becuase there is more than one, or because the cryptographic hashes are different. The whole purpose of consensus in a decenteralized cryptocurrency is to decide which of multiple different otherwise equal blockchains is the one and only correct one, universal to all users.
21:59:35	andytoshi:	zack-truthcoin: because you haven't defined a total ordering on transactions
21:59:43	zack-truthcoin:	yeah, and if someone made a new blockchain, it wouldn't stop us from knowing which blockchain is the correct one.
22:00:02	zack-truthcoin:	"total ordering"?
22:00:10	andytoshi:	are you in high school?
22:00:14	gmaxwell:	zack-truthcoin: in bitcoin this is true because there is eventually only a single valid blockchain with the most computational work behind it.
22:00:15	andytoshi:	(just curious)
22:00:25	zack-truthcoin:	no
22:01:04	andytoshi:	sorry, i just meant, you're missing a lot of terminoligy
22:01:07	zack-truthcoin:	gmaxwell: in my ps this is truth because there is only one blockchain that is longest and also has the same money on it as expected.
22:01:11	andytoshi:	"begging the question" and "total ordering"
22:01:22	zack-truthcoin:	what field is that terminology from?
22:01:26	andytoshi:	zack-truthcoin: a total ordering is one in which for any two transactions, one definitely comes after the other
22:01:28	andytoshi:	zack-truthcoin: mathematics
22:01:31	andytoshi:	and computing science
22:01:37	gmaxwell:	begging the question is just standard english.
22:01:59	zack-truthcoin:	Sorry my english isn't good enough.
22:02:22	zack-truthcoin:	why do you think that the transactions need to be ordered? which transactions do you think need to be ordered?
22:03:11	andytoshi:	i think that's like the first paragraph of my PoS document
22:04:11	zack-truthcoin:	What attack do you think I am vulnerable to?
22:04:35	justanotheruser:	zack-truthcoin: doublespend which pretty much makes a blockchain pointless
22:04:48	andytoshi:	i join the system. i see many forks because everyone is required to track every fork (because they can invalidate each others' coins)
22:05:08	andytoshi:	i'm required to receive funds at different addresses on each fork because otherwise my coins will be lost (how to i enforce this? idk)
22:05:23	andytoshi:	at this point, i can spend my money on each fork independently
22:05:35	andytoshi:	and i've commited a double-spend attack -just by doing the rational thing-
22:05:41	zack-truthcoin:	you are not required to track forks at all.
22:05:41	andytoshi:	sorry, i've gotta run
22:05:54	andytoshi:	then you can't invalidate coins based on the contents of other chains
22:06:06	zack-truthcoin:	why not?
22:06:26	zack-truthcoin:	If someone signs with their private key, I can use their public key to prove they did it
22:06:34	zack-truthcoin:	if they signed contradictory things, I can prove they did it
22:06:37	justanotheruser:	zack-truthcoin: do you have a paper describing your system?
22:06:43	zack-truthcoin:	yes, one sec..
22:06:50	zack-truthcoin:	https://github.com/zack-bitcoin/slasher/blob/master/pos.pdf
22:07:39	justanotheruser:	"This is a weaker kind of consensus than POW consensus. If you you leave your computer off longer
22:07:42	justanotheruser:	than 2 weeks, your money will get deleted.
22:07:45	justanotheruser:	It is recommended to sell all your money for bitcoin before turning off your computer, every time.
22:07:48	justanotheruser:	wat
22:12:43	justanotheruser:	1) The reward for mining a block should be negative. Usually, no one makes blocks until there are
22:12:46	justanotheruser:	enough transaction fees to pay for a new block. It is impossible to use money to get more money.
22:13:15	justanotheruser:	in costless simulation, you can include other peoples tx and get their fees in your alternative history.
22:14:26	zack-truthcoin:	but in my pos you cannot include other people's tx during costless simulation. Each pubkey can only own money on a single fork.
22:15:16	justanotheruser:	it is trivial to generate more than one public key?
22:15:23	mr_burdell:	how do you initially distribute money with a negative block reward?
22:15:37	mr_burdell:	centrally?
22:16:13	justanotheruser:	mr_burdell: either that or with a mining phase (which has its own problems)
22:16:20	zack-truthcoin:	the genesis block gives a ton of money to a single address. The way to get money is to purchase it from someone else.
22:16:29	mr_burdell:	so centrally
22:16:50	zack-truthcoin:	it is trivial to make public keys, I agree.
22:20:30	gmaxwell:	zack-truthcoin: I'm unhappy that you're continuing to ignore the simple stuation that andytoshi and I laid out for you where the attacker alice has created an attack chain, and you know alice and alice is telling you that the attack chain is legit.
22:20:38	gmaxwell:	situation*
22:21:03	gmaxwell:	I'm not sure how I can pose this problem in any simpler manner.
22:21:41	zack-truthcoin:	of the many thousands of public keys that I know about, none of them would have money on Alice's chain, but many of them would have money on Bob's chain. so I would download from bob instead.
22:22:38	mr_burdell:	but both bob and alice say they have money on their chain... how do you know which is legit?
22:23:06	zack-truthcoin:	not possible. Once a public key has money on one chain, it can never be used to store money on any of the others.
22:23:25	mr_burdell:	but how do you know that if you're a new observer?
22:23:28	kanzure:	maybe if malicious nodes never existed..
22:23:33	gmaxwell:	::sigh:: There are several problems with that statement. One is that funds can be paid to any address at any time on any chain without the participation of the reciever. So you must mean something different from what you're saying there. Secondly you've said nothing about how you know of these addresses in the first place or why you're trusting them, thirdly you may know of addresses on each one, which produces a conflicting result.
22:23:53	gmaxwell:	kanzure: yes, lots of schemes are workable if byzantine attackers don't exist
22:24:04	kanzure:	i thought that would be obvious
22:24:30	zack-truthcoin:	you got the addresses from looking at the blockchain at an earlier point in history. It is not possible that some are on one fork, and others are on a different fork.
22:24:57	mr_burdell:	what if you never saw the blockchain before?
22:25:27	zack-truthcoin:	when the blockchain is very young, this is a possibility. people see it for the first time.
22:26:04	zack-truthcoin:	when it was first made, very tiny amounts of money is given to 2000 different people who all agree to keep it in the same pubkey. so long as a single of the 2000 still exist, then you know which fork to join.
22:26:23	gmaxwell:	That statement has nothing to do with the age of the blockchain. Participants may come and go. If you have an assuption that all future participants have joined the system from the start you must say it explicitly, as it would be a major limitation.
22:26:41	zack-truthcoin:	I am not making that assumption
22:26:49	gmaxwell:	zack-truthcoin: what if that single person is dishonest?
22:26:56	zack-truthcoin:	which single person?
22:27:31	gmaxwell:	The "single of the 2000"?
22:28:08	zack-truthcoin:	that person has 2 choices that I can see: 1) leave money in that pubkey 2) spend it. which one of these options is less honest in your eyes? neither threatens the system.
22:28:31	mr_burdell:	if you weren't originally one of the 2000, how do you find out who those 2000 were?
22:29:04	zack-truthcoin:	The genesis block is hard-coded into the source.
22:29:27	gmaxwell:	zack-truthcoin: he can do nothing, allow it to expire in the main chain, and then later use it in the attack fork and keep it alive there. Then by your metric the attack fork is the legitimate one.
22:29:46	zack-truthcoin:	even if it expired in the main chain, he still cannot use it to store funds on a fork.
22:30:03	zack-truthcoin:	once a pubkey is used once in a fork, it can never be used in any other fork.
22:30:07	gmaxwell:	zack-truthcoin: the fork has diverged before the funds expired in the main chain.
22:30:17	gmaxwell:	in the fork he did not allow them to expire.
22:30:47	zack-truthcoin:	I don't understand the scenario
22:31:33	mr_burdell:	so they can both be legit, but now you're saying they're two different alt coins?
22:32:25	zack-truthcoin:	it is possible to take a snap-shot of the any block, and launch a new currency from that point. Eveyone who wants to be involved has to move their money to a different address. It is a way to launch an altcoin.
22:32:32	gmaxwell:	There is a chain. At some point there is only a single of the original users left (your example). That original user allows his funds to expire, perhaps by accident or maliciously. Later he authors a fork that splits off the past history before that expiration, and in it he does not allow his funds to expire. There now exist two competing chains, one which has funds assigned to one of the original users in it, one which does not. ...
22:32:33	mr_burdell:	so what happens if one fork refuses to acknowledge another fork, and then you've successfully duplicated money
22:32:38	gmaxwell:	... By your earlier metric the former is the proper chain.
22:33:55	zack-truthcoin:	If he made a long-range attack, he needs to quickly move his funds to a different address, because he cannot pledge with the old address. He has 100 blocks to send the money to a different address, and then has ~900 blocks to pledge with his new address.
22:34:19	zack-truthcoin:	the 2 resultant forks never pledge with the same pubkeys ever.
22:34:35	gmaxwell:	zack-truthcoin: please respond to the situation I've laid out for you.
22:34:42	zack-truthcoin:	or if they do, the pubkey is punished on both chains.
22:35:14	zack-truthcoin:	I though I did respond to your scenario just now...
22:35:48	zack-truthcoin:	if he made a long-range attack, he needs to quickly move his funds to a different adress, because he cannot pledge with the old address. he has 100 blocks to send the money to a different address
22:36:19	gmaxwell:	mr_burdell: can you see any connection with the situation I've setup and zack's comments? Am I just missing it here?
22:36:24	mr_burdell:	is this supposed to be moderated by a central authority?
22:36:27	zack-truthcoin:	there would be 0 of the original people left on the original chain
22:36:44	mr_burdell:	gmaxwell: I think he assumes the forks know about each other
22:36:51	mr_burdell:	somehow
22:36:58	zack-truthcoin:	but everyone who is using the chain has an ever-growing list of active users, and can refer to that much larger list.
22:37:11	gmaxwell:	mr_burdell: but the absense of time travel can prevent that.
22:37:56	zack-truthcoin:	the forks do know about each other. there are 2 punitive transaciton types. If anyone is caught pledging on multiple chains, they lose their money. If any pos signer signs on multiple chains, they get punished.
22:38:32	mr_burdell:	yeah... that's where I'm lost
22:38:35	pigeons:	me too
22:39:08	gmaxwell:	zack-truthcoin: In the situation I setup Alice allows her coins to expire on the real chain. Some time, perhaps a thousand years later, alice creates a fork before that expiration point and simulates it up to the current height. Alice's original key exists in the fork, but not in the prior real chain. By the metric you described alice's attack chain would be the one true chain, as it contains an original keyholder.
22:39:47	zack-truthcoin:	her key never existed in the real chain? then how did she have money that expired?
22:41:06	zack-truthcoin:	my_burdell: imagine you had a privkey that you used to sign all your promises, and you told pigeons that 2+2=5 and promised with your privkey, and tole me 2+2=4 and promised iwth your privkey. if pigeon and I share our data, we could discover that you lied.
22:41:11	gmaxwell:	zack-truthcoin: it existed, she was one of the original participants.
22:41:22	zack-truthcoin:	then she can't have use the same pubkey on the attack fork.
22:41:43	gmaxwell:	zack-truthcoin: By what mechenism?
22:42:14	zack-truthcoin:	a punitive transaction. If anyone uses the same pubkey to pledge to contradictory blockchains, they lose all their money on both chains. the pubkey is blacklisted on both chains.
22:42:24	gmaxwell:	She did not pledge contradictory blockchains.
22:42:28	zack-truthcoin:	?
22:42:31	gmaxwell:	She allowed her coins to expire on the main chain.
22:42:40	gmaxwell:	(accidentally or maliciously, doesn't matter)
22:43:28	gmaxwell:	but in the fork, which branches before that expiration, she is observed pledging that chain and her coins never expire there.
22:44:12	zack-truthcoin:	ok, I think I understand the attack you are suggesting now.
22:45:45	gmaxwell:	I am just extending a condition that you set out, that a single person in the original set is required to still hold coins; and extending it to the simplest possible logical attack arising from that criteria.
22:59:50	zack-truthcoin:	I remember now! The method you describe does produce an alternative fork that has pubkeys. So we do the next step: we compare length.
23:00:06	zack-truthcoin:	blocklength increases with every block like this:
23:01:01	zack-truthcoin:	never mind. I need to think more on this.
23:01:57	zack-truthcoin:	delta blocklength=(number of pos signers)*((total coins on this fork)/(total coins at genesis))^10
23:02:01	justanotheruser:	zack-truthcoin: remember that distributed consensus is not a trivial problem. It wasn't solved until 2009
23:03:10	zack-truthcoin:	a fork created in the method you describe would have less than 1/2 the total coins on it. Using my delta_blocklength, the real chain will grow like 2000 times faster
23:04:11	zack-truthcoin:	The number of coins destroyed by the attack is far less than how much the attack costs to pull off.
23:05:23	gmaxwell:	'faster' by what metric? Alice has infinite time on her fork, she's effectively a pocket universe onto herself (with her coconspirators). (and it may not just be alice it might be many other people who had let coins expire in the past)
23:06:03	zack-truthcoin:	oh yeah, you are right
23:06:46	zack-truthcoin:	uhh... no wait, the attack costs a proof-of-burn in the beginning
23:07:59	zack-truthcoin:	I can't think of any way to stop her from iterating the attack once she can do it once.
23:33:37	dgenr8:	Luke-Jr: so having the economic majority in place of the consensus majority would be an improvement
23:33:51	dgenr8:	gmaxwell: ...sadly
23:34:19	dgenr8:	what have you done with the real Luke-Jr and gmaxwell??
23:34:51	Luke-Jr:	…
23:35:13	dgenr8:	Bernanke could buy x% of the BTC with ginned up money any time
23:35:33	Luke-Jr:	dgenr8: economic majority is not Bernanke
23:35:35	Apocalyptic:	dgenr8, it's Yellen now
23:36:08	dgenr8:	Apocalyptic: oh ya, thank you
23:38:20	justanotheruser:	I think consensus through an economic majority would be better if could work
23:38:24	Luke-Jr:	dgenr8: we actually took that coversation private since it's off-topic here; if you want to discuss it, I'm glad to, but this is the wrong channel
23:41:15	dgenr8:	IMO an economic majority is a majority the public, who benefits from the system. some guy with a lot of money today can blow it all tomorrow.
23:41:37	dgenr8:	s/a majority//
23:44:10	gmaxwell:	dgenr8: no one said anything about coin ownership meaning anything; I could define a new Bitcoin right now where I own 90% of the coins; I am not suddenly the economic majority. Economic majority involves the control of things like assets and labor that people would want to obtain. But it cannot be strictly defined because it has a fuzzy border around the participating economy. This is an old concept, which was discussed in the ...
23:44:16	gmaxwell:	... bitcoin community years ago on bct and on the bitcoin wiki. As luke says, it's really orthorgonal to this channel.
23:48:22	gmaxwell:	(though, as an aside, the fed very likely cannot buy up the majority of bitcoin at this point, an attempt to do that directly would have a non-trivial risk directly collapsing the USD... at no point has more than a small bitcoins been actively available for sale. At one point to clear out the MTGOX orderbook completely would have required more than a trillion dollars.)
23:49:43	dgenr8:	we agree then
23:50:57	dgenr8:	its just that PoS was being discussed
23:52:40	zack-truthcoin:	In the attack we were discussing: Alice failed to pledge to any fork, and let her coins die. So that at a later date she could pick up from that point in time.
23:53:06	kanzure:	but it was a history rewriting attack
23:53:17	zack-truthcoin:	I expect that less than 1/3 the total coins would get burned on any block like this. so any blockchain produced this way would have less than 1/2 as may coins in it.
23:54:12	zack-truthcoin:	so if we have to choose between forks, we just remember to ignore any forks that have less than 1/2 as many coins as the fork that has the most coins that we know about.
23:55:43	zack-truthcoin:	eventually the blockchain will grow so old, that people will have burned 1/3rd the total supply. At that point, I recommend that the community re-boots the coin with a new genesis block, and has everyone own as much money as they did before.
23:55:59	gmaxwell:	zack-truthcoin: hold up. You said before that when given a choice between two chains, one that has a single original remaining coinholder still in it, and one that does not, they pick the chain with the single original coinholder still in it. Is this untrue?
23:56:42	gmaxwell:	If you keep changing the design its a waste of everyone's time to talk about it. The changed version ends up with weaknesses that the original version did not, and so all discussion needs to be repeated.
23:57:57	mr_burdell:	perhaps once a chain is known where there are no original coin holders, that rule is eliminated
23:58:02	zack-truthcoin:	there are 3 checks we do: 1) if it doesn't have any original coinholders, or people who owned coins on the same blockchain as coinholders, then we ignore it 2)out of the other forks we know about, ignore any forks with less than 1/2 as many coins as the fork with the most coins 3) the longest fork left is the right one.
23:59:40	mr_burdell:	you could have 50% of the original owners collude with the attack though
23:59:47	phantomcircuit:	and this is why i dont bother to criticize until there is a well defined specification