{"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-10\n📝 Original message:On Wed, Jan 08, 2014 at 02:20:57AM -0800, Jeremy Spilman wrote:\n\u003e Thanks Peter for the paper!\n\u003e \n\u003e I'm just going to restate your 'simple explanation' to make sure I\n\u003e got it...\n\u003e \n\u003e The payee publishes a public key of theirs, which will be a\n\u003e long-standing identifier, public key = 'Q', corresponding private\n\u003e key = 'd'.\n\u003e \n\u003e To pay them, payee generate a keypair, private key = 'e' public key\n\u003e of 'P'. Publish 'P' in the transaction.\n\u003e \n\u003e The payer can calculate S = eQ, where S is a shared secret between\n\u003e payer/payee. The payee calculates the same S as S = dP. So the payee\n\u003e sees 'P' in a transaction, and multiplies by their private key, to\n\u003e get S.\n\u003e \n\u003e Now that we have the shared secret, either side can calculate an\n\u003e offset to Q which becomes the pay-to-address. When you say\n\u003e BIP32-style derivation, Q' = H(S) + Q, does this mean Q +\n\u003e SHA256(33-byte S)?\n\nI think that's correct, but my ECC math is a bit shakey... In any case,\nwhat's important is that you can derive a pubkey such that only the\nrecipient has the privkey, and without knowledge of the shared secret\nyou can't determine what the recipients master pubkey was.\n\n\u003e A payee has to check each transaction (or every transaction of a\n\u003e fixed prefix) with 'P', calculate Q' = Q + H(dP) and see if that\n\u003e transaction pays to Q'. If the address matches, then the payee can\n\u003e spend it with private key of d + H(dP).\n\nYup, you're understanding matches mine. (no guarantee if my\nunderstanding is correct!)\n\n\u003e One downside is that you have to hold your private key in memory\n\u003e unencrypted in order to identify new payments coming in. So\n\u003e stealth-addresses may not be suitable for receiving eCommerce\n\u003e payments, since you can't implement a corresponding watch-only\n\u003e wallet, e.g. there's no way to \"direct-deposit into cold storage.\"\n\nOh, sorry, I forgot to mention it in my first write-up but you can\neasily make stealth addresses include a second pubkey for the purpose of\nthe communication that either isn't used in the scriptPubKey at all, or\nis part of a n-of-m multisig. (n\u003e=2) Interestingly that also means you\ncan give a third-party that key and out-source the effort of scanning\nthe blockchain for you.\n\n-- \n'peter'[:-1]@petertodd.org\n00000000000000028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857\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/20140110/f85268c9/attachment.sig\u003e"}