Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2014-01-10 📝 Original message:On Wed, Jan 08, 2014 at ...

📅 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>;