path: root/b8/8e03068c1ef8bea09d67c2efbe28b936366d66

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jeremy@taplink.co>) id 1W2iE8-0003FV-Bv
	for bitcoin-development@lists.sourceforge.net;
	Mon, 13 Jan 2014 14:10:52 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of taplink.co
	designates 50.117.27.232 as permitted sender)
	client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
	helo=mail.taplink.co; 
Received: from mail.taplink.co ([50.117.27.232])
	by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76)
	id 1W2iE6-0008OR-S9 for bitcoin-development@lists.sourceforge.net;
	Mon, 13 Jan 2014 14:10:52 +0000
Received: from laptop-air.hsd1.ca.comcast.net ([192.168.168.135]) by
	mail.taplink.co ; Mon, 13 Jan 2014 06:18:39 -0800
Content-Type: multipart/alternative; boundary=----------quLNl5KWjFmOZozi4Nm4ts
To: "Mike Hearn" <mike@plan99.net>
References: <op.w9mb5dv0yldrnw@laptop-air.hsd1.ca.comcast.net>
	<CANEZrP38DsYP4KRk1Jz_hiMrP_ZPCj6=TDKmr-t-r2BJRMjDSQ@mail.gmail.com>
Date: Mon, 13 Jan 2014 06:10:14 -0800
MIME-Version: 1.0
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.w9mpncluyldrnw@laptop-air.hsd1.ca.comcast.net>
In-Reply-To: <CANEZrP38DsYP4KRk1Jz_hiMrP_ZPCj6=TDKmr-t-r2BJRMjDSQ@mail.gmail.com>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.135#jeremy@taplink.co#465
X-Spam-Score: -0.7 (/)
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 SPF_PASS               SPF: sender matches SPF record
	-0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain 1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	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: 1W2iE6-0008OR-S9
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Stealth Payments - Sample Code / Proof of
	Concept
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: Mon, 13 Jan 2014 14:10:52 -0000

------------quLNl5KWjFmOZozi4Nm4ts
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On Mon, 13 Jan 2014 03:18:28 -0800, Mike Hearn <mike@plan99.net> wrote:

> Cool!
>
> On Mon, Jan 13, 2014 at 10:18 AM, Jeremy Spilman <jeremy@taplink.co>  
> wrote:
>> I spent 1BTC on TestNet to a stealth address...
>>    TxID:  
>> df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c
>
> ... but can you redeem it?

But of course!

Every time the test runs it makes a new ephemeral key, so I wrote a  
separate test with hard-coded values from the block chain (as it would be  
in real-life) to create a redeeming Tx. I've added the RedeemStealth code  
to the Gist.

It sent successfully using sendrawtransaction, TxID:  
ed92364d2b6f6528dea32dbf6c4d5d6291b601aff1ddb4eeb124d003c7c7ff07

I'm self mining since no one else seems to be on TestNet this time of  
night... going to catch some sleep, hopefully by the time I wake up it'll  
be on the chain.


>> Code which generated this transaction is here:
>> https://gist.github.com/jspilman/8396495
>
> That's rather interesting code. Is this using a private C# bitcoin  
> implementation?

Indeed it is. One day I may publish the libraries, but they aren't doing  
anything particularly special under the hood, just the standard  
Bitcoin/EC/BIP32 stuff and using OpenSSL under the hood instead of the  
more typical BouncyCastle.

I just tried to keep things extremely concise in the APIs. Hopefully all  
the function calls are obvious what they are doing. Since there's no  
actual wallet behind it, the code to setup the inputs is a bit annoying,  
but actually building and signing transactions is super clean.


>> I wonder if the 0BTC OP_RETURN transactions should be hidden from the
>> Transaction List?
>
> Yes, of course. The transaction list should just say something like
>
>    "Payment received from Jeremy,  0.1 BTC"

In this case I'm just looking at the payee wallet, but yes, "Payment set  
to Jeremy" should be possible, with the name coming from the CN.

