It already does exist.  Again, check out http://synala.com/

I'm not saying use Synala, but it is open sourced on Github, so you should at least check out the code and database schema to see how it's done properly and securely, as Synala supports exactly what you're looking for.

Anyway, this thread has been enough of a time suck.  I'm out.

Ok, so what's your plan of attack here?  You're going to run "listsinceblock" via crontab every 5 minutes, or?

Also, your OP mentioned you need to separate multiple wallets with one install of Bitcoin Core.  How are you going to tackle that with listunspent and listsinceblock?  You need some way to organize them, as to which goes to what wallet.

So instead of creating a retry queue, you're going to rely on "listunspent" instead?  How are you going to separate that with multiple wallets / systems?  How will you know which UTXO goes where?  Using the "accounts" within bitcoin core, or?

No.  If bitcoind goes down for a few hours for whatever reason, it'll pick up where it left off, and fire all necessary blocknotify commands from the time it went down as it downloads the rest of the blockchain.

Depends.  How are you generating these addresses?  Are you using the wallet.dat file and getnewaddress RPC command?  Or are you using a BIP32 key(s)?  If the latter, then at the very least you need to store a database of addresses with their associated key indexes, otherwise you won't know how to generate the proper private keys to send the funds.  Even without that, you're still going to need to separate the UTXOs between your multiple wallets somehow, and bitcoin core isn't going to do that for you.

The blocknotify is used for confirmations.  One block = 1 confirmation, right?  Say your software is set to confirm a tx after 4 confirms.  So every time blocknotify fires, you add 1 confirmation to each tx.  Once a tx in your system hits 4 confirmations, you look it up in the blockchain using gettransaction, and ensure it still shows 4 confirmations there.  If a block reorg happened, the gettransaction command will report back with -1 confirmations, so you know to abandon that tx.

No.  Add "walletnotify" / "blocknotify" options to your bitcoin.conf file.  Then use the "importaddress" RPC function to import any addresses your software generates, and bitcoind will fire the "walletnotify" command any time funds hit any address you've imported.  Then use "blocknotify" to track confirmations within your system.

Assuming you're using a HD BIP32 wallet though, then the "listunspent" isn't going to be enough, especially if you want to separate things between wallets / systems.  You'll also need to store, a) which wallet the funds are assigned to, and b) which key index was used to generate the address, so you know how to generate the child private key from the BIP32 master key.

Again, maybe take a look at the code in Synala if you know PHP.  It provides good examples of how this is done.

Ok, we're talking about two completely different things here.  You're talking about large organizations with multiple corporations and bank accounts spread across the globe, who deal with 10s or 100s of millions in funds, and report to the likes of FinCEN, correct?  In that case, I doubt an out of the box solution would even be possible, because every system would have to be customized for that specific business (model).  I'm assuming folks like Bitstamp go with custom solutions, because they have millions in their budget to do so.

And yes, my solutions are meant for the small business owners, the 1 - 5 man shops or similar.  People that make say $100k - $500k/year.  For my target audience, my solutions work beautifully.

If you're looking towards folks like BitStamp, et al, then sounds as though the market is wide open for you, if you can put together even a base system that can be easily customized.  You're basically talking about writing your own node, correct?  That's a fairly adventurous task, and many have failed at trying, including myself.  Could be lucrative if you managed to pull it off though.  Probably wouldn't get too many clients, but when you're signing $1.5mm contracts, you don't really need many.

EDIT:  You mentioned the bitcoind & "accounting" servers must both be online, but that's not true.  If bitcoind goes down, when it comes back online, it'll begin firing all necessary "blocknotify" and "walletnotify" commands as it downloads the blockchain from where it left off.  Then just write a quick JSON API to communicate between the servers, queue the txs / blocks, send JSON request, if a proper response is received remove tx / block from queue.  If proper response not received, leave in queue and retry at regular intervals until proper response is received.

Just checked and confirmed, yes, the "listunspent" function does list all UTXOs from watch-only addresses added via the "importaddress" function.  Should note, the watch-only inputs have the "spendable" attribute set to false, but that's the only difference i can see.

Wouldn't really recommend that method for multiple reasons, and better to keep your own database of UTXOs for your addresses, but your software, so your choice.

EDIT:  If you're by chance using a HD wallet, you somewhat have to keep a list of UTXOs yourself anyway.  Otherwise, if you're going to rely solely on "listunspent", you're not going to know what key index was used to generate the child key / address from the master BIP32 key, and that piece of information is quite important if you ever want to send the funds.

