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 AABD21240 for ; Wed, 17 Feb 2016 02:43:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2D8E0163 for ; Wed, 17 Feb 2016 02:43:03 +0000 (UTC) Received: by mail-io0-f174.google.com with SMTP id z135so17445198iof.0 for ; Tue, 16 Feb 2016 18:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=tcCLUuzbCu0P35eCv62Fx8ovXaU50amK7YGFrNdxim4=; b=PIiivooywjTGPug98qLyp+M6DEQ1DvJ8X8fJi5Fl5mn7w9q8NTcpPqQda22BREalXh BT+Hz9cB6ewjNGPaqkP7N5IZ/c77cKOwoqPJHT4mNc+OIQhLxy88wWgCY1kGDT0UBrPO L5bmKYIn9mbcHrnLsGGmfvGAxgbVgQ1uGKGT58uTCfhzbz4u1pZqtcd71uU0zwSvAGYy YybSIbS9gDwsVnaONc3q1iEPfxcFczcekTsF3IckXKvGY3jJBxHR7JiUAWHRJHPnh3oo J/Lk/SRGfdg+43ARkLmblzAjmtz1QtTx19T7TaGrPwjKlcw7VdfD6kWZ7nGiIRc+ZYyQ yatQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=tcCLUuzbCu0P35eCv62Fx8ovXaU50amK7YGFrNdxim4=; b=eibf5rJPsBzpUE88TVI/AyccFst46TL9NaiAQiIrUjJnjBUnGyntoKsZqa0TjAESrE ZKkD7NQcOOznjQkiOeqfuHZg3dzp6+hu8gqXHHyXdxVMExDKpVCmeEBsOaoCy0WOIuOz 9nbRbl8YNXZ1X1GyjpVx4hAxpeY3f3jGlMy87+RqCZPcA2aELh8asia77o8OG0r4OBrp 3qY8gbNheNKMZfzpOgYUTvICaS/EMUVLH9W2UYufMjlgQmqzGQQa0cemWbt8+6O96Di6 QCr5T0RmKiyqxcHVFSXMqT0iCHv2eUe8kNStfOOhP6iKrZgQI/79hywVwJdMwvgBFjRN rcwg== X-Gm-Message-State: AG10YOR+YsZ/S8x2CcXmTEUM0/qR6PR9/kt0XbDFnCXGW9JGnEqZe5QLAROBELOhS5noyc++JjOimn7KVX9Mkg== MIME-Version: 1.0 X-Received: by 10.107.132.142 with SMTP id o14mr768906ioi.75.1455676982728; Tue, 16 Feb 2016 18:43:02 -0800 (PST) Sender: gmaxwell@gmail.com Received: by 10.107.132.75 with HTTP; Tue, 16 Feb 2016 18:43:02 -0800 (PST) In-Reply-To: <201602170046.17166.luke@dashjr.org> References: <201602170046.17166.luke@dashjr.org> Date: Wed, 17 Feb 2016 02:43:02 +0000 X-Google-Sender-Auth: NGEApIQ-_iCuMKLPRVXNHSySg2M Message-ID: From: Gregory Maxwell To: Bitcoin Dev Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] [BIP Proposal] New "feefilter" p2p message 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, 17 Feb 2016 02:43:03 -0000 On Wed, Feb 17, 2016 at 12:46 AM, Luke Dashjr via bitcoin-dev wrote: > On Tuesday, February 16, 2016 8:20:26 PM Alex Morcos via bitcoin-dev wrote: >> # The feefilter message is defined as a message containing an int64_t where >> pchCommand == "feefilter" > > What happened to extensibility? I did think it might be interesting to do a priorityrate filter. but since it seems no one is even working on adding an index for ancestor priorityrate... or working on a space limited priority mempool... if that extension would be needed it could just be a new "priorityfilt" command. > And why waste 64 bits for what is almost > certainly a small number? Technically fees per byte could be greater than 32 bits (e.g. a 9000 BTC fee is enough). Values are normally 64 bits already. >> # The fee filter is additive with a bloom filter for transactions so if an >> SPV client were to load a bloom filter and send a feefilter message, >> transactions would only be relayed if they passed both filters. > > This seems to make feefilter entirely useless for wallets? I think your reasoning is that you want to learn of your own transactions even if they don't meet the filter? I'm not sure this reasoning plays out though-- regardless of what your own feefilter is, if a tx has too low a rate for your peers to relay it, they won't and you won't learn of it. I might wave my hands at a use case for OR "I will relay very high fee txn ... or my own"; but considering that performance/privacy disaster that bloom filters are-- and that to relay third party txn at all you need to be able to validate them (or will get yourself banned). Also, if you really want the OR behavior you could make two connections... the same cannot be said for and. Maybe one argument I could add is that if we added a priorityrate filter, that one would be an OR