Topic: bitcoind-ncurses: Terminal front-end for bitcoind (Read 11355 times)

This is for nodes. Never keep bitcoin online.

Welcome back.

I would like to point out that it would still be quite interesting if you can add support for accounts and wallets. Its a big part of what some companies need, due to the fact that we have the logic broken down on the accounts level directly from BitcoinD. Having a great overview in command line, vs. the output we have today would be a good features. Hope you can reconsider and have it added.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I, Atelopus Zeteki <[email protected]> am the owner of the public key:

0x47DA40099E00994C Daniel Edgecumbe <[email protected]>

and the GitHub username:

https://github.com/esotericnonsense

and the domain name:

https://esotericnonsense.com

The Daily Telegraph 2016-05-02 'Families in dark as doctors let patients die'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXJ1KsAAoJEOK9FOwsfUWP+CoQAKKyh/8MUlZxsahH+KjJG5Kf
3z/jcMZVJyyOD/Pc7Gd6Iy+LBWVenmUdwtRKeuzIENX/aZ0vU7bnXqNBPG3NgcQE
tMbewxEyMbdGUi7LqKdTB1yFiX+BODXL3v5WpUAGfhjbxNe8kXCErPp1iUQhErlc
Z5zK9+cmiCTqPQScaUsu4kQu0QsFILWa7wjs23OTMJRjxSYF1aXiqircwgsMg7Q9
9f6Xd9zGLL2mCFVB2rFvi+ROlOcMVZ2/DfVwydW0mbBe9u67AEbZjQ65Pjy5tkbJ
hByn10B55+sYYdbypFUTzVgmyhW8N3Lzz5yEkKYZHhCiNdP+uJaqDW7QV8f0M6uB
MMCpz+hppFQWdmq63VCbTE/GqbhDczeRr8h4UpJ5LNw9cWbPqrBIlbFLdzY7RWI6
nOP4fjce4YJHxCympo6ZP1PgZHLj6Yhdc5TcaSM+/cSQXF8BtmkdYFJHcpeZCch9
YWrGjpyxtr7X8+QCkXGGxlYN4AOoDk05CnT9ZS+tIonPLvTzF2RpOXJRH3wxNR74
Pr08SVDK95r7S9JJEknVGflKV++CeE0dtWBqseUBryKIqBNQKqSQmEjIuigWaCL7
nrOKngfI/m3GEu6nVtuUNnQZ22BDYgCyUV6b7qXCGAUhhuGzojnizNgls/UJpDzw
atwbohdtFZc5/BonemHP
=sBpY
-----END PGP SIGNATURE-----

Glad you're back

Well, it's been a while!

A few small tweaks have been made to the repo.
Andrew Chen helpfully posted a fix for Bitcoin Core v0.12 in my absence, which has now been merged.

I have changed my GitHub username - a PGP signed confirmation of this with the same key as my original post here will be forthcoming (currently battling with importing the key).

- esotericnonsense/azeteki

Hi JackH. Sorry for the delay in responding.

I have not added account tracking because my impression based on hanging around IRC is that accounts are a deprecated feature and may well end up being removed completely at some point.

Feel free to hack away and submit pull reqs if you are that way inclined though.

(The transaction/wallet side is really more of a curiosity than anything else to me personally at present.)

Just one question. Does it allow for overview of accounts and wallets connected to accounts?

I can easily see this being used vs a GUI if it can track accounts. Basically the RPC command known as " getaccountaddress " and "  getaccount " and " getaddressesbyaccount " and most importantly " getbalance  [account] [minconf=1]  " .

It would be by far the best tracker to track multiple accounts and values and movement of coins for a wallet service, or at least offer a different perspective.

This is really cool

It would be great if we could get following parameter :
Estimated  time to sync upto to latest block on network ..

Hi Amphibian,

I played around a bit and noticed ipv6 addresses exceed the cell width on the peers page.
https://github.com/azeteki/bitcoind-ncurses/pull/13



Really loving it.
--vertoe


/edit, I just released a basic version for darkcoin.

I use it on digital ocean, works perfectly on ssh

Live mempool transaction view would be cool

Thank you vertoe.

If anyone has used this over SSH or similar some feedback would be useful. I have only tested locally. Others have suggested ideas on how to emulate latency that I'll be looking into later.

I plan to introduce more configuration options at some point to avoid the need for people to go in and change hardcoded stuff.

