From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XEk6E-0002Rt-B9 for bitcoin-development@lists.sourceforge.net; Tue, 05 Aug 2014 19:08:42 +0000 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; Received: from mail-ig0-f179.google.com ([209.85.213.179]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XEk6D-0001sJ-Bo for bitcoin-development@lists.sourceforge.net; Tue, 05 Aug 2014 19:08:42 +0000 Received: by mail-ig0-f179.google.com with SMTP id h18so1671644igc.12 for ; Tue, 05 Aug 2014 12:08:36 -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=ZPgqVMfo3RTSt4LEXeQmV1xZYLDmb4Mrla6hWs6o5Xg=; b=J8CzchLzxk53Atk4gYXdDU+SefdhG7qFqjYB7sUzcqCU+Wico3dwe+OWR7dzE77QEe TI8bRC3MrZ/Va4lPZHEeyrKajJe87c7EeIH76lv6IHpXvseagUcl/WEYbD7E2hXAaOGJ Elu/iM5pyTUmKev4x6itAkdBWBINURUOT7JL7QBm1GYj4YK3IjlZH6BW++Q7dSzcvF32 3bBNPbURVmQ7JiWcs0M5wmIFM4GEgZUGeko872u3EtWUHr6kXHH5qvjRE9esW4yz7qoJ aATmFd1T/rxmw8ufh6HwsMised7jHUdHeOw6984l5AK51rHdEJ67vV78X9zchQU1q7Cm 8ezQ== X-Gm-Message-State: ALoCoQl7IyGKm5QSE/piMuRPR+8Giy7qG/nd12ocKzK+7ElJw+2RInw9WyfId8ZJqBUctgqdJzEr X-Received: by 10.50.80.116 with SMTP id q20mr51604246igx.22.1407265714403; Tue, 05 Aug 2014 12:08:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.78 with HTTP; Tue, 5 Aug 2014 12:08:14 -0700 (PDT) In-Reply-To: References: From: Jeff Garzik Date: Tue, 5 Aug 2014 15:08:14 -0400 Message-ID: To: Mike Hearn Content-Type: multipart/alternative; boundary=089e0153668207b86504ffe695da 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: 1XEk6D-0001sJ-Bo Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] deterministic transaction expiration X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 19:08:42 -0000 --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
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

=C2=A0=C2=A0=C2=A0 uint256 tx_hash; // hash of next field
=C2=A0=C2=A0=C2=A0 CTransaction tx;
=C2=A0=C2=A0=C2=A0 int64= _t nFee; // Cached to avoid expensive parent-transaction lookups
=C2=A0= =C2=A0=C2=A0 size_t nTxSize; // ... and avoid recomputing tx size
=C2=A0=C2=A0=C2=A0 int64_t nTime; // Local time when entering the mempool=C2=A0=C2=A0=C2=A0 double dPriority; // Priority when entering the mempoo= l
=C2=A0=C2=A0=C2=A0 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.=C2=A0 Or, addit= ional in-memory indexes may be constructed to maintain hashes ordered by pr= iority/fees.

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.

--
Jeff Garzik
Bitcoin core developer and open source evangelist
= BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--089e0153668207b86504ffe695da--