Topic: Implementing Blockchain API - Help me figure out which implementation is better? (Read 632 times)
February 19, 2014, 02:52:15 AM
You know, I've written network engines for games and stuff, but I've not yet looked into web sockets. I'll have to look into that tomorrow. I know there are some browsers that don't support it, so I should still have a fallback, even if I go that route. Unless... well, why don't you tell me how you would/do use it, and maybe I can get a glimpse of how I should be doing things.
February 19, 2014, 12:48:38 AM
You're right! Thank you for bringing that to my attention. The functions for creating addresses or checking status requires a main password, but not a secondary. (All transactions require both.) That certainly helps make me feel better about using the Wallet API.
Much obliged, friend!
Much obliged, friend!
Are you 100% determined to use the blockchain api? If you use bitcoind, both use cases are easy.
If you really, really want to use the blockchain api, you can create the addresses locally, then monitor them with the blockchain websocket API: https://blockchain.info/api/api_websocket
February 18, 2014, 09:41:16 PM
You're right! Thank you for bringing that to my attention. The functions for creating addresses or checking status requires a main password, but not a secondary. (All transactions require both.) That certainly helps make me feel better about using the Wallet API.
Much obliged, friend!
Much obliged, friend!
February 18, 2014, 07:38:21 PM
I believe you can create a secondary password but I might be wrong. Now that I opened my mouth guess I owe it to you to verify one way or the other.
On edit:
Under account settings > passwords
My understanding is this encrypts the private keys with the secondary password. Someone would need this password (which server won't have) in order to either use blockchain.info to send coins or to decrypt the private keys in the backup if they obtained that.
Of course, do your own due diligence, verify independently, you are dealing with money, all that good stuff.
On edit:
Under account settings > passwords
Quote
Second Password
You may optionally set a second password which will be required when you send funds from your account. For large wallets your browser may become unresponsive for a few minutes when changing this option.
You may optionally set a second password which will be required when you send funds from your account. For large wallets your browser may become unresponsive for a few minutes when changing this option.
My understanding is this encrypts the private keys with the secondary password. Someone would need this password (which server won't have) in order to either use blockchain.info to send coins or to decrypt the private keys in the backup if they obtained that.
Of course, do your own due diligence, verify independently, you are dealing with money, all that good stuff.
February 18, 2014, 07:18:02 PM
I believe (been a while since I look at the API) that you can create limited API keys so the server would only have the ability to execute API calls not unlock or spend the wallet.
I've not seen anything like this in the documentation, which asks specifically for the "main My Wallet password." The "Passwords" section in Blockchain doesn't seem to indicate having multiple passwords to access the API, either.
If you happen to find what you recall, please let me know! That would make me much more secure in putting those passwords on a server.
February 18, 2014, 06:54:39 PM
Your con on the later may not be 100% accurate. I believe (been a while since I look at the API) that you can create limited API keys so the server would only have the ability to execute API calls not unlock or spend the wallet.
Due your own due diligence on that blockchain may have made changes but it is worth investigating and if not true that removes that con.
Due your own due diligence on that blockchain may have made changes but it is worth investigating and if not true that removes that con.
February 18, 2014, 06:47:32 PM
The two things I want to do seem very easy.
1) Create an address on-demand.
2) Monitoring the transactions on this address (amount + confirmations, specifically).
This can be done with the Receive Payments API by creating a forwarding address and listening to callbacks.
Pros: Anonymous, doesn't require a My Wallet account, and no credentials are stored on the server (potential security risk).
Cons: Callbacks happen only once every ten minutes, and there's no way to actively check the status of transactions.
This can also be done with the My Wallets API using the Create Address and Get Address Balance functions.
Pros: Active polling means I can check whenever I want and don't have to rely on callbacks (sometimes a security concern).
Cons: I would need to include my Wallet Main Password (but not the Secondary Password) on the server so it can make the function calls. Get Address Balance doesn't tell me how many confirmations it has, only whether or not it has the required number of confirmations (a function parameter). (It's nice to show customers: "You have 3 of 6 required confirmations.")
So, help me talk it through and figure out which of these two implementations is better? Thanks.
1) Create an address on-demand.
2) Monitoring the transactions on this address (amount + confirmations, specifically).
This can be done with the Receive Payments API by creating a forwarding address and listening to callbacks.
Pros: Anonymous, doesn't require a My Wallet account, and no credentials are stored on the server (potential security risk).
Cons: Callbacks happen only once every ten minutes, and there's no way to actively check the status of transactions.
This can also be done with the My Wallets API using the Create Address and Get Address Balance functions.
Pros: Active polling means I can check whenever I want and don't have to rely on callbacks (sometimes a security concern).
Cons: I would need to include my Wallet Main Password (but not the Secondary Password) on the server so it can make the function calls. Get Address Balance doesn't tell me how many confirmations it has, only whether or not it has the required number of confirmations (a function parameter). (It's nice to show customers: "You have 3 of 6 required confirmations.")
So, help me talk it through and figure out which of these two implementations is better? Thanks.
Jump to: