02:20:03	zooko:	http://eprint.iacr.org/2015/235
02:22:05	nsh:	ty zooko :)
02:22:13	nsh:	is PET on atm?
02:22:26	kanzure:	positron emission tomography?
02:23:21	nsh:	privacy-enhancing technologies sympoconfomeetothings
02:23:55	nsh:	(if you twitter search 'privacy-enhancing' you get a lot of photos of bathrooms)
02:26:00	nsh:	(nope, PETS is next on in July in Philly)
02:26:17	nsh:	or June 30 -- July 2
02:28:19	zooko:	nsh: I just saw that paper from twitter from Frederic Jacobs:
02:30:24	nsh:	* nsh nods
04:28:49	prodatalab__:	prodatalab__ is now known as prodatalab
05:28:36	maaku:	maaku is now known as Guest85609
06:10:19	fanquake:	fanquake has left #bitcoin-wizards
06:32:38	s1w-:	s1w- is now known as s1w
08:05:16	verne.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	verne.freenode.net:	Users on #bitcoin-wizards: andy-logbot damethos prodatalab_ thrasher` cbeams lclc_ Rynomster hktud0 Crowley2k coinheavy go1111111 bedeho s1w dgenr8 RoboTeddy orik Guest85609 coiner PRab p15 Apocalyptic Dr-G molec d1ggy_ zooko hashtag mkarrer xerox iddo copumpkin DoctorBTC Burrito justanotheruser espes__ PaulCapestany arubi bramc x98gvyn crowleyman nuke1989 adam3us1 waxwing hashtag_ MoALTz LeMiner jaekwon_ Emcy_ grandmaster HM adams_ SubCreative Adlai AdrianG devrandom
08:05:16	verne.freenode.net:	Users on #bitcoin-wizards: roasbeef spinza dc17523be3 OneFixt JonTitor jcorgan antgreen` Tiraspol GAit harrow tromp_ Pan0ram1x cluckj Starduster shesek Transisto [d__d] Luke-Jr realcr binaryatrocity kyuupichan NikolaiToryzin luny antgreen ahmed_ huseby face betarigs_admin melvster airbreather Visheate phedny dignork yorick amiller_ petertodd kanzure Iriez michagogo yrashk catcow Muis cfields Zouppen sneak coryfields_ stevenroose alferz gribble Cory LarsLarsen cryptowest_
08:05:17	verne.freenode.net:	Users on #bitcoin-wizards: ajweiss berndj kinlo Logicwax midnightmagic crescendo wizkid057 otoburb wumpus GreenIsMyPepper phantomcircuit BlueMatt jaromil gwillen dasource fenn tromp eordano nickler Alanius BananaLotus guruvan ryan-c lnovy ebfull sdaftuar veorq helo Hunger- xabbix runeks null_radix gmaxwell SwedFTP epscy nanotube andytoshi bliljerk101 starsoccer comboy nsh Taek EasyAt livegnik optimator fluffypony Meeh cursive yoleaux dansmith_btc morcos Fistful_of_Coins
08:05:17	verne.freenode.net:	Users on #bitcoin-wizards: dardasaba isis smooth Xzibit17 artifexd kumavis mariorz Krellan platinuum Oizopower Keefe catlasshrugged eric mappum jbenet wiz heath gnusha warren lechuga_ jessepollak Graet Eliel veox warptangent indolering K1773R TD-Linux leakypat CryptOprah Anduck a5m0 d9b4bef9 mr_burdell NeatBasis davout brand0 @ChanServ throughnothing btc___ azariah MRL-Relay hguux__ so BrainOverfl0w
10:37:06	nickguest:	solo mine spartancoin
10:37:44	nsh:	* nsh looks at nickguest
10:42:26	fluffypony:	nickguest: has spamming that junk ever worked for anyone ever?
10:42:27	fluffypony:	hint: the answer is no.
11:02:02	phantomcircuit:	ffs nobody with ops is awake
11:04:53	phantomcircuit:	sipa, nickguest is trying to spam some silly altcoin
11:06:18	sipa:	sipa has kicked nickguest from #bitcoin-wizards
11:06:41	sipa:	phantomcircuit: i've warned him about it before
11:09:11	phantomcircuit:	sipa, thanks
11:33:07	Muis:	Is there a proven method to distract a pseudo-random number from the chain that cannot be influenced by miners, or is that impossible by design?
11:34:38	stonecoldpat:	what do you mean by distract
11:34:41	sipa:	you can make it arbitrarily expensive
11:34:45	sipa:	he means extract
11:34:48	stonecoldpat:	ah sorry
11:34:56	sipa:	but you can't make it non-influencable
11:37:42	phantomcircuit:	sipa, arbitrarily expensive?
11:39:32	sipa:	by waiting long enough
11:41:37	phantomcircuit:	sipa, oh
11:42:00	phantomcircuit:	sipa, well you can get reasonably small amounts of entropy from the high? low? bits of the blockhash
11:42:04	phantomcircuit:	but that's about it really
11:42:49	phantomcircuit:	it would cost whatever the block reward is multiplied by 2^(fixed bits beyond target) to cheap
11:42:51	phantomcircuit:	cheat*
11:43:05	phantomcircuit:	even a small amount of cheating would be very expensive
11:43:16	stonecoldpat:	argubly that random number (blockhash) is influenced by the miner, if its a random number he doesnt like, then he doesnt publish it (at the cost of 25btc)
11:43:33	stonecoldpat:	^ just as you said...
11:49:40	phantomcircuit:	stonecoldpat, yeah i wouldn't suggest it for sure since there are better sources of entropy
11:50:01	phantomcircuit:	but for an application where you need widely witnessed entropy from the future
11:50:09	phantomcircuit:	well i cant actually think of anything else
11:51:00	Guest89372:	Guest89372 is now known as berndj
11:52:31	Muis:	if you take the hash of all the blocks in the chain
11:52:45	Muis:	does that make the number more random or secure than the hash of the last block
11:53:22	phantomcircuit:	sure but it's predictable
11:53:25	Muis:	since then an attacker would have to start from genesis
11:53:31	phantomcircuit:	or i guess known?
11:53:32	Muis:	how do you mean predictable?
11:53:47	phantomcircuit:	i dont mean you can predict the next one
11:53:56	Muis:	ah okay :)
11:53:59	phantomcircuit:	i mean that if you start now using previous block hashes doesn't help
11:54:04	phantomcircuit:	since everybody already knows those
11:54:29	Muis:	i dont mean the previous block hashes, but hashes over the full block (more work-intensive)
11:54:42	Muis:	but that doesnt change much to the concept
11:55:18	stonecoldpat:	Muis: the blockheader should already be the hash of all the blocks in the chain
11:55:33	Muis:	true
11:55:47	Muis:	but if you are a miner
11:55:55	Muis:	and you want to influence the random miner
11:56:47	Muis:	its harder to find a hash with difficulty X over the contents of all blocks, then to find over a hash, since that doesnt require much I/O
11:57:09	Muis:	*random number
11:59:33	Muis:	so SHA(SHA(B[0] + B[1] + B[2])) instead of SHA(SHA(MERKLE[0] , MERKLE[1])), etc.
12:00:37	stonecoldpat:	intuitively i think both of them are the same thing
12:00:56	Muis:	I guess they aren't
12:00:58	stonecoldpat:	since under all of that - the randomness comes from the signatures which both of them include
12:01:05	Muis:	because when you say: the order of the blocks doesnt matter
12:01:11	Muis:	and you want to try all combinations of orders
12:01:18	Muis:	would you rather hash hashes or hash blockcombinations?
12:01:55	stonecoldpat:	thats what i mean, hash hashes or hash block combinations, both of these are increated from the randomness in the public keys and ecdsa signatures, they are just different represetnations of the same randomness
12:02:09	stonecoldpat:	both of these are created*
12:02:13	Muis:	true
12:02:23	Muis:	but the sheer amount of data is much bigger
12:02:40	Muis:	and the time for a hash is dependant on the amount of data
12:02:55	stonecoldpat:	a hash just makes something look more random, but it may not necessarily be any more random than something that used the same source
12:04:05	Muis:	true
12:04:15	stonecoldpat:	ive got to run, but it is an interesting thought experiment
12:04:17	Muis:	but I mean it requires all miners to have fast access to a copy of the whole chain
12:04:26	Muis:	that is good for SPV nodes :)
12:04:44	Muis:	you cannot make such garantuees by hashing hashes
12:06:03	Muis:	phantomcircuit: suppose my 'coin' uses the bc.info to fetch a random value from bitcoins chain, instead of my own (poor secured) chain
12:06:16	Muis:	which value should I use?
12:06:48	Muis:	the number of transactions in a block? the block hash? something else?
12:07:55	Muis:	I just need the bitcoin protocol to give me a INT32 that I know is expensive too cheat, and will change frequently
12:08:44	Muis:	the total number of bytes from the block maybe?
12:26:52	kanzure:	Muis: fetching data from blockchain.info is a very bad design decision
12:27:31	Muis:	kanzure: if they dont trust it, they can use another explorer, or run a full client
12:28:00	kanzure:	that's not how consensus works
12:28:06	Muis:	i am not creating a financial network, so most people will trust blockchain.info to publish the correct chain, more than they have trust in my network
12:28:42	kanzure:	arguably you are not; you are creating a security vulnerability waiting to happen.
12:30:19	eudoxia:	he does have a bit of a point about trust
12:30:48	eudoxia:	then again there's probably a way you can offer users to verify your chain is the consensun
12:30:51	eudoxia:	consensus*
12:30:59	kanzure:	yes, it's possible that his software does not implement decentralized consensus, but integrating with a third party api like blockchain.info is trivial so i would assume that's not what he's asking about
12:43:46	Muis:	i need to select random miners for my blocks, and it seems more logical to pick them based on a random number in the bitcoin chain, then to let them do massive amounts of pow just so I can select one
12:47:40	justanotheruser:	Muis: what are you doing?
12:48:06	kanzure:	you could pick the same pubkey that mined the latest bitcoin block
12:48:12	kanzure:	in fact, you can implement bitcoin consensus
12:48:26	kanzure:	and directly connect to the bitcoin p2p network
12:48:28	justanotheruser:	PoW is only partially there to randomly select a miner. It is also there so it is prohibatively costly to create a fork.
12:50:50	Muis:	what I want to accomplish is that I can group my nodes in 255 groups
12:51:10	Muis:	they are free to pick a group, but they are not free to switch groups faster than 10 blocks
12:51:27	Muis:	then every block I select a random group that is allowed to mine
12:51:41	Muis:	and all others groups can switch off their equipment during that block
12:51:57	Muis:	since they already know they can never get the block reward
12:52:52	Muis:	now if the numbers I pick are reasonably random
12:53:03	Muis:	then won't my network offer better security as bitcoin with less power?
12:53:43	Muis:	since miners have no incentive to switch groups
12:53:52	Muis:	you could even allow them to already do PoW for their group
12:54:00	kanzure:	your idea seems to be vulnerabile to sybil
12:54:01	Muis:	and that that PoW stays valid for 3 blocks
12:54:05	Muis:	why?
12:54:09	sipa:	sipa has left #bitcoin-wizards
12:54:25	Muis:	if the group-number is included in the hash?
12:54:28	kanzure:	for the same reason all of your other ideas are vulnerable to sybil. we were just talking about this yesterday. read the backlog.
12:54:34	Muis:	how can a an attacker mine for two groups?
12:55:00	Muis:	if he can proof he spend X work for group X
12:55:02	kanzure:	identity just doesn't work. that's what sybil is able to exploit.
12:55:08	Muis:	and cannot do X work for all groups?
12:56:04	justanotheruser:	Muis: https://download.wpsoftware.net/bitcoin/pos.pdf
12:56:27	Muis:	the flaw in proof of stake seems to be that there is nothing at stake
12:56:34	justanotheruser:	basically decentralized consensus works through the burning of an external resource and probably can't be done otherwise
12:56:35	Muis:	so you can easily mine at two chains simultanously
12:56:54	Muis:	that flaw is not present in my idea?
12:57:00	justanotheruser:	yes, but this paper can apply beyond PoS
12:57:06	Muis:	so if there is a second flaw in PoS
12:57:30	Muis:	i am curious to know it. but I will read the paper first
12:57:33	justanotheruser:	Muis: so it's impossible for anyone but the selected miner to mine the block?
12:57:43	Muis:	justanotheruser: no
12:57:56	justanotheruser:	okay, so they can mine a fork and forge the timestamp
12:58:06	kanzure:	i agree with justanotheruser that pos.pdf is about more than just proof-of-stake
12:58:38	Muis:	its impossible for anyone outside the selected group to mine the block
12:58:45	kanzure:	haha
12:59:13	justanotheruser:	Muis: basically how do you prove you're in a group
12:59:34	Muis:	suppose we say a group = a gps coordinate, and you publish yours, and the difficulty is the distance between your coordinates and the target. then everyone can mine a block, but some are more lucky than others, because their location is closer to the target
12:59:47	kanzure:	gps is spoofable
12:59:54	Muis:	you proof you are in a group by comitting to a group
13:00:01	kanzure:	no
13:00:10	Muis:	so I hash my own gps coordinates for 2 years long
13:00:13	kanzure:	please read more about sybil attacks
13:00:18	Muis:	and I collect proof of work for that location
13:00:42	Muis:	if I want to collect pow for other coordinates
13:00:49	Muis:	how would that work? I would have to split the work
13:00:52	justanotheruser:	Muis: okay, so ignoring the fact that GPS is spoofable, I rent 255 servers for $2/month and they all talk to my full node multiplying my profits by 255
13:01:06	Muis:	that doesnt work
13:01:25	Muis:	i mean it does work
13:01:29	justanotheruser:	lol
13:01:37	Muis:	but you are at a disadvantage to the people that are really in that group
13:02:17	Muis:	because you do POW together with a partner, you hash eachother responses
13:02:32	Muis:	and you will always be the slowest one because of your proxy
13:02:36	kanzure:	trivial to just join a billion groups. there's no such thing as identity so you can run as many fake nodes in fake groups as you want.
13:02:36	justanotheruser:	yeah, my partner is another program running on my server
13:04:00	fanquake:	fanquake has left #bitcoin-wizards
13:04:18	Muis:	you commit PoW to a group, so you cannot join a thousands groups, and be the biggest every where. and you can do pow together with somebody else in that group. Suppose I have 10000 sybils, if I want to join group X, i need a 10000 real people that want to partner with me, otherwise I have to do twice the work for half the reward
13:04:47	Muis:	so unless thats a very popular group, every miner most likely already has a partner there
13:04:54	prodatalab_:	prodatalab_ is now known as prodatalab
13:04:56	kanzure:	not half the reward
13:06:45	justanotheruser:	you keep redefining this system
13:07:34	justanotheruser:	and requiring a group creates a huge economy of scale.
13:07:46	Muis:	economy of scale?
13:08:08	justanotheruser:	it becomes more profitable the more money you spend
13:08:55	Muis:	suppose we label the group by GPS coordinates, you can make them more precise? So first you mine for your continent, later you mine for your country or city, and when its mainstream you mine for your street.
13:09:15	justanotheruser:	ehh, read up on sybil attacks, this isn't workable
13:09:19	Muis:	wouldnt that spread out nicely across the globe, instead of 3 large datacenters
13:09:42	justanotheruser:	there is no trustless proof-of-coordinate
13:09:44	kanzure:	Muis: http://en.wikipedia.org/wiki/Sybil_attack
13:09:59	Muis:	I prevent the sybil attack by including the group-name in the pow hash?
13:10:16	Muis:	and I cannot think of a way an attacker could get around that
13:10:28	justanotheruser:	by writing a different group name
13:10:30	Muis:	because the amount of work you did for group X prooves your weight in that group
13:10:51	Muis:	how can you write a different group name?
13:11:09	justanotheruser:	Muis: okay, so alice is mining in one group right?
13:11:13	Muis:	yes
13:11:14	justanotheruser:	and bob is mining in another group right?
13:11:17	Muis:	yes
13:11:32	justanotheruser:	and alice can't be in bobs group at the same time?
13:11:36	justanotheruser:	right?
13:11:44	Muis:	alice can be in bobs group
13:11:52	justanotheruser:	but, since they're in another group they can't be
13:11:54	Muis:	but she must split her hash-power equalyy between the groups
13:12:05	Muis:	ok
13:12:30	justanotheruser:	well if you are using maximal hashpower your system doesn't accomplish it's original goal of reducing elecricity expended
13:13:11	justanotheruser:	but sure, you can put "Hey guys, I'm in group 193" in the coinbase if you like, not that it would do anything
13:17:14	Muis:	If a group decides to mine even though their group-number is so far away from the target, that they most likely always will be beaten, that's their choice, and in that case electricity is not reduced. but for the rational miners it is
13:18:19	Muis:	so if only 50% of them act rational and financially motivated, then 50% energy is saved
13:19:16	kanzure:	group membership doesn't work like that
13:19:31	Muis:	why not
13:19:39	kanzure:	do you know what i am going to say?
13:19:44	Muis:	screw you
13:19:50	Muis:	:)
13:19:52	kanzure:	i am just asking
13:19:54	Muis:	no what did you plan to say?
13:19:57	Muis:	no
13:20:02	kanzure:	http://en.wikipedia.org/wiki/Sybil_attack
13:20:06	Muis:	lol
13:20:29	Muis:	I am willing to read all I can, but I still haven't heard a practical example of how someone can cheat in my scheme
13:20:37	Muis:	and I thought justanotheruser was about to explain one
13:22:43	Muis:	you pay 'rent' for a group, if you want to join multiple, no problem, but you pay much more in rent for many groups were you contribute small hashpower, than renting one group and focussing all your power there
13:23:06	justanotheruser:	Muis: your system has only been defined to the extent that you can throw on another component and fix the problem I just explained, only to create another problem.
13:24:42	justanotheruser:	Pastebin a definition for the system that is thorough enough so you can't say "oh, this additional component will fix that" in response to me pointing out a flaw.
13:25:09	Muis:	:)
13:26:22	kanzure:	Muis: i think the more interesting thing you should be trying to learn is why bitcoin seems to be sybil-resistnat.
13:26:27	kanzure:	whoops i mean sybil-resistant
13:26:40	kanzure:	rather than trying to come up with your own sybil-resistant implementation (which so far you have not been able to do....)
13:28:26	Muis:	isnt it sybil resistance because you proof you dedicated effort into something that isnt fungible?
13:29:03	kanzure:	nope, bitcoin is sybil-resistant because who you are doesn't matter
13:30:15	Adlai:	bitcoin's PoW is equally difficult if you make your one huge mining farm look like $maxint small miners
13:30:15	Muis:	its not 1 cpu = 1 vote anymore, so who you are is defined by the amount of hash-rate that you have
13:30:33	Adlai:	there's no "who you are", only "what you can do with the hardware you control and the energy you feed it"
13:30:34	kanzure:	"1 cpu = 1 vote" was the wrong idea
13:30:50	Muis:	why
13:31:09	kanzure:	because it's nonsense. votes don't even make sense. there's no way to "register" a single cpu. it's all kinds of dumb.
13:31:13	justanotheruser:	oh here comes the vote discussion
13:31:36	kanzure:	"1 cpu 1 vote" is not sybil-resistant
13:31:49	Muis:	lol
13:31:49	Adlai:	it's closer to "1 hash/second = 1 lottery ticket"
13:31:53	Muis:	its in the Satoshi paper
13:32:17	justanotheruser:	the important thing is it still is 1 cpu 1 vote in the sense that now a 1000000 CPUs can fit into a single piece of hardware
13:32:18	Muis:	but it was the wrong idea and not sybil-resistant?
13:32:22	Muis:	does Satoshi know that?
13:32:38	kanzure:	there are many things that satoshi didn't know
13:32:40	kanzure:	like how to write a standard
13:32:42	justanotheruser:	Muis: he just disagrees with using the word "vote" to describe it
13:32:55	kanzure:	justanotheruser: i also disagree with the "1 cpu" thing too.
13:33:14	Muis:	im trying to find a way to bring back the idea of 1 person = 1 vote, and there may be solutions to accomplish that, and it could that it turns out that CPU was a bad measurement
13:33:30	kanzure:	Muis: there was never an idea of "1 person = 1 vote". sorry.
13:33:54	Muis:	1 person = 1 cpu = 1 vote
13:33:59	kanzure:	Muis: there is no way for a computer to "know" "your identity"... that's not a computable concept.
13:34:02	justanotheruser:	1 hash one lotto ticket!
13:34:21	Muis:	lets stick to the lotto ticket analogy
13:34:26	Muis:	suppose I can buy a lotto ticket
13:34:41	kanzure:	you can't...
13:34:45	Muis:	and with every ticket sold I decrease the total jackpot, and my own expected value
13:34:54	Muis:	would I buy two tickets? or 1000 as a Sybil?
13:35:23	Muis:	it would be in my best interest to act rational and buy one
13:35:39	Muis:	and hope that other people act rational too
13:35:46	Muis:	but Im assured that even if they do not
13:35:50	Muis:	they will make a loss
13:36:25	Muis:	so on average, they will
13:39:18	p15x:	do you know about the prisoner's dilemma
13:58:32	Muis:	yes
13:58:54	Muis:	its kinda similar
14:06:29	stonecoldpat:	I would agree with Aldai in the defintion that its more a lottery ticket than a vote
14:06:49	stonecoldpat:	its not the most votes who win, its just who gets the winning lotto ticket
14:08:16	smooth:	kanzure: who you are does matter in a way, because 51 people with 1% of hash power each is not the same as one person with 51% hash power
14:08:36	kanzure:	smooth: what do you mean?
14:08:45	smooth:	the incentives are different
14:09:36	smooth:	the assumption of the poorly named 1-cpu-1-vote is that all votes are "small"
14:16:37	justanotheruser:	smooth: all votes are about the same size because rational actors will use up to date ASICs
14:16:58	justanotheruser:	1 cpu 1 vote doesn't really imply a person can't have 10000 CPUs
14:17:09	smooth:	yes thats why i said its poorly named
14:17:20	justanotheruser:	oh, I see
14:17:34	smooth:	although i would argue it DID imply that
14:18:11	smooth:	well maybe 10k cpus fine, but not say 100m or more
14:20:50	Muis:	would there buy a problem if PoW is not coupled to a block
14:21:06	Muis:	that you can save it, as long as it can only be used once?
14:25:00	Muis:	my feeling says its insecure, but I cant really figure out why
14:26:50	Muis:	so for example, the only requirement for bitcoin miners is that they provide a hash for the string "BITCOIN" + random, which meets the difficulty, but the hash does not include the timestamp nor the blocknumber.
14:27:19	Muis:	and once you use one your hashes to create a block, you cannot use that same hash again for another block
14:28:43	Muis:	but you may store them or sell them as long as they dont get published
14:28:48	stonecoldpat:	if i understand what your saying... that means that hash could be used for *any* block, you produce the hash, i steal it and use it with my block - theres no criteria to stop it being used more than once
14:29:23	stonecoldpat:	the PoW is used to protect the integrity of the block - to make sure its contents cannot be changed without changing the PoW
14:29:25	Muis:	but if the hash is recorded in the chain, you could just lookup if its already used?
14:30:12	Muis:	if I produce it you can steal it, but we cannot both use it on the same chain
14:31:17	stonecoldpat:	the reason it cant be stolen today is because it is coupled with a block - otherwise its up to anyones discretion to choose which chain they follow - as using *any* pow with a block would allow infinite possible chains
14:32:06	Muis:	okay, thats true
14:32:24	Muis:	so if you couple a time, but not a block, does that make things different?
14:33:01	stonecoldpat:	well, the PoW acts as a relative timestamp - thats why it solves the decentralization problem
14:33:39	justanotheruser:	Muis: progress in PoW is bad. If you want more reading, pow.pdf is easier to understand and a nice read.
14:33:41	Muis:	relative to the blockheader it hashes
14:33:58	Muis:	justanotheruser: i will, tnx
14:41:33	andytoshi:	Muis: can you make precise this "more tickets you buy the smaller the jackpot gets" notion? specifically what is the likelihood of winning (i guess (#tickets bought)/(#total tickets)) and how does your jackpot function work ... i wonder if it's possible to set one up such that for each player the maximum expected payoff is achieved for 1 ticket (not zero) or at least for some small finite number of
14:41:36	andytoshi:	tickets
14:42:48	Muis:	It works exponential
14:42:52	andytoshi:	i think that's a well-defined mathematical problem, i think in solving it you'll convince yourself it's impossible (but maybe not, which would interest me too), and should provide some intuition about game theory ... then we can worry about things like "how to determine the number of tickets bought"
14:43:01	Muis:	So it decreases really quickly
14:43:10	Muis:	But starts very large
14:43:30	justanotheruser:	is the sybil problem even what a PoW solves? If sybil is solved, you need an incentive to keep all the actors in line.
14:43:37	andytoshi:	what i'm asking for is a mathematical proof that expected utility for each player is maximized if the player buys some small nonzero number N of tickets
14:44:38	Muis:	I am trying to accomplish that by making the entry fee for the lottery higher than the expected payout
14:44:56	Muis:	But because transaction fees also happen to be entry fees
14:45:08	andytoshi:	do whatever you want; i'm telling you that you can mathematically prove whether or not it accomplishes your goal (which i have stated precisely for you)
14:45:13	Muis:	People dont mind if they loose if they needed to make one anyway
14:45:59	Muis:	But if you buy tickets (make transactions) just for the jackpot
14:46:07	andytoshi:	and i'd like you to do this because these sorts of handwavey arguments don't accomplish anything; i suspect all parties are talking past each other because english is ambiguous and super bad at detecting miscommunication.
14:46:10	Muis:	You have a negative expected value
14:46:28	andytoshi:	no. write out the equations.
14:46:38	Muis:	I will try to make some document which proofs this
14:49:48	Muis:	But it can all be boiled down to this: in a regular lottery you buy tickets. here you get a ticket for free with each transaction, but they earn less on average than the tx fee costs.
14:53:10	Muis:	Would you join that lottery unless you really had to make a transaction? If your answer is no andytoshi, then it must be proovable
14:55:49	kanzure:	andytoshi: i think this guy is just bad at reading
14:55:55	andytoshi:	Muis: it's easy to make the EV negative regardless of the number of tickets i buy, have your payout function be 0. i thought you wanted to encourage participation but not sybilling, so you want my optimum number of tickets to be positive but not infinite
14:55:57	kanzure:	andytoshi: i don't have any other explanations to give you
14:56:41	smooth:	Muis: do this: < andytoshi> no. write out the equations.
14:56:57	smooth:	you are risking unnecesarily alienating people at this point
14:57:40	Muis:	andytoshi: I encourage particpation by giving away free tickets to the people paying TX fees?
14:57:47	andytoshi:	kanzure: :/ Muis: i'd like you to explore the math probelm i gave you above (devise a jackpot function which does what you want), i can't respond anymore to you until you do it because it's using a lot of -wizards scrollback, as well as the time of myself and other readers; i'm saying this because it's true, not to be mean
14:59:18	stonecoldpat:	+1 andytoshi point, unless you write a clear description then its hard to debate (as seen earlier by 'adding-on' new components)
14:59:20	Muis:	Okay, np
15:05:00	Muis:	Every TX is a ticket, every ticket earns back its total transaction-fee but only every 3 blocks on average. That is a good lottery if I need to make TX for other reasons, and a bad lottery if I try to use it to sybil attack or to make profits or spam. Thats a clear and well defined scheme.
15:48:17	andytoshi:	Muis: why do you say "every 3 blocks on average" instead of just "consistently 1/3 its fee" ... introducing randomness seems like totally unnecessary complexity. then why 1/3 rather than 0? i don't see how that changes the incentives. finally: if your transactions receive no payout (which i think is incentive-equivalent to what you described) what do you think you have accomplished? "here's my
15:48:20	andytoshi:	system: there are transactions"?
15:48:57	amiller_:	andytoshi, i think what he's saying is very simple, i don't see what you're sending him to the chalkboard for
15:49:00	amiller_:	he's just saying there's a -EV lottery
15:49:12	amiller_:	that's easy, you just delete some fraction of the transaction fees
15:50:16	amiller_:	and i think the point that he's making is one that i like to make, which is that people play -EV lotteries all the time, that's why charity fundraising drives often have 'raffles'
15:50:24	andytoshi:	amiller_: earlier he was suggesting a +EV lottery except it's -EV if you buy more than one ticket (to discourage sybilling). somehow he is trying to assemble a consensus system from all this, i'm just giving him subproblems so he can see what a concrete piece of something looks like
15:50:25	zooko`:	zooko` is now known as zooko
16:17:52	Muis:	andytoshi: always 1/3 is not the same as once every 3 blocks. Because when I have to make a single TX, one in 3 times i will make a profit and double my fee. And the other two times I loose nothing. With your scheme i can predict my return, which is not wanted
16:19:37	Muis:	Its true that over a long period it will have the same returns
16:20:54	gmaxwell:	gmaxwell has left #bitcoin-wizards
16:33:24	StephenM_:	StephenM_ is now known as StephenM347
16:40:17	kanzure:	"I am your enemy, the first one you've ever had who was smarter than you. There is no teacher but the enemy. No one but the enemy will tell you what the enemy is going to do. No one but the enemy will ever teach you how to destroy and conquer. Only the enemy shows you where you are weak. Only the enemy tells you where he is strong. And the rules of the game are what you can do to him and what you can stop him from doing to you. I am ...
16:40:23	kanzure:	... your enemy from now on."
16:42:57	amiller_:	andytoshi, agreed. Muis I don't want to discourage you because i think there's something useful in there, trying to design more carefully the incentive reward / lottery scheme to achieve some kind of effect on the participation distribution.
16:43:13	amiller_:	but it's really hard to analyze all this even just by thinking through it
16:43:34	amiller_:	try to find any way you can to break off a chunk of this as a subproblem and just discuss that maybe
16:44:19	amiller_:	i think do think that a -EV lottery is self-stabilizing and resistant to sybils
16:44:57	amiller_:	the economic assumptions that could justify this are a) individuals play lotteries, but only a limited amount over time, e.g. people that spend $10/week on lottery tickets or a few hours at a casino a year
16:45:29	amiller_:	and b) as a trend, "large entities" tend to be closer to expected utility theory and less likely to gamble compared to small individuals
16:46:04	amiller_:	the first one (a) is needed to justify having a -EV incentive scheme in the first place, and the second one (b) is why a -EV is inherently sybil resistant
16:47:14	amiller_:	anyway, this is a "subproblem" because i'm just talking for now about participation levels (who spends resources to participate and how much), and it doesn't say anything about "mining" or consensus reallly
16:48:08	amiller_:	forget about consensus and blocks and tx fees for now, if the incentive stuff ends up appealing, we could probably build a mining game around it, but its the incentive stuff that's weird / interesting to start with.
16:49:25	kanzure:	there may be valuable immunity in a direction like "fraud proofs and once showing a fraud proof being able to replace a large participant with any number of smaller participants without losing out on hashrate or being vulnerable to hashrate attacks from the larger participant that might decide to switch to your separate blockchain to mess with your retargeting".
16:50:05	kanzure:	(that sort of immunity makes larger participants less problematic)
16:50:49	kanzure:	((i was not proposing a mechanism))
17:21:16	kanzure:	"Password recovery attacks against RC4 in TLS" http://www.isg.rhul.ac.uk/tls/RC4passwords.pdf
17:52:31	Guest85609:	Guest85609 is now known as maaku
18:08:52	huffer:	Yeah, hello :) I was watching a talk of DevCore, and Gavin mentioned this chat room so I wanted to check if it exists :)
18:09:46	Adlai:	indeed it does, although discussion is slow sometimes (and rapidfire at others)
18:09:50	huffer:	so it does exist, though it’s awfully quiet in here
18:09:51	huffer:	:)
18:10:10	huffer:	well, many thanks Adlai
18:10:10	Adlai:	all but the busiest irc rooms have dead time
18:11:07	huffer:	I don’t have a topic of discussion for now so I won’t bore you or distract you guys anymore - but thanks for future conversations
18:12:25	phiche1:	@huffer that's how I found this channel too. It was busy earlier today. Don't worry there is probably plenty of stuff in here to look forward to that will go right over your head (like mine)
18:13:12	Adlai:	if you're looking for immediate gratification, see /topic
18:13:15	huffer:	cool, phiche1, looking forward…
18:13:46	phiche1:	thanks for the tip Adlai!
18:55:01	huffer:	huffer has left #bitcoin-wizards
20:30:19	waxwing__:	waxwing__ is now known as waxwing
20:51:26	belcher_:	belcher_ is now known as belcher
20:59:37	brand0:	brand0 is now known as gwerwi
21:01:31	gwerwi:	gwerwi is now known as brand0
21:02:11	BlueMatt:	does anyone have any opinions on relative-to-my-inputs-OP_CLTV?
21:02:44	BlueMatt:	ie RCLTV is equivalent to CLTV?
21:02:50	BlueMatt:	maybe petertodd?
21:04:14	BlueMatt:	its useful in some contracts that take the form OP_IF everyone_signs OP_ELSE something_is_published_in_this_output (maybe just the fact that this output exists)
21:06:07	BlueMatt:	ehhh, I'll move to -dev, its not very wizard-y
22:56:29	kanzure:	factom stuff http://sourceforge.net/p/bitcoin/mailman/message/33603951/
22:57:23	moa1:	"The largest verified computation (SETI@home) uses verification by replication." https://en.wikipedia.org/wiki/Verifiable_computing
22:57:53	moa1:	you could argue bitcoin is a larger set of verified computations?
22:58:52	phantomcircuit:	moa1, bitcoin is actually a fairly small amount of verified computation
22:59:05	phantomcircuit:	it is however far more secure than seti@home's replication model
22:59:09	moa1:	done by > 6000 nodes though
22:59:13	kanzure:	what's the right measurement for the "size" of a verification? number of bits ?
22:59:18	phantomcircuit:	(they dont worry too much about people faking work)
23:00:00	maaku:	moa1: the amount of computation actually verified by bitcoin is small
23:00:14	moa1:	maaku: heh yes but ...
23:03:57	moa1:	6500 nodes verifying a small problem uses more computation resources than 2 nodes verifying a large problem
23:13:38	phantomcircuit:	moa1, you're massively under estimating the volume of work that goes through seti@home...
23:19:29	phantomcircuit:	petertodd, is it even possible to prove that you published something and that it's the only version without having censorship issues?
23:23:19	zz_lnovy:	zz_lnovy is now known as lnovy
23:25:04	lnr:	lnr has left #bitcoin-wizards
23:28:38	amiller_:	phantomcircuit, sure it is, petertodd convinced me by telling me how
23:28:49	phantomcircuit:	amiller_, ha
23:29:42	phantomcircuit:	amiller_, but how
23:30:06	phantomcircuit:	his scheme with the encryption of the key?
23:30:28	amiller_:	give me a sec, its simpler, trying to reconstruct it from memory now
23:33:10	amiller_:	okay got it in head-ram, gonna try explaining this, ive been trying to figure out how to unravel the idea, its really clever but a bit tricky to explain.
23:33:23	amiller_:	i'll try this way.... here's how you set it up.
23:34:29	amiller_:	start by putting on the blockchain an ordinary transaction with a single output you can spend
23:35:00	amiller_:	there's nothing apparently special about this transaction, it looks just like all the others and isn't "linked" to you
23:36:19	amiller_:	now, publish a transaction containing a description of your gadget (how the description is constructed i'll describe later),
23:36:37	amiller_:	the idea is this description is the name of a "write once, but *later*"
23:37:15	amiller_:	you will *later* want to choose that message, and prove to someone that you set it to one particular value and can't equivocate by convincing two different people you set it two different ways
23:37:42	amiller_:	okay i'm a little bogged down already by trying to describe the *goal* but since you brought it up, i think you get it, so ill switch to how it works.
23:38:07	amiller_:	this "description" is actually a commitment (a hash plus some randomness) of the nondescript transaction output we prepared earlier.
23:39:05	amiller_:	ah okay here's where the encryptoin comes in, the commitment is to a) that transaction output, and to b) a symmetric encryption key
23:39:18	amiller_:	okay so
23:40:29	amiller_:	you "write once" to that value by *spending* that output, and including an encryption of your message, under the symmetric key i mentioned, in some steganogrphic bits, like the transaction output pubkey hashes
23:41:27	amiller_:	this is the crux of the idea, you have already *committed* to the transaction output you are going to spend, but you haven't revealed any information about what it is yet
23:41:49	phantomcircuit:	amiller_, yeah i think that's what i was thinking of before
23:41:49	amiller_:	so you can actually do the spending of it and embed your message covertly.
23:41:54	amiller_:	okay
23:42:38	amiller_:	sorry, if i had remembered it required encryption i would have assumed you knew it when you mentioned that. oh well, i guess i got the practice explaining it i wanted. i think its a really great idea it took me a while to understand
23:42:51	phantomcircuit:	that's not actually censorship proof but it is resistant
23:44:05	phantomcircuit:	since a miner/relay node that understands the protocol can clearly block the last step
23:44:26	amiller_:	no
23:44:33	amiller_:	which last step
23:44:39	amiller_:	its censorship-proof
23:44:53	phantomcircuit:	two transactions A and B
23:45:06	amiller_:	the miner can't tell which transactions are involved
23:45:19	amiller_:	this technique involves hiding data in perfectly ordinary transactions, there's really no way to tell
23:45:23	amiller_:	the output can be any output you can spend
23:45:30	phantomcircuit:	sure they can, the set of possible candidates is small enough to brute force
23:45:37	amiller_:	wat no its not
23:45:49	amiller_:	oh, i think you misunderstood when i said "commitment"
23:45:53	amiller_:	not just the hash, but a hash plus some randomness
23:46:28	amiller_:	you can't just try all the transactions and see which one the hash matches, until i reveal the randomness (which i can do privately to anyone i want to give my unequivocable message to)
23:46:44	amiller_:	oh, actually encryption isn't required at all.
23:46:59	phantomcircuit:	amiller_, so the randomness is basically a key
23:47:19	phantomcircuit:	and i can publish multiple versions of the same thing only not using the same transaction output
23:47:39	amiller_:	yes
23:48:23	phantomcircuit:	i feel like there's an issue with that but i cant quite put my finger on it
23:48:34	amiller_:	there's not, i checked lol
23:49:28	phantomcircuit:	it clearly basically solves asset tracking issues but only if the transaction output is tied to the asset
23:49:53	phantomcircuit:	oh wait
23:50:41	phantomcircuit:	i was going to say there's nothing stopping you from committing to the txo twice with different random values butt hen i realized derp
23:51:11	amiller_:	its less obvious to me how it clearly solves asset tracking, im still trying to figure that part out actually.
23:51:51	phantomcircuit:	amiller_, i dont see how you could both track an asset using transaction outputs and keep the first transactions output censorship proof
23:52:30	amiller_:	well you have to start somewhere
23:52:40	phantomcircuit:	amiller_, that ones easy, you generate the next spend transaction in advance and commit to it with the message you're making censorship resistant
23:52:50	amiller_:	okay then you're done, what else is there exactly
23:52:50	phantomcircuit:	whoever controls that output controls the asset
23:53:33	phantomcircuit:	im not sure you can actually make that work without revealing to the world that the next transaction output is going to be though
23:53:44	phantomcircuit:	no you can
23:53:50	phantomcircuit:	neat
23:54:25	phantomcircuit:	well sort of
23:54:40	phantomcircuit:	anybody who has ever known which outputs the asset corresponds to can censor transactions
23:54:46	amiller_:	no
23:55:02	amiller_:	you can like, lazy load a chain of these things
23:55:03	phantomcircuit:	in that example they can because they would be able to identify the "next" output
23:55:36	amiller_:	use output #1 for your message, and #2 for the commitment to the next hidden-in-plain-sight transaction
23:55:58	phantomcircuit:	amiller_, that makes the protocol interactive and involves everybody whose ever owned the asset....
23:55:59	amiller_:	as long as you can keep putting nondescript transactions in the chain, you can link these together
23:56:31	amiller_:	of course it's interactive but not prohibitively so? one transaction per... transaction
23:56:34	phantomcircuit:	the random values need to be published at each step to prevent the thing from being a huge nuisance
23:57:03	phantomcircuit:	oh and this would be horribly broken by even a small reorg
23:57:04	phantomcircuit:	heh
23:57:14	amiller_:	no it wouldn't
23:57:22	amiller_:	you wait for longer than a small reorg before revealing your randomness
23:57:26	phantomcircuit:	sure it would since you have to reveal the random value
23:57:29	amiller_:	this is a lot like guy fawkes signatures
23:57:31	phantomcircuit:	a reorg would make it censorable
23:58:08	phantomcircuit:	i guess you could commit to two outputs one for the message and one for the random value
23:58:25	phantomcircuit:	and then delay the random value disclosure for long enough that a reorg wouldn't break the system
23:58:56	phantomcircuit:	it's certainly not a general solution to the problem i described though :P
23:58:59	amiller_:	no you commit to one output, but you "use" that output in a transaction with two outputs
23:59:02	phantomcircuit:	there's a bunch of edge cases
23:59:48	amiller_:	i think all of your criticisms have been due to the proposed solution being hard to visualize