From: Gregory Maxwell <greg@xiph•org>
To: Luke Dashjr <luke@dashjr•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT
Date: Fri, 23 Sep 2016 23:43:49 +0000 [thread overview]
Message-ID: <CAAS2fgTCOq1pHrPVbkNzCp_bYqbXh6Y6osF5_jFUZRy1rWPQCw@mail.gmail.com> (raw)
In-Reply-To: <201609232220.41783.luke@dashjr.org>
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).
next prev parent reply other threads:[~2016-09-23 23:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-23 9:57 Luke Dashjr
2016-09-23 13:43 ` Russell O'Connor
[not found] ` <CAAS2fgQGC695mkyze+mVTZZoQN1mh+1y32u-D6Yv1R7nXWPDcg@mail.gmail.com>
2016-09-23 18:57 ` Gregory Maxwell
2016-09-23 20:02 ` Peter Todd
2016-09-23 22:20 ` Luke Dashjr
2016-09-23 23:43 ` Gregory Maxwell [this message]
2016-09-23 14:37 ` Tom
2016-09-23 22:34 ` Luke Dashjr
2016-09-24 0:08 ` Dave Scotese
2016-09-24 9:37 ` Tom
2016-09-23 16:18 ` Peter Todd
2016-10-01 4:01 ` Rusty Russell
2016-10-01 5:02 ` Luke Dashjr
2016-10-05 2:15 ` Nathan Cook
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=CAAS2fgTCOq1pHrPVbkNzCp_bYqbXh6Y6osF5_jFUZRy1rWPQCw@mail.gmail.com \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/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