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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tomh@thinlink.com>) id 1XEsQF-000342-Fi
for bitcoin-development@lists.sourceforge.net;
Wed, 06 Aug 2014 04:01:55 +0000
X-ACL-Warn:
Received: from mail-pa0-f48.google.com ([209.85.220.48])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XEsQE-0005pi-D9
for bitcoin-development@lists.sourceforge.net;
Wed, 06 Aug 2014 04:01:55 +0000
Received: by mail-pa0-f48.google.com with SMTP id et14so2642033pad.35
for <bitcoin-development@lists.sourceforge.net>;
Tue, 05 Aug 2014 21:01:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=G1EWHFavRCIfnLTmNL0QfS00MflqnCi/d44F3DzcVEc=;
b=GZubvNxXQpmUWgKMtZddDDba1HxlKA9AdjoNtiUZPR1YDZn3T36CN1AsyxH908x1L0
5jXCAuW2X5Ei0gJ+1Oe3Bv1KpZDYxqdcyuv9suX0sxouWaEYLBQviT+tkjgnhD2lNHeu
475TCSITyllVbr5HBy/cFGRHipo7qCzAwliG4Wz1tHf5k9UmSBSPLOHmoUyc9TQ8bjax
9cgQHhtgGzW49LNTRaWtny0R+EDUCYwzWed53aFE1udS1UXXmR1KR2N3O9L/ZiHrvGZC
scjD/xerVfZLksGR3s48vaQk7IzlDLlRW4HKMX8+V34RKcjQdxfysYNlCK/RJ+LieXcY
7fQA==
X-Gm-Message-State: ALoCoQlFfprGQbjwz9yqWy7ZjCG9jLYpdAXhaxJKDQcwViMsooo+Gye64HJt958SB0spQ3bIZPF1
X-Received: by 10.70.140.13 with SMTP id rc13mr8720053pdb.127.1407297708570;
Tue, 05 Aug 2014 21:01:48 -0700 (PDT)
Received: from [192.168.1.89] (99-6-44-248.lightspeed.sntcca.sbcglobal.net.
[99.6.44.248]) by mx.google.com with ESMTPSA id
vu7sm12687334pab.34.2014.08.05.21.01.47
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Tue, 05 Aug 2014 21:01:47 -0700 (PDT)
Message-ID: <53E1A8AF.4030206@thinlink.com>
Date: Tue, 05 Aug 2014 21:01:51 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com> <CAJHLa0O2wFq2Vs5Bes_8x1q_j0VC+U4DQkx=6GqT8w5e8Lh5Qg@mail.gmail.com>
<CA+iPb=ET+A-qB8TgPX8D-ut1DWnq9tZJ=14igfRVWO6eog6Xgw@mail.gmail.com>
In-Reply-To: <CA+iPb=ET+A-qB8TgPX8D-ut1DWnq9tZJ=14igfRVWO6eog6Xgw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1XEsQE-0005pi-D9
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: Wed, 06 Aug 2014 04:01:55 -0000
On 8/5/2014 12:10 PM, Kaz Wesley wrote:
> Any approach based on beginning a transaction expiry countdown when a
> transaction is received (as in mempool janitor) seems unviable to me:
> once a node has forgotten a transaction, it must be susceptible to
> reaccepting it;
It's hard to argue with that logic.
If nLockTime is used for expiration, transaction creator can't lie to
help tx live longer without pushing initial confirmation eligibility
into the future. Very pretty. It would also enable "fill or kill"
transactions with a backdated nLockTime, which must be confirmed in a
few blocks, or start vanishing from mempools.
|
