Re: [bitcoin-dev] Anti-transaction replay in a hardfork

[Matt Corallo <lf-lists@mattcorallo.com>]

[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]

Excuse me, yes, for previously-signed transactions this is required. We might consider some limits on UTXO-chain-from-before-the-fork-length and likely something like move towards only allowing one transaction per block from the old mode over time.

I highly disagree that compatibility with existing transaction signing software should be considered (but for hardware which cannot be upgraded easily we do need to consider it). Wallets which can upgrade should, as much as possible, upgrade to a new form to maximize chain divergence and are going to end up having to upgrade to know a new header format anyway, so am extra few lines of code to change a transaction version should be trivial.

On January 26, 2017 12:21:37 PM EST, Gavin Andresen <gavinandresen@gmail.com> wrote:
>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

[-- Attachment #2: Type: text/html, Size: 2388 bytes --]