path: root/43/55214a7b4cb1ace54216998eb6f8ab1d295e06

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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; 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">&lt;<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 &lt;<a href=3D"mailto:rx@awsomnet.or=
g" target=3D"_blank">rx@awsomnet.org</a>&gt; 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.&nbsp; Only a full node can tell if a transaction<br>
may get confirmed, or is nonsense.&nbsp; 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.&nbsp; Why are<br=
>
light clients looking at the mempool anyway?&nbsp; 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).&nbsp; 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.&nbsp; You can start grabbing headers at some point<br>=

a while ago, before your set of keys was generated.&nbsp; 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>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; 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>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; 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 &amp; 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">
&lt;/jonas&gt;<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--