Bitcoin Core – What are the risks of running a pre-SegWit node (v12.1)?

Pre-segwit nodes consider segwit transactions non-standard and do not accept them into the mempool, so they do not forward them either. They only participate in the relay of unconfirmed non-Segwit transactions. Currently, approximately 94% of transactions use at least one Segwit input.

Therefore, pre-SegWit nodes see a small portion of unconfirmed transactions. This can potentially reduce the bandwidth usage of that node, since segwit peers will also not forward unconfirmed segwit transactions. Segwit is backwards and forwards compatible in that pre-Segwit nodes still process the blockchain on which they operate the most, because even if non-standard, Segwit transactions are evaluated as valid and reach the same chain state. However, they cannot assess the validity of segwit transactions, and since they inherently do not process witness data, they end up blindly trusting that most of the chain of operations is in fact valid. This will allow pre-SegWit nodes to accept invalid blockchains designed to enable double-spend attacks against those nodes. Because Pre-Segwit nodes only confirm a small portion of unconfirmed transactions in the queue, fee estimates may be significantly skewed.

Bitcoin Core 0.12.1 was released in November 2016 and reached end-of-life at the end of 2017. In addition to all the performance improvements over the past seven years, there are also yet to be fixed fixes for security issues found in the project that could affect that release. It has been backported. It’s unclear what benefits users can expect from running a client this old. If your motivation is to reduce bandwidth usage, you can achieve the same (and more) by running: -blocksonly Maintained version of the mod. If they explicitly only want to relay legacy transactions, I suspect they could change the behavior of the nodes with a small patch so that they appear as non-Segwit nodes without actually downgrading to unmaintained software.

Nodes that do not participate in relaying unconfirmed transactions cannot use compact block relays, which generally results in slower propagation of new blocks. Bitcoin Core’s peer manager protects some peers from eviction by taking advantage of peers that have recently been the first to contribute new blocks. I believe that even if the majority of nodes (e.g. 90%) switch to non-segwit operation, the remaining nodes will form a well-connected compact block relay backbone that will be largely unaffected.

My suspicion is that anyone running older node software or a pretentious non-Segwit node will mostly downgrade their experience without much impact on other nodes.

If a miner downgrades to mining only non-SegWit transactions, they will pick from a smaller pool of unconfirmed transactions while forwarding higher fee SegWit transactions from the Mempool. This causes its own block rewards to be reduced for the benefit of non-participating miners.

Overall, I don’t see any benefit to this idea other than perhaps what it offers to the adopter. A vague feeling of doing somethingAll the drawbacks apply to the adopters themselves, so I wouldn’t worry at all if I saw some people implementing it.