MIME-Version: 1.0
In-Reply-To: <93ac7433-470c-d59e-e085-29f0f1613676@mattcorallo.com>
References: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
	<93ac7433-470c-d59e-e085-29f0f1613676@mattcorallo.com>
From: Gavin Andresen <gavinandresen@gmail.com>
Date: Thu, 26 Jan 2017 12:21:37 -0500
Message-ID: <CABsx9T0PcbMxjfBJZYveQayhTUb1C3YNZCEMA1T=f9mAfxHypg@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c095ce4f67df0054702946d
Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork
Precedence: list

--94eb2c095ce4f67df0054702946d
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 25, 2017 at 10:29 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> To maximize fork divergence, it might make sense to require this. Any
> sensible proposal for a hard fork would include a change to the sighash
> anyway, so might as well make it required, no?
>

Compatibility with existing transaction-signing software and hardware
should be considered.

I think any hard fork proposal should support a reasonable number of
reasonable-size old-sighash transactions, to allow a smooth transaction of
wallet software and hardware and to support anybody who might have a
hardware wallet locked away in a safe deposit box for years.

-- 
--
Gavin Andresen

--94eb2c095ce4f67df0054702946d
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">On W=
ed, Jan 25, 2017 at 10:29 PM, Matt Corallo via bitcoin-dev <span dir=3D"ltr=
">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div id=3D":1m6" class=3D"a3s aXjCH m159d8d262b0da=
180">To maximize fork divergence, it might make sense to require this. Any<=
br>
sensible proposal for a hard fork would include a change to the sighash<br>
anyway, so might as well make it required, no?</div></blockquote></div><br>=
Compatibility with existing transaction-signing software and hardware shoul=
d be considered.</div><div class=3D"gmail_extra"><br></div><div class=3D"gm=
ail_extra">I think any hard fork proposal should support a reasonable numbe=
r of reasonable-size old-sighash transactions, to allow a smooth transactio=
n of wallet software and hardware and to support anybody who might have a h=
ardware wallet locked away in a safe deposit box for years.</div><div class=
=3D"gmail_extra"><div><br></div>-- <br><div class=3D"gmail_signature" data-=
smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div d=
ir=3D"ltr"><div>--<br>Gavin Andresen<br></div><div><br></div></div></div></=
div></div></div>
</div></div>

--94eb2c095ce4f67df0054702946d--