I have an online store and already accept CC payments and I want to start accepting crypto. I'm using the regtest to test the application and so I can't rely on third party APIs plus I feel doing that will hurt at scaling. I'm trying to set it up where each new order will have its own address and I'll have a cronjob periodically check if the address received the payment then send money to cold storage wallet as follows:
Generate address -> receive payment -> wait for confirmations -> send coins to cold storage and show confirmed payment
Currently I save the address in a database associated with the order and generate it using getnewaddress(). I'm stuck on checking the balance of said address and how many confirmations the payment has. I saw accounts looked kind of like what I was looking for but its deprecated so I cant use that. I looked into using blockchain.info JSON API but then with scaling I have to worry about request limits and if I'm trying to request information on too many addresses at once I think it will result in an error. For example, say I have like 4000 orders and the cronjob needs to check all 4000 addresses during the cronjob to get it done efficiently then the addresses that received enough confirmation switch order to paid in database and send coins to cold storage wallet off of server. Plus I'm trying to test it in regtest mode so obviously I cant use a 4rd party API. I saw listunspent() after manually adding addresses and rescanning the chain but I feel if you have thousands of orders and addresses it will be very inefficient every time the job is run and slow the server down.
What is a solution to what I'm trying to accomplish?
I'm very tech savvy and am interested in the be my own bank aspect so I'm not trying to use third party processors or use blockchain.info's wallet API.
I wish there were more people like you (not using bitpay) to protect the privacy of your customers. You are doing similar to How I take VPN monthly payments (see a recent jump in number of user using this type of payment option), and just to share my experience - (correct me please if any of those steps were deemed sub-optimal):
1) with offline and isolated PHYSICAL, non virtualized (Zen, vmware, etc) computer (with much older hardware, say Pentium III no IPMI/other build in BMI chips to scrape your memory during run-time) pre-generate pool of cold private keys address, using dumpprivkey(getnewaddress()). I keep a changing pool of address on live (or more exposed) system and keep no logs for privacy, and those address are only good for receive 1 payment for 1 instance only.
- example: getnewaddress "" bech32 to create bc1 prefixed native-segwit receive address to let your customer save fees.. assume you have core running.
- Also create like 15% of those payment address in 3xx p2sh-segwit format simple getnewaddress() "" p2sh-segwit, then dumpprivkey() those said address and guard it / safe keeping those off-line.
- Note current block count with getblockcount() for faster load for preparing your bitcoin core wallet for manual coinjoin transaction in step 5
- After generated btc payment address/private key in safe place (see step 5)
2) call API to generate QR bitmaps (zxing, etc.. a little off topic so I can't say more)
3) check those pre-generated balance using getreceivedbyaddress bc1xxxxxxxxxx etc.
4) No need to send to cold storage. you pre-generated those private keys they are in floppy disks (or what ever else you choose.. automated Type 316 stainless steel plate tele-type would be my choice)
5) when you need to pay hosting or in my case co-location fees and need fiat, send it to chipmixer if its large (not feasible in my case because payments are normally 8 - 100 usd and chipmixer only do 0.001 btc). Or, if you want to do it yourself,
a) on a different computer, with freshly install OS importprivkey() those address where in step 3 have getreceivedbyaddress(addr)>0. make sure to importprivkey "privatekey" false to keep your system away from rescanning private key.
b) then rescanblockchain (Chain height from Step 1) to ready your wallet for manual coin-join / chipmix hybrid mixing.
6) create larger coinjoin transactions (I'm still writing software to automate RPC call with createrawtransaction() to a pool of chipmixer inputs. You can tor and than hit chipmixer and get a pool say 32 session keys,
a) now you have 32 output address - Note: Don't wait long between this step and complete your coin join transaction, because chipmixer only good for limited time.. I usually drag it out to 24 to save on tx fees (core is good at estimate this or to be sure visit bitcoinfees.earn.com i.e.,)
b) each one with base 2 power of kbtc and have say around 64 inputs. So you have output to each of those 32 as 0.001, 0.002 ... 0.00x; where x^2 represents the chip size you want
c) enjoy lower fees with bc1 / p2sh-segwit enabled receive addresses
I manually create and select mgmt enabled). I found p2sh-segwit address receives payment confirmation than legacy. bc1 comes in at about the same speed as legacy but with much reduced size and higher satoshi/byte it generally arrives as quick as legacy payment input address.
7) face2face and cash in those chips... I usually keep like 100 or so chipmixer private keys so I can cash out exact amount during LBC face-2-face meetups to cash out NTD fiats. I usually PGP a reputable bitcoin dealer from HK/Korea/ in LBC and they will stop regularly to help give me cash at spot price.
Note: Help on 6 on createrawtransaction() bc1 segwit-enabled coin-join transaction is much appreciated. Anyone could provide me with example / sample script would save me about 2 hrs each week to make this transaction bulletproof manually.