BITDEPOSIT: DETERRING ATTACKS AND ABUSES OF CLOUD COMPUTING SERVICES THROUGH ECONOMIC MEASURES
Jakub Szefer and Ruby B. Lee – Princeton University
Extending the possibilities of the Hashcash protocol to encompass Bitcoin as a deposit-based accountability platform for cloud computing services, Jakub Szefer and Ruby B. Lee have offered up a [potentially] powerful idea.
The premise of the paper is as follows: free cloud computing services have significant abuse potential; requiring a proof of work–or in this case a micropayment to be refunded upon fulfillment of some predetermined condition–might deter such malicious activity. This is one realization of the Bitcoin contract.
Let’s see how this plays out. First, the payment must be initiated and processed:
“Before a user can use a service, he or she makes a digital payment to the provider. This is done via the Bitcoin network and does not require interaction with the provider yet. The amount required before service can be used will be specified by the service provider. Each provider can set his or her own level of deposit. Moreover, different users can be required to make different deposits (e.g. a new user will have to make a large deposit, while a returning user will make a lower deposit). The payment is made in the Bitcoin network and is tied to the user’s public key, V K.”
...
“Once a payment has been made, the user contacts the service provider to initiate a service. The user provides the public key that was used to make the payment (or the service provider could have cached a key for returning users). The V K will be later used by the service provider to verify messages sent by this user – V K is essentially an identifier that ties the user to the payment.”
…
“Upon receiving a request, the service provider needs to make sure the payment, i.e. the deposit, has been made. The provider checks with the public Bitcoin blockchain to see if the transaction of the required amount has been made to the provider. If such transaction has been recorded, the user has made a payment. The provider can use the blockchain to also check that the public key, V K, provided by the user matches the one in the Bitcoin blockchain.”
So just to get the service up and running, a significant amount of back and forth between the user, service, and the blockchain must occur. This seems a bit clunky. Let’s keep reading.
“Once the user’s payment and public key have been verified with the Bitcoin network, the service can be run… The service provider needs to monitor the user’s actions and detect any attacks or abuses… If no attack or abuse was detected, the user is repaid back their amount of the deposit.”
Hmmm, seems like that could be a computationally-intensive process for certain types of services… especially when distributed across large scale operations. The authors raise their own issues as well (size of the deposits, excessive transaction costs, breaking of pseudoanonymity, public key reuse, and reliability of deposit returns):
“The value of the deposit is a subjective quantity that needs to be determined by the service provider. Large deposits may detract some users, while deposits that are too small will not be effective.”
…
“Our proposed scheme relies on users and service providers exchanging small amounts of digital money. The BitDeposit scheme actually repays the users less than they paid because of the transaction costs. While the costs are very small, they are non-zero.”
…
However, when the scheme is used with any service that requires or obtains information about the user (e.g. user’s friends’ e-mail addresses that they use to communicate with) the service learns some information that can be potentially used to break the pseudonomity. This breaks the pseudonomity of the public keys in the Bitcoin network for the user.”
…
A related issue which also concerns the public keys of a user is the key reuse. To be able to tie the transactions to a user, the same key used in the Bitcoin network needs to be used to sign messages later sent to the service provider.
…
An unanswered challenge is also how to make sure the service provider eventually returns the deposit (if there was no attack or abuse). For large service providers, reputation could be used so users would likely know that it is a good provider and that their deposit will be returned.”
To avoid excessive transaction cost, I propose one amendment to the proposal: it appears that such a service would be most suitable if the interactions did not occur between the user and the service-provider directly. Instead, a third party could be involved who would act as a middle man. Using the various contractual conditions possible with colored coins (but applied to this non-color use case) the users could store their deposits on this middle man’s server, and if and only if they abused the service (and set one abuse condition to true) the deposit would be sent to the service provider.
If this middle man could aggregate enough businesses under its roof (Gravatar, for example), [responsible] end users would only suffer transaction costs during the initial funding process. The end user would be required to store sufficient funds with this service to fulfill all their cloud-computing needs. They could extract the funds whenever they please. If the user has no access to Bitcoins a proof of work model could be substituted.
To address other complications raised by the authors: This entity could payout deposits in dollars or Bitcoins depending on the customer’s preferences to avoid market fluctuations. Depending on the service being used, personal information can be withheld from the cloud computing service to enforce the psuedoanonymity of the Bitcoin network.
All in all there is definitely some potential here; regardless, I don’t see this become a reality in the immediate future. While the implementation on the client side is relatively straightforward, standardizing the checking/reportage of abuse cases might be a bit more difficult (depending on the service). Definitely something for us to keep an eye out for.
My question to you guys is this: what is the most feasible implementation of this 'middle man'? As a 3rd party service or as an addition directly to the bitcoin protocol (which I'd be happy to code into an alt-chain for testing when I can manage) - obviously some qualities to this could not be hardcoded into bitcoin (e.g. fiat payout, etc...). Ignore those if you have to.
Original post:
https://btcgsa.wordpress.com/2013/06/11/hashcash-bitcoin-style/Source:
https://www.princeton.edu/~szefer/papers/acc2013.pdf
