00:11:03	Taek42:	Taek42 is now known as Guest15260
00:11:03	david___:	david___ is now known as Taek42
00:13:45	[\\\\]:	[\\\\] is now known as [\\\]
00:16:17	michagogo_:	michagogo_ is now known as michagogo
00:16:33	licnep_:	licnep_ is now known as licnep
00:18:56	BlueMatt_:	BlueMatt_ is now known as BlueMatt
00:38:45	luke-jr_:	luke-jr_ is now known as Luke-Jr
01:03:02	phantomcircuit:	midnightmagic, im fairly certain i could break namecoin horribly
01:03:11	phantomcircuit:	ie namecoin security is based on nobody giving a shit
08:05:14	weber.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:14	weber.freenode.net:	Users on #bitcoin-wizards: andy-logbot jbenet UukGoblin 20WABIUFV wiretapped Graftec Aquent spinza espes__ cannon p15 GAit OX3_ AaronvanW fanquake jchp_ ebfull pen TheSeven qualiabyte david__ sipa Luke-Jr Guest45243 OneFixt artifexd nsh Emcy_ coryfields michagogo licnep BlueMatt [\\\] zlinn_ Sangheili dgenr8 [d__d] SDCDev midnightmagic mappum super3 jaekwon altoz drawingthesun bsm117532 Iriez [Derek] bobke HaltingState postpre shesek nsh- ericp4 copumpkin melvster
08:05:14	weber.freenode.net:	Users on #bitcoin-wizards: nuke1989 Adohgg mr_burdell zenojis pajarillo koshii bbrittain crescend1 jgarzik SomeoneWeird go1111111 waxwing HM maaku Krellan phantomcircuit sl01 asoltys azariah4 zibbo gmaxwell samson_ Keefe Fistful_of_coins DoctorBTC poggy harrow kmels Hunger- Grishnakh Muis tromp CryptOprah_ digitalmagus7 rs0 warren iddo btc_ Dyaheon roasbeef berndj-blackout andytoshi Meeh mmozeiko Eliel eAndrius CodeShark throughnothing tacotime Guest47516 BigBitz
08:05:14	weber.freenode.net:	Users on #bitcoin-wizards: Transisto K1773R Alanius nickler_ nanotube Logicwax mkarrer Starsoccer tucenaber tromp__ LarsLarsen comboy jaromil pi07r ryan-c kanzure EasyAt gwillen BrainOverfl0w otoburb smooth pigeons Anduck helo Guest50253 weex abc56889 lechuga_ TD-Linux a5m0 catcow amiller dansmith_btc danneu LaptopZZ_ burcin optimator_ jcorgan petertodd wizkid057 nkuttler wumpus lianj Apocalyptic @ChanServ gribble phedny so kinlo
13:06:52	fanquake:	fanquake has left #bitcoin-wizards
13:26:56	jgarzik:	jgarzik is now known as home_jg
13:29:15	Brizo:	Brizo has left #bitcoin-wizards
13:35:36	david__:	david__ is now known as Taek42
16:16:26	jgarzik:	gmaxwell, amiller: hey rock stars,
16:17:27	jgarzik:	A gentleman wrote a technical bitcoin book, and is fishing around for endorsements. I wrote the foreword, and suggested you two as reviewers.
16:17:38	jgarzik:	You might get a ping related to this
16:17:56	jgarzik:	Feel free to ignore or tell him to shove off, if unwanted.
16:19:50	justanotheruser:	justanotheruser has left #bitcoin-wizards
16:24:05	justanotheruser:	Is stake grinding considered a NaS attack? It seems like it should be since it depends on the property that you can generate tons of blocks at no cost.
16:25:39	tacotime:	i don't consider it to be that. i consider it moreso to be like a >50% attack. NaS implies generating consensus on parallel forks with no cost to you.
16:26:29	justanotheruser:	Why does it imply generating in parallel?
16:27:16	tacotime:	well, it's the assumed behaviour of a pow consensus chain if pow was free. you'd get multiple forks because the network could never achieve consensus.
16:27:40	tacotime:	stake grinding isn't technically free, it's just like if you gave yourself a deeply unfair mining advantage in a pow chain.
16:27:56	tacotime:	for instance if you had 10 th/s and the network was only 100 gh/s.
16:28:18	justanotheruser:	Creating alternative chains in general isn't free
16:29:02	tacotime:	well, in some pos systems it is, or at least, cost very very little to the user aside from identifying active chains and elongating them.
16:29:11	justanotheruser:	it's just that getting a bunch of old private keys and generating stake takes constant computational power per block, while stake grinding takes linear
16:29:30	gmaxwell:	tacotime: uh, I don't agree... it's mostly the canonical nothing at stake example... It's not entirely free, but in some sense nothing is.
16:29:56	gmaxwell:	justanotheruser: you probably have to do some degree of stake grinding with your old keys unless you managed to get all of them
16:30:47	justanotheruser:	gmaxwell: Yeah, I'm referring to stake grinding a block at the top of the mainchain
16:31:10	justanotheruser:	but I agree, unless you got a lot of keys, you would probably need to stake grind
16:32:05	tacotime:	gmaxwell: okay. net cost of generating stake blocks/whatever on parallel forks is the same, and the end user loses nothing by elongating multiple parallel forks. the "free" refers to the latter part, is what i mean.
16:32:53	justanotheruser:	I was thinking that if someone wanted to attack NXT, stake grinding would be the best option
16:33:08	justanotheruser:	wait until you win and then win the block 1440 in the future
16:33:38	tacotime:	yeah. but that's more like manipulating the pos algo so that you have some unintended unfair advantage.
16:33:39	justanotheruser:	you have to generate a lot of blocks in the small amount of time you have to forge though
16:34:14	tacotime:	NaS is an inherent problem where elongating all chains has the same cost as elongating one chain.
16:34:25	tacotime:	well.
16:34:31	tacotime:	virtually. :P
16:35:12	tacotime:	you need to be aware of those chains, and use the computational power required to generate those blocks, and i'm making the assumption that it's negligible.
16:36:35	justanotheruser:	it's dependent on the forging power of the network. Right now it seems to be around 250,000,000NXT, so you need to make 1,000,000 block-attempts on average to win (given you have 250NXT)
16:37:52	justanotheruser:	I wonder if a normal desktop can make that many blocks in 2minutes
16:38:17	tacotime:	well
16:38:20	tacotime:	that's just pow
16:38:36	tacotime:	adjusted for stake :P
16:38:57	justanotheruser:	yeah
16:39:29	justanotheruser:	I'm not implying the fact that a regular desktop can't attack makes it safe
16:39:31	jgarzik:	I stand corrected, the author/book is now public: https://twitter.com/pfrancobtc
16:40:14	tacotime:	justanotheruser: that makes it more or less boil down to the general pos function
16:40:26	justanotheruser:	?
16:40:33	tacotime:	SHA256(prevtx + output + timestamp) < (value * 2^256)/D
16:40:52	tacotime:	except you're doing something other than sha256 hashes...
16:41:09	justanotheruser:	what is "it"?
16:41:24	justanotheruser:	[12:40] justanotheruser: that makes it more or less boil down to the general pos functiot
16:41:36	tacotime:	http://vitalik.ca/files/problems.pdf
16:41:40	tacotime:	problem 5 slide
16:41:45	tacotime:	er
16:41:51	tacotime:	sorry the nxt staking algo
16:42:35	tacotime:	that's the generalized form of the simplest pos function, and i'm guessing that nxt is pretty similar if you can stake grind like that.
16:43:00	petertodd:	jgarzik: "A gentleman wrote a technical bitcoin book" <- what's this guys name? I had a similar qury a few months ago
16:43:21	jgarzik:	petertodd, what did I just send to the channel? :)
16:43:27	petertodd:	jgarzik: yup
16:43:29	tacotime:	just replace SHA256 with whatever nxt uses to check if a block is valid
16:43:50	jgarzik:	petertodd, that's the guy that contacted you?
16:43:53	tromp:	even nxt ppl dont know how staking is supposed to work; see https://nxtforum.org/general/forging-questions/
16:44:05	justanotheruser:	its not really the simplest IMO. They added a bunch of stuff to make it so their shills could argue it's safe. "you need to attack in 12 hours or you fail since 720 block reorgs don't work". "you can't stake grind because the winner for the next block isn't determined by the previous, it's determined by the one 1440 behind"
16:44:17	petertodd:	jgarzik: well, a guy contacted me, I'm curious if there's more than one guy writing a technical bitcoin book
16:44:37	tacotime:	justanotheruser: that formula i mean. nxt is horribly convoluted.
16:44:46	jgarzik:	petertodd, I stand corrected, the author/book is now public: https://twitter.com/pfrancobtc
16:45:02	justanotheruser:	I see
16:45:32	petertodd:	jgarzik: ah, I think that's the guy - hopefully amiller/gmaxwell have more time than me :)
16:45:35	justanotheruser:	yeah, tslb*(diff between pub key and prev block sig)*(funds controlled by that pub key) is what I think they have, and that is pretty simple
16:45:40	tacotime:	i still don't totally follow wtf is going on with nxt, but i wouldn't be surprised that as the value increases so does the likelihood of a successful forking attack. :)
16:46:08	petertodd:	tacotime: nxt wants me to do an audit
16:46:13	tacotime:	oh boy
16:46:19	justanotheruser:	:O
16:46:32	tacotime:	well. enjoy the java. :)
16:46:51	petertodd:	tacotime: oh, it's java? that's a nice excuse to scale the scope down...
16:46:53	tromp:	enjoy the lack of technical details in the "whitepaper"
16:47:59	tacotime:	petertodd: hopefully they've cleaned it up a bit from the days when all the error handling was the java equiv of "if catch err { pass }"
16:48:30	justanotheruser:	petertodd: I hope you go for their fundamental flaws rather than their broken java
16:50:22	tacotime:	https://bitbucket.org/JeanLucPicard/nxt/src is the source
16:50:28	tacotime:	doesn't look much at all like the initial releases
16:56:26	Guyver2_:	Guyver2_ is now known as Guyver2
17:18:28	pigeons:	gmaxwell had mentioned that after open-sourcing, NXT was attaacked and the current source is closed again, that that repo won't build the current binaries
17:18:42	pigeons:	pretty sure it was him
17:42:06	gmaxwell:	pigeons: it had gone closed again, but perhaps it's open again. No clue at the moment.
17:42:42	gmaxwell:	the thread with tromp is amusing.
18:47:26	home_jg:	home_jg is now known as jgarzik
19:04:00	Brizo:	Brizo has left #bitcoin-wizards
19:09:57	tacotime:	https://forum.cryptonote.org/viewtopic.php?f=7&t=270
19:10:09	tacotime:	"For instance, the Bitcoin algorithm simply doubles some hash values, “imitating” the missed transaction."
19:10:29	tacotime:	"It is not the best solution possible since doubling the inner hash results in a “ghost hash”. The resulting root hash may be the same even if the hash was not doubled, but created from some child node(s). Thus, different transactions sets might produce the same root hash, which is unacceptable."
19:11:47	sipa:	different sets of transactions can't; but lists (with potential duplicates) can, yes
19:11:51	sipa:	which is very unfortunate
19:12:56	tacotime:	can that fork the bitcoin network?
19:15:35	sipa:	no
19:15:43	sipa:	not anymore, since it was fixed ages ago
19:15:49	tacotime:	ah, okay
19:16:03	sipa:	it just means we need to verify a claimed block doesn't contain duplicate txids
19:36:07	Luke-Jr:	tacotime: see https://en.bitcoin.it/wiki/CVEs#CVE-2012-2459
19:36:26	Luke-Jr:	fixed in 0.6.1
19:37:14	tacotime:	Luke-Jr: ty
19:49:45	Taek42:	gmaxwell, going back to the newcomer/outsider problem on signature based consensus: if we assume that at the moment, the majority of keys are honest, then after conesnsus occurs we can store a hash of the transfer process in a POW blockchain, like the Bitcoin blockchain. If the signers corrupt in the future, any alternate history they create will have to be placed in a later block. You can effectively use your POW blockchain as a timestamp, and
19:49:45	Taek42:	have nodes reject anything that is late by X blocks
19:51:45	Taek42:	of course then you're still effectively using POW as your foundation of consensus.
20:01:09	gmaxwell:	right, you can make PoS do something useful so long as you alredy have an existing consensus.
20:01:15	gmaxwell:	(though this is true for many things!)
20:09:30	Dizzle__:	Dizzle__ is now known as Dizzle
20:24:14	Taek42:	Long post; http://pastebin.com/iZC8FFtP
20:25:44	Dizzle:	Taek42: you thought about using Freenet as a starting point?
20:26:32	jgarzik:	tee hee hee
20:26:41	jgarzik:	* jgarzik gets the nxt boys all riled up on twitter
20:26:44	tacotime:	oh
20:26:49	tacotime:	is this storj?
20:27:31	Taek42:	no not storj, thankfully
20:28:06	Taek42:	I've tried to keep us under the radar while the whitepaper is incomplete
20:28:23	tacotime:	my thoughts are that a blockchain for decentralized storage is not really the way to do
20:28:33	tacotime:	i think that's been rehashed here numerous times though
20:30:01	Taek42:	is the primary problem scale, or are there other issues?
20:30:33	tacotime:	scale mainly, you're duplicating everything on everyone's machine who you want a topology that's much more like a ccn.
20:30:43	midnightmagic:	Taek42: or check out tahoe-lafs too, they've done a ridiculous amount of thinking about the ideas..
20:30:46	tacotime:	s/who/when
20:31:18	super3:	filecoin?
20:31:25	tacotime:	zooko is often around here too
20:31:28	helo:	also, permanent history is frequently unnecessary for file storage
20:32:25	Taek42:	super3 this is Sia
20:32:27	super3:	ah
20:32:28	tacotime:	ccn tokenization is the sort of voodoo black magic proposed by maidsafe, but it hasn't come to fruition yet.
20:32:36	super3:	Taek42: happy to help
20:33:31	Taek42:	what does ccn stand for?
20:33:49	tacotime:	content centric network
20:34:04	tacotime:	https://github.com/maidsafe
20:34:10	tacotime:	i guess it's still in active development.
20:34:32	super3:	Taek42: byzantine problems are not so bad when you use a blockchain, but there are many other ways to do it
20:34:44	Taek42:	maidsafe has always struck me as too horribly complex to be secure.
20:35:56	super3:	the best way to handle it is separate the data protocol from the payment protocol from Sybil/byzantine solver
20:36:07	super3:	if you don't assume there is a singular solution things get easier
20:36:39	Taek42:	The hard part is that you have to have some trustworthy way to figure out what the topology of the network is at a given moment
20:37:15	super3:	Taek42: they have been around since 2006... i like them just still waiting for a product
21:11:37	Taek42:	tacotime: http://pastebin.com/3A9JZ4A4
21:25:12	tacotime:	um. okay. let's see if i have some idea. so you have a masterchain, which points to a merkle tree root of blockheader hashes of slave chains.
21:25:32	tacotime:	and the master chain waits for all the slave chains to make a new block, and then itself starts hashing on a new block.
21:25:41	tacotime:	the the slave chains store all sorts of data.
21:26:31	Taek42:	almost, but it's not forced to be synchronous
21:26:38	tacotime:	um
21:26:42	Taek42:	IE the master can make a block without needing all the slaves to have made a block
21:26:50	tacotime:	how do you achieve temporal stability then?
21:27:40	tacotime:	do you just not include slave chains with missing next blocks in your merkle tree?
21:27:46	bsm117532:	time wimey stuff.
21:28:21	Taek42:	So, if a slave chain doesn't have a block, it's just assumed that it hasn't made that block yet
21:28:31	Taek42:	and that it'll have a block by the next master block
21:28:40	Taek42:	so it's excluded from the merkle tree
21:29:03	tacotime:	so if whoever is making the master blocks doesn't like a particular slave tree or wants to manipulate the difficulty
21:29:05	Taek42:	so one slave can be on block 50 while another's on block 45
21:29:07	tacotime:	it doesn't include them?
21:29:22	Taek42:	does that not make sense?
21:29:25	tacotime:	s/slave tree/slave blockchain
21:29:33	tacotime:	it does but i'm not sure it's a good idea
21:29:40	Taek42:	hmm. why not?
21:29:47	tacotime:	see above
21:30:01	tacotime:	all your slave block chains really are at the whims of the central miner
21:30:15	tacotime:	who would surely manipulate them for his own economic interest
21:30:42	Taek42:	the root chain composed of many nodes, in the same way that the slave chains are
21:30:44	tacotime:	if i'm correct in assuming your slave chains have some kind of cross masterchain tx in them
21:31:34	tacotime:	right, but a miner with <51% can abuse slave chain difficulty without consequence...
21:32:02	tacotime:	i mean, you could make masterchain subsidy based on the number of slave blocks you include i guess
21:32:04	Taek42:	that's where proof-of-storage is more useful
21:32:05	Eliel:	Taek42: What's the benefit from this complexity? Assuming you can make it work.
21:32:17	tacotime:	to incentivize inclusion of slave blockchain blocks
21:32:18	Taek42:	Eliel the benefit is that it scales better.
21:32:43	Taek42:	*the pos is useful because you can't switch storage from chain to chain, you have to keep proving on the storage
21:32:57	Taek42:	and you don't have the luxury of picking which chain you are in, you are placed in a random chain
21:33:12	Taek42:	and there are turbulence effects that prevent you from effectively rerolling
21:35:00	Luke-Jr:	Taek42: sounds like merged mining
21:35:03	tacotime:	"placed in a random chain" how?
21:35:21	tacotime:	if you're incentivizing with tx fees it'll be competitive
21:36:31	tacotime:	i'm not sure how you'd sync all the different tx with data that are coming in so that one and only one chain would get a certain set of them
21:36:56	Taek42:	Incentive structure: you must be doing proof-of-storage to participate in a chain. You must be participating in a chain to be rewarded for your proof of storage. People are paying you to hold onto their files, which is what you are performing proof of storage on.
21:37:46	tacotime:	okay right
21:37:58	tacotime:	so a user has some data that he embeds in a tx, which he sends to the network
21:38:03	Taek42:	Placing into a random chain: As a node, you are responsible for a specific set of files, of an appoximate size (say 1TB total). You have to be proving that specific data or you are kicked. Those specific proofs will only be recognized on one particular chain
21:38:39	tacotime:	and the network gives this tx to one and only one slave blockchain
21:38:40	tacotime:	somehow
21:38:47	Taek42:	yes
21:38:53	tacotime:	how?
21:39:22	tacotime:	are you using schnorr signatures to resolve tx malleability so that the tx hashes are deterministic?
21:40:12	Taek42:	each blockchain is watching a different set of wallets
21:40:25	Taek42:	so if a txn has a source wallet, there's only one blockchain it can correspond with
21:40:29	tacotime:	oh
21:40:50	tacotime:	and to get your coins from main chain to slave chain you have to do some kind of magic
21:40:53	tacotime:	like two way peg
21:41:51	tacotime:	you could even do one way i guess (proof of burn) and recognize it from the parent blockchain i suppose
21:42:23	Eliel:	Taek42: does your system make any use of the fact that for any piece of data that is stored and worth keeping, there exists someone who is motivated to work towards making sure it is stored?
21:42:46	Eliel:	possible even multiple someones
21:43:08	Taek42:	so if you're sending your coins from one chain to another, the transaction is recognized by the root chain as the one chain moving coins to the other, and has some hash that allows you to verify the source and destination wallet
21:43:50	tacotime:	well i guess you could try to motivate every miner to store it for an extended period of time by making them provide a set of merkle proofs for files randomly selected by nonce/block header hash when you generate a new block
21:44:14	tacotime:	to prove you have some subset of the history present
21:44:22	tacotime:	that doesn't mean you need to upload it to anyone else, though
21:44:48	tacotime:	and actually uploading it means that other people will get the data and be able to create blocks, so it's disincentivized
21:45:44	Taek42:	Eliel, every file uploaded to the network has exactly 1 person who is responsible for keeping it, and they are motivated by the reward for performing proof of storage on it. If they disappear and take your file with them, it's gone. But you use erasure coding, and upload 50 pieces of your file, such that you can recover it from any 25 remaining hosts (redundancy 2), you're pretty secure. Pick any M-of-N value you want.
21:46:24	Taek42:	tacotime that's pretty much how it works
21:46:43	tacotime:	Taek42: that presents massive problems then
21:46:56	tacotime:	because hoarding data is heavily incentivized
21:46:58	Eliel:	Taek42: no, you misunderstood what I mean. What I mean is that, if I've uploaded a file to the network, _I_ have a motivation to work towards keeping the file online.
21:47:59	Taek42:	tacotime you mean there's no incentive to share the file once you are able to do proofs with it?
21:48:15	tacotime:	Taek42: correct
21:48:25	Eliel:	whether I do this by paying someone else to do it or do it myself doesn't really matter.
21:48:41	tacotime:	you can keep making blocks for the rest of time by yourself and reaping the reward if you don't
21:48:56	Taek42:	Eliel, oh. The only use we make of that is that you pay to have the file online.
21:49:48	bsm117532:	Dumb question...I was thinking about "proof of storage" the other day, as in, make a storage-hard function as your consensus mechanism.
21:50:02	tacotime:	bsm117532: someone did that recently
21:50:10	Eliel:	It's a recurring payment, I hope? Otherwise the system has no way of purging unnecessary files.
21:50:10	bsm117532:	That is, the function should require random access to the stored data.
21:50:18	tacotime:	it's called "burstcoin"
21:50:22	tacotime:	and i haven't looked into it
21:50:27	Taek42:	tacotime, there's no motivation for you to hoard a piece because nobody else will ever be asked to prove on it anyway. The design of the network is that each file goes in exactly one place, and uploaders NEED to make use of erasure coding. But I think you could also have some system for paying hosts to download a file - pay for the bandwidth costs.
21:51:40	Taek42:	Eliel that's largely discussed here: https://github.com/DavidVorick/Sia/blob/papers/doc/addressing.tex
21:52:25	bsm117532:	One could easily combine burstcoin's idea of "Proof of Capacity" with data that isn't randomly generated -- using user data instead.
21:53:16	Taek42:	you essentially drop a lump sum into a file, and it's stored until the money runs out. Then it's purged from the network. If you want it to be on for longer than that, you just re-upload it. Not terribly clean, but otherwise there are attacks the network is vulnerable to
21:56:26	tacotime:	i'm still a little confused as to how you actually do the exchange from that lump sum though
21:56:52	tacotime:	you'd need to upload the file to someone to do that, i guess you'd need a request tx signed by the pubkey
21:57:40	tacotime:	so the miner sends out the data and then the person who asked for it signs something that lets them shave off a bit of the sum held in that address and give it to the miner
21:57:49	tacotime:	or whoever gave it to them
21:58:04	tacotime:	but how do you prove sending data to someone?
22:00:55	tacotime:	what i mean is, you receive some pile of data after requesting it, but how does the sender prove that it was sent to you?
22:01:45	tacotime:	aside from maybe like a zkSNARK over the entire network topology
22:02:39	Taek42:	prove sending data:
22:02:55	Taek42:	actually I'm going to try and copy-paste this from somewhere else
22:08:40	Taek42:	http://pastebin.com/LJ8ipHaK
22:11:43	tacotime:	define erasure coding
22:13:21	Taek42:	Reed-Solomon Coding
22:13:38	tacotime:	because otherwise it's hard for my to figure out why the moderators would not act in the best interest of the block miners, because their collusion is beneficial to both parties
22:14:27	tacotime:	hmm
22:14:33	Taek42:	hmm. In the event that someone fails to upload a file to the network, the file is just removed
22:14:36	tacotime:	that just seems to be ecc.
22:14:49	Taek42:	which reduces the total amount of demand for the coin
22:14:49	tacotime:	and the coins are destroyed?
22:15:02	tacotime:	well what i mean is
22:15:34	tacotime:	person possessing the data (probably a miner) decides they don't wanna cough up the data, so you call in some moderators.
22:15:44	tacotime:	but the moderators actually end up being paid by the miner.
22:15:53	Taek42:	oh
22:16:02	Taek42:	I was just talking about the upwards direction. hmmm
22:16:04	tacotime:	so they say, oh, yeah, we got this file.
22:16:38	tacotime:	and so the miner is paid for giving the file (which they never did), and they give a portion of that back to the moderators.
22:17:07	Taek42:	yeah I see the issue there. Don't have a solution prepared
22:17:34	Taek42:	but couldn't the uploader do the same thing?
22:17:47	tacotime:	what is his incentive to?
22:17:50	Taek42:	Just somehow negotiate with the mods through some backdoor deal
22:18:14	tacotime:	because wouldn't his file be deleted if they denied it existed?
22:18:20	Taek42:	well if the uploader is uploading a fake file, with the intention that it lands on a host he controls
22:18:52	Taek42:	then he can pretend to store things by computing the fake file, and have a bigger say in consensus than his physical storage would allow
22:19:09	Taek42:	I don't know how to make sure the mods are incentivized to be honest
22:19:26	Taek42:	other than that bad behavior will ultimately devaule the network
22:19:33	tacotime:	it sounds catastrophic in both directions
22:20:05	tacotime:	well yes but then you're left with a network which is most of the time dysfunctional, so there'll be a weird reliability equilibrium heh
22:20:32	tacotime:	and also if you have competitors and they see this as a way to destroy you, they will
22:20:38	tacotime:	no one plays fair in alt chains
22:22:38	tacotime:	you could i guess make m-of-n multisig for the files and only give signatures out for each progressive chunk of the file sent
22:23:03	Taek42:	alt chains are definiately more vulnerable to >51% dishonesty. If 51% of mods are honest in spite of alternate incetives it's fine
22:23:39	Taek42:	but I agree it would be better to have mods that are motivated to be honest because dishonesty is less rewarding in the short and long term
22:24:10	tacotime:	it's not even 51%, they will exploit technical flaws too. pretty much anything to break it. someone forked our chain the other week with a technical flaw.
22:25:02	Taek42:	what coin is that? Technical explots is something we're worried about, we plan on getting a code audit before release
22:25:26	tacotime:	monero
22:26:01	Taek42:	ah nice. I read good things about monero
22:26:25	tacotime:	:)
22:26:52	Taek42:	One thing that's nice about our consensus model is that there's little advantage to pooling
22:27:05	tacotime:	right
22:27:18	Taek42:	as long as it's not broken :P
23:48:47	justanotheruser:	Do you guys think there will ever be a consensus model that doesn't depend on PoW or a blockchain that works just as well if not better?
23:49:09	justanotheruser:	s/consensus/distributed consensus
23:49:24	tacotime:	never say never
23:50:40	justanotheruser:	indeed
23:50:45	justanotheruser:	but my hopes aren't high
23:50:45	lechuga_:	i never wouldve guessed the current model would be realized so i wont wager any further