--- Log opened Thu Sep 05 00:00:09 2013 04:14 < gmaxwell> a pigeonhole principal violator looking for funds: https://bitcointalk.org/index.php?topic=288152.msg1958077;boardseen#new 04:15 < gmaxwell> next week we're going to have zeropoint energy people. 14:31 < midnightmagic> hah, awesome. 14:31 < midnightmagic> uber-compression to the rescue 14:33 < midnightmagic> comp.compression.research FAQ needs to be resurrected I guess 14:34 < midnightmagic> "and yes, this game idea would itself be worth millions if you knew everything it entailed" 14:34 < midnightmagic> i love it 15:34 < amiller> now i'm working on a paper about a proof-of-storage puzzle 15:35 < amiller> a couple of high profile professional researchers are surprisingly interested in this and so i get to collaborate with them 15:35 < amiller> it's basically the use-knowledge-of-blockchain-as-mining idea 15:36 < amiller> only they're less interested in it being the blockchain data itself, they think of it as storing arbitrarily useful unrelated data like library of congress, or maybe random user data if a user is willing to put up a bounty for storing their favorite data 15:36 < amiller> it doesn't really matter because the construction is the same 15:37 < amiller> i'm focusing on basically what the optimal mining strategy is for a puzzle like this 15:37 < amiller> especially if you have an ssd or a hard disk, and if you try to outsource it to a centralized storage depot somewhere 15:37 < gmaxwell> amiller: I was trying to come up with a way where the payment in the block would be paid to the author of a proof of storage proof in order to frustrate outsourcing the proof but didn't come up with anything great. 15:38 < amiller> well we have two ideas 15:38 < amiller> one is just to rely on latency making it hard 15:38 < amiller> like outsourcing generally means having round trip latency 15:38 < amiller> and the more latency you have from selecting a nonce to learning the result, the more likely someone else will find an answer in that time, so it's bad for you 15:39 < amiller> especially if the number of iterations is set really high... but that's also bad for proof size 15:39 < gmaxwell> yea, well the latency potentially has other negative implications... like strongly favoring consolidation. 15:39 < amiller> i dont' think i like that approach over all 15:39 < amiller> it also means that an SSD is really ineffective 15:39 < amiller> er an HDD 15:39 < amiller> the other idea is to make the operation at each step actually be a signature 15:40 < amiller> therefore you either need to securely outsource / obfuscate the signing operation with your key 15:40 < amiller> or you need to give the outsourcer your key 15:41 < amiller> i like this approach better, but in any case it's interesting to experiment with the parameters and performance tradeoffs 15:41 < amiller> the main thing i'm interested in is 15:41 < amiller> since the random seek time is somewhat expensive in either case 15:42 < amiller> how much more efficient (in throughput) can you make it by having lots of puzzle attempts pipelined / in a batch 15:42 < amiller> so you can read one block of a file 15:42 < amiller> and service all the threads that are waiting on that block, basically 15:43 < amiller> i think it depends on the ratio of the inner state (one hash, basically) and the effective block size for the disk 16:06 < gmaxwell> amiller: yea, I've thought of making the pseudorandom permutation in the search a trap door, but I think that makes the proofs much bigger. --- Log closed Fri Sep 06 00:00:11 2013