From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2FA4AB3D for ; Wed, 15 Jul 2015 00:25:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D38247C for ; Wed, 15 Jul 2015 00:25:09 +0000 (UTC) Received: by pdbqm3 with SMTP id qm3so14164189pdb.0 for ; Tue, 14 Jul 2015 17:25:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Lhv7DKDaYD+yjSYcQYgGaRt2zJMXxT0T4tI342hxWGY=; b=kMCG9zDCMTvzsMVMccAlh3lFUvaZ0Sf64mzuBaN68ZJnZF1ZpUUXUE80VbE4awmsR4 Sfgim2+ujWtAG6OzMXFJMNZevGVW9Aqbc1SbhoNM5e4QxDcK58/IZfhiM+pQQdu2Ezfz ssLoPNoD5Q49FJEH24BhF8pU67ERZXoP4j22iWmGX6yu/bT6O+f08ZIOVvQehjmSR7C3 UXCT+kZKGKhiStx5kq+/9pTA74wCEY2VlzwT91gKjza02llOCwC2VAmVfSx+f4wjKKtt AR1XbqYGkdNDQ4VzYKVnQX43fQiPhRHAp9NwcHpcjtONlo2R6MHFDzFoM8wWW3CksGIs MCVg== X-Gm-Message-State: ALoCoQncYqv+tIyOoPEO9WOC/rwvTViPE2m/RejD9Wd+qRn7T0PcQUuvwWK70tlMNdoUIIZbpk8m X-Received: by 10.70.100.105 with SMTP id ex9mr2305742pdb.115.1436919909394; Tue, 14 Jul 2015 17:25:09 -0700 (PDT) Received: from [10.100.1.239] ([204.58.254.99]) by smtp.googlemail.com with ESMTPSA id ie3sm2551661pbb.49.2015.07.14.17.25.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Jul 2015 17:25:08 -0700 (PDT) Message-ID: <55A5A837.1090203@thinlink.com> Date: Tue, 14 Jul 2015 17:24:23 -0700 From: Tom Harding User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Bitcoin Dev Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_WEB autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Mempool "Expected Byte Stay" policy X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 00:25:10 -0000 Spammers out there are being very disrepectful of my fullnode resources these days! I'm making some changes. In case others are interested, here's a description: There is now a maximum size for the memory pool. Space is allocated with a pretty simple rule. For each tx, I calculate MY COST of continuing to hold it in the mempool. I measure the cost to me by "expected byte stay": expectedByteStay = sizeBytes * expectedBlocksToConfirm(feeRate) Rule 1: When there's not enough space for a new tx, I try to make space by evicting txes with expectedByteStay higher than tx. I'm NOT worrying about - Fees EXCEPT via their effect on confirmation time - Coin age You already made money on your old coins. Pay up. - CPFP Child's expectedBlocksToConfirm is max'ed with its parent, then parent expectedByteStay is ADDED to child's - Replacement You'll get another chance in 2 hours (see below). Rule 2: A transaction and its dependents are evicted on its 2-hour anniversary, whether space is required or not The latest expectedBlocksToConfirm(feeRate) table is applied to the entire mempool periodically. What do you think? I'll let you know how it works out. I'm putting a lot of faith in the new fee estimation (particularly its size independence). Another possibility is clog-ups by transactions that look like they'll confirm next block, but don't because of factors other than fees (other people's blacklists?)