{"type":"rich","version":"1.0","author_name":"npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727","author_url":"https://nostr.ae/npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-01-13\n📝 Original message:On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman \u003cjeremy at taplink.co\u003e wrote:\n\u003e \u003e I think for displaying the payment in the UI after it's been made via  \n\u003e PP, we have to fully\n\u003e \u003e support sending to a new standard address type anyway.\n\nOn Sun, 12 Jan 2014 10:26:18 -0800, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e Why? Showing an address is meaningless, especially if the user didn't  \n\u003e type it in or see\n\u003e it somewhere else. It's just an opaque random number, all putting it in  \n\u003e the UI can do is\n\u003e make it look scarier :)\n\u003e\n\u003e Part of the point of the payment protocol is it lets merchants provide  \n\u003e human readable text\n\u003e for transactions instead of addresses.\n\nOf course you're right, moving away from addresses is definitely part of  \nthe point of PP.\n\nOn Sun, 12 Jan 2014 13:18:33 -0800, Gavin Andresen  \n\u003cgavinandresen at gmail.com\u003e wrote:\n\u003e No, please. Make it easy for non-geeks, extend the payment protocol, or  \n\u003e we'll spend the next\n\u003e two years writing code that tries to ignore linebreaks and spaces and  \n\u003e changing \u003cinput\u003e in HTML\n\u003e forms to \u003ctextarea\u003e...\n\nAgreed, it's long enough to be even more problematic than usual. If the  \ngeneral consensus is that there should not even be a standardized address  \nform, then I can skip that entirely, and go straight to trying to extend  \nPP.\n\nIt's a given this will be implemented for Payment Protocol. The question  \nis whether it's also usable outside of PP.\n\nI was kind of imagining that we could encourage people to replace all  \ntheir static address text that live on Github pages, and README.me, and  \nforum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention  \ncould be to require only transporting xSTL addresses within a URI, even  \ngoing so far as to not support them copy/pasted. 101 characters is not  \nmuch longer (and sometimes shorter) than PaymentRequest URIs end up being.\n\nI think there are ways to make stealth addresses easy enough to use that  \npeople actually prefer using them for P2P payments which do not involve a  \nfull-stack merchant. In that case, if it was a PaymentRequest it would  \nalmost certainly not be signed, and would be more easily shared over email  \nor SMS as a URI than as a file attachment or, even worse, putting the  \nunsigned PR file up on a third-party server which probably won't do a good  \njob securing it.\n\n* PP Implementation Overview *\n\nThe basic PaymentRequest\u003ePaymentDetails is expecting 'output' containing  \none or more TxOuts with script and amount. I believe the general approach  \nis to put a fallback address into 'output' for backward compatibility, and  \nput Q and Q2 into an extension field.\n\nSo we add a new optional field to PaymentDetails which contains the one or  \ntwo PubKeys. Not sure if we want different protobuf tags, or if the  \ndifference in length of the value makes it obvious enough which approach  \nis being used;\n\n    optional bytes stealthOnePubKey = 1000\n    optional bytes stealthTwoPubKey = 1001\n\nor just\n\n    optional bytes stealth = 1000\n\n* User Interaction / Flow *\n\nLets follow this through from the user perspective, starting with what it  \nlooks like today. I'm having a hard time finding screenshots of what PP  \nlooks like in BitcoinQT, so I built from HEAD and using Gavin's  \nHandy-Dandy PaymentRequest Generator  \n(https://bitcoincore.org/~gavin/createpaymentrequest.php):\n\nScreenshots: http://imgur.com/a/k6j9D\n\nImage 1 - 'Send' screen after clicking a PR URI with a small transaction  \nand auto-calculated fee\nImage 2 - System Tray notification after clicking 'Send'\nImage 3 - Transaction List showing partially confirmed transaction\nImage 4 - Transactions details popup\n\nWe see 'Pay To' (Common Name from the cert) and 'Memo' on the Send screen.  \nThe System Tray notification popup and Transaction List shows just the  \naddress string. The 'Transaction details' window shows 'Merchant' which I  \nthink is the same as 'Pay To'. You also have 'Copy address' option in the  \nright-click menu.\n\nMemo seems not to be saved, or at least not visible in the UI after  \nsending a payment.\n\n* Transaction Display *\n\nThe address string is fairly pervasive, which is why I was originally  \nthinking it would make sense to implement all the address handling first,  \nso all those screens would continue to work as specified, without trying  \nto hack something different in those fields.\n\nWithout digging too far into the code, it looks like \"address\" displayed  \nis derived from the TxOut -- e.g. script.cpp:ExtractDestination. This  \ncould be a bit problematic depending on what we really want to show to the  \nuser -- the stealth multisig, or the pubkeys?\n\nPart of the point of stealth addresses is actually making them reusable.  \nSo if you're the originator of the payment, you might want the wallet to  \ntag that transaction somehow with the pubkeys used to generate it.\n\nAlso, ideally I think I would want multiple different stealth payments  \nwithin a single wallet to the same merchant / pubkeys to be identifiable  \nas such.\n\n* Sample Code *\n\nWill follow in another email, to be sent shortly!"}