rich1.0npub1rjzq78n467z9ugxvfq6cyxdk8n3rtn8h92yjnrtene4a52g847rsgvs23thttps://nostr.ae/npub1rjzq78n467z9ugxvfq6cyxdk8n3rtn8h92yjnrtene4a52g847rsgvs23tnjumphttps://nostr.ae📅 Original date posted:2012-02-01 📝 Original message:> However, I think perhaps the bitcoin project should be split into a library, with a prototype client and the actual clients. This library facilitates this. I'll be trying your implementation soon. And libbitcoin/subvertx too. Partly because they're also non-interpreted, and partly to what seems better architected... To the minimal extent of my understanding... I'd like to see wallet ops completely separated from background chain ops. ie: have a chain daemon doing it's thing, updating, verifying, etc. The generator doing it's thing. And a wallet app that can independently manage separate wallets in parallel, referencing the live chain files as needed. It seems a library would allow quality focus on the separate functions and let apps/ui's use the fn's as desired on top. Right now, it seems I have to run bitcoind and can only deal with one wallet at a time, having to stop it, deal with state issues, swap in a new wallet, start it, and repeat till illness ensues :( And when the chain is being processed hard by the daemon cpuwise, bitcoin RPC takes minutes to respond, if ever or errors out. If wallet ops or statistical queries on the chain need it for integrity or reading, a db checkpoint/lock/logroll could be implemented into the chain demon processes with a client lib api to trigger it as needed. Don't know, just saying. fyi... boost 1.48 and db 4.8.30 work fine with 0.5.2, 0.5.x, and master, you just need to compile and include it by hand if you want it and your package manager doesn't have it.