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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <keziahw@gmail.com>) id 1XD1nP-0007xH-MY
for bitcoin-development@lists.sourceforge.net;
Fri, 01 Aug 2014 01:38:11 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.43 as permitted sender)
client-ip=209.85.219.43; envelope-from=keziahw@gmail.com;
helo=mail-oa0-f43.google.com;
Received: from mail-oa0-f43.google.com ([209.85.219.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XD1nO-000790-R2
for bitcoin-development@lists.sourceforge.net;
Fri, 01 Aug 2014 01:38:11 +0000
Received: by mail-oa0-f43.google.com with SMTP id i7so2645047oag.30
for <bitcoin-development@lists.sourceforge.net>;
Thu, 31 Jul 2014 18:38:05 -0700 (PDT)
X-Received: by 10.182.66.130 with SMTP id f2mr2945040obt.84.1406857085392;
Thu, 31 Jul 2014 18:38:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.61.195 with HTTP; Thu, 31 Jul 2014 18:37:45 -0700 (PDT)
In-Reply-To: <20140801010657.GA15436@localhost.localdomain>
References: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>
<20140801010657.GA15436@localhost.localdomain>
From: Kaz Wesley <keziahw@gmail.com>
Date: Thu, 31 Jul 2014 18:37:45 -0700
Message-ID: <CA+iPb=GoGEXGprC6QCXrecM7qOTpCh09cYNqymXq5XH2zsELWQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
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
(keziahw[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: 1XD1nO-000790-R2
Cc: Bitcoin Dev <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 01:38:11 -0000
On Thu, Jul 31, 2014 at 6:06 PM, Peter Todd <pete@petertodd.org> wrote:
> Anything that changes the semantics of nLockTime will do harm to
> existing and future applications that make use of nLockTime for things
> like refund transactions.
I think this would be compatible with most uses of nLockTime -- e.g.,
at the time a refund transaction becomes broadcastable, its
beneficiary would usually have no reason to wait for a long time
before broadcasting it; if they did so (probably because they weren't
online to redeem the refund), they'd need to use the
submit-directly-to-miner option, but they wouldn't lose their refund.
> In any case, why do transactions need finite lifespans in mempools? If
> you want to double-spend them with higher fees, then implement
> replace-by-fee.
Perpetuating transactions that have been in mempools for a long time
and are not being confirmed has been cited as a reason for nodes not
to exchange mempools (#3721, #1833, #3722); it's been implied that it
would be desirable for wallets to wait until a transaction had had a
chance to be accepted before double-spending with a higher fee
(#3722); and an unconfirmed transaction-age-based policy for
preventing mempool accumulation has been advocated (#3753, #3722) [I
hope my summarization is not misrepresenting anyone's opinions here;
please see the arguments made in the actual comments on the bugs].
These discussions are mostly fairly old, but I don't know of any
changes that have been made that provide alternative answers to these
concerns mentioned by at least three different developers.
> In any case, lifetimes will never be deterministic as not everyone runs
> the same software.
That's true, but none of the benefits of these changes require the
policy to be unanimous; most of the effect could be provided by most
of the network following these rules.
>> Transactions would stop being relayed and drop out of mempools a fixed
>> number of blocks from their creation; once that window had passed, the
>> sender's wallet could begin to expect the transaction would not be
>> confirmed. In case a reorg displaces a transaction until after its
>> expiry height, a miner can still put it back in the blockchain; the
>> expiry height is just a relay rule. Also, a user who needed to get
>> their original "expired" transaction confirmed could still do so by
>> submitting it directly to a miner with suitable policies.
>
> ...in which case someone will circumvent this IsStandard() rule by
> submitting "expired" transactions directly to miners with suitable
> policies.
Yes, that is a feature. None of the benefits of transaction expiration
rely on expiration being final, and any possible downsides of
expiration are largely mitigated by the option still being available
to get expired transactions mined.
|
