{"type":"rich","version":"1.0","author_name":"npub1rjzq78n467z9ugxvfq6cyxdk8n3rtn8h92yjnrtene4a52g847rsgvs23t","author_url":"https://nostr.ae/npub1rjzq78n467z9ugxvfq6cyxdk8n3rtn8h92yjnrtene4a52g847rsgvs23t","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2012-02-01\n📝 Original message:\u003e 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.\n\nI'll be trying your implementation soon. And libbitcoin/subvertx too.\nPartly because they're also non-interpreted, and partly to what seems\nbetter architected...\n\nTo the minimal extent of my understanding... I'd like to see wallet\nops completely separated from background chain ops. ie: have\na chain daemon doing it's thing, updating, verifying, etc. The\ngenerator doing it's thing. And a wallet app that can independently\nmanage separate wallets in parallel, referencing the live chain files\nas needed. It seems a library would allow quality focus on the separate\nfunctions and let apps/ui's use the fn's as desired on top. Right now, it\nseems I have to run bitcoind and can only deal with one wallet at a time,\nhaving to stop it, deal with state issues, swap in a new wallet, start\nit, and repeat till illness ensues :( And when the chain is being processed\nhard by the daemon cpuwise, bitcoin RPC takes minutes to respond, if ever\nor errors out. If wallet ops or statistical queries on the chain need it for\nintegrity or reading, a db checkpoint/lock/logroll could be implemented into\nthe chain demon processes with a client lib api to trigger it as needed.\nDon't know, just saying.\n\nfyi... boost 1.48 and db 4.8.30 work fine with 0.5.2, 0.5.x, and master,\nyou just need to compile and include it by hand if you want it and\nyour package manager doesn't have it."}