On Thu, Apr 09, 2015 at 07:22:52AM -0700, Jeff Garzik wrote: > On Thu, Apr 9, 2015 at 7:10 AM, Stephen Morse > wrote: > > > Is hashing transaction data once for each input really a huge bottleneck, > > though? Do mobile devices have an issue with this? > > > > > Think about what slow transaction verification speed means. Slower > propagation across the network. More work per node. Greater opportunity > for algorithmic attacks, races and other shenanigans by attackers. Keep in mind though we can always make part of the soft-fork be to make the hash operations in the new CHECKSIG mechanism consume sigops. For the OP: Have you looked at how CODESEPARATOR allows the signature to sign code to run as part of verifying the signature? E.g. my signature can say "valid if you run these additional opcodes and they return true" where those additional opcodes take the transaction, hash it in the defined way, and verify that the ECC signature correctly signs that hash and the hash of the additional opcodes. For instance in this case making a signature that's only valid if the tx fee is less than the defined amount would be a matter of GET_FEE LESSTHAN VERIFY This can be a much more general mechanism with easy to test modular opcodes; for the consensus-critical codebase this can result in a much easier and simpler to test CHECKSIG facility than a dozen new flags. -- 'peter'[:-1]@petertodd.org 000000000000000006975f442f50caa4fcc18e165746b3c77b641b75635afecb