📅 Original date posted:2017-06-19 📝 Original message:On Monday, 19 June 2017 ...

Tom Zander [ARCHIVE] /

npub1mju…xnq7

2023-06-07 18:02:12

in reply to nevent1q…vy6v

📅 Original date posted:2017-06-19
📝 Original message:On Monday, 19 June 2017 17:49:59 CEST Jonas Schnelli wrote:
> Hi
>
> > On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote:
> >> It's been debated if [filtering of] unconfirmed transactions are
> >> necessary,
> >
> > Why would it not be needed? Any SPV client (when used as a
> > payment-receiver) requires this from a simple usability point of view.
>
> 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.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Author Public Key

npub1mju50kqcm07heu967fkq6h4kq666xgekc4yrldf7q52xx9vr8jnsrdxnq7

Seen on

wss://relay.nostr.band

Show more details

Published at

2023-06-07 18:02:12

Kind type

1 Short Text Note

Event JSON

{ "id": "2eb71947ba76b4e08fc3eabc475be65a2227241c4c0497438c37ac42a9908487", "pubkey": "dcb947d818dbfd7cf0baf26c0d5eb606b5a32336c5483fb53e05146315833ca7", "created_at": 1686160932, "kind": 1, "tags": [ [ "e", "55a56c7ebba05dd9613a9ae00ae6d5bbfa4f7fd0155fa447a7d09d61ff658a4b", "", "root" ], [ "e", "f75326869e559208c4daacaf8d1987adda0c1e314e4d07103acf0a14cc8869c4", "", "reply" ], [ "p", "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e" ] ], "content": "📅 Original date posted:2017-06-19\n📝 Original message:On Monday, 19 June 2017 17:49:59 CEST Jonas Schnelli wrote:\n\u003e Hi\n\u003e \n\u003e \u003e On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote:\n\u003e \u003e\u003e It's been debated if [filtering of] unconfirmed transactions are\n\u003e \u003e\u003e necessary,\n\u003e \u003e \n\u003e \u003e Why would it not be needed? Any SPV client (when used as a\n\u003e \u003e payment-receiver) requires this from a simple usability point of view.\n\u003e \n\u003e I think many users would be willing ...\n\u003e a) … to trade higher privacy (using client side filtering) for not having\n\u003e the „incoming transaction“ feature b) – if they want 0-conf – to fetch\n\u003e all inved transactions\n\nYou seem to misunderstand the usecase.\nIf you send me a transaction, both of use are using our phones, then I need \nto be able to have immediate feedback on the transaction being broadcast on \nthe network.\nThis is not about zero-conf, this is simple seeing what is happening while \nit is happening.\n\nAdditionally, when the transaction that is meant for my wallet is broadcast, \nI want my SPV wallet to parse and check the actual transaction.\nIt is not just to see that *something* was actually send, but also to be \nable to see how much is being paid to me. Maybe If the transaction is marked \nas RBF-able, etc.\n\nReally basic usability: provide information to your users when you can, \nshould they want to, and by default on.\n-- \nTom Zander\nBlog: https://zander.github.io\nVlog: https://vimeo.com/channels/tomscryptochannel", "sig": "1e9520bc41960f24b8d86b914bf343dfe810e43c4322c4f0c7a3f81d8fa3d79bdd0137d6f559de29f5e9c16ce0ce2fe93c5e9d2bcb9a31c89b4d4c24fc3f6f2c" }