{"type":"rich","version":"1.0","author_name":"npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6h","author_url":"https://nostr.ae/npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2012-02-02\n📝 Original message:I agree on your architectural considerations - and with libcoin you can have several wallets in the same application ( and several RPC servers for that matter). And ... they all use the same Node / blockchain.\n\nYou will also find the RPC server in libcoin blistering fast compared to the Satoshi client. (It was actually what got me to write libcoin in the first place...). The Satoshi client HTTP server executes all rpc commands in its own thread, but to do so, it needs to stop the thread of the Node, even though the command executed is just a query (i.e. not a SendTo), you hence have two threads blocking each other and when they wait, you wait... In libcoin all the query methods access the blockChain as a const object and they can hence safely query it without intervening the work of the Node thread. The exception are the SendTo methods that first query if a transaction can take place, then pushes it to the work-queue of the Node thread and again exits immediately. The actual execution then follows once the Node has finished its current tasks (e.g. validating a block).\n\nI have attached the code for a very simple one node, two wallet, libcoin client below (~30 lines), and I have added it to the libcoin source as an example (example name: extrawallets).\n\nOnce running, you can access your extra wallet using the RPC interface:\n./extrawallet extragetbalance\nAnd youy normal wallet by:\n./extrawallet getbalance\n\nI'll leave the generalization to an n-wallet gui application to the reader ;)\n\nCheers,\n\nMichael\n\n....\n\n// The derived classes below are only to get other class names (using the auto rpc name feature)\n// I will put adding a \"setName\" method to the Method class on the todo. \nclass ExtraGetBalance : public GetBalance {\npublic:\n   ExtraGetBalance(Wallet\u0026 wallet) : GetBalance(wallet) {}\n};\nclass ExtraSendToAddress : public GetBalance {\npublic:\n   ExtraSendToAddress(Wallet\u0026 wallet) : GetBalance(wallet) {}\n};\n\nint main(int argc, char* argv[])\n{    \n   logfile = CDB::dataDir(bitcoin.dataDirSuffix()) + \"/debug.log\";\n\n   Node node; // deafult chain is bitcoin\n\n   Wallet wallet(node, \"wallet.dat\"); // add the wallet\n   Wallet extra_wallet(node, \"extra_wallet.dat\"); // add the extra wallet\n\n   thread nodeThread(\u0026Node::run, \u0026node); // run this as a background thread\n\n   Server server;\n\n   // Register Server methods.\n   server.registerMethod(method_ptr(new Stop(server)));\n\n   // Register Node methods.\n   server.registerMethod(method_ptr(new GetBlockCount(node)));\n   server.registerMethod(method_ptr(new GetConnectionCount(node)));\n   server.registerMethod(method_ptr(new GetDifficulty(node)));\n   server.registerMethod(method_ptr(new GetInfo(node)));\n\n   // Register Wallet methods. - note that we don't have any auth, so anyone (on localhost) can read your balance!\n   server.registerMethod(method_ptr(new GetBalance(wallet)));\n   server.registerMethod(method_ptr(new SendToAddress(wallet)), Auth(\"username\",\"password\"));\n   server.registerMethod(method_ptr(new ExtraGetBalance(wallet)));\n   server.registerMethod(method_ptr(new ExtraSendToAddress(wallet)), Auth(\"username\",\"password\"));\n   server.run();\n\n   node.shutdown();\n   nodeThread.join();\n}\n\n\nOn 02/02/2012, at 00:50, grarpamp wrote:\n\n\u003e\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\u003e \n\u003e I'll be trying your implementation soon. And libbitcoin/subvertx too.\n\u003e Partly because they're also non-interpreted, and partly to what seems\n\u003e better architected...\n\u003e \n\u003e To the minimal extent of my understanding... I'd like to see wallet\n\u003e ops completely separated from background chain ops. ie: have\n\u003e a chain daemon doing it's thing, updating, verifying, etc. The\n\u003e generator doing it's thing. And a wallet app that can independently\n\u003e manage separate wallets in parallel, referencing the live chain files\n\u003e as needed. It seems a library would allow quality focus on the separate\n\u003e functions and let apps/ui's use the fn's as desired on top. Right now, it\n\u003e seems I have to run bitcoind and can only deal with one wallet at a time,\n\u003e having to stop it, deal with state issues, swap in a new wallet, start\n\u003e it, and repeat till illness ensues :( And when the chain is being processed\n\u003e hard by the daemon cpuwise, bitcoin RPC takes minutes to respond, if ever\n\u003e or errors out. If wallet ops or statistical queries on the chain need it for\n\u003e integrity or reading, a db checkpoint/lock/logroll could be implemented into\n\u003e the chain demon processes with a client lib api to trigger it as needed.\n\u003e Don't know, just saying.\n\u003e \n\u003e fyi... boost 1.48 and db 4.8.30 work fine with 0.5.2, 0.5.x, and master,\n\u003e you just need to compile and include it by hand if you want it and\n\u003e your package manager doesn't have it.\n\nMichael Gronager, PhD\nDirector, Ceptacle\nJens Juels Gade 33\n2100 Copenhagen E\nMobile: +45 31 45 14 01\nE-mail: gronager at ceptacle.com\nWeb: http://www.ceptacle.com/"}