Tahoe LAFS + cryptocurrency compensation system
Lionel Bouton
lionel-subscription at bouton.name
Mon Apr 28 11:23:34 UTC 2014
Le 28/04/2014 10:21, bin.echo at 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
More information about the tahoe-dev
mailing list