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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@bitpay.com>) id 1XEkXT-0003Hq-3D
for bitcoin-development@lists.sourceforge.net;
Tue, 05 Aug 2014 19:36:51 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.213.173 as permitted sender)
client-ip=209.85.213.173; envelope-from=jgarzik@bitpay.com;
helo=mail-ig0-f173.google.com;
Received: from mail-ig0-f173.google.com ([209.85.213.173])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XEkXL-0000L8-0c
for bitcoin-development@lists.sourceforge.net;
Tue, 05 Aug 2014 19:36:51 +0000
Received: by mail-ig0-f173.google.com with SMTP id h18so7559383igc.6
for <bitcoin-development@lists.sourceforge.net>;
Tue, 05 Aug 2014 12:36:37 -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=tgibydKW5BZQidZ61S256+tJ2wH0MHbcWzAO5xokkkQ=;
b=dz4BEw3fVIa0SjlW4YE7EO1BinGsIq9VTjiL1XBgVW0wEsePPWcxbHDOOLV5Dyqyxk
/d+ZI66XzM7DbeMFOCfiGLuk3RWyOvh5B8dzNX1tigveLbRPcsOYjqGqxmi+ooC2DRX9
QMi1I1B0V2c7yaFLwjTl/S7mnqC2dVxBO8aL/mQYjkgB+dX33GjrrbshJOMrcUOQN/tX
ofEE+h/TTUXq+11Z0lfFvrG38KszZy+z2O6jQ1CbHJUP8guhanUrc9TnZdbESIrskoTv
ErDSH2ioCTtXrTHuBbRNqaKdzcPcZeJbcowRp1Uciw8iFEyL4mXF0/r9p4Jt+9NsWBJt
2u3A==
X-Gm-Message-State: ALoCoQnfUDM6jKZimuLszatAktfsaIaHjlDYtdioaJIaApKqJ3q7Llcik2g1zEu2IeJpRAGEdXOe
X-Received: by 10.50.126.100 with SMTP id mx4mr10216201igb.1.1407267397525;
Tue, 05 Aug 2014 12:36:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.78 with HTTP; Tue, 5 Aug 2014 12:36:17 -0700 (PDT)
In-Reply-To: <CA+iPb=ET+A-qB8TgPX8D-ut1DWnq9tZJ=14igfRVWO6eog6Xgw@mail.gmail.com>
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>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Tue, 5 Aug 2014 15:36:17 -0400
Message-ID: <CAJHLa0NrnOD0zNw_7E_3K_VTj=h2TJrWNZ=DEN9p7DWF=DUfDw@mail.gmail.com>
To: Kaz Wesley <keziahw@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3a9604558a8604ffe6f990
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: 1XEkXL-0000L8-0c
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 19:36:51 -0000
--047d7b3a9604558a8604ffe6f990
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 5, 2014 at 3:10 PM, Kaz Wesley <keziahw@gmail.com> wrote:
> Any approach based on beginning a transaction expiry countdown when a
> transaction is received (as in mempool janitor) seems unviable to me:
>
...
> That's why I think including information in the transaction itself, as
> with my nLockTime/IsStandard proposal, is necessary for transactions
> to reliably eventually die off from mempools.
>
"reliably die off from mempools" leads into the land of "tightly
synchronizing memory pools across the network" which is a problem of...
large scope and much debate. :)
For the moment, simply capping the mempool's size at each local node is a
much more reachable goal. Capping, then, implies some culling policy. In
general, bitcoind Tx mempool size is rather open ended, and that needs
sorting out.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--047d7b3a9604558a8604ffe6f990
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Aug 5, 2014 at 3:10 PM, Kaz Wesley <span dir=3D"ltr"><<a href=3D"mai=
lto:keziahw@gmail.com" target=3D"_blank">keziahw@gmail.com</a>></span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">Any approach based on beg=
inning a transaction expiry countdown when a<br>
transaction is received (as in mempool janitor) seems unviable to me:<br>
</blockquote><div>... <br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">That's why I think including information in the transaction itse=
lf, as<br>
with my nLockTime/IsStandard proposal, is necessary for transactions<br>
to reliably eventually die off from mempools.<br></blockquote></div><br></d=
iv><div class=3D"gmail_extra">"reliably die off from mempools" le=
ads into the land of "tightly synchronizing memory pools across the ne=
twork" which is a problem of... large scope and much debate.=C2=A0 :)<=
br>
<br></div><div class=3D"gmail_extra">For the moment, simply capping the mem=
pool's size at each local node is a much more reachable goal.=C2=A0 Cap=
ping, then, implies some culling policy.=C2=A0 In general, bitcoind Tx memp=
ool size is rather open ended, and that needs sorting out.=C2=A0 <br clear=
=3D"all">
</div><div class=3D"gmail_extra"><br>-- <br>Jeff Garzik<br>Bitcoin core dev=
eloper and open source evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a hr=
ef=3D"https://bitpay.com/" target=3D"_blank">https://bitpay.com/</a>
</div></div>
--047d7b3a9604558a8604ffe6f990--
|
