...

[infested999]

So basically I make a new address for each user, but it's just 1 of many addresses in the hot wallet?

Yes. At Just-Dice I used bitcoind, and simply did getAddressesByAccount() to see if there was already an address associated with a userid, and getAccountAddress() to get one if there wasn't. Then you can listAccounts() to see the balance for each account with the required number of confirmations and move() to move the funds from a player's 'account' to the main hot wallet account so you don't count it twice.

Recently I heard Gavin saying that the 'accounts' feature in bitcoind is likely to be removed soon, so I guess this isn't a good idea to use any more.

I would advise against the account feature, it isn't meant to be a database, like you are using it. I usually just keep a database table that links addresses to users, I think this system is more robust than using the account feature.


And to be honest I have written dice games in javaEE, which is actually really strong.

How do you get live updates from new deposits. Do I have to check for new deposits for every possible deposit address once per minute? What do you recommend to run so that when a deposit happens there is a event that says "Hey, you got a new deposit" and how do you link this to the site?

[dooglus]

Pretty sure listreceivedbyaddress also protects against that.

I looked into it - I don't see any way to prevent it returning the entire list of addresses and transactions each time you call it.

That's a huge ever-growing amount of data to parse over and over again.

I'd much rather have bitcoind do all that grunt work for me and just tell me which account has a new confirmed deposit.

[gweedo]

So basically I make a new address for each user, but it's just 1 of many addresses in the hot wallet?

Yes. At Just-Dice I used bitcoind, and simply did getAddressesByAccount() to see if there was already an address associated with a userid, and getAccountAddress() to get one if there wasn't. Then you can listAccounts() to see the balance for each account with the required number of confirmations and move() to move the funds from a player's 'account' to the main hot wallet account so you don't count it twice.

Recently I heard Gavin saying that the 'accounts' feature in bitcoind is likely to be removed soon, so I guess this isn't a good idea to use any more.

I would advise against the account feature, it isn't meant to be a database, like you are using it. I usually just keep a database table that links addresses to users, I think this system is more robust than using the account feature.


And to be honest I have written dice games in javaEE, which is actually really strong.

How do you get live updates from new deposits. Do I have to check for new deposits for every possible deposit address once per minute? What do you recommend to run so that when a deposit happens there is a event that says "Hey, you got a new deposit" and how do you link this to the site?

So the flow I did for javaEE, is a couple of checks. One was a cronjob, in tomcat they are not called that, this runs every 5 mins (remember I wait for 1 confirmations anyway, so I don't have to run every 5-10 secs which is probably what you would do for non-confirmed transactions). For my next check, I always run bitcoind in -tx=1 mode so I have access to the entire bitcoin blockchain, and don't have to use a blockchain api. Then using netcat and java socket server, I would have bitcoind send any wallet transactions to the socket server, and put in a queue (any first in first out data structure would work). Remember take this with a grain of salt this transaction, it is usually a non-confirmed transaction, and it can be subject to many attacks. This just alerts my application that a transaction is possible waiting and to track it a bit.

Now that we verified that indeed we have a new balance, I use web sockets to push it to the user. JavaEE is amazing at writing this in a simple class. If you don't want to use websockets, or the the users can't get a good connection, then just simple javascript polling works as well. Then that updates the frontend accordingly. Remember to always check the balance before executing anything server side. This is just a view, and should never be trusted.

Pretty sure listreceivedbyaddress also protects against that.

I looked into it - I don't see any way to prevent it returning the entire list of addresses and transactions each time you call it.

That's a huge ever-growing amount of data to parse over and over again.

I'd much rather have bitcoind do all that grunt work for me and just tell me which account has a new confirmed deposit.

Yes it is a big list, but what I usually do with java, is just hold on to it in an array of objects and remove the the ones we have already processed already. I can always build that array at startup from the double entry database, incase of shutdown or restart.

[infested999]

So the flow I did for javaEE, is a couple of checks. One was a cronjob, in tomcat they are not called that, this runs every 5 mins (remember I wait for 1 confirmations anyway, so I don't have to run every 5-10 secs which is probably what you would do for non-confirmed transactions). For my next check, I always run bitcoind in -tx=1 mode so I have access to the entire bitcoin blockchain, and don't have to use a blockchain api. Then using netcat and java socket server, I would have bitcoind send any wallet transactions to the socket server, and put in a queue (any first in first out data structure would work). Remember take this with a grain of salt this transaction, it is usually a non-confirmed transaction, and it can be subject to many attacks. This just alerts my application that a transaction is possible waiting and to track it a bit.

Thanks gweed

Would you ever consider using the websockets API ( https://blockchain.info/api/api_websocket ) with grep to filter out only transactions to the addresses you are interested in?

Code:

dumpsockets.py ws://ws.blockchain.info/inv | grep -f myaddresses.txt

I'm learning about websockets because I really like the "live" information concept instead of running a script over and over again.

[gweedo]

So the flow I did for javaEE, is a couple of checks. One was a cronjob, in tomcat they are not called that, this runs every 5 mins (remember I wait for 1 confirmations anyway, so I don't have to run every 5-10 secs which is probably what you would do for non-confirmed transactions). For my next check, I always run bitcoind in -tx=1 mode so I have access to the entire bitcoin blockchain, and don't have to use a blockchain api. Then using netcat and java socket server, I would have bitcoind send any wallet transactions to the socket server, and put in a queue (any first in first out data structure would work). Remember take this with a grain of salt this transaction, it is usually a non-confirmed transaction, and it can be subject to many attacks. This just alerts my application that a transaction is possible waiting and to track it a bit.

Thanks gweed

Would you ever consider using the websockets API ( https://blockchain.info/api/api_websocket ) with grep to filter out only transactions to the addresses you are interested in?

Code:

dumpsockets.py ws://ws.blockchain.info/inv | grep -f myaddresses.txt

I'm learning about websockets because I really like the "live" information concept instead of running a script over and over again.

Depends on the situation. For me bitcoind over everything, because I have trust issues but looking at the callbacks of bitcoind...

Code:

-walletnotify=<cmd>    Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)

https://en.bitcoin.it/wiki/Running_Bitcoin#Command-line_arguments

You can't beat them, just don't trust them too much, since they are all done with no confirmations.

[infested999]

Code:

-walletnotify=<cmd>    Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)

What does it mean when a transaction changes? When a transaction changes from 1 confirmation to 2 confirmation? Or does any new transaction count as a transaction change?

[gweedo]

Code:

-walletnotify=<cmd>    Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)

What does it mean when a transaction changes? When a transaction changes from 1 confirmation to 2 confirmation? Or does any new transaction count as a transaction change?

Yes that is why I run bitcoind in tx=1 so I can track the transaction.

[dooglus]

What does it mean when a transaction changes? When a transaction changes from 1 confirmation to 2 confirmation? Or does any new transaction count as a transaction change?

According to the comment in the source code:

// notify an external script when a wallet transaction comes in or is updated

It is done in CWallet::AddToWallet() which appears to be called when a transaction is seen on the network as a standalone transaction or in a block. It won't be called for the 2nd or later confirmation of a transaction.

I don't see an obvious way of defending against malleability attacks using this. It's quite possible you'll see a deposit to a customer address from an unconfirmed transaction, and then later see a deposit of the same amount to the same address from a transaction with a different txid that made it into a block, where the two transactions are mutually incompatible since they have the same inputs.

In other words, there's -walletnotify to tell you when a new transaction arrived, but there's nothing to tell you when that transaction was overwritten by a new version of the same transaction.

[gweedo]

What does it mean when a transaction changes? When a transaction changes from 1 confirmation to 2 confirmation? Or does any new transaction count as a transaction change?

According to the comment in the source code:

// notify an external script when a wallet transaction comes in or is updated

It is done in CWallet::AddToWallet() which appears to be called when a transaction is seen on the network as a standalone transaction or in a block. It won't be called for the 2nd or later confirmation of a transaction.

I don't see an obvious way of defending against malleability attacks using this. It's quite possible you'll see a deposit to a customer address from an unconfirmed transaction, and then later see a deposit of the same amount to the same address from a transaction with a different txid that made it into a block, where the two transactions are mutually incompatible since they have the same inputs.

In other words, there's -walletnotify to tell you when a new transaction arrived, but there's nothing to tell you when that transaction was overwritten by a new version of the same transaction.

Yes walletnotify should NEVER be the only way to accept payments, I use it so I can run a cronjob every 5mins and still make it snappy. It basically tells my java application that a payment could be on it's way and to track this one.

[dooglus]

Yes walletnotify should NEVER be the only way to accept payments, I use it so I can run a cronjob every 5mins and still make it snappy. It basically tells my java application that a payment could be on it's way and to track this one.

So what do you use?

listreceivedbyaddress dumps the entire list of transactions ever received, so you can't really use that except maybe once at startup.
-walletnotify is unreliable, in that it can tell you about the same transaction twice, and tells you about unconfirmed transactions

So what's left?

I like 'listaccounts' and am sad it is going away.

[gweedo]

Yes walletnotify should NEVER be the only way to accept payments, I use it so I can run a cronjob every 5mins and still make it snappy. It basically tells my java application that a payment could be on it's way and to track this one.

So what do you use?

listreceivedbyaddress dumps the entire list of transactions ever received, so you can't really use that except maybe once at startup.
-walletnotify is unreliable, in that it can tell you about the same transaction twice, and tells you about unconfirmed transactions

So what's left?

I like 'listaccounts' and am sad it is going away.

Well it is going away for good reason, hopefully or maybe a couple people (I know I would throw in a couple bucks) for a true enterprise account system to be built not into bitcoind, but on top of it, kinda like bitcoin-cli. This would great for things and would support ACID. Right now the bitcoind accounts technically are not reliable by those standards.

For the non-technical people ACID is the standard by which all database management systems are consider reliable.

[bkora]

you can buy ready to use code for your dice gambling site
you can find many people selling here on forum

[Jarx]

Yes walletnotify should NEVER be the only way to accept payments, I use it so I can run a cronjob every 5mins and still make it snappy. It basically tells my java application that a payment could be on it's way and to track this one.

So what do you use?

listreceivedbyaddress dumps the entire list of transactions ever received, so you can't really use that except maybe once at startup.
-walletnotify is unreliable, in that it can tell you about the same transaction twice, and tells you about unconfirmed transactions

So what's left?

I like 'listaccounts' and am sad it is going away.

Hey,

So what are you using now? (sorry for bumping old thread)