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 557ACEE2 for ; Mon, 2 Apr 2018 22:18:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pl0-f50.google.com (mail-pl0-f50.google.com [209.85.160.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4AC085F5 for ; Mon, 2 Apr 2018 22:18:22 +0000 (UTC) Received: by mail-pl0-f50.google.com with SMTP id v18-v6so4054969ply.12 for ; Mon, 02 Apr 2018 15:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version; bh=z2sxXtT/vwLT7mLIuX66a6Ms3h6IBu7c5vB8ADtm+hw=; b=M1RXXgCDNvAVqSjtYteOvBGQaKqF+hOBEznloub35mPvZjcSCx1/bmEQFW4rw38UCA 4h1S608u0jC5Y0NjNCQmhq97D5S2DhIj8in7QgN16qQNnWQOhHR5p7m0UFwSo/p58hwN nIZpcq8KX1QTUuYqKGX9d5hNOE1bJ5mkYSwnqCATEMrVNMf08gMg+V6VcdNheY87tnUy DM7kJbwVN+3GZeu7RZjcYRxYstUgb1TQEvniPdZWcvRHCr2DIcf2J+uRUmMVMuW5kd7J AtS6I+Y9EiW8b0sy3ViTZCyyU8A8Ms4r7bp1wwVRkpRUbg+fAChVvOY0v77VpymZbyha rk0Q== 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:subject:mime-version; bh=z2sxXtT/vwLT7mLIuX66a6Ms3h6IBu7c5vB8ADtm+hw=; b=BYRHFM6IAlBrwZK1FRa6iZozZR0H/2EbmSM+hVA7Dq9o75idlHQW4zx8bOWir6ONwU zF2xFpiyXciD7I1rbNxyIrWssW50Pyequ2XAZRshTOIjSv8dq1w++EjrYrc2uYcEwqko u1pcJffzd6N1kPfsXi3vD68Sr8flD0sGJE2uUyIZiYrToxlRSX0huuwKqBDDtHTcxIgh 6b+o3GcdAGFJGU69gLW9FUx+ueXKNmM6UDHQDi3N/CCq0QZoPq5WZ1PMhFm5i/bQyVPr yD7NeIKGaiyX50sMDqvfb46sLI9DvuY0Cs3pzIREjSkgRilIuWmQmlpk6N66wjjRdYY5 Pczw== X-Gm-Message-State: AElRT7HJKujtp6iPpLCGhGST4uK+TUEm1Y9je3du2u2fYt7sRDkLBa0h qxCPTGQwQ5mOoWYqIwfpL8P1X0Br X-Google-Smtp-Source: AIpwx48CZO+i2wwtP39XrTQHpI6gIQ2kYsOjHMjLKzg5ml1YyJ/b3n9RdYk2NQiFfPZE1Kje5KbMlQ== X-Received: by 2002:a17:902:988f:: with SMTP id s15-v6mr11251727plp.57.1522707501434; Mon, 02 Apr 2018 15:18:21 -0700 (PDT) Received: from [206.87.122.5] (dhcp-206-87-122-5.ubcsecure.wireless.ubc.ca. [206.87.122.5]) by smtp.gmail.com with ESMTPSA id g11sm2076901pfi.15.2018.04.02.15.18.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Apr 2018 15:18:20 -0700 (PDT) Date: Mon, 2 Apr 2018 15:18:07 -0700 From: Gleb Naumenko To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <9ab6e32e-db51-4ce4-8f3c-3a77f7b1f9bd@Spark> X-Readdle-Message-ID: 9ab6e32e-db51-4ce4-8f3c-3a77f7b1f9bd@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5ac2ac88_628c895d_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: Tue, 03 Apr 2018 00:05:40 +0000 Subject: [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: Mon, 02 Apr 2018 22:18:23 -0000 --5ac2ac88_628c895d_7d7e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, I have a couple of ideas regarding transaction relay protocol and wanted = 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 because = each node creates 8 connections. =C2=A0I also realized that sending INV m= essages is a significant part of the overall bandwidth consumed by a publ= ic-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 *all* of = the transactions. A new protocol should also keep the same zero-trust, ro= bustness, decentralization guarantees and latency. Idea: while joining the network, a new node agrees on some filter with ea= ch of 8 nodes it connects to. So that NewNode <-> Node=5FA will be used t= o relay only a subset of transactions, NewNode <-> Node=5FB for another s= ubset. This will significantly decrease the redundancy. To keep the guarantees, I would keep some redundancy (for example, each t= ransaction 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* nodes. = Getting a bloom filter of a subset of the mempool transactions from Node=5F= B 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 kn= ow. If there were any similar ideas =E2=80=94 please let me know. Best, Gleb --5ac2ac88_628c895d_7d7e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
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

--5ac2ac88_628c895d_7d7e--