Re: [Bitcoin-development] Build your own nHashType

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

On Thu, Apr 09, 2015 at 07:22:52AM -0700, Jeff Garzik wrote:
> On Thu, Apr 9, 2015 at 7:10 AM, Stephen Morse <stephencalebmorse@gmail.com>
> 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 <max fee + 1> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]