From: Gregory Maxwell <greg@xiph•org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT
Date: Fri, 23 Sep 2016 18:57:57 +0000 [thread overview]
Message-ID: <CAAS2fgTJ9iPoE6fvMBhFB8ruwy-6aTo4Ka5agK+LHjSqGa2-rw@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgQGC695mkyze+mVTZZoQN1mh+1y32u-D6Yv1R7nXWPDcg@mail.gmail.com>
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.
next prev parent reply other threads:[~2016-09-23 18:57 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 [this message]
2016-09-23 20:02 ` Peter Todd
2016-09-23 22:20 ` Luke Dashjr
2016-09-23 23:43 ` Gregory Maxwell
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=CAAS2fgTJ9iPoE6fvMBhFB8ruwy-6aTo4Ka5agK+LHjSqGa2-rw@mail.gmail.com \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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