path: root/6f/d52300388f5aac73cb0b1bddb7f05a5f7a39cf

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <justus.ranvier@monetas.net>) id 1YlpvB-0000Fj-51
	for bitcoin-development@lists.sourceforge.net;
	Sat, 25 Apr 2015 02:34:21 +0000
Received: from mail-ig0-f169.google.com ([209.85.213.169])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Ylpv9-000375-Ay
	for bitcoin-development@lists.sourceforge.net;
	Sat, 25 Apr 2015 02:34:21 +0000
Received: by igbyr2 with SMTP id yr2so29005257igb.0
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 24 Apr 2015 19:34:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=mMOXfI62+pT6lAHnEnyl+XikcQ67jmaxcDOkfk+GpRY=;
	b=a/fbYAc7o2a3rDi5PU0B4ad1ot1TgajPbyq+zGhsqjf7tHlhQMoxldBNwClXSo2rcq
	zjoAQrNkwakgVD3xKQaeHmkpsD5xo8LdglO6e9cwvnlfS/GQigkxHh0uLSVsiSJwQHcA
	eUSv/R3/+srb9h/o46kTDxxG9kOLXGlW8/Rf8fY3NN353oHiKqbLXedP4cEABnz1/DJP
	NCddPjSdhidoAeqtPjtdV8C2RZaeIth6Jn9gU2hbmuS2Bg1rI4uo10q+OnFr2aY5NBdC
	OSfRwoNhnx4lf56qMzuCxUe33JG7vn6kKUi2Dx4MsM+cbQr0cO1ybAdYjpYfqtR0BliU
	GZ6w==
X-Gm-Message-State: ALoCoQk1p8Oc3XGH1ap1XUE2avz29vV3fIGDP8MAYLQW5Qpi6Y+27IbASdU3DJyoRTet4ehVtiLZ
MIME-Version: 1.0
X-Received: by 10.50.126.105 with SMTP id mx9mr1035417igb.21.1429929253955;
	Fri, 24 Apr 2015 19:34:13 -0700 (PDT)
Received: by 10.36.205.135 with HTTP; Fri, 24 Apr 2015 19:34:13 -0700 (PDT)
In-Reply-To: <CAAS2fgSAT2otym64oUACpWD8jWLAB6dBusONn-WUx2DK59SB5w@mail.gmail.com>
References: <CAHabJ+Mn0=vfLvTJ+z3tx8cFAAuLD1pLp4rOe3pM6MtCrCxjwg@mail.gmail.com>
	<1AE7B0A2-90EE-42EE-9D30-4DC1B5892E53@newcastle.ac.uk>
	<CAHabJ+NDqMN-rQ1BN1TfOjGLQHH-3Wd28LdoF95Agn4HdRrThg@mail.gmail.com>
	<CAHabJ+PMdQ-f7G8RNz0R7mfGUwBMAsnCyO=NmQhxyq0+gB1aPg@mail.gmail.com>
	<CAAS2fgSAT2otym64oUACpWD8jWLAB6dBusONn-WUx2DK59SB5w@mail.gmail.com>
Date: Sat, 25 Apr 2015 04:34:13 +0200
Message-ID: <CAHabJ+O7n=_ACXJx6_2DzoFC6h=2dk0aR3u3_LZhHgDut1gNMA@mail.gmail.com>
From: Justus Ranvier <justus.ranvier@monetas.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b4145d43c7e6d05148359d5
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1Ylpv9-000375-Ay
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: Reusable payment codes
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: Sat, 25 Apr 2015 02:34:21 -0000

--047d7b4145d43c7e6d05148359d5
Content-Type: text/plain; charset=UTF-8

On Sat, Apr 25, 2015 at 3:30 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Sat, Apr 25, 2015 at 12:22 AM, Justus Ranvier
> <justus.ranvier@monetas.net> wrote:
> > Taking the hash of the secret would then require an extra step to make
> sure
> > the hash is valid for secp256k1.
>
> The x value may not be a valid member of the group, effectively the
> same as with a hash. Its also very unequally distributed, as only
> about half the possible values are points on the curve.


ack


> > With 97 byte standard OP_RETURN values the ephemeral public
> > key could be appended to the chain code, but that's undesirable for
> other reasons.
>
> Can you elaborate?  Storing a ~33 byte (deterministically generated)
> ephemeral key should be all that is required. Everything else,
> including the chain code could be derived from it. What reason do you
> have to include additional data?
>

The goal of the notification transaction is to send the same payment code
to every recipient, but obscure the identity of the sender of the
notification transaction from third party blockchain observers.

The shared secret is used for that purpose, and the sender's public key
used for ECDH can't be one derived from the payment code since the
recipient doesn't yet know the payment code.

The notification transaction needs to communicate the 65 byte payment code
along with one ephemeral public key used for ECDH. If that ephemeral key is
not located in a signature script, it has to be somewhere else (such as in
the same OP_RETURN output as the payment code.)


> > Taking the SHA512 of something less than 512 bits seemed wrong.
>
> Why should it?  Adding the Y does not increase the entropy at all.  As
> an aside, I think this can be reformulated to only need 256 bits of
> output, and then the need for yet-another-hash-function could be
> avoided in some cases.
>

Already fixed in
https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521
but it would be good to get confirmation of whether the way I fixed it is
valid.

> In this proposal I optimized for non-reliance on third party services
>
> The requirement for inputs is a guaranteed dependency on third party
> services; so if thats whats being optimized for here it must go (well,
> I think it must go for the reason of avoiding blocking users from
> using other schemes to control their coins too..).
>

I'm not sure what you mean by "the requirement for inputs is a guaranteed
dependency on third party
services"

At the proposal currently stands, an SPV wallet will have no trouble
sending or receiving notification transactions without access to a third
party service. The recipient just needs to see the transactions associated
with its notification address.

The point about restricting the types of scripts used as inputs is valid,
but I think workarounds are available. If nothing else, the sender can make
a suitable input using it's own (suitably mixed) coins first.

> I agree. I could not find a straightforward way to express a
> multisignature payment code in less than 80 bytes.
>
> A prior stealth address proposal here handled them fine with only a
> single ephemeral point in the op_return. It does result in a longer
> address (is that what you're referring to with '80 bytes'?)
>

I considered defining an additional path level for deterministic m-of-n
multisig and adding a few bytes to the payment code to express those
parameters, but thought it would be too limiting since it would preclude
multisig with truly independent keys. It is a thing that could be done,
however.

> Exchanges could restrict bitcoin withdrawals to a single payment code
> known to be associated with their identified customer.
> > In some jurisdictions the ability to prove that withdrawals are sent to
> a positively-identified party, rather than arbitrary third parties, might
> move some Bitcoin businesses out of money transmitter territory into less
> onerous regulatory situations.
>
> But this mandates horrible key management practices, reliance on a
> single "hardcoded" private key which you cannot change; even if it
> might be compromised or lost to the wind. It's less horrible than
> sticking to a single address because it doesn't wedge privacy, I
> agree; but care should be taken that a tortured dance for confused
> regulatory cargo-cult reasons doesn't mandate people not engage in
> sound practices like periodic key rotation. :)
>

Cold storage is still available (if admittedly less convenient than in
traditional wallets).

I would expect exchanges in practice to allow for payment codes to be
changed, just with non-trivial waiting periods and plenty of human
overview. It would be an infrequent event compared to the frequency of
withdrawals.

Various schemes which use public key authentication instead of passwords
for web site authentication could be used to continually verify that the
user hasn't lost access to the key.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Apr 25, 2015 at 3:30 AM, Gregory Maxwell <span dir=3D"ltr">&lt;<a href=
=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><span class=3D"">On Sat, Apr 25, 2015 at=
 12:22 AM, Justus Ranvier<br>
&lt;<a href=3D"mailto:justus.ranvier@monetas.net">justus.ranvier@monetas.ne=
t</a>&gt; wrote:<br>
&gt; Taking the hash of the secret would then require an extra step to make=
 sure<br>
&gt; the hash is valid for secp256k1.<br>
<br>
</span>The x value may not be a valid member of the group, effectively the<=
br>
same as with a hash. Its also very unequally distributed, as only<br>
about half the possible values are points on the curve.</blockquote><div><b=
r></div><div>ack</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex"><span class=3D"">&g=
t; With 97 byte standard OP_RETURN values the ephemeral public<br>
&gt; key could be appended to the chain code, but that&#39;s undesirable fo=
r other reasons.<br>
<br>
</span>Can you elaborate?=C2=A0 Storing a ~33 byte (deterministically gener=
ated)<br>
ephemeral key should be all that is required. Everything else,<br>
including the chain code could be derived from it. What reason do you<br>
have to include additional data?<br></blockquote><div><br></div><div>The go=
al of the notification transaction is to send the same payment code to ever=
y recipient, but obscure the identity of the sender of the notification tra=
nsaction from third party blockchain observers.<br><br>The shared secret is=
 used for that purpose, and the sender&#39;s public key used for ECDH can&#=
39;t be one derived from the payment code since the recipient doesn&#39;t y=
et know the payment code.</div><div><br>The notification transaction needs =
to communicate the 65 byte payment code along with one ephemeral public key=
 used for ECDH. If that ephemeral key is not located in a signature script,=
 it has to be somewhere else (such as in the same OP_RETURN output as the p=
ayment code.)</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><span class=3D"">
&gt; Taking the SHA512 of something less than 512 bits seemed wrong.<br>
<br>
</span>Why should it?=C2=A0 Adding the Y does not increase the entropy at a=
ll.=C2=A0 As<br>
an aside, I think this can be reformulated to only need 256 bits of<br>
output, and then the need for yet-another-hash-function could be<br>
avoided in some cases.<br></blockquote><div><br></div><div>Already fixed in=
 <a href=3D"https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c=
4ae68f212c8b2dcd1b521">https://github.com/justusranvier/rfc/commit/8c4d3429=
012eb15847c4ae68f212c8b2dcd1b521</a> but it would be good to get confirmati=
on of whether the way I fixed it is valid.=C2=A0</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><span class=3D"">&gt; In this proposal I optimized for non-relia=
nce on third party services<br>
<br>
</span>The requirement for inputs is a guaranteed dependency on third party=
<br>
services; so if thats whats being optimized for here it must go (well,<br>
I think it must go for the reason of avoiding blocking users from<br>
using other schemes to control their coins too..).<br></blockquote><div><br=
></div><div>I&#39;m not sure what you mean by &quot;the requirement for inp=
uts is a guaranteed dependency on third party</div><div>services&quot;=C2=
=A0<br><br>At the proposal currently stands, an SPV wallet will have no tro=
uble sending or receiving notification transactions without access to a thi=
rd party service. The recipient just needs to see the transactions associat=
ed with its notification address.</div><div><br></div><div>The point about =
restricting the types of scripts used as inputs is valid, but I think worka=
rounds are available. If nothing else, the sender can make a suitable input=
 using it&#39;s own (suitably mixed) coins first.</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex"><span class=3D"">&gt; I agree. I could not find a straightforwa=
rd way to express a multisignature payment code in less than 80 bytes.<br>
<br>
</span>A prior stealth address proposal here handled them fine with only a<=
br>
single ephemeral point in the op_return. It does result in a longer<br>
address (is that what you&#39;re referring to with &#39;80 bytes&#39;?)<br>=
</blockquote><div><br></div><div>I considered defining an additional path l=
evel for deterministic m-of-n multisig and adding a few bytes to the paymen=
t code to express those parameters, but thought it would be too limiting si=
nce it would preclude multisig with truly independent keys. It is a thing t=
hat could be done, however.</div><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span clas=
s=3D"">&gt; Exchanges could restrict bitcoin withdrawals to a single paymen=
t code known to be associated with their identified customer.<br>
</span><span class=3D"">&gt; In some jurisdictions the ability to prove tha=
t withdrawals are sent to a positively-identified party, rather than arbitr=
ary third parties, might move some Bitcoin businesses out of money transmit=
ter territory into less onerous regulatory situations.<br>
<br>
</span>But this mandates horrible key management practices, reliance on a<b=
r>
single &quot;hardcoded&quot; private key which you cannot change; even if i=
t<br>
might be compromised or lost to the wind. It&#39;s less horrible than<br>
sticking to a single address because it doesn&#39;t wedge privacy, I<br>
agree; but care should be taken that a tortured dance for confused<br>
regulatory cargo-cult reasons doesn&#39;t mandate people not engage in<br>
sound practices like periodic key rotation. :)<br>
</blockquote></div><br></div><div class=3D"gmail_extra">Cold storage is sti=
ll available (if admittedly less convenient than in traditional wallets).<b=
r><br>I would expect exchanges in practice to allow for payment codes to be=
 changed, just with non-trivial waiting periods and plenty of human overvie=
w. It would be an infrequent event compared to the frequency of withdrawals=
.<br><br>Various schemes which use public key authentication instead of pas=
swords for web site authentication could be used to continually verify that=
 the user hasn&#39;t lost access to the key.</div></div>

--047d7b4145d43c7e6d05148359d5--