>
>> Maybe the simple way to punt on this is to just show 'Merchant' in the
>> address column if it is available and an address is not.
>
> I am surprised it's not already the case! Though "merchant" is perhaps a  
> bit biased as a name, internally it perhaps should just be called  
> "Recipient". >There's no requirement for you to be a merchant to create  
> payment protocol requests.

Yeah, right now for PaymentProtocol fulfilled payments, on the payer's  
Transaction List, it shows the address in the 'Address' column, but if you  
right-click and look at 'Transaction details' you will see something like:


    Status: 42 confirmations
    Date: 1/12/2014 21:07
    To: mrhz5ZgSF3C1BSdyCKt3gEdhKoRL5BNfJV
    Debit: -0.10 BTC
    Net amount: -0.10 BTC
    Transaction ID:  
93c50347e35062a3501fcea15d1a22ace8d1b059affb9913fc9e7df4e7d6a00b-000
    Merchant: www.bitcoincore.org



I agree 'Merchant' might not be the best name, especially since when  
you're making the payment the field is labeled simply 'Pay To'.



But I think we agree, why show 'mrhz5ZgSF3C1BSdyCKt3gEdhKoRL5BNfJV' in the  
transaction list instead of just "Paid To: www.bitcoincore.org" and then  
perhaps the Memo field could be stuck under 'Transaction details', instead  
of losing that important bit of info.

>
>> I can probably make the necessary changes to IsMine, but I don't know
>> where we should keep 'd2'/'Q2' unencrypted so it's available for doing  
>> the
>> necessary tests, but has no chance of ever be used as a stand-alone
>> private key?
>
> The wallet format would need extending.
>
> I'd feel a lot more comfortable if the protocol was reviewed by a  
> professional cryptographer though. I think think Gregory already brought  
> up an issue >to do with people able to detect such payments by testing  
> if decrypted values are points on the curve, or something like that.

Not sure I follow that, will look forward to hearing more about it.

The only risk I know of is that there are checks in theory that you would  
do on Q1/Q2, but since the payee is the one generating Q1/Q2 they would  
literally be attacking themselves. I referenced two papers in a prior  
email specifically on reusing ephemeral keys in ECDH, and the validation  
you need to do on Q1/Q2 when re-using an ephemeral key to send two  
messages to two different pubKeys. I think the idea of checking the  
pubKeys when re-using ephemeral keys is more when the pubKeys are under  
the attackers control. But the validation is not complicated, and I'll see  
if I can add it tomorrow.

It would be good to fully understand how a possible small-group attack  
would work...  This is a bit of guess-work on my part:

    If a payee managed to foot-shoot themselves with a bad Q2 pubKey, then  
gives out d2/Q2 to a scanning service run by Mallory...

    Mallory has d2/Q2, given P from a transaction, he calculates S2 (as  
usual):

       byte[] S2 = EC.DH(d2, P);

    But with the small sub-group attack with Q2 he can learn 'e' (the  
ephemeral private key) used:

       byte[] S2 = EC.DH(e, Q2);

    and from that he can calculate S1 directly, when he should only know S2.

       byte[] S1 = EC.DH(e, Q1);

So does that mean Mallory can find 'd1'? It looks like you would need  
another small sub-group attack on P, the ephemeral public key, so another  
key the attacker doesn't control which would have to randomly be bad.

       byte[] S1 = EC.DH(d1, P);

But I'm definitely not a professional cryptographer. Perhaps Matthew Green  
might be a good candidate to review this?

AND YAY, my stealth redemption Tx just went through, goodnight :-)  
http://blockexplorer.com/testnet/tx/df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c#o0
------------quLNl5KWjFmOZozi4Nm4ts
Content-Type: multipart/related; boundary=----------quLNl5KWjFmOZorIKGl4Bq

