Topic: Easiest way to accept BTC and test (Read 3535 times)

Thanks.  I had tried the following in the past, but it didn't work:

curl --user bituser --data-binary '{"id":"t0", "method": "gettransaction", "params": [c92d655f850a0feae01d785733a74e4d610fc07d0da4d7c086f363569f550ec8] }' http://127.0.0.1:8332/

I tried putting in quotes and it worked:

curl --user bituser --data-binary '{"id":"t0", "method": "gettransaction", "params": ["c92d655f850a0feae01d785733a74e4d610fc07d0da4d7c086f363569f550ec8"] }' http://127.0.0.1:8332/

That id might have to go in params

If you're going to hold just enough in the hot wallet to cover expected withdrawals, doesn't this imply that you are sweeping bitcoins from user accounts to your holding account and moving the bitcoins out of the holding account to your offline wallet?  If so, then I'm confused when you write that you "don't sweep those funds into the holding account..."  Can you elaborate?


I've been playing around with jsonRPCClient.php (from https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)) and getblock to get the information on the block identified by the block hash sent from blocknotify.  I've been trying to find the structure of the data returned by getblock and it seems to be similar to what Luke-Jr entered in his second code box at https://bitcointalksearch.org/topic/07-gettransactiongetblock-rpc-calls-89725.  Is this correct?  If so, then it seems that getblock can return many transaction IDs in the "tx" array.  If so, then it seems that one possible approach is to process each one of the transaction IDs to find the user accounts and number of confirmations and then update your database accordingly.  Based on what you wrote previously, it seems that you do not prefer to do it this way, but you prefer to query your database for users with unconfirmed funds and then call getbalance [account] [minconf=0] and getbalance [account] [minconf=4] on each user account and if the amount of BTCs is the same for both getbalance calls, then you update/indicate the user's BTC amount as all confirmed.  Correct?


I'm wondering if I can get by having both the RPC client and bitcoind RPC server on the same machine.  I assume that this is less secure than having the RPC client and bitcoind RPC server on different machines.  If so, do you know how much less secure it is or what the risks are?  Am I correct to assume that when you get a *notify on the bitcoind RPC server, it runs a curl command that invokes the RPC client which processes the data by running jsonRPCClient (https://en.bitcoin.it/wiki/API_reference_(JSON-RPC))?

Do you know the syntax for the curl command for gettransaction or getblock?  I tried the following:

curl --user bituser --data-binary '{"id":"t0", "method": "gettransaction c92d655f850a0feae01d785733a74e4d610fc07d0da4d7c086f363569f550ec8", "params": [] }' http://127.0.0.1:8332/

but i get an error:

{"result":null,"error":{"code":-32601,"message":"Method not found"},"id":"t0"}

Exactly.  We'll only hold enough in the hot wallet to cover expected withdrawls.  If we get a rush of withdrawals, users will get an error, and we'll be notified.  It's not the best customer experience but it should rarely happen, and it's better than losing a hot wallet.


We've tested millions of sendFrom transactions and no problems at all.  Our scaling plan includes not using it, though.  Instead, we'll maintain the local ledger.


Eventually, we'll sweep funds from the account the user deposits to, directly to the holding account and maintain their balance in the database.  Right now, we don't sweep those funds into the holding account because we're using the built-in account system with no problems.  Thousands of accounts and tens of thousands of transactions between accounts with no perceptible lag in our profiler.
We've always planned to move away from the account system because we've heard it isn't scalable.  We have most of that code written and tested, but have yet to see any scalability problems that would cause us to move away from teh account system.


blocknotify happens each time a block is found on the network.  That's the only time a confirmation changes on a deposit.  A confirmation is defined as a new block found that includes the transaction.  This happens on average every 10 minutes.  So your server gets a block notify every ten minutes, and checks only the accounts that have unconfirmed funds from a recent deposit.  Once a user's account has 100% of the balance confirmed by 4 transactions, we don't have to check them again on the next blocknotify.


Yea - that's SSL between the rpc client and the bitcoind rpc server.  If it's on the same machine, you may be able to forego ssl.  We have it enabled.

You're right that I should worry only about the minimum viable product and the easiest way to process bitcoins.  Just out of curiosity though, what do you plan to do when you get thousands of customers?

When you get a rush of users, then I assume that this becomes an issue only if they all want to withdraw bitcoins.  I assume that if your holding account runs out of bitcoins, then you can tell your users to wait as you manually move some bitcoins from your cold (which I assume is the same as offline) storage?


