Bitcoin backend integration - Do I really need the notion of "a wallet"?

Question

I am developing an application that will accept Bitcoins targetting some specific "items" in my application, and later transfert some of those Bitcoins to externals addresses.

In many similar projects I read about, they use the notion of "wallets". For example if you use Bitcoinj: it seems the first thing to do is to create wallets!

I understand what GUI wallet softwares are and why those are important for end users. But in a backend application, if I understand correctly, a wallet is simply a seed that can generate some private/public keys pairs in a deterministic way. Is that correct?

So, in the end, the only thing that really matters in order to be able to manage the coins sent to "a wallet" (sent to a specific user or for a specific "item") is to know the private keys that were involved.

In my application, I plan on generating a new private/public keys pair for every new "receive coins" transaction. Not from a seed, simply a random pair! And since I already have a database, I was thinking about storing the generated keys in a table (the private keys begin encrypted), with information about what the transaction was for.

And when I would need to send coins to external addresses, I would decrypt some private keys, create inputs using them, create a transaction that I would sign, and then broadcast that transaction.

In other words, currently I would not really have the notion of "wallets".

So my question:

Am I missing something about what "a wallet" actually does (in a backend application)?

Do I need something else in order to implement the "receive/send" process I'm talking about or is my database table with all the private/public keys pairs enough?

Answer 1

I understand what GUI wallet softwares are and why those are important for end users. But in a backend application, if I understand correctly, a wallet is simply a seed that can generate some private/public keys pairs in a deterministic way. Is that correct?

Correct, but you miss the most important feature of a wallet...crafting transaction / bitcoin script! And that part is not trivial as it involves such things as coin selection algorithm, bitcoin standard script +~segwit(also for generating segwit address), signatures etc.

What matter in the end are the key indeed... but you should not underestimated what feature does a wallet provide and instead of persisting tons of encrypted priv key you should definitively take a look of HD wallet (BIP32, BIP44, BIP49, BIP84)which are "basically" a determinist way given a seed / mnemonic, to handle an infinite amount of key. This way you could just persist paths.

See a wallet more like a tool, or a library a module a package whatever, you would require that I'm pretty sure, because when you mention "create inputs using them, create a transaction that I would sign, and then broadcast that transaction", that's what a wallet does.

About you received/send, I guess you have to handle or take into account a given transaction state, mined, validated (~6 confirmations, depends your requirements) or not. This way your app will behave differently. Basically you need a node or an API and a wallet "package" tool which will bridge the gap between your app and the node.