------------quLNl5KWjFmOZorIKGl4Bq
Content-Type: text/html; charset=iso-8859-15
Content-ID: <op.1389622214045.61b3b5665d6b32ce@192.168.168.135>
Content-Transfer-Encoding: Quoted-Printable

<!DOCTYPE html><html><head>
<style type=3D"text/css">body { font-family:'Times New Roman'; font-size=
:13px}</style>
</head>
<body>On Mon, 13 Jan 2014 03:18:28 -0800, Mike Hearn &lt;mike@plan99.net=
&gt; wrote:<br><br><blockquote style=3D"margin: 0 0 0.80ex; border-left:=
 #0000FF 2px solid; padding-left: 1ex"><div dir=3D"ltr">Cool!<div><br></=
div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, Jan 13=
, 2014 at 10:18 AM, Jeremy Spilman <span dir=3D"ltr">&lt;<a href=3D"mail=
to: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=
:1px #ccc solid;padding-left:1ex">I spent 1BTC on TestNet to a stealth a=
ddress...<br>
&nbsp; &nbsp; TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01=
a18ea4ed8b4c<br></blockquote><div><br></div><div>... but can you redeem =
it?</div></div></div></div></blockquote><div><br></div><div>But of cours=
e!</div><div><br></div><div>Every time the test runs it makes a new ephe=
meral key, so I wrote a separate test with hard-coded values from the bl=
ock chain (as it would be in real-life) to create a redeeming Tx. I've a=
dded the RedeemStealth code to the Gist.</div><div><br></div><div>It sen=
t successfully using sendrawtransaction, TxID: ed92364d2b6f6528dea32dbf6=
c4d5d6291b601aff1ddb4eeb124d003c7c7ff07</div><div><br></div><div>I'm sel=
f mining since no one else seems to be on TestNet this time of night... =
going to catch some sleep, hopefully by the time I wake up it'll be on t=
he chain.</div><div><br></div><div>&nbsp;</div><blockquote style=3D"marg=
in: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
Code which generated this transaction is here:<br>
<a href=3D"https://gist.github.com/jspilman/8396495" target=3D"_blank">h=
ttps://gist.github.com/jspilman/8396495</a></blockquote><div><br></div><=
div>That's rather interesting code. Is this using a private C# bitcoin i=
mplementation?</div></div></div></div></blockquote><div><br></div><div>I=
ndeed it is. One day I may publish the libraries, but they aren't doing =
anything particularly special under the hood, just the standard Bitcoin/=
EC/BIP32 stuff and using OpenSSL under the hood instead of the more typi=
cal BouncyCastle.</div><div><br></div><div>I just tried to keep things e=
xtremely concise in the APIs. Hopefully all the function calls are obvio=
us what they are doing. Since there's no actual wallet behind it, the co=
de to setup the inputs is a bit annoying, but actually building and sign=
ing transactions is super clean.</div><div><br></div><div>&nbsp;</div><b=
lockquote style=3D"margin: 0 0 0.80ex; border-left: #0000FF 2px solid; p=
adding-left: 1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wonder if the 0BTC =
OP_RETURN transactions should be hidden from the<br>
Transaction List?<br></blockquote><div><br></div><div>Yes, of course. Th=
e transaction list should just say something like</div><div><br></div><d=
iv>&nbsp; &nbsp; "Payment received from Jeremy, &nbsp;0.1 BTC"</div></di=
v></div></div></blockquote><div><br></div><div>In this case I'm just loo=
king at the payee wallet, but yes, "Payment set to Jeremy" should be pos=
sible, with the name coming from the CN.</div><div><br></div><blockquote=
 style=3D"margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-le=
ft: 1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><div><br></div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">Maybe the simple way to punt on this i=
s to just show 'Merchant' in the<br>
address column if it is available and an address is not.</blockquote><di=
v><br></div><div>I am surprised it's not already the case! Though "merch=
ant" is perhaps a bit biased as a name, internally it perhaps should jus=
t be called "Recipient". There's no requirement for you to be a merchant=
 to create payment protocol requests.</div></div></div></div></blockquot=
e><div><br></div><div>Yeah, right now for PaymentProtocol fulfilled paym=
ents, on the payer's Transaction List, it shows the address in the 'Addr=
ess' column, but if you right-click and look at 'Transaction details' yo=
u will see something like:</div><div><br></div><div>
<p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-=
right:0px; -qt-block-indent:0; text-indent:0px;"><span style=3D" font-fa=
mily:'verdana, arial, helvetica, sans-serif'; font-weight:600;">&nbsp; &=
nbsp;Status:</span><span style=3D" font-family:'verdana, arial, helvetic=
a, sans-serif';"> 42 confirmations<br></span><span style=3D" font-family=
:'verdana, arial, helvetica, sans-serif'; font-weight:600;">&nbsp; &nbsp=
;Date:</span><span style=3D" font-family:'verdana, arial, helvetica, san=
s-serif';"> 1/12/2014 21:07<br></span><span style=3D" font-family:'verda=
na, arial, helvetica, sans-serif'; font-weight:600;">&nbsp; &nbsp;To:</s=
pan><span style=3D" font-family:'verdana, arial, helvetica, sans-serif';=
"> mrhz5ZgSF3C1BSdyCKt3gEdhKoRL5BNfJV<br></span><span style=3D" font-fam=
ily:'verdana, arial, helvetica, sans-serif'; font-weight:600;">&nbsp; &n=
bsp;Debit:</span><span style=3D" font-family:'verdana, arial, helvetica,=
 sans-serif';"> -0.10 BTC<br></span><span style=3D" font-family:'verdana=
, arial, helvetica, sans-serif'; font-weight:600;">&nbsp; &nbsp;Net amou=
nt:</span><span style=3D" font-family:'verdana, arial, helvetica, sans-s=
erif';"> -0.10 BTC<br></span><span style=3D" font-family:'verdana, arial=
, helvetica, sans-serif'; font-weight:600;">&nbsp; &nbsp;Transaction ID:=
</span><span style=3D" font-family:'verdana, arial, helvetica, sans-seri=
f';"> 93c50347e35062a3501fcea15d1a22ace8d1b059affb9913fc9e7df4e7d6a00b-0=
00<br></span><span style=3D" font-family:'verdana, arial, helvetica, san=
s-serif'; font-weight:600;">&nbsp; &nbsp;Merchant:</span><span style=3D"=
 font-family:'verdana, arial, helvetica, sans-serif';"> www.bitcoincore.=
org<br></span></p><p style=3D" margin-top:0px; margin-bottom:0px; margin=
-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"><span=
 style=3D" font-family:'verdana, arial, helvetica, sans-serif';"><br></s=
pan></p><p style=3D" margin-top:0px; margin-bottom:0px; margin-left:0px;=
 margin-right:0px; -qt-block-indent:0; text-indent:0px;"><span style=3D"=
 font-family:'verdana, arial, helvetica, sans-serif';">I agree 'Merchant=
' might not be the best name, especially since when you're making the pa=
yment the field is labeled&nbsp;simply 'Pay To'.<br></span></p><p style=3D=
" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; =
-qt-block-indent:0; text-indent:0px;"><span style=3D" font-family:'verda=
na, arial, helvetica, sans-serif';"><br></span></p><p style=3D" margin-t=
op:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-=
indent:0; text-indent:0px;"><span style=3D" font-family:'verdana, arial,=
 helvetica, sans-serif';">But I think we agree, why show '</span><span s=
