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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YgAed-00033D-3E
for bitcoin-development@lists.sourceforge.net;
Thu, 09 Apr 2015 11:29:51 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.182 as permitted sender)
client-ip=209.85.212.182; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f182.google.com;
Received: from mail-wi0-f182.google.com ([209.85.212.182])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YgAeb-0007V2-Np
for bitcoin-development@lists.sourceforge.net;
Thu, 09 Apr 2015 11:29:51 +0000
Received: by wiax7 with SMTP id x7so53130354wia.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 09 Apr 2015 04:29:43 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.109.169 with SMTP id ht9mr5461013wib.86.1428578983760;
Thu, 09 Apr 2015 04:29:43 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.11 with HTTP; Thu, 9 Apr 2015 04:29:43 -0700 (PDT)
In-Reply-To: <CABHVRKTNFoLm9LEO=ctT_UP9zW7QOMQzVXitKC=PAzj=HG9OHg@mail.gmail.com>
References: <CABHVRKTNFoLm9LEO=ctT_UP9zW7QOMQzVXitKC=PAzj=HG9OHg@mail.gmail.com>
Date: Thu, 9 Apr 2015 13:29:43 +0200
X-Google-Sender-Auth: yfUNiWoUmNBgp4bUzD4ufHipvN4
Message-ID: <CANEZrP12kZ8vRAo=feprJ9_oRXUPKJ=iF6kZdxxbai=TxjzM9g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Stephen Morse <stephencalebmorse@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f3baed9dc682e051348f6d9
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1YgAeb-0007V2-Np
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Build your own nHashType
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: Thu, 09 Apr 2015 11:29:51 -0000
--e89a8f3baed9dc682e051348f6d9
Content-Type: text/plain; charset=UTF-8
Hi Stephen,
It's an interesting idea. I'm not sure that all the combinations make
sense. Excluding the connected output script or value but still signing the
prev tx hash appears pointless: the script cannot change anyway, and you
still need to know what it is to actually calculate the inputs to it, so
what is the point of this?
I also worry that quite a few of these combinations could be unexpectedly
dangerous. If you don't sign the prevout hash or value and combine it with
a regular pay-to-address output then you've effectively written a blank
cheque that can be used by anyone, to claim any money ever sent to that
address ... no? And then any p2p node or miner could do so, making the
transaction pretty useless.
That isn't inherently a problem as long as people understand which
combinations have what effects or cannot be used for various reasons. But
it would need good documentation and careful thought to explore each
possibility people might use.
I'll leave the soft fork business to one side for now. I think any change
in CHECKSIG or new version of it would likely be ready around the same time
as the hard fork we need for changing the block size limit anyway, and it's
much cleaner to do it that way.
The most important change that we need in sighash calculation, IMO, is
ensuring that you don't have to hash data over and over again without a
good reason. The current sighash definition is unfortunate because it's
possible to make small transactions that involve hashing huge amounts of
data. It's not clear to me that your proposal fixes that: ideally there
would be one exactly one sighash for one transaction no matter how many
checksigs are involved in verifying it.
thanks,
-mike
--e89a8f3baed9dc682e051348f6d9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Stephen,<div><br></div><div>It's an interesting ide=
a. I'm not sure that all the combinations make sense. Excluding the con=
nected output script or value but still signing the prev tx hash appears po=
intless: the script cannot change anyway, and you still need to know what i=
t is to actually calculate the inputs to it, so what is the point of this?<=
/div><div><br></div><div>I also worry that quite a few of these combination=
s could be unexpectedly dangerous. If you don't sign the prevout hash o=
r value and combine it with a regular pay-to-address output then you've=
effectively written a blank cheque that can be used by anyone, to claim an=
y money ever sent to that address ... no? And then any p2p node or miner co=
uld do so, making the transaction pretty useless.</div><div><br></div><div>=
That isn't inherently a problem as long as people understand which comb=
inations have what effects or cannot be used for various reasons. But it wo=
uld need good documentation and careful thought to explore each possibility=
people might use.</div><div><br></div><div>I'll leave the soft fork bu=
siness to one side for now. I think any change in CHECKSIG or new version o=
f it would likely be ready around the same time as the hard fork we need fo=
r changing the block size limit anyway, and it's much cleaner to do it =
that way.</div><div><br></div><div>The most important change that we need i=
n sighash calculation, IMO, is ensuring that you don't have to hash dat=
a over and over again without a good reason. The current sighash definition=
is unfortunate because it's possible to make small transactions that i=
nvolve hashing huge amounts of data. It's not clear to me that your pro=
posal fixes that: ideally there would be one exactly one sighash for one tr=
ansaction no matter how many checksigs are involved in verifying it.</div><=
div><br></div><div>thanks,</div><div>-mike</div><div><br></div></div>
--e89a8f3baed9dc682e051348f6d9--
|
