Competing nodes - List of BTC implementations in competition for the Blockchain

[HostFat]

This is a list of the competing full nodes currently available.

Some of them may have rules that can results in a soft fork and/or a hard fork, so you have to understand them before choosing which one you will install on your system.
Near the name of the node there can be a "flag" -> HF - This means that if a majority of the network (usually over a % of blocks) will update to this node over the most used before, than it will hard fork.
But, you should always check for updates on their official website to be sure about last minute updates.

I'll try to maintain this list updated as possible.
Advices are welcome.

The discussion is self-moderated, I'll probably delete spam (and paid sig spam) and trolling.

The first is the most used node currently, the others are in random order.


Bitcoin Core
Site: https://bitcoincore.org
Code: https://github.com/bitcoin/bitcoin

BTCD (new implementation in Go)
Code: https://github.com/btcsuite/btcd

Bitcoin Unlimited (Core fork) - HF
Site: http://www.bitcoinunlimited.info
Subreddit: https://www.reddit.com/r/bitcoin_unlimited
Code: https://github.com/BitcoinUnlimited/BitcoinUnlimited

Bitcoin Classic (Core fork) - HF
Site: https://bitcoinclassic.com
Subreddit: https://www.reddit.com/r/bitcoin_classic
Code: https://github.com/bitcoinclassic

Bitcoin Knots (Core fork)
Site: http://bitcoinknots.org/
Code: https://github.com/luke-jr/bitcoin

Bitcoin XT (Core fork) - HF
Site: https://bitcoinxt.software
Subreddit: https://www.reddit.com/r/bitcoinxt
Code: https://github.com/bitcoinxt/bitcoinxt

BitcoinJ (common used as Java SPV node only, it has an experimental full verification)
Site: https://bitcoinj.github.io/full-verification
Code: https://github.com/bitcoinj/bitcoinj
Release notes: https://bitcoinj.github.io/release-notes

Toshi (new implementation in Ruby)
Site: https://toshi.io/
Code: https://github.com/coinbase/toshi

The Bitcoin Foundation (not "Bitcoin Foundation" - Fork of old Bitcoin code)
Site: http://thebitcoin.foundation/
Code: http://btc.yt/lxr/satoshi/source/

Haskoin (new implementation in Haskell)
Code: https://github.com/haskoin/haskoin

Libbitcoin (new implementation in C++)
Site: https://libbitcoin.org
Code: https://github.com/libbitcoin/libbitcoin

Bcoin (new implementation in Javascript)
Site: http://bcoin.io - http://bcoin.io/browser.html
Code: https://github.com/bcoin-org/bcoin


Blocks stats
https://coin.dance/blocks
http://nodecounter.com/#bitcoin_classic_blocks

Node stats:
https://bitnodes.21.co
https://coin.dance/nodes
http://nodecounter.com

Fee & Size stats (other stats?)
https://www.btc.com/en/stats/block-size
https://statoshi.info/dashboard/db/fee-and-priority-estimates

Bitcoin website (different owners)
https://bitcoin.org
https://www.bitcoin.com
http://bitcoinforks.org - Proposing hard forks

General subreddit:
https://www.reddit.com/r/bitcoin - Against hard fork
https://www.reddit.com/r/btc - Open to hard fork
https://www.reddit.com/r/Btcfork - Proposing hard forks

[1713547326]

1713547326

[1713547326]

1713547326

[achow101]

Are these all software that will fork the blockchain? If so, I don't think Btcd and Bitcoin LJR belong since they don't implement anything that would fork.

[HostFat]

Are these all software that will fork the blockchain? If so, I don't think Btcd and Bitcoin LJR belong since they don't implement anything that would fork.

No.

I've added this text:
"Some of them may have rules that can results in soft fork and hard fork, so you have to understand them before choosing which one you will install on your system."

Do you think that it's better to show a "flag" to indicate that the node will push for an hard fork over the most used one node?

EDIT
Added

[achow101]

Are these all software that will fork the blockchain? If so, I don't think Btcd and Bitcoin LJR belong since they don't implement anything that would fork.

No.

I've added this text:
"Some of them may have rules that can results in soft fork and hard fork, so you have to understand them before choosing which one you will install on your system."

Do you think that it's better to show a "flag" to indicate that the node will push for an hard fork over the most used one node?

