public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jeremy Spilman" <jeremy@taplink.co>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Stealth Addresses
Date: Sun, 12 Jan 2014 02:33:02 -0800	[thread overview]
Message-ID: <op.w9kkxcityldrnw@laptop-air.hsd1.ca.comcast.net> (raw)
In-Reply-To: <20140110102037.GB25749@savin>

> 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.

Great point. Even if it's not a 3rd party, I think it's really important  
to be able to scan for transactions with a key which can't actually spend  
the funds.

The first approach is just one-pass ECDH. I think you're saying the second  
approach is two rounds of ECDH but re-using the same e/P (usually referred  
to as r/R in ECIES). I think this is safe, unlike reusing an ephemeral key  
for signing operations.

   Payee: Publish Q, Q2                     [d, d2 are privkeys, Q, Q2 are  
pubkeys]
   Payer: 1) Generate ephemeral key: e / P  [e is privkey, P is pubkey]
          2) S = e * Q                      [first shared secret]
          3) S2 = e * Q2                    [second shared secret, reusing  
'e']
          4) Q' = Q + H(S)                  [pay-to stealth address]
          5) Q2' = Q2 + H(S2)               [stealth 'marker']

   Watch: 1) Look for TxOut with OP_RETURN <P>
          2) Q2' = Q2 + H(d2 * P)
          3) Check for Q2' elsewhere in the Tx

S/MIME for example, allows reuse of the ephemeral keypair. When reusing an  
ephemeral keypair where A reuses (x, X) to encrypt different messages to  
more than one user, A should verify the static public keys to prevent  
small-subgroup attacks.[1][2]

Let's say you pay-to Q' and then Q2' value has to be somewhere else in the  
transaction. You could put it next to the shared P in OP_RETURN. OP_RETURN  
<P> <Q2'> would be 66 bytes.

But then Mallory could generate transactions with the right Q2' but with  
his own pubkey in Step 2 instead of Q. So your scanner would detect a  
payment, but you wouldn't be able to spend it, and Mallory could.

That's a good argument for putting Q2' in a 2-of-2 multisig so that  
pulling this trick would at least make the transaction unspendable for  
both parties, which may be good enough deterrent, but you're still going  
to want to check it against your 'd' before fulfilling a large order. Your  
online watch process could queue the matching transactions, which you  
could move to your offline machine, decrypt your key, and verify the  
transactions are spendable.

Now, you would need to get two pubkeys to the payer, throw in a prefix to  
help standardize it, and end up with addresses that could look like (for  
example):

xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX
tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba

Those addresses are 74 bytes:  
<Prefix><CompressedPubKey1><CompressedPubKey2><Checksum>

   xSTL Prefix = 0xC0CB9270
   tSTL Prefix = 0xB2E27D50
   NOTE: I do NOT have the corresponding privkeys for these four pubkeys!

Those just happened to be the first matching prefixes I found for 74 byte  
addresses. I could try to find ones which start with a specific byte if  
that's somehow better, like 0x04 to match BIP32.

Unfortunately, I don't think you can just derive a second public key from  
the first to keep the address shorter, and still keep the first private  
key secure, even if the second private key is stolen. You only get  
equivalent security as BIP32 public derivation, where you can't lose a  
child private key.

Do we also want xSTL (or whatever user friendly string) prefixes for  
single pubkey (41 byte) stealth addresses?

I'll wait a couple days for feedback, then I'll try to implement the  
following prototypes:

1) Pay to STL addresses
2) Watcher process to detect and queue STL payments for a given d2/Q2
3) Offline verifier to take output from Watcher and verify spendable given  
encrypted d/d2

Obviously extending QT directly for #1 would be ideal, I may even be able  
to do that since supporting a new address type should be fairly contained.  
But if not I'll punt to writing a node.js or python script which connects  
to bitcoind via RPC.

Thanks,
Jeremy

