<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Credit card reversals involve an escrow agent with control over the entire network and with a strong interest in preserving the network. A better analogy would be blind acceptance of any slip of paper under the assumption that it is sufficient currency. It may or may not be so, but you are on your own in either case.</div><div><br></div><div>e</div><div><br>On Jan 3, 2017, at 4:36 PM, Aaron Voisine via bitcoin-dev &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Knowing that a transaction is property formatted and that it has been broadcast to the gossip network is useful in many situations. You're only thinking 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 situation where credit card transactions are accepted today for instance, it is useful to know that a transaction has been initiated, even though it can be reversed at any time up to 60 days later.<br><div class="gmail_extra"><br><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Aaron Voisine</div><div>co-founder and CEO<br><a href="http://breadwallet.com" target="_blank">breadwallet</a></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Jan 3, 2017 at 4:10 PM,  <span dir="ltr">&lt;<a href="mailto:bfd@cock.lu" target="_blank">bfd@cock.lu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Unfortunately a non validating 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=""><br>
<br>
<br>
On 2017-01-03 15:46, Aaron Voisine wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
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="h5"><br>
On Tue, Jan 3, 2017 at 3:06 PM, adiabat &lt;<a href="mailto:rx@awsomnet.org" target="_blank">rx@awsomnet.org</a>&gt; wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="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="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">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="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin: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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin: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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
compatible.<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin: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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin: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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin: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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin: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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin: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="gmail_quote" style="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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
filtering – if &amp; once BDF would have been deployed (any type,<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From the user-experience perspective, this is probably pretty<br>
</blockquote>
important<br>
<br>
<blockquote class="gmail_quote" style="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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
minutes to hours until they appear).<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="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="gmail_quote" style="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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&lt;/jonas&gt;<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
______________________________<wbr>_________________<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
bitcoin-dev mailing list<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
</blockquote>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a> [1]<br>
</blockquote><span class="">
<br>
______________________________<wbr>_________________<br>
<br>
bitcoin-dev mailing list<br>
<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<br>
</span><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a> [1]<span class=""><br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
</span><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a> [1]<br>
</blockquote>
<br>
<br>
<br>
Links:<br>
------<br>
[1] <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
[2] <a href="http://breadwallet.com" rel="noreferrer" target="_blank">http://breadwallet.com</a><br>
</blockquote>
</blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>bitcoin-dev mailing list</span><br><span><a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></html>