accounting using bitcoins

[davidsarah]

A ​post on the Bitcoin forum pledges a bounty to:

Create an accounting system that will incentivize people to contribute HD space and make it easy to pay bitcoins for storage of data.

Presumably, this would involve a storage client being configured with an URL for a Bitcoin ​JSON-RPC API server, which implies access to a Bitcoin ​account. When it needs to send a share to a particular server or renew a lease on that server, it obtains the server's Bitcoin address and sends payment to that address using the API. (Alternatively, it has already sent payment and the transaction deducts from the amount it has prepaid.) The server similarly has an account and verifies that it has received payment before storing a share, or considering a lease to be renewed.

Open questions:

• who/what decides the rate at which bitcoins are used to pay for storage? (Perhaps each storage server can advertise its own rate, and that is one input to a more sophisticated server selection algorithm? But that sounds conplicated for an initial implementation.)

• can a client verify that a server is upholding its storage contract, rather than just sending money and trusting the server?

• are payments bound to particular transactions (storing a share or updating a lease), or are they bound to a connection between a storage client and server, and valid for any transaction on that connection?

• how can the accounting system be made general enough to accomodate bitcoins and other likely accounting schemes, without being overcomplicated?

• how do the Bitcoin-related operations affect performance?

The Python-BitcoinRPC library is ​here. (Sigh, yet another dependency.)

[davidsarah]

Another question:

• is it sufficient for a storage client to use coins from a single account? (This would require each independent user to run their own gateway and keep it inaccessible to other users.)

[alaricsp]

I have a proposal for how to implement this: ​http://www.snell-pym.org.uk/archives/2011/05/24/cloud-storage/

I don't know much about what Tahoe-LAFS expects from its storage providers, but I hope the hybrid client-assigned and hash-assigned ID scheme I came up with to meet the needs of my own Ugarit project would do for you guys too :-) Please comment on my blog post if not!

[davidsarah]

Open questions:

• who/what decides the rate at which bitcoins are used to pay for storage? (Perhaps each storage server can advertise its own rate, and that is one input to a more sophisticated server selection algorithm? But that sounds conplicated for an initial implementation.)

Perhaps we can reimplement ​this idea from MojoNation:

In early versions of MojoNation, users were required to set prices for any services their node provided. Most users had no idea how to choose prices, so the Mojo layer was rewritten to use a second-price rolling auction. Each node maintained a queue of incoming requests that had not yet been processed, sorted by a bid field contained in each request. Requests were serviced in order, from highest to lowest bids. This shifted the burden of pricing decisions from servers to clients: each user could set a price he was willing to pay for services, and his node would offer that bid in outgoing requests. This scheme was intended to create a simple feedback loop: if the system is responding slowly, increase your bid and if the system is responding quickly, decrease it.