Aaron Voisine [ARCHIVE] on Nostr: 📅 Original date posted:2017-01-03 📝 Original message:Knowing that a transaction ...
📅 Original date posted:2017-01-03
📝 Original message:Knowing that a transaction is property formatted and that it has been
broadcast to the gossip network is useful in many situations. You're only
thinking about whether you can know a transaction is valid and/or settled.
This is not the only possible useful information in actual real world use.
Any situation where credit card transactions are accepted today for
instance, it is useful to know that a transaction has been initiated, even
though it can be reversed at any time up to 60 days later.
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com>;
On Tue, Jan 3, 2017 at 4:10 PM, <bfd at cock.lu> wrote:
> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170103/06669e05/attachment-0001.html>;
📝 Original message:Knowing that a transaction is property formatted and that it has been
broadcast to the gossip network is useful in many situations. You're only
thinking about whether you can know a transaction is valid and/or settled.
This is not the only possible useful information in actual real world use.
Any situation where credit card transactions are accepted today for
instance, it is useful to know that a transaction has been initiated, even
though it can be reversed at any time up to 60 days later.
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com>;
On Tue, Jan 3, 2017 at 4:10 PM, <bfd at cock.lu> wrote:
> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170103/06669e05/attachment-0001.html>;