bfd at cock.lu [ARCHIVE] on Nostr: 📅 Original date posted:2017-01-03 📝 Original message:The concept was not ...
📅 Original date posted:2017-01-03
📝 Original message: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
📝 Original message: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