Jonas Schnelli [ARCHIVE] on Nostr: đź“… Original date posted:2017-06-19 đź“ť Original message:>> >> I think many users ...
đź“… Original date posted:2017-06-19
đź“ť Original message:>>
>> I think many users would be willing ...
>> a) … to trade higher privacy (using client side filtering) for not having
>> the „incoming transaction“ feature b) – if they want 0-conf – to fetch
>> all inved transactions
>
> You seem to misunderstand the usecase.
> If you send me a transaction, both of use are using our phones, then I need
> to be able to have immediate feedback on the transaction being broadcast on
> the network.
> This is not about zero-conf, this is simple seeing what is happening while
> it is happening.
>
> Additionally, when the transaction that is meant for my wallet is broadcast,
> I want my SPV wallet to parse and check the actual transaction.
> It is not just to see that *something* was actually send, but also to be
> able to see how much is being paid to me. Maybe If the transaction is marked
> as RBF-able, etc.
>
> Really basic usability: provide information to your users when you can,
> should they want to, and by default on.
I see this use case.
But I did receive bank wire transfers for the last decades without _immediately_ knowing that someone sent funds to me.
I personally would ALWAYS trade the higher bandwidth consumption (300MB mempool filtering) or slower notification time (maybe ~1h) for preserving privacy.
I agree, there are use cases where you want immediate notification, those use cases could probably be solved by not trowing away privacy („parsing“ all transactions and running in the background).
/jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170619/beccad65/attachment.sig>;
đź“ť Original message:>>
>> I think many users would be willing ...
>> a) … to trade higher privacy (using client side filtering) for not having
>> the „incoming transaction“ feature b) – if they want 0-conf – to fetch
>> all inved transactions
>
> You seem to misunderstand the usecase.
> If you send me a transaction, both of use are using our phones, then I need
> to be able to have immediate feedback on the transaction being broadcast on
> the network.
> This is not about zero-conf, this is simple seeing what is happening while
> it is happening.
>
> Additionally, when the transaction that is meant for my wallet is broadcast,
> I want my SPV wallet to parse and check the actual transaction.
> It is not just to see that *something* was actually send, but also to be
> able to see how much is being paid to me. Maybe If the transaction is marked
> as RBF-able, etc.
>
> Really basic usability: provide information to your users when you can,
> should they want to, and by default on.
I see this use case.
But I did receive bank wire transfers for the last decades without _immediately_ knowing that someone sent funds to me.
I personally would ALWAYS trade the higher bandwidth consumption (300MB mempool filtering) or slower notification time (maybe ~1h) for preserving privacy.
I agree, there are use cases where you want immediate notification, those use cases could probably be solved by not trowing away privacy („parsing“ all transactions and running in the background).
/jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170619/beccad65/attachment.sig>;