bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 17, 2014, 02:41:21 AM |
|
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
Newbie
Offline
Activity: 16
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 13, 2014, 12:29:14 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) .
|
|
|
|
azeteki (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 96
Merit: 10
esotericnonsense
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 30, 2014, 06:55:51 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) . I am glad to hear that you found it useful. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Legendary
Offline
Activity: 2912
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 30, 2014, 09:26:45 PM |
|
I check for updates weekly ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8684
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 30, 2014, 11:40:33 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 01, 2014, 12:19:07 AM |
|
I just discovered this. This is awesome! Thanks a lot for making this. I love console guis.
|
|
|
|
arnuschky
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 01, 2014, 12:20:18 AM |
|
BTW, anyone ever used this on a production system? Adding transaction creation would be awesome, even though it's risky business. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
azeteki (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 96
Merit: 10
esotericnonsense
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 01, 2014, 01:04:06 AM Last edit: December 01, 2014, 01:15:04 AM by azeteki |
|
gmaxwell, I've missed being able to stay in touch with the field. Glad to see that bitcoin has not yet died. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Legendary
Offline
Activity: 2912
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 01, 2014, 01:56:00 AM |
|
For standalone wallet, doesn't armory have a python library you can use?
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8684
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 01, 2014, 11:17:19 AM |
|
gmaxwell, I've missed being able to stay in touch with the field. Glad to see that bitcoin has not yet died. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 01, 2014, 11:44:28 AM |
|
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. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2014, 09:52:34 AM |
|
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. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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.
|
If you liked this post buy me a beer. Beers are quite cheap where I live! bc1q707guwp9pc73r08jw23lvecpywtazjjk399daa
|
|
|
azeteki (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 96
Merit: 10
esotericnonsense
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2014, 07:09:19 PM |
|
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. ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fraw.githubusercontent.com%2Fazeteki%2Fbitcoind-ncurses%2Fmaster%2Fscreenshots%2Fbitcoind-ncurses-forks.png&t=665&c=gwD-Uqv_ZAhW1A)
|
|
|
|
azeteki (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 96
Merit: 10
esotericnonsense
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 20, 2014, 09:40:25 PM |
|
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: 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
Legendary
Offline
Activity: 2912
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 20, 2014, 09:54:56 PM |
|
Updated
|
|
|
|
vertoe
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 22, 2014, 10:56:01 AM |
|
This is so awesome for managing bitcoin on webservers. Thanks for this gold.
|
|
|
|
azeteki (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 96
Merit: 10
esotericnonsense
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 22, 2014, 12:03:08 PM |
|
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
Legendary
Offline
Activity: 2912
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 22, 2014, 12:19:07 PM |
|
I use it on digital ocean, works perfectly on ssh
Live mempool transaction view would be cool
|
|
|
|
|
btc_enigma
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 24, 2014, 10:09:01 PM |
|
This is really cool
It would be great if we could get following parameter : Estimated time to sync upto to latest block on network ..
|
|
|
|
|