Published on: 2016-08-04T00:59:11+00:00
In a message posted to the bitcoin-dev mailing list, it is highlighted that many people rely on their own separate account systems and use bitcoind primarily for sending, receiving, and verifying transactions. However, it is noted that bitcoind is not intended to be a comprehensive solution for running an entire bitcoin deposit and withdrawal system; it simply provides the necessary tools for building such a system. For those in need of a pre-built solution, companies like BitGo offer platforms that can fulfill this role.The message also raises concerns about the deprecation of accounts in bitcoind. The poster explains that if they have accounts, they must ensure that account holders do not overcharge their accounts. One potential solution suggested is to use "createrawtransaction() + fundrawtransaction() + signrawtransaction()" to guarantee that the transaction can be paid by an account. However, with accounts being deprecated and no sendrawtransactionfrom() method available, the poster faces the dilemma of either constructing their own account system or presuming that the account code will not be untangled and hacking bitcoind to incorporate a sendfrom function with a fixed fee parameter that overrides the size multiplication.The absence of an integrated account system in bitcoind is deemed problematic as it hinders the effective tracking of all incoming funds to all addresses. Without accounts, bitcoind essentially functions as a person-to-person manual client, making it challenging to establish many-to-many automatic organizations on top of the platform. The poster asserts that there are likely numerous developers facing similar predicaments and warns that deprecating accounts without offering a viable alternative could discourage further bitcoin-related development.The writer identifies two key issues with bitcoind that render it unsuitable for many projects. Firstly, if accounts are present, it becomes crucial to prevent account holders from overcharging their accounts. The suggested workaround involves using "createrawtransaction() + fundrawtransaction() + signrawtransaction()" and ensuring that the transaction can be paid by an account. However, since accounts are deprecated and there is no sendrawtransactionfrom() method, the writer must either develop their own account system or hope that they can successfully modify bitcoind to include a sendfrom function with a fixed fee parameter. Secondly, without accounts, bitcoind is limited to being a person-to-person manual client, making it impossible to construct many-to-many automatic organizations on top of the platform. The writer argues against deprecating accounts as it severely restricts the usability of bitcoind for various projects. They even disclose that they ceased development related to bitcoin after encountering difficulties with transactions requiring fees and the platform's inability to handle such fees within accounts.In conclusion, the writer hopes that developers understand their concerns are genuine rather than mere trolling. They emphasize that without accounts, building many-to-many automatic organizations becomes arduous, necessitating predictable fees. While acknowledging privacy issues with using accounts for off-chain microtransactions, the writer asserts that it currently remains the most viable option.
Updated on: 2023-08-01T18:48:41.126636+00:00