bitcoind-ncurses: Terminal front-end for bitcoind

[bitpop]

My peers page has no heights

You're running a non-git version of bitcoind. Next major version will have them for you.

Gotcha

[aquarat]

This application is awesome, thank you azeteki.

I've been considering using something like a Trezor for storing my BTC for quite some time... but I think that putting an old PC to work as a wallet is better (seeing as it's in a safe, is secured behind multiple firewalls and is only electronically accessible via SSH). At the moment I do everything on the CLI, but your app makes it a lot easier/visually appealing to work with bitcoind on a terminal.

Thanks again .

[azeteki]

This application is awesome, thank you azeteki.

I've been considering using something like a Trezor for storing my BTC for quite some time... but I think that putting an old PC to work as a wallet is better (seeing as it's in a safe, is secured behind multiple firewalls and is only electronically accessible via SSH). At the moment I do everything on the CLI, but your app makes it a lot easier/visually appealing to work with bitcoind on a terminal.

Thanks again .

I am glad to hear that you found it useful.

As of late a number of life issues has meant that I've had to take a step back from Bitcoin for the time being.
With a little luck I may be able to continue development (in addition, I would like to branch outside of bitcoind-ncurses and pursue a number of other ideas).
The world will decide this in time.

[bitpop]

I check for updates weekly

[gmaxwell]

I'm sad to have not heard from you for a while...

Though I'd come by to point out: If you get some time and interest again; git master getchaintips rpc should be a pretty nice source of information for another screen in this tool.

[arnuschky]

I just discovered this.
This is awesome!
Thanks a lot for making this.
I love console guis.

[arnuschky]

BTW, anyone ever used this on a production system?

Adding transaction creation would be awesome, even though it's risky business.

[azeteki]

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.

Adding transaction creation would be awesome, even though it's risky business.

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.

[bitpop]

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

[gmaxwell]

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.

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.

[arnuschky]

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.

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.

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.

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).

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.

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...

[spin]

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).

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.

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...

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

[azeteki]

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.

[azeteki]

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:

Code:

2014-12-20 21:35:52.247 LL2 rpcrequest: getinfo
2014-12-20 21:35:52.250 LL1 CONNECTED
2014-12-20 21:35:52.350 LL1 updating (2.103s since last)
2014-12-20 21:35:52.350 LL2 rpcrequest: getnettotals
2014-12-20 21:35:52.354 LL2 rpcrequest: getconnectioncount
2014-12-20 21:35:52.356 LL2 rpcrequest: getrawmempool
2014-12-20 21:35:52.365 LL2 rpcrequest: getbalance
2014-12-20 21:35:52.371 LL2 rpcrequest: getunconfirmedbalance
2014-12-20 21:35:52.373 LL2 rpcrequest: getblockcount
2014-12-20 21:35:52.375 LL1 === NEW BLOCK 335144 ===
2014-12-20 21:35:52.375 LL2 rpcrequest: getblockhash
2014-12-20 21:35:52.377 LL2 rpcrequest: getblock
2014-12-20 21:35:52.429 LL2 rpcrequest: getrawtransaction
2014-12-20 21:35:52.434 LL2 rpcrequest: getdifficulty
2014-12-20 21:35:52.437 LL2 rpcrequest: getnetworkhashps
2014-12-20 21:35:52.439 LL2 rpcrequest: getnetworkhashps
2014-12-20 21:35:52.442 LL2 rpcrequest: estimatefee
2014-12-20 21:35:52.444 LL2 rpcrequest: estimatefee
2014-12-20 21:35:52.446 LL1 update done in 0.096s
2014-12-20 21:35:53.197 LL1 interface request: {'stop': True}
2014-12-20 21:35:53.197 LL1 halting RPC thread on request by user

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

[bitpop]

Updated

[vertoe]

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

[azeteki]

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.

[bitpop]

I use it on digital ocean, works perfectly on ssh

Live mempool transaction view would be cool

[vertoe]

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.

[btc_enigma]

This is really cool

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