Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5057394B for ; Thu, 26 Jan 2017 17:42:01 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 87406180 for ; Thu, 26 Jan 2017 17:42:00 +0000 (UTC) Received: from [IPv6:2607:fb90:1f0f:c5e:8efa:6107:8cb6:b944] (unknown [172.56.19.90]) by mail.bluematt.me (Postfix) with ESMTPSA id BCE8B136B7E; Thu, 26 Jan 2017 17:41:57 +0000 (UTC) Date: Thu, 26 Jan 2017 17:41:55 +0000 In-Reply-To: References: <93ac7433-470c-d59e-e085-29f0f1613676@mattcorallo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----GXR9I0B4MGVXTLB30PGIIWH1KG5YZR" Content-Transfer-Encoding: 7bit To: Gavin Andresen , Bitcoin Protocol Discussion From: Matt Corallo Message-ID: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 17:42:01 -0000 ------GXR9I0B4MGVXTLB30PGIIWH1KG5YZR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Excuse me, yes, for previously-signed transactions this is required=2E We m= ight consider some limits on UTXO-chain-from-before-the-fork-length and lik= ely something like move towards only allowing one transaction per block fro= m the old mode over time=2E I highly disagree that compatibility with existing transaction signing sof= tware should be considered (but for hardware which cannot be upgraded easil= y we do need to consider it)=2E Wallets which can upgrade should, as much a= s possible, upgrade to a new form to maximize chain divergence and are goin= g to end up having to upgrade to know a new header format anyway, so am ext= ra few lines of code to change a transaction version should be trivial=2E On January 26, 2017 12:21:37 PM EST, Gavin Andresen wrote: >On Wed, Jan 25, 2017 at 10:29 PM, Matt Corallo via bitcoin-dev < >bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrote: > >> To maximize fork divergence, it might make sense to require this=2E 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=2E > >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=2E > >--=20 >-- >Gavin Andresen ------GXR9I0B4MGVXTLB30PGIIWH1KG5YZR Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Excuse me, yes, for previously-signed transactions= this is required=2E We might consider some limits on UTXO-chain-from-befor= e-the-fork-length and likely something like move towards only allowing one = transaction per block from the old mode over time=2E

I highly disagree that compatibility with existing transaction signing sof= tware should be considered (but for hardware which cannot be upgraded easil= y we do need to consider it)=2E Wallets which can upgrade should, as much a= s possible, upgrade to a new form to maximize chain divergence and are goin= g to end up having to upgrade to know a new header format anyway, so am ext= ra few lines of code to change a transaction version should be trivial=2E
On January 26, 2017 12:21:37 PM EST, Gavin= Andresen <gavinandresen@gmail=2Ecom> wrote:
On = Wed, Jan 25, 2017 at 10:29 PM, Matt Corallo via bitcoin-dev <bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrote:=
To maximize fork divergence, it might make sense to requ= ire this=2E 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 sh= ould be considered=2E

I think any hard fork proposal should support a reasonabl= e number of reasonable-size old-sighash transactions, to allow a smooth tra= nsaction of wallet software and hardware and to support anybody who might h= ave a hardware wallet locked away in a safe deposit box for years=2E
<= div class=3D"gmail_extra">

--
--
Gavin Andresen

------GXR9I0B4MGVXTLB30PGIIWH1KG5YZR--