tyle=3D" font-family:'verdana, arial, helvetica, sans-serif';">mrhz5ZgSF=
3C1BSdyCKt3gEdhKoRL5BNfJV' in the transaction list instead of just&nbsp;=
</span><span style=3D" font-family:'verdana, arial, helvetica, sans-seri=
f';">"Paid To: </span><span style=3D" font-family:'verdana, arial, helve=
tica, sans-serif';">www.bitcoincore.org" and then perhaps the Memo field=
 could be stuck under 'Transaction details', instead of losing that impo=
rtant bit of info.</span><span style=3D" font-family:'verdana, arial, he=
lvetica, sans-serif';"><br></span></p></div><div><br></div><blockquote s=
tyle=3D"margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left=
: 1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote">
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can probably make t=
he necessary changes to IsMine, but I don't know<br>
where we should keep 'd2'/'Q2' unencrypted so it's available for doing t=
he<br>
necessary tests, but has no chance of ever be used as a stand-alone<br>
private key?<br></blockquote><div><br></div><div>The wallet format would=
 need extending.</div><div><br></div><div>I'd feel a lot more comfortabl=
e if the protocol was reviewed by a professional cryptographer though. I=
 think think Gregory already brought up an issue to do with people able =
to detect such payments by testing if decrypted values are points on the=
 curve, or something like that.</div>
</div></div></div>
</blockquote><div><br></div><div>Not sure I follow that, will look forwa=
rd to hearing more about it.</div><div><br></div><div>The only risk I kn=
ow of is that there are checks in theory that you would do on Q1/Q2, but=
 since the payee is the one generating Q1/Q2 they would literally be att=
acking themselves. I referenced two papers in a prior email specifically=
 on reusing ephemeral keys in ECDH, and the validation you need to do on=
 Q1/Q2 when re-using an ephemeral key to send two messages to two differ=
ent pubKeys. I think the idea of checking the pubKeys when re-using ephe=
meral keys is more when the pubKeys are under the attackers control. But=
 the validation is not complicated, and I'll see if I can add it tomorro=
w.</div><div><br></div><div>It would be good to fully understand how a p=
ossible small-group attack would work... &nbsp;This is a bit of guess-wo=
rk on my part:</div><div><br></div><div>&nbsp; &nbsp;If a payee managed =
to foot-shoot themselves with a bad Q2 pubKey, then gives out d2/Q2 to a=
 scanning service run by Mallory...</div><div><br></div><div>&nbsp; &nbs=
p;Mallory has d2/Q2, given P from a transaction, he calculates S2 (as us=
ual):</div><div><br></div><div>&nbsp; &nbsp; &nbsp; byte[] S2 =3D EC.DH(=
d2, P);</div><div><br></div><div>&nbsp; &nbsp;But with the small sub-gro=
up attack with Q2 he can learn 'e' (the ephemeral private key) used:</di=
v><div><br></div><div>&nbsp; &nbsp;&nbsp; &nbsp;byte[] S2 =3D EC.DH(e, Q=
2);</div><div><br></div><div>&nbsp; &nbsp;and from that he can calculate=
 S1 directly, when he should only know S2.&nbsp;</div><div><br></div><di=
v>&nbsp; &nbsp;&nbsp; &nbsp;byte[] S1 =3D EC.DH(e, Q1);</div><div><br></=
div><div>
So does that mean Mallory can find 'd1'? It looks like you would need an=
other small sub-group attack on P, the ephemeral public key, so another =
key the attacker doesn't control which would have to randomly be bad.
</div><div><br></div><div>&nbsp; &nbsp;&nbsp; &nbsp;byte[] S1 =3D EC.DH(=
d1, P);</div><div><br></div><div>But I'm definitely not a professional c=
ryptographer. Perhaps Matthew Green might be a good candidate to review =
this?</div><div><br></div><div>AND YAY, my stealth redemption Tx just we=
nt through, goodnight :-) http://blockexplorer.com/testnet/tx/df092896c1=
347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c#o0</div></body></=
html>
------------quLNl5KWjFmOZorIKGl4Bq--

------------quLNl5KWjFmOZozi4Nm4ts--