Gocoin - totally different bitcoin client with deterministic cold wallet

[fronti]

nice client and the downloader is really fast, cool work!

but a question, i see that you "only" support ipv4 in the client. will you plan to support ipv6 also?
Then I can setup some more nodes

[1713482525]

1713482525

[1713482525]

1713482525

[1713482525]

1713482525

[1713482525]

1713482525

[1713482525]

1713482525

[piotr_n]

thanks. ipv6 suport will eventually come. it just hasn't' got high enough priority so far.

[piotr_n]

OK... After a several changes in Gocoin, currently it does everything up till (including) b89.

Two blocks do not return the expected result:

b48 - block with the time stamp more than 2 hours in the future.
I cannot properly against the blocks data from the disk, but I trust I didn't screw up this check.

b61 - same ID of a coinbase TX.
I'm not going to be adding a check for this, as it can only happen with v1 bocks, which are long gone.

In a future, when I find some more time, I will try to somehow fix the tests tool; make it stable and test all my further gocoin releases against it.
Will also do the remaining "massive reorgs" tests...


Thank you once again, @hhanh00 - I really appreciate your input.
It helped me to find (and fix) another few compatibility issues, on the blocks checking.
Some of the checks in Gocoin were too strict (e.g. b64), others (e.g. b66) were not strict enough.

A friend of mine modified the original tool for me.
Now it's feeding the test blocks (one-by-one) to an external command.

This allowed me to make a simple wrapper for the gocoin library in order to test the blocks compatibility.
All test pass, except for b61, which I am not going to fix as it would decrease performance of the lib, just for the sake of the test. So I implemented a work-around in the wrapper, for this specific test.
All the rest is passing - up till the block "b1004", which is the last one in the test suite.

If anyone would like to test it by himself, or use the java tool my friend made to test their own software, it's all in here:
https://github.com/piotrnar/btc_block_validator

Start the tool using

Code:

java -jar bitcoin.jar

.. it will be executing a command next_block.exe in the current folder for each new block.
The block is always in file named dupa.bin - just ignore the first 8 bytes.
Additionally next_block.exe is called with 5 command line arguments. One of them is the hash of the top block expected to be after the block processing is done - that's how you verify whether the block from dupa.bin is properly processed/rejected.

[piotr_n]

Just want to let everyone know that with the new HEAD (to become version 1.7.0) there is kind of a major change in the node.       

The node client does not keep any wallet data anymore - not in the file system, nor it RAM.
Instead the wallets' public addresses are stored in the LocalStorage, on the browser that operates node's WebUI.
The improvement is that a balance of any (P2SH or P2KH) address can be fetched instantly.
Balances of specific wallets are now fetched by the browser while loading a relevant page (Wallet or SendTx) of the WebUI.
The content of the HTTP request (list of addresses) is not stored at the node's side.

At this moment you can only fetch balance of P2SH and P2KH addresses - the support for stealth addresses has been turned off.
Additionally, all the wallet features have been disabled in TextUI.

Because it needs to build the database of all the addresses and their balances, the node launches significantly longer now.
It also requires more RAM - I changed the RAM requirement to 8GB.

Please note that (to save memory and improve performance) by default the balance database does not account for unspent outputs with less than 0.001 BTC.
You can change that by modifying the config value "AllBalances.MinValue" (set it to 1 to have everything listed).


I believe this is a change in a good direction.
It allows multiple users (wallet owners) to share the same gocoin node; improves performance of fetching the balances, as well as the privacy by not storing the content of the requests.

If you like the old functionality (with stealth addresses and wallet files stored at the server), checkout version 1.6.4

[piotr_n]

Just a quick update on the latest development, to let you know that I am still alive and the project is being maintained

The latest release 1.7.2 comes with some nice features.

I've been happy to learn that the core team finally did something to speed up the blocks' propagation - that came with 0.13.
Therefore with pleasure, I have implemented BIP-152 into Gocoin - I love this new method.

I've also optimised the algorithm of dropping worse (slowest) peer, in order to be connected to the best performing ones.
Now it considers not only the ping, but mostly the number of a new blocks we have received from a peer.

The full list of changes, as always, in the changelog.

[r.o.o.t]

Great work you are doing here !
What would you think about decred.org from the developers of other golang bitcoin client ?

[piotr_n]

What would you think about decred.org from the developers of other golang bitcoin client ?

Sorry, I don't have an opinion.

I'm too much involved in my bitcoin stuff and have no time to look into alternative-crypto projects.
I rarely even look in other bitcoin projects - mostly if they have something I might want for myself

[piotr_n]

Sorry for not updating for so long.

I've been travelling for the last couple of months, so no development, just field testing.
It should last for a couple of more months and then I will be back.

Before I left, I made version 1.8.0 - I've just tagged it, as it's been quite stable.
I have it running on my windows laptop and a linux VPS and it has been working fine for the last couple of months.
Once I had to restart it, as it hanged after over 50 days of uptime - I have some ideas why, will try to fix it, but first would like to see it happening again.
Also it well rejected the invalid block mined recently by BU node, although there was also something I will have to look at, as I found one debug of when it happened weird.

Anyway, the current 1.8.0 has segwit support and a few other cool things, and it's stable.
I got rid of the downloader, as the client is now able to sync the chain just as fast (with some additional command line switches).


As for the future development.

When I come back home, I want to make it possible to bootstrap (and further run) the node with only the block headers and a corresponding UTXO snapshot.
Basically it will be possible to run the full node without downloading and keeping the blockchain on the disk.
It will only keep the headers and the UTXO db. At this moment it's about 3GB of data.
Obviously it will be an optional feature and you will still be able to keep (and serve) all the blocks, if you please.