Maybe he's talking about writing your own node or something, I don't know.  If that's the case, then yes, that's quite difficult when dealing with block reorgs, ensuring you get all txs and blocks from the P2P network without skipping a beat, ensure everything is valid, etc.

However, if you're willing to leverage Bitcoin Core, then everything is quite simple.

Huh?  It's somewhat two-way.  Not completely, but there are "walletnotify" and "blocknotify" config options available, and combine that with the "importaddress" function if you're not using the wallet.dat file, and it will instantly notify your software of a new tx that's assigned to one of your addresses and every new block.

As for block reorgs, that's quite simple too.  For example, say you set it for 4 confirmations required.  Every time a new block is generated, your software immediately fires, adds 1 confirmation to each tx, then looks up each unconfirmed tx that has 4 confirmations, and ensures it's still a valid tx.  If not, bitcoind will show the confirmations at -1, meaning block reorg so you abandon that tx.  If it's still valid and showing 4 confs within the blockchain though, then you confirm it in your system.

Or am I missing something here?

http://synala.com/

Would do the trick.  You can either setup multiple wallets with different BIP32 key pairs within one installation of Synala, or install it multiple times, and just enter the same RPC connection settings in each install.  Would require you to have one full node running, but you could run the multiple systems / wallets off that one node without problem.

Only thing is, during install it'll ask you to add lines to the bitcoin.conf file like:


You'll need to change those to run a bash script instead for the multiple sites.  So instead you would have for example:


Then create the bash files with the appropriate PHP commands being run, one for each install.  So for example, /home/coind/process_tx.sh would contain:


Hope that helps!

Whoops, thanks for pointing the small typo out.  All fixed.

http://synala.com/

Might do the trick for you.  Will easily support a large number of users, can handle both product purchases and invoices, keeps all tx data you need, generates a new address for each deposit, has a hook system so you can easily run additional PHP code when various actions occur, etc.  Free, and open sourced on Github.  It does require a full node on your server though, although doesn't use the wallet.dat file.

If you need a software system that's a little more commercial / enterprise level, we do have that available, and just drop me a PM with requirements.

You'll have to plug it into whatever wallet software you were using to receive funds.  That software should be able to retrieve the balance for you.

Aside from that, there's no way to tell what exact key index structure was used to generate the child keys.  If they went with what's recommended (m / is_change / n) then a generic solution might work, but wouldn't rely on accuracy.  Is that the key index used?  Are they hardened child keys, or no?  etc...

I can confirm it works perfectly fine on CentOS.  That's what we generally use for production servers.

Works fine on Linux Mint as well, which is based on Ubuntu, and what I use for my personal PC.

Understood, but again, I believe that's up to the individual users / merchants / market.  Everyone has a different usage for bitcoin, and some people don't mind their privacy being compromised in exchange for a more user-friendly system.  If your primary aim is privacy, then you should know how to do it, as it's not difficult to setup intermediate addresses for incoming funds, then split-up and bounce those funds around the blockchain enough times to skew where they went, before they hit your actual wallet.

I don't believe it's something the core dev team should worry about / implement, no.  I think it's something best left up to the market, and individual merchants / online operations.

Everything I develop has generates a new address for every transaction by default, but sometimes clients will want things like change sent back to the originating address.  I explain to them why the practice is discouraged and so on, but at the end of the day, it is their business and they can do what they like.

1 BTC/month?  Are you kidding me?  That node probably costs you maybe $0.50/month to run, if you even notice a higher cost of living due to running it.

Myself and clients combined have dozens of full nodes running across the internet.  The $$$ to run a node never factors into anything.

No, other way around.  The executable / binary is inside the VM.  For example, my offline signer is a Python app at:

https://github.com/peterscott78/offline_signer/

Go into the /bin/ directory, and there's binaries available for Windows and LINUX 32/64 bit.  Just download it to any computer without Python, OpenSSL or anything else installed, and it will still work just fine.  All you need is that archive.

Same goes for Qt, as I have a development IDE developed in it.  Or for another example, Bitcoin Core is developed in Qt, and works great on any OS right out of the box.

Nope.  What happens in you setup VMs with each desired OS, then compile it from source on each OS.  For both, Python and Qt it will generate an executable binary, with all necessary dependencies / libraries for that OS.  There's absolutely no additional software / configuration / dependencies required, and it will work straight out of the box.  Once compiled, I can setup another VM with a fresh install of whatever OS with no development tools / libs on it, and it'll work perfectly.

Anyway, I'm not here to argue.  If you like C#, then great, stick with it.   If you want to distribute a desktop app and want it truly cross platform, there are better options than C#.