summaryrefslogtreecommitdiff
path: root/95/9d8d7bdc24d05b61664af1bcd6786d3575487e
blob: 1aee6816ac2c1c835418462430338914a2f3a09e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <andyparkins@gmail.com>) id 1RsaxC-0002OP-JU
	for bitcoin-development@lists.sourceforge.net;
	Wed, 01 Feb 2012 14:14:30 +0000
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; 
Received: from mail-wi0-f175.google.com ([209.85.212.175])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Rsax7-0001Ns-79
	for bitcoin-development@lists.sourceforge.net;
	Wed, 01 Feb 2012 14:14:30 +0000
Received: by wibhq7 with SMTP id hq7so1364870wib.34
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 01 Feb 2012 06:14:19 -0800 (PST)
Received: by 10.180.81.66 with SMTP id y2mr41750032wix.20.1328105658941;
	Wed, 01 Feb 2012 06:14:18 -0800 (PST)
Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178])
	by mx.google.com with ESMTPS id ho4sm45029787wib.3.2012.02.01.06.14.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 01 Feb 2012 06:14:14 -0800 (PST)
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>
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(andyparkins[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Rsax7-0001Ns-79
Subject: Re: [Bitcoin-development] BIP16/17 replacement
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 01 Feb 2012 14:14:30 -0000

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