Bitcoin Optech: Newsletter #373 Recap

Mark “Murch” Erhardt and Mike Schmidt are joined by Matt Morehouse, Daniela Brozzoni, and Gustavo Flores Echaiz to discuss Newsletter #373.News● Eclair vulnerability (18:50) ● Research into feerate settings (0:35) Selected Q&A from Bitcoin Stack Exchange● Implications of OP_RETURN changes in upcoming Bitcoin Core version 30.0? (28:27) ● If OP_RETURN relay limits are ineffective, why remove the safeguard instead of keeping it as a default discouragement? (42:12) ● What are the worst-case stress scenarios from uncapped OP_RETURNs in Bitcoin Core v30? (43:25) ● If OP_RETURN needed more room, why was the 80-byte cap removed instead of being raised to 160? (50:39) ● If arbitrary data is inevitable, does removing OP_RETURN limits shift demand toward more harmful storage methods (like UTXO-inflating addresses)? (59:48) ● If OP_RETURN uncapping doesn’t increase the UTXO set, how does it still contribute to blockchain bloat and centralization pressure? (1:00:17) ● How does uncapping OP_RETURN impact long-term fee-market quality and security budget? (1:02:11) ● Assurance blockchain will not suffer from illegal content with 100KB OP_RETURN? (1:04:34) ● What analysis shows OP_RETURN uncapping won’t harm block propagation or orphan risk? (1:05:25) ● Where does Bitcoin Core keep the XOR obfuscation keys for both block data files and level DB indexes? (1:06:10) ● How robust is 1p1c transaction relay in bitcoin core 28.0? (1:06:34) ● How can I allow getblocktemplate to include sub 1 sat/vbyte transactions? (1:10:37) Releases and release candidates● Bitcoin Core 30.0rc1 (1:13:00) Notable code and documentation changes● Bitcoin Core #33333 (1:15:26) ● Bitcoin Core #28592 (1:18:36) ● Eclair #3171 (1:22:33) ● Eclair #3175 (1:26:41) ● LDK #4064 (1:29:36) ● LDK #4067 (1:31:04) ● LDK #4046 (1:32:43) ● LDK #4083 (1:35:27) ● LND #10189 (1:38:23) ● BIPs #1963 (1:41:17)