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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
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 1YgDiF-00054d-Gz
for bitcoin-development@lists.sourceforge.net;
Thu, 09 Apr 2015 14:45:47 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YgDi9-0000gZ-JP
for bitcoin-development@lists.sourceforge.net;
Thu, 09 Apr 2015 14:45:47 +0000
Received: by wgsk9 with SMTP id k9so100170345wgs.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 09 Apr 2015 07:45:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.14.67 with SMTP id n3mr6675842wic.92.1428590735566; Thu,
09 Apr 2015 07:45:35 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.11 with HTTP; Thu, 9 Apr 2015 07:45:35 -0700 (PDT)
In-Reply-To: <CABHVRKSET18D13+yi4MTPs6+4xwUD5vuJszCOJG9CaTi0+CAvA@mail.gmail.com>
References: <CABHVRKTNFoLm9LEO=ctT_UP9zW7QOMQzVXitKC=PAzj=HG9OHg@mail.gmail.com>
<CANEZrP12kZ8vRAo=feprJ9_oRXUPKJ=iF6kZdxxbai=TxjzM9g@mail.gmail.com>
<CABHVRKSET18D13+yi4MTPs6+4xwUD5vuJszCOJG9CaTi0+CAvA@mail.gmail.com>
Date: Thu, 9 Apr 2015 16:45:35 +0200
X-Google-Sender-Auth: H02KiD_ML1IaO4ql0MOQzk_RKlw
Message-ID: <CANEZrP3mBibjUK99L=E9jHFAvQ0QLpx0ke112=yQjw-RhjWnyg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Stephen Morse <stephencalebmorse@gmail.com>
Content-Type: multipart/alternative; boundary=f46d04138cd552ae0805134bb3d7
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: 1YgDi9-0000gZ-JP
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 14:45:47 -0000
--f46d04138cd552ae0805134bb3d7
Content-Type: text/plain; charset=UTF-8
>
> I don't think it's quite a blank check, but it would enable replay attacks
> in the form of sending the money to the same place it was sent before if an
> address ever receives coins again.
>
Right, good point. I wonder if this sort of auto forwarding could even be a
useful feature. I can't think of one right now.
> It's hard, though, because there is different data needs to be signed for
> each input.
>
Yes but is that fundamental or is there a way to avoid it? That's what I'm
getting at.
> Another possibility would be to put the previous scriptPubKey and previous
> output value at the END of the serialized transaction, so that you could
> make use of some sort of a signature hash midstate.
>
Interesting idea! I don't agree it's messy. If anything it should be
simpler than what we have today - the need to edit a transaction *in the
middle* means that sighash computation involves constantly reserializing a
transaction before it even gets to be hashed.
> Is hashing transaction data once for each input really a huge bottleneck,
> though? Do mobile devices have an issue with this?
>
Consider what happens with very large transactions, like a big assurance
contract that might have thousands of inputs and be multiple megabytes in
size. Obviously such large transactions cannot happen today, but there is
user demand for giant contracts (or at least, users tell me there is,
whether they'd actually do it for real is a bit unclear).
--f46d04138cd552ae0805134bb3d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><div>I don't think it's quite a blank check,=
but it would enable replay attacks in the form of sending the money to the=
same place it was sent before if an address ever receives coins again. </d=
iv></div></div></div></blockquote><div><br></div><div>Right, good point. I =
wonder if this sort of auto forwarding could even be a useful feature. I ca=
n't think of one right now.</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><div>It's hard, though, because there is different data needs to =
be signed for each input. </div></div></div></div></blockquote><div><br></d=
iv><div>Yes but is that fundamental or is there a way to avoid it? That'=
;s what I'm getting at.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><div>Another possibility would be to put the previous scriptPubKey and pr=
evious output value at the END of the serialized transaction, so that you c=
ould make use of some sort of a signature hash midstate. </div></div></div>=
</div></blockquote><div><br></div><div>Interesting idea! I don't agree =
it's messy. If anything it should be simpler than what we have today - =
the need to edit a transaction <i>in the middle</i>=C2=A0means that sighash=
computation involves constantly reserializing a transaction before it even=
gets to be hashed.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I=
s hashing transaction data once for each input really a huge bottleneck, th=
ough? Do mobile devices have an issue with this?</div></div></div></div></b=
lockquote><div><br></div><div>Consider what happens with very large transac=
tions, like a big assurance contract that might have thousands of inputs an=
d be multiple megabytes in size. Obviously such large transactions cannot h=
appen today, but there is user demand for giant contracts (or at least, use=
rs tell me there is, whether they'd actually do it for real is a bit un=
clear).</div></div></div></div>
--f46d04138cd552ae0805134bb3d7--
|