EDIT
Added

OK. Thanks for the clarification.

In that case, I have an addition, BitcoinJ. It is primarily SPV but it does have an experimental full node implementation.

Edit: also, I think that this site: https://bitcoin.org/en/bitcoin-core/ is bitcoin core's official page than bitcoincore.org is. It has more info and the downloads are hosted there.

[HostFat]

bitcoincore.org is going to be the official website of Bitcoin Core. (I think that it is already official)
Links to the download are already present here https://bitcoincore.org/en/releases/0.11.2/

They are updating it day by day, bitcoin.org is already well known as website and it's more a general website.

[achow101]

bitcoincore.org is going to be the official website of Bitcoin Core. (I think that it is already official)
Links to the download are already present here https://bitcoincore.org/en/releases/0.11.2/

They are updating it day by day, and bitcoin.org is already well known as website.

Those are just release notes. The actual downloads are still on bitcoin.org.

[HostFat]

I've added bitcoin.org as bitcoin website.

On https://bitcoincore.org/en/releases/0.11.2/ there is also the link to download binaries on bitcoin.org.
I'm sure that they'll add them on bitcoincore.org as well.

[Amph]

i'm fairly certain that none of those will get any real consensus besides core,

core is aiming as well to increase the limit to 2mb, so the other are obsolete

they seems like a way, for some dev to say " this version is mine, i made it..."

[shorena]

Toshi.io (full node in ruby) -> https://github.com/coinbase/toshi

[canth]

i'm fairly certain that none of those will get any real consensus besides core,

core is aiming as well to increase the limit to 2mb, so the other are obsolete

they seems like a way, for some dev to say " this version is mine, i made it..."

Do you have any updates showing that core devs are moving toward a 2MB max block size? I agree that they are going to have to do it eventually but communication from Core devs have been relatively quiet this week after most miner (pools) indicated they would use Classic (if needed) to move to 2MB blocks via a HF. I am not looking to get into yet another debate about the merits of block size, just wanted to see if you had any info I don't.

(deleted image - waiting for a better miner representation)

[Lauda]

Do you have any updates showing that core devs are moving toward a 2MB max block size? I agree that they are going to have to do it eventually but communication from Core devs have been relatively quiet this week after most miner (pools) indicated they would use Classic (if needed) to move to 2MB blocks via a HF. I am not looking to get into yet another debate about the merits of block size, just wanted to see if you had any info I don't.

This picture is false, F2 does not support Classic. Please stop posting it around.

[canth]

Do you have any updates showing that core devs are moving toward a 2MB max block size? I agree that they are going to have to do it eventually but communication from Core devs have been relatively quiet this week after most miner (pools) indicated they would use Classic (if needed) to move to 2MB blocks via a HF. I am not looking to get into yet another debate about the merits of block size, just wanted to see if you had any info I don't.

This picture is false, F2 does not support Classic. Please stop posting it around.
[/img]

Fair enough - I searched and wasn't able to find F2Pool thoughts on Classic. Edited my original post - there's enough other pools that support Classic at this point, it's not to be ignored.

[Amph]

i'm fairly certain that none of those will get any real consensus besides core,

core is aiming as well to increase the limit to 2mb, so the other are obsolete

they seems like a way, for some dev to say " this version is mine, i made it..."

Do you have any updates showing that core devs are moving toward a 2MB max block size? I agree that they are going to have to do it eventually but communication from Core devs have been relatively quiet this week after most miner (pools) indicated they would use Classic (if needed) to move to 2MB blocks via a HF. I am not looking to get into yet another debate about the merits of block size, just wanted to see if you had any info I don't.

(deleted image - waiting for a better miner representation)

https://bitcoin.org/en/bitcoin-core/capacity-increases-faq, they want to do it via segregate witness

[canth]

i'm fairly certain that none of those will get any real consensus besides core,

core is aiming as well to increase the limit to 2mb, so the other are obsolete

they seems like a way, for some dev to say " this version is mine, i made it..."

Do you have any updates showing that core devs are moving toward a 2MB max block size? I agree that they are going to have to do it eventually but communication from Core devs have been relatively quiet this week after most miner (pools) indicated they would use Classic (if needed) to move to 2MB blocks via a HF. I am not looking to get into yet another debate about the merits of block size, just wanted to see if you had any info I don't.

(deleted image - waiting for a better miner representation)

https://bitcoin.org/en/bitcoin-core/capacity-increases-faq, they want to do it via segregate witness

At best, that's a 1.7M block size equivalent. The miners supporting 2M blocks via Classic are well aware of SW. I'm also very supportive of SW although less so for the accounting trick scalability increase and more so for the new scripting features and malleability fix. Back to my original point, no Core does not support a 2M block size via HF which is what miners (among others) are now pushing for.

[HostFat]

@shorena
Added.

Fair enough - I searched and wasn't able to find F2Pool thoughts on Classic. Edited my original post - there's enough other pools that support Classic at this point, it's not to be ignored.

https://bitcointalk.org/index.php?topic=700411.msg13571787#msg13571787

Policy change announcement: We support the hard fork effort to increase the max block size to 2MB. Seg-wit may be deployed together in this hard fork if it can be ready in time, or it can be merged later. Non-controversial features in the hard fork wishlist, if it does not delay the hard fork process, can be deployed at the same time. The hard fork should be implemented in Core, eventually. “Bitcoin” Classic, which despite was born on the same day that XT dies, is an attempt that could make the hard fork happen sooner. We welcome Classic. We are going to cease support for FSS-RBF after upgrading to version 0.12, some time in the next few weeks. We may not implement the opt-in RBF feature. We believe that we should do everything we can do to make 0-conf transactions as secure as possible. We do not believe the concept of fee market.

[LiteCoinGuy]

thx for making this HostFat, i think that is a valuable summary. is theymos allowing that these days?  

[HostFat]

thx for making this HostFat, i think that is a valuable summary. is theymos allowing that these days?  

I hope so, but please avoid this argument here now.

[Amph]

i'm fairly certain that none of those will get any real consensus besides core,

core is aiming as well to increase the limit to 2mb, so the other are obsolete

they seems like a way, for some dev to say " this version is mine, i made it..."

Do you have any updates showing that core devs are moving toward a 2MB max block size? I agree that they are going to have to do it eventually but communication from Core devs have been relatively quiet this week after most miner (pools) indicated they would use Classic (if needed) to move to 2MB blocks via a HF. I am not looking to get into yet another debate about the merits of block size, just wanted to see if you had any info I don't.

(deleted image - waiting for a better miner representation)

https://bitcoin.org/en/bitcoin-core/capacity-increases-faq, they want to do it via segregate witness

At best, that's a 1.7M block size equivalent. The miners supporting 2M blocks via Classic are well aware of SW. I'm also very supportive of SW although less so for the accounting trick scalability increase and more so for the new scripting features and malleability fix. Back to my original point, no Core does not support a 2M block size via HF which is what miners (among others) are now pushing for.

it's equivalent of 1.75 mega at minimum, and it can be expanded to be above 2MB, and anyway 2mb, is a temporary step toward the issue, so having 1.75 or 2mb will not change anything

in case tere will be a saturation of the 2mb limit, having 1.75 will suffice with a little delay on the transaction, much better than what happened with the stress test

[achow101]

Fairly certain that bitcore: https://bitcore.io/ is a full node software as well.

[canth]

it's equivalent of 1.75 mega at minimu, and it can be expanded to be above 2MB, and anyway 2mb, is a temporary step toward the issue, so having 1.75 or 2mb will not change anything

in case tere will be a saturation of the 2mb limit, having 1.75 will suffice with a little delay on the transaction, much better than what happened with the stress test

Huh? SW cannot get more than a 1.75x increase on its own. I'm unaware of any on-chain throughput increases that can be had as a soft fork, other than the SW accounting trick.

1) We have no idea when SW will be ready for release. It's over 500 lines of code that need to be reviewed, very much unlike a max block size increase.
2) We have no idea when most wallets will be ready to accommodate SW.
3) We don't really know whether miners will charge lower fees for SW transactions and theoretically incentivize users to upgrade and start using SW transactions rather than typical transactions.

I'm a big fan of some of the features that SW brings, but it's not a sure bet that this has any effect on throughput in 2016. Even if it does, the number of daily transactions has been growing quickly enough that we'll need a 2017 solution as well, and this brings up the 2MB + SW block size increase. There's a reason that miners aren't jumping on board SW alone.