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 F2DEF957 for ; Tue, 3 Jan 2017 23:06:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33197171 for ; Tue, 3 Jan 2017 23:06:27 +0000 (UTC) Received: by mail-io0-f175.google.com with SMTP id h133so205242727ioe.3 for ; Tue, 03 Jan 2017 15:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=awsomnet-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YSlA875jsHyKdX+3QkkfsaK+IJ3iJmoTMlqb3esLTR8=; b=v8A874wuDXbD0iPTXz9HGKtRGdOsM8yLKNqQ62msYfA07Uuh37/Qd07cYeXWulR2Kw 2Ai0/sg5hCEQOPhZJ3IkWDp82I0gwoqF9B33RiOPkPEWDLsWYK0VgIcaLdkwZx9rW9GF xzxLeFdLzvEUvq9QYYjYiASB1U1Y6OTg6tMsIlrSry3oquVJspTYHWKpj0hR89JCNhQU Di+ke0JUAJBHxX4j2STvl4Dfqn3JrBvAtvWZ5Wg4uHwhrumtpW0ISAIbx6lqugoPTErz 4XlMqno+Zcn1T8N+QzsMCy/mSzvgU8WbYSHuinlV8fc3pAni43qeOofHX3ykkeDYJ58n hqcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YSlA875jsHyKdX+3QkkfsaK+IJ3iJmoTMlqb3esLTR8=; b=EnRyFMCoR2mADtC1jCKWvBJow/iKiCXWduMspTZ90IMOlfHWgKhF5FhmGQagNe4nco n74jhtkwXIhm+inLz88Zp5mpZRRhu2uUzGq3nlVDtnrRNQSX49NKcESx4pnbXr3TZykK rFas9h8aX+8217WV5UvF+WJ61cr8VVCZNYZgUuEVJQF9yUW+Ufl3vdusve2TYDNJnlGy MstwZxQ3R6gQYJMIuoyhoE2Up8qv67KIJLF7Y+xgM5NKuaLPkbtNaPJYO/EDbkXGMYol L101HTsDKSnG85CfisY0y8r6MmsnHNBb6Zu8Gf1UrMdOD/7I4OjUH6/JnCC7vjDancM0 BLtQ== X-Gm-Message-State: AIkVDXJhVfYv6VpFyfFpGNKjvMHf3YsELGC6KeCyTXG/kXla5fRUKvLR/gZD2GcgIdkSU+qi7kNmQiK3SZ4L+w== X-Received: by 10.107.166.84 with SMTP id p81mr34183386ioe.15.1483484786532; Tue, 03 Jan 2017 15:06:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.208.207 with HTTP; Tue, 3 Jan 2017 15:06:26 -0800 (PST) X-Originating-IP: [73.234.153.245] In-Reply-To: References: <71d822e413ac457a530e1c367811cc24@cock.lu> <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch> <74aeb4760316b59a3db56c0d16d11f28@cock.lu> From: adiabat Date: Tue, 3 Jan 2017 18:06:26 -0500 Message-ID: To: Aaron Voisine , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a11415270bb45c8054538b790 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, 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: Tue, 03 Jan 2017 23:06:28 -0000 --001a11415270bb45c8054538b790 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mempool transactions have their place, but "unconfirmed" and "SPV" don't belong together. Only a full node can tell if a transaction may get confirmed, or is nonsense. Unfortunately all the light / SPV wallets I know of show mempool transactions, which makes it hard to go back... (e.g. "why doesn't your software show 0-conf! your wallet is broken!", somewhat akin to people complaining about RBF) So, this is easy, just don't worry about mempool filtering. Why are light clients looking at the mempool anyway? Maybe if there were some way to provide SPV proofs of all inputs, but that's a bit of a mess for full nodes to do. Without mempool filtering, I think the committed bloom filters would be a great improvement over the current bloom filter setup, especially for lightning network use cases (with lightning, not finding out about a transaction can make you lose money). I want to work on it and may be able to at some point as it's somewhat related to lightning. Also, if you're running a light client, and storing the filters the way you store block headers, there's really no reason to go all the way back to height 0. You can start grabbing headers at some point a while ago, before your set of keys was generated. I think it'd be very worth it even with GB-scale disk usage. -Tadge On Tue, Jan 3, 2017 at 5:18 PM, Aaron Voisine via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 co= st > 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. > > Aaron > > On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev linuxfoundation.org> wrote: > >> The concept combined with the weak blocks system where miners commit >> >> to potential transaction inclusion with fractional difficulty blocks >> >> is possible. I'm not personally convinced that unconfirmed transaction >> >> display in a wallet is worth the privacy trade-off. The user has very >> >> little to gain from this knowledge until the txn is in a block. >> >> >> >> >> >> On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote: >> >> > Hi >> >> >> We introduce several concepts that rework the lightweight Bitcoin >> >> >> client model in a manner which is secure, efficient and privacy >> >> >> compatible. >> >> >> >> >> >> The BFD can be used verbatim in replacement of BIP37, where the filte= r >> >> >> can be cached between clients without needing to be recomputed. It ca= n >> >> >> also be used by normal pruned nodes to do re-scans locally of their >> >> >> wallet without needing to have the block data available to scan, or >> >> >> without reading the entire block chain from disk. >> >> > I started exploring the potential of BFD after this specification. >> >> > >> >> > What would be the preferred/recommended way to handle 0-conf/mempool >> >> > filtering =E2=80=93 if & once BDF would have been deployed (any type, >> >> > semi-trusted oracles or protocol-level/softfork)? >> >> > >> >> > From the user-experience perspective, this is probably pretty importan= t >> >> > (otherwise the experience will be that incoming funds can take serval >> >> > minutes to hours until they appear). >> >> > Using BIP37 bloom filters just for mempool filtering would obviously >> >> > result in the same unwanted privacy-setup. >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 >> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a11415270bb45c8054538b790 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mempool transactions have= their place, but "unconfirmed" and "SPV" don't bel= ong together.=C2=A0 Only a full node can tell if a transaction may get conf= irmed, or is nonsense.=C2=A0 Unfortunately all the light / SPV wallets I kn= ow of show mempool transactions, which makes it hard to go back... (e.g. &q= uot;why doesn't your software show 0-conf! your wallet is broken!"= , somewhat akin to people complaining about RBF)

So= , this is easy, just don't worry about mempool filtering.=C2=A0 Why are= light clients looking at the mempool anyway?=C2=A0 Maybe if there were som= e way to provide SPV proofs of all inputs, but that's a bit of a mess f= or full nodes to do.

Wi= thout mempool filtering, I think the committed bloom filters would be a gre= at improvement over the current bloom filter setup, especially for lightnin= g network use cases (with lightning, not finding out about a transaction ca= n make you lose money).=C2=A0 I want to work on it and may be able to at so= me point as it's somewhat related to lightning.

Also, if you're running a light client, and storing the filters = the way you store block headers, there's really no reason to go all the= way back to height 0.=C2=A0 You can start grabbing headers at some point a= while ago, before your set of keys was generated.=C2=A0 I think it'd b= e very worth it even with GB-scale disk usage.

-Tadge


On T= ue, Jan 3, 2017 at 5:18 PM, Aaron Voisine via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Unconfirmed transactions are incredibly import= ant 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 l= arge cost to losing the ability to have instant transactions in many or eve= n most situations. This cost is typically well above the fraud risk.=C2=A0<= /div>

It's important to recognize that bitcoin serve= s a wide variety of use cases with different profiles for time sensitivity = and fraud risk.

Aaron
<= div class=3D"h5">

On Tue, Jan 3, 20= 17 at 12:41 PM bfd--- via bitcoin-dev <bitcoin-dev@lists.linuxfound= ation.org> wrote:
The conc= ept combined with the weak blocks system where miners commit

to potential transaction inclusion with fr= actional difficulty blocks

i= s possible. I'm not personally convinced that unconfirmed transaction
display in a wallet is worth = the privacy trade-off. The user has very

little to gain from this knowledge until the txn is in a block= .





On 20= 17-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote:

> Hi

>> We introduce several concepts that rework the lightweight Bi= tcoin

>> client model = in a manner which is secure, efficient and privacy

>> compatible.

>>

>= ;> The BFD can be used verbatim in replacement of BIP37, where the filte= r

>> can be cached bet= ween clients without needing to be recomputed. It can

>> also be used by normal pruned nodes to d= o re-scans locally of their

= >> wallet without needing to have the block data available to scan, o= r

>> without reading t= he entire block chain from disk.

> I started exploring the potential of BFD after this specification= .

>

> What would be the preferred/recommended way = to handle 0-conf/mempool

>= ; filtering =E2=80=93 if & once BDF would have been deployed (any type,=

> semi-trusted oracles o= r protocol-level/softfork)?

= >

> From the user-expe= rience perspective, this is probably pretty important

> (otherwise the experience will be that incom= ing funds can take serval

&g= t; minutes to hours until they appear).

> Using BIP37 bloom filters just for mempool filtering would= obviously

> result in th= e same unwanted privacy-setup.
<= br>>

> </jonas><= br class=3D"m_582444580811563830gmail_msg">
>

>
> _______________________________________________

> bitcoin-dev mailing list

> bitcoin-dev@lists.linuxfoundation.org

> https://lists.linuxfoundation.org/mailman= /listinfo/bitcoin-dev
<= br>_______________________________________________

bitcoin-dev mailing list

bitcoin-de= v@lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin= -dev

<= /div>

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--001a11415270bb45c8054538b790--