{"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:2014-01-14\n📝 Original message:On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote:\n\u003e It's a given this will be implemented for Payment Protocol. The question  \n\u003e is whether it's also usable outside of PP.\n\nI think what stealth addresses is showing is that the concept of an\naddress being \"instructions on how to generate a txout/tx that results\nin me getting Bitcoins\" is actually quite valuable; it and\nBIP32-derivation addresses with chaincodes are pretty clear cases where\njust replacing address with scriptPubKey isn't sufficient.\n\n\u003e I was kind of imagining that we could encourage people to replace all  \n\u003e their static address text that live on Github pages, and README.me, and  \n\u003e forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention  \n\u003e could be to require only transporting xSTL addresses within a URI, even  \n\u003e going so far as to not support them copy/pasted. 101 characters is not  \n\u003e much longer (and sometimes shorter) than PaymentRequest URIs end up being.\n\nYeah, I don't see anything wrong with stealth addresses whatever length\nthey wind up being. It's a good intermediate step, and without them\npeople will just pass around unsigned payment requests and other stuff.\n\n\u003e I think there are ways to make stealth addresses easy enough to use that  \n\u003e people actually prefer using them for P2P payments which do not involve a  \n\u003e full-stack merchant. In that case, if it was a PaymentRequest it would  \n\u003e almost certainly not be signed, and would be more easily shared over email  \n\u003e or SMS as a URI than as a file attachment or, even worse, putting the  \n\u003e unsigned PR file up on a third-party server which probably won't do a good  \n\u003e job securing it.\n\nAt the DarkWallet hackathon we had discussed how to integrate stealth\naddresses into OpenPGP keys as a new user id type for instance, and\nsimilarly into x.509 certs.\n\nThe big advantage here is the identity of *who* you are paying is\nimportant, not just \"I got this signed payment request\". Basically the\nconcept becomes \"identity signed payment address\" and the signature\nbinding the identity to the address is a one time and offline thing; an\nissue with the payment protocol as it stands is that it encourages\nsigning keys to be kept online to issue payment requests. If you have a\nscheme where the private keys that bound the identity to the address can\nbe kept offline you're much better off, because the attacker can only\ncreate a fake payment request, they can't divert the funds to\nthemselves.\n\nSo with that in mind, I strongly suggest sticking with defining a\nreasonable stealth address spec. But when you do, keep in mind that you\nmay want to upgrade it in the future, preferably in a backwards\ncompatible way. Also, it shouldn't be limited to exactly 2-of-2\nCHECKMULTISIG, there's no reason why n and m can't be picked as needed.\nSure, it means the addresses are not fixed length, but for something\nthat is mostly an internal detail and only occasionally visible to\nadvanced users, I see no issues there.\n\nAlong those lines: what would a BIP32 chain code address look like? What\nhappens when you want to use that with a multisig-protected wallet?\n\n\u003e * PP Implementation Overview *\n\u003e \n\u003e The basic PaymentRequest\u003ePaymentDetails is expecting 'output' containing  \n\u003e one or more TxOuts with script and amount. I believe the general approach  \n\u003e is to put a fallback address into 'output' for backward compatibility, and  \n\u003e put Q and Q2 into an extension field.\n\u003e \n\u003e So we add a new optional field to PaymentDetails which contains the one or  \n\u003e two PubKeys. Not sure if we want different protobuf tags, or if the  \n\u003e difference in length of the value makes it obvious enough which approach  \n\u003e is being used;\n\u003e \n\u003e     optional bytes stealthOnePubKey = 1000\n\u003e     optional bytes stealthTwoPubKey = 1001\n\nI think you're missing the bigger picture here, not least of which is\nthat backwards compatibility is a bit of a misnomer for an unreleased\nstandard. :)\n\nWhy put this into the PaymentDetails? That a stealth address is to be\nused for the payment is a property of the outputs being requested, not\nthe payment itself. We're better off if that goes into the Output\nmessage, and further more it suggests that the Output message shouldn't\ncontain raw scriptPubKey's but rather addresses. After all, IsStandard()\nmeans we have to inspect the scriptPubKey to see if we can even pay to\nwhat the sender is requesting.\n\nOnce you establish that it's addresses that Outputs specify, then it's\neasy enough to make a stealth address type, or a BIP32-chain-code\naddress type, or whatever else comes up in the future.\n\n\n\u003e Also, ideally I think I would want multiple different stealth payments  \n\u003e within a single wallet to the same merchant / pubkeys to be identifiable  \n\u003e as such.\n\nAgreed.\n\n-- \n'peter'[:-1]@petertodd.org\n00000000bda8ab55740699711a11572c4eec9dc9f714e4896559aac310a115ff\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 685 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140114/95b840b6/attachment.sig\u003e"}