{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-12-01\n📝 Original message:On Sun, Dec 01, 2013 at 06:19:14PM +0100, Mike Hearn wrote:\n\u003e \u003e Both can be combined into adapting the current generic messages (\"This\n\u003e \u003e payment should become spendable shortly\" for incoming and \"This payment\n\u003e \u003e has not been transmitted yet\" for outgoing transactions). \n\u003e \n\u003e What would the new messages say?\n\u003e \n\u003e We need to get away from the notion of senders attaching fees anyway. This is the wrong way around because it’s the recipient who cares about double spending risk, not the sender. That’s why merchants keep running into issues with people attaching zero fees. Of course they attach zero fees. They know they aren’t going to double spend. It’s the merchant who cares about getting the security against that.\n\u003e \n\u003e The UI for sending money should end up dead simple - no mention of fees anywhere, IMO.\n\u003e \n\u003e The UI for receiving money could be a bit more complicated but even then - I think if ordinary people using smartphone wallets are having to think about how quickly they want their transaction to confirm and adjust fees, etc on the receiving side then we’re getting dangerously close to the usability failure zone.\n\u003e \n\u003e Unfortunately we lack the protocol pieces to get the right UI here :( Someone needs to sit down and figure out what the UI *should* look like, in the ideal world, and then work backwards to figure out what needs to be done to get us there.\n\u003e \n\u003e \u003e For outgoing transactions, if it is very clear that they're never going\n\u003e \u003e to be confirmed, I'd like to see a \"Revoke\" button.\n\u003e \n\u003e Disagree. There should never be any cases in which a transaction doesn’t confirm. Period. I know there have been bugs with bitcoinj that could cause this in the past, but they were bugs and they got fixed/will get fixed.\n\u003e \n\u003e Settlement failure is just unacceptable and building a UI around the possibility will just encourage people to think of it as normal, when it should not be so.\n\nBitcoin is and always will be limited in capacity - transactions may not\nconfirm in a reasonable about of time because of high-demand and/or DoS\nattacks. Giving senders and/or receivers the ability to increase fees\nafter the fact is the only way you'll ever be able to deal with these\nsituations. Of course, in those situations revoke isn't going to be 100%\nreliable until the txins get spent elsewhere, but that just indicates\nthe UI problem is around that kind of functionality is subtle.\n\n\nre: merchants paying tx fees, child-pays-for-parent is inefficient, and\nmicropayments direct to miners isn't implemented. (though I did write up\na rough sketch of how to do that in a decentralized fashion on\n#bitcoin-dev) Propose something concrete.\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131201/daa712d9/attachment.sig\u003e"}