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.
You 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).
I 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).
Once running, you can access your extra wallet using the RPC interface:
./extrawallet extragetbalance
And youy normal wallet by:
./extrawallet getbalance
I'll leave the generalization to an n-wallet gui application to the reader ;)
Cheers,
Michael
....
// The derived classes below are only to get other class names (using the auto
rpc name feature)
// I will put adding a "setName" method to the Method class on the todo.
class ExtraGetBalance : public GetBalance {
public:
ExtraGetBalance(Wallet& wallet) : GetBalance(wallet) {}
};
class ExtraSendToAddress : public GetBalance {
public:
ExtraSendToAddress(Wallet& wallet) : GetBalance(wallet) {}
};
int main(int argc, char* argv[])
{
logfile = CDB::dataDir(bitcoin.dataDirSuffix()) + "/debug.log";
Node node; // deafult chain is bitcoin
Wallet wallet(node, "wallet.dat"); // add the wallet
Wallet extra_wallet(node, "extra_wallet.dat"); // add the extra wallet
thread nodeThread(&Node::run, &node); // run this as a background thread
Server server;
// Register Server methods.
server.registerMethod(method_ptr(new Stop(server)));
// Register Node methods.
server.registerMethod(method_ptr(new GetBlockCount(node)));
server.registerMethod(method_ptr(new GetConnectionCount(node)));
server.registerMethod(method_ptr(new GetDifficulty(node)));
server.registerMethod(method_ptr(new GetInfo(node)));
// Register Wallet methods. - note that we don't have any auth, so anyone
(on localhost) can read your balance!
server.registerMethod(method_ptr(new GetBalance(wallet)));
server.registerMethod(method_ptr(new SendToAddress(wallet)),
Auth("username","password"));
server.registerMethod(method_ptr(new ExtraGetBalance(wallet)));
server.registerMethod(method_ptr(new ExtraSendToAddress(wallet)),
Auth("username","password"));
server.run();
node.shutdown();
nodeThread.join();
}
On 02/02/2012, at 00:50, grarpamp wrote:
>> 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.
Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: grona...@ceptacle.com
Web: http://www.ceptacle.com/
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
