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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
