path: root/21/281fdd671794f62933fb4f6e645bf5c8dd7c85

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <justus.ranvier@monetas.net>) id 1YlnqD-0006hd-ME
	for bitcoin-development@lists.sourceforge.net;
	Sat, 25 Apr 2015 00:21:05 +0000
Received: from mail-ie0-f171.google.com ([209.85.223.171])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YlnqC-0003Y5-KB
	for bitcoin-development@lists.sourceforge.net;
	Sat, 25 Apr 2015 00:21:05 +0000
Received: by iedfl3 with SMTP id fl3so106766106ied.1
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 24 Apr 2015 17:20:59 -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:content-type;
	bh=R7y/aS+xGx5Ew6THrzWWIayfsHw1/tgUedp21d0Qwk4=;
	b=lst+t1EjOkgRZ+znvXeunliDYZoLEhG6jQdsr+xwO5CctoWIkp794esg+asDi3aG/M
	+CezEkXR+FEFO0uBaplVTyDX3pNPbhUop6KgD0ynU+TkQtgPGpJ1/vK29LtQno8O/c2t
	xFWX2JitK4yfwG5SEzExmmd+GEvNEOVPspX/XtFXky3/o4ApCaP6E7LD9UaFt1lo84m5
	3G/amhCsu+ULjJ1pKRP0MIdjGDp2iY1jYPxffCfUNFcvC26BclgeWV1ZgiOdJCzIiUk5
	EzPnpEPxhiOfOcLuNpFaQfgi53YakAjoLlCiRXG0K5/yzm+DjF6YtzlEz3GETIaP8QzE
	VbYw==
X-Gm-Message-State: ALoCoQm6cl4+g+p1bY97wkn1bkV8AtC1n5l7qWqRRZL904kdwK3iz+JIRgE2xPhUY6QVsz+7XaFJ
MIME-Version: 1.0
X-Received: by 10.42.129.73 with SMTP id p9mr1674241ics.48.1429921259265; Fri,
	24 Apr 2015 17:20:59 -0700 (PDT)
Received: by 10.36.205.135 with HTTP; Fri, 24 Apr 2015 17:20:59 -0700 (PDT)
In-Reply-To: <CAHabJ+MtWJS=e3tkGih=xoP4ARgHe8X=D_p9OWTnRJi0z9epBw@mail.gmail.com>
References: <CAHabJ+Mn0=vfLvTJ+z3tx8cFAAuLD1pLp4rOe3pM6MtCrCxjwg@mail.gmail.com>
	<CAAS2fgRVcwNfYv8fnoS_uRtDoGqRiWAXcPgaK8if8FO_G6LQoQ@mail.gmail.com>
	<CAHabJ+MtWJS=e3tkGih=xoP4ARgHe8X=D_p9OWTnRJi0z9epBw@mail.gmail.com>
Date: Sat, 25 Apr 2015 02:20:59 +0200
Message-ID: <CAHabJ+PWRUYEO8mY68kH_wy5iozx0JQG1N_aQhUWcvnMR36A+A@mail.gmail.com>
From: Justus Ranvier <justus.ranvier@monetas.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=20cf301af6d9b738d70514817cbf
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: 1YlnqC-0003Y5-KB
Subject: [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 00:21:05 -0000

--20cf301af6d9b738d70514817cbf
Content-Type: text/plain; charset=UTF-8

On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell <gmaxwell@gmail.com>
wrote:

> So this requires making dust payments to a constantly reused address
> in order to (ab)use the blockchain as a messaging layer.
>
> Indeed, this is more SPV compatible; but it seems likely to me that
> _in practice_ it would almost completely undermine the privacy the
> idea hoped to provide; because you'd have an observable linkage to a
> highly reused address.
>

I agree that the output associated with notification transactions would
require special handling to avoid privacy leaks. At a minimum they'd
require mixing or being donated to miners as a transaction fee.


>
> It would also more than double the data sent for the application where
> 'stealth addresses' are most important: one-time anonymous donations
> (in other contexts; you have two way communication between the
> participants, and so you can just given them a one off address without
> singling in the public network.)
>

Communication is only one way, except for the case in which the recipient
wants to send a refund. Assuming no refund and only a single anonymous
donation in the lifetime of the sender's identity, payment codes would
require 65 bytes vs 40 bytes for stealth addresses.

As soon as the sender sends more than one donation to the same recipient,
payment codes show an space advantage over stealth addresses.

This kind of binding was intentionally designed out of the stealth
>
address proposal;  I think this scheme can be made to work without any
> increase in size by reusing the payment code as the ephemeral public
> key (or actually being substantially smaller e.g. use the shared
> secret as the chain code, but I should give it more thought)
>

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.

This is fundamentally more expensive to compute; please don't specify
> "uncompressed".
>

Taking the SHA512 of something less than 512 bits seemed wrong.


> This appears incompatible with multisignature; which is unfortunate.
>

I agree. I could not find a straightforward way to express a multisignature
payment code in less than 80 bytes.


> I'm disappointed that there isn't any thought given to solving the
> scanning privacy without forcing non-private pure-overhead messaging
> transactions on heavily reused addresses. Are you aware of the IBE
> approach that allows someone to request a third party scan for them
> with block by block control over their delegation of scanning?
>

I suspect this is a case where we just can't have all the features we want.

In this proposal I optimized for non-reliance on third party services and a
guaranteed ability to recover spendable funds from a seed backup.

Gaining those two features resulted in some tradeoffs as you noted, but I
think there are enough benefits to make them worthwhile.

In particular, payment codes could be the basis for a Heartbleed-free
payment protocol that can positively identify customers and automatically
provide refund capabilities in a merchant-customer relationship. A merchant
only requires one payment code which they can safely use for all their
customers, meaning they only ever need to associate 65 bytes with their
identity to allow customers to make sure they are paying the right entity.

Exchanges could restrict bitcoin withdrawals to a single payment code known
to be associated with their identified customer. This would make thefts
easier (without involving address reuse as in locking withdrawals to a
single P2PKH address).

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.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Fri, Apr 24, 20=
15 at 10:58 PM, Gregory Maxwell <span dir=3D"ltr">&lt;<a href=3D"mailto:gma=
xwell@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;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex">So this requires making dust payments to a constantly =
reused address<br>
in order to (ab)use the blockchain as a messaging layer.<br>
<br>
Indeed, this is more SPV compatible; but it seems likely to me that<br>
_in practice_ it would almost completely undermine the privacy the<br>
idea hoped to provide; because you&#39;d have an observable linkage to a<br=
>
highly reused address.<br></blockquote><div><br></div></span><div>I agree t=
hat the output associated with notification transactions would require spec=
ial handling to avoid privacy leaks. At a minimum they&#39;d require mixing=
 or being donated to miners as a transaction fee.</div><span class=3D""><di=
v>=C2=A0</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">
<br>
It would also more than double the data sent for the application where<br>
&#39;stealth addresses&#39; are most important: one-time anonymous donation=
s<br>
(in other contexts; you have two way communication between the<br>
participants, and so you can just given them a one off address without<br>
singling in the public network.)<br></blockquote><div><br></div></span><div=
>Communication is only one way, except for the case in which the recipient =
wants to send a refund. Assuming no refund and only a single anonymous dona=
tion in the lifetime of the sender&#39;s identity, payment codes would requ=
ire 65 bytes vs 40 bytes for stealth addresses.</div><div><br></div><div>As=
 soon as the sender sends more than one donation to the same recipient, pay=
ment codes show an space advantage over stealth addresses.</div><span class=
=3D""><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);bord=
er-left-style:solid;padding-left:1ex">This kind of binding was intentionall=
y designed out of the stealth<br></blockquote><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
address proposal;=C2=A0 I think this scheme can be made to work without any=
<br>
increase in size by reusing the payment code as the ephemeral public<br>
key (or actually being substantially smaller e.g. use the shared<br>
secret as the chain code, but I should give it more thought)<br></blockquot=
e><div><br></div></span><div>With 97 byte standard OP_RETURN values the eph=
emeral public</div>key could be appended to the chain code, but that&#39;s =
undesirable for other reasons.<span class=3D""><br><br><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Thi=
s is fundamentally more expensive to compute; please don&#39;t specify<br>
&quot;uncompressed&quot;.<br></blockquote><div><br></div></span><div>Taking=
 the SHA512 of something less than 512 bits seemed wrong.</div><span class=
=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex">This appears incompatible with mult=
isignature; which is unfortunate.<br></blockquote><div><br></div></span><di=
v>I agree. I could not find a straightforward way to express a multisignatu=
re payment code in less than 80 bytes.</div><span class=3D""><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex">I&#39;m disappointed that there isn&#39;t any thought g=
iven to solving the<br>
scanning privacy without forcing non-private pure-overhead messaging<br>
transactions on heavily reused addresses. Are you aware of the IBE<br>
approach that allows someone to request a third party scan for them<br>
with block by block control over their delegation of scanning?<br></blockqu=
ote><div><br></div></span><div>I suspect this is a case where we just can&#=
39;t have all the features we want.</div><div><br></div><div>In this propos=
al I optimized for non-reliance on third party services and a guaranteed ab=
ility to recover spendable funds from a seed backup.<br><br>Gaining those t=
wo features resulted in some tradeoffs as you noted, but I think there are =
enough benefits to make them worthwhile.</div><div><br></div><div>In partic=
ular, payment codes could be the basis for a Heartbleed-free payment protoc=
ol that can positively identify customers and automatically provide refund =
capabilities in a merchant-customer relationship. A merchant only requires =
one payment code which they can safely use for all their customers, meaning=
 they only ever need to associate 65 bytes with their identity to allow cus=
tomers to make sure they are paying the right entity.<br><br>Exchanges coul=
d restrict bitcoin withdrawals to a single payment code known to be associa=
ted with their identified customer. This would make thefts easier (without =
involving address reuse as in locking withdrawals to a single P2PKH address=
).</div><div><br></div><div>In some jurisdictions the ability to prove that=
 withdrawals are sent to a positively-identified party, rather than arbitra=
ry third parties, might move some Bitcoin businesses out of money transmitt=
er territory into less onerous regulatory situations.</div></div><br></div>=
</div>
</div><br></div>

--20cf301af6d9b738d70514817cbf--