1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bip@mattwhitlock.name>) id 1XD3UC-0000ji-9s
for bitcoin-development@lists.sourceforge.net;
Fri, 01 Aug 2014 03:26:28 +0000
X-ACL-Warn:
Received: from qmta04.westchester.pa.mail.comcast.net ([76.96.62.40])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1XD3UB-0005ju-9I for bitcoin-development@lists.sourceforge.net;
Fri, 01 Aug 2014 03:26:28 +0000
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76])
by qmta04.westchester.pa.mail.comcast.net with comcast
id ZFNN1o0051ei1Bg54FSMiM; Fri, 01 Aug 2014 03:26:21 +0000
Received: from crushinator.localnet
([IPv6:2601:6:4800:47f:1e4e:1f4d:332c:3bf6])
by omta24.westchester.pa.mail.comcast.net with comcast
id ZFSM1o0052JF60R3kFSM6v; Fri, 01 Aug 2014 03:26:21 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: Gregory Maxwell <gmaxwell@gmail.com>
Date: Thu, 31 Jul 2014 23:26:20 -0400
Message-ID: <1515086.GQImTWpAiA@crushinator>
User-Agent: KMail/4.13.3 (Linux/3.12.21-gentoo-r1; KDE/4.13.3; x86_64; ; )
In-Reply-To: <CAAS2fgQPVwMzHBWmbRLBHZcm+YEbioqUHoL_a-SLr9yWDmguiw@mail.gmail.com>
References: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>
<3826251.5rGb1MfKOu@crushinator>
<CAAS2fgQPVwMzHBWmbRLBHZcm+YEbioqUHoL_a-SLr9yWDmguiw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [76.96.62.40 listed in list.dnswl.org]
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XD3UB-0005ju-9I
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] deterministic transaction expiration
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 03:26:28 -0000
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.
|
