bitcoin core RPC compatible lite wallet proxy?

[Envrin]

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.

Doesn't that mean you need to manually parse the blockchain for UTXOs to your scripts/addresses? That means calling getblock and then getrawtransaction for each transaction in every block?

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.

[1714900082]

1714900082

[1714900082]

1714900082

[1714900082]

1714900082

[monsterer]

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.

Doesn't that mean you need to manually parse the blockchain for UTXOs to your scripts/addresses? That means calling getblock and then getrawtransaction for each transaction in every block?

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.

That's basically equivalent to using listunspent, or listsinceblock in combination with the watch only features. I personally wouldn't build a system around blocknotify as its fragile and cannot deal with historical data.

[hhanh00]

It would help if you give performance requirements.

- number of addresses
- number of concurrent requests
- response time

Otherwise, nearly anything can be a UTXO database. Including the blockchain.

[Envrin]

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.

[monsterer]

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)?  

I'm not using either. I'm using importaddress, but its not a BIP32 generated key.

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.

And if your monitoring daemon goes down? I don't use blocknotify for that reason. Any chain scanner must be able to carry on where it left off after a power cut or any other outage. Relying on blocknotify for that would leave you out of sync with the network.

[Envrin]

And if your monitoring daemon goes down? I don't use blocknotify for that reason. Any chain scanner must be able to carry on where it left off after a power cut or any other outage. Relying on blocknotify for that would leave you out of sync with the network.

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.

[monsterer]

And if your monitoring daemon goes down? I don't use blocknotify for that reason. Any chain scanner must be able to carry on where it left off after a power cut or any other outage. Relying on blocknotify for that would leave you out of sync with the network.

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.

Not bitcoind, your own daemon process which is being notified. If that suffers some outage, you're left out of sync.

[Envrin]

Not bitcoind, your own daemon process which is being notified. If that suffers some outage, you're left out of sync.

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?

[monsterer]

Not bitcoind, your own daemon process which is being notified. If that suffers some outage, you're left out of sync.

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?

listsinceblock is more robust because you can just store the last processed block and get all transactions from that point. This negates the need to have a special case for a retry queue.

[Envrin]

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.

[monsterer]

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.

My plan is to have the daemon process continually sync by polling listsinceblock every N seconds. Then some kind of other accounting system to track which addresses belong to which 'account' (this is not the bitcoin accounting system), so that you can build raw transactions by gathering utxos.

Like I said in the OP, I didn't want to do any of this, since it seems like it ought to already exist, but there we are.

[Envrin]

Like I said in the OP, I didn't want to do any of this, since it seems like it ought to already exist, but there we are.

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.

[Hannu]

Is there a bitcoin core RPC compatible lite wallet available which proxies onto a full node for the data?

Use case: multiple merchant wallets, one blockchain, one API on one machine without having to duplicate the blockchain.

I have a full node running, which is great, but I need multiple wallets... Having lite wallet(s) which would get their data from my full node would be awesome and not have any of the trust issues a lite wallet would normally have.

I don't want to have to implement another RPC wrapper, so this needs to be compatible with the core RPC API.

Cheers, Paul.

Hello Paul,

I dont use proxy at all in newest core version. I have problem to reach the point when its loading blockchain.
They cannot help me at work. I asked even engineer buddy to help =(