rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2014-01-10 📝 Original message:On Wed, Jan 08, 2014 at 02:20:57AM -0800, Jeremy Spilman wrote: > Thanks Peter for the paper! > > I'm just going to restate your 'simple explanation' to make sure I > got it... > > The payee publishes a public key of theirs, which will be a > long-standing identifier, public key = 'Q', corresponding private > key = 'd'. > > To pay them, payee generate a keypair, private key = 'e' public key > of 'P'. Publish 'P' in the transaction. > > The payer can calculate S = eQ, where S is a shared secret between > payer/payee. The payee calculates the same S as S = dP. So the payee > sees 'P' in a transaction, and multiplies by their private key, to > get S. > > Now that we have the shared secret, either side can calculate an > offset to Q which becomes the pay-to-address. When you say > BIP32-style derivation, Q' = H(S) + Q, does this mean Q + > SHA256(33-byte S)? I think that's correct, but my ECC math is a bit shakey... In any case, what's important is that you can derive a pubkey such that only the recipient has the privkey, and without knowledge of the shared secret you can't determine what the recipients master pubkey was. > A payee has to check each transaction (or every transaction of a > fixed prefix) with 'P', calculate Q' = Q + H(dP) and see if that > transaction pays to Q'. If the address matches, then the payee can > spend it with private key of d + H(dP). Yup, you're understanding matches mine. (no guarantee if my understanding is correct!) > One downside is that you have to hold your private key in memory > unencrypted in order to identify new payments coming in. So > stealth-addresses may not be suitable for receiving eCommerce > payments, since you can't implement a corresponding watch-only > wallet, e.g. there's no way to "direct-deposit into cold storage." Oh, sorry, I forgot to mention it in my first write-up but you can easily make stealth addresses include a second pubkey for the purpose of the communication that either isn't used in the scriptPubKey at all, or is part of a n-of-m multisig. (n>=2) Interestingly that also means you can give a third-party that key and out-source the effort of scanning the blockchain for you. -- 'peter'[:-1]@petertodd.org 00000000000000028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 685 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140110/f85268c9/attachment.sig>