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
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@bitpay.com>) id 1XEiqr-00029y-Fa
for bitcoin-development@lists.sourceforge.net;
Tue, 05 Aug 2014 17:48:45 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.223.170 as permitted sender)
client-ip=209.85.223.170; envelope-from=jgarzik@bitpay.com;
helo=mail-ie0-f170.google.com;
Received: from mail-ie0-f170.google.com ([209.85.223.170])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XEiqq-0004dr-BX
for bitcoin-development@lists.sourceforge.net;
Tue, 05 Aug 2014 17:48:45 +0000
Received: by mail-ie0-f170.google.com with SMTP id rl12so1489954iec.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 05 Aug 2014 10:48:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=+abJyQZGk+kZA+773GQTsQaGhqbFIUZIuoQAHE9cNd4=;
b=cNuMKfmSsdYnCT2QIYAf7DiUCXUDtNCMlEKlUSuJC0mRrEb5NzcuX5rRfh7gNvMxEd
d6fSuMUE9c+6XLj7vcLFf5CeQjh+ii600qXaTa3pBLHWQX3V1WPR51+rJdsxGeljUT8V
eU0UmXE90tzjMSGObNu0h/CCntRPTd8kEOTZP2TMYkpTnKo1u2e6X9LD556USS+9maxW
JgkHBUZeJbXj9KcCsCOEh8klB8azOqblHLjbm1+lclM0gqtDFK/vCL3n1iMWLMhSVxFf
IJsbkjdTEMshkX2ZhNhFNu0GDuh3NPCNg75EAy7LDFR5ebrI6DxBaDkIj+kh9zsbUXhr
wSZw==
X-Gm-Message-State: ALoCoQnUDYmNANLtrZZl7b/I2gdm+plMnqATsqCt8/4vCmFZiuEVxKl6pJYJztSRFl8CAqBWDDDA
X-Received: by 10.50.80.116 with SMTP id q20mr50871128igx.22.1407260918977;
Tue, 05 Aug 2014 10:48:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.78 with HTTP; Tue, 5 Aug 2014 10:48:18 -0700 (PDT)
In-Reply-To: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>
References: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Tue, 5 Aug 2014 13:48:18 -0400
Message-ID: <CAJHLa0O2wFq2Vs5Bes_8x1q_j0VC+U4DQkx=6GqT8w5e8Lh5Qg@mail.gmail.com>
To: Kaz Wesley <keziahw@gmail.com>
Content-Type: multipart/alternative; boundary=089e015366822eae5504ffe57711
X-Spam-Score: -0.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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1XEiqq-0004dr-BX
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: Tue, 05 Aug 2014 17:48:45 -0000
--089e015366822eae5504ffe57711
Content-Type: text/plain; charset=UTF-8
Glad this was brought up.
Transaction expiration is something that I have wanted to see happen in
bitcoin for a long, long time. The user experience of unconfirming
transactions setting around in limbo is just horrible. Bitcoin software by
necessity has gotten better about attaching fees so this sort of behavior
is uncommon, but that does not eliminate the problem.
Of course, we cannot presume that a transaction will truly disappear -- The
Internet Never Forgets -- but given a bit of mempool adjusting, we can
achieve the next best thing: the majority of the network "forgets" the
transaction and becomes willing to relay a respend of some or all of the
inputs. This uses existing client logic where the client must rebroadcast
a transaction until it is confirmed.
In general, if a transaction has not made it into a block within 144*X
blocks, there is _some_ reason it is getting rejected by the miners.
The mempool janitor is a garbage collector design. This is inferior to the
"superblock" model described at
https://github.com/bitcoin/bitcoin/issues/3723 Other models can also
achieve similar results.
There are a lot of issues tied together here: transaction expiration, the
desire to cap the mempool ram usage, scalability, DoS prevention, ...
mempool ties a lot together.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--089e015366822eae5504ffe57711
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>Glad this was brought up.<br><br></div=
>Transaction expiration is something that I have wanted to see happen in bi=
tcoin for a long, long time.=C2=A0 The user experience of unconfirming tran=
sactions setting around in limbo is just horrible.=C2=A0 Bitcoin software b=
y necessity has gotten better about attaching fees so this sort of behavior=
is uncommon, but that does not eliminate the problem.<br>
<br></div>Of course, we cannot presume that a transaction will truly disapp=
ear -- The Internet Never Forgets -- but given a bit of mempool adjusting, =
we can achieve the next best thing:=C2=A0 the majority of the network "=
;forgets" the transaction and becomes willing to relay a respend of so=
me or all of the inputs.=C2=A0 This uses existing client logic where the cl=
ient must rebroadcast a transaction until it is confirmed.<br>
<br></div>In general, if a transaction has not made it into a block within =
144*X blocks, there is _some_ reason it is getting rejected by the miners.<=
br><br></div>The mempool janitor is a garbage collector design.=C2=A0 This =
is inferior to the "superblock" model described at <a href=3D"htt=
ps://github.com/bitcoin/bitcoin/issues/3723">https://github.com/bitcoin/bit=
coin/issues/3723</a>=C2=A0=C2=A0 Other models can also achieve similar resu=
lts.<br>
<div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">There =
are a lot of issues tied together here:=C2=A0 transaction expiration, the d=
esire to cap the mempool ram usage, scalability, DoS prevention, ...=C2=A0=
=C2=A0 mempool ties a lot together.<br clear=3D"all">
<br>-- <br>Jeff Garzik<br>Bitcoin core developer and open source evangelist=
<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.com/" target=
=3D"_blank">https://bitpay.com/</a>
</div></div></div>
--089e015366822eae5504ffe57711--
|