[1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols
       http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf

[2] - Validation of Elliptic Curve Public Keys
       http://www.iacr.org/archive/pkc2003/25670211/25670211.pdf




  parent reply	other threads:[~2014-01-12 10:33 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-06 12:03 [Bitcoin-development] Stealth Addresses Peter Todd
2014-01-08 10:20 ` Jeremy Spilman
2014-01-10 10:20   ` Peter Todd
2014-01-10 11:28     ` Drak
2014-01-10 12:00       ` Peter Todd
2014-01-12 10:33     ` Jeremy Spilman [this message]
2014-01-12 12:51       ` Mike Hearn
2014-01-12 18:20         ` Jeremy Spilman
2014-01-12 18:26           ` Mike Hearn
2014-01-13  9:13             ` Jeremy Spilman
2014-01-14 14:15               ` Peter Todd
2014-01-14 17:54                 ` Odinn Cyberguerrilla
2014-01-12 21:18       ` Gavin Andresen
2014-01-13  9:52         ` Gregory Maxwell
2014-01-13 10:39           ` Mike Hearn
2014-01-13 13:37             ` Roy Badami
2014-01-13 15:58               ` Mike Hearn
2014-01-13 20:11                 ` Roy Badami
2014-01-14 22:53                 ` Roy Badami
2014-01-15  0:19                   ` Drak
2014-01-15 20:22                     ` Ben Davenport
2014-01-15 20:38                       ` Gregory Maxwell
2014-01-15 20:44                         ` Jeff Garzik
2014-01-15 22:38                           ` [Bitcoin-development] Static addresses on chains encouraging address *RE* use Troy Benjegerdes
2014-01-15 23:01                           ` [Bitcoin-development] Stealth Addresses Mike Hearn
2014-01-15 23:04                           ` Roy Badami
2014-01-15 23:07                             ` Jeff Garzik
2014-01-15 23:17                               ` Roy Badami
2014-01-15 23:19                                 ` Roy Badami
2014-01-15 23:09                           ` [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses) Adam Back
2014-01-16  1:02                             ` Jeremy Spilman
2014-01-16  1:32                               ` Gregory Maxwell
2014-01-18 17:44                                 ` Troy Benjegerdes
2014-01-18 20:25                                   ` Christophe Biocca
2014-01-20 11:11                                   ` Peter Todd
2014-01-21  4:00                                 ` Jeremy Spilman
2014-01-24  9:17                                   ` Peter Todd
2014-01-16 11:42                               ` Adam Back
2014-01-16 18:19                                 ` Troy Benjegerdes
2014-01-16  0:05                           ` [Bitcoin-development] Stealth Addresses Jeremy Spilman
2014-01-16  0:10                             ` Gregory Maxwell
2014-01-16  0:24                             ` Mark Friedenbach
2014-01-16  0:44                             ` Eric Martindale
2014-01-16  6:26                               ` Gary Rowe
2014-01-16  9:48                                 ` Wladimir
2014-01-16  1:16                             ` Odinn Cyberguerrilla
2014-01-16 10:14                             ` Drak
2014-01-16 10:19                               ` Mike Hearn
2014-01-16 11:12                               ` [Bitcoin-development] reusable address privacy problems & fuzzy bait limitations (Re: Stealth Addresses) Adam Back
2014-01-16 21:28                             ` [Bitcoin-development] Stealth Addresses Peter Todd
2014-01-17  2:30                               ` Johnathan Corgan
2014-01-17  3:13                               ` Jeremy Spilman
2014-01-17  7:49                               ` Drak
2014-01-17  9:15                                 ` Mike Hearn
2014-01-17  9:19                                   ` Mark Friedenbach
2014-01-17  9:23                                   ` Natanael
2014-01-17  9:59                                   ` Drak
2014-01-17 20:16                                     ` Cameron Garnham
2014-01-17 14:46                                   ` Peter Todd
2014-01-17 19:21                                     ` Ben Davenport
2014-01-18  4:55                                       ` Alan Reiner
2014-01-18  5:09                                         ` Gregory Maxwell
2014-01-18 23:12                                           ` Jeremy Spilman
2014-01-18 23:50                                             ` Gregory Maxwell
2014-01-20 11:08                                             ` Peter Todd
2014-01-13 19:53               ` Roy Badami
2014-01-13 19:57                 ` Mike Hearn
2014-01-13 20:01                   ` Roy Badami
2014-01-13 19:40           ` Roy Badami
2014-01-13 19:44             ` Drak
2014-01-13 19:59               ` Alan Reiner
2014-01-13 20:10                 ` Gregory Maxwell
2014-01-13 20:15                   ` Peter Todd
2014-01-13 22:02                   ` Jeremy Spilman
2014-01-14 14:19                     ` Peter Todd
2014-01-14 19:12                       ` Jeremy Spilman
2014-01-14 20:48                         ` Peter Todd
2014-01-14 21:51                         ` Adam Back
2014-01-14 22:34                           ` Jeremy Spilman
2014-01-13 20:14                 ` Peter Todd
2014-01-13 20:41                   ` Alan Reiner
2014-01-13 20:47                     ` Gregory Maxwell
2014-01-13 21:02                     ` Roy Badami
2014-01-13 21:15                       ` Alan Reiner
2014-01-13 21:27                         ` Peter Todd
     [not found]                           ` <op.w9ne31oqyldrnw@laptop-air.hsd1.ca.comcast.net>
2014-01-14 12:10                             ` Peter Todd
2014-03-06 12:23 ` Dan Carter
     [not found] <mailman.417890.1389952750.21953.bitcoin-development@lists.sourceforge.net>
2014-01-17 12:16 ` joseph

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=op.w9kkxcityldrnw@laptop-air.hsd1.ca.comcast.net \
    --to=jeremy@taplink.co \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox