From: Gleb Naumenko <naumenko.gs@gmail•com>
To: Bitcoin-Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] New BIP for p2p messages/state enabling reconciliation-based protocols (Erlay)
Date: Wed, 25 Sep 2019 14:28:00 +0300 [thread overview]
Message-ID: <8914e269-e922-43f4-8846-9fb21a8044f3@Spark> (raw)
In-Reply-To: <c06eeb3e-4611-4196-8d2f-f3c3470aeea3@Spark>
[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]
We are opening for review a draft of the new BIP, which describes low-level specifications for the reconciliation-based transaction announcement protocol.
https://github.com/naumenkogs/bips/blob/bip-reconcil/bip-reconcil.mediawiki
Agreeing on this spec would enable integration of more bandwidth-efficient relay protocols, like Erlay (https://arxiv.org/abs/1905.10518).
The draft has all the background necessary to understand the work, so please read and review.
It introduces salted short transaction IDs (required to do reconciliation efficiently) and demonstrates how to compute sketches based on these IDs (including simple python scripts).
It also introduces wtxid-based truncated transaction IDs (to trivially save significant fraction of the bandwidth).
Finally, it specifies all the messages to be used by an efficient reconciliation-based protocol, and new state variables required for the protocol.
Please note that, comparing to the Erlay paper, we decided to add extra round, where 2 parties explicitly map 32-bit short IDs to 128-bit truncated IDs, because otherwise peers which take >1s to reconcile would cause transmitting duplicate transactions (extra bandwidth), and we cannot assume <1s latency in Bitcoin, especially over Tor.
According to my estimates, the bandwidth overhead due to the measure from the BIP (extra communication round) is only extra 10% comparing to the original Erlay estimates.
It is possible that we missed some of the state variables required to handle corner cases of the protocol, because the spec is based on my prototype code, and it might evolve when we will be building an actual production-ready implementation.
Overall, I believe that this spec is ready for review.
Even though this work does not require a fork, the change is quite significant, and peer-review is critical for the system, so please take a look. Feel free to reach out for questions and comments here or directly over email.
– gleb
[-- Attachment #2: Type: text/html, Size: 2462 bytes --]
next parent reply other threads:[~2019-09-25 11:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <c06eeb3e-4611-4196-8d2f-f3c3470aeea3@Spark>
2019-09-25 11:28 ` Gleb Naumenko [this message]
2019-09-27 2:08 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8914e269-e922-43f4-8846-9fb21a8044f3@Spark \
--to=naumenko.gs@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox