Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.175 as permitted sender)
	client-ip=209.85.212.175; envelope-from=andyparkins@gmail.com;
	helo=mail-wi0-f175.google.com; 
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 1 Feb 2012 14:14:08 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
References: <201201311651.02726.andyparkins@gmail.com>
In-Reply-To: <201201311651.02726.andyparkins@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2479945.80yN0cNbTc";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201202011414.12221.andyparkins@gmail.com>
Subject: Re: [Bitcoin-development] BIP16/17 replacement
Precedence: list

--nextPart2479945.80yN0cNbTc
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

On 2012 January 31 Tuesday, Andy Parkins wrote:

>  - Increase the version number in transactions to make a new transaction
>    structure
>  - Dump the "scriptPubKey" field completely.  Everything will be pay-to-
>    script-hash in version2 transactions
>  - Replace it with "hashOfClaimingScript"
>  - Add an "unsignedParameters" array.

Having thought about it; I've realised that the above is simply BIP16 witho=
ut=20
the backward compatibility work in it.  If BIP16 renamed the scriptPubKey=20
field to "hashOfClaimingScript" and no longer ran it as a script, it woudl =
be=20
close to identical.  We'd simply define the field as

 0xa9 0x14 <hashOfClaimingScript> 0x87

Detection of this format of scriptPubKey activates "version2" processing of=
=20
the transaction.  And similarly, a new definition of scriptSig to be two=20
fields:

   unsignedInitialStackBlock
   scriptClaim

I'm sure nobody cares about my opinion; but that's actually been the moment=
=20
of epiphany for me (and I raise it here, in case it is for someone else). =
=20
Having previously been against BIP16, I'm now happy with BIP16 -- it's a=20
progression towards the ideal... having a literal claimScriptHash field=20
instead of scriptPubKey; and never running scriptPubKey.

Potentially OP_CHECKSIG could be simplified as well because the rules could=
=20
be "anything that's not the serialized script" in scriptSig is not signed.

I can imagine one day, when the network is all BIP16 compliant, that=20
scriptPubKey will no longer be allowed to run as script at all.


Andy

=2D-=20
Dr Andy Parkins
andyparkins@gmail.com

--nextPart2479945.80yN0cNbTc
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

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

iEYEABECAAYFAk8pSLAACgkQwQJ9gE9xL21mEACglO3l1+UAprJOwgUEVn8cWi9f
qlAAn10MPG6H297xWJJ2b9ToQHN2lTiC
=Yjzz
-----END PGP SIGNATURE-----

--nextPart2479945.80yN0cNbTc--