Adding transaction creation would be awesome, even though it's risky business.
Topic: bitcoind-ncurses: Terminal front-end for bitcoind - page 2. (Read 11314 times)
BTW, anyone ever used this on a production system?
Adding transaction creation would be awesome, even though it's risky business.
Adding transaction creation would be awesome, even though it's risky business.
I just discovered this.
This is awesome!
Thanks a lot for making this.
I love console guis.
This is awesome!
Thanks a lot for making this.
I love console guis.
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.
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.
I check for updates weekly
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'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.
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'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
. My peers page has no heights
You're running a non-git version of bitcoind. Next major version will have them for you.Gotcha
My peers page has no heights
You're running a non-git version of bitcoind. Next major version will have them for you.
My peers page has no heights
WRT peer height.
The syncheight is based on what the peer has advertised to us, so if a peer is not synced up yet its syncheight will be -1. You might want to fall back to displaying the starting height there if and only if it's value is more than one less than your current height and syncheight is -1.
The syncheight is based on what the peer has advertised to us, so if a peer is not synced up yet its syncheight will be -1. You might want to fall back to displaying the starting height there if and only if it's value is more than one less than your current height and syncheight is -1.
Beautiful thank you
I wanted to thank all of the people who have used and tested bitcoind-ncurses so far and especially those who have donated.
It is a good feeling to know that your work is appreciated. So, thank you all very much.
It is a good feeling to know that your work is appreciated. So, thank you all very much.
Updated to v0.0.20.
A few small additions:
Errors field, for example 'This is a pre-release test build' for development releases
(note that this is only checked on boot; it does not refresh as of yet, this is planned)
Transaction view no longer quits the program if a tx is not found
Transaction verbose mode now colours outputs according to their spent/unspent status
A number of modularization updates that should ease code accessibility and speed up the program in areas
Monitor view now displays implicit hashrate as per diff (the hashrate that would be required to sustain average 10 minute block rate)
Peer view now displays node sync height and time connected
Monitor view now displays estimatefee data (on bitcoind development release only)
RPCSSL support (untested by me; thanks to PRab and mikegogulski on GitHub)
A few small additions:
Errors field, for example 'This is a pre-release test build' for development releases
(note that this is only checked on boot; it does not refresh as of yet, this is planned)
Transaction view no longer quits the program if a tx is not found
Transaction verbose mode now colours outputs according to their spent/unspent status
A number of modularization updates that should ease code accessibility and speed up the program in areas
Monitor view now displays implicit hashrate as per diff (the hashrate that would be required to sustain average 10 minute block rate)
Peer view now displays node sync height and time connected
Monitor view now displays estimatefee data (on bitcoind development release only)
RPCSSL support (untested by me; thanks to PRab and mikegogulski on GitHub)
By looking at his screenshot I'm guessing that btcd doesn't support all the newest bitcoin rpc calls. From the screenshot I can see he had to remove chainwork display as I think it was only added via getblockchaininfo relatively recently to bitcoin core.
No; that should fail over safely.
A lot of the items on the monitor view should just disappear if the required info can't be obtained.
'disablewallet' support for example just works de facto because the getbalance req fails, and so nothing is displayed.
Not everything is totally safe against this (I don't really sanity check the information from bitcoind; if getblock reports no hash it might die, for example).
Unfortunately I don't really have the prereqs to test things like btcd.
My system is old and rather slow.
bitcoind reindex takes me a few weeks for example.
Hopefully at some point I will be able to justify buying a new system.
What needed modifying for btcd?
First issue was just getting it to run on Windows.
https://github.com/PRab/bitcoind-ncurses/commit/d13bfd3a59c86b097593d746c4f4b910eb355659
After that, I needed to figure out why btcd wasn't working. Nothing needed to change in btcd, but btcd requires SSL. I haven't been able to get SSL to work for bitcoind/bitcoin-qt so it was a bit tricky for me to test.
https://github.com/azeteki/bitcoind-ncurses/issues/5
https://github.com/jgarzik/python-bitcoinrpc/issues/35
After a bit of pain and debugging I successfully got bitcoind-ncurses working for both btcd and bitcoind simultaneously!
[...]
[...]
What needed modifying for btcd?
By looking at his screenshot I'm guessing that btcd doesn't support all the newest bitcoin rpc calls. From the screenshot I can see he had to remove chainwork display as I think it was only added via getblockchaininfo relatively recently to bitcoin core.
After a bit of pain and debugging I successfully got bitcoind-ncurses working for both btcd and bitcoind simultaneously!
[...]
[...]
What needed modifying for btcd?
After a bit of pain and debugging I successfully got bitcoind-ncurses working for both btcd and bitcoind simultaneously!
Probably a matter of personal taste...
My plan is to move towards making hotkeys configurable via .conf or similar.
I actually don't really like J/K for block navigation either.
It used to be left/right but after adding the footer and allowing left/right to navigate views I changed it.
As a side note, this is trivial to change without even knowing Python, though unwieldy. Go into hotkey.py, look for keymap = {... and change the keys that map block_seek_forward_one and block_seek_back_one.
I just git pulled from a1989f3 to 6276b9f and noticed that now it's way faster to move among the transactions in the wallet, well done on this!
Originally I had a lazy time.sleep in both the RPC and interface threads, just to get up and running.
Now it's more sensible. The sleep function waits on data.
So if a message is passed from RPC to interface or vice versa, response should be instant, rather than waiting for the next iteration of the loop.
If you want some real fun, turn up your keyboard repeat rate to max.
Probably a matter of personal taste but I find the J/K bindings counterintuitive to move among blocks. I'd expect J to go to the next block instead of the previous one since J is usually used to move forward. Re: "HOME/END: quicker" I'd use PgDn/PgUp for that, and maybe relegate Home/End to even larger jumps.
Although if it were me, I'd use H/L to browse blocks and J/K to move up/down in the transaction list, both in the Block and Wallet windows. Specifically, not having J/K in the Wallet window bugs me somewhat.
I just git pulled from a1989f3 to 6276b9f and noticed that now it's way faster to move among the transactions in the wallet, well done on this!
Although if it were me, I'd use H/L to browse blocks and J/K to move up/down in the transaction list, both in the Block and Wallet windows. Specifically, not having J/K in the Wallet window bugs me somewhat
.I just git pulled from a1989f3 to 6276b9f and noticed that now it's way faster to move among the transactions in the wallet, well done on this!
Jump to: