Exploring alternative full node implementations - Gocoin

[ABCbits]

Intro

Inspired by tiltedIceCream reply[1] on thread "Why aren't alternative implementations encouraged?"[2], i'm inspirited to try alternative Bitcoin full node implementation. Based on Jameson Lopp benchmark[3], Gocoin seems to have good performance so i decide to give a try.

Basic info

• It's written in Go language (golang).
• It's solely developed by piotr_n[4].
• It has both full node and wallet functionally.
• It's developed since 2013[5].
• Gocoin load all UTXO to RAM.

My system

• Debian-based OS
• Old 6 core CPU
• 32GB RAM
• 3.5" HDD (Both Bitcoin Core and Gocoin data stored here)
• Bitcoin Core 23.0
• Gocoin 1.10.1

Compile and installation

The documentation[6] only mention i need git and golang on my system. Since it doesn't mention required golang version, i just use golang provided my distro. I receive golang 1.18.1 which is only slightly older than newest version (1.18.4[7]).

Code:

sudo apt update && sudo apt install golang-go
go version

When i read tweak page[8], Gocoin also support using external secp256k1 library from Bitcoin Core. So i decide to install secp256k1 on my system and clone Gocoin 1.10.1.

Code:

sudo apt-get install gcc automake autoconf libtool make git libgmp-dev
git clone --depth 1 --branch v23.0 https://github.com/bitcoin/bitcoin.git
cd bitcoin/src/secp256k1/
./autogen.sh
./configure --enable-module-schnorrsig
make
sudo make install

Using Gocoin built-in benchmark, external secp256k1 library have 40% faster performance on my system. So i decide to use external secp256k1 library by copying sipasec.go to parent directory.

Code:

git clone --depth 1 --branch 1.10.1 https://github.com/piotrnar/gocoin
cd lib/others/cgo/ec_bench/
go run gonative.go
go run sipasec.go

cd ../../../../client/speedups/
cp sipasec.go ..

Finally it's time to compile Gocoin. You could just compile the client to run full node, but i try to compile everything. It's straightforward and only took few seconds. Both client and wallet compiled with no problem, although 5 external Gocoin failed to compile. I only managed to fix utxo_compress and utxo_decompress after using latest code from Gocoin latest commit.

Code:

cd /path/to/gocoin
cd client/
go build
cd ../wallet/
go build
cd ../tools/
for item in *go; do go build $item; done;

Code:

# command-line-arguments
./utxo_benchmark.go:33:38: invalid operation: cannot slice k (variable of type int)
./utxo_benchmark.go:43:37: cannot use v (variable of type map[utxo.UtxoKeyType][]byte) as type []byte in argument to binary.LittleEndian.Uint32
./utxo_benchmark.go:51:32: cannot use k (variable of type int) as type utxo.UtxoKeyType in argument to utxo.NewUtxoRecStatic
./utxo_benchmark.go:51:35: cannot use v (variable of type map[utxo.UtxoKeyType][]byte) as type []byte in argument to utxo.NewUtxoRecStatic
./utxo_benchmark.go:59:26: cannot use k (variable of type int) as type utxo.UtxoKeyType in argument to utxo.NewUtxoRec
./utxo_benchmark.go:59:29: cannot use v (variable of type map[utxo.UtxoKeyType][]byte) as type []byte in argument to utxo.NewUtxoRec
# command-line-arguments
./verify_script.go:19:54: undefined: syscall.Proc
./verify_script.go:35:22: undefined: syscall.Syscall9
./verify_script.go:45:21: undefined: syscall.LoadDLL
# command-line-arguments
./verify_tx.go:24:42: undefined: syscall.Proc
./verify_tx.go:37:22: undefined: syscall.Syscall9
./verify_tx.go:47:21: undefined: syscall.LoadDLL

Initial Block Download (IBD)

Here's my gocoin.conf which mashed together from Jameson Lopp blog[3] and Gocoin documentation[9-10]. I also configure Gocoin only connect to my Bitcoin Core node. gocoin.conf should be located on directory where you run/launch client file.

Code:

{
    "Memory.CacheOnDisk": false,
    "LastTrustedBlock": "00000000000000000000dbf2ac1b8bbebf83f8d3bd9f9c4a6a5a250548291224",
    "AllBalances.AutoLoad": false,
    "UTXOSave.SecondsToTake": 0,
    "Net.ListenTCP": false,
    "Net.MaxOutCons": 20,
    "Memory.GCPercTrshold": 100,
    "Memory.UseGoHeap": true,
    "Stat.NoCounters": true,
    "Datadir":"/path/to/my/hdd",
    "ConnectOnly": "127.0.0.1:8333",
    "WebUI.ServerMode": true
}

The sync process took about 6.8 hours. As expected, HDD is the only bottleneck on sync process where my Bitcoin Core report sent speed 11-18MB/s speed. Gocoin RAM usage after IBD is 23.1GB, although it's reduced to 19GB after i close and open Gocoin again. Directory size of Gocoin is about 354GB, while Bitcoin Core is about 493GB (txindex, blockfilterindex, coinstatsindex enabled). I have to say Gocoin web UI is rather nice.




[1] https://bitcointalk.org/index.php?topic=5406961.msg60608073#msg60608073
[2] https://bitcointalk.org/index.php?topic=5406961.20
[3] https://blog.lopp.net/2021-bitcoin-node-performance-tests-2/
[4] https://bitcointalk.org/index.php?topic=199306.0
[5] https://github.com/piotrnar/gocoin/tree/aae8e1774fdfe8bae99bccb5c3fd6113ad7fbc95
[6] https://gocoin.pl/gocoin_installation.html
[7] https://go.dev/dl/
[8] https://gocoin.pl/gocoin_tweaks.html
[9] https://gocoin.pl/gocoin_performance.html
[10] https://gocoin.pl/gocoin_manual_config.html

[ABCbits]

WebUI

To access WebUI, just type 127.0.0.1:8833 or localhost:8833 on your Browser. You'll see homepage of Gocoin which show some statistic about your node. Most parts is easy to understand if you already use Bitcoin Core with primary intention to run full node. I don't what SPB refers though.



"Transactions" tab shows your node mempool. Compared with Bitcoin Core, Gocoin show more detail information about your node mempool statistic. You can enable/disable memory pool and transaction relay here. You also can upload and broadcast transaction as well. I haven't test this feature yet, so i don't know accepted transaction file format.



If you scroll down, you also can see list of transaction on your node mempool. It's quite detailed where it shows total signature operation and time to verify the transaction in milliseconds (ms). You also can choose how much transaction to be shown and how it's sorted.



"Blocks" tab show some newest blocks. It's quite interesting to see total signature operation of each block, which rarely shown on Bitcoin block explorer. The rest is something you can see on most block explorer.



"Miners" tab show statistic about miner during last 24 hours. I like how Gocoin show how much BTC earned by miner/pool from transaction fees.



"Counters" tab show lots of statistic about your node. Most of you won't find it's interesting, unless you're trying to analyze something.



TextUI

TextUI is available after you start Gocoin from terminal, load all UTXO/mempool to RAM and optionally start WebUI server. When you enter help, there are 56 available commands. But i'll just show few command here. By the way, the TextUI doesn't support key up to show previous typed command.

Code:

Gocoin client version 1.10.1
Using config file gocoin.conf
Using modernc.org/memory package to skip GC for UTXO records
Public auth key: @2295tiTyJeYkL8aroquqbuA8EEt5YPYCGQouSfGu7t9Gv
Using libsecp256k1.a for ECVerify, SchnorrVerify & CheckPayToContact
Blockchain open in 1m16.1746388s.  5078 + 9374 MB of RAM used (6024)
Connect to bitcoin network via 127.0.0.1:8333
1404 transactions taking 990429 Bytes loaded from mempool.dmp
201 transactions use 212 memory inputs
Starting WebUI at 127.0.0.1:8833
ssl_cert/ca.crt not found
> help
The following 56 commands are supported:
   allbal, ab - Show Allbalance statistics
   balance, a - List balance of given bitcoin address (or raw public key)
   ban - Ban a peer specified by IP
   bchain, b - Display blockchain statistics
   bip9 - Analyze current blockchain for BIP9 bits (add 'all' to see more)
   cache - Show blocks cached in memory
   configload, cl - Re-load settings from the common file
   configsave, cs - Save current settings to a common file
   configset, cfg - Set a specific common value - use JSON, omit top {}
   conn - Connect to the given node (specify IP and optionally a port)
   counters, c - Show all kind of debug counters
   dlimit, dl - Set maximum download speed. The value is in KB/second - 0 for unlimited
   drop - Disconenct from node with a given IP
   friends - Show current friends settings
   getmp, mpg - Send getmp message to the peer with the given ID
   help, h, ? - Shows this help
   info, i - Shows general info about the node
   inv - Send inv message to all the peers - specify type & hash
   kill - Kill the node. WARNING: not safe - use 'quit' instead
   maxouts, o - Show addresses with highest number of outputs [0,1,2,3 or count]
   mem - Show detailed memory stats (optionally free, gc or a numeric param)
   mempool, mp - Show the mempool statistics
   minerstat, m - Look for the miner ID in recent blocks (optionally specify number of hours)
   net, n - Show network statistics. Specify ID to see its details.
   newblock, nb - build a new block
   nodestat, ns - Shows all known nodes version statistics
   peeradd, pa - Add a peer to the database, mark it as alive
   peerdel, pd - Delete peer from the DB
   peers, p - Operation on pers database ('peers help' for help)
   pend - Show pending blocks, to be fetched
   purge - Purge all unspendable outputs from UTXO database
   quit, q - Quit the node
   rd - Show recently disconnected incoming connections
   redo - Redo last block
   richest, r - Show addresses with most coins [0,1,2,3 or count]
   savebl - Saves a block with a given hash to a binary file
   saveutxo, s - Save UTXO database now
   trust, t - Assume all donwloaded blocks trusted (1) or un-trusted (0)
   tx1send, stx1 - Broadcast transaction to a single random peer (identified by a given <txid>)
   txcheck, txc - Verify consistency of mempool
   txchild, ch - show all the children fo the given tx
   txdecode, td - Decode a transaction from memory pool (identified by a given <txid>)
   txdel, dtx - Remove a transaction from memory pool (identified by a given <txid>)
   txlist, ltx - List all the transaction loaded into memory pool up to 1MB space <max_size>
   txlistban, ltxb - List the transaction that we have rejected
   txload, tx - Load transaction data from the given file, decode it and store in memory
   txmpload, mpl - Load transaction from the given file (must be in mempool.dmp format)
   txmpsave, mps - Save memory pool to disk
   txsave - Save raw transaction from memory pool to disk
   txsend, stx - Broadcast transaction from memory pool (identified by a given <txid>)
   txsendall, stxa - Broadcast all the transactions (what you see after ltx)
   ulimit, ul - Set maximum upload speed. The value is in KB/second - 0 for unlimited
   unban - Unban a peer specified by IP[:port] (or 'unban all')
   undo - Undo last block
   utxo, u - Display UTXO-db statistics
   wallet, w - Enable (on) or disable (off) wallet functionality

allbal or ab shows Bitcoin distribution on each address. I just found out there are at least 11500 Bitcoin stored on Taproot address.

Code:

> ab
AllBalMinVal: 0.00100000   UseMapCnt: 100
AllBalancesP2KH:  9316080 records, 15769961 outputs, 8453062.37091608 BTC, 8065 maps
AllBalancesP2SH:  4880392 records, 8708172 outputs, 5060770.48319191 BTC, 4659 maps
AllBalancesP2WKH:  6008374 records, 9031904 outputs, 3097910.65303046 BTC, 2387 maps
AllBalancesP2WSH:  423467 records, 494987 outputs, 734667.71948642 BTC, 78 maps
AllBalancesP2TAP:  29907 records, 32859 outputs, 11509.20487519 BTC, 2 maps
Ready in 2.336s

balance or a show balance of an address or raw public key. The result is quite detailed which show when and how much an address receive Bitcoin. I really like this feature since it's fast and not exist on Bitcoin. But i wonder why the developer chose a as short hand option rather than b, bl or bal.

Code:

> a bc1qu8ujv03v0g4h4dpvempm9snkrrmrue4m5dsmtf
bc1qu8ujv03v0g4h4dpvempm9snkrrmrue4m5dsmtf has 0.06024620 BTC in 4 records:
     0.01468000 BTC 2760df3b1f0ca44b0f698a34017c7c70b631dfea2707c5ecdecacdb327b3494c-003 737049
     0.01528000 BTC 601fedd571bdfc1d2a1942820b8a215989a4183178b4b3bb9f22ecd1ccdd2540-002 740308
     0.01600750 BTC 4e3a91f58e2fb0669ab8430eb5c4271c75ad7d0be6f52b54fddebfff648791a1-004 744138
     0.01427870 BTC f811c517cc2cf53cf37cde949b58e1176edf9406e06ee229ca23e5977cb2ffce-001 746595
Ready in 0.001s

richest or r show Bitcoin address with most Bitcoin. It also can show richest Bitcoin addressed based on address type. I wouldn't use it much, but it's good this feature exist.

Code:

> richest help
Specify the address type or/and number of top records to display
Valid address types: 0-P2K, 1-P2SH, 2-P2WKH, 3-P2WSH, 4-P2TAP
Ready in 0.000s
> richest 1 5
Counting only addr type P2SH
5059253.17916417 BTC in 8708418 unspent recs from 4880479 P2SH addresses
Top addresses with at least 0.00000000 BTC: 4880479
1 34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo 252597.22065495 BTC in 141 inputs
2 3LYJfcfHPXYJreMsASk2jkn69LWEYKzexb 125351.13621699 BTC in 15 inputs
3 3M219KR5vEneNb47ewrPfWyb5jQ2DjxRP6 101266.00000000 BTC in 2 inputs
4 37XuVSEpWW4trkfmvWzegTHQt7BdktSKUs 94505.32948895 BTC in 11 inputs
5 3Kzh9qAqVWQhEsfQz7zEQL1EuSx5tyNLNS 66688.63295257 BTC in 157 inputs
Ready in 6.100s
> richest 4 20
Counting only addr type P2TAP
11509.27100655 BTC in 32859 unspent recs from 29907 P2TAP addresses
Top addresses with at least 0.00000000 BTC: 29907
1 bc1ptev79mgw2a8gva285qjx4waunsmwtscz86tv38wylggrvsrdtxdspyg8j7 2000.00089559 BTC in 2 inputs
2 bc1pgr6fsrurg8mz3rymkkfsagrl03dhaj5ep7da7kurhwftc433dynq6hn24l 675.00000000 BTC in 1 inputs
3 bc1pxt5ytk0x4zsx3mknaksy33wju537ry4j7gwnvv232lhgu7hthalqs5e9td 616.59237878 BTC in 1 inputs
4 bc1p6qspdmx9dl88udm8uw3g2m2sxnqcaz2u4jh8wujsz5766499w98qzm48yf 260.00000000 BTC in 1 inputs
5 bc1p6xvd3dkw05zm30ztwcmdlgc8cc5tg3umxr3spnrdfzaenyke9ezs4j6a27 212.71608460 BTC in 1 inputs
6 bc1pmxywlfzfwuucfy28udfgzu4nnm7kyakscvy80fyzzdggzxgvuw0s4g7897 210.92668965 BTC in 1 inputs
7 bc1p8v9752vmw730tc5hm05cuy62aegdngvrkes0qqfjjjrj2lt9s0yqhdv7ht 200.00000000 BTC in 1 inputs
8 bc1ppz5umrxdysczu7ks3q9u9rkhcctuvdamlcw8v88m6hw4vd3n6npqf9rrpj 178.12582122 BTC in 1 inputs
9 bc1pylqj8tcer64h2ampy00s8eq97vqmmkq0ecupe5rk4l8ulucc77xsqwpryg 169.33314128 BTC in 1 inputs
10 bc1ptw0jdnxmjyknrctlacvmgz0dkd28kfax3xq8rs7xm9ty3u0w9qls3hm9gf 150.00000000 BTC in 1 inputs
11 bc1pn7dm6hv05hmmkuqeqmw9a52rtlx9gqa6u746k2pqle0nua2psdasqdx6ww 139.70007253 BTC in 1 inputs
12 bc1pq9zdsct8ffh3nq9p2rwaj6jrrcpuydmnvrek3e0gjke0lnjpgjpq2h9tae 108.99998237 BTC in 1 inputs
13 bc1p2tv3e8qtksfas4xe7zpt8sya0tc4tm97mul3pv7p0psruf5t6npqe3und9 100.99825585 BTC in 1 inputs
14 bc1p5tx3jfy8yhmwqgh4y3j9uscy0vh24qxjpv0ey0pxqamsz7dn7f0qq3ggkn 100.10100000 BTC in 3 inputs
15 bc1pz25hq6hwp6fsgw2mkepu53q6tqqc57gyk0en45459727rhu7a35seeml2s 99.99999878 BTC in 1 inputs
16 bc1phf8s5phcur3tdf9684yxspz72vlqq99xy26lzw4fru0vvapkxjnqpy7q44 98.67490552 BTC in 2 inputs
17 bc1pa63l4zkwjhq54ucnxkgjwqga3ge7c4mzqqgc9d4s3va2s7e7ga7s2qdt5e 88.96373094 BTC in 1 inputs
18 bc1pk5rcyd308ld4e9dkd8yehd602tr5c5xrgh2ewmgj8y9fk44mnsnqcwp59l 85.02946910 BTC in 1 inputs
19 bc1pv6pe8wfp6yq2np6j6npqhfsavjpsdaemp4kv87usx9zw8lxssfmquhz525 81.39410000 BTC in 3 inputs
20 bc1pj66nqend9wsey6dd5q7cqvxq97y70pey7j0lswgmvwmwcnylynvsfsuaau 80.00174160 BTC in 1 inputs
Ready in 0.034s

Gocoin configuration

As i said earlier, Gocoin can be configured through gocoin.conf file. But i just realized you can edit it from WebUI homepage. But what surprise me is there are few field which isn't mention on Gocoin config documentation[1] which are RPC., TXPool.Debug and Memory.FreeAtStart. The RPC is limited to experimentation mining API though[2], so it's not interesting feature for me.



Reducing RAM

Since Gocoin RAM usage is quite high, i tried to reduce it's RAM consumption. Based on Gocoin documentation page[1,3]. there are few action i could do. First action is compressing UTXO records. With tools i compiled earlier, it only reduce UTXO.db file from 8.5GB to 8.2GB on the HDD. Second action is modifying gocoin.conf which involve memory, you can see my modification below.

Code:

{
    ...
    "Memory": {
        "GCPercTrshold": 20,
        "UseGoHeap": false,
        "MaxCachedBlks": 24,
        "CacheOnDisk": true,
        "PurgeUnspendableUTXO": true
    },
    ...
}

I managed to reduce RAM consumption to ~14.9GB. IMO it's rather small reduction since Gocoin usually use 17-19GB RAM. But there's nothing much i could do since Gocoin still store all UTXO to RAM.



Conclusion

Aside from RAM usage, Gocoin appear to be decent Bitcoin full node implementation. It's very impressive single developer write Gocoin alone. I don't need instant access to UXO though, so Gocoin isn't suitable for me. But even if i do, the RPC currently limited to mining-related feature.

Some things i like,
* Minimum dependency with easy compilation process
* Lots of features on TextUI
* Neat WebUI, although some feature only available on TextUI
* Lots of external tools
* Fast sync time, which only hold back by my HDD


Some things i don't like,
* Load all UTXO to RAM
* Incomplete documentation
* RPC only support mining-related feature, even though many feature exist on TextUI


[1] https://gocoin.pl/gocoin_manual_config.html
[2] https://gocoin.pl/gocoin_issues.html
[3] https://gocoin.pl/gocoin_tweaks.html

[n0nce]

Thanks for the experiment and the great writeup. I've been toying with the idea of spinning up another node with an alternative implementation a while ago.

The sync process took about 6.8 hours. As expected, HDD is the only bottleneck on sync process where my Bitcoin Core report sent speed 11-18MB/s speed. Gocoin RAM usage after IBD is 23.1GB, although it's reduced to 19GB after i close and open Gocoin again. Directory size of Gocoin is about 354GB, while Bitcoin Core is about 493GB (txindex, blockfilterindex, coinstatsindex enabled). I have to say Gocoin web UI is rather nice.

This is the only thing worrying me a bit: 19GB of memory usage is a lot. Not that RAM is expensive, but some nodes simply don't have that much built-in.
Do you know whether Gocoin bases its RAM usage on how much total RAM is available or would it be creating a 3+GB pagefile on a 16GB machine?

And can you compare with Bitcoin Core's memory usage on the same system?

[PawGo]

Thanks for the experiment and the great writeup. I've been toying with the idea of spinning up another node with an alternative implementation a while ago.

The sync process took about 6.8 hours. As expected, HDD is the only bottleneck on sync process where my Bitcoin Core report sent speed 11-18MB/s speed. Gocoin RAM usage after IBD is 23.1GB, although it's reduced to 19GB after i close and open Gocoin again. Directory size of Gocoin is about 354GB, while Bitcoin Core is about 493GB (txindex, blockfilterindex, coinstatsindex enabled). I have to say Gocoin web UI is rather nice.

This is the only thing worrying me a bit: 19GB of memory usage is a lot. Not that RAM is expensive, but some nodes simply don't have that much built-in.
Do you know whether Gocoin bases its RAM usage on how much total RAM is available or would it be creating a 3+GB pagefile on a 16GB machine?

Exactly my question. I assume it uses what is available, as project has already several years I am not sure if having more than 16GB was so obvious years ago. I really wonder how it would behave on machine with 8GB total (which means it would have around 6GB free, to use).
Would it be possible for you to launch it with limited memory settings? (maybe using cgroups?)

[DaveF]

According to their github page yes, you need AT LEAST 16GB of RAM

Hardware

client:

    64-bit architecture OS and Go compiler.
    File system supporting files larger than 4GB.
    At least 16GB of system RAM.

Seems very excessive. Yes it does a lot but still 16GB for most people that makes it a non starter. If I'm running it on my 'main PC' that would mean I need more then 16GB so I could do other stuff.
If I am running it on an older spare PC, that probably means I need to buy more RAM or just run core. Which can run fine on a much lower end system.

Still nice to have more options.

-Dave

[n0nce]

According to their github page yes, you need AT LEAST 16GB of RAM

Hardware

client:

    64-bit architecture OS and Go compiler.
    File system supporting files larger than 4GB.
    At least 16GB of system RAM.

Interesting, thanks for looking it up. A bit rushed from my side not to check myself.

Seems very excessive. Yes it does a lot but still 16GB for most people that makes it a non starter. If I'm running it on my 'main PC' that would mean I need more then 16GB so I could do other stuff.
If I am running it on an older spare PC, that probably means I need to buy more RAM or just run core. Which can run fine on a much lower end system.

One of my nodes was a laptop with 4GB of RAM and upgrading it to 8GB gave the initial block download an amazing speed boost. But for normal operation it would get along just fine with 4. I know people for whom 8GB is totally fine on their daily driver machine, so yeah, for maximum accessibility (think: lower income countries, etc.) requiring 16GB is definitely too high. My belief is that low system requirements are needed for the best shot at true decentralization.

But I guess it comes with the choice of programming language (Go). It would be great seeing a Rust implementation, since that should in theory give almost just (?) as performant code as C. In fact, Core Lightning is moving away from C and rewriting things in Rust.

[pooya87]

But I guess it comes with the choice of programming language (Go). It would be great seeing a Rust implementation, since that should in theory give almost just (?) as performant code as C. In fact, Core Lightning is moving away from C and rewriting things in Rust.

Technically speaking speed and efficiency is not decided based on what language was used (at least for most modern languages this is true). The implementation and the developer's expertise decides whether the code is fast or not.

[NotATether]

Why is all that RAM needed, to make one giant dbcache? The majority of servers have only 16GB of RAM, so I don't see this client being used by a lot of nodes.

[ABCbits]

Do you know whether Gocoin bases its RAM usage on how much total RAM is available or would it be creating a 3+GB pagefile on a 16GB machine?

But I guess it comes with the choice of programming language (Go). It would be great seeing a Rust implementation, since that should in theory give almost just (?) as performant code as C. In fact, Core Lightning is moving away from C and rewriting things in Rust.

Why is all that RAM needed, to make one giant dbcache? The majority of servers have only 16GB of RAM, so I don't see this client being used by a lot of nodes.

Gocoin simply load all UTXO to RAM.

The client (p2p node) is an application independent from the wallet. It keeps the entire UTXO set in RAM, providing an instant access to all its records and - in consequece - an extraordinary blochchain processing performance.

And can you compare with Bitcoin Core's memory usage on the same system?

I don't see the point, since it's heavily based on your dbcache value. IIRC it only use 1-2GB RAM although dbcache value is far higher.

Would it be possible for you to launch it with limited memory settings? (maybe using cgroups?)

If you could show tutorial without installing lots of application or recompiling kernel, i could do a quick test.

[n0nce]

But I guess it comes with the choice of programming language (Go). It would be great seeing a Rust implementation, since that should in theory give almost just (?) as performant code as C. In fact, Core Lightning is moving away from C and rewriting things in Rust.

Technically speaking speed and efficiency is not decided based on what language was used (at least for most modern languages this is true). The implementation and the developer's expertise decides whether the code is fast or not.

It is, though. For instance, a (modern) interpreted language like Python will be slower than a compiled C binary that does the same task.
So in general, I wouldn't say that speed and efficiency are completely unrelated to chosen language.

I am not knowledgeable enough about Go to explain well why it performs worse than C, but in a similar task (running a Lightning node), the Go implementation has been causing lots of issues for people and I was under the impression that Go is harder to optimize than C or Rust since it's more higher level / more abstract. But I may be wrong, that's just what I read online.

Gocoin simply load all UTXO to RAM.

The client (p2p node) is an application independent from the wallet. It keeps the entire UTXO set in RAM, providing an instant access to all its records and - in consequece - an extraordinary blochchain processing performance.

Okay, I mean it does have a benefit then. I guess it will depend on your application. It's going to be rare, but whoever runs services that need 'instant access to all UTXOs' may want to actually run Gocoin. Especially since if they are optimizing Bitcoin Core for similar UTXO access performance, they may increase dbcache to a similar value anyway.

[ABCbits]

I finally finished writing my experiment with Gocoin, it took longer than expected. Does anyone have suggestion what alternative implementations i should check next? But please don't suggest one of these,
1. Mako. It's still on heavy development, https://github.com/chjj/mako#development-status.
2. Bitcoin Knots. It's fork of Bitcoin Core, so i don't expect major difference with Bitcoin Core.
3. Libbitcoin version 4. I have negative experience with it, https://bitcointalk.org/index.php?topic=5329445.msg56811006#msg56811006.

Gocoin simply load all UTXO to RAM.

The client (p2p node) is an application independent from the wallet. It keeps the entire UTXO set in RAM, providing an instant access to all its records and - in consequece - an extraordinary blochchain processing performance.

Okay, I mean it does have a benefit then. I guess it will depend on your application. It's going to be rare, but whoever runs services that need 'instant access to all UTXOs' may want to actually run Gocoin. Especially since if they are optimizing Bitcoin Core for similar UTXO access performance, they may increase dbcache to a similar value anyway.

That makes sense, but currently Gocoin RPC only limited to mining-related feature. People who need instant access to all UTXO need to find workaround with Gocoin's Text UI.

[NotATether]

Why is all that RAM needed, to make one giant dbcache? The majority of servers have only 16GB of RAM, so I don't see this client being used by a lot of nodes.

Gocoin simply load all UTXO to RAM.

The client (p2p node) is an application independent from the wallet. It keeps the entire UTXO set in RAM, providing an instant access to all its records and - in consequece - an extraordinary blochchain processing performance.

I can see this becoming an operational problem if the UTXO set doubles or triples at any given time, then GoCoin will simply run out of memory before it can load all the UTXO sets. Why not just load the most recent UTXOs, if short of RAM? It's more likely that recent coins will be spent before dormant coins anyway.

[n0nce]

Why is all that RAM needed, to make one giant dbcache? The majority of servers have only 16GB of RAM, so I don't see this client being used by a lot of nodes.

Gocoin simply load all UTXO to RAM.

What I don't understand is that the UTXO set is not this large. I am checking again, but it should be in the 4-5GB range; at least it was last I checked.

Code:

bitcoin@localhost:~> du -sh chainstate/
4.8G	chainstate/

This would fit on my system in RAM by just setting -dbcache=5000 or something like that, even though I only have 8GB of system memory. Keep in mind I also have electrs and lightningd running.

Code:

bitcoin@localhost:~> free -h
              total        used        free      shared  buff/cache   available
Mem:          7.5Gi       1.2Gi       520Mi       3.0Mi       5.7Gi       6.0Gi
Swap:         2.0Gi       1.0Gi       1.0Gi

It could actually have something to do with the choice of programming language after all, as I mentioned before. Similar issues (high system resource utilization, hard to optimize / reduce) were reported by various people when using lnd (Go) instead of c-lightning (C).

[...]
But I guess it comes with the choice of programming language (Go). It would be great seeing a Rust implementation, since that should in theory give almost just (?) as performant code as C. In fact, Core Lightning is moving away from C and rewriting things in Rust.

[pooya87]

It could actually have something to do with the choice of programming language after all, as I mentioned before. Similar issues (high system resource utilization, hard to optimize / reduce) were reported by various people when using lnd (Go) instead of c-lightning (C).

I wish I knew more about GO to be able to give a technical answer but I still believe that optimizing code depends mostly on the developer not the language.
For example if you implement UTXO like this in C# you'll get a lot of overhead because of the way the byte array is stored elsewhere in the memory then a reference to its position is stored inside the struct with a bunch of other overhead that increases the total memory consumption.

To give you an idea about severity of this in C#, I was running an analysis on block headers and the program was consuming more than 200 MB. With some tweaks I brought it back down below 100 MB and closer to the file size itself which is about 60 MB.
I use this example because people generally think C# is slow too which is not correct.

P.S. FWIW the live UTXO size could be fetched from here: https://statoshi.info/d/000000009/unspent-transaction-output-set

[n0nce]

It could actually have something to do with the choice of programming language after all, as I mentioned before. Similar issues (high system resource utilization, hard to optimize / reduce) were reported by various people when using lnd (Go) instead of c-lightning (C).

I wish I knew more about GO to be able to give a technical answer but I still believe that optimizing code depends mostly on the developer not the language.
For example if you implement UTXO like this in C# you'll get a lot of overhead because of the way the byte array is stored elsewhere in the memory then a reference to its position is stored inside the struct with a bunch of other overhead that increases the total memory consumption.

To give you an idea about severity of this in C#, I was running an analysis on block headers and the program was consuming more than 200 MB. With some tweaks I brought it back down below 100 MB and closer to the file size itself which is about 60 MB.
I use this example because people generally think C# is slow too which is not correct.

