brainstorming part 2:

client pre-pays by funding a bitcoin address in advance, if they know the purchase price, and then simply sends the private key in the request (use HTTPS )

eg. http://server.com/secret_info?bitcoin_private_key=5fiwejwoefjwiewefmfiweiwjcewjmiejwifjeijwoewjioejiow

server then sweeps the key, checks it is the required amount, etc and sends the info

it's nothing but an idea at the moment, but take blockexplorer just as an example.

they provide an api to get various info, such as the 'received' amount of an address:

http://blockexplorer.com/q/getreceivedbyaddress/1A8JiWcwvpY7tAopUkSnGuEYHmzGYfZPiq

however, they also ask people not to query it too often, because of server resources, etc.

if such a service were paid for, it could help pay for server resources/profit for the api developer.

eg. http://blockexplorer.com/q/getreceivedbyaddress/1A8JiWcwvpY7tAopUkSnGuEYHmzGYfZPiq?payment_key=5fji23892u3dfj389kfjw8jij23fj2ifj2323f829jf82j3fffji

if payment_key is invalid or doesn't contain enough bitcoins, die(); else sweep the key and output the requested info.

there are millions of api's out there... some that you have to sign up for and pay a monthly subscription fee, some that currently have no subscription option but limit the number of requests.


pretty much any api you can think of could use this system... off the top of my head, let's say there's an api for a 'daily joke', where each joke costs 0.00001 btc, or a certain fx chartist might charge 0.01 per up/down/hold prediction.


edit: also a server could easily provide binary data for a given request, eg: http://pornsite/hotvideo.mp4?payment_key=5fji23892u3dfj389kfjw8jij23fj2ifj2323f829jf82j3fffji

yeah i was thinking something along those lines too, except using an api key that is given to you on your first request...

if you were going to use the same service more than once, you could pay up front for many requests, and the output of the first request contains an api_key for use in all the follow-up requests.

each call from then on might also output a summary of your remaining balance, etc.

Well, actually... If you get that API key, it has to be delivered via public channel (or maybe via SSL). If you use the bitcoin address as the API key, there is no that problem.

However the problem with using that method is, that with bitcoin software often you don't have access to the public keys (web wallets), and also, it is usually nontrivial to figure the public key any way, so it is not very user-friendly...

Oh, regarding the TOS issue: If you say the first 10BTC are the fee for regulatory measures, this could even be used in combination with TOS enforcement. So the user may get his 10BTC deposit back within 2 weeks at any time when cancelling his subscription. To have the service simple in this scenario though, the returning address should be given along with the first subscription as otherwise people would try to redirect the refund. Actually a refund mechanism wouldn't be that bad anyway.:

request: {
  "secret":"12abb9eb-959a-4ada-bee2-b6d6539b9dc7",/some uuid
  "upload":"some image data"/the actual api call
}
answer: {
  "error":"unknown secret",
  "message":"Please use the register method to pay with BTC or register for an API key at www.server.com where you can pay with paypal"
}
request: {
  "secret":"12abb9eb-959a-4ada-bee2-b6d6539b9dc7",
  "register":"1u1e6DUsZ7rwX6UrkHqSz1Gs6oKnVCLkTPx"
}
answer: {
  "fund-address":"1Gs6oKnVCLkTPxu1e6DUsZ7rwX6UrkHqSz"
  "message":"please charge the fund address + 10BTC deposit"
}

// fund the address ...

request: {
  "secret":"12abb9eb-959a-4ada-bee2-b6d6539b9dc7",
  "upload":"some image data"
}
answer: {
  "result":"2.5MB uploaded",
  "api-balance":"1.0012"
}
answer: {
  "error":"funds depleted",
  "fund-address":"1Gs6oKnVCLkTPxu1e6DUsZ7rwX6UrkHqSz",
  "message":"please fund or request a return of your deposit with a call to returnDeposit"
}
request: {
  "secret":"12abb9eb-959a-4ada-bee2-b6d6539b9dc7",
  "returnDeposit":""
}
answer: {
  "result":"1.0012 sent to 1u1e6DUsZ7rwX6UrkHqSz1Gs6oKnVCLkTPx. The deposit of 10BTC will be sent there within 10 days. Review pending.",
  "api-balance":"0"
}

... hmm ... makes sense. There should not be a big breach of privacy by sending the paybackaddress with every request so essentially the $secret could require to contain a valid bitcoin address but as long as this is found, any extension to the string could be optional for those that prefer to reuse their addresses. All others should be fine with using only an address.

omg ... so the api could be abused for money laundering. I put in tainted coins and trigger payback immediately. But that's not an issue of the api as the provider can make sure to return the potentially tainted coins to their source. But yeah, every service dealing with bitcoins can be abused in a similar manner. I'm only afraid that in the end bitcoin will be less anonymous than anything we know today.

There is a service I would like to see that might tie in with this.  Just before processing a customer's credit card for an online transaction, I would like to be able to cross reference the customer's card number against a global "chargeback blacklist".  If the database returns a match, indicating that this card number has been charged back against some other company in the past, I want to be able to refuse the transaction (or force the customer to use another payment method, such as Bitcoin).

Presumably, this service would also enable me to report cardholders who have charged back against us to have them added to the database.  To avoid the security risk of sharing credit card numbers, each lookup could be performed based on an MD5 or SHA256 hash of the customer's credit card number.

At least partial anonymity for the business would be somewhat important for this service for two reasons: 1) Many businesses might not be comfortable revealing sales volume based on the number of lookups performed; 2) The credit card industry (Visa/MC) might not take too kindly to merchants who screen their customers like this.  The general position that the card industry takes is that the merchant may do nothing to discourage the customer from issuing a chargeback (or to hold the customer accountable for chargeback fraud after the fact).

Many of the online merchants my company works with lose about 1-2% of their gross sales to charge backs and related fees.  We would gladly pay a large portion of any amount a service like this could save us.  The only condition is that it would have to actually be effective -- at least to some degree -- so it would need enough merchants participating to build up enough data to make it worthwhile.

maxmind only does heuristics based on ip, etc

Ok