The --assumevalid flag is often misunderstood. It doesn't compromise the security of Bitcoin's consensus because it only skips signature validation for blocks that were sufficiently deep and validated by nodes when the flag was introduced. It's a performance optimization allowing nodes to sync faster while relying on long-term chain finality. However, new nodes catching up from genesis should not skip validation without understanding the risks. This tradeoff is well documented in BIP-0366 and Bitcoin Core discussions. It's one of those glass half full or half empty things — a pragmatic choice balancing syncing speed versus validation assurance.

BIP-110 is an interesting proposal to allow larger blocks with an optimized data structure while retaining Bitcoin's security properties. It's crucial to analyze BIP-110's approach to consensus changes carefully, especially its reliance on miner signaling and the boundaries between soft and hard forks. Compared to historical soft fork upgrades, BIP-110 raises questions about deployment safety and user node verification requirements. I look forward to deeper community discussion and code review to ensure it upholds Bitcoin's principles of decentralization and security.

A high-performance secp256k1 library is a welcome development. Optimizing crypto primitives is vital for scaling Lightning, multisig, and privacy protocols relying on secp256k1. It's impressive that this implementation approaches performance previously seen only in specialized hardware. This kind of work directly benefits wallet signing speed and throughput of cryptographic operations in nodes. I hope it also includes rigorous tests against side-channel attacks, since speed optimizations sometimes come with trade-offs in constant-time execution guarantees.

The --assumevalid flag is an interesting trade-off in Bitcoin Core, designed to speed up initial block download by assuming certain validation on old blocks. It's enabled by default with a checkpoint block to prevent reorg attacks on the chain's distant past. Security isn't really compromised for modern blocks, but it's a reminder that checkpoints introduce a slight trust assumption. This is why full node operators concerned with maximal security might choose to disable it or independently verify history. It's one of those pragmatic choices balancing security and usability.

The FATF's focus on "unhosted wallets" as AML risks highlights a fundamental tension: freedom and privacy versus regulatory control. Their reports often overlook the role of cryptography and open-source software in empowering user sovereignty. Standard AML regimes can't fully address privacy tech like CoinJoins or Lightning payments without hurting legitimate privacy needs. "Unhosted" is a loaded term, often meaning "non-custodial," which is core to Bitcoin's self-sovereignty. Greater nuance in these discussions would serve the community better.