path: root/fb/3413544e2839fcbc50af5b37f5d754b7a35c41

Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 19658123D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 16 Feb 2016 20:20:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
	[209.85.223.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1C1B01A2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 16 Feb 2016 20:20:27 +0000 (UTC)
Received: by mail-io0-f182.google.com with SMTP id l127so205965632iof.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 16 Feb 2016 12:20:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=7IQKADJZN0ktiGrfQPkeTgDfqZff97guXOB/wBLW79k=;
	b=jmKTXJiKujjCZQVRhKxko3RFMT/oryVv0XAPHLkvXM31JP5a58OUGQKQWCCYBXwtZT
	yADMWSdBALExhfQB4jcYE+ynxoT4idnlKNDUsQh5efMQSBOe6NIEh0mzqvgKbLcW4VJm
	uOP/kZiP8uH+22nNp1UsQpqJF7tfU2pYk8T3zV5U8OgenBBEpHoNZ8q5aKYzA+aXk8Sv
	+2rIXfuAI9y9E4JJVqSZCGJPmUqPhYlBqIExYZwGeDJ53IW7TEfxOpeEOM6lPjCxDkWS
	+v2V+4kAXPbG8FcjwXcZaCSNPq5BPCNqqphstcZ7S63oqO3+VQvJ/ErarsR30INyzOEp
	C6fA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:date:message-id:subject:from:to
	:content-type;
	bh=7IQKADJZN0ktiGrfQPkeTgDfqZff97guXOB/wBLW79k=;
	b=SVzzvjNWBKl2MpdCpLW1fcC8WCwIlSSNWCq1+plMcheIRY7KxeEMfZQ30CkU4BISX+
	DG/jKsxN5B12Jl9a54CXe77U/PQ2wVQepH8U4525zbqR3npCXAnz4RnplVDAoSkocrl8
	1eLi2cZczS8c5FSHiDaGsIpzyIKmfQPvwfVIsukgQB55QMjIy8oyGRlRwiu85Mh7ZHjj
	Z5Mzdr0B02OybVyFrcPY7YIPWZiTsw1TJzZod88ZgL7BXF8gqWkgMlr5s64KH7GkhcXF
	vv6DYC22CYYVQFVY6Mbpvnlg45oGsHjFUaU5+cKJQfNVx6++XZYjXUENR1hg2lUdhlL5
	rtAA==
X-Gm-Message-State: AG10YOQNuW0BoT4ycGxT2w3QFgt/j+UGSC/bg0WrdwRfmAoEmXW445jIlrucNKUXtlUyYDBtFL8ZXu3CWL2Fpw==
MIME-Version: 1.0
X-Received: by 10.107.10.147 with SMTP id 19mr23015289iok.46.1455654026521;
	Tue, 16 Feb 2016 12:20:26 -0800 (PST)
Received: by 10.64.113.193 with HTTP; Tue, 16 Feb 2016 12:20:26 -0800 (PST)
Date: Tue, 16 Feb 2016 15:20:26 -0500
Message-ID: <CAPWm=eXi98cC0KP=5WayU05hezDFswrPe+vA58cTHvVLc80OzQ@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113eddf22ad1b7052be8dd2c
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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: [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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2016 20:20:28 -0000

--001a113eddf22ad1b7052be8dd2c
Content-Type: text/plain; charset=UTF-8

Hi,

I'm proposing the addition of a new optional p2p message to help reduce
unnecessary network traffic.  The draft BIP is available here and pasted
below:
https://gist.github.com/morcos/9aab223c443c9258c979

The goal of this message is to take advantage of the fact that when a node
has reached its mempool limit, there is a minimum fee below which no
transactions are accepted to the mempool.  Informing peers of this minimum
would save them inv'ing your node for those transaction id's and save your
node requesting them if they are not in your recentRejects filter.

This message is optional and may be ignored as a protocol rule.  There is
also an option to turn off sending the messages in the implementation.

Thanks to Suhas Daftuar, Greg Maxwell, and others for helping develop the
idea.

-Alex

Draft BIP text:

<pre>
  BIP: <unassigned>
  Title: feefilter message
  Author: Alex Morcos <morcos@chaincode.com>
  Status: Draft
  Type: Standards Track
  Created: 2016-02-13
</pre>

==Abstract==

Add a new message, "feefilter", which serves to instruct peers not to send
"inv"'s to the node for transactions with fees below the specified fee rate.

==Motivation==

The concept of a limited mempool was introduced in Bitcoin Core 0.12 to
provide protection against attacks or spam transactions of low fees that
are not being mined. A reject filter was also introduced to help prevent
repeated requests for the same transaction that might have been recently
rejected for insufficient fee. These methods help keep resource utilization
on a node from getting out of control.

However, there are limitations to the effectiveness of these approaches.
The reject filter is reset after every block which means transactions that
are inv'ed over a longer time period will be rerequested and there is no
method to prevent requesting the transaction the first time.  Furthermore,
inv data is sent at least once either to or from each peer for every
transaction accepted to the mempool and there is no mechanism by which to
know that an inv sent to a given peer would not result in a getdata request
because it represents a transaction with too little fee.

After receiving a feefilter message, a node can know before sending an inv
that a given transaction's fee rate is below the minimum currently required
by a given peer, and therefore the node can skip relaying an inv for that
transaction to that peer.

==Specification==

# The feefilter message is defined as a message containing an int64_t where
pchCommand == "feefilter"
# Upon receipt of a "feefilter" message, the node will be permitted, but
not required, to filter transaction invs for transactions that fall below
the feerate provided in the feefilter message interpreted as satoshis per
kilobyte.
# 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.
# Inv's generated from a mempool message are also subject to a fee filter
if it exists.
# Feature discovery is enabled by checking protocol version >= 70013

==Considerations==
The propagation efficiency of transactions across the network should not be
adversely affected by this change. In general, transactions which are not
accepted to your mempool are not relayed and the funcionality implemented
with this message is meant only to filter those transactions.  There could
be a small number of edge cases where a node's mempool min fee is actually
less than the filter value a peer is aware of and transactions with fee
rates between these values will now be newly inhibited.

Feefilter messages are not sent to whitelisted peers if the
"-whitelistforcerelay" option is set. In that case, transactions are
intended to be relayed even if they are not accepted to the mempool.

There are privacy concerns with deanonymizing a node by the fact that it is
broadcasting identifying information about its mempool min fee. To help
ameliorate this concern, the implementaion quantizes the filter value
broadcast with a small amount of randomness, in addition, the messages are
broadcast to different peers at individually randomly distributed times.

If a node is using prioritisetransaction to accept transactions whose
actual fee rates might fall below the node's mempool min fee, it may want
to consider setting "-nofeefilter" to make sure it is exposed to all
possible txid's.

==Backward compatibility==

Older clients remain fully compatible and interoperable after this change.
The sending of feefilter messages can be disabled by unsetting the
"-feefilter" option.

==Implementation==

https://github.com/bitcoin/bitcoin/pull/7542

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

<div dir=3D"ltr">Hi,<div><br></div><div>I&#39;m proposing the addition of a=
 new optional p2p message to help reduce unnecessary network traffic.=C2=A0=
 The draft BIP is available here and pasted below:</div><div><a href=3D"htt=
ps://gist.github.com/morcos/9aab223c443c9258c979">https://gist.github.com/m=
orcos/9aab223c443c9258c979</a><br></div><div><br></div><div>The goal of thi=
s message is to take advantage of the fact that when a node has reached its=
 mempool limit, there is a minimum fee below which no transactions are acce=
pted to the mempool.=C2=A0 Informing peers of this minimum would save them =
inv&#39;ing your node for those transaction id&#39;s and save your node req=
uesting them if they are not in your recentRejects filter.</div><div><br></=
div><div>This message is optional and may be ignored as a protocol rule.=C2=
=A0 There is also an option to turn off sending the messages in the impleme=
ntation.</div><div><br></div><div>Thanks to Suhas Daftuar, Greg Maxwell, an=
d others for helping develop the idea.</div><div><br></div><div>-Alex</div>=
<div><br></div><div>Draft BIP text:</div><div><br></div><div><div>&lt;pre&g=
t;</div><div>=C2=A0 BIP: &lt;unassigned&gt;</div><div>=C2=A0 Title: feefilt=
er message</div><div>=C2=A0 Author: Alex Morcos &lt;<a href=3D"mailto:morco=
s@chaincode.com">morcos@chaincode.com</a>&gt;</div><div>=C2=A0 Status: Draf=
t</div><div>=C2=A0 Type: Standards Track</div><div>=C2=A0 Created: 2016-02-=
13</div><div>&lt;/pre&gt;</div><div><br></div><div>=3D=3DAbstract=3D=3D</di=
v><div><br></div><div>Add a new message, &quot;feefilter&quot;, which serve=
s to instruct peers not to send &quot;inv&quot;&#39;s to the node for trans=
actions with fees below the specified fee rate.</div><div><br></div><div>=
=3D=3DMotivation=3D=3D</div><div><br></div><div>The concept of a limited me=
mpool was introduced in Bitcoin Core 0.12 to provide protection against att=
acks or spam transactions of low fees that are not being mined. A reject fi=
lter was also introduced to help prevent repeated requests for the same tra=
nsaction that might have been recently rejected for insufficient fee. These=
 methods help keep resource utilization on a node from getting out of contr=
ol.</div><div><br></div><div>However, there are limitations to the effectiv=
eness of these approaches.=C2=A0 The reject filter is reset after every blo=
ck which means transactions that are inv&#39;ed over a longer time period w=
ill be rerequested and there is no method to prevent requesting the transac=
tion the first time.=C2=A0 Furthermore, inv data is sent at least once eith=
er to or from each peer for every transaction accepted to the mempool and t=
here is no mechanism by which to know that an inv sent to a given peer woul=
d not result in a getdata request because it represents a transaction with =
too little fee.</div><div><br></div><div>After receiving a feefilter messag=
e, a node can know before sending an inv that a given transaction&#39;s fee=
 rate is below the minimum currently required by a given peer, and therefor=
e the node can skip relaying an inv for that transaction to that peer.</div=
><div><br></div><div>=3D=3DSpecification=3D=3D</div><div><br></div><div># T=
he feefilter message is defined as a message containing an int64_t where pc=
hCommand =3D=3D &quot;feefilter&quot;</div><div># Upon receipt of a &quot;f=
eefilter&quot; message, the node will be permitted, but not required, to fi=
lter transaction invs for transactions that fall below the feerate provided=
 in the feefilter message interpreted as satoshis per kilobyte.</div><div>#=
 The fee filter is additive with a bloom filter for transactions so if an S=
PV client were to load a bloom filter and send a feefilter message, transac=
tions would only be relayed if they passed both filters.</div><div># Inv&#3=
9;s generated from a mempool message are also subject to a fee filter if it=
 exists.</div><div># Feature discovery is enabled by checking protocol vers=
ion &gt;=3D 70013</div><div><br></div><div>=3D=3DConsiderations=3D=3D</div>=
<div>The propagation efficiency of transactions across the network should n=
ot be adversely affected by this change. In general, transactions which are=
 not accepted to your mempool are not relayed and the funcionality implemen=
ted with this message is meant only to filter those transactions.=C2=A0 The=
re could be a small number of edge cases where a node&#39;s mempool min fee=
 is actually less than the filter value a peer is aware of and transactions=
 with fee rates between these values will now be newly inhibited.</div><div=
><br></div><div>Feefilter messages are not sent to whitelisted peers if the=
 &quot;-whitelistforcerelay&quot; option is set. In that case, transactions=
 are intended to be relayed even if they are not accepted to the mempool.</=
div><div><br></div><div>There are privacy concerns with deanonymizing a nod=
e by the fact that it is broadcasting identifying information about its mem=
pool min fee. To help ameliorate this concern, the implementaion quantizes =
the filter value broadcast with a small amount of randomness, in addition, =
the messages are broadcast to different peers at individually randomly dist=
ributed times.</div><div><br></div><div>If a node is using prioritisetransa=
ction to accept transactions whose actual fee rates might fall below the no=
de&#39;s mempool min fee, it may want to consider setting &quot;-nofeefilte=
r&quot; to make sure it is exposed to all possible txid&#39;s.</div><div><b=
r></div><div>=3D=3DBackward compatibility=3D=3D</div><div><br></div><div>Ol=
der clients remain fully compatible and interoperable after this change.=C2=
=A0 The sending of feefilter messages can be disabled by unsetting the &quo=
t;-feefilter&quot; option.</div><div><br></div><div>=3D=3DImplementation=3D=
=3D</div><div><br></div><div><a href=3D"https://github.com/bitcoin/bitcoin/=
pull/7542">https://github.com/bitcoin/bitcoin/pull/7542</a></div></div><div=
><br></div></div>

--001a113eddf22ad1b7052be8dd2c--