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 E662EB7F for ; 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 ; 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 ; 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 ; 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 Date: Mon, 12 Jun 2017 09:46:23 -0500 X-Gmail-Original-Message-ID: Message-ID: To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Andrew Miller Surya Bakshi Shaileshh Bojja Venkatakrishnan Pramod Viswanath