After searching a bit online, it seems that Go has a built-in garbage collector that can indeed use memory a bit lavishly. However it can be improved, such as described here.
https://medium.com/safetycultureengineering/analyzing-and-improving-memory-usage-in-go-46be8c3be0a8

I can't say for sure, but it's possible that these Bitcoin Go projects that have higher memory usage than their C and Rust counterparts are simply not optimized like that. So in that case you would be right that it depends on the developers. Would love to see them get more optimized so they run on cheaper hardware, which is where people generally like to run their nodes (be it Raspberry Pis at MSRP or used x86 hardware).

P.S. FWIW the live UTXO size could be fetched from here: https://statoshi.info/d/000000009/unspent-transaction-output-set

That's handy!

Gocoin simply load all UTXO to RAM.

What I don't understand is that the UTXO set is not this large. I am checking again, but it should be in the 4-5GB range; at least it was last I checked.

Code:

bitcoin@localhost:~> du -sh chainstate/
4.8G	chainstate/

--snip--

FYI, UTXO file on Gocoin is 8.5GB (or 8.2GB uncompressed). I also expect Gocoin UTXO size on RAM is higher since it need to be deserialized.

You think it takes more than double the amount of memory to store it deserialized? So if I were to set my node's dbcache to something like 5GB in Bitcoin Core, it wouldn't fit the whole UTXO set?
And why is it 8.5GB instead of <5.. Another multiple GB wasted - I think there's a lot of optimizing potential for this software before being widely used.

[ABCbits]

FYI, UTXO file on Gocoin is 8.5GB (or 8.2GB uncompressed). I also expect Gocoin UTXO size on RAM is higher since it need to be deserialized.

You think it takes more than double the amount of memory to store it deserialized? So if I were to set my node's dbcache to something like 5GB in Bitcoin Core, it wouldn't fit the whole UTXO set?
And why is it 8.5GB instead of <5.. Another multiple GB wasted - I think there's a lot of optimizing potential for this software before being widely used.

It's not impossible if you ask me. Deserialized transaction on Bitcoin Core mempool is far higher than 2x. Looking at https://statoshi.info/d/000000020/memory-pool at 2022-07-30 09:10:00, totalTxBytes is 993KB but it's mempool memory usage is 4.94MB.

[NotATether]

FYI, UTXO file on Gocoin is 8.5GB (or 8.2GB uncompressed). I also expect Gocoin UTXO size on RAM is higher since it need to be deserialized.

You think it takes more than double the amount of memory to store it deserialized? So if I were to set my node's dbcache to something like 5GB in Bitcoin Core, it wouldn't fit the whole UTXO set?
And why is it 8.5GB instead of <5.. Another multiple GB wasted - I think there's a lot of optimizing potential for this software before being widely used.

There is little that can be optimized in the UTXO data format, for example it certainly cannot be compressed using zlib or zstd because these only give paltry returns in space, but require at least linear time to decompress every time you need to check a UTXO set.

At the end of the day, it really is down to the language you use. Even interpreters that are built on top of C++ tend to use much more resources for small programs than the equivalent codebase written directly in C++ (and even using a modest number of class objects).

[PowerGlove]

{...} Since Gocoin RAM usage is quite high, i tried to reduce it's RAM consumption {...}

{...} Would it be possible for you to launch it with limited memory settings? {...}

{...} What I don't understand is that the UTXO set is not this large. I am checking again, but it should be in the 4-5GB range; at least it was last I checked {...}

Since a good amount of the discussion has been about excessive memory usage, I just wanted to leave this excerpt from the release notes [1] of Go 1.19 (released ~6 days ago):

{...} The runtime now includes support for a soft memory limit. This memory limit includes the Go heap and all other memory managed by the runtime, and excludes external memory sources such as mappings of the binary itself, memory managed in other languages, and memory held by the operating system on behalf of the Go program. This limit may be managed via runtime/debug.SetMemoryLimit or the equivalent GOMEMLIMIT environment variable {...}

I haven't tried it, but maybe this will be of help to someone looking to get Gocoin's memory usage under control.

[1] https://go.dev/doc/go1.19#runtime

[PowerGlove]

If i understood the release note correctly, it require modification Gocoin source code.

You'll have to recompile with 1.19 to be on the new runtime, but I don't think changing Gocoin's source code is necessary. The soft memory limit can be configured via the new GOMEMLIMIT environment variable [1].

Like I said, I haven't experimented with this, it just caught my eye and I remembered this thread.

[1] https://go.dev/doc/gc-guide#Memory_limit