From: Gregory Maxwell <gmaxwell@gmail•com>
To: Matt Whitlock <bip@mattwhitlock•name>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] deterministic transaction expiration
Date: Thu, 31 Jul 2014 20:31:19 -0700 [thread overview]
Message-ID: <CAAS2fgT2g9FgsVuKWLLxNqE_pp1DgdAc-edLL474UQ+eJQiXwg@mail.gmail.com> (raw)
In-Reply-To: <1515086.GQImTWpAiA@crushinator>
On Thu, Jul 31, 2014 at 8:26 PM, Matt Whitlock <bip@mattwhitlock•name> wrote:
> 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.
A distinction there is that they can only become invalid via a
conflict— replaced by another transaction authored by the prior
signers. If no other transaction could be created (e.g. you're a
multisigner and won't sign it again) then there is no such risk. It
now introduces chance events ("act of god") into the mix where they
they didn't exist before. Basically it takes was what is a very loose
one way coupling and makes it much tighter. I'm sure if you spend a
bit thinking you can come up with some more corner cases that it would
expose— e.g. flooding the network with unrelated high fee transactions
in order to push a transaction out to where it can never be mined at
all.
next prev parent reply other threads:[~2014-08-01 3:31 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
2014-08-01 3:31 ` Gregory Maxwell [this message]
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=CAAS2fgT2g9FgsVuKWLLxNqE_pp1DgdAc-edLL474UQ+eJQiXwg@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bip@mattwhitlock$(echo .)name \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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