MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 03 Jan 2017 14:28:56 -0800
From: bfd@cock.lu
To: Aaron Voisine <voisine@gmail.com>
In-Reply-To: <CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>
References: <71d822e413ac457a530e1c367811cc24@cock.lu>
	<77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
	<74aeb4760316b59a3db56c0d16d11f28@cock.lu>
	<CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>
Message-ID: <d57d0f8e0732757d77efdd404170df0d@cock.lu>
User-Agent: Roundcube Webmail/1.2.3
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet
 performance and SPV security
Precedence: list

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@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@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