I was looking for official web API to operating with Bitcoin system, but found nothing.
Thank you in advance!
If you're fine with securing and running your own Bitcoin server and interacting with that, there's a guide at https://en.bitcoin.it/wiki/API_reference_(JSON-RPC). But if you're not comfortable securing your own instance of bitcoind, then you could always use a third-party service like Blockchain.info's API.
Please be aware that hackers are particularly targeting servers and websites that they think probably hold bitcoin. If you're thinking of launching a Bitcoin service, take a lot of time to educate yourself about the services that have lost their users' funds and what they did wrong. Take a look at Blockchain.info if you want to see a Bitcoin web service implemented well. Their servers never hold private keys "in the clear", so bitcoin cannot be stolen from their users if their servers are ever compromised.
Update: If you are building a Bitcoin service that holds bitcoin for users, the current "best practice" (circa June 2014) is to generate a hierarchical deterministic wallet using a random string of words as a seed and encrypt it client side with the user's username and password. At that point it's safe to send to the server for storage. The user should be shown the seed used to generate their HD wallet and prompted to write it down and store it somewhere safe. Without this string, it will be impossible for them to retrieve their wallet in the event they forget their username or password. When the user logs in later, the client-side code should grab the encrypted wallet and decrypt it again client-side. All operations requiring a decrypted wallet, such as signing transactions, should be done client-side. The server should never be exposed to the wallet "in the clear."
Related
As you may know the BLPAPI core developer guide (https://data.bloomberglp.com/professional/sites/10/2017/03/BLPAPI-Core-Developer-Guide.pdf) is not very intuitive and I was not able find a way to connect and authenticate without using the Bloomberg Anywhere Application.
I'm currently looking to develop an application that will run automatically on its own everyday at a specific time and would like to have this application to authenticate itself with Bloomberg and connect to the API.
Many thanks.
Justin, authenticating against the BLP API requires one of a few options to be in place. If you're only considering something around the Bloomberg (Professional) Terminal then you need to have a valid 'token' in place. When you light up a Bloomberg Terminal it creates a token and makes a BLP API 'delivery point' available on localhost:8194. When you log out of the Terminal the token remain valid and then delivery point remains intact. The token gets invalidated in two circumstances, either timeout (not even sure it will last overnight), and, the Bloomberg user logging in somewhere else (including on the Bloomberg phone app).
I should also say, that your application use case is constrained by licensing, in that you can only write display applications (as defined by exchange rules).
What some Bloomberg customers resort to if they have challenges around 24/7 applications, and, only have Bloomberg Terminals, is that they buy something called a Server API (SAPI). It allows a client/server pattern to be developed whereby the server portion can login in with its own credentials (application name), and, the client portion authenticates with the Terminal token/user. So, you could write the server component collecting data 24/7 but only delivers the analytics/results, etc when the Bloomberg Terminal users logs in.
If you're looking for something a little more systematic/autonomous then as a customer you should look at the Bloomberg Enterprise products such as B-PIPE, where the above need not apply, and you have a much more liberal accommodation of patterns.
As with all things finance, the devil is in the detail.. and depending on whether you're looking at exchange traded data or OTC, various rules and fees will apply.
Good luck
I want to make a desktop application which will need to use a 3rd party REST API to get information. However, the number of requests is limited by the API Key. If I use one API key for all users, the request quota will be exhausted really fast. Now, is it standard (and legal) to make each user sign up for his/her own API key? How are API keys used in context of open-source projects?
To generate the API key, I want to make a sign up form within the application, where the user puts in his/her information and the application sends those information to the 3rd party website to get an API key. Does that sound right?
In general the use of an API is limited to the requests from one machine and not to the API key most of the time.
Again depending of the type of third party services you are using, but the requests to the service should be established by the client not the server.
For example if you want to know geographic coordinates from a specific place, but obviously you can't ask the user directly for GPS coordinates. So you implement the Google Maps Javascript Library into your app which requests the Google API for the coordinates to the human readable address and returns it to the client. This in turn sends the data to your server.
In this way your server never comes into contact with the third party service.
If you have sensitive data or data which shouldn't be manipulated by the user you have to request from your server directly of course. But take a look into the documentation of the service before hack something together which isn't in the intention of the service provider.
Never ever try to outwit a service provider. They will detect your inappropriate use and block you for all time!
I am using the standard paypal developer API (NVP) to get current inventory levels:
https://api-3t.paypal.com/nvp?METHOD=BMGetInventory&VERSION=95.0&USER=____&PWD=____&SIGNATURE=____&HOSTEDBUTTONID=_____
But, I have a concern... If the api is enabled and the key is compromised somehow, what is the worst case scenario? For example: it looks like it is possible to send payments using the API. Is there a second tier of verification of payments that happens outside the API?
I have spent around 30 minutes researching the topic without any clarity in terms of what kind of financial damage could be done if an api information is compromised.
If your PayPal API credentials are compromised then someone can make API calls on your behalf. This includes sending and/or withdrawing money from your account.
There are some ways to limit the permissions of a PayPal API credential on the pages where you set the credential up, so you might be able to create a key that is somewhat less dangerous. It has changed over time so I can't offer details; google and/or log in to your account and look.
And yes, PayPal has lots of fraud detection that it runs internally on payments, but they have no legal responsibility to figure out that your API has has been stolen and I would strongly recommend not relying on them to save your bacon in such a case.
Protect your keys, especially ones with access to your money.
We're building a multi-tenant SAAS web-application. Our tenants want the option to accept credit card payments for the various products that we allow them to market through our application. To support this we will require that the tenant has their own Braintree account. The tenant provides us with their Braintree API keys through our app. We then use those API keys to interact with their Braintree account on their behalf (card storage, card verification and basic transactions).
This model is the same as the model used by the existing Braintree customers WooThemes, Goodsie, TutorTrove and many more.
We need to record the tenant's API info (merchant ID, public API key and private API key) for this all to work.
My questions are:
Can we simply store this information in our application database?
Does storing this information affect the PCI/DSS scope of us or our tenants?
If we can't store the information in raw form, what is an appropriate storage form?
Note: we have contacted Braintree directly with this same question, but we didn't think it would hurt to get other opinions as well :).
Cheers,
Sam
IMHO, Please note that you will be [if not, should be] having tenant based crypt keys [each tenant can configure their own crytographic algorithm and the keys => SAAS Cusomization], Please do encrypt the AuthorizationId using the tenant specific keys and then persist in the database. These kind of sensitive data should be secured and you should have a note stating that you are maintaining these keys in the database so that the tenant's can opt out if not required and manually enter the key whenever required. This will ensure safety. By the way is your application using SSL.
Please do share your thoughts on this suggestion
So Braintree responded to this question with:
So long as your system is PCI compliant, and your merchants are aware
that their API keys are stored on your server, then you should be
fine. How you store the integration API keys is completely up to you,
and [we] don’t really have any best practices to offer.
So, it doesn't seem like this case affects the PCI/DSS scope of our product, and it seems we are free to choose an appropriate way to store the private API keys that we obtain (saravanan's suggestion is one possible option).
I need to create an application that can accept BitCoin donations. I will have clients sending the data and a server to collect the results. Now, I have my own BitCoin account (on http://ww.MyBitCoin.com) but how would I transfer coins automatically from the client to my server where it will then be added to my account?
I'm not certain what you're asking here.
You want your application to send coins from a remote machine to your server? Due to the nature of bitcoins, this isn't possible. What you can do, however, is ask for donations, and give out your receiving address, which is almost like an account number at a bank. There is a page at http://www.weusecoins.com/ that will tell you how to get a receiving address, I highly recommend reading that site.