From: Matt Corallo <lf-lists@mattcorallo•com>
To: Gavin Andresen <gavinandresen@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork
Date: Thu, 26 Jan 2017 17:41:55 +0000 [thread overview]
Message-ID: <CC8A4B24-7620-4D61-AE93-D60C7096CFAE@mattcorallo.com> (raw)
In-Reply-To: <CABsx9T0PcbMxjfBJZYveQayhTUb1C3YNZCEMA1T=f9mAfxHypg@mail.gmail.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 --]
prev parent reply other threads:[~2017-01-26 17:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-24 14:33 Johnson Lau
2017-01-24 18:52 ` Tom Harding
2017-01-25 4:03 ` Johnson Lau
2017-01-25 19:32 ` Tom Harding
2017-01-27 20:47 ` Johnson Lau
2017-01-27 22:11 ` Tom Harding
2017-01-25 1:22 ` Natanael
2017-01-25 7:05 ` Johnson Lau
2017-01-25 7:15 ` Natanael
2017-01-25 7:21 ` Johnson Lau
2017-01-25 7:29 ` Natanael
2017-01-25 7:42 ` Johnson Lau
2017-01-26 3:29 ` Matt Corallo
2017-01-26 7:03 ` Chris Priest
2017-01-26 7:14 ` Johnson Lau
2017-01-26 8:59 ` Chris Priest
2017-01-26 9:20 ` Johnson Lau
2017-01-26 10:55 ` Edmund Edgar
2017-01-26 15:58 ` Tom Harding
2017-01-26 17:21 ` Gavin Andresen
2017-01-26 17:41 ` Matt Corallo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CC8A4B24-7620-4D61-AE93-D60C7096CFAE@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox