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 A6B3C989 for ; Wed, 4 Apr 2018 02:10:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pl0-f51.google.com (mail-pl0-f51.google.com [209.85.160.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AA73514F for ; Wed, 4 Apr 2018 02:10:39 +0000 (UTC) Received: by mail-pl0-f51.google.com with SMTP id s24-v6so11842719plq.6 for ; Tue, 03 Apr 2018 19:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=KUEn/EQI03EbCzZokRYkYz4Z/6cIjW1iKy27S/qtIcI=; b=FkoyXi77+UEQiOoR0k3QGyXbkLMmqUXimwmwNrqDjedRvyBfPGMSDz0J4tI0nIU26x 9tjYIZSqSk4i9d/T0X/g1MGh/Opuh7/BS38ml0oGo8adGVEsOi6LNHDS0H26PbWhTUZE 731qmTDk3o6Vq3Sz2+/EhInSN85sz8iTL4Yw5ZMcAdH5XiL88GCpbsO3wc9j0xaovXlm keRFPk/wWR9fV6amSSy4XXvJOqVSCeY7sL9ZPMQmACFoMtrztmMmltTfb83ByMifN1mQ Q9UYhxbWtRo2Or60T8cVhKUxl+CCoR1OFYWWerzHeDFQSh4Xh4mlMUJfi4eo+9965ZsV l40A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=KUEn/EQI03EbCzZokRYkYz4Z/6cIjW1iKy27S/qtIcI=; b=TrJVz+pU5X6Ilgy70Ngx6jbFeE74zf8/htcU9sB3R/h0mttAXBggcyNRnQLaG68pTq pe/Jt2N8FBNnGlABu7Yj+P6OKbfNRE8BMHCQHJmlcPWIZFG3KfTVsISmR8w62xc6VBah hdoNW1CUgzuMugEKjdAePkDj7S0l8RNh7e39sWcYXhaEgxbUe3j33kwoB7AiyDvtdCba xujn+T1KB/CwcaHIZqGox9+9L4eiIJSFZYy3SrYry/kjkKMwflHAsnN0olpKg7Izf55c ITOICXnWwsF+Wy6oObGT+P6VUKXBdbyFePk4pppXUVCOMPa+VSewgyTkhG5lvsr4kGVo muoQ== X-Gm-Message-State: AElRT7G+71+xQgbUZXvZIc4kmIR8PostQeYAxZatz7PexkzFFnWhQfMG tt7bPt+XgmxMjAd+tmklFXW6gGe/ X-Google-Smtp-Source: AIpwx4/WP6AT7+8miBq81P/Nyr4ePoWuQkN+RdUqoZq6+QdAlt9FtLOAUiURh8b+3vgYHvq3nLI0IQ== X-Received: by 2002:a17:902:1665:: with SMTP id g92-v6mr16155596plg.195.1522807838767; Tue, 03 Apr 2018 19:10:38 -0700 (PDT) Received: from [10.128.1.247] ([209.58.135.74]) by smtp.gmail.com with ESMTPSA id d15sm8465022pfj.121.2018.04.03.19.10.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 19:10:37 -0700 (PDT) Date: Tue, 3 Apr 2018 19:10:56 -0700 From: Gleb Naumenko To: Bitcoin Protocol Discussion , Jim Posen Message-ID: In-Reply-To: References: <9ab6e32e-db51-4ce4-8f3c-3a77f7b1f9bd@Spark> X-Readdle-Message-ID: a1de9445-731f-4f94-b5b9-6a94588ba12e@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5ac43479_614fd4a1_7d7e" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 04 Apr 2018 02:53:49 +0000 Subject: Re: [bitcoin-dev] Low-bandwidth transaction relay X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 02:10:40 -0000 --5ac43479_614fd4a1_7d7e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Yeah, sure. > How much bandwidth is consumed by redundant tx INVs currently=3F Currently, for an average public-IP node all INVs consume 0.05 Mbps or 54= 0 megabytes per day. This number is based on current ratio public-IP node= s:private-IP nodes and transaction rate. This number is a sum of both inc= oming and outgoing aspects. Thus redundant INV=E2=80=99s on average consu= me 0.044 Mbps or 475 megabytes per day. > What is this as a % of overall bandwidth usage=3F This is hard to estimate because overall bandwidth includes helping other= nodes to bootstrap from scratch. If we don=E2=80=99t consider this aspec= t, my very rough estimate, and a short experiment shows that INV=E2=80=99= s are around 50% of overall bandwidth (it also depends on different facto= rs like your hardware comparing to other public-IP nodes). I=E2=80=99m go= ing to double-check this number soon. > How would filtering txs through N=3D2 links affect network propagation=3F= Yes, network propagation for a new protocol definitely worth measuring. I= =E2=80=99m going to look at it in the near future. > Do you propose setting filters on inbound peers as well=3F This is a good question. I think some filter may be applied to inbound connections. Theoretically,= a symmetrical filter does not make much sense =E2=80=94 it might be even= tually the same filter for all of the connections except first 8 outgoing= ones, so it=E2=80=99s better to use independent filters. However, I=E2=80=99m not entirely sure it is needed. =46ilters on inbound= peers will reduce a download aspect. It might be much less critical than= upload (if we assume that private-IP nodes hear about transactions later= because those have much fewer connections). I think this question needs = another experiment. On Apr 3, 2018, 10:45 AM -0700, Jim Posen , wrote:= > Hey. This idea sounds quite interesting. It'd be helpful to see some mo= re numbers to evaluate it. > > - How much bandwidth is consumed by redundant tx INVs currently=3F What= is this as a % of overall bandwidth usage=3F > - How would filtering txs through N=3D2 links affect network propagatio= n=3F This probably requires simulation to determine. > - Do you propose setting filters on inbound peers as well=3F > > > On Mon, Apr 2, 2018 at 3:18 PM, Gleb Naumenko via bitcoin-dev wrote: > > > Hi all, > > > I have a couple of ideas regarding transaction relay protocol and w= anted to share it with and probably get some feedback. > > > > > > I did some emulation and simulation and found out that around 90% o= f INV messages sent by public-IP nodes are idle (duplicate), obviously be= cause each node creates 8 connections.=C2=A0 I also realized that sending= INV messages is a significant part of the overall bandwidth consumed by = a public-IP node. At a larger scale, this will result in people not able = to run a public-IP node. > > > > > > My idea is in some sense similar to BIP37 but applied to public-IP = nodes. Here I want to emphasize that all the nodes will still receive *al= l* of the transactions. A new protocol should also keep the same zero-tru= st, robustness, decentralization guarantees and latency. > > > > > > Idea: while joining the network, a new node agrees on some filter w= ith each of 8 nodes it connects to. So that NewNode <-> Node=5FA will be = used to relay only a subset of transactions, NewNode <-> Node=5FB for ano= ther subset. This will significantly decrease the redundancy. > > > > > > To keep the guarantees, I would keep some redundancy (for example, = each transaction INV is sent over 2 links). > > > > > > To make it robust to attacks, I have 2 extensions in my mind: > > > 1. Set reconciliation (for a subset of transactions) with *other* n= odes. Getting a bloom filter of a subset of the mempool transactions from= Node=5FB may help to figure out whether Node=5FA is malicious, very slow= , etc. > > > 2. Rotating the filters every N minutes (N < 10) > > > > > > I can see some issues with latency here, but I believe this problem= has a solution. > > > > > > =46eedback is appreciated=21 > > > > > > If you want to look at a draft of the proposal =E2=80=94 please let= me know. > > > If there were any similar ideas =E2=80=94 please let me know. > > > > > > Best, > > > Gleb > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > bitcoin-dev mailing list > > > bitcoin-dev=40lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > --5ac43479_614fd4a1_7d7e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Yeah, sure.

> How much bandwidth is consumed by redundant tx INVs currently=3F=
Currently, for an average public-IP node all INVs consume 0.05 Mbps = or 540 megabytes per day. This number is based on current ratio public-IP= nodes:private-IP nodes and transaction rate. This number is a sum of bot= h incoming and outgoing aspects. Thus redundant INV=E2=80=99s on average = consume 0.044 Mbps or 475 megabytes per day.

> What is this as a % of overall bandwidth usage=3F
This is hard to estimate because overall bandwidth includes helping = other nodes to bootstrap from scratch. If we don=E2=80=99t consider this = aspect, my very rough estimate, and a short experiment shows that INV=E2=80= =99s are around 50% of overall bandwidth (it also depends on different fa= ctors like your hardware comparing to other public-IP nodes). I=E2=80=99m= going to double-check this number soon.

> How would filtering txs through N=3D2 links affect network prop= agation=3F
Yes, network propagation for a new protocol definitely worth measuri= ng. I=E2=80=99m going to look at it in the near future.

> Do you propose setting filters on inbound peers as well=3F
This is a good question.&=23160;
I think some filter may be applied to inbound connections. Theoretic= ally, a symmetrical filter does not make much sense =E2=80=94 it might be= eventually the same filter for all of the connections except first 8 out= going ones, so it=E2=80=99s better to use independent filters.
However, I=E2=80=99m not entirely sure it is needed. =46ilters on in= bound peers will reduce a download aspect. It might be much less critical= than upload (if we assume that private-IP nodes hear about transactions = later because those have much fewer connections). I think this question n= eeds another experiment.

On Apr 3, 2018, 10:45 AM -0700, Jim Posen <jim.posen=40gmail.com>, = wrote:
Hey. This idea sounds quite interesting. It'd be hel= pful to see some more numbers to evaluate it.

- How much bandwidth is consumed by redundant tx INVs currently=3F W= hat is this as a % of overall bandwidth usage=3F
- How would filtering txs through N=3D2 links affect network propaga= tion=3F This probably requires simulation to determine.
- Do you propose setting filters on inbound peers as well=3F

On Mon, Apr 2, 2018 at 3:18 PM, Gleb Nau= menko via bitcoin-dev <bitcoin-dev= =40lists.linuxfoundation.org> wrote:
Hi all,
I have a couple of ideas regarding transaction relay protocol and wa= nted to share it with and probably get some feedback.

I did some emulation and simulation and found out that around 90% of= INV messages sent by public-IP nodes are idle (duplicate), obviously bec= ause each node creates 8 connections.&=23160; I also realized that sendin= g INV messages is a significant part of the overall bandwidth consumed by= a public-IP node. At a larger scale, this will result in people not able= to run a public-IP node.

My idea is in some sense similar to BIP37 but applied to public-IP n= odes. Here I want to emphasize that all the nodes will still receive *all= * of the transactions. A new protocol should also keep the same zero-trus= t, robustness, decentralization guarantees and latency.

Idea: while joining the network, a new node agrees on some filter wi= th each of 8 nodes it connects to. So that NewNode <-> Node=5FA wil= l be used to relay only a subset of transactions, NewNode <-> Node=5F= B for another subset. This will significantly decrease the redundancy.

To keep the guarantees, I would keep some redundancy (for example, e= ach transaction INV is sent over 2 links).

To make it robust to attacks, I have 2 extensions in my mind:&=23160= ;
1. Set reconciliation (for a subset of transactions) with *other* no= des. Getting a bloom filter of a subset of the mempool transactions from = Node=5FB may help to figure out whether Node=5FA is malicious, very slow,= etc.
2. Rotating the filters every N minutes (N < 10)

I can see some issues with latency here, but I believe this problem = has a solution.

=46eedback is appreciated=21

If you want to look at a draft of the proposal =E2=80=94 please let = me know.
If there were any similar ideas =E2=80=94 please let me know.

Best,
Gleb


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
bitcoin-dev mailing list
bitcoin-de= v=40lists.linuxfoundation.org
https://lists.linuxf= oundation.org/mailman/listinfo/bitcoin-dev


--5ac43479_614fd4a1_7d7e--