1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
Return-Path: <soc1024@illinois.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E662EB7F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Jun 2017 14:55:08 +0000 (UTC)
X-Greylist: delayed 00:08:42 by SQLgrey-1.7.6
Received: from relays-agent06.techservices.illinois.edu
(relays-agent06.techservices.illinois.edu [204.93.2.7])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 339CC23C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Jun 2017 14:55:08 +0000 (UTC)
Received: from uex132.ad.uillinois.edu (uex132.cites.illinois.edu
[192.17.212.208])
by relays-agent06.techservices.illinois.edu (8.16.0.17/8.16.0.17) with
ESMTPS id v5CEkPgX010658
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Jun 2017 09:46:25 -0500
Received: from mail-ot0-f173.google.com (64.22.180.153) by
uex132.ad.uillinois.edu (192.17.212.208) with Microsoft SMTP Server
(TLS) id 15.0.1236.3; Mon, 12 Jun 2017 09:46:24 -0500
Received: by mail-ot0-f173.google.com with SMTP id i31so67450904ota.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Jun 2017 07:46:24 -0700 (PDT)
X-Gm-Message-State: AKS2vOzK12xWk2iK4nWPAbFXW49bajMuoTKZ5zEeUlmiXiaqnxe3XgAv
Ogfxn46oixa8Y4TpwtS6XKtnww9Cvw==
X-Received: by 10.157.37.181 with SMTP id q50mr31589376ota.44.1497278784101;
Mon, 12 Jun 2017 07:46:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.235.35 with HTTP; Mon, 12 Jun 2017 07:46:23 -0700 (PDT)
From: Andrew Miller <soc1024@illinois.edu>
Date: Mon, 12 Jun 2017 09:46:23 -0500
X-Gmail-Original-Message-ID: <CAF7tpExcfbB5mvL0nNnSTJxU5eJOeFs2z3Gor9ZXWYxh1szSTg@mail.gmail.com>
Message-ID: <CAF7tpExcfbB5mvL0nNnSTJxU5eJOeFs2z3Gor9ZXWYxh1szSTg@mail.gmail.com>
To: <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [64.22.180.153]
X-ClientProxiedBy: cex137.ad.uillinois.edu (64.22.177.33) To
uex132.ad.uillinois.edu (192.17.212.208)
X-Spam-Score: 0
X-Spam-Details: rule=cautious_plus_nq_notspam policy=cautious_plus_nq score=0
spamscore=0
suspectscore=10 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0
classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000
definitions=main-1706120257
X-Spam-OrigSender: soc1024@illinois.edu
X-Spam-Bar:
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving
Transaction Propagation
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, 12 Jun 2017 14:55:09 -0000
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 =E2=80=9Cstem=E2=80=9D phase, and then =E2=80=9Cfluff=E2=
=80=9D 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=3D83181866&p=
age=3D2
- https://botbot.me/freenode/bitcoin-wizards/2017-01-18/?msg=3D79578754&p=
age=3D2
- 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>
|
