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 9E17E95E for ; Wed, 4 Jan 2017 11:00:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0165690 for ; Wed, 4 Jan 2017 11:00:57 +0000 (UTC) Received: from mail-qk0-f169.google.com ([209.85.220.169]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0M9qSE-1cDm0f0bdY-00B3x4 for ; Wed, 04 Jan 2017 12:00:57 +0100 Received: by mail-qk0-f169.google.com with SMTP id u25so391734643qki.2 for ; Wed, 04 Jan 2017 03:00:56 -0800 (PST) X-Gm-Message-State: AIkVDXLMxS59FUsmI9nF09+n61vUfR2MV/lxt2yf0nEW+rtS0LRX0ROZqn6CI3eNvDn61jO07TmnhIm/byAWkA== X-Received: by 10.55.112.65 with SMTP id l62mr74444415qkc.76.1483527655998; Wed, 04 Jan 2017 03:00:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.144.130 with HTTP; Wed, 4 Jan 2017 03:00:55 -0800 (PST) In-Reply-To: References: <71d822e413ac457a530e1c367811cc24@cock.lu> <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch> <74aeb4760316b59a3db56c0d16d11f28@cock.lu> From: Adam Back Date: Wed, 4 Jan 2017 11:00:55 +0000 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= , Bitcoin Protocol Discussion Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:Go6s/A+fyynxXxvUimpinjvixLSrPWC8rLB0k/TvkoxfIrWZFx0 Oid+4BLPa5d/Hn/Dsi1/DUGY/3pnbJRTmTIrgv9iHwPOhLdi/5L4ou/iz3wRFt4e0PaD7Ie RT8kMV4xlDjgMXD8tzMOjCCAr8IHUADDq/BoJoBSMgKmofkZm+ZmqXM+EJMbnecRVgqyzhw dxk3CiHnh76+E05d3Yk7w== X-UI-Out-Filterresults: notjunk:1;V01:K0:gYZSY6X0V8Y=:CbnUeHWjF/NYqPmTMnoTqx 409c8JaGr8h7DxDcqaQsuMu1pzrv43HTBjHGn3lPKeeSwTysM7l5nO/aP7RmXO+LwhLMGuCD9 dxj7NO9rYsZeh0DvTfkSjaJqQjHkahzGmJ41Ckr2ZuQSZQhK+HUyW4goYZ4HbpSEvOwKib5BY enL3UMdsPbRtvouzLto0zCAZHYTG5Gi7QgNZZvUbCoOMJ0PJuJT389CFE9ZVvwF5y7mvfTYEt aXz5Pbe9qIkyObjJbMblQSVU3odHsAUQA7xNwQPkemdc7828H2BdxaD/zQX/09d6zda/qG9DC QVNfMXDJZCdKPo8WZE9c4YpLIPlfGARiGLY0wilaJtArWUR5mCaviJU7Fadyw7n/9CCvtEY2s mTi6uehPv0LFgRhJz3/SWsf08XY+1a6vfBkm/ija5Y8cl8KCT5zCiSGG+A/3eEOA9exr8n5dU c6ML+WcsnxHg7WPd1RwTeIsa97dHTbgfcWbsAdQS/r+o6qC3OsmqJz2t6kPzc+dxKitX2D0S3 IdUUjhBeK6jZNaLUOFZhXPRUr4ESD+90uTjQgzLystTfsbG0LN6Oqoo6XxfgVQLmj6uWmMa3k ku8bGzrPmOixPI1bBipL6Lm1Vgg+YVXPSCB2uK6SeUHUur7eRNdV4GIivgJVlUEjdCtXP4h97 FVjW9c2QDbmTIkJVgPt8qlhYEZVCpp1SKmaMsHhNh5gh/hKAWTwAxfsTK/SORLQ4y4nmRq0DC zabuukLSsHrznY33 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security 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: Wed, 04 Jan 2017 11:00:58 -0000 I think this discussion started from the block bloom filter where there is a bloom filter commitment in the block which can be downloaded and is much smaller than the block. An SPV node based on that model would download headers and bloom filters, verify the bloom filter is committed to, and test locally if any addresses managed by the wallet are in the filter (or false positives for being in it), and then download blocks with hits. Apparently there are maybe 50% more compact alternatives to bloom filters but people have been using bloom filter as a short-hand for that. The block bloom filter does seem to have higher overhead than the query model, but it offers much better privacy. I think there was previous discussion about maybe doing something with portions of blocks so you can know which half or quarter of the block etc. Adam On 4 January 2017 at 10:13, Jorge Tim=C3=B3n via bitcoin-dev wrote: > There were talks about implementing spv mode for bitcoin core without usi= ng > bloom filters. Less efficient because it downloads full blocks, but bette= r > for privacy. Perhaps other spv implementations should consider doing the > same instead of committing the filters in the block? > > Now I feel I was missing something. I guess you can download the whole bl= ock > you're interested in instead of only your txs and that gives you privacy. > But how do you get to know which blocks are you interested in? > > If the questions are too basic or offtopic for the thread, I'm happy gett= ing > answers privately (but then maybe I get them more than once). > > > On 4 Jan 2017 09:57, "Aaron Voisine via bitcoin-dev" > wrote: > > It's easy enough to mark a transaction as "pending". People with bank > accounts are familiar with the concept. > > Although the risk of accepting gossip information from multiple random > peers, in the case where the sender does not control the receivers networ= k > is still minimal. Random node operators have no incentive to send fake > transactions, and would need to control all the nodes a client connects t= o, > and find a non-false-positive address belonging to the victims wallet. > > It's not impossible, but it's non trivial, would only temporarily show a > pending transaction, and provide no benefit to the node operator. There a= re > much juicier targets for an attacker with the ability to sybil attack the > entire bitcoin p2p network. > > Aaron > > On Tue, Jan 3, 2017 at 11:47 PM Jonas Schnelli wro= te: >> >> Hi >> >> >> >> > Unconfirmed transactions are incredibly important for real world use. >> >> > Merchants for instance are willing to accept credit card payments of >> >> > thousands of dollars and ship the goods despite the fact that the >> >> > transaction can be reversed up to 60 days later. There is a very large >> >> > cost to losing the ability to have instant transactions in many or >> >> > even most situations. This cost is typically well above the fraud risk= . >> >> > >> >> > It's important to recognize that bitcoin serves a wide variety of use >> >> > cases with different profiles for time sensitivity and fraud risk. >> >> > >> >> I agree that unconfirmed transactions are incredibly important, but not >> >> over SPV against random peers. >> >> >> >> If you offer users/merchants a feature (SPV 0-conf against random >> >> peers), that is fundamentally insecure, it will =E2=80=93 sooner or late= r =E2=80=93 lead >> >> to some large scale fiasco, hurting Bitcoins reputation and trust from >> >> merchants. >> >> >> >> Merchants using and trusting 0-conf SPV transactions (retrieved from >> >> random peers) is something we should **really eliminate** through >> >> education and by offering different solution. >> >> >> >> There are plenty, more sane options. If you can't run your own full-node >> >> as a merchant (trivial), maybe co-use a wallet-service with centralized >> >> verification (maybe use two of them), I guess Copay would be one of >> >> those wallets (as an example). Use them in watch-only mode. >> >> >> >> For end-users SPV software, I think it would be recommended to... >> >> ... disable unconfirmed transactions during SPV against random peers >> >> ... enable unconfirmed transactions when using SPV against a trusted >> >> peer with preshared keys after BIP150 >> >> ... if unconfirmed transactions are disabled, show how it can be enabled >> >> (how to run a full-node [in a box, etc.]) >> >> ... educate, inform users that a transaction with no confirmation can be >> >> "stopped" or "redirected" any time, also inform about the risks during >> >> low-conf phase (1-5). >> >> >> >> I though see the point that it's nice to make use of the "incoming >> >> funds..." feature in SPV wallets. But =E2=80=93 for the sake of stabilit= y and >> >> (risk-)scaling =E2=80=93 we may want to recommend to scarify this featur= e and =E2=80=93 >> >> in the same turn =E2=80=93 to use privacy-preserving BFD's. >> >> >> >> >> >> >> >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >