1

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?

2

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.

  • Thank you for your very complete answer! I still have a question though: couldn't I simply use functions provided by libraries like Bitcoinj or bitcoind RPC to compute all those complex things, but without using their "wallets"? Thing is I would prefere not to be bound to a specific library and have to have wallets directories of a specific format as required by the library! – electrotype Oct 17 at 17:51
  • 1
    Of course you can, take a look at bitcoind rpc doc labels for instance upper right in black. Let's say it describe what set of function represent a wallet (Under wallet section). Just take what you need but keep in mind that "basically" all function excluding wallet's one are what data does a bitcoin node provide. You could consume that but in real practise the wallet consume it the most. Hope it's clear! – onepix Oct 18 at 9:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.