Bitpay and invoice-based is an interesting solution for stores. But it is not so useful for exporadic funding issues or for those who want to better understand how it works.
The idea of checking balances, in unique addresses, is very interesting. Recently I needed to collect money from a group of people for a simple project in a forum similar to this one. Not everyone was comfortable with Bitcoin, so I thought it would be an opportunity to demonstrate in practice how it would work. But it turned out to be a lot more complicated and expensive than I'd imagined.
So lately whenever someone asks about a Payment Gateways I suggest Bitpay.
Anyway, even for educational purposes, demonstrate how to use specific addresses, even if it is difficult to create one for each task and take advantage of public ledger make this solution using bitcoind become quite interesting.
Thanks for the step by step explanation. It will be of great help.
Topic: Re: need urgent support for activate cooper member,any admin please support me (Read 203 times)
April 07, 2018, 12:56:13 AM
April 06, 2018, 03:45:06 AM
It's just bitcoind + about 200 lines of code. BitPay and Coinbase are only (maybe) useful if you need a guaranteed USD value right away when someone pays you. If you're willing to accept a little exchange-rate risk, I highly recommend handling payments yourself.
Until very recently, I was using the bitcoind accounts pattern (getaccountaddress & getbalance) recommended from about 2011 to 2014. But this has been deprecated for a few years, and it seems to be broken in 0.16. In order to quickly work around the 0.16 bug, I switched to the one-address-per-user anti-pattern (getaddress -> put this address in your database for the user -> getreceivedbyaddress) which you should really not do because it involves address reuse. (But the forum's case of reusing addresses once or twice isn't the end of the world, which is why I'm accepting it for now.)
I haven't decided yet how I'll handle payments in the long-term. Bitcoind-accounts were kind of nice in how they handled payments as user balances rather than invoices. It allows for easier, closer integration with your site, I think, and it makes it easier to think about a lot of edge cases. It wouldn't be all that difficult to basically re-implement bitcoind-accounts on my end so as to keep things roughly as they are while avoiding address reuse.
On the other hand, I feel like the ecosystem is mainly moving in the direction of invoices rather than balances. Bitcoind's development seems to be focused on that use-case, and LN fits far more naturally into an invoice-based system. For this, I'd be inclined to switch to BTCPay (which will support LN when possible), but that'd require a total rethink and rewrite of my payments code.
So:
If you want an invoice-based system similar to PayPal, Coinbase, or BitPay, or if you want to be more future-proof, use BTCPay.
If you want to do what the forum does and deal in user balances rather than invoices, it's pretty easy to use bitcoind directly. Something like (pseudocode):
Until very recently, I was using the bitcoind accounts pattern (getaccountaddress & getbalance) recommended from about 2011 to 2014. But this has been deprecated for a few years, and it seems to be broken in 0.16. In order to quickly work around the 0.16 bug, I switched to the one-address-per-user anti-pattern (getaddress -> put this address in your database for the user -> getreceivedbyaddress) which you should really not do because it involves address reuse. (But the forum's case of reusing addresses once or twice isn't the end of the world, which is why I'm accepting it for now.)
I haven't decided yet how I'll handle payments in the long-term. Bitcoind-accounts were kind of nice in how they handled payments as user balances rather than invoices. It allows for easier, closer integration with your site, I think, and it makes it easier to think about a lot of edge cases. It wouldn't be all that difficult to basically re-implement bitcoind-accounts on my end so as to keep things roughly as they are while avoiding address reuse.
On the other hand, I feel like the ecosystem is mainly moving in the direction of invoices rather than balances. Bitcoind's development seems to be focused on that use-case, and LN fits far more naturally into an invoice-based system. For this, I'd be inclined to switch to BTCPay (which will support LN when possible), but that'd require a total rethink and rewrite of my payments code.
So:
If you want an invoice-based system similar to PayPal, Coinbase, or BitPay, or if you want to be more future-proof, use BTCPay.
If you want to do what the forum does and deal in user balances rather than invoices, it's pretty easy to use bitcoind directly. Something like (pseudocode):
Code:
# you have a SQL table `addresses` with columns user, time, address
# and a table `spends` with columns user, time, amountSpent
def getAddress(username):
address = sqlQuery("select address from addresses where user=% order by time desc limit 1", username)
if address is null or bitcoindQuery("getreceivedbyaddress % 0", address) is not 0:
address = bitcoindQuery("getnewaddress")
sqlQuery("insert into addresses values (%, NOW(), %)", username, address)
return address
def logUserSpend(username, amount):
sqlQuery("insert into spends values (%, NOW(), %)", username, amount)
def getBalance(username, minConfirmations):
balance = 0
for address in sqlQuery("select address from addresses where user=%", username):
balance += bitcoindQuery("getreceivedbyaddress % %", address, minConfirmations)
totalSends = sqlQuery("select sum(amountSpent) from spends where user=%", username)
return balance - totalSends
# The above is conceptually how you do it, but you may want to
# add something to avoid so many calls to bitcoindQuery, which is
# a slow operation. As written, this doesn't scale to hundreds of
# addresses per user. For example, you may want to store balances
# for old addresses and assume that the user will not reuse them,
# or poll bitcoind's listsinceblock looking for addresses for
# whom you should update the balances in your database.
def exampleBuyItem(phase, user):
if phase is entry:
print "Please pay to %", getAddress(user)
elif phase is registerPayment:
sqlQuery("set transaction isolation level serializable")
sqlQuery("start transaction")
if getBalance(user, 6) >= price:
sendUserTheItem()
logUserSpend(user, price)
else:
print "Not enough money"
sqlQuery("commit")
April 06, 2018, 12:51:15 AM
need urgent support for activate cooper member,any admin please support me
Not an admin, but have you read https://bitcointalk.org/index.php?action=credit;promote and followed the instructions? The process is automatic except that you need to return to the page to 'wear' your new copper membership.Quote
The address above was newly generated just for you, so when any BTC is sent to it, we will know to credit it to your account. It is all automatic.
Could someone explain how it works or where I can read more about the code? It seems rather simple, safe, and fast.
Many people always ask about gateways or means of payments for simple tasks using Bitcoin and this method would be a fine example to present.
Jump to: