| 00:08:34 | davidlatapie: | davidlatapie has left #bitcoin-wizards |
| 00:45:01 | TurtleBib: | TurtleBib has left #bitcoin-wizards |
| 00:51:41 | kanzure: | had an out of band conversation with andytoshi in austin at dinner tonight |
| 00:52:09 | kanzure: | we were wondering how to store science papers |
| 00:52:16 | kanzure: | the problem is that nobody has a complete copy of science |
| 00:52:26 | zooko: | Yeah. :-( |
| 00:52:29 | kanzure: | and nobody seeds because altruism or something, and it's 50 TB for the majority of science anyway |
| 00:52:41 | kanzure: | so, besides altruism, it would seem to make sense to pay people to host science |
| 00:53:04 | nsh: | well, maybe we ought to have a reliable and robust shared library storage system before we go about collecting all the science |
| 00:53:12 | nsh: | otherwise there's going to be significant duplication of effort |
| 00:53:35 | kanzure: | a centralized operation can exist without hosting the papers centrally |
| 00:53:37 | nsh: | preferably somewhere immune to copythink |
| 00:53:42 | nsh: | * nsh nods |
| 00:54:25 | kanzure: | there can be a centralized entity that allocates chunks of pdfs (but never entire pdfs) (and never ever single pdfs) to hosting providers |
| 00:55:22 | kanzure: | readers pay through the centralized arbitrator and the arbitrator acts as a router to known hosts (modulo tor) for those chunks |
| 00:56:06 | gmaxwell: | I'll gladly pay to store a complete copy of science, if someone would provide it to me. (as would archive.org for that matter) :P |
| 00:56:23 | gmaxwell: | kanzure: I have 40TB of storage sitting idle mostly at the moment. (actually cold in in a box) |
| 00:56:25 | kanzure: | unfortunately most people can't store 50 TB |
| 00:56:41 | kanzure: | well, hosting 40 TB is not that difficult really, i mean that you can't publicly do that and provide access |
| 00:57:21 | kanzure: | and most people don't have 40 TB anyway-- they should be able to host a small portion of science in exchange for money. |
| 00:57:23 | justanotheruser: | kanzure: what percentage of science was the aaron swartz leak? |
| 00:57:32 | kanzure: | aaron swartz didn't actually leak anything |
| 00:57:40 | kanzure: | that was gmaxwell |
| 00:58:07 | kanzure: | "leak" |
| 00:58:23 | justanotheruser: | meh |
| 00:58:32 | justanotheruser: | leak let you understand it |
| 00:59:11 | kanzure: | each paper chunk would be signed |
| 00:59:39 | kanzure: | the arbitrator also maintains a merkle root or hash table of all available chunks ... |
| 01:00:07 | kanzure: | all this does right now is proof that i host a chunk, and a merkle root gives us the ability to prove that the chunk is one that the arbitrator approved, and that i am not censoring (but the arbitrator might) |
| 01:00:20 | kanzure: | there really should be proof of retrievability in here somewhere |
| 01:01:16 | kanzure: | arbitrator can provide payment escrow of some sort based on proof of retrievability perhaps. |
| 01:01:47 | justanotheruser: | kanzure: so you want a proof of storage for donors? |
| 01:01:49 | kanzure: | the payment to the science chunk hoster does not have to be instant really. it could take a while if necessary. like for escrow reasons. |
| 01:01:56 | kanzure: | it's not storage, it's retrievability. |
| 01:02:10 | justanotheruser: | I think this is a non-issue tbh. If someone had all of science plenty of people would host it |
| 01:02:19 | kanzure: | it should be a bitcoin output that can only be redeemed in the event of proof of retrievability or something... |
| 01:02:43 | nsh: | i don't think diffused responsibility and fancy crypto will necessarily fend off Elsevier's fleet of flying monkey attack lawyers though |
| 01:02:46 | justanotheruser: | kanzure: I'm not sure you can "prove" retrievability |
| 01:03:05 | justanotheruser: | you can probably invoke trust for it |
| 01:04:06 | kanzure: | hmm there may be a dispute between the reader and the hoster... where the reader doesn't rleease something to get the escrower to complete.. hrm. |
| 01:04:22 | kanzure: | oblivious rounds could be useful |
| 01:04:31 | justanotheruser: | you've read this right? https://bitcointalk.org/index.php?topic=310323.0 |
| 01:05:21 | kanzure: | s/rounds/ram ... -andytoshi |
| 01:06:39 | kanzure: | im thinking re oblivious ram, to use an oblivious ram protocol with memory lookups replaced by eg onion ouutes -- andy |
| 01:07:30 | kanzure: | the idea being, a transcript of correct oram execution is a proof of transmission that the sender can create |
| 01:09:47 | kanzure: | as a rule it is important to not rely on altruism for the correct operation of this system |
| 01:13:06 | kanzure: | oracle can look at transcripts between a host and a reader |
| 01:13:09 | kanzure: | similar to otr i guess |
| 01:13:16 | kanzure: | some publicly verifiable system |
| 01:13:19 | gmaxwell: | meh, I mean right now 50TB of storage costs $500/yr on a 5 year hardware refresh cycle. (and hopefully dropping). I think you underestimate what people could pay for. |
| 01:13:39 | kanzure: | the length of the transcript between the two nodes, and every message is signed by both parties, and the host and the reader submits the transcripts to the arbitrator longest one wins |
| 01:13:59 | kanzure: | i'm sure they can pay for it but there are legal reasons why nobody has opened up access to 50 TB |
| 01:14:05 | gmaxwell: | I think thats too vague. |
| 01:14:40 | gmaxwell: | (I mean your protocol stuff) |
| 01:14:49 | zooko: | * zooko has been reading the conversation with interest. |
| 01:15:22 | kanzure: | well the main problem was something about a reader not receiving it... no way to prove a negative. |
| 01:15:27 | kanzure: | s/it/chunks |
| 01:15:29 | gmaxwell: | Sure you can have someone serve the data out and pay them to do this. okay, but this doesn't _control_ access to the information, e.g. prevent extra copies.. without losing the benefit of the redundancy in the first place. |
| 01:15:56 | kanzure: | er, why would control be necessary |
| 01:15:58 | gmaxwell: | Don't assume that paying to send copies (storage and bandwidth) has anything to do with it, it doesn't. If that were it I'd personally make it happen. |
| 01:17:13 | kanzure: | i agree that sending is not the problem |
| 01:17:20 | kanzure: | storage and access is.. |
| 01:17:53 | gmaxwell: | It's not. Go drop the control over it and the legal gatekeeping, it'll be all available in as much quantity as anyone cares to copy it three days after it hits my hands. |
| 01:18:22 | kanzure: | (like the copyright legal risk) |
| 01:18:35 | kanzure: | i agree that it's fine if it's available to copy |
| 01:19:08 | kanzure: | er, mayi ask why you are not already hosting a copy of all of science? |
| 01:19:25 | gmaxwell: | Because I am unable to obtain it. |
| 01:19:34 | kanzure: | btw what we're saying is that the science arbitration oracle does not have to be exposed to legal risk as much as hosting and distributing copies |
| 01:19:38 | kanzure: | oh, well i have it |
| 01:19:44 | kanzure: | i could have told you that ages ago |
| 01:19:51 | kanzure: | * kanzure scratches his head |
| 01:19:58 | gmaxwell: | ha |
| 01:20:14 | gmaxwell: | Ah, oh okay, so I may be misunderstanding what you were talking about. |
| 01:20:23 | gmaxwell: | Hurray for being non-concrete. |
| 01:20:26 | kanzure: | how do you protect against hateful publishers suing the crap out of you |
| 01:21:09 | gmaxwell: | So you propose a system operating without the consent of the publishers, which is immune to surpression by being highly distributed... but is sustainable because it has a model to fund its operation? |
| 01:21:45 | kanzure: | well, my goal was to avoid relying on altruism, so i think yes |
| 01:22:28 | gmaxwell: | (I've mostly just been expecting for the price of storage to reach a point where some anonymous benefactors can just buy 1000 50TB disks, ship them to random people with a note that says they have a moral obligation to replicate and pass on the disk, or at least pass it along to someone who will; a purely offline system has much better robustness properties.) |
| 01:22:55 | zooko: | Gotta go read a bedtime story or ten to my five year old. :-) Hopefully you folks still be solving the world's science-sharing problem when I get back. |
| 01:23:28 | kanzure: | i agree that ridiculously cheap storage would be extremely helpful |
| 01:23:41 | kanzure: | not everyone has to store a full copy |
| 01:23:47 | gmaxwell: | (even better when its self bootable and knows how to copy itself...) |
| 01:24:29 | kanzure: | when you download you end up getting extra chunks of bits of extra papers |
| 01:24:30 | gmaxwell: | kanzure: it's better if the system is offline, because the security model traverses social networks exclusively without being broadly observable, in a way that a network based system is. Also, a full collection can have value that potentially unreliable network access cannot. |
| 01:24:55 | kanzure: | i am not arguing against the existence of full collections |
| 01:25:08 | gmaxwell: | but right fair enough, it's not generally pratical now. |
| 01:25:52 | gmaxwell: | so going back to what you were talking about before, I don't know that reader access is a useful test probe, since you can just creat sybil readers. |
| 01:25:54 | kanzure: | i agree that it would be bad to rely on some sort of pdf scarcity re: funding model for hosts (or paying the hosts) |
| 01:26:25 | kanzure: | this is entirely a legal risk pricing scheme |
| 01:26:32 | kanzure: | it's not like data storage is particularly novel |
| 01:26:43 | kanzure: | servers sending files is totally not novel at all |
| 01:26:47 | gmaxwell: | yea, sorry, I thought you were trying to address storage and transfer. |
| 01:26:58 | gmaxwell: | I understand that you're not now. |
| 01:27:15 | kanzure: | do you think that transfer is particularly important, like requiring tor |
| 01:27:25 | gmaxwell: | you also have to consider that legal risks are greatly enhanced by commercial gains. |
| 01:27:46 | Taek: | I'm struggling to understand what the core issue is? What's to stop you from putting it on a .onion? |
| 01:28:08 | kanzure: | yes it would be nice if the hosts are anonymous and receiving pseudonymous payments |
| 01:28:27 | gmaxwell: | I mean, elsevier's revenue is on the order of 7 billion a year. This pays for a lot of trouble generation. |
| 01:30:08 | gmaxwell: | Taek: hidden service security is very low, especially for long lived widely known things that move a lot of traffic. |
| 01:31:02 | Taek: | is legal persecution the core problem then? |
| 01:31:16 | kanzure: | dude people have died over this |
| 01:32:56 | gmaxwell: | Taek: there isn't really any other problem; unlike movie and music publishing the widespread copying of academic works doesn't create socially difficult questions like how do you pay the authors. (they're already not paid via the publishing) |
| 01:40:40 | Taek: | thing is movie and music piracy seems to do just fine. you can get pretty much any once-popular movie or album from at least one of a wealth of trackers |
| 01:40:47 | Taek: | what makes science so much harder? |
| 01:42:19 | gmaxwell: | The coverage of movies is fairly poor, mostly covering only popular things; you just miss how much is missing... and they're massively more interesting the audience for papers is often much smaller.. and there is a benefit from having reliable access that is greater than the sum of the benefits of the indivigual works. |
| 01:47:20 | Taek: | on movies: piratebay might not be great but the set of movie private trackers (karagarga, hdbits, tehconnection, passthepopcorn, cinematik) has pretty extensive coverage in my experience. Though you are right even obscure films are probably orders of magnitude more visible than the average scientific paper |
| 01:48:08 | Taek: | probably more visible than the average scientific journal, though I really wouldn't know |
| 01:55:50 | GnarSith: | academic piracy is also more heavily policed. you dont see the RIAA suiciding aaron swartz. |
| 02:05:09 | Luke-Jr: | academic piracy? people are killing researchers? |
| 02:05:43 | phantomcircuit: | lulz |
| 02:10:54 | AdrianG: | idk taek |
| 02:10:55 | kanzure: | i wonder if academic textbooks were overpriced even in the 1800s. |
| 02:11:04 | AdrianG: | some obscure films are very hard to find. |
| 02:11:14 | AdrianG: | academic paper scarcity is just due to paywalls. |
| 02:11:53 | AdrianG: | the only paper i couldnt find immediately in digital format was some endocrine medical journal article from 1950s |
| 02:11:57 | AdrianG: | or possibly early 60s |
| 02:12:09 | kanzure: | it would be interesting if you could claim that ISI web of knowledge is corrupt because it is not publicly verifiable |
| 02:12:29 | kanzure: | it would be trivial to implement some sort of citation metric system thingy where each paper signs its citations |
| 02:13:05 | kanzure: | and if you find discrepancies (whether in ocr or otherwise) you could claim academic fraud on behalf of isi and use this as a reason to switch to a system with public auditing and really the most basic forms of cryptography... |
| 02:13:28 | kanzure: | oops i meant whether due to ocr or otherwise |
| 02:13:50 | kanzure: | (because at some point certain systemic errors across an entire field is no different from trying to influence citation graphs/ranking/prestige/science funding) |
| 02:14:10 | kanzure: | (a similar argument can be made about ocr and interpretation of foreign-language names and discrimination, if you were feeling ungrateful) |
| 02:14:55 | kanzure: | er i mean ungracious not ungrateful |
| 02:18:00 | kanzure: | zooko must have like ten five year-olds |
| 02:29:12 | davidlatapie: | davidlatapie has left #bitcoin-wizards |
| 02:34:49 | kyletorpey: | kyletorpey has left #bitcoin-wizards |
| 02:38:35 | justanotheruser: | kanzure: I'm not sure how well a trustless payment for "hosting" would work. You then have a big incentive to have the file while not giving it to anyone |
| 02:39:00 | kanzure: | you are not paying for hosting, just for a copy or access or the transfer or the retrieving |
| 02:40:17 | justanotheruser: | kanzure: then you still have a bit of a trust problem. |
| 02:40:22 | kanzure: | why's that |
| 02:40:34 | justanotheruser: | Why do I need to pay you after you send me a file? |
| 02:40:55 | fenn: | gmaxwell: "50TB of storage costs $500/yr" that's $500/mo on amazon glacier, which isnt really hosted storage it's more like off-site backup |
| 02:40:57 | kanzure: | you would pay upfront |
| 02:41:01 | justanotheruser: | There is no enforcement |
| 02:41:02 | fenn: | gmaxwell: why do you have 40TB lying around? |
| 02:41:11 | justanotheruser: | kanzure: why would I need to send you a file? |
| 02:41:20 | kanzure: | justanotheruser: because you want the money |
| 02:41:25 | justanotheruser: | kanzure: but I already have the money |
| 02:41:38 | kanzure: | no, the scheme i elaborated on above does not give the money to the host immediately |
| 02:41:48 | justanotheruser: | kanzure: yes, you had an arbitrator |
| 02:42:00 | justanotheruser: | I mean yes, you are correct, not yes contradicting your "no" |
| 02:42:04 | maaku: | maaku is now known as Guest26327 |
| 02:42:06 | kanzure: | heh |
| 02:42:43 | justanotheruser: | and then that leaves us with the problem of preventing sybil arbitrators. |
| 02:42:47 | kanzure: | there may be a way to use cryptography such that the reader is incentivized to put together multiple chunks and submit some proof to the network to retrieve some money they put into escrow or something |
| 02:43:15 | justanotheruser: | kanzure: putting together multiple chunks locally isn't broadcasting though |
| 02:43:29 | kanzure: | like, maybe each host encodes some value in each of the chunks, such that when multiple hosts send their multiple chunks or whatever to the reader, that the reader can assemble a complete transaction to recover some balance he originally sent into "escrow" that was over and beyond the actual "price" |
| 02:43:39 | kanzure: | he would be incentivized to broadcast to get recovery |
| 02:43:45 | kanzure: | ... maybe. |
| 02:43:53 | kanzure: | (i am making things up) |
| 02:44:30 | justanotheruser: | anyways, I hope you can somewhat understand why my thoughts that a few central authorities would be a good idea. It is probably pretty difficult getting everyones incentives aligned for a system like this. |
| 02:45:00 | kanzure: | unfortunately serving files from a central location is specifically counter to the threat model |
| 02:45:37 | justanotheruser: | if it is distributed and in many countries publishers don't have legal power over it is less of a threat. |
| 02:45:58 | kanzure: | why would publishers not attack within their own jurisdictions? |
| 02:46:10 | justanotheruser: | who would they attack? |
| 02:46:19 | kanzure: | hosts, dns, etc. |
| 02:46:50 | justanotheruser: | the hosts would have to be in this other country |
| 02:47:01 | justanotheruser: | re: dns, ask piratebay |
| 02:47:08 | justanotheruser: | whatever domain they're on now :P |
| 02:47:44 | kanzure: | aren't most of the piratebay people undergoing lots of lawsuits right now |
| 02:48:09 | justanotheruser: | yep. |
| 02:48:16 | justanotheruser: | at least they were |
| 02:48:22 | justanotheruser: | I haven't been keeping up with them |
| 02:49:25 | kanzure: | so the hosts would also have to never travel ever |
| 02:50:53 | fenn: | "serving files from a central location is specifically counter to the threat model" just about sums it up |
| 02:51:16 | fenn: | dont you kids remember napster |
| 02:51:46 | justanotheruser: | kanzure: yep |
| 02:52:20 | kanzure: | it's interesting is that torrent seeders still get sued |
| 02:52:34 | kanzure: | and that people who are seeding partial copies are less often sued (i actually can't cite any relevant case) |
| 02:52:38 | justanotheruser: | fenn: US based |
| 02:53:20 | phantomcircuit: | fenn, glacier is offsite backup for non critical data |
| 02:53:23 | kanzure: | and even though a seeder might never send an entire copy to a leecher, the law has generally looked upon each seeder as if distributing entire copies (even if the leecher only used them for non-contiguous chunks and not the entire file) |
| 02:53:29 | phantomcircuit: | it's lol expensive to actually read from |
| 02:53:40 | phantomcircuit: | iirc it's like quadratic with the rate at which you read |
| 02:53:48 | fenn: | phantomcircuit: yeah my point was that hosting 50TB is a lot more expensive than $500/yr |
| 02:54:14 | kanzure: | er, 50 TB is not outside the realm of a single rack or whatever |
| 02:54:42 | fenn: | you can probably fit it into a 1U or 2U slot |
| 02:55:02 | phantomcircuit: | 50/6 ~= 9 |
| 02:55:05 | phantomcircuit: | so yeah 2U |
| 02:55:18 | phantomcircuit: | 1U if they weren't hot swap or it was back to back |
| 02:56:52 | kanzure: | another reason that you will need a science oracle is that there's really no way to "prove" that any random addition to the collection is "science" as far as i know |
| 02:57:08 | kanzure: | and supplementary docs are huge and suddenly you have to consider storing jove.com's video collection or something |
| 02:57:21 | kanzure: | http://diyhpl.us/~bryan/jove.urls.txt |
| 02:57:48 | justanotheruser: | phantomcircuit: quadratic with the rate you read? |
| 02:58:00 | phantomcircuit: | justanotheruser, yeah |
| 02:58:16 | justanotheruser: | I must not be reading that right? Why would it be like that? |
| 02:58:26 | phantomcircuit: | you're assigned some rate under which it's reasonable based on how much you have stored |
| 02:58:31 | kanzure: | there are certain forms of storage where it takes more effort to read than write |
| 02:58:43 | phantomcircuit: | but they dont provide any tools to keep yourself under that rate |
| 02:58:44 | kanzure: | you can make different storage reliability or longevity guarantees in different scenarios |
| 02:59:03 | phantomcircuit: | justanotheruser, im guessing that it's just servers with wake on lan that are powered down almost all of the time |
| 02:59:09 | phantomcircuit: | so they want to batch reads |
| 02:59:10 | kanzure: | (which they wouldn't be able to make to all writable storage on their infrastructure, of course) |
| 02:59:23 | kanzure: | oh that's strange, i would have assumed something more elaborate, like tapes |
| 02:59:26 | justanotheruser: | phantomcircuit: so this is just for "glacier"? |
| 02:59:32 | phantomcircuit: | justanotheruser, yes |
| 02:59:40 | phantomcircuit: | everything else gets cheaper in volume |
| 02:59:57 | phantomcircuit: | kanzure, maybe, it's the same economics |
| 03:00:03 | kanzure: | would the cost of tape retrieval explain their pricing |
| 03:00:33 | fenn: | i dont think they use tapes |
| 03:00:45 | phantomcircuit: | iirc glacier actually reads back data at intervals to ensure data doesn't get corrupt with time |
| 03:00:53 | phantomcircuit: | tapes would make that a supreme nuisance |
| 03:01:18 | phantomcircuit: | i seriously think it's just old power hungry servers which they turn off most of the time |
| 03:01:23 | fenn: | oh my bad "Glacier runs on Spectra T-Finity tape libraries with LTO-6 tapes" |
| 03:01:42 | fenn: | but nobody actually knows? |
| 03:02:23 | phantomcircuit: | fenn, there's a bunch of speculation about it |
| 03:02:31 | phantomcircuit: | but nothing confirmed afaik |
| 03:02:46 | fenn: | let's just assume they use tattooed gnomes |
| 03:04:50 | kanzure: | there is very little incentive in my scheme for a hoster to not try to figure out what their chunks are |
| 03:05:22 | kanzure: | or, if they track how much they have been uploading versus their income, they could just sybil themselves into a new set of chunks somehow(?) and try to get a set of chunks that pays better |
| 03:05:32 | kanzure: | so the least-often-requested chunks would have to be carefully subsidized by the science oracle |
| 03:07:22 | kanzure: | well, all of the chunks would have to be carefully subsidized i suppose, but particularly those hosts that are unlucky to get a random mix of totally worthless chunks that nobody ever wants |
| 03:07:31 | fenn: | that's what happens in freenet, but the least-requested chunks get lost and disappear |
| 03:07:34 | kanzure: | well, okay, so just do some good chunk mixing and distribution |
| 03:07:53 | kanzure: | isn't freenet anonymity-focused rather than focused on chunk-preserving |
| 03:08:17 | fenn: | initially it was not anonymous but then they messed it all up for i don't know why |
| 03:08:47 | kanzure: | andytoshi and i should go stalk brandon wiley since he's in the area |
| 03:09:10 | zooko: | Oookay. The kids or asleep, or at least feigning it convincingly. |
| 03:09:27 | zooko: | Did we solve the matter of distribution of scientific knowledge yet? |
| 03:09:32 | fenn: | no |
| 03:09:49 | kanzure: | the millenial science ark is just beginning |
| 03:10:07 | fenn: | how many cubits should it have |
| 03:10:10 | kanzure: | or personally i've been leaning towards strategic science reserve |
| 03:10:13 | kanzure: | but whatever |
| 03:10:33 | zooko: | " zooko must have like ten five year-olds" ← it definitely seems like that sometimes. |
| 03:10:43 | fenn: | what if it's made of gopherwood |
| 03:12:18 | fenn: | ok so i think we can say that storage is not the problem, it's distribution without a central point of failure |
| 03:12:42 | fenn: | anyone with a gopherwood box can put 50 hard drives in it |
| 03:13:39 | Taek: | and how do you update it? have a new drive for each years worth of science? |
| 03:13:56 | fenn: | yes, there are write-only file systems |
| 03:14:28 | fenn: | and things like git-annex can reorganize the structure without actually touching the bulk of the data |
| 03:15:26 | fenn: | it seems that IP address is the main vulnerability by which publishers can track down people hosting information |
| 03:15:54 | kanzure: | "oh noes you were storing 20 bytes of data"? |
| 03:16:45 | kanzure: | s/storing/sending |
| 03:18:57 | fenn: | tor was discounted for reasons i didn't understand (and cant find in backlog) |
| 03:19:24 | fenn: | kanzure: how do you transmit the data from a throwaway IP without storing it? |
| 03:19:37 | kanzure: | "hidden service security is very low, especially for long lived widely known things that move a lot of traffic." |
| 03:19:56 | kanzure: | in that context what is "you" |
| 03:20:13 | phantomcircuit: | kanzure, that is only true for certain configurations |
| 03:20:34 | fenn: | "you" is an agent with access to the data |
| 03:20:41 | phantomcircuit: | you can copy the private key to multiple systems and make it very hard to identify the hidden service |
| 03:20:45 | kanzure: | fenn: and what are you not storing? |
| 03:20:49 | fenn: | the data |
| 03:20:51 | phantomcircuit: | there's a bunch of gotchas in doing that though |
| 03:21:08 | kanzure: | fenn: storing is not something that people are prosecuted for |
| 03:21:09 | phantomcircuit: | like they fight with the directory servers about whose hidden service descriptor to use |
| 03:22:23 | kanzure: | as far as i can tell nobody has been prosecuted for sending a few bytes but not a complete file |
| 03:22:26 | kanzure: | i know this is a very weak observation |
| 03:22:33 | zooko: | There exists a Tahoe-LAFS storage grid made up entirely of servers which are reachable only as Tor-hidden-services. |
| 03:22:35 | zooko: | So I'm told. |
| 03:22:36 | fenn: | say publisher's crack squad of goons downloads a paper from 1.2.3.4, they email the ISP for that address and demand personally identifying information, then file a lawsuit against whoever that was |
| 03:22:55 | kanzure: | they weren't papers, see above (chunking, never storing a paper on a single server, etc) |
| 03:23:05 | fenn: | what use is a chunk? |
| 03:23:09 | kanzure: | zooko: i was trying to design a system that doesn't rely on altruism.. |
| 03:23:23 | kanzure: | fenn: well you would get chunks from multiple sources to assemble a file, possibly using torrenting |
| 03:23:40 | fenn: | ok, goon squad downloads chunks from 1.2.3.4 and 1.2.3.5 |
| 03:23:52 | fenn: | now they have two targets to sue |
| 03:25:18 | zooko: | kanzure: I'm not aware of any parts of the Tahoe-LAFS design that would have to be undone in order to make it agoric. |
| 03:26:10 | kanzure: | zooko: huh? so why isn't everyone storing all would-have-otherwise-been-torrented-but-isn't-because-nobody-wants-to-seed content there? |
| 03:26:51 | kanzure: | wait, i might have misparsed a thing there... |
| 03:27:26 | zooko: | Forgive me if I'm being short, but this is one of those things that I've grown weary of. |
| 03:27:29 | zooko: | Not your fault. |
| 03:27:42 | kanzure: | which part are you particularly weary of? |
| 03:28:03 | zooko: | The thing is, Tahoe-LAFS comprises about 5 or 6 parts. Any system with similar ambitions would be similarly complex. E.g. Freenet, GNUnet, and many others. |
| 03:28:28 | zooko: | And, 90% of it would not need to change at *all* in order to extend it to an agoric system |
| 03:28:36 | kanzure: | ah, i'm not sure that perceived complexity factors strongly into whether or not it is operational |
| 03:29:05 | zooko: | But, well-meaning, educated people like you, come along and say "I want an agoric system!" and then immediately set about reinventing the parts that would *not* need to change. |
| 03:29:07 | zooko: | See my point? |
| 03:29:19 | kanzure: | i'm not sure i am interested in reinventing anything |
| 03:29:24 | kanzure: | for example, above i was strongly opposed to reinventing tor |
| 03:29:27 | zooko: | So maybe your new variant is better in some ways, but the differences from tahoe-lafs are not *necessary* to achieve your stated goals. |
| 03:29:32 | kanzure: | (or that was possibly just in private said to andytoshi) |
| 03:30:03 | zooko: | Like I said, it isn't you that I'm ranting at, it is the half a dozen people who came past just before you and did *that*. That thing that I just complained about. |
| 03:30:15 | kanzure: | whatever, it's valid i'm sure |
| 03:30:25 | justanotheruser: | so what is the decentralization problem with sidechains and mining given that p2pool could split the chain they're evaluating and use fraud proobs |
| 03:31:44 | zooko: | There are some patches to streamline Tahoe-LAFS integration with Tor that could use code review: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2319 |
| 03:31:54 | fenn: | zooko: what is the current bandwidth capacity of this tor-tahoe system? |
| 03:32:20 | fenn: | and how does it scale? |
| 03:32:48 | kanzure: | "Users do rely on storage servers for availability. The ciphertext is erasure-coded into N shares distributed across at least H distinct storage servers (the default value for N is 10 and for H is 7) so that it can be recovered from any K of these servers (the default value of K is 3). Therefore only the failure of H-K+1 (with the defaults, 5) servers can make the data unavailable." |
| 03:33:06 | kanzure: | how would these servers be paid for retrieving the correct data? |
| 03:33:10 | kanzure: | or storing or something. |
| 03:33:36 | gmaxwell: | 19:40 < fenn> gmaxwell: "50TB of storage costs $500/yr" that's $500/mo on amazon glacier, which isnt really hosted storage it's more like off-site backup |
| 03:34:02 | gmaxwell: | fenn: thats what you pay in premium for using a commercial service instead of just buying disks. |
| 03:34:15 | zooko: | fenn: I don't know the capacity of the tor-tahoe grid. |
| 03:34:27 | zooko: | fenn: I guess it probably scales, in terms of number of servers, to hundreds of servers. |
| 03:34:39 | zooko: | (Because there have been tahoe-lafs grids before with hundreds of servers.) |
| 03:34:45 | zooko: | kanzure: I was thinking Bitcoin. |
| 03:36:03 | kanzure: | so you pay bitcoin when? |
| 03:36:28 | zooko: | Well, this is where it gets interesting. |
| 03:37:18 | zooko: | And notice that these questions are exactly the same for tahoe-lafs-agoric as for any related architecture such as the ideas we were kicking around on this channel earlier. |
| 03:37:46 | kanzure: | i believe there are many possible answers, some more correct than others |
| 03:37:54 | kanzure: | and others that are totally insecure and broken |
| 03:37:59 | zooko: | Well, what do you think would be the best answer? |
| 03:38:27 | kanzure: | i would prefer a system that does not pay cheaters |
| 03:38:46 | kanzure: | or a system that does not collapse under the presence of cheaters |
| 03:38:54 | fenn: | what about sliding scale donation |
| 03:38:56 | zooko: | * zooko thinks. |
| 03:39:17 | kanzure: | aren't donations just another way of saying altruism and begging |
| 03:39:25 | zooko: | Um, so the main expense that I'm thinking about is that of operating a storage server with some storage capacity. |
| 03:39:37 | fenn: | yes, but nobody donates to cheating |
| 03:39:58 | zooko: | A storage server can "cheat" by pretending to store your ciphertexts for you but failing to deliver them later. |
| 03:39:59 | kanzure: | zooko: so we have lots of people that have huge paper archives, colossally huge |
| 03:40:09 | kanzure: | zooko: and the problem is that nobody can really host 12 terabytes of libgen torrents |
| 03:40:19 | kanzure: | zooko: without being subjected to intense legal pressure |
| 03:40:26 | fenn: | (there are numerous ways to cheat, best to be explicit about what sort of cheating) |
| 03:40:34 | zooko: | So, I was thinking maybe pay the storage servers regularly, e.g. monthly, if they pass proof-of-retrievability tests. |
| 03:40:39 | kanzure: | and nobody really wants to host just a portion of science for free or something, because they don't believe everyone else will, and that makes their random chunk less useful |
| 03:40:56 | kanzure: | (who would be making the regular payments?) |
| 03:42:11 | fenn: | i thought we established that storage wasnt the problem |
| 03:42:15 | kanzure: | there are very few people who want to host "Annuals of Geology in Odessa, Texas" compared to whatever their special interest is |
| 03:43:03 | kanzure: | for some reason we haven't seen people making their multi-terabyte collections available over tor for free |
| 03:43:05 | zooko: | kanzure: if nobody wants to host it, or to pay for its hosting, then there is no incentive-compatible means to make it be hosted, so I don't understand your objection. |
| 03:45:03 | kanzure: | earlier i proposed a central oracle that figures out payment routing and making sure enough of science is incentivized to be available or something |
| 03:45:17 | fenn: | kanzure: libgen is already available in the clear from russia; there's no need for them to use tor. is there some other collection that would be using tor? |
| 03:45:26 | kanzure: | where each payment subsidizes the whole thing |
| 03:45:29 | kanzure: | libgen is extremely vulnerable |
| 03:45:56 | kanzure: | fenn: let's put it this way, i think that there are people in each of the major publications that would gladly dump their entire collections into this |
| 03:46:14 | zooko: | kanzure: so you're hypothesizing that there is enough aggregate willingness to pay to fund a big collection, but that if people pick and choose what to support then parts will fall through the cracks entirely. |
| 03:46:14 | kanzure: | let me clarify, there is observable evidence of this |
| 03:46:24 | kanzure: | oh, absolutely, yes |
| 03:46:37 | kanzure: | especially the falling through the cracks part |
| 03:46:49 | kanzure: | that's already happening, in the same way that libraries regret not archiving literally everything almost every day |
| 03:46:59 | kanzure: | s/libraries/academic libraries |
| 03:48:36 | fenn: | why has nobody made a tor worm |
| 03:48:44 | fenn: | makes all computers exit nodes |
| 03:49:03 | gmaxwell: | fenn: this isn't contributing usefully to the discussion here. |
| 03:49:11 | fenn: | okay |
| 03:50:03 | fenn: | i am primarily concerned with how to preserve access to scientific knowledge, not how to pay people for it |
| 03:50:43 | kanzure: | what do you mean by preserve- you don't have access at all |
| 03:50:48 | kanzure: | and paying for it might be how to make it happen |
| 03:56:08 | fenn: | "preserve" in a long now scenario; will papers be available in 100 years, 1000 years? access is more of a short term issue but may contribute to preservation in the long term |
| 03:56:36 | fenn: | the average paper has a low copy number |
| 03:56:50 | fenn: | there aren't very many copies of each paper |
| 03:59:30 | kanzure: | you want to optimize for number of distinct widely-distributed papers that each individually go away in different failure modes or failure scenarios, instead of "1 paper 100 times on a single ssd" etc. |
| 04:08:26 | zooko: | Goodnight folks. |
| 04:09:15 | kanzure: | zooko: don't feel discouraged, it just takes a while for me to read everything |
| 05:38:10 | justanotheruser: | justanotheruser is now known as yukitteru |
| 05:38:21 | yukitteru: | yukitteru is now known as justanotheruser |
| 05:42:59 | penny: | penny is now known as Guest27123 |
| 08:05:17 | wolfe.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:17 | wolfe.freenode.net: | Users on #bitcoin-wizards: andy-logbot Jokosh cbeams Guyver2 PaulCape_ bit2017 chris2000 wiretapped RoboTeddy [7] todaystomorrow Dr-G2 jaekwon_ fanquake eristisk NikolaiToryzin cfields coryfields super3 devrandom justanotheruser Kretchfoop rfreeman_w MRL-Relay NeueWelt SDCDev Sangheili mappum Guest3670 hollandais jbenet epscy bosma mortale iddo Flyer33 dzan shesek tacotime HaltingState kjj21__000 ericp4 DoctorBTC bitjedi Taek zenojis Cory sneak digitalmagus adlai EasyAt |
| 08:05:17 | wolfe.freenode.net: | Users on #bitcoin-wizards: nsh_ Anduck devsaturn Baz___ warptangent Greed Hunger- Transisto LarsLarsen optimator_ Starduster wizkid057 altoz kumavis heath andytoshi dgenr8 ebfull comboy arowser1 BrainOverfl0w copumpkin c0rw1n nuke1989 spinza waxwing fds4345 dansmith_btc samson_ gazab Graftec sl01 Iriez artilectinc go1111111 bbrittain BigBitz Apocalyptic emsid Starsoccer throughnothing warren tromp_ null_radix gavinandresen iambernie dansmith- Meeh pi07r GnarSith irc88 |
| 08:05:17 | wolfe.freenode.net: | Users on #bitcoin-wizards: forrestv kyuupichan stonecoldpat Nightwolf AdrianG Logicwax jgarzik mmozeiko fluffypony mr_burdell Eliel zibbo_ tromp berndj SomeoneWeird kgk firepacket Dyaheon myeagleflies wumpus @ChanServ lechuga_ abc56889 harrow so ahmed_ Gnosis Keefe pajarillo roasbeef ryan-c otoburb helo [Tristan] TD-Linux catcow danneu btc_ crescendo amiller yoleaux jrayhawk_ Muis michagogo @gwillen BlueMatt smooth petertodd bobke hguux _2539 gmaxwell sipa [\\\] livegnik |
| 08:05:17 | wolfe.freenode.net: | Users on #bitcoin-wizards: burcin Graet CryptOprah espes__ midnightmagic HM_ gnusha LaptopZZ [d__d] fenn artifexd phedny phantomcircuit paperbot superobserver Luke-Jr poggy a5m0 Alanius kinlo btcdrak Krellan nsh gribble CodeShark kanzure Fistful_of_coins weex_ asoltys lnovy Grishnakh nanotube pigeons K1773R |
| 08:25:22 | maaku: | maaku is now known as Guest70892 |
| 08:25:53 | Guest70892: | Guest70892 is now known as maaku |
| 10:26:08 | maaku: | why didn't Justcoin advocate rewinding consensus when the exploit was discovered? |
| 10:28:23 | Luke-Jr: | maaku: huh? wasn't justcoin killed by regulators, not exploit? |
| 10:41:48 | phantomcircuit: | maaku, because it's not a bitcoin exploit |
| 10:41:52 | phantomcircuit: | Luke-Jr, lol no |
| 11:01:30 | maaku: | phantomcircuit: right, that's why it would have actually worked. either manually reset consensus (as has been done before), or freeze the stolen funds and issue replacements |
| 11:02:17 | phantomcircuit: | maaku, freeze what funds, it's IOUs for less than existed |
| 11:02:41 | phantomcircuit: | there's nothing to freeze |
| 11:03:06 | phantomcircuit: | it's like if bitcoind just started randomly reporting all receive transactions in listtransactions as being 100x their real size |
| 11:07:28 | phantomcircuit: | maaku, only way to make it right is for those responsible to pay up |
| 11:07:33 | phantomcircuit: | which i cant imagine is going to happen |
| 11:08:56 | sipa: | maaku, phantomcircuit: why are you guys awake? |
| 11:09:29 | phantomcircuit: | sipa, because i got up at 2pm |
| 11:10:06 | phantomcircuit: | ima be super grumpy tomorrow though |
| 11:10:07 | phantomcircuit: | :/ |
| 11:10:14 | phantomcircuit: | "tomorrow" being today of course |
| 11:56:31 | cbeams_: | cbeams_ is now known as cbeams |
| 12:26:16 | penny: | penny is now known as Guest27453 |
| 13:31:56 | pigeons: | maaku: there's no exploit. its 100% justcoin deciding to handle people's money without knowing what they are doing. they credited people's account's with the full amount they tried to send |
| 13:32:30 | pigeons: | on partial payments, even theough the nodes modified and their new balances clearly show what was actually modified, and its been like that since the beginiging |
| 13:32:44 | pigeons: | and then they let people withdraw the fake balances they credited them |
| 13:33:37 | pigeons: | well yeah an exploit against justcoin's horrible implementation |
| 13:34:15 | pigeons: | then lots of excuses and misdirection after something bad happens is telling |
| 13:38:13 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 13:50:38 | contrapumpkin: | contrapumpkin is now known as copumpkin |
| 13:51:22 | penny: | penny is now known as Guest51192 |
| 14:22:41 | phantomcircuit: | pigeons, https://github.com/ripple/gatewayd/issues/186 |
| 14:22:47 | phantomcircuit: | that seems pretty clear cut |
| 14:40:39 | stonecoldpat: | Eliel: regarding block convo yesterday, i don't think there would be a great orphan rate - as you have the majority of the network working with you to produce the next block - and you could choose 20% of the network to stale mine, which makes it unlikely that they would produce a new block before the next one |
| 14:42:28 | Eliel: | as long as the orphan rate increase is noticeable, miners are incentivized to fix it |
| 14:45:51 | stonecoldpat: | but if you were able to even just cut off 5% of the mining network, it may not actually increase the orphan rate and would be a victory |
| 15:00:50 | pigeons: | phantomcircuit: justcoin didnt use that system, gatewayd |
| 15:01:32 | pigeons: | they were just idiots. seems the ripplelabs code causes problems as well |
| 15:02:31 | pigeons: | seems rippleabs shouldn't be writing code that handles people's money either :) |
| 15:59:19 | jgarzik: | tromp, https://twitter.com/jgarzik/status/527851031531880448 |
| 16:07:29 | zooko: | ☺ Cuckoo PoW |
| 16:08:50 | tromp: | thx for the pointer, jgarzik |
| 16:09:18 | sipa: | * sipa imagines a cuckoo saying "pow! pow! pooooow!" |
| 16:11:15 | zooko: | I'm currently planning to use Cuckoo PoW. |
| 16:11:21 | zooko: | But, I can't talk about that right now because I need to go meet with my wife. |
| 16:11:45 | jgarzik: | hehe |
| 16:11:48 | sipa: | oh, PoW is proof of wife? |
| 16:11:52 | jgarzik: | lol |
| 16:12:05 | zooko: | :-) |
| 16:12:39 | tromp: | jgarzik: answer to HoboJerk tweet: by default, yes, unless you involve graph size in difficulty adjustment |
| 16:44:34 | maaku: | maaku is now known as Guest54407 |
| 16:45:53 | Guest54407: | Guest54407 is now known as maaku |
| 16:58:38 | phantomcircuit: | jgarzik, that is at least a well written memory hard proof of work |
| 17:07:03 | tromp: | of course the memory hardness is only conjectured and cannot be proven |
| 17:10:13 | phantomcircuit: | true and there have been improvements to the original implementation that were significant |
| 17:56:00 | Aquent: | Aquent is now known as Aquent1 |
| 18:03:17 | Dizzle__: | Dizzle__ is now known as Dizzle |
| 18:21:49 | Arpolix: | Arpolix has left #bitcoin-wizards |
| 20:24:14 | berndj: | berndj is now known as Guest45347 |
| 20:38:40 | zooko`: | zooko` is now known as zooko |
| 21:08:42 | berndj-blackout: | berndj-blackout is now known as berndj |
| 22:17:52 | bassguitarman: | bassguitarman has left #bitcoin-wizards |