Subject: Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

From: Gregory Maxwell <[email-masked]>
Date: Fri, 23 Sep 2016 23:43:49 +0000

On Fri, Sep 23, 2016 at 10:20 PM, Luke Dashjr via bitcoin-dev
<[email-masked]> 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).