| 01:35:13 | justanotheruser: | justanotheruser is now known as justabadspeller |
| 03:10:12 | justabadspeller: | justabadspeller is now known as justanotheruser |
| 03:56:57 | jcluck: | jcluck is now known as cluckj |
| 05:27:21 | gigavps: | gigavps is now known as Guest81110 |
| 06:30:13 | wallet421: | wallet421 is now known as wallet42 |
| 06:39:05 | stqism: | stqism is now known as NikolaiToryzin |
| 06:40:22 | Pasha: | Pasha is now known as Cory |
| 07:35:58 | fanquake: | fanquake has left #bitcoin-wizards |
| 11:28:35 | gigapvs: | gigapvs has left #bitcoin-wizards |
| 12:51:00 | gavinandresen_: | gavinandresen_ is now known as gavinandresen |
| 13:19:27 | jbenet: | http://filecoin.io |
| 13:33:10 | jcluck: | jcluck is now known as cluckj |
| 13:36:29 | iddo_: | is this an implementation of permacoin ? |
| 13:36:35 | iddo_: | iddo_ is now known as iddo |
| 13:40:01 | iddo: | amiller: ^ |
| 13:43:13 | jbenet: | iddo_ it isn't, though Filecoin (as presented in this paper) and Permacoin are highly compatible. future versions could build on permacoin's PoW. |
| 13:43:45 | gmaxwell: | iddo: It doesn't appear to make any use of a locally testable code. It doesn't appear to have an answer to the CSPRNG attack. |
| 13:43:55 | iddo: | jbenet: you're behind this? why don't you cite permacoin in your whitepaper? |
| 13:44:27 | iddo: | gmaxwell: what's the CSPRNG attack? |
| 13:46:00 | gmaxwell: | iddo: I ask the network to store, say, blocks of AES(counter,s) with s known only to me. If I do a lot of this I can mine with no storage, but other participants are required to have storage. If storage is most of the cost, and I can pile mining income back into paying for more storage… |
| 13:47:11 | iddo: | ahh |
| 13:47:11 | gmaxwell: | (my comments not withstanding, I'm certantly happy to see people doing more novel things) |
| 13:47:57 | iddo: | i haven't read permacoin paper yet, does it suffer from same PRNG attack? |
| 13:48:16 | jbenet: | gmaxwell that's not a problem when you must pay more to add blocks than expected reward |
| 13:48:59 | gmaxwell: | amiller had a sort of handwave argument that the linear code used in permacoin made the CSPRNG attack less bad, but thats not clear to me... the CSPRNG still removes a degree of freedom wherever a block is used, it might even make it worse in that a given probe is more likely to depend on CSPRNG data. |
| 13:48:59 | iddo: | jbenet: why would miners mine at a loss? |
| 13:49:45 | jbenet: | here blocks means data blocks. or pieces. |
| 13:50:01 | gmaxwell: | jbenet: perhaps! but if the gap is small a byzantine attacker (really byzantine may also mean 'rational' from outside your threat model) might still set the world on fire. |
| 13:50:22 | gmaxwell: | I don't mean to say the CSPRNG attack breaks these systems but it does undermine the assumptions. If its fixable it would be good to fix it. |
| 13:51:09 | gmaxwell: | e.g. if the 'coins' in it become valuable independant of the storage a trader may seek to corner the market on new coin production. |
| 13:51:21 | jbenet: | gmaxwell it's within the threat model-- and the gap shoudn't be small. it should be quite large. |
| 13:53:36 | iddo: | BTW there's also new paper on energy-efficient proof-of-space cryptocurrency (no PoW i.e. rational to use storage instead of PoW), it's quite impressive research i think, but the paper isn't public yet |
| 13:55:56 | iddo: | jbenet: why is the whitepaper anonymous? |
| 13:56:00 | gmaxwell: | jbenet: it's not clear to me that the threat model considers people storing junk thats cheap for them to produce at a loss in order to corner the market on new coins. ... seems to me like the kind of threat that can't really be addressed. |
| 13:57:03 | jbenet: | and iddo, to answer your question, I intend to cite permacoin in the future :) -- had this construction before i learned about permacoin. filecoin and permacoin could work well together, and will be talking to amiller about this in the future. |
| 13:58:07 | amiller: | it'd be appropriate to cite permacoin as concurrent work and point out how it's different... for one thing you already support a more rich API with gets/puts rather than just backup storage |
| 13:58:50 | jbenet: | gmaxwell what's the full attack here? |
| 13:59:13 | helo: | long term decentralization reduction? |
| 14:00:08 | helo: | * helo reads about PoSpace |
| 14:00:12 | adam3us: | adam3us has left #bitcoin-wizards |
| 14:02:29 | gmaxwell: | jbenet: I can store data which is asymetrically cheap for me to retrieve, allowing me a privledged position for mining at least if I do it long enough. This undermines the cost assumptions of the system. Really thats it, surely you agree that miners being able to reduce their costs relative to other miners are bad— Even if somehow mining is designed to be a loss (premine?) traders may seek to corner the market. |
| 14:02:32 | jbenet: | amiller sort of, it's actually better to cite it in the future. i avoided doing so to prevent people thinking filecoin was an improvement on top of permacoin. these two should be considered as independent nodes in the graph, with future work able to on both. in fact, let's talk about that offline later on. |
| 14:05:55 | amiller: | jbenet, "concurrent work" is a perfect code phrase for "this is a separate node in the graph" :) |
| 14:06:12 | jbenet: | gmaxwell in this construction, miners are competing on PoW still. PoR is not substantially contributing to delaying miners. |
| 14:06:53 | iddo: | jbenet: i'm curious, what's your rationale for remaining anonymous? |
| 14:07:08 | amiller: | jbenet, is it right to say that as a miner, first you try to find a proof of work, and then if you find one, you try to solve the proof of retrievabiliyt? |
| 14:07:29 | jbenet: | meaning, having data you can reproduce helps marginally, but you're time is spent mostly on PoW. |
| 14:07:33 | gmaxwell: | jbenet: Then how is your storage not delegatable? |
| 14:07:42 | jbenet: | amiller yep, that's right |
| 14:08:06 | amiller: | bbl |
| 14:08:59 | jbenet: | gmaxwell, it isn't necessarily. if a miner is using some other service as a storage mechansism, it's free to do so. |
| 14:09:05 | jbenet: | see discussion on secondary markets |
| 14:09:28 | jbenet: | (meaning, i don't claim non outsourceability) |
| 14:09:40 | gmaxwell: | so why will the outcome here not just be a single large pool with all the storage, and no redundancy? |
| 14:11:08 | jbenet: | total storage should exceed piece set size by a large factor. |
| 14:11:23 | jbenet: | in theory you could end with N pools. |
| 14:13:38 | jbenet: | (and ofc, you can solve this amiller's non outsourceability) |
| 14:16:21 | jbenet: | with* |
| 14:19:39 | iddo: | jbenet: why would N pools store the same files, instead of saving costs by delegating and storing the files at a single pool? |
| 14:26:09 | jbenet: | iddo: depends on whether they want to compete, or it's just one large pool -- though, the way i see this playing out is more toward the emergence of a secondary market optimizing the storage away. |
| 14:26:21 | jbenet: | (this = pools) |
| 14:28:22 | iddo: | isn't it more rational to cooperate instead of compete? this way each server stores different files? |
| 14:34:57 | jbenet: | iddo right, pooling up to a point. |
| 14:37:02 | gmaxwell: | if the storage gets 'optimized away' it kinda ends up being a pretext. |
| 14:37:08 | iddo: | isn't it rational for every N to merge into N/2 pools etc., until N=1 ? |
| 14:37:34 | gmaxwell: | jbenet: do you have any thoughts to the liability issue? In many jurisdictions (e.g. US) there is information for which possession is a strict liability crime. |
| 14:39:26 | iddo: | actually that's maybe an argument against N=1, if server is seized by authorities then there's redudency...? |
| 14:39:45 | shesek: | gmaxwell, how can something like this be enforced? |
| 14:40:02 | jbenet: | gmaxwell it's dangerous to threaten permanent storage of illegal bits. So, this construction doesn't force you to store everything, only incentivizes you to. Authorities can post a takedown list of pieces, which will affect miners' incentive structures. |
| 14:40:04 | iddo: | shesek: if N=1 then it can be enforced easily... |
| 14:40:05 | shesek: | I can be in possession of some information by visiting a website that adds it to my cache |
| 14:40:15 | shesek: | without every seeing this information, even |
| 14:40:22 | shesek: | * ever |
| 14:40:57 | jbenet: | gmaxwell but those willing to risk it, can do so if they desire to. perhaps full takedown facilities should be built in, but I'm not yet convinced. |
| 14:41:02 | shesek: | or by someone sending me an email with the information hidden inside the headers (assuming a local email client) |
| 14:41:37 | jbenet: | (i happen to think censorship is really really bad. so i don't want to make it trivially easy. on the other hand, it's stupid to boast a system that can store any illegal bits). |
| 14:41:41 | shesek: | its not rational to blame people for just possessing data, you must at least show intent |
| 14:45:55 | gmaxwell: | shesek: it's not rational, but it is the law currently. Thats what strict liability means. :( Of course, enforcement is super-selective. |
| 14:46:54 | gmaxwell: | jbenet: fair answer in any case. |
| 14:48:10 | gmaxwell: | (and arguably a better answer than we have in Bitcoin— which basically amounts to keeping the channel so narrow enough that any prosecution sounds silly... "what, would you prosecute a newspaper when someone encodes some illegal data into the classified archives??" |
| 14:48:15 | gmaxwell: | ) |
| 14:49:52 | jbenet: | gmaxwell, that can get pretty bad for Bitcoin if some writes a trivial stego tool on the web that makes transactions and reads them back out. |
| 14:50:02 | jbenet: | (bitcoin and everyone) |
| 14:50:35 | jbenet: | i think bitcoin is safe from that now though, too bif. |
| 14:50:37 | jbenet: | big* |
| 14:52:37 | gmaxwell: | jbenet: perhaps, but see my newspaper example. There is some boundary where the storage is so contrived it's obvious that the _tool_ is really the storage device, but this is untested and fuzzy like many things in law. |
| 14:53:29 | jbenet: | yep, we are in agreement. |
| 14:56:44 | jbenet: | gmaxwell i'm looking for bitcoin hackers who'd be interested in building the client for filecoin with me. thoughts on good people? (potentially paid work) |
| 15:03:36 | nkuttler_: | nkuttler_ is now known as nkuttler |
| 15:05:15 | lclc_: | lclc_ is now known as lclc |
| 15:38:17 | nairb: | jbenet: what's filecoin ? |
| 15:38:34 | jbenet: | nairb: filecoin.io |
| 15:44:39 | nairb: | jbenet: is encryption built-in or would you have to "put" encrypted files? |
| 15:44:53 | jbenet: | nairb: pre-crypt. |
| 15:45:00 | sipa: | that's the client side thing anyway |
| 15:46:38 | gmaxwell: | for some of those liabilities reasons you might want to have it setup so that storing non-encrypted data is hard— but thats hard. :) |
| 15:48:06 | jbenet: | gmaxwell, true. yep, doable. not as expensive as PoW :] |
| 15:49:14 | nairb: | i guess it just kinda needs to be built into the client in a seamless way |
| 15:49:34 | nairb: | using the private key or something so you don't need a separate password or anything to decrypt |
| 15:49:36 | gmaxwell: | well there is the number theoretic provable hash that I came up with that lets you prove your lookup key is a hash. And you use the data being hashed to derrive an encryption key. Potentially even a NI cut and choose proof that shows the data is AES encrypted... but just building it in the software is probably best. |
| 15:56:31 | sipa: | jgarzik: what is your sidechain idea? |
| 15:57:10 | jgarzik: | sipa, https://bitcointalk.org/index.php?topic=676703.msg7682680#msg7682680 |
| 15:57:40 | jgarzik: | sipa, with miner buyin, it seems like a low cost merged mining alternative |
| 15:57:50 | jgarzik: | sipa, as each miner would mine one of those locally |
| 15:58:08 | sipa: | heh, no 2-way pegging? |
| 15:58:18 | jgarzik: | sipa, but as gmaxwell points out, can otherwise be subject to thundering herds etc. |
| 15:58:21 | jgarzik: | sipa, KISS |
| 15:58:40 | jgarzik: | sipa, I just want to do namecoin-like, no frills, easy for my aged brain to reason secure |
| 15:58:47 | sipa: | i wouldn't call it a sidechain in that case, just some odd merge-mined alternate chain |
| 15:59:42 | jgarzik: | sipa, In jgarzik-terminology-land, a "side chain" is any chain that requires/builds upon bitcoin's mining network hashpower/strength |
| 15:59:49 | sipa: | ok |
| 16:00:05 | sipa: | i think most commonly that's called merged mining |
| 16:00:21 | sipa: | side chains seems to mean any chain (merged mined or not) that has 2-way pegging |
| 16:00:30 | sipa: | as in: different chain, but same currency |
| 16:00:41 | jgarzik: | sipa, I think 1-way pegging can count too |
| 16:00:45 | sipa: | perhaps yes |
| 16:01:06 | jgarzik: | * jgarzik happens to think 1-way pegging has uses, and is again simpler to reason about than 2-way |
| 16:12:39 | maaku: | * maaku thinks the word needs a more specific meaning to be useful at all |
| 16:13:32 | nairb: | people were talking about side-chains before someone (gmaxwell?) came up with a way to do two-way pegged side-chains... so I'd tend to think of a two-way sidechain as a special case of side-chains. |
| 16:14:16 | nairb: | but I was thinking of sidechains as being something that's at least one-way pegged, not just merge-mined |
| 16:19:45 | maaku: | side chains isn't necessarily pegging as I've used the term ... it is any chain in which you can move bitcoin value from main chain to the alt chain *and back* |
| 16:19:53 | maaku: | pegging is just one interesting mechanism for doing so |
| 16:25:18 | mhanne_: | mhanne_ is now known as mhanne |
| 16:43:36 | jtimon: | nairb I think the previous most generic term was altchain (meaning it may not have its own p2p coin) |
| 17:10:33 | stqism: | stqism is now known as NikolaiToryzin |
| 20:22:10 | davidlatapie: | davidlatapie has left #bitcoin-wizards |
| 22:21:04 | moneycat: | moneycat has left #bitcoin-wizards |
| 22:59:38 | tomaw: | [Global Notice} Hi, sorry for the rerouting spam. I'm done now. |
| 23:00:32 | nkuttler_: | nkuttler_ is now known as nkuttler |
| 23:01:07 | kinlo_: | kinlo_ is now known as kinlo |