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; 
MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] deterministic transaction expiration
Precedence: list

--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">&lt;<a href=3D"mai=
lto:keziahw@gmail.com" target=3D"_blank">keziahw@gmail.com</a>&gt;</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&#39;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">&quot;reliably die off from mempools&quot; le=
ads into the land of &quot;tightly synchronizing memory pools across the ne=
twork&quot; 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&#39;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--