How do you solve the Sybil problem when determining reputation?<div><br></div><div>It's easy to forsee a network of Sybils concocting elaborate false histories about their excellent trading relationships. They then put out some awesome looking contracts, get suckers to accept them, host files for them, never pay, and disappear.</div>
<div><br></div><div>Until you have that secure reputation system in place, it's hard to treat storage service as a fungible commodity.</div><div><br></div><div><div class="gmail_quote">On Mon, Jun 11, 2012 at 6:04 PM, Jack Byer <span dir="ltr"><<a href="mailto:ftn768@gmail.com" target="_blank">ftn768@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(This is a cross-post from: <a href="https://bitcointalk.org/index.php?topic=86384" target="_blank">https://bitcointalk.org/index.php?topic=86384</a>)<br>
<br>
<br>
<br>
A market mechanism for buying and selling hard drive space would look<br>
a lot like the commodity markets. If you express a contract in a<br>
standard form they can be traded on an exchange to achieve price<br>
discovery. The following is not a complete specification but just an<br>
example of how such a system might work.<br>
<br>
Contract trading could be done on #bitcoin-otc or a similar platform<br>
(including the reputation function). Contracts will be priced in<br>
bitcoins. Storage is expressed in blocks of 1 MiB and the base time<br>
interval is one increment of the Bitcoin block chain.<br>
<br>
Block servers (nodes that sell space) can list the contracts they are<br>
willing to accept in human and machine-readable form as something like<br>
this: "BLOCKSTORAGE,O,10,10000,144,0.001,0.0005,0.00025"<br>
<br>
This means that the node is offering (O) to contract with any node<br>
with a reputation of 10 or more. Up to 10000 blocks are available for<br>
144 time units. The total cost of the contract is 0.001 BTC per block.<br>
Of this total cost 0.0005 is due up front and 0.00025 is due at the<br>
completion of the contract. The remainder is due in periodic intervals<br>
(perhaps as often as every time increment).<br>
<br>
When a node that is looking to sell storage can express the contract<br>
it is looking for as a bid (B). It could either work as both the block<br>
server and the client can scan the order book to look for a matching<br>
contract or the exchange can handle the matching. There would need to<br>
be a means to express what should happen to the data at the end of the<br>
contract. It can either be deleted (the client no longer needs it) or<br>
it can be transferred to another block server or it can be returned to<br>
the client.<br>
<br>
At the end of each contract the client and the block server both leave<br>
feedback on each other which will either increase or decrease their<br>
respective reputations. Block servers with high reputations will be<br>
able to charge more up front because the clients can be more confident<br>
they will actually be able to get their data back at the end of the<br>
contract. Clients with high reputation won't need to pay as much up<br>
front because the block servers can be more confident they will be<br>
paid at the end of the contract. In general a higher reputation will<br>
lead to better prices for both a client and a block server.<br>
<br>
The client should have a method of verifying that the block server<br>
actually retained the data instead of just tossing it into the<br>
bitbucket. One possible way to do this is to periodically transmit a<br>
block number and two offsets and ask for the hash of the data between<br>
the two offsets. The client could pre-select this verification blocks<br>
before transmitting the data and have enough hashes stored ahead of<br>
time for the number of verification it expects to need.<br>
<br>
This is just a rough draft and probably still has holes that need to<br>
be filled in but how does it look as a basic outline?<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a><br>
<a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Tony Arcieri<br><br>
</div>