Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.213.179 as permitted sender)
	client-ip=209.85.213.179; envelope-from=jgarzik@bitpay.com;
	helo=mail-ig0-f179.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP0AXvF5EYvsdpYxGUi5yV9eD_8qUge80XCoaeyekfd67Q@mail.gmail.com>
References: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>
	<CAJHLa0O2wFq2Vs5Bes_8x1q_j0VC+U4DQkx=6GqT8w5e8Lh5Qg@mail.gmail.com>
	<CANEZrP0AXvF5EYvsdpYxGUi5yV9eD_8qUge80XCoaeyekfd67Q@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Tue, 5 Aug 2014 15:08:14 -0400
Message-ID: <CAJHLa0PTCRZL5PzrQYehRKG5G_D1i9zRdoqy4EN2ooMf7rh_8A@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e0153668207b86504ffe695da
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] deterministic transaction expiration
Precedence: list

--089e0153668207b86504ffe695da
Content-Type: text/plain; charset=UTF-8

I feel like a lot of this will be driven by implementation, and costs of
changing the implementation.  Additional look-backs are of course doable,
but they incur some disk I/O costs.  The fields available in memory for
each mempool TX are

    uint256 tx_hash; // hash of next field
    CTransaction tx;
    int64_t nFee; // Cached to avoid expensive parent-transaction lookups
    size_t nTxSize; // ... and avoid recomputing tx size
    int64_t nTime; // Local time when entering the mempool
    double dPriority; // Priority when entering the mempool
    unsigned int nHeight; // Chain height when entering the mempool

As a first pass, we may prune the mempool without additional db lookups
quite easily based on time criteria.  Or, additional in-memory indexes may
be constructed to maintain hashes ordered by priority/fees.

Those techniques seem likely to be attempted before resorting to looking
back two or three TXs deep at coin age -- which I admit is an interesting
metric.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

--089e0153668207b86504ffe695da
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I feel like a lot of this will be driven by impl=
ementation, and costs of changing the implementation.=C2=A0 Additional look=
-backs are of course doable, but they incur some disk I/O costs.=C2=A0 The =
fields available in memory for each mempool TX are<br>

<br></div><div>=C2=A0=C2=A0=C2=A0 uint256 tx_hash; // hash of next field<br=
></div><div>=C2=A0=C2=A0=C2=A0 CTransaction tx;<br>=C2=A0=C2=A0=C2=A0 int64=
_t nFee; // Cached to avoid expensive parent-transaction lookups<br>=C2=A0=
=C2=A0=C2=A0 size_t nTxSize; // ... and avoid recomputing tx size<br>

=C2=A0=C2=A0=C2=A0 int64_t nTime; // Local time when entering the mempool<b=
r>=C2=A0=C2=A0=C2=A0 double dPriority; // Priority when entering the mempoo=
l<br>=C2=A0=C2=A0=C2=A0 unsigned int nHeight; // Chain height when entering=
 the mempool<br><br></div>As a first pass, we may prune the mempool without=
 additional db lookups quite easily based on time criteria.=C2=A0 Or, addit=
ional in-memory indexes may be constructed to maintain hashes ordered by pr=
iority/fees.<br>

<br></div><div>Those techniques seem likely to be attempted before resortin=
g to looking back two or three TXs deep at coin age -- which I admit is an =
interesting metric.<br></div><div><div><div><div class=3D"gmail_extra"><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></div></div>

--089e0153668207b86504ffe695da--