Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CB8B5BAF for ; Mon, 19 Jun 2017 20:49:30 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from blaine.gmane.org (unknown [195.159.176.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 169AD1A6 for ; Mon, 19 Jun 2017 20:49:28 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dN3br-0005Of-Ft for bitcoin-dev@lists.linuxfoundation.org; Mon, 19 Jun 2017 22:49:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-dev@lists.linuxfoundation.org From: Andreas Schildbach Date: Mon, 19 Jun 2017 22:49:17 +0200 Message-ID: References: <537fb7106e0387c77537f0b1279cbeca@cock.lu> <55482016.LADLl5KXAH@strawberry> <4052F361-966C-4817-9779-146D4B43D1FE@jonasschnelli.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 In-Reply-To: Content-Language: en-US X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, FORGED_MUA_MOZILLA,RDNS_NONE autolearn=no version=3.3.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients 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, 19 Jun 2017 20:49:31 -0000 Most SPV wallets make it quite clear that unconfirmed transactions are just that. On 06/19/2017 06:36 PM, adiabat via bitcoin-dev wrote: > This has been brought up several times in the past, and I agree with > Jonas' comments about users being unaware of the privacy losses due to > BIP37. One thing also mentioned before but not int he current thread > is that the entire concept of SPV is not applicable to unconfirmed > transactions. SPV uses the fact that miners have committed to a > transaction with work to give the user an assurance that the > transaction is valid; if the transaction were invalid, it would be > costly for the miner to include it in a block with valid work. > > Transactions in the mempool have no such assurance, and are costlessly > forgeable by anyone, including your ISP. I wasn't involved in any > debate over BIP37 when it was being written up, so I don't know how > mempool filtering got in, but it never made any sense to me. The fact > that lots of lite clients are using this is a problem as it gives > false assurance to users that there is a valid but yet-to-be-confirmed > transaction sending them money. > > -Tadge >