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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1XD3Z0-0003Bz-DY
for bitcoin-development@lists.sourceforge.net;
Fri, 01 Aug 2014 03:31:26 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.180 as permitted sender)
client-ip=209.85.220.180; envelope-from=gmaxwell@gmail.com;
helo=mail-vc0-f180.google.com;
Received: from mail-vc0-f180.google.com ([209.85.220.180])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XD3Yz-0005tc-8F
for bitcoin-development@lists.sourceforge.net;
Fri, 01 Aug 2014 03:31:26 +0000
Received: by mail-vc0-f180.google.com with SMTP id ij19so5635826vcb.25
for <bitcoin-development@lists.sourceforge.net>;
Thu, 31 Jul 2014 20:31:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.220.74.10 with SMTP id s10mr3096498vcj.61.1406863879656;
Thu, 31 Jul 2014 20:31:19 -0700 (PDT)
Received: by 10.52.187.132 with HTTP; Thu, 31 Jul 2014 20:31:19 -0700 (PDT)
In-Reply-To: <1515086.GQImTWpAiA@crushinator>
References: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>
<3826251.5rGb1MfKOu@crushinator>
<CAAS2fgQPVwMzHBWmbRLBHZcm+YEbioqUHoL_a-SLr9yWDmguiw@mail.gmail.com>
<1515086.GQImTWpAiA@crushinator>
Date: Thu, 31 Jul 2014 20:31:19 -0700
Message-ID: <CAAS2fgT2g9FgsVuKWLLxNqE_pp1DgdAc-edLL474UQ+eJQiXwg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1XD3Yz-0005tc-8F
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:31:26 -0000
On Thu, Jul 31, 2014 at 8:26 PM, Matt Whitlock <bip@mattwhitlock.name> wrot=
e:
> I understand what you're saying, but I don't understand why it's a proble=
m. Transactions shouldn't be considered "final" until a reasonable number o=
f confirmations anyway, so the possibility that an "accepted" transaction c=
ould become invalid due to a chain reorganization is not a new danger. Ordi=
nary 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=E2=80=94 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=E2=80=94 e.g. flooding the network with unrelated high fee transacti=
ons
in order to push a transaction out to where it can never be mined at
all.
|