For example, at present the RPC backend updates every 2 seconds and the monitor view every second. Over a high latency link this might be too often. You can change this if you know where to look but that's hardly ideal.

I would also appreciate feedback from anyone who has tried this on an RPi, Cubox or similar machine (e.g. top/htop cpu usage stats, if it's usable, etc.) That would help me to get an idea of where to focus development.

This is so awesome for managing bitcoin on webservers. Thanks for this gold.

Updated

v0.0.22.

Added some basic logging functionality which should help for debugging purposes and identify areas where speedups can be made. (getrawmempool vs. getnetworkinfo is a big one at present).
For now the loglevel is hardcoded in rpc.py. Right at the top is a function with 'if loglevel > x'.

loglevel 0: (default) Nothing.
loglevel 1: Regular updates, new blocks, halt request.
loglevel 2: All RPC requests.
loglevel 3: Time taken for bitcoind to respond to each RPC request.

Example at log level 2:


Screenshots have been updated with new functionality, see the second post in the thread or github.

v0.0.21 - basic addition of 'getchaintips' for users running master

Very small update that hopefully explains itself for users on git master. I imagine the feature will make it in to v0.10. Should fail safe on non-git though I've not tested.

I agree on the armory points.
Also thanks for the tool.  Very nice.

There would be a middle ground here: using the new watch-only addresses of bitcoind, you could delegate all the tracking to bitcoind. Private keys and coin control could then be handled by bitcoind-ncurses. Would be a nice compromise as it would allow you to get all the potential while getting around having to implement your own rescanning, indexing, and tracking code.


I think bitpop's suggestion of taking a look at armory is a good one. It's also written in python and solved most of these problems already. An ncurses interface to some of armory's functions (while relying only on bitcoind) would be an awesome combination!

Feature wise, what I would love is to see a ncurses interface to coincontrol: constructing transactions by selecting UTXOs from the list of available ones and computing fees following different schemes (free, pre 0.8.2, current, manual).


Indeed. I can only say: keep up the good work! Hope you'll find some income in the space that allows you to continue this work. If this ever happens to myself, I would happily donate as well...

Delete bitcoin-config.h and rerun autogen.sh.  Also make clean before building. Some of the changes we made have upset the build system for dirty build directories. Sorry for that. Hopefully this will get you going. You may also need to install libgmp-devel if you don't have it currently.

For standalone wallet, doesn't armory have a python library you can use?

gmaxwell,

I've missed being able to stay in touch with the field. Glad to see that bitcoin has not yet died.

getchaintips looks quite interesting. If I'm interpreting the source comments correctly (I can't compile and test right now) then it matches a feature I was intending to add to bitcoind-ncurses - monitoring forks and their eventual resolve.


Indeed.
There are a few different approaches to this whole business that I can think of.

The first is to rely on bitcoind to perform the wallet functionality. Tell bitcoind to send some coins, and bitcoind consults its' wallet.dat and so forth.
Least likely to go wrong, but limited in scope.

The second and more ambitious is to effectively produce a standalone wallet that uses bitcoind to connect to the p2p network only. In this case bitcoind-ncurses would have its' own 'wallet.dat' format, produce its own keys, do its' own coin control, and so on and so forth. Much more 'fun' for me, and also achieving the secondary aim of producing a viable split between the 'node' that is bitcoind and the 'wallet' that is bitcoind, but requiring that I really know what I'm doing.

What I would need to do to feel comfortable with either solution is to spend a lot of time studying how bitcoind achieves its' wallet functionality and also ensure that Python is even capable of producing a reasonably secure wallet (which would entail a fair amount of crypto-study).

To elaborate on the latter point - take a basic function like 'walletpassphrase'. This needs to be handled very carefully. You can end up in a situation where the passphrase sits around in RAM for the rest of all eternity after being used. Or perhaps the size of the program's RAM usage increases by some predefined way based on passphrase content. Maybe the query takes a different amount of time depending on the length of the password, etcetera. Some of these probably matter as side channel attacks and others may not. If I am to produce a wallet tool for general consumption then I have a moral obligation to do everything within my power to ensure that it is safe because people can and will use it to store lots of money.

It makes me very happy that people have found my work useful so far. Finding some solution to fund the roof over my head whilst also pursuing this sort of project remains the challenge we all struggle with.