diff options
| author | Gleb Naumenko <naumenko.gs@gmail.com> | 2018-04-02 15:18:07 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-04-02 22:18:23 +0000 |
| commit | 44b30166e538ff0d5778145c94dbb9f4c704c490 (patch) | |
| tree | 6e95f444865bd1fa1ae2b1a3867fe5317e02c33c | |
| parent | a52e1853d482be841a685a9fdb85ca4072eb1697 (diff) | |
| download | pi-bitcoindev-44b30166e538ff0d5778145c94dbb9f4c704c490.tar.gz pi-bitcoindev-44b30166e538ff0d5778145c94dbb9f4c704c490.zip | |
[bitcoin-dev] Low-bandwidth transaction relay
| -rw-r--r-- | b0/ba66b63f8cbc62826f9b111e3289f4fbfe1a5c | 188 |
1 files changed, 188 insertions, 0 deletions
diff --git a/b0/ba66b63f8cbc62826f9b111e3289f4fbfe1a5c b/b0/ba66b63f8cbc62826f9b111e3289f4fbfe1a5c new file mode 100644 index 000000000..c1295477f --- /dev/null +++ b/b0/ba66b63f8cbc62826f9b111e3289f4fbfe1a5c @@ -0,0 +1,188 @@ +Return-Path: <naumenko.gs@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 557ACEE2 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 2 Apr 2018 22:18:22 +0000 (UTC) +Received: by mail-pl0-f50.google.com with SMTP id v18-v6so4054969ply.12 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org> + (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 <naumenko.gs@gmail.com> +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 <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: 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 + +<html xmlns=3D=22http://www.w3.org/1999/xhtml=22> +<head> +<title></title> +</head> +<body> +<div name=3D=22messageBodySection=22 style=3D=22font-size: 14px; font-fam= +ily: -apple-system, BlinkMacSystem=46ont, sans-serif;=22> +<div>Hi all,</div> +<div>I have a couple of ideas regarding transaction relay protocol and wa= +nted to share it with and probably get some feedback.</div> +<div><br /></div> +<div>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.</div> +<div><br /></div> +<div>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.</div> +<div><br /></div> +<div>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.</d= +iv> +<div><br /></div> +<div>To keep the guarantees, I would keep some redundancy (for example, e= +ach transaction INV is sent over 2 links).</div> +<div><br /></div> +<div>To make it robust to attacks, I have 2 extensions in my mind:&=23160= +;</div> +<div>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.</div> +<div>2. Rotating the filters every N minutes (N < 10)</div> +<div><br /></div> +<div>I can see some issues with latency here, but I believe this problem = +has a solution.</div> +<div><br /></div> +<div>=46eedback is appreciated=21</div> +<div><br /></div> +<div>If you want to look at a draft of the proposal =E2=80=94 please let = +me know.</div> +<div>If there were any similar ideas =E2=80=94 please let me know.</div> +<div><br /></div> +<div>Best,</div> +<div>Gleb</div> +</div> +<div name=3D=22messageReplySection=22 style=3D=22font-size: 14px; font-fa= +mily: -apple-system, BlinkMacSystem=46ont, sans-serif;=22><br /> +<div></div> +</div> +</body> +</html> + +--5ac2ac88_628c895d_7d7e-- + + |