That's good to know.


According to tgerring's posting at https://bitcointalksearch.org/topic/bitcoind-create-accounts-via-api-300632:

I don't understand what you mean by:  "We don't do the sweep currently on the live site".  Can you explain or elaborate?


Let me reiterate what you wrote above to fully understand what you are doing.  You keep track of users (in your database) who have unconfirmed funds.  When a blocknotify comes in, you call getbalance for each and every one of your users who have unconfirmed funds, to find out if these users still have or no longer have unconfirmed funds.  For users who no longer have unconfirmed funds, you write into your application database to indicate this, so that your application can tell your user that he has more bitcoins to play with.  Do I have this right?

Don't the blocknotify come in quite often, especially if you have thousands of users?  I'm assuming that blocknotify will run every time there is a confirmation on each and every transaction for every one of your users.  There could eventually be thousands of confirmations on a transaction.  Here's a possible number of blocknotifies:
1,000 confirmations X 5 deposits X 1,000 users = 5,000,000 blocknotifies.  For each of these blocknotifies, you are checking all of your users with unconfirmed funds.  This means you can be running getbalance 2,500,000,000 times (5m X 500) if you have 500 users with unconfirmed funds.  This seems like a lot of processing.  Do I have this wrong?


When we launch, do we need to run SSL on mainNet (assuming mainNet refers to regular bitcoins)?  Why is SSL needed?  What data needs to be encrypted?


It's amazing how much less productive and wealthy our economies are due to all of the extra work and money we have to spend to protect ourselves from hackers, criminals, etc.  Also, the adoption of bitcoin would be much more widespread if it wasn't for these hackers and criminals.

lmao

We wanted withdrawals automated, so we don't use a watch-only wallet.


We solve the wallet backup problem by keeping a copy of the private keys in the database.  For now, we're using the account system with thousands of accounts and tens-of-thousands of transactions without issue.  We have a secondary ledger than uses walletnotify and blocknotify to stay in sync.  We still use the bitcoin account system as the place of record, but our side-by-side tests have been perfect so far.  We could move off of the built-in account system if we needed to.  But you asked the easiest way to do some testing - not the most robust 
FWIW, this is also our cold-storage strategy.  When a user logs in, we push funds from the holding account into their account so they can play.  When they logout, we move it back to the holding account.  Then, we only keep a percentage of the total funds in teh holding account to support the numebr of people on the site at any given time.  This means if we got a rush of users, we would need to turn some away.  If only that would happen 

I'm not familiar enough with the armory system to comment on their wallet.  Perhaps they create a large number of addresses instead of the 100 (default) created by the reference client?  Not sure...

That sounds about right.  Note that you can do all of that without writing any software.  *notify can just be echos to a text file.  Also, bitcoind is a commandline version of the api, so you can do bitcoind getinfo, or bitcoind listtransactions, etc. to test out the api.


We user sendFrom so they funds are removed from the users account, rather than the wallet.


Pretty close.  We create a new account for the user, then use walletnotify to watch for deposits.  When a deposit comes in, it's "unverified".
We then use blocknotify to watch for new blocks.  When a block comes in, we check the balance of the users account with 0 confirmations, then again with 4 confirmations.  The delta is their "unconfirmed" balance.
We don't do the sweep currently on the live site, but that's how we handle cold storage.

It's not obvious. 
You can call getbalance and pass in the number of confirmations you want.  So if a user has 10 confirmations on their first 1btc deposit, and 2 confirmations on their second 5btc deposit:
getbalance 0 confirmations = 6btc
getbalance 4 confirmations = 1btc
From that, we can calculate that they have a balance of 1btc, and an additional 5btc unconfirmed.

So then blocknotify is only used to say, "A new block was received, and users' confirmations may have changed." 
We just use it to trigger a re-check of the users that have unconfirmed funds.  If the confirmed and unconfirmed balances are the same, we can stop checking their account with each new block.

Only run on testnet.  There's no need to run on mainNet until you're getting close to launch. 
I'm happy to answer questions.  Just know that you're only getting one team's opinion.  There are a million ways to do things 



Virtual Keyboard and Mouse.  A well known bitcoin casino had their data center's maintenance site hacked.  Someone put in an order to have a VKM installed.  The machine rebooted and the attackers attempted to use the vkm to get console access.  Thankfully, the casino used full-disk encryption, so reboots required a manual password step. 
Attackers in this space are really, really clever.

