SwiftSync -- Speeding up IBD with pre-generated hints (PoC)

The discussion begins with an appreciation of the observed performance improvements when RAM constraints are not a limiting factor, highlighting the significance of these enhancements. A suggestion is made to conduct a benchmark using a theoretical hash aggregate function with zero cost to determine the maximum potential savings, implying an interest in optimizing performance further by exploring the boundaries of computational efficiency.

The conversation then shifts towards security concerns, specifically regarding the risk of accidental collisions in hashing. It's noted that using a 4-byte hash presents a one in four billion chance of mistakenly accepting an invalid chain, which, while low, suggests a preference for erring on the side of caution. The recommendation is to use at least a 16-byte hash to maintain security standards without compromise, indicating a careful consideration of the trade-offs between performance and security.

Further clarification seems to be sought on whether the assumeutxo hash and hints originating from the same source might impact the system's ability to fail early in the detection of discrepancies, pointing to a nuanced understanding of the underlying mechanisms. However, reassurance is offered regarding the improbability of accidental hash collisions when employing a 32-byte hash with salt, suggesting confidence in the robustness of this approach against such risks.

Lastly, the email touches upon the potential for batch validation of Schnorr signatures as a means to reduce CPU load, particularly for versions not utilizing assumevalid optimization. This indicates an ongoing exploration of various techniques to enhance system efficiency without sacrificing security, with anticipation expressed for future benchmarks that will shed light on the effectiveness of these strategies.