MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <201609232220.41783.luke@dashjr.org>
References: <201609230957.03138.luke@dashjr.org>
	<CAMZUoKnY7s1b75Z_0QCb2hh-Q_hCE4-9dZ9tY58HaUQy6=aCbw@mail.gmail.com>
	<201609232220.41783.luke@dashjr.org>
From: Gregory Maxwell <greg@xiph.org>
Date: Fri, 23 Sep 2016 23:43:49 +0000
Message-ID: <CAAS2fgTCOq1pHrPVbkNzCp_bYqbXh6Y6osF5_jFUZRy1rWPQCw@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>, 
	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 10:20 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> In the innocent use case of this opcode, a double-spend has already occurred,
> and this should be a strict improvement. In the non-innocent abuse of this
> opcode, I don't see that it's any worse than simply double-spending.

There is a fungibility hit... right now, absent double spends (and
privacy issues), every coin you might get paid is equal.

With this script feature as described, you could get paid a coin which
has one of these in its recent past, pinning the block immediately
before it. A reorg long enough to remove that block-- due to an
attack, or an ordinary block race, or some kind of consensus glitch
(like we had in March 2013 or around the activation of BIP65)-- is
_guaranteed_ to invalidate those coins, even without any double spend.

If the scheme doesn't do as I suggest and prevent over-eager usage
(perhaps 100 is too much, I just decided to match coinbases); then it
should probably have a consensus enforced explicit "maximum survivable
reorg" that is traced along with the outputs, so that someone who
received exposed coins could handle it sensibly.

Just for plain engineering reasons, I still think it is important to
now allow overly short back references. If the reference has to be a
few blocks back we don't need to worry about short forks breaking
propagation, and simple mempool handling like purging all CBAH
transactions on a large reorg would work fine.  It need not be so long
as to implicate Petertodd's concern that you could only use it where
it wouldn't matter.  (Though I also disagree that a depth of 100
achieves that, consider persistent chain forks).