rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2017-09-11 📝 Original message:On Mon, Sep 11, 2017 at 5:43 PM, Daniel Stadulis via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > I think it's relevant to treat different bug severity levels with different > response plans. > > E.g. > Compromising UTXO custody (In CVE-2010-5141, OP_RETURN vulnerability) > Compromising UTXO state (In CVE-2013-3220, blockchain split due to Berkeley > DB -> LevelDB upgrade, CVE-2010-5139 Overflow bug, unscheduled inflation of > coins) > Compromising Node performance (Various node-specific DoS attacks) > > Should have different disclosure policies, IMO This assumes the states are discernible. They often aren't cleanly. You obviously know how bad it is in the best case, but the worst could be much worse. I've multiple time seen a hard to exploit issue turn out to be trivial when you find the right trick, or a minor dos issue turn our to far more serious. Simple performance bugs, expertly deployed, can potentially be used to carve up the network--- miner A and exchange B go in one partition, everyone else in another.. and doublespend. And so on. So while I absolutely do agree that different things should and can be handled differently, it is not always so clear cut. It's prudent to treat things as more severe than you know them to be. In fact, someone pointed out to me a major amplifier of the utxo-memory attack thing today that Bitcoin Core narrowly dodges which would have made it very easy to exploit against some users, and which it seems no one previously considered. I also think it's somewhat incorrect to call this thread anything about disclosure, this thread is not about disclosure. Disclosure is when you tell the vendor. This thread is about publication and that has very different implications. Publication is when you're sure you've told the prospective attackers.