summaryrefslogtreecommitdiff
path: root/e7/32b1d8ecdf45d58ae8a65702dbfed69600ca9a
blob: ab5976bae5e2637132deff33e193f86144757ce1 (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
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
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 1RsGvN-0002SE-Jh
	for bitcoin-development@lists.sourceforge.net;
	Tue, 31 Jan 2012 16:51:17 +0000
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; 
Received: from mail-we0-f175.google.com ([74.125.82.175])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1RsGvI-0003Or-7s
	for bitcoin-development@lists.sourceforge.net;
	Tue, 31 Jan 2012 16:51:17 +0000
Received: by werc1 with SMTP id c1so277938wer.34
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 31 Jan 2012 08:51:06 -0800 (PST)
Received: by 10.216.138.8 with SMTP id z8mr2459532wei.20.1328028666148;
	Tue, 31 Jan 2012 08:51:06 -0800 (PST)
Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178])
	by mx.google.com with ESMTPS id hc10sm38505954wib.8.2012.01.31.08.51.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 31 Jan 2012 08:51:04 -0800 (PST)
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>
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
X-Headers-End: 1RsGvI-0003Or-7s
Subject: [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: Tue, 31 Jan 2012 16:51:17 -0000

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