From: Matt Whitlock <bip@mattwhitlock•name>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] deterministic transaction expiration
Date: Thu, 31 Jul 2014 23:26:20 -0400 [thread overview]
Message-ID: <1515086.GQImTWpAiA@crushinator> (raw)
In-Reply-To: <CAAS2fgQPVwMzHBWmbRLBHZcm+YEbioqUHoL_a-SLr9yWDmguiw@mail.gmail.com>
On Thursday, 31 July 2014, at 7:28 pm, Gregory Maxwell wrote:
> On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock <bip@mattwhitlock•name> wrote:
> > It would make more sense to introduce a new script opcode that pushes the current block height onto the operand stack. Then you could implement arbitrary logic about which blocks the transaction can be valid in. This would require that the client revalidate all transactions in its mempool (really, only those making use of this opcode) whenever the chain tip changes.
>
> Transactions that become invalid later are have pretty severe
> consequences because they might mean that completely in an absence of
> fraud transactions are forever precluded due to a otherwise harmless
> reorg.
I understand what you're saying, but I don't understand why it's a problem. Transactions shouldn't be considered "final" until a reasonable number of confirmations anyway, so the possibility that an "accepted" transaction could become invalid due to a chain reorganization is not a new danger. Ordinary transactions can similarly become invalid due to chain reorganizations, due to inputs already having been spent in the new branch.
next prev parent reply other threads:[~2014-08-01 3:26 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-01 0:58 Kaz Wesley
2014-08-01 1:06 ` Peter Todd
2014-08-01 1:37 ` Kaz Wesley
2014-08-01 1:38 ` Matt Whitlock
2014-08-01 2:28 ` Gregory Maxwell
2014-08-01 3:26 ` Matt Whitlock [this message]
2014-08-01 3:31 ` Gregory Maxwell
2014-08-05 18:01 ` Alex Mizrahi
2014-08-02 0:36 ` Tom Harding
2014-08-05 17:02 ` Flavien Charlon
2014-08-05 17:48 ` Jeff Garzik
2014-08-05 18:54 ` Mike Hearn
2014-08-05 19:08 ` Jeff Garzik
2014-08-05 19:10 ` Kaz Wesley
2014-08-05 19:36 ` Jeff Garzik
2014-08-06 4:01 ` Tom Harding
2014-08-06 12:55 ` Jeff Garzik
2014-08-06 13:54 ` Mike Hearn
2014-08-06 14:44 ` Tom Harding
2014-08-06 15:08 ` Jeff Garzik
2014-08-06 15:17 ` Christian Decker
2014-08-06 15:42 ` Peter Todd
2014-08-06 16:15 ` Jeff Garzik
2014-08-06 17:02 ` Tom Harding
2014-08-06 17:21 ` Mark Friedenbach
2014-08-06 17:34 ` Peter Todd
2014-08-06 17:24 ` Jeff Garzik
2014-08-06 16:31 ` Mark Friedenbach
2014-08-06 17:20 ` Peter Todd
2014-08-06 17:30 ` Mark Friedenbach
2014-08-06 17:38 ` Peter Todd
2014-08-08 17:38 ` Tom Harding
2014-08-08 18:13 ` Jeff Garzik
2014-08-08 18:42 ` Kaz Wesley
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=1515086.GQImTWpAiA@crushinator \
--to=bip@mattwhitlock$(echo .)name \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/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