>> >> 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