It was suggested to me that when users withdraw, I should send bitcoins to users manually from an offline wallet.  I was thinking of using Armory to do this and to install an Armory Watching-only wallet (https://bitcoinarmory.com/about/using-our-wallet/) on the server.  Have you looked into this?  Did you use Armory's offline wallet for your "cold storage"?

Did you automate the sending of bitcoins to users?

I read up on https://en.bitcoin.it/wiki/Accounts_explained.  It states: 
What are VKMs?  Virtual Knowledge Managers?  What harm can they do?

We started with blockchain.  The experiences I mentioned above around lack of support and reliability led us to investigate something else.  We decided on our own wallet for three reasons:
1)  We already had the blockchain integration, which is basically the exact same as the bitcoind integration, so it was less work.
2)  We had a bad taste in our mouth about outsourcing that incredibly critical part of the stack. 
3)  We want local wallet performance.

Once you have the blockchain/bitcoin integration (again, they're basically the same), the effort of moving to a local wallet is:
1)  Install the client and configure it to run as a server (minimal work)
2)  Understand the security implications of having a local wallet, cold storage, etc.  You'll have security work with an outsourced partner as well, so I don't think this work is really incremental.


Yes, but we wanted a tighter integration with the network. We don't consider ourselves a merchant.  The goals are different.  We don't care about fiat prices, exchanging for USD, physical terminals and QR codes, etc.  Our integration is basically the "Pre-generating Bitcoin addresses" option in the document you linked.


Yes.  Here is a better article:  https://en.bitcoin.it/wiki/Accounts_explained
Having a local wallet and an account for each user lets you move money around between users in the system without incurring confirmation delays or network costs.  Depends on your needs, but that was critical for the head-to-head aspect of our games.



No, but it looks like a fine article.  Our technology stack is node.js on the backend.  There's a node-bitcoin package that we use to integrate with the json-rpc API.  We just used that and the Original API document you referenced above.


If you have the client installed, your bitcoin.conf should be in ~/Library/Application Support/bitcoin.conf.  If it's not there, create it and then you can use the following options to control the client:  https://en.bitcoin.it/wiki/Running_Bitcoin

For walletnotify, it's easy.  It just says that whenever a transaction hits the wallet (a deposit, for example), call your command line.  What we do is use curl to post the transaction to our node.js webserver, which then handles the transaction.

The address in the URL is a private address.  If you give that to someone, they can put it in their own URL and be playing as you, including withdrawing funds.

The public account ID is something you can share with others in public forums without fear of someone logging in as you.  In fact, our referral program uses the public ID as an ID to refer others publicly.



There are differing schools of thought on this.  The "purists" point to the fact that bitcoin's anonymity and plausible deniability come from the way it never re-uses addresses.  The "pragmatists" point that that it's a lot easier to re-use them in cases where anonymity isn't required.  I'm in the first camp, but for reasons of simplicity, MooCoin reuses addresses.  Each user has a dedicated address.


I was talking about the Bitcoin community - not the community on this board.
I guess it's harsh to call them unsavory.  Opportunistic is probably more accurate.  Sites that hold bitcoins, or credentials that have access to bitcoins, are a huge target for hackers.  The things that make bitcoin great, for example, anonymity, immediacy, virtuality, are also things that make it very easy to steal without repercussion.  Know that your server will be attacked, your faucet will be drained, your games will be botted, your service provider will let people in to your datacenter to install VKMs, etc.  All of these things have happened and will continue to happen.  Be prepared as you become the steward of the trust and currency of the folks on your website.

Thanks for your posting.  It is very interesting, as your experience is similar to what I'm trying to do.  Your suggestions sound very good.

To simplify our lives, we would rather use Bitpay or Coinbase.  Even though our game requires skill, there is still an element of chance, hence it can be deemed as gambling.  Therefore, Coinbase and Bitpay won't help us.  Am I correct to assume that your game is deemed as gambling and that's why you had to use bitcoind or Blockchain?

How much extra work was it to get bitcoind and wallet running on your server, versus Blockchain.info's API?

Have you ever looked at using MtGox or any of the "Merchant Services" (payment processors) listed at https://en.bitcoin.it/wiki/How_to_accept_Bitcoin,_for_small_businesses and https://en.bitcoin.it/wiki/Merchant_Howto?


When you say "bitcoin account system", are you referring to the "Original Bitcoin client/API calls list" (https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list)?

Did you start with this tutorial?:  https://en.bitcoin.it/wiki/PHP_developer_intro


I don't have bitcoin.conf on my Mac, but I do have bitcoin-temp.conf.  I do not have walletnotify or blocknotify in my bitcoin-temp.conf, but I found this:  https://bitcointalksearch.org/topic/how-to-use-walletnotify-203438 which explains how to use walletnotify, but it sounds complicated.

I checked out MooCoin.  What is the difference between the address in the personal URL and the public account ID?

Unlike MooCoin, our users are already registered with usernames.  Am I correct to assume that we should assign a different bitcoin address to each user for them to make deposits to, and re-use the address when the user wants to make subsequent deposits?  (I assume that when our users wants to withdraw, we should prompt him/her for his/her bitcoin address, store it and use it for future withdraws.)


The users on the bitcoin forums seem like they are trying to be helpful.  What are they are trying to scam or hack?

So we recently went through this when developing MooCoin.

Let me save you some heartache.

First, don't use the blockchain API.  You'll end up using it for a while, fighting with it, not getting support when it goes down, then moving to your own wallet anyway.  The API goes down all the time, and if you're accepting bitcoin deposits, their realtime address subscription websocket is REALLY unstable.  We spent weeks trying to get it running before giving up and moving to our own wallet on our own servers.  It's really not as hard as you think to do that.  Especially because I can help answer questions you might have since we just did it 

Second, start by really understanding the bitcoin account system in the reference client, and using it.  You may want to move away from it to an offline ledger at some point, but it's totally usable for an MVP.  It will simplify everything.  When you're reading about the account system, realize that you're the bank, and each of your players has an account. 

If you want a place to start, look at the walletnotify and blocknotify options in the bitcoin.conf.  Those will tell you when a deposit has come in to one of your addresses (accounts), and when you have confirmations of those deposits.

Use the testnet.  There are faucets out there that will give you testnet coins, and it's as easy as running your client with testnet=1 in your bitcoin.conf.  You're going to be doing SO many transactions that the network fees become expensive.  And, you're going to want to test a 50 BTC wager at some point and you likely don't want to mess that up on the main net.

Even if you don't build cold-storage capabilities at first, at least think through how you will do it in the future.  It has some architectural implications that you'll want to get right the first time to avoid re-working large parts of the app.

Go play around with MooCoin.  Check out what we did to get some ideas about what's possible.  We're happy to help. 

Lastly, and it pains me to say this, be careful who you trust around here.  The Bitcoin community is really turning a corner for the better, but there's still a large portion of people that are remnants of the bad old days.  Hacking attempts, scams, etc are rife in this community.  Just be careful.

Good luck!  The community needs some more cool and unique playthings amongst the rabble of dice games.  Go build something awesome and let us know if you need help!

Thanks,
The MooCoin Team

Well you will have a "cron" script that is cronned. But that same script can be called manually EXTRA TIMES and telling it to just check one address, the ipn one. You wouldn't listen the the ipn, just use it to call the cron script manually. Watch out for differences in confirmations between ipn and cron though.

For simplicity, you might want to assign one permanent address to each player. This will make it easier to cron, less queries. Second, even if you change it everytime, people will reuse, if not only the first time by sending 2 transactions. So using new ones each time doesn't give you an excuse not to check each one every time which increases queries. But yes, best practices says to use a new one each time.

Depending on how many players, you may hit blockchain api limits. Thankfully, you can transition to your own bitcoin abe at that time and still use the receive api.

When I wrote "cron", I was referring to your statement about cron:  You wrote: "Your cron would loop through all your player addresses, then loop through all their payments and make sure you got them all."  Aren't you referring to a cron script?  Why would the ipn trigger the cron script if the cron script is supposed to run every hour?

Why would I assign an address to players upon their registration on our site?  Assign the address to whom?  I don't know what you mean by "On registration you assign an address with the receive api".  My understanding of how the Blockchain.info's Receive Payment API works is this:  When my player wants to deposit bitcoin, I call the Blockchain API, providing my receive address.  The API returns a receive address (that belongs to Blockchain), that I show to my player, so that my player can send bitcoin to that address.  After the player sends bitcoin to that address, Blockchain forwards the bitcoin to my receive address.  The next time the same player wants to deposit money again, I call the Blockchain API again, providing my receive address, and the API provides another (different) receive address (which belongs to Bockchain), which I show to my player.  So, each time a player wants to send bitcoin to me, the player is sending to a different address provided by Blockchain.

IPN i mean the callbackurl.
By triggering cron I mean the cron script, a subset of it, not an actual cron.

No on player registration. The receive api forwards bitcoin, it doesn't store it.

Thanks.  You wrote "Your ipn would trigger the second part.".  What is ipn?  instant payment notification?  What second part are you referring to?  The "cron"?  If so, why would the ipn trigger the cron if the cron is supposed to run every hour?

You wrote: "On registration you assign an address with the receive api."  Are you referring to my registration with Blockchain?  I don't know what you mean by "forward it".

You would use https://blockchain.info/q/getreceivedbyaddress and loop through transactions making sure you got them all. Set it to a few confirmations.

Your cron would loop through all your player addresses, then loop through all their payments and make sure you got them all. Database is easy due to transaction ids.

Your ipn would trigger the second part.

On registration you assign an address with the receive api. But remember this address has to work forever in case they store it, so forward it knowing that.

I am talking about the "callback url" field at the blockchain.info (as you mentioned... ).
I worked with blockchain for a while and I cant tell you exactly how often they fail to send notification but it happens sometimes, so you can't trust it for 100%.
using bitcoin API calls it is more complicated but you can try to look for open source implementation of higher level (C# maybe..) if you don't want to implement it by yourself or buy from some one for a few bitcoins maybe... and use it.
Or at least try to use some other service for payment notifications to make 2 points of failure.
because otherwise you'll have some very disappointment customers and that cant be good especially for a new site.. :-)

I'm not sure what you mean by "security is pull only".

How do we pull?  I checked out the following from Blockchain.info:

• JSON API:  https://blockchain.info/api/blockchain_api
  
• Query API:  https://blockchain.info/q

The closest or most relevant thing to what you are talking about, that I can find is their "Single Address" JSON API, or specifically:  http://blockchain.info/address/$bitcoin_address?format=json  I think it shows the following as their JSON response?

{
   "hash160":"660d4ef3a743e3e696ad990364e555c271ad504b",
   "address":"1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F",
   "n_tx":17,
   "n_unredeemed":2,
   "total_received":1031350000,
   "total_sent":931250000,
   "final_balance":100100000,
   "txs":[--Array of Transactions--]
}

However, I do not see how the above enables me to pull security.

You should be aware that security is pull only. So even if they push a notification, you must also pull. You can also bulk pull hourly to catch missed payments.

Thanks for your input and warning.  We don't know how popular bitcoins will be with our players, so we want to build the minimum viable product initially.  Besides, it seems that using the bitcoin API call list seems much more complicated.  With Blockchain.info, I assume that you are referring to our callback URL that they will post to.  Would you know how often Blockchain.info has failed or been late in sending the notifications to the callback URL?  Have you had experience in using Blockchain.info's "receive payment API"?

The best idea would be using the bitcoin API call list.
you can also use blockchain.info but if you should know that sometimes they fail to send the notification or send it much later then the actual transaction took place,
so basically using a blockchain is a single failure point.

That's the btce but I guess there's no api. By blockchain hot wallet I mean holding the coins in their wallet too. The receive api can be pointed anywhere including their own.

Sorry, I'm confused.  I thought using Blockchain.info's "receive payment API" is simpler.  How is the hot wallet simpler than Blockchain?

Thanks for suggesting MtGox.  I found this:  https://www.mtgox.com/merchant  and I sent them an inquiry on whether they will work with gambling sites and for more information on how to use their Payment Gateway.

What is "btce".  I found https://btc-e.com/ which is an exchange but doesn't seem to provide payment processing.

Ok keep it simple, use a hot wallet all around. Minimum viable product. Until it gets to an amount you can't insure, move on. I'm available for consulting and programming.

There's also mtgox which probably won't care if you don't do fiat. Or btce. Exchanges might be better since withdrawing is more separated.

Even though our game is skill-based, there is an element of chance.  Hence, it will be deemed as gambling.  Coinbase will not help us because of this.

Building a hot wallet on our server seems like more work than using Blockchain.info's "receive payment API", isn't it?  We don't know how popular bitcoin will be with our users.  Therefore, it seems that it will be easier to use Blockchain.info first and if it gets traction, then we build the hot wallet.  Please do not hesitate to tell me otherwise as I welcome any additional input and appreciate your suggestion of the hot wallet.  That is good to know and hopefully, we'll get to the stage where we need it.  Thanks.

I already had searched and looked into this.  I should've posted what I had found, which was the above and the following:

http://www.reddit.com/r/Bitcoin/comments/1r329e/

The comment on reddit casted confusion onto what the real minimum was for Blockchain, hence I asked my question.  Then I thought about it and decided that our minimum should be 0.001 BTC anyways.

Thanks for your help!

Yes that will be a hot wallet. But I'd cron it to transfer a certain amount out every hour.

There's nothing stopping you from using coinbase either

You know you really should do your own searching and reading.

https://blockchain.info/api/api_receive

Make of the above what you will.

bitpop:  Thanks for your input.

Your link explains how to use JSON-RPC PHP to call bitcoind.  I assume that bitcoind uses the "bitcoin API call list" (https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list).  Does this mean that you think this method is an easier way to accept bitcoin from users than to use Blockchain.info's "receive payment API"?

The benefits of Blockchain.info's "receive payment API" are that we only need to generate one address and can keep our private key offline.  Doesn't this "JSON-RPC PHP calling bitcoind" method imply that my bitcoin wallet will be running on my server?  If so, how do we keep our private keys off of our server?

I run MAMP (Mac Apache MySQL PHP) on my localhost to do development and testing.  I assume that I can run bitcoin in the background on my Mac and have it communicate with JSON-RPC PHP as per https://bitcointalksearch.org/topic/bitcoind-on-a-mac-snow-leopard-21956 ?

The maximum amount that we will accept as deposit from an user is likely going to be 1 BTC and the minimum amount will be 0.001 BTC.  Is this still too small for Blockchain.info?

Here https://en.bitcoin.it/wiki/PHP_developer_intro

Thanks for your input Abdussamad.  Which open source php code did you link to?  Are you referring to the following link that you provided?

https://bitcointalksearch.org/topic/m.4379742

The above link shows PHP code for using Blockchain.info, which I already have and want to test.

It is possible to use bitcoind then. You can generate addresses using open source php code that I linked to before. To find out about transactions to those addresses you can use bitcoind. Bitcoind has a feature where it runs a command each time it learns of a new transaction. All you have to do is watch for transactions to addresses you've handed out to your customers.

Thanks for your input.  Unfortunately, we do not know Python.

Nevertheless, to start, we may not have that many customers.  Therefore, shouldn't we avoid the send programs?  Shouldn't we send manually whenever a user requests withdrawal?

Do you have any suggestions on how to prevent hacks to change the deposit address?

I only know php too

If you know python (unfortunately I don't) you can get a callback too. There is a script in the electrum repo

https://github.com/spesmilo/electrum/blob/master/scripts/merchant/merchant.readme

Problem is no callback

Blockchain.info will not work for small amounts. They only forward payments greater than a certain amount. For a game I imagine small amounts will be the rule rather than the exception?

I suggest using an electrum MPK. See my post here:

https://bitcointalksearch.org/topic/m.4379742

The example also shows the database going through pending sends. You would modify it to do a dry run to tell you how much to deposit then send for real.

A hot wallet is a wallet your server can send from, eg. The example BUT has funds. Keep it empty until sending.

Also watch out for a hack where they change your deposit address.

Thanks for your reply.  Let me reiterate what you wrote, so I understand you fully.

You gave a sending example, but you are recommending that I do not use it.  Instead, I should "manually fill and send" to my users.  Is that correct?

What is a "hot wallet"?

Use blockchain

Here's a sending example https://bitcointalksearch.org/topic/blockchain-mass-send-api-sql-data-type-to-use-5-amazon-voucher-as-a-thank-you-409372

I would receive to an armory wallet and manually fill and send hot wallet

Id start looking here:

http://bitcoin.stackexchange.com/questions/4445/is-there-a-blockchain-info-for-testnet


kosta

We are building an online game and planning to enable our players to play for bitcoins.  Therefore, we need to enable players to deposit and withdraw bitcoins.

Which way is the easiest to start accepting bitcoins from users?  Use the bitcoin API call list (https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list) or use Blockchain.info's "receive payment API" (http://blockchain.info/api/api_receive)?

On Blockchain.info's page for "receive payment API", it gives a PHP example:  https://github.com/blockchain/receive_payment_php_demo.  The example enables your website to prompt the user to send bitcoins to us, via Blockchain.info.  I like to test this out.  Which way is the best way to test it out?  Send real bitcoins or send testnet bitcoins?

If the best way to test is to use real bitcoins, I'm assuming that we should send one Satoshi (0.00000001 BTC) each time?  But how much transaction or network fee will I have to pay (since it is likely that I'll need to send BTC many times)?

If the best way to test is to use Testnet coins, then how does one use them?  I cannot find good information on how to use them to answer questions such as:  Can we use testnet coins to test out the bitcoin API call list or Blockchain.info's "receive payment API" and their PHP example?