Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.154 as permitted sender)
	client-ip=62.13.148.154; envelope-from=pete@petertodd.org;
	helo=outmail148154.authsmtp.co.uk; 
Date: Thu, 9 Apr 2015 13:28:09 -0400
From: Peter Todd <pete@petertodd.org>
To: Jeff Garzik <jgarzik@bitpay.com>
Message-ID: <20150409172808.GB27775@muck>
References: <CABHVRKTNFoLm9LEO=ctT_UP9zW7QOMQzVXitKC=PAzj=HG9OHg@mail.gmail.com>
	<CANEZrP12kZ8vRAo=feprJ9_oRXUPKJ=iF6kZdxxbai=TxjzM9g@mail.gmail.com>
	<CABHVRKSET18D13+yi4MTPs6+4xwUD5vuJszCOJG9CaTi0+CAvA@mail.gmail.com>
	<CAJHLa0NgV=6D=TAy4sm_EAfYiZULK-d9GMcddW1-DZRHCE8Sew@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="UHN/qo2QbUvPLonB"
Content-Disposition: inline
In-Reply-To: <CAJHLa0NgV=6D=TAy4sm_EAfYiZULK-d9GMcddW1-DZRHCE8Sew@mail.gmail.com>
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Build your own nHashType
Precedence: list


--UHN/qo2QbUvPLonB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.co=
m>
> wrote:
>=20
> > Is hashing transaction data once for each input really a huge bottlenec=
k,
> > though? Do mobile devices have an issue with this?
> >
>=20
>=20
> 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.

--=20
'peter'[:-1]@petertodd.org
000000000000000006975f442f50caa4fcc18e165746b3c77b641b75635afecb

--UHN/qo2QbUvPLonB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVJramXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNjk3NWY0NDJmNTBjYWE0ZmNjMThlMTY1NzQ2YjNjNzdi
NjQxYjc1NjM1YWZlY2IvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzdDgf9Fj/uxiOASb7dqz1FzLT+nilX
LiOaYIXxvfgz7Ch4PQKXv6ZaoxOp0SBi9C6fvxgrcxpIe1LDiCPLqMm47X6PBcG1
yscC4B/xGMgI4KN0j2xsW/9pbvsQYxFixo0lhhx/6aEVC7t8ppJ7tjNVBIgZZipO
fSovEYGY+5IMjqAluD6tYpYuBKph64+kEfFc2dqEhraSpaD+eHfFIuCCZDosHpUE
e+TolSI56oBsSbpXeoelo88A66VTFuTzcvhWrcIKWnGtKi9fUswaaO7IJJLPSoho
PJ3ZKQdouZ20cdr3p026/13sZIeMinn1H7JWbv5aMOOll8pV78WFL1aquK6Wjw==
=ExeM
-----END PGP SIGNATURE-----

--UHN/qo2QbUvPLonB--