MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <CAAS2fgQGC695mkyze+mVTZZoQN1mh+1y32u-D6Yv1R7nXWPDcg@mail.gmail.com>
References: <201609230957.03138.luke@dashjr.org>
	<CAMZUoKnY7s1b75Z_0QCb2hh-Q_hCE4-9dZ9tY58HaUQy6=aCbw@mail.gmail.com>
	<CAAS2fgQGC695mkyze+mVTZZoQN1mh+1y32u-D6Yv1R7nXWPDcg@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Fri, 23 Sep 2016 18:57:57 +0000
Message-ID: <CAAS2fgTJ9iPoE6fvMBhFB8ruwy-6aTo4Ka5agK+LHjSqGa2-rw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT
Precedence: list

On Fri, Sep 23, 2016 at 1:43 PM, Russell O'Connor via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I believe Bitcoin currently enjoys the property that during an "innocent"
> re-org, i.e. a reorg in which no affected transactions are being double
> spent, all affected transactions can always eventually get replayed, so long
> as the re-org depth is less than 100.

> My concern with this proposed operation is that it would destroy this
> property.

The reorg safety impact of this proposal could be eliminated and the
mempool handling complexity greatly reduced if the transaction was
required to be locktimed at least 100 blocks after the block its
referencing.

This would also resolve a rather severe DOS weakness that the spec has
with the suggestion that nodes would relay this rule without
validating it. With the depth restriction nodes could relay one (or a
couple) blocks early without creating a situation where someone can
consume relay resources with near zero odds of paying a fee for them.

Irritatingly, applications of this rule would really want to be
applied at signing time (like locktime is), not as part of a
scriptpubkey. With it part of a scriptpubkey two moves are required. I
think solving this is important.

FWIW, this scheme more has been proposed before for another reason--
effectively allowing users to 'vote against' long reorgs by making
sure their transactions can't be included in them. Though for that
application it was only needed to use 32 bits of the block hash.