Why Nostr? What is Njump?
2023-06-07 17:55:03
in reply to

bfd at cock.lu [ARCHIVE] on Nostr: 📅 Original date posted:2017-01-03 📝 Original message:The concept combined with ...

📅 Original date posted:2017-01-03
📝 Original message: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
Author Public Key
npub1mdmqmt0prpddcexkljfzd40uf7nvrc56c7gsg2spn3lgcjghguxqwgy6y7