From: Andrew Miller <soc1024@illinois•edu>
To: <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation
Date: Mon, 12 Jun 2017 09:46:23 -0500 [thread overview]
Message-ID: <CAF7tpExcfbB5mvL0nNnSTJxU5eJOeFs2z3Gor9ZXWYxh1szSTg@mail.gmail.com> (raw)
Dear bitcoin-dev,
We've put together a preliminary implementation and BIP for
Dandelion, and would love to get your feedback on it. Dandelion is a
privacy-enhancing modification to Bitcoin's transaction propagation
mechanism. Its goal is to obscure the original source IP of each
transaction.
https://github.com/gfanti/bips/blob/master/bip-dandelion.mediawiki
https://github.com/gfanti/bitcoin/tree/dandelion
The main idea is that transaction propagation proceeds in two
phases: first the “stem” phase, and then “fluff” phase. During the
stem phase, each node relays the transaction to a *single* peer. After
a random number of hops along the stem, the transaction enters the
fluff phase, which behaves just like ordinary transaction
flooding/diffusion. Even when an attacker can identify the location of
the fluff phase, it is much more difficult to identify the source of
the stem. Our approach and some preliminary evaluation are explained
in more detail in the BIP. The research paper originally introducing
this idea was recently presented at SIGMETRICS'17.
https://arxiv.org/pdf/1701.04439.pdf
Compared to the original paper, our current proposal includes
several new design ideas, especially:
- Stronger attacker model: we defend against an attacker that
actively tries to learn which nodes were involved in the stem phase.
Our approach is called "Mempool Embargo", meaning a node that receives
a "stem phase" transaction behaves as though it never heard of it,
until it receives it again from someone else (or until a random timer
elapses).
- Robustness. We think the privacy benefit shouldn't come at the
expense of propagation quality. Our implementation is designed so that
if some node drops the transaction (or when Dandelion is adopted only
partially), then the fallback behavior is ordinary Bitcoin
propagation.
We'd especially like feedback on the implementation details related
to the two points above. The mempool embargo mechanism is tricky,
since it hard to rule out indirect behavior that reveals if a
transaction is in mempool. In the BIP we explain one counterexample,
but at least it requires the attacker to get its connections banned.
Are there other ways we haven't thought of? We think the alternative
approach (bypassing mempool entirely) seems even harder to get right,
and foregoes existing DoS protection.
We're currently running in-situ benchmark experiments with this code
on testnet and will report on those in this thread if there's
interest.
Some prior discussion can be found here:
- https://botbot.me/freenode/bitcoin-wizards/2017-03-29/?msg=83181866&page=2
- https://botbot.me/freenode/bitcoin-wizards/2017-01-18/?msg=79578754&page=2
- https://github.com/sbaks0820/bitcoin-dandelion/issues/1 (notes
from gmaxwell that we've mostly incorporated in the current proposal)
Thanks!
-----
Giulia Fanti <gfanti@andrew•cmu.edu>
Andrew Miller <soc1024@illinois•edu>
Surya Bakshi <sbakshi3@illinois•edu>
Shaileshh Bojja Venkatakrishnan <bjjvnkt2@illinois•edu>
Pramod Viswanath <pramodv@illinois•edu>
next reply other threads:[~2017-06-12 14:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-12 14:46 Andrew Miller [this message]
2017-06-13 1:00 ` Gregory Maxwell
2017-09-21 2:10 Giulia Fanti
2018-05-10 12:59 Bradley Denby
2018-06-04 20:29 ` Bradley Denby
2018-07-05 14:50 ` Neudecker, Till (TM)
2018-06-06 4:01 ` Pieter Wuille
2018-06-11 14:31 ` Bradley Denby
2018-06-12 1:05 ` Pieter Wuille
2018-06-26 0:12 ` Bradley Denby
2018-06-26 5:20 ` Gregory Maxwell
[not found] <mailman.3774.1530901879.19027.bitcoin-dev@lists.linuxfoundation.org>
2018-07-08 12:50 ` Giulia Fanti
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=CAF7tpExcfbB5mvL0nNnSTJxU5eJOeFs2z3Gor9ZXWYxh1szSTg@mail.gmail.com \
--to=soc1024@illinois$(echo .)edu \
--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