drumr_

There are two specific vulnerabilities in Bitcoin Core that could have been fixed and avoided any talk of a fork. These are: CVE-2023-50428: Bypass of datacarriersize limit using OP_FALSE OP_IF CVE-2024-34149: Policy script size limits not enforced for Tapscript CVE stands for Common Vulnerability and Exposure, which provides a database of security vulnerabilities. The issues allowing spam to propagate freely on Bitcoin were acknowledged as vulnerabilities and made it into the CVE database. From a cybersecurity perspective, fixing vulnerabilities is a no brainer, even if the effect of the fix isn't perfect. Basic code changes would have at least made it so that the latest versions of Core and onward would not have that specific bug. The issues were fixed in Knots 25.1. Varying rationale has been given for not implementing the proposed fixes, but to me, all that has happened is that two bugs weren't fixed. I don't care that spammers would have an alternate method of getting their transactions relayed. The official policy of the reference implementation would be that relaying those transactions is non-standard. Policy defaults matter. Standards matter. Friction matters. This whole problem could have been solved ages ago by Core practicing basic vulnerability management.

Capping the supply of Bitcoin at 21M doesn't make sense. Beacuse over time, keys will be lost. In fact, as time goes to infinity, all keys will be lost. I strongly support a clear monetary policy with an absolute upper bound on the # of Bitcoins in the future. Say, fix a max issuance rate and you get that (a good choice is 4% a year, this is a reasonable upper bound on human population expansion). This way, you ensure there's enough to go around. And I'm not even talking about the security problem, looming large on the horizon.

Today we are announcing that OCEAN’s backend will be upgraded to follow multiple chains independently in the event of a BIP 110 chain split. If a split occurs, DATUM miners automatically continue on whichever chain their own node enforces, and OCEAN will credit rewards to a split share log for that chain, subject to the chain’s continued operation and to our Terms of Service. OCEAN will effectively operate as two pools from the split point. Updated Terms of Service addressing split handling will be published before block 961632. We are building all this so our miners can receive rewards based on their own actions without adversely affecting other OCEAN miners.