Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.175 as permitted sender)
	client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com;
	helo=mail-we0-f175.google.com; 
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Tue, 31 Jan 2012 16:50:58 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1573734.FR5WsQH80B";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201201311651.02726.andyparkins@gmail.com>
Subject: [Bitcoin-development] BIP16/17 replacement
Precedence: list

--nextPart1573734.FR5WsQH80B
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

Gulp.  Am a little nervous about wading into this swamp.  However, it seems=
=20
to me that the debate has veered into the personal and away from the=20
technical.  Surely if there are objections to both suggestions, that anothe=
r=20
solution might be better?  The answer doesn't have to be A or B, if the=20
answer C turns out to be acceptable.

That being said; I am not confident enough to start making BIPs so I offer=
=20
this idea up for my traditional mailing-list roasting but with the hope tha=
t=20
I blindly stumble toward something more acceptable to everyone.

=2D---

If the change is going to be a big one anyway and will require a client=20
upgrade why not...

 - 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.

hashOfClaimingScript is _not_ script.  It's just the hash of the script tha=
t=20
is allowed to claim the output.  Then before scriptSig is allowed to run, i=
t=20
is hashed and compared against the hashOfClaimingScript.

unsignedParameters replaces the need for all the crazy messing around that=
=20
OP_CHECKSIG currently does because it is specifically a block of the=20
transaction that it not signed (although I would include the array size byt=
es=20
in the signature calculation), therefore no script filtering is necessary.

The claiming script, scriptSig, can then be checked against whatever list o=
f=20
templates you like.  For pay-to-address it will probably look like:

  OP_PUSHPARAMETER {0}
  OP_PUSH { <claimant public key> }
  OP_CHECKSIGVERIFY

Handling the more complicated transactions (they're the point of all this=20
after all) is pretty obvious; the unsignedParameters block can hold as many=
=20
signatures as you like.  It also removes the need for OP_CHECKMULTISIG, sin=
ce=20
the script can specify the signature conditions.  e.g. a 2-of-3 script:

  OP_PUSHPARMETER {0}
  OP_PUSH { <claimant public key0> }
  OP_CHECKSIG
  OP_PUSHPARMETER {1}
  OP_PUSH { <claimant public key1> }
  OP_CHECKSIG
  OP_PUSHPARMETER {1}
  OP_PUSH { <claimant public key1> }
  OP_CHECKSIG
  OP_ADD
  OP_ADD
  OP_PUSH {1}
  OP_GREATERTHAN

(I'm sure someone cleverer than I can improve on the above)

=2D----

Let the flaming commence...


Andy

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

--nextPart1573734.FR5WsQH80B
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)

iEYEABECAAYFAk8oG/MACgkQwQJ9gE9xL23vwACfeYvy5yud7AZqlnBkCv8aoa85
Zh0AoJJbZQoqyiYSzA51SDxYy0+GO0D8
=shkA
-----END PGP SIGNATURE-----

--nextPart1573734.FR5WsQH80B--