From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <eric@voskuil.org> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F2B9A932 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 4 Jan 2017 06:06:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f51.google.com (mail-it0-f51.google.com [209.85.214.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 64198FE for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 4 Jan 2017 06:06:34 +0000 (UTC) Received: by mail-it0-f51.google.com with SMTP id o141so293365810itc.0 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 03 Jan 2017 22:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J2ISpB60xm58SgLy/pJre6hiTvzlEBui1O2hSSfo9uU=; b=mqX373Y7e9LyrokYCTPlNqAYYN+OU6RM72pAwY4gWK4fJNVWSIEuZTMR2YFjU6RRDk bdlzjbpcVeFNtcyE1ynWu1wqVRdilszEc1JEgr53cbWXA39vY4UQuqDVlrqbToikqNO+ TNmim9RmmLNH//d/eJfxnAkj3Hiez/Cxr1a9iTWtQr5+1HMh5UYHii0PweelGwFJ6Xu+ R2o6eRVVzdeMtqsFZBhHuYrabnoyykdmdKTafN4Glf/lsHRE+zr9w4Er85u0r7IUgSV3 pBM//3hGl8gGzwRkT4J8EoL1wNhDrag/gDSTxrVBS41l9egZ+MiuzN9cqE+IR9yUmKTW BZYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J2ISpB60xm58SgLy/pJre6hiTvzlEBui1O2hSSfo9uU=; b=SYzZB+X1qA//2LHiFyu//X+liImQNTD5BY2+E5E4vmVHhvrY7dgrZJvzdYhwaCW33b 9967eUFp1M4TaUglj00ZVS2jUWQmnhqY3otIKyW7DtzYTtWSVHcEY7/IgWpzEGOQ/s+F s7JD7uJFSPzn3/wyWWkkHM+1cWmWhDeHzxrF/GQrSvKBVT+ctM6uTU7AkdsVnRQLoIa+ Xk2P718clXoqvyWY12RK3//DStiVT2bxYBEPqgQzYAwwJNTS7e5vjwqUJqr6scXEkKKp letauPHN/i0e2WaS/gdhlERpu32aSpuP2dC1xZ3SQAFWMqzTQVMkS0V29MBs4mMU92l3 7vCg== X-Gm-Message-State: AIkVDXLJGog2NYskK5YbpURktOjPF2B+4+q6emwhpBZd/xdYJnWE1+JwhBGB/XtaPBnPFQ== X-Received: by 10.36.64.21 with SMTP id n21mr51619807ita.27.1483509993726; Tue, 03 Jan 2017 22:06:33 -0800 (PST) Received: from ?IPv6:2601:600:9000:d69e:2443:5ad0:902b:5a3b? ([2601:600:9000:d69e:2443:5ad0:902b:5a3b]) by smtp.gmail.com with ESMTPSA id c9sm6407137ioc.2.2017.01.03.22.06.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 22:06:32 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-6EBFF3C9-346E-4C8E-A7CA-7F30229947C9 Mime-Version: 1.0 (1.0) From: Eric Voskuil <eric@voskuil.org> X-Mailer: iPhone Mail (14B100) In-Reply-To: <CACq0ZD4==ePkuR_dMALABDJcyyWe0x=21-w80cTp0CLe47_Emg@mail.gmail.com> Date: Tue, 3 Jan 2017 22:06:31 -0800 Content-Transfer-Encoding: 7bit Message-Id: <25735AD4-CDCC-4632-AE03-1B657643E757@voskuil.org> References: <71d822e413ac457a530e1c367811cc24@cock.lu> <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch> <74aeb4760316b59a3db56c0d16d11f28@cock.lu> <CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com> <CAKEeUhiQiUA_E6JF22foV11-WnGZH+kEzfUhROm=gvVN1qMr4A@mail.gmail.com> <CACq0ZD5WV7ORmEJgGSquyRzndH_XP9FrLbwSNKQC5Zuh08NVDw@mail.gmail.com> <22b7d05fb2b8a7a0f1c2fa0b6b375f7e@cock.lu> <CACq0ZD4==ePkuR_dMALABDJcyyWe0x=21-w80cTp0CLe47_Emg@mail.gmail.com> To: Aaron Voisine <voisine@gmail.com>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 04 Jan 2017 07:09:50 +0000 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 <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: Wed, 04 Jan 2017 06:06:36 -0000 --Apple-Mail-6EBFF3C9-346E-4C8E-A7CA-7F30229947C9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Credit card reversals involve an escrow agent with control over the entire n= etwork and with a strong interest in preserving the network. A better analog= y would be blind acceptance of any slip of paper under the assumption that i= t is sufficient currency. It may or may not be so, but you are on your own i= n either case. e > On Jan 3, 2017, at 4:36 PM, Aaron Voisine via bitcoin-dev <bitcoin-dev@lis= ts.linuxfoundation.org> wrote: >=20 > Knowing that a transaction is property formatted and that it has been broa= dcast to the gossip network is useful in many situations. You're only thinki= ng about whether you can know a transaction is valid and/or settled. This is= not the only possible useful information in actual real world use. Any situ= ation where credit card transactions are accepted today for instance, it is u= seful to know that a transaction has been initiated, even though it can be r= eversed at any time up to 60 days later. >=20 > Aaron Voisine > co-founder and CEO > breadwallet >=20 >> On Tue, Jan 3, 2017 at 4:10 PM, <bfd@cock.lu> wrote: >> Unfortunately a non validating SPV wallet has absolutely no idea if >> the information about an unconfirmed transaction they are seeing is >> anything but properly formatted. They are connecting to an easily >> manipulated, sybil attacked, and untrusted network and then asking >> them for financial information. Seeing an unconfirmed transaction in a >> wallet that's not also fully validating is at best meaningless. >>=20 >>=20 >>> On 2017-01-03 15:46, Aaron Voisine wrote: >>> If the sender doesn't control the receiver's network connection, then >>> the information the receiver gains by watching the mempool is if the >>> transaction has propagated across the bitcoin network. This is useful >>> to know in all kinds of situations. >>>=20 >>> Aaron Voisine >>> co-founder and CEO >>> breadwallet [2] >>>=20 >>> On Tue, Jan 3, 2017 at 3:06 PM, adiabat <rx@awsomnet.org> wrote: >>>=20 >>>> 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) >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> -Tadge >>>>=20 >>>> On Tue, Jan 3, 2017 at 5:18 PM, Aaron Voisine via bitcoin-dev >>>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>>>=20 >>>> 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. >>>>=20 >>>> It's important to recognize that bitcoin serves a wide variety of >>>> use cases with different profiles for time sensitivity and fraud >>>> risk. >>>>=20 >>>> Aaron >>>>=20 >>>> On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev >>>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>>> The concept combined with the weak blocks system where miners commit >>>>=20 >>>> to potential transaction inclusion with fractional difficulty blocks >>>>=20 >>>> is possible. I'm not personally convinced that unconfirmed >>>> transaction >>>>=20 >>>> display in a wallet is worth the privacy trade-off. The user has >>>> very >>>>=20 >>>> little to gain from this knowledge until the txn is in a block. >>>>=20 >>>> On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote: >>>>=20 >>>>> Hi >>>>=20 >>>>>> We introduce several concepts that rework the lightweight Bitcoin >>>>=20 >>>>>> client model in a manner which is secure, efficient and privacy >>>>=20 >>>>>> compatible. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> The BFD can be used verbatim in replacement of BIP37, where the >>>> filter >>>>=20 >>>>>> can be cached between clients without needing to be recomputed. >>>> It can >>>>=20 >>>>>> also be used by normal pruned nodes to do re-scans locally of >>>> their >>>>=20 >>>>>> wallet without needing to have the block data available to scan, >>>> or >>>>=20 >>>>>> without reading the entire block chain from disk. >>>>=20 >>>>> I started exploring the potential of BFD after this specification. >>>>=20 >>>>>=20 >>>>=20 >>>>> What would be the preferred/recommended way to handle >>>> 0-conf/mempool >>>>=20 >>>>> filtering =E2=80=93 if & once BDF would have been deployed (any type, >>>>=20 >>>>> semi-trusted oracles or protocol-level/softfork)? >>>>=20 >>>>>=20 >>>>=20 >>>>> =46rom the user-experience perspective, this is probably pretty >>>> important >>>>=20 >>>>> (otherwise the experience will be that incoming funds can take >>>> serval >>>>=20 >>>>> minutes to hours until they appear). >>>>=20 >>>>> Using BIP37 bloom filters just for mempool filtering would >>>> obviously >>>>=20 >>>>> result in the same unwanted privacy-setup. >>>>=20 >>>>>=20 >>>>=20 >>>>> </jonas> >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> _______________________________________________ >>>>=20 >>>>> bitcoin-dev mailing list >>>>=20 >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>=20 >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1] >>>>=20 >>>> _______________________________________________ >>>>=20 >>>> bitcoin-dev mailing list >>>>=20 >>>> bitcoin-dev@lists.linuxfoundation.org >>>>=20 >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1] >>>>=20 >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1] >>>=20 >>>=20 >>>=20 >>> Links: >>> ------ >>> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> [2] http://breadwallet.com >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-6EBFF3C9-346E-4C8E-A7CA-7F30229947C9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div></div><div>Credit card reversals invol= ve an escrow agent with control over the entire network and with a strong in= terest in preserving the network. A better analogy would be blind acceptance= of any slip of paper under the assumption that it is sufficient currency. I= t may or may not be so, but you are on your own in either case.</div><div><b= r></div><div>e</div><div><br>On Jan 3, 2017, at 4:36 PM, Aaron Voisine via b= itcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc= oin-dev@lists.linuxfoundation.org</a>> wrote:<br><br></div><blockquote ty= pe=3D"cite"><div><div dir=3D"ltr">Knowing that a transaction is property for= matted and that it has been broadcast to the gossip network is useful in man= y situations. You're only thinking about whether you can know a transaction i= s valid and/or settled. This is not the only possible useful information in a= ctual real world use. Any situation where credit card transactions are accep= ted today for instance, it is useful to know that a transaction has been ini= tiated, even though it can be reversed at any time up to 60 days later.<br><= div class=3D"gmail_extra"><br><div><div class=3D"gmail_signature" data-smart= mail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div di= r=3D"ltr"><div>Aaron Voisine</div><div>co-founder and CEO<br><a href=3D"http= ://breadwallet.com" target=3D"_blank">breadwallet</a></div></div></div></div= ></div></div></div></div> <br><div class=3D"gmail_quote">On Tue, Jan 3, 2017 at 4:10 PM, <span dir=3D= "ltr"><<a href=3D"mailto:bfd@cock.lu" target=3D"_blank">bfd@cock.lu</a>&g= t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">Unfortunately a non validat= ing SPV wallet has absolutely no idea if<br> the information about an unconfirmed transaction they are seeing is<br> anything but properly formatted. They are connecting to an easily<br> manipulated, sybil attacked, and untrusted network and then asking<br> them for financial information. Seeing an unconfirmed transaction in a<br> wallet that's not also fully validating is at best meaningless.<span class=3D= ""><br> <br> <br> On 2017-01-03 15:46, Aaron Voisine wrote:<br> </span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><span class=3D""> If the sender doesn't control the receiver's network connection, then<br> the information the receiver gains by watching the mempool is if the<br> transaction has propagated across the bitcoin network. This is useful<br> to know in all kinds of situations.<br> <br> Aaron Voisine<br> co-founder and CEO<br></span> breadwallet [2]<div><div class=3D"h5"><br> On Tue, Jan 3, 2017 at 3:06 PM, adiabat <<a href=3D"mailto:rx@awsomnet.or= g" target=3D"_blank">rx@awsomnet.org</a>> wrote:<br> <br> </div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= der-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"> Mempool transactions have their place, but "unconfirmed" and "SPV"<br> don't belong together. Only a full node can tell if a transaction<br> may get confirmed, or is nonsense. Unfortunately all the light /<br> SPV wallets I know of show mempool transactions, which makes it hard<br> to go back... (e.g. "why doesn't your software show 0-conf! your<br> wallet is broken!", somewhat akin to people complaining about RBF)<br> <br> So, this is easy, just don't worry about mempool filtering. Why are<br= > light clients looking at the mempool anyway? Maybe if there were<br> some way to provide SPV proofs of all inputs, but that's a bit of a<br> mess for full nodes to do.<br> <br> Without mempool filtering, I think the committed bloom filters would<br> be a great improvement over the current bloom filter setup,<br> especially for lightning network use cases (with lightning, not<br> finding out about a transaction can make you lose money). I want to<br= > work on it and may be able to at some point as it's somewhat related<br> to lightning.<br> <br> Also, if you're running a light client, and storing the filters the<br> way you store block headers, there's really no reason to go all the<br> way back to height 0. You can start grabbing headers at some point<br>= a while ago, before your set of keys was generated. I think it'd be<br= > very worth it even with GB-scale disk usage.<br> <br> -Tadge<br> <br> On Tue, Jan 3, 2017 at 5:18 PM, Aaron Voisine via bitcoin-dev<br> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan= k">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<br> <br> Unconfirmed transactions are incredibly important for real world<br> use. Merchants for instance are willing to accept credit card<br> payments of thousands of dollars and ship the goods despite the fact<br> that the transaction can be reversed up to 60 days later. There is a<br> very large cost to losing the ability to have instant transactions<br> in many or even most situations. This cost is typically well above<br> the fraud risk.<br> <br> It's important to recognize that bitcoin serves a wide variety of<br> use cases with different profiles for time sensitivity and fraud<br> risk.<br> <br> Aaron<br> <br> On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev<br> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan= k">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<br> The concept combined with the weak blocks system where miners commit<br> <br> to potential transaction inclusion with fractional difficulty blocks<br> <br> is possible. I'm not personally convinced that unconfirmed<br> transaction<br> <br> display in a wallet is worth the privacy trade-off. The user has<br> very<br> <br> little to gain from this knowledge until the txn is in a block.<br> <br> On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Hi<br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> We introduce several concepts that rework the lightweight Bitcoin<br> </blockquote></blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> client model in a manner which is secure, efficient and privacy<br> </blockquote></blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> compatible.<br> </blockquote></blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> </blockquote></blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The BFD can be used verbatim in replacement of BIP37, where the<br> </blockquote></blockquote> filter<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> can be cached between clients without needing to be recomputed.<br> </blockquote></blockquote> It can<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> also be used by normal pruned nodes to do re-scans locally of<br> </blockquote></blockquote> their<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> wallet without needing to have the block data available to scan,<br> </blockquote></blockquote> or<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> without reading the entire block chain from disk.<br> </blockquote></blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> I started exploring the potential of BFD after this specification.<br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> <br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> What would be the preferred/recommended way to handle<br> </blockquote> 0-conf/mempool<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> filtering =E2=80=93 if & once BDF would have been deployed (any type,<br= > </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> semi-trusted oracles or protocol-level/softfork)?<br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> <br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> =46rom the user-experience perspective, this is probably pretty<br> </blockquote> important<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> (otherwise the experience will be that incoming funds can take<br> </blockquote> serval<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> minutes to hours until they appear).<br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Using BIP37 bloom filters just for mempool filtering would<br> </blockquote> obviously<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> result in the same unwanted privacy-setup.<br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> <br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> </jonas><br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> <br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> <br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> ______________________________<wbr>_________________<br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> bitcoin-dev mailing list<br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b= itcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> </blockquote> <br> </div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= der-left:1px #ccc solid;padding-left:1ex"> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r= el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/m= ailman/listinfo/bitcoin-d<wbr>ev</a> [1]<br> </blockquote><span class=3D""> <br> ______________________________<wbr>_________________<br> <br> bitcoin-dev mailing list<br> <br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b= itcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> <br> </span><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin= -dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb= r>org/mailman/listinfo/bitcoin-d<wbr>ev</a> [1]<span class=3D""><br> <br> ______________________________<wbr>_________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b= itcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> </span><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin= -dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb= r>org/mailman/listinfo/bitcoin-d<wbr>ev</a> [1]<br> </blockquote> <br> <br> <br> Links:<br> ------<br> [1] <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-de= v" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>o= rg/mailman/listinfo/bitcoin-d<wbr>ev</a><br> [2] <a href=3D"http://breadwallet.com" rel=3D"noreferrer" target=3D"_blank">= http://breadwallet.com</a><br> </blockquote> </blockquote></div><br></div></div> </div></blockquote><blockquote type=3D"cite"><div><span>____________________= ___________________________</span><br><span>bitcoin-dev mailing list</span><= br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de= v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin= uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></= html>= --Apple-Mail-6EBFF3C9-346E-4C8E-A7CA-7F30229947C9--