diff options
| author | Michael Grønager <gronager@ceptacle.com> | 2012-02-02 09:32:24 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-02-02 08:32:36 +0000 |
| commit | 172596ce4fc9f5f8f1f1421bcdc1f740e6e69f76 (patch) | |
| tree | e6f03fb9e61c466d01ab642995a43607e91bacd1 | |
| parent | 255111092008d9c69a2e6276c3af6a52806d8892 (diff) | |
| download | pi-bitcoindev-172596ce4fc9f5f8f1f1421bcdc1f740e6e69f76.tar.gz pi-bitcoindev-172596ce4fc9f5f8f1f1421bcdc1f740e6e69f76.zip | |
Re: [Bitcoin-development] Announcement: libcoin
| -rw-r--r-- | e0/a1876f6974f23b7e7c0701bb5fe0cc2a469411 | 192 |
1 files changed, 192 insertions, 0 deletions
diff --git a/e0/a1876f6974f23b7e7c0701bb5fe0cc2a469411 b/e0/a1876f6974f23b7e7c0701bb5fe0cc2a469411 new file mode 100644 index 000000000..86041721d --- /dev/null +++ b/e0/a1876f6974f23b7e7c0701bb5fe0cc2a469411 @@ -0,0 +1,192 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <gronager@ceptacle.com>) id 1Rss5s-0002lr-LA + for bitcoin-development@lists.sourceforge.net; + Thu, 02 Feb 2012 08:32:36 +0000 +X-ACL-Warn: +Received: from 2508ds5-oebr.0.fullrate.dk ([95.166.54.49] + helo=mail.ceptacle.com) + by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1Rss5o-0004bB-Ad for bitcoin-development@lists.sourceforge.net; + Thu, 02 Feb 2012 08:32:36 +0000 +Received: from localhost (localhost [127.0.0.1]) + by mail.ceptacle.com (Postfix) with ESMTP id 929731696A2A; + Thu, 2 Feb 2012 09:32:26 +0100 (CET) +X-Virus-Scanned: amavisd-new at ceptacle.com +Received: from mail.ceptacle.com ([127.0.0.1]) + by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new, + port 10024) + with ESMTP id s2yDxW1llbDu; Thu, 2 Feb 2012 09:32:25 +0100 (CET) +Received: from [10.0.1.28] (2508ds5-oebr.0.fullrate.dk [95.166.54.49]) + by mail.ceptacle.com (Postfix) with ESMTPSA id 5B5E81696A1A; + Thu, 2 Feb 2012 09:32:25 +0100 (CET) +Mime-Version: 1.0 (Apple Message framework v1251.1) +Content-Type: text/plain; charset=us-ascii +From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com> +In-Reply-To: <CAD2Ti29cto8wS1jO5yOkORbE48c+t6Of2vysXcA0xM9LKCOCgg@mail.gmail.com> +Date: Thu, 2 Feb 2012 09:32:24 +0100 +Content-Transfer-Encoding: quoted-printable +Message-Id: <4CE9708D-0627-480C-B928-3F812544CD90@ceptacle.com> +References: <D55C3D18-8286-44E9-B877-6FCE7C05E980@ceptacle.com> + <CAJna-HiS34V5rNrRfFOMRJ6JhRmS1aeEE3oA=o07Hgf4S6qNfw@mail.gmail.com> + <54950761-EBFB-402E-8D7B-0B54A08260D2@ceptacle.com> + <CAD2Ti29cto8wS1jO5yOkORbE48c+t6Of2vysXcA0xM9LKCOCgg@mail.gmail.com> +To: grarpamp <grarpamp@gmail.com> +X-Mailer: Apple Mail (2.1251.1) +X-Spam-Score: 0.0 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. +X-Headers-End: 1Rss5o-0004bB-Ad +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Announcement: libcoin +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Thu, 02 Feb 2012 08:32:36 -0000 + +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.=20= + +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[]) +{ =20 + logfile =3D 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. +>=20 +> 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... +>=20 +> 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. +>=20 +> 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: gronager@ceptacle.com +Web: http://www.ceptacle.com/ + + + |