I've been thinking to establish some industry-wide standard for distributing a secured (first by the community signatures, later ideally by the chain protocol itself) UTXO snapshots, but it's not going to happen any soon, as it seems to be involving shit loads of politicking.
So I will just start with my own little solution and see from there, because I find this feature quite necessary already, as new people are very reluctant to try full nodes since they need so much time to bootstrap. Plus the blocks on my travel laptop have already taken so much space that I had to start removing porn, and that's really disturbing

[piotr_n]

I have a new update, but first of all I'd like to know if anyone is actually reading this.
Please let me know if you do and if you'd like to read some updates in this topic, or I won't be wasting my energy on this forum thread.

The 1.9.0 release has some reorgs inside the source code and the architecture in general.
It should perform even better.

Since the UTXO db only gets updated on new blocks, I decided to simply the approach and just keep a snapshot of it on the disk.
It's being flushed to disk after each update (new block), but at a vert low priority so it doesn't take too much system resources.

Now the whole UTXO database is caried by the single UTXO.db file, which is about 2.4 GB big.
When you start the new client, it should convert your old "unspent4" DB to the new format automatically.

Also, if you want to bootstrap a new node, you only need this file and the block headers file (about 60MB).
I can distribute the quick bootstrap files, if anyone is interested.

Which brings me to the point that the recent versions of gocoin node can work with purged blocks database.
If your blocks happen to be taking too much space, just close the client and execute:

Code:

bdb -purgeall

Or:

Code:

bdb -purgeto <block_height>

This will either purge all blocks or only up ot the given height.
Follow the instructions on the screen as you need some extra copying/deleting, just to be safe and not delete you blocks DB by accident.

Again: make sure to not have the client node running while using the bdb tool.

[sgbett]

Brilliant presentation at Future of Bitcoin. Your client looks really good, hopefully it will get you some more recognition!

[piotr_n]

thank you

[xcsler]

Great presentation at the Future of Bitcoin!

[LightRider]

How can I unban a peer?

[piotr_n]

How can I unban a peer?

You can start the client with -unban to unban all peers.

[Jace]

Hi Piotr, I saw your presentation at The Future of Bitcoin in Arnhem last week (I'm one of the Arnhem Bitcoincity organisers ) and that was awesome! Very interesting, you're doing great work!

I'd love to set up a new Bitcoin node using Gocoin. Would a Raspberry Pi 3 with Ubuntu be sufficient? I assume it would need to have 16 GB of ram? (is that even possible?) And perhaps a 256 or 512 GB SDcard? Or do you recommend something more powerful, e.g. a barebone miniPC?

[piotr_n]

Thanks.

You need at least 8 GB of RAM.
I'm unaware of any raspberry pi having that much.

As soon as you have a Linux board with that much ram, there should be no problem to run gocoin there.
It is possible, but I'm not sure if anything like this (cheap arm cpu board with 8+GB of RAM) is available on the market.

As for the storage space requirement, you can purge blocks database regularly,  in which case 16 GB of storage should be enough.

If you want to keep the entire block chain though, you need about 120 GB, as of today.

[piotr_n]

An important announcement, concerning the possible 2x fork next month.

Unlike the other self proclaimed bitcoin experts, my professional opinion is that miners do rule the bitcoin protocol.
A chain with the most POW is the one to follow - that's how the system has been designed and that's the only way it can work securely.
Whether I like this fact or not is irrelevant.

It is somehow likely that starting from block #494784 the majority of the miners will choose to mine 2x bigger blocks.
That is why the current version of Gocoin (not yet tagged, but see the HEAD) is already made to accept 2x bigger blocks, starting from #494784.

If the fork does happen, the node will use the branch with a bigger POW - without discriminating any of the two consensus choices.
If the fork doesn't happen or in a longer term the 2x branch will not get the mining majority, the code consensus change will eventually get removed from the source code.

If anyone does not like it and want to stick to the old rules, you need to edit the file "lib/chain/chain.go" and comment out (remove) the line with:
[q]ch.Consensus.S2XHeight = 494784[/q]

Now, excuse me, I have to go buy some popcorn


Edit 11th Nov 2017:
Fork cancelled - consensus changes removed.

[Polygora]

Thanks for this, really helping me decipher the internals of these technologies.

[bengems]

What's up with xgox? Is the development still alive?....because people are dumping their stash without looking back as if there is a bad news on xgox.

What news is causing all the panic sell?

[piotr_n]

If anyone is interested, the (not yet tagged) version 1.9.4 of gocoin supports native segwit addresses (the ones in bech32 format).

I've used them for a couple of weeks already and they seem to have been working just fine.
Still, make sure to verify your signed transaction before broadcasting it.

Spending from a native segwit address might cut your transaction fee by as much as half - that's when you have your coins already deposited at a native segwit address.

Let me know if you need a help using it.
Basically "Segwit Deposit Addresses" for your existing (traditional) wallet are automatically shown in the Wallet tab of the web interface.
And you can enter bech32 encoded addresses in the MakeTX tab for output addresses.
Use the new version of wallet app to sign the transaction that either spends from or to a new (bech32 encoded) address.

Obviously, the backward compatible P2SH segwit address types are working as well, but that's a very old news (I think 1.9.0)
Still better to use the native segwit addresses (in bech32 format) as they make fairly cheaper transactions.

As for the moment you need the gocoin client to spend from your native segwit addresses.
It's because none of the block explorers used by balio tool supports fetching their balances yet.

Some screenshots:
https://imgur.com/ACWUAh8
https://imgur.com/gqGYXUY

Cheers