📅 Original date posted:2017-01-03
📝 Original message:Mempool transactions have their place, but "unconfirmed" and "SPV" don't
belong together. Only a full node can tell if a transaction may get
confirmed, or is nonsense. Unfortunately all the light / SPV wallets I
know of show mempool transactions, which makes it hard to go back... (e.g.
"why doesn't your software show 0-conf! your wallet is broken!", somewhat
akin to people complaining about RBF)
So, this is easy, just don't worry about mempool filtering. Why are light
clients looking at the mempool anyway? Maybe if there were some way to
provide SPV proofs of all inputs, but that's a bit of a mess for full nodes
to do.
Without mempool filtering, I think the committed bloom filters would be a
great improvement over the current bloom filter setup, especially for
lightning network use cases (with lightning, not finding out about a
transaction can make you lose money). I want to work on it and may be able
to at some point as it's somewhat related to lightning.
Also, if you're running a light client, and storing the filters the way you
store block headers, there's really no reason to go all the way back to
height 0. You can start grabbing headers at some point a while ago, before
your set of keys was generated. I think it'd be very worth it even with
GB-scale disk usage.
-Tadge
On Tue, Jan 3, 2017 at 5:18 PM, Aaron Voisine via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> 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
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170103/399f0f9b/attachment.html>;
adiabat [ARCHIVE] /
npub1sa…y4xsu
2023-06-07 17:55:04
in reply to nevent1q…5gqk
Author Public Key
npub1sax5yz8xgp684kl9c5f4kzljunm7u569vgfvuv66xtnl2aqs664s0y4xsuSeen on
wss://relay.noswhere.comPublished at
2023-06-07 17:55:04Event JSON
{
"id": "574d92848c5270b123d1910c2d834d58810be3451606f6151394382f2c8eae6e",
"pubkey": "874d4208e640747adbe5c5135b0bf2e4f7ee53456212ce335a32e7f57410d6ab",
"created_at": 1686160504,
"kind": 1,
"tags": [
[
"e",
"12de089a3e4ccbe31128a134586c26b5a984bf25231ca8b54e0116dac53ecb14",
"",
"root"
],
[
"e",
"b6f5fc6484e919a43c6dc60f86abf000ce3231023af9c41d9953c0bc23edbcb6",
"",
"reply"
],
[
"p",
"db760dade1185adc64d6fc9226d5fc4fa6c1e29ac791042a019c7e8c4917470c"
]
],
"content": "📅 Original date posted:2017-01-03\n📝 Original message:Mempool transactions have their place, but \"unconfirmed\" and \"SPV\" don't\nbelong together. Only a full node can tell if a transaction may get\nconfirmed, or is nonsense. Unfortunately all the light / SPV wallets I\nknow of show mempool transactions, which makes it hard to go back... (e.g.\n\"why doesn't your software show 0-conf! your wallet is broken!\", somewhat\nakin to people complaining about RBF)\n\nSo, this is easy, just don't worry about mempool filtering. Why are light\nclients looking at the mempool anyway? Maybe if there were some way to\nprovide SPV proofs of all inputs, but that's a bit of a mess for full nodes\nto do.\n\nWithout mempool filtering, I think the committed bloom filters would be a\ngreat improvement over the current bloom filter setup, especially for\nlightning network use cases (with lightning, not finding out about a\ntransaction can make you lose money). I want to work on it and may be able\nto at some point as it's somewhat related to lightning.\n\nAlso, if you're running a light client, and storing the filters the way you\nstore block headers, there's really no reason to go all the way back to\nheight 0. You can start grabbing headers at some point a while ago, before\nyour set of keys was generated. I think it'd be very worth it even with\nGB-scale disk usage.\n\n-Tadge\n\n\nOn Tue, Jan 3, 2017 at 5:18 PM, Aaron Voisine via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Unconfirmed transactions are incredibly important for real world use.\n\u003e Merchants for instance are willing to accept credit card payments of\n\u003e thousands of dollars and ship the goods despite the fact that the\n\u003e transaction can be reversed up to 60 days later. There is a very large cost\n\u003e to losing the ability to have instant transactions in many or even most\n\u003e situations. This cost is typically well above the fraud risk.\n\u003e\n\u003e It's important to recognize that bitcoin serves a wide variety of use\n\u003e cases with different profiles for time sensitivity and fraud risk.\n\u003e\n\u003e Aaron\n\u003e\n\u003e On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev \u003cbitcoin-dev at lists.\n\u003e linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e The concept combined with the weak blocks system where miners commit\n\u003e\u003e\n\u003e\u003e to potential transaction inclusion with fractional difficulty blocks\n\u003e\u003e\n\u003e\u003e is possible. I'm not personally convinced that unconfirmed transaction\n\u003e\u003e\n\u003e\u003e display in a wallet is worth the privacy trade-off. The user has very\n\u003e\u003e\n\u003e\u003e little to gain from this knowledge until the txn is in a block.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote:\n\u003e\u003e\n\u003e\u003e \u003e Hi\n\u003e\u003e\n\u003e\u003e \u003e\u003e We introduce several concepts that rework the lightweight Bitcoin\n\u003e\u003e\n\u003e\u003e \u003e\u003e client model in a manner which is secure, efficient and privacy\n\u003e\u003e\n\u003e\u003e \u003e\u003e compatible.\n\u003e\u003e\n\u003e\u003e \u003e\u003e\n\u003e\u003e\n\u003e\u003e \u003e\u003e The BFD can be used verbatim in replacement of BIP37, where the filter\n\u003e\u003e\n\u003e\u003e \u003e\u003e can be cached between clients without needing to be recomputed. It can\n\u003e\u003e\n\u003e\u003e \u003e\u003e also be used by normal pruned nodes to do re-scans locally of their\n\u003e\u003e\n\u003e\u003e \u003e\u003e wallet without needing to have the block data available to scan, or\n\u003e\u003e\n\u003e\u003e \u003e\u003e without reading the entire block chain from disk.\n\u003e\u003e\n\u003e\u003e \u003e I started exploring the potential of BFD after this specification.\n\u003e\u003e\n\u003e\u003e \u003e\n\u003e\u003e\n\u003e\u003e \u003e What would be the preferred/recommended way to handle 0-conf/mempool\n\u003e\u003e\n\u003e\u003e \u003e filtering – if \u0026 once BDF would have been deployed (any type,\n\u003e\u003e\n\u003e\u003e \u003e semi-trusted oracles or protocol-level/softfork)?\n\u003e\u003e\n\u003e\u003e \u003e\n\u003e\u003e\n\u003e\u003e \u003e From the user-experience perspective, this is probably pretty important\n\u003e\u003e\n\u003e\u003e \u003e (otherwise the experience will be that incoming funds can take serval\n\u003e\u003e\n\u003e\u003e \u003e minutes to hours until they appear).\n\u003e\u003e\n\u003e\u003e \u003e Using BIP37 bloom filters just for mempool filtering would obviously\n\u003e\u003e\n\u003e\u003e \u003e result in the same unwanted privacy-setup.\n\u003e\u003e\n\u003e\u003e \u003e\n\u003e\u003e\n\u003e\u003e \u003e \u003c/jonas\u003e\n\u003e\u003e\n\u003e\u003e \u003e\n\u003e\u003e\n\u003e\u003e \u003e\n\u003e\u003e\n\u003e\u003e \u003e _______________________________________________\n\u003e\u003e\n\u003e\u003e \u003e bitcoin-dev mailing list\n\u003e\u003e\n\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\n\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170103/399f0f9b/attachment.html\u003e",
"sig": "f23d3e0614e4766448aed9f1438178eb28f1f935b13804268ebd22bacc5c5a0603d43a0e3ca4f6a684f65625be75ac76efb48b33a2f19ad18669af2103fa514d"
}