On Wed, Jun 18, 2014 at 08:52:22AM -0400, Gavin Andresen wrote: > RE: most of Peter Todd's comments: > > All of that should be separate pull requests. Big Honking Pull Requests > are harder to review and are more likely to be bike-shedded to death.
Well, just doing one and not the rest isn't necessarily a good idea. The malleability protection definitely seems like a good idea, and has had quite a bit of review. > RE: not relaying/mining transactions with OP_NOPs so miners don't mine > up-version transactions that are invalid under future-new-rules: I'm not > convinced it is worth adding more code (more potential for bugs) to protect > against something that isn't going to happen because up-version > transactions are non-standard (due to version check) in any case. Do we have consensus that future soft-forks to add new opcodes will always be done in conjunction with a transaction nVersion bump? If so, then that's ok, if not, then we should have a whitelist. The code to restrict the opcodes to the softfork-safe subset is trivial, a GetOp() loop and a switch statement. It can always be removed later. Something that comes to mind is if we do always bump nVersion then OP_NOPx always will have a parallel "do-nothing" behavior, which means EvalScript() will always have to have code enabling that backwards compatible behavior. -- 'peter'[:-1]@petertodd.org 000000000000000004e51d8d00eedb31ec1505d245f48960896b79f0e7193c2a
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
