path: root/58/a6186fa67c27e9fc3978f0155c8023b71e15c8

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1W2KWH-000591-Eu
	for bitcoin-development@lists.sourceforge.net;
	Sun, 12 Jan 2014 12:52:01 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.174 as permitted sender)
	client-ip=209.85.214.174; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f174.google.com; 
Received: from mail-ob0-f174.google.com ([209.85.214.174])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1W2KWF-00004q-Ub
	for bitcoin-development@lists.sourceforge.net;
	Sun, 12 Jan 2014 12:52:01 +0000
Received: by mail-ob0-f174.google.com with SMTP id wo20so11175obc.33
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 12 Jan 2014 04:51:54 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.58.36 with SMTP id n4mr16273007oeq.51.1389531114503; Sun,
	12 Jan 2014 04:51:54 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.99.112 with HTTP; Sun, 12 Jan 2014 04:51:54 -0800 (PST)
In-Reply-To: <op.w9kkxcityldrnw@laptop-air.hsd1.ca.comcast.net>
References: <20140106120338.GA14918@savin>
	<op.w9c5o7vgyldrnw@laptop-air.hsd1.ca.comcast.net>
	<20140110102037.GB25749@savin>
	<op.w9kkxcityldrnw@laptop-air.hsd1.ca.comcast.net>
Date: Sun, 12 Jan 2014 13:51:54 +0100
X-Google-Sender-Auth: o87o6pzvy8O3ZyamnziOblBVYtE
Message-ID: <CANEZrP0Np_FGhw=m6OffijByzz9r4D2AA78jCkzh=NZh=xrbjQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeremy Spilman <jeremy@taplink.co>
Content-Type: multipart/alternative; boundary=089e01538baa7c04dc04efc56ca5
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1W2KWF-00004q-Ub
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Stealth Addresses
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 12 Jan 2014 12:52:01 -0000

--089e01538baa7c04dc04efc56ca5
Content-Type: text/plain; charset=UTF-8

You can always just extend the payment protocol with the new fields as
well, vs making very long addresses. If this technique can be made to work
well, it would have applicability in both fixed textual address context,
and for a fixed/upload-once payment protocol file. That has the advantage
of backwards compatibility as well - the new addresses would not be
clickable or acceptable by old wallets, but with the payment protocol you
can always craft a bitcoin URI that contains a regular current style
address, and a link to a fixed payment protocol file (uploaded to a
pastebin type site), and modern wallets would ignore the address and use
the ECDH based system instead.



On Sun, Jan 12, 2014 at 11:33 AM, Jeremy Spilman <jeremy@taplink.co> wrote:

> > 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
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--089e01538baa7c04dc04efc56ca5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You can always just extend the payment protocol with the n=
ew fields as well, vs making very long addresses. If this technique can be =
made to work well, it would have applicability in both fixed textual addres=
s context, and for a fixed/upload-once payment protocol file. That has the =
advantage of backwards compatibility as well - the new addresses would not =
be clickable or acceptable by old wallets, but with the payment protocol yo=
u can always craft a bitcoin URI that contains a regular current style addr=
ess, and a link to a fixed payment protocol file (uploaded to a pastebin ty=
pe site), and modern wallets would ignore the address and use the ECDH base=
d system instead.<div>
<br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">On Sun, Jan 12, 2014 at 11:33 AM, Jeremy Spilman <span dir=3D"ltr">&lt;<=
a href=3D"mailto:jeremy@taplink.co" target=3D"_blank">jeremy@taplink.co</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">&gt; Oh, sorry, I forgot t=
o mention it in my first write-up but you can<br>
&gt; easily make stealth addresses include a second pubkey for the purpose =
of<br>
&gt; the communication that either isn&#39;t used in the scriptPubKey at al=
l, or<br>
&gt; is part of a n-of-m multisig. (n&gt;=3D2) Interestingly that also mean=
s you<br>
&gt; can give a third-party that key and out-source the effort of scanning<=
br>
&gt; the blockchain for you.<br>
<br>
</div>Great point. Even if it&#39;s not a 3rd party, I think it&#39;s reall=
y important<br>
to be able to scan for transactions with a key which can&#39;t actually spe=
nd<br>
the funds.<br>
<br>
The first approach is just one-pass ECDH. I think you&#39;re saying the sec=
ond<br>
approach is two rounds of ECDH but re-using the same e/P (usually referred<=
br>
to as r/R in ECIES). I think this is safe, unlike reusing an ephemeral key<=
br>
for signing operations.<br>
<br>
=C2=A0 =C2=A0Payee: Publish Q, Q2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [d, d2 are privkeys, Q, Q2 are<br>
pubkeys]<br>
=C2=A0 =C2=A0Payer: 1) Generate ephemeral key: e / P =C2=A0[e is privkey, P=
 is pubkey]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2) S =3D e * Q =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[first shared secret]<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3) S2 =3D e * Q2 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[second shared secret, reus=
ing<br>
&#39;e&#39;]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4) Q&#39; =3D Q + H(S) =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[pay-to stealth address]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5) Q2&#39; =3D Q2 + H(S2) =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [stealth &#39;marker&#39;]<br>
<br>
=C2=A0 =C2=A0Watch: 1) Look for TxOut with OP_RETURN &lt;P&gt;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Q2&#39; =3D Q2 + H(d2 * P)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3) Check for Q2&#39; elsewhere in the Tx=
<br>
<br>
S/MIME for example, allows reuse of the ephemeral keypair. When reusing an<=
br>
ephemeral keypair where A reuses (x, X) to encrypt different messages to<br=
>
more than one user, A should verify the static public keys to prevent<br>
small-subgroup attacks.[1][2]<br>
<br>
Let&#39;s say you pay-to Q&#39; and then Q2&#39; value has to be somewhere =
else in the<br>
transaction. You could put it next to the shared P in OP_RETURN. OP_RETURN<=
br>
&lt;P&gt; &lt;Q2&#39;&gt; would be 66 bytes.<br>
<br>
But then Mallory could generate transactions with the right Q2&#39; but wit=
h<br>
his own pubkey in Step 2 instead of Q. So your scanner would detect a<br>
payment, but you wouldn&#39;t be able to spend it, and Mallory could.<br>
<br>
That&#39;s a good argument for putting Q2&#39; in a 2-of-2 multisig so that=
<br>
pulling this trick would at least make the transaction unspendable for<br>
both parties, which may be good enough deterrent, but you&#39;re still goin=
g<br>
to want to check it against your &#39;d&#39; before fulfilling a large orde=
r. Your<br>
online watch process could queue the matching transactions, which you<br>
could move to your offline machine, decrypt your key, and verify the<br>
transactions are spendable.<br>
<br>
Now, you would need to get two pubkeys to the payer, throw in a prefix to<b=
r>
help standardize it, and end up with addresses that could look like (for<br=
>
example):<br>
<br>
xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrf=
C3pDimfTWMkiUb7x3jX3J26JSX<br>
tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK=
8EwVo1jdjxNDFNDWxhnQiAy4ba<br>
<br>
Those addresses are 74 bytes:<br>
&lt;Prefix&gt;&lt;CompressedPubKey1&gt;&lt;CompressedPubKey2&gt;&lt;Checksu=
m&gt;<br>
<br>
=C2=A0 =C2=A0xSTL Prefix =3D 0xC0CB9270<br>
=C2=A0 =C2=A0tSTL Prefix =3D 0xB2E27D50<br>
=C2=A0 =C2=A0NOTE: I do NOT have the corresponding privkeys for these four =
pubkeys!<br>
<br>
Those just happened to be the first matching prefixes I found for 74 byte<b=
r>
addresses. I could try to find ones which start with a specific byte if<br>
that&#39;s somehow better, like 0x04 to match BIP32.<br>
<br>
Unfortunately, I don&#39;t think you can just derive a second public key fr=
om<br>
the first to keep the address shorter, and still keep the first private<br>
key secure, even if the second private key is stolen. You only get<br>
equivalent security as BIP32 public derivation, where you can&#39;t lose a<=
br>
child private key.<br>
<br>
Do we also want xSTL (or whatever user friendly string) prefixes for<br>
single pubkey (41 byte) stealth addresses?<br>
<br>
I&#39;ll wait a couple days for feedback, then I&#39;ll try to implement th=
e<br>
following prototypes:<br>
<br>
1) Pay to STL addresses<br>
2) Watcher process to detect and queue STL payments for a given d2/Q2<br>
3) Offline verifier to take output from Watcher and verify spendable given<=
br>
encrypted d/d2<br>
<br>
Obviously extending QT directly for #1 would be ideal, I may even be able<b=
r>
to do that since supporting a new address type should be fairly contained.<=
br>
But if not I&#39;ll punt to writing a node.js or python script which connec=
ts<br>
to bitcoind via RPC.<br>
<br>
Thanks,<br>
Jeremy<br>
<br>
[1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://www.math.uwaterloo.ca/~ajmenez=
e/publications/ephemeral.pdf" target=3D"_blank">http://www.math.uwaterloo.c=
a/~ajmeneze/publications/ephemeral.pdf</a><br>
<br>
[2] - Validation of Elliptic Curve Public Keys<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://www.iacr.org/archive/pkc2003/2=
5670211/25670211.pdf" target=3D"_blank">http://www.iacr.org/archive/pkc2003=
/25670211/25670211.pdf</a><br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
CenturyLink Cloud: The Leader in Enterprise Cloud Services.<br>
Learn Why More Businesses Are Choosing CenturyLink Cloud For<br>
Critical Workloads, Development Environments &amp; Everything In Between.<b=
r>
Get a Quote or Start a Free Trial Today.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D119420431&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D119420431&amp;iu=3D/4140/ostg.clktrk</a><br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>

--089e01538baa7c04dc04efc56ca5--