[bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

[bfd at cock.lu]

The concept was not particularly targeted towards businesses, but
allowing for significantly improved wallet performance and reducing
privacy for lite clients. You would expect that a business has the
capacity to run a fully validating, fully storing node of their own.
If they’re not something is fundamentally broken with Bitcoin, or
their rationale of continuing to use it.


On 2017-01-03 14:18, Aaron Voisine 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
> cost 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
> <bitcoin-dev at lists.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
>> filter
>> 
>>>> can be cached between clients without needing to be recomputed.
>> It can
>> 
>>>> 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 – 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
>> important
>> 
>>> (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.
>> 
>>> 
>> 
>>> </jonas>
>> 
>>> 
>> 
>>> 
>> 
>>> _______________________________________________
>> 
>>> bitcoin-dev mailing list
>> 
>>> bitcoin-dev at lists.linuxfoundation.org
>> 
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
>> _______________________________________________
>> 
>> bitcoin-dev mailing list
>> 
>> bitcoin-dev at lists.linuxfoundation.org
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev