Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.75 as permitted sender)
	client-ip=62.13.149.75; envelope-from=pete@petertodd.org;
	helo=outmail149075.authsmtp.net; 
Date: Thu, 19 Jun 2014 06:09:09 -0400
From: Peter Todd <pete@petertodd.org>
To: Gavin Andresen <gavin@bitcoinfoundation.org>
Message-ID: <20140619100909.GA3544@savin>
References: <CABsx9T2+_tLOPELm+K54D=6SNkHg1ZeO_T1jSM=CQZYJKGODFw@mail.gmail.com>
	<20140618001503.GA8360@savin>
	<CABsx9T2O42pER0b1v9oeU14_K=KVWVqHzcfFmWAhSxoYAn12vg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb"
Content-Disposition: inline
In-Reply-To: <CABsx9T2O42pER0b1v9oeU14_K=KVWVqHzcfFmWAhSxoYAn12vg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: relax the IsStandard rules for
 P2SH transactions
Precedence: list


--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 18, 2014 at 08:52:22AM -0400, Gavin Andresen wrote:
> RE: most of Peter Todd's comments:
>=20
> 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 prote=
ct
> 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.

--=20
'peter'[:-1]@petertodd.org
000000000000000004e51d8d00eedb31ec1505d245f48960896b79f0e7193c2a

--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQGrBAEBCACVBQJTorbCXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNGU1MWQ4ZDAwZWVkYjMxZWMxNTA1ZDI0NWY0ODk2MDg5
NmI3OWYwZTcxOTNjMmEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsZqQgAk+atVJhjNkUK1P8+Cw1tgNeb
WQ2mP16FMYwCv9pi/QTXUItfQgxxsY7iUcpmmLIyI7PRfEZh0ybBGTerWS4BjlRe
016ceuLuS/vdISkER2qocjBWhb/6WSIa/MhTartxFPOU48/30cHIxSOgSApEX4gx
SpPxuQLjITeovBGPvjyipV4DZDuAhcAh6Cj28o5vO4AiRs2KvMPcnKiWEX1GcEKn
sT5smtXa2nDgowHTD4MFunrwu97WypFWv9VlRjnvgvHuwxPTKgy9RX9QsRUlydjo
yBtl/Mji9JnFbcsOBZJQ5FazbzqvQG6QA3SCZWZguaRcyxXrIiVsqZwCvipQSQ==
=KVfC
-----END PGP SIGNATURE-----

--VS++wcV0S1rZb1Fb--