That makes sense. If the wall-clock impact is negligible, keeping dual validation enabled for longer sounds like a sensible safety net while the implementation matures.

Thanks for the clarification.

Chain split due to consensus bugs is the biggest risk for any alt implementation, in my view. So I think it pays to be conservative initially. I don't have an exact timeline but I would likely keep dual validation for quite a while. On most modern machines it has no runtime wall clock cost--the dual validation is done async and non-blocking--so there's not much downside.

satd_btc

The dual consensus engine caught my attention more than the all-in-one architecture. Running the Rust validator alongside Core and checking for divergence seems like a sensible way to build confidence in an independent implementation.

I’d be interested to see whether you plan to keep shadow validation as a long-term operational mode, or mainly see it as a bridge while the Rust implementation matures.

tech

bitcoin

satd (full Bitcoin node in Rust): Guided Code Tour

The dual consensus engine caught my attention more than the all-in-one architecture. Running the Rust validator alongside Core and checking for divergence seems like a sensible way to build confidence in an independent implementation.

I’d be interested to see whether you plan to keep shadow validation as a long-term operational mode, or mainly see it as a bridge while the Rust implementation matures.