Le 28/04/2014 10:21, bin.e...@gmail.com a écrit : > I'm interested to hear what people think. Is there anything obvious I > have missed?
It seems to me that it doesn't scale well with the number of files stored by Alice: the more files she wants to store the more bounties she'll have to issue. If trying to store small files you may hit problems with dust too. I think this kind of compensation system would end-up being limited to occasional long-term large file storage. I've not yet received a reply to my previous mail regarding duplicate shares so I'm not sure of the extent of the problem (there's always a window after a repair where duplicate shares can exist) but as you generate a payment address for each share one of the store nodes having a duplicated share won't get paid which isn't fair (as it was Alice client which generated the duplicate). Another problem is that Alice doesn't know if someone will actually claim the bounty : there will have to be a mechanism to keep track of unclaimed bounties. Unclaimed bounty wouldn't necessarily mean that the share isn't properly stored as the bounty claim is optional. This is linked with a problem I would have with the system: I would prefer to be able to configure my client to use storage nodes which expect compensation to have a more reliable storage. The bounty mechanism wouldn't work for me : I'd prefer to be billed by each store node and reuse the same kind of verification process (hash of nonce + share content) to verify actual storage before payment. Which leads to my last question : I'm not sure about your goals with a zero-knowledge compensation system. Which knowledge do you want not to be published and in which cases would it be useful to avoid it being published ? The automated part is obviously useful but the zero-knowledge one isn't clear to me. Best regards, Lionel Bouton _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
