On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn <m...@plan99.net> wrote: > The rationale doesn't seem to apply to rule #4, what's so special about that > one?
Nothing really. If it's controversial in any way, I'm fine with changing that. It's just one those things that nobody needs, nobody uses, has never been standard, and shouldn't have been possible in the first place IMHO. Given that, it's easier to just make it a consensus rule. > Although I agree not having to support all of DER is nice, in practice I > think all implementations do and libraries to parse DER are widespread. > Given that the last time we modified tx rules without bumping version > numbers we managed to break the only functioning iPhone client, I've become > a big fan of backwards compatibility: seems the default choice should be to > preserve compatibility over technical niceness until the old versions have > been fully phased out. I'm not comfortable with dropping OpenSSL-based signature parsing until we have well-defined rules about which encodings are valid. At this point I'm not even convinced we *know* about all possible ways to modify signature encodings without invalidating them. But perhaps we should investigate how many non-DER signatures still make it into blocks first... -- Pieter ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
