Topic: Idea for a paid, anonymous api service. (Read 1874 times)

Ok

I'm afraid I just wouldn't have the time to devote to a sales effort on this.  I could, however, bring in all the merchants in our network.  Combined, we could probably flag a few hundred bad customers a month.  I can see that it would take a lot of merchant reporting to make this work though.

maxmind only does heuristics based on ip, etc

@BradZimdack I can build this very quickly and already started years ago. My problem was finding merchants and I'm not good with sales. If you want to partner and you do the sales and I do the programming and website, PM me.

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.

I really like this idea. We need a PHP library.

... 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.

Make the secret "$secret + $paybackaddress" then.

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"
}

subscribing.

I guess this should run in parallel to established services. Most API-keys I retrieved so far were not connected with a fee but with registration and signing to obey their rules. Not to make the data available to others, not to excessively use the data, not to push illegal data, etc and none of them was connected with costs.

Your scenario though is where you don't have rules where the service provider would want to lock out one API key for TOS violations. It would be a simple, read only service. Therefore I doubt there is any benefit of reusing API-keys when the bitcoin charge is depleted. As bitcoin is not well suited for micro transactions, it would be necessary to charge for many calls, so the API key would only be a token related to a charged account.

Why not allow the user to define the secret?

request:
{
  "secret":"12abb9eb-959a-4ada-bee2-b6d6539b9dc7", //some uuid
  "function":"tellMeTheFuture" //the actual api call
}

answer:
{
  "error":"funds depleted",
  "fund-address":"1Gs6oKnVCLkTPxu1e6DUsZ7rwX6UrkHqSz",
  "message":"0.0001BTC per call to the fund-address or register for an API key at www.server.com where you can pay with paypal"
}
{
  "result":"you will live long and prosper",
  "api-balance":"1.0012"
}

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...

Interesting idea!

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.

Actually I like the model where you deposit bitcoins to the server, and use them more. It can still be fairly anonymous - eg. your first bitcoin deposit creates your account, then later you can do requests by singing the request with your bitcoin public key you made the first bitcoin transaction.

Creating lots of these microtransactions is not that sensible, since there will be transaction fees in the future.

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

so what is it? a proxy service or something more?

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

i'm just brainstorming, none of this has been coded, thought through much, or debugged... i'm just typing it out as i think of it...

you send an api request to a certain web service, along with an optional postback url:

eg. http://server.com/secret_info?postback=http://client.com/receive_info.php

server then outputs something like:


client then sends 3.5 btc to the address given, and the server posts the secret info to the client's postback url as soon as it sees the transaction on the network (or as soon as it has a certain number of confirmations).

...............

alternatively, (for more client anonymity), if the client doesn't specify a postback url, the server simply outputs a key for use in a secondary request:


once the client has the unique key, it sends 3.5 btc to the address given, and then re-asks the server for the info:

eg. http://server.com/secret_info?key=afwiejowjeiwjefifjwioejfwijefijmwiejcoiw

the server then checks to see if the corresponding address has received the purchase amount (3.5 btc) and if so outputs the secret info:



no signup necessary, no ongoing api membership fees... just one-off payments for one-off pieces of info from the api.

one might pay blockexplorer/blockchain.info in this manner if they charged a tiny amount for each request

that way if they charged a certain price, they could allow requests to come in far more often, like thousands per hour.