Topic: Gocoin - totally different bitcoin client with deterministic cold wallet - page 9. (Read 38500 times)

Super, it's down to ~2.2GB now and ~1% CPU after restart. I will try to play around with the wallet and/or code.

Try to exit it and restart. The memory consumption should go lower. Normally it does not go above 3GB at my PC.
As for the 30% CPU - it should not happen in between new blocks. Unless you are receiving lots of txs and the node is busy verifying them.
You can disable relying transactions by editing the config file - then the CPU woudl only be busy while verifying new blocks (every 10 minutes on average).

If you play with the source code, that should be easy to add.
Just put the addresses that you want to monitor inside the wallet and look into client/main.go, where it does:
This is printing some message each time a balance on any of the wallet's addresses changes.
Add there whatever you need  e.g. a call to http.Get(...) and you should have the functionality you seek.

Also remember that the wallet.BalanceChanged is set only when a new relevant txs has been mined into a block (so not for yet-unconfirmed transactions).

Ok, now it finished.

- ok with wallet error, not using wallet yet
- network socket error message is gone now, check
- network tab shows many connections, check

And it has all the blocks now. Great !  It also has 6GB of my RAM and 30% CPU, so i might have to move it to a server : )

I plan to maybe use it for my address monitor (my hobby version of triplespeeder's bicoinmonitor.net) - he is using a bitcoind fork that hits a url on new transactions, can your tool do something similar? Also how do you recommend querying gocoins version of the utx base for address balances? (the tools/fetchbalance.go uses blockchain.info api, would like to get it all locally)

Thanks again !

This just tells you where to put a wallet - a text file with your public addresses (each address in new line).

This is unusual. Do you have any other app bound to TCP port 8833?
Aren't you by a chance running two instances of the client, at the same time?

When you go to the Network tab - are there any net connections established?

Yes - it keeps a history of which unspent outputs were added/removed with each block, in case if there was a fork and it had to unwind the changes while switching to a different  branch.
But it is now set to 5000 blocks - I'm not aware of such a deep forks ever happening in the past.

Anyway, if you want to restart importing the DB, fetch the new init.cpp (this one does not abort on error) and delete the entire folder d:\data\gocoin\btcnet
See how it goes then.
And make sure that you are not running two instances of the client.

Hi Piotr

Thanks for your help. If i restart it goes:

Using NewEC wrapper for EC_Verify
Gocoin client version 0.8.1
Opening blockchain... (Ctrl-C to interrupt)
Blockchain open in 35.300 seconds
open d:\data\gocoin\btcnet\wallet\DEFAULT: The system cannot find the file specified.
open d:\data\gocoin\btcnet\wallet.txt: The system cannot find the file specified.
Starting WebUI at 127.0.0.1:8833 ...
> ListenTCP listen tcp4 0.0.0.0:8333: Only one usage of each socket address (protocol/network address/port) is normally permitted.

When i go to the webui the last blockheight is 238773, so at first glance it does not seem like it's downloading anything beyond the orphaned block where it crashed.

Can you help me on the mechanisms behind one block being more orphaned than another? , just for my own understanding, thx. For example height 226794 also splits, but it is "less orphaned" than 233046. Is it because there is too many blocks between the output being created and then later referenced in a spend? If yes, why does it occur on a orphan, could it also have occured on a main chain block?

I will try commenting out the errors as in the new submit. Would everything still be in sync, theres some comment about unwind buffer not being able to handle...?

Thanks : )

 

Thanks for reporting.

It looks like it aborted importing blocks from the satoshi's db, because there was some very orphaned block inside.
But if you re-launch the client after this - it should download all the further blocks from the internet, haven't it?

You can also take a new client/init.go and see how it goes then - in the updated version it prints the error but continues with converting the db.

Hi Piotr

Thank you for your work on this. I am trying it out, but getting an error on block 00000000000000560719da7088be587ea9c3018cfbbfae2dd2540682185c034b (#233046). It says:

.....
7474.8MB of data processed. We are at height 234765. Processing speed 10.507MB/sec, recent: 12853.3KB/s
7582.1MB of data processed. We are at height 235421. Processing speed 10.510MB/sec, recent: 10967.8KB/s
7710.2MB of data processed. We are at height 236155. Processing speed 10.541MB/sec, recent: 13109.1KB/s
7850.1MB of data processed. We are at height 236949. Processing speed 10.588MB/sec, recent: 14325.8KB/s
7958.2MB of data processed. We are at height 237625. Processing speed 10.586MB/sec, recent: 10700.6KB/s
8087.1MB of data processed. We are at height 238516. Processing speed 10.616MB/sec, recent: 13185.7KB/s
CheckBlock failed: CheckBlock: Block 00000000000000560719da7088be587ea9c3018cfbbfae2dd2540682185c034b hooks too deep into the chain: 233046/238760 000
00000000000e76cddac91bfdbf51a73f31ec740e07d651fba24f381289965

Do you maybe know what could be wrong. Im on windows 8, 64bit golang. I chose not to verify scripts.

Thanks ! : )

This month's update: changes up to version 0.8.0

Wallet
It does not show characters on screen while a user is entering the seed-password.
The solution is unfortunately platform dependent and requires MinGW in case of Windows.
If you cannot compile the wallet anymore, you can switch this feature off - just delete "wallet/hidepass_*.go"

Client
From the things that only devels care about, the structure of the code in the "client/" folder has been hugely reworked.
It isn't all-in-one anymore, but contains sub-packages.

As for the useful features, starting from version 0.7.6 there is a new tab on WebUI: MakeTx.
MakeTx allows the user to select (in a GUI-like matter) the specific outputs that he wants to spend and produces the exact command line that shall be executed.
It creates the "balance/" folder for the wallet, along with "pay_cmd.txt" file containing the command to be executed at the wallet's PC in order to sign the requested tx.
An example screenshot of how the new feature looks in your browser: http://imgur.com/JyIRZJl

FetchBalance
Recently I have also created quite a useful tool that can fetch a balance of your wallet from the popular block explorers.
I tried to use only one of them, but could not find a fully satisfying API and ended up needing both; blockchain.info & blockexplorer.com
Not every transaction can be recovered this way, but most of them should work. If any transaction cannot be fetched and decoded properly, it will inform you.

I will try to add a proxy support for it later, so you could easily fetch your wallet's balance using Tor.

Using this tool you do not need an online node anymore; only the small wallet app, and you have a fully functional and secure bitcoin brain/deterministic/cold wallet solution.
It is a single file tools/fetchbal.go - compile it to an executable, or use "go run" on the source.

Not having the client, you can just use blockchain.info/pushtx to broadcast the signed transactions coming from the wallet.

---

If anyone would like to try any of the pieces, but does not want to play with building the s/w himself, I can provide binaries for Windows or Linux.
Also, if you built and tried it on Mac, please let me know whether it works - I am curious to know, but have no apples here.

A quick update for people interested in this project, if such even exist

Wallet
Considering the Android's RNG incident and the rumors that other systems might also be "NSA friendly", I modified the wallet app in a way that its security does not rely on random number source anymore. Note that it never had for private key calculation (since it uses deterministic wallet driven by a password-seed), but it did for signing, and now it doesn't even for signing.

Client
I ported sipa's secp256k1 lib (the 10x26 option) to Go. It is now a default option for ECDSA signature checks, so there is no need to struggle with C compilers anymore to get a decent performance.
It performs better than the openssl wrapper (so also better than your current satoshi client), though is still like 3-5 times slower from the cgo wrapper using an original secp256k1 lib.
The openssl wrapper is still there, if you prefer to use it (having a security concerns). Same applies for the native ECDSA lib, though this one is still deadly slow.

There were also some fixes around accessing maps from different threads that were not properly protected, which was causing memory leaks - this should be fixed now.

Plus plenty of other things, not really worth mentioning, like a new command to purge orphaned blocks from the database, or replaced block's gzip compression with snappy (performs much better).

Thanks.
I've actually made a huge progress ever since I published this topic - lots to talk about, most things I don't remember, though I try to keep the changelog up to date.

From the know issues part, it still uses lots of system memory, which I could probably address by moving the UTXO db to leveldb, but since I have 12GB of RAM on my PC, I just don't care about these 4GB. And knowing that the leveldb would make fetching a balance of a random address extremely slow (comparing to what I have now), it discourages me even more from optimizing the mem usage.

And there is still this EC_Verify that works very slowly while using the standard go libs, so one of the cgo wrappers should be used, but building it, especially on windows, is a bit of a hassle.

Besides that, I'm quite satisfied with this project - these days Gocoin is the only bitcoin client I use and whoever has not tried it can only regret

this seems a very good ideia. i really like your feature set.
i'm gonna to some more reading and digging around. Hopefully i'm going to try it out soon.

Thanks

GO is awesome

great job

at least one

is it live in the network?

This is a reasonable, rational and admirable stance.

They were. Another thing that I found very useful were maps.

Sweet.  I'll take a look.


It would be interesting to see how Go's special benefits could be proven in a bitcoin client.

Of course - it would be a huge waste to not use such a great feature, and also go routines...
Though not really so much of it, at least at this stage.

If you grep the sources for "chan" or "go", you can find the places.

Awesome.  Thanks for bringing Go to Bitcoin.


Re: Go's special channel interfaces.  Any benefit for a Bitcoin client?

Thanks for an advise, but I am doing well, not working for a corp that cuts a large part of my work's fruits, to pay for their stupid marketing, just so stupid people could be jumping up an down...

Just a "thanks, I like your client and I actually use it" from a random person - that's all I need as an incentive for my work.