1

I am using the bitcoind account system for my web app, but it doesn't work the way I want it to work. So I want to make my own account system in Laravel(probably opensource).

The main reason for the account system is that I can't know the fee when I send a transaction. With my own account system I can check if the fee is correct and then send the transaction.

But how can I setup a safe account system?

I was thinking about a table with all the bitcoin accounts(I am not using the users table so I can create accounts for an order for example).

Then an address table with all the addresses linked to an account.

But how do I handle incomming transactions? And outgoing transactions? If I for some reason change something outside my account system, it will probably will break pretty easy.

Do I have to import all the transactions to calculate the right account balances?

And I want to make the system in a way that I can make transactions between accounts, without making a "real" transaction, just like it works now.

I think it isn't that hard without the account-to-account transactions and moving bitcoin addresses to other accounts features, just import all the transactions in the database and calculate the balance for every address. And than sum the address balance for every account, but I need it.

Does this kind of system already exists. If not can someone help me with thinking this out.

5
  • Is there any particular reason why addresses must be associated with specific accounts? From what you write it seems to me that you're in full control of the funds on every account anyway, so just tracking the balances of your users separately from the addresses would be much easier.— Note that the "account system" in Bitcoin Core has been deprecated for years and wasn't meant to be used for accounting, it's not surprising that it doesn't do what you want it to. ;)
    – Murch
    Mar 4, 2017 at 11:47
  • @Murch I just want to make a good project that is very scalable. So other people can use it also. If I use it for other projects it can be implemented very easy. If I keep track of the user balance separately from the addresses and I make a mistake(It happends a lot ;)) it wouldn't be good.
    – Jan Wytze
    Mar 4, 2017 at 12:16
  • Keeping all the users' funds in separate addresses means that you have no benefit of scale for issues like fees and coin selection. You'd grind the UTXOs to tiny pieces as your users manage their funds, you'd be unable to aggregate payments via Lightning channels without updating on-chain (or payment channels)… It's anything but scalable.— I'm also not sure that keeping the balances separate makes it much harder to make a mistake.
    – Murch
    Mar 4, 2017 at 12:26
  • @Murch think I that have found the way. I have a table with all the transactions. These have an user id. The user id is the id of the owner of the address at the time of receivement. So if the address goes to another account, the transactions still belongs the the user who received them. This way I can just get all the transactions of an user and calculate the balance.
    – Jan Wytze
    Mar 4, 2017 at 13:08
  • Yeah, that seems much better way to do it. :) Just be sure to account for transactions only after confirmation, and perhaps even after a a few blocks or your table will be very confused by blockchain reorganizations or stale blocks. ;)
    – Murch
    Mar 4, 2017 at 13:16

1 Answer 1

0

I have the account system working! Only I didn't really test it, so it isn't stable. https://github.com/jwz104/bitcoin-accounts

It works with an user, address and transaction table.

There is running a cronjob that registers all received transactions. If the adddress is found in the address table, it will add the transaction with the user id of the address. If the address has no user_id the transaction will not be added because it is a return transaction(Change).

When a transaction is created the package will send the amount of bitcoins to the address, and the bitcoin that are left are send to a return address(Address without user_id) so the user won't pay to much.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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