📅 Original date posted:2017-01-03
📝 Original message:Unfortunately a non validating SPV wallet has absolutely no idea if
the information about an unconfirmed transaction they are seeing is
anything but properly formatted. They are connecting to an easily
manipulated, sybil attacked, and untrusted network and then asking
them for financial information. Seeing an unconfirmed transaction in a
wallet that's not also fully validating is at best meaningless.
On 2017-01-03 15:46, Aaron Voisine wrote:
> If the sender doesn't control the receiver's network connection, then
> the information the receiver gains by watching the mempool is if the
> transaction has propagated across the bitcoin network. This is useful
> to know in all kinds of situations.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet [2]
> On Tue, Jan 3, 2017 at 3:06 PM, adiabat <rx at awsomnet.org> wrote:
>
>> 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 [1]
>>
>> _______________________________________________
>>
>> bitcoin-dev mailing list
>>
>> bitcoin-dev at lists.linuxfoundation.org
>>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>
>
>
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> [2] http://breadwallet.com
bfd at cock.lu [ARCHIVE] /
npub1md…gy6y7
2023-06-07 17:55:05
in reply to nevent1q…lhrl
Author Public Key
npub1mdmqmt0prpddcexkljfzd40uf7nvrc56c7gsg2spn3lgcjghguxqwgy6y7Published at
2023-06-07 17:55:05Event JSON
{
"id": "191c8beeb0120791b544e9e2f9f167cfbaea98453d471d49c15996df0c969032",
"pubkey": "db760dade1185adc64d6fc9226d5fc4fa6c1e29ac791042a019c7e8c4917470c",
"created_at": 1686160505,
"kind": 1,
"tags": [
[
"e",
"12de089a3e4ccbe31128a134586c26b5a984bf25231ca8b54e0116dac53ecb14",
"",
"root"
],
[
"e",
"4c89109d69988f3ab99f162559923dc32a9eab81903924f9a7e7060b4cdfc1ce",
"",
"reply"
],
[
"p",
"3a24ce2145c5488aebfb0fc113e7d44234e9d3733afa45e2d880eb259c3eade3"
]
],
"content": "📅 Original date posted:2017-01-03\n📝 Original message:Unfortunately a non validating SPV wallet has absolutely no idea if\nthe information about an unconfirmed transaction they are seeing is\nanything but properly formatted. They are connecting to an easily\nmanipulated, sybil attacked, and untrusted network and then asking\nthem for financial information. Seeing an unconfirmed transaction in a\nwallet that's not also fully validating is at best meaningless.\n\n\nOn 2017-01-03 15:46, Aaron Voisine wrote:\n\u003e If the sender doesn't control the receiver's network connection, then\n\u003e the information the receiver gains by watching the mempool is if the\n\u003e transaction has propagated across the bitcoin network. This is useful\n\u003e to know in all kinds of situations.\n\u003e \n\u003e Aaron Voisine\n\u003e co-founder and CEO\n\u003e breadwallet [2]\n\u003e On Tue, Jan 3, 2017 at 3:06 PM, adiabat \u003crx at awsomnet.org\u003e wrote:\n\u003e \n\u003e\u003e Mempool transactions have their place, but \"unconfirmed\" and \"SPV\"\n\u003e\u003e don't belong together. Only a full node can tell if a transaction\n\u003e\u003e may get confirmed, or is nonsense. Unfortunately all the light /\n\u003e\u003e SPV wallets I know of show mempool transactions, which makes it hard\n\u003e\u003e to go back... (e.g. \"why doesn't your software show 0-conf! your\n\u003e\u003e wallet is broken!\", somewhat akin to people complaining about RBF)\n\u003e\u003e \n\u003e\u003e So, this is easy, just don't worry about mempool filtering. Why are\n\u003e\u003e light clients looking at the mempool anyway? Maybe if there were\n\u003e\u003e some way to provide SPV proofs of all inputs, but that's a bit of a\n\u003e\u003e mess for full nodes to do.\n\u003e\u003e \n\u003e\u003e Without mempool filtering, I think the committed bloom filters would\n\u003e\u003e be a great improvement over the current bloom filter setup,\n\u003e\u003e especially for lightning network use cases (with lightning, not\n\u003e\u003e finding out about a transaction can make you lose money). I want to\n\u003e\u003e work on it and may be able to at some point as it's somewhat related\n\u003e\u003e to lightning.\n\u003e\u003e \n\u003e\u003e Also, if you're running a light client, and storing the filters the\n\u003e\u003e way you store block headers, there's really no reason to go all the\n\u003e\u003e way back to height 0. You can start grabbing headers at some point\n\u003e\u003e a while ago, before your set of keys was generated. I think it'd be\n\u003e\u003e very worth it even with GB-scale disk usage.\n\u003e\u003e \n\u003e\u003e -Tadge\n\u003e\u003e \n\u003e\u003e On Tue, Jan 3, 2017 at 5:18 PM, Aaron Voisine via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \n\u003e\u003e Unconfirmed transactions are incredibly important for real world\n\u003e\u003e use. Merchants for instance are willing to accept credit card\n\u003e\u003e payments of thousands of dollars and ship the goods despite the fact\n\u003e\u003e that the transaction can be reversed up to 60 days later. There is a\n\u003e\u003e very large cost to losing the ability to have instant transactions\n\u003e\u003e in many or even most situations. This cost is typically well above\n\u003e\u003e the fraud risk.\n\u003e\u003e \n\u003e\u003e It's important to recognize that bitcoin serves a wide variety of\n\u003e\u003e use cases with different profiles for time sensitivity and fraud\n\u003e\u003e risk.\n\u003e\u003e \n\u003e\u003e Aaron\n\u003e\u003e \n\u003e\u003e On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\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\n\u003e\u003e transaction\n\u003e\u003e \n\u003e\u003e display in a wallet is worth the privacy trade-off. The user has\n\u003e\u003e 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 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\n\u003e\u003e filter\n\u003e\u003e \n\u003e\u003e\u003e\u003e can be cached between clients without needing to be recomputed.\n\u003e\u003e It can\n\u003e\u003e \n\u003e\u003e\u003e\u003e also be used by normal pruned nodes to do re-scans locally of\n\u003e\u003e their\n\u003e\u003e \n\u003e\u003e\u003e\u003e wallet without needing to have the block data available to scan,\n\u003e\u003e 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\n\u003e\u003e 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\n\u003e\u003e important\n\u003e\u003e \n\u003e\u003e\u003e (otherwise the experience will be that incoming funds can take\n\u003e\u003e 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\n\u003e\u003e 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 [1]\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 [1]\n\u003e\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]\n\u003e \n\u003e \n\u003e \n\u003e Links:\n\u003e ------\n\u003e [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e [2] http://breadwallet.com",
"sig": "e894af337f72c478961c7b29f6011b313f06aa46408fc7e7300a87161cbc465eaa7cdfdbfb48cb642eff0e66c48271b40c63e914125d6e311d03ec7e19f134ca"
}