Are there other open source Bitcoin full node wallets other than bitcoin.org?

[OtherFullnode]

Hi,

are there other open source Bitcoin full node wallets other than bitcoin.org?

Thanks

[Lauda]

Not really, and if it isn't listed there there is usually a good reason why.

[HCP]

Note that of the 4 "full node" wallets listed on bitcoin.org, Armory requires Bitcoin Core to function correctly anyway and mSigna hasn't been updated since August 2017.

So for a Full Node, your basic options are Bitcoin Core or Bitcoin Knots.

[OmegaStarScream]

Take a look at this (C#): https://github.com/stratisproject/StratisBitcoinFullNode

It doesn't look like something for the average user though.

[Carlton Banks]

So for a Full Node, your basic options are Bitcoin Core or Bitcoin Knots.

what about btcd? I think that's still keeping up, but I have no idea as to how well it supports the protocol.



But when it comes to full nodes, a monoculture works better. If the miners were all using alternative versions of Bitcoin full nodes, the chances that the network would fork because of differing bugs would be much higher.

This already happened back in 2013, even with the Bitcoin Core monoculture (although it didn't have that brand name back in 2013). The way blocks were stored on disk changed in version 0.8.0, and all the 0.8.0 nodes split themselves off into a complete separate fork of the Bitcoin blockchain for a few dozen blocks before everyone noticed. The 0.8.0 code had to be fixed to stop that happening, and everyone mining/running a node rolled back to 0.7.3 to stay on the main chain while the fix was being coded.

I know alot of people will be all "muh choice of client", but reality/logic is a bitch. You can choose: a different coin, which has the exact same problem. Try to popularize an alternative full-node for Litecoin or Monero, the people owning XMR and LTC will tell you the same thing; "please don't, you'll destabilize the network"

[HCP]

Yeah... perhaps I should have qualified it somewhat Although, the OP did specify "full node wallet"... and btcd doesn't include wallet functionality:

One key difference between btcd and Bitcoin Core is that btcd does NOT include wallet functionality and this was a very intentional design decision.

Although they do provide that using the "btcwallet" daemon designed to interface with btcd: https://github.com/btcsuite/btcwallet


And yes, even the btcd devs acknowledge the difficulties that alternative full node devs face:

It properly downloads, validates, and serves the block chain using the exact rules (including consensus bugs) for block acceptance as Bitcoin Core. We have taken great care to avoid btcd causing a fork to the block chain. It includes a full block validation testing framework which contains all of the 'official' block acceptance tests (and some additional ones) that is run on every pull request to help ensure it properly follows consensus. Also, it passes all of the JSON test data in the Bitcoin Core code.

[pooya87]

If the miners were all using alternative versions of Bitcoin full nodes, the chances that the network would fork because of differing bugs would be much higher.

another way of looking at it is one miner running multiple full node implementations and if a problem arises in one of them (like the inflation bug) they can notice it right away instead of letting the bad chain grow long before someone reports it and they find it through other channels like social media!

here is another one called gocoin https://bitcointalk.org/index.php?topic=199306.0

[Carlton Banks]

If the miners were all using alternative versions of Bitcoin full nodes, the chances that the network would fork because of differing bugs would be much higher.

another way of looking at it is one miner running multiple full node implementations and if a problem arises in one of them (like the inflation bug) they can notice it right away instead of letting the bad chain grow long before someone reports it and they find it through other channels like social media!

no

that would risk forking the chain, which also cuts the miner's revenue in half until the fork is resolved/decided (as the risk is high that one chain fork would be permanently orphaned and everything mined on it worthless). Then the miner is incentivized to choose which chain will win before that. The outcome could be a total mess for days or even weeks.

to put it another way; miners could've chosen your strategy long ago. A small minority did. But some large number, probably more than half, know the risks I outlined above and decided to take minimal such risks.

[pooya87]

1. use Bitcoin Core for mining activity
2. use other client and compare it's network information (current block height, hash of recently mined block, etc.)

yes, this is what i meant. mainly the verification using multiple implementation at the same time.
a rather poor example would be what A. Chow was doing in this website: https://btcforkmonitor.info/ (a poor example because the clients were all copies of bitcoin core such as btc1, bitcoin unlimited,... instead of stand alone implementations of bitcoin).

imagine if in August 2010 the miners were running more than one bitcoin core, or even if they were running more than one version. in that case when they received the buggy block and their main client (core version 0.8?) accepted it, they could have seen other instances possibly reject it which would act as an indication of something being wrong right away instead of having to find out about it on social media and the invalid chain wouldn't have had grown for 50+ blocks!

basically the design would be like a warning mechanism that shows a message saying "i just found an anomaly, human intervention is required".
this is not just for miners either. i believe any big business dealing with large sums of money must do this.

[achow101]

1. use Bitcoin Core for mining activity
2. use other client and compare it's network information (current block height, hash of recently mined block, etc.)

yes, this is what i meant. mainly the verification using multiple implementation at the same time.
a rather poor example would be what A. Chow was doing in this website: https://btcforkmonitor.info/ (a poor example because the clients were all copies of bitcoin core such as btc1, bitcoin unlimited,... instead of stand alone implementations of bitcoin).

imagine if in August 2010 the miners were running more than one bitcoin core, or even if they were running more than one version. in that case when they received the buggy block and their main client (core version 0.8?) accepted it, they could have seen other instances possibly reject it which would act as an indication of something being wrong right away instead of having to find out about it on social media and the invalid chain wouldn't have had grown for 50+ blocks!

basically the design would be like a warning mechanism that shows a message saying "i just found an anomaly, human intervention is required".
this is not just for miners either. i believe any big business dealing with large sums of money must do this.

You may be interested in https://forkmonitor.info/nodes/btc.