📅 Original date posted:2017-01-01
📝 Original message: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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170101/91d3f504/attachment.sig>;
Jonas Schnelli [ARCHIVE] /
npub1nf…3dtxs
2023-06-07 17:55:03
in reply to nevent1q…yhr5
Author Public Key
npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxsPublished at
2023-06-07 17:55:03Event JSON
{
"id": "4a65296174697bf2a013b81ea5e9ef5fbfb5349aae6df19e3151d6540e3c0549",
"pubkey": "9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c",
"created_at": 1686160503,
"kind": 1,
"tags": [
[
"e",
"12de089a3e4ccbe31128a134586c26b5a984bf25231ca8b54e0116dac53ecb14",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2017-01-01\n📝 Original message:Hi\n\u003e We introduce several concepts that rework the lightweight Bitcoin\n\u003e client model in a manner which is secure, efficient and privacy\n\u003e compatible.\n\u003e\n\u003e The BFD can be used verbatim in replacement of BIP37, where the filter\n\u003e can be cached between clients without needing to be recomputed. It can\n\u003e also be used by normal pruned nodes to do re-scans locally of their\n\u003e wallet without needing to have the block data available to scan, or\n\u003e without reading the entire block chain from disk.\nI started exploring the potential of BFD after this specification.\n\nWhat would be the preferred/recommended way to handle 0-conf/mempool\nfiltering – if \u0026 once BDF would have been deployed (any type,\nsemi-trusted oracles or protocol-level/softfork)?\n\nFrom the user-experience perspective, this is probably pretty important\n(otherwise the experience will be that incoming funds can take serval\nminutes to hours until they appear).\nUsing BIP37 bloom filters just for mempool filtering would obviously\nresult in the same unwanted privacy-setup.\n\n\u003c/jonas\u003e\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170101/91d3f504/attachment.sig\u003e",
"sig": "ed40ba6c4c07cedc66aa98a4cc34532b6bf0c8c6e50809fb2367e3c0b2d1d73383dd2309f488ae7c98a81685bc16cab2c30d712686cac4c0b9639d45d3d4a7d0"
}