path: root/0d/1dbc1ed15891ec8590618060001dd36bb941d0

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 1YlnqZ-0006k9-F8
	for bitcoin-development@lists.sourceforge.net;
	Sat, 25 Apr 2015 00:21:27 +0000
Received: from mail-ig0-f179.google.com ([209.85.213.179])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YlnqX-0003Yb-Si
	for bitcoin-development@lists.sourceforge.net;
	Sat, 25 Apr 2015 00:21:27 +0000
Received: by igblo3 with SMTP id lo3so27325738igb.1
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 24 Apr 2015 17:21:20 -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=ICN5a4qrT74UN4YWD5g9WYwwSsZeq+Y1awLn1cVUN4w=;
	b=TCz4ZREc1BVVEPRljmDJJiDhj5ztwoFk3OqZx+vzZ6P/rLi62z/ftzj9SuRGniCcrH
	KTL2y2Lx1ZR8ACwzXzmcLQap6SSjfFnRUSiOYYEYLoa69RxFwsaWfvkrfAvJFxmBUGEy
	Khv41OLTkao0D/iiKHdTr6OR26p5//ZolzbAf5xJeu/aCyuNkOqsvtmDXDN/4acQVepx
	F62bbVXpDYmY0x7CJ/RzbELSxL6g1u7etJeR6U7hgZPxwLLfvyP2nq83ou+Ismoa7AoI
	pUKO1pdyZxbEV45tdhqHzoIbxQDLhWOg6uYO6BcZrPUBt+e6/wmN28QoOPldizjFuouw
	T0uQ==
X-Gm-Message-State: ALoCoQnzrb63mj03u7zMof8+sVETLgvt9qQ9ucRv63bk+yrCv8jrnyYfwCYZDlbZ4cufHV0BJLoN
MIME-Version: 1.0
X-Received: by 10.107.130.84 with SMTP id e81mr1197822iod.80.1429921280550;
	Fri, 24 Apr 2015 17:21:20 -0700 (PDT)
Received: by 10.36.205.135 with HTTP; Fri, 24 Apr 2015 17:21:20 -0700 (PDT)
In-Reply-To: <CAHabJ+Oabx80+_1KutfrPUt5QEnMivfNeeh4uJJJOsiHRQqSZw@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>
	<CAHabJ+Oabx80+_1KutfrPUt5QEnMivfNeeh4uJJJOsiHRQqSZw@mail.gmail.com>
Date: Sat, 25 Apr 2015 02:21:20 +0200
Message-ID: <CAHabJ+N1acagTJ_-P=BJ_5unHU6ywNZK+wNzZJzTmyFdZ4AMrQ@mail.gmail.com>
From: Justus Ranvier <justus.ranvier@monetas.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a113eca2efbfddc0514817d49
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: 1YlnqX-0003Yb-Si
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:27 -0000

--001a113eca2efbfddc0514817d49
Content-Type: text/plain; charset=UTF-8

I have pushed an updated version of the proposal which incorporates some of
the received feedback and adds a note about the consequences of sharing a
payment code-enabled walled on multiple devices:

https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki

https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521

On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier <justus.ranvier@monetas.net
> wrote:

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

--001a113eca2efbfddc0514817d49
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">I have pushed =
an updated version of the proposal which incorporates some of the received =
feedback and adds a note about the consequences of sharing a payment code-e=
nabled walled on multiple devices:<br><br><a href=3D"https://github.com/jus=
tusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki" target=3D"_blank"=
>https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.media=
wiki</a><br><div><br></div><div><a href=3D"https://github.com/justusranvier=
/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521" target=3D"_blank">htt=
ps://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dc=
d1b521</a><br></div></div><div class=3D"HOEnZb"><div class=3D"h5"><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Apr 25, 2015 at 12=
:21 AM, Justus Ranvier <span dir=3D"ltr">&lt;<a href=3D"mailto:justus.ranvi=
er@monetas.net" target=3D"_blank">justus.ranvier@monetas.net</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote"><span>On Fri, Apr 24, 2015 =
at 10:58 PM, Gregory Maxwell <span dir=3D"ltr">&lt;<a href=3D"mailto:gmaxwe=
ll@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">So this requires making dust payments to a constantly reu=
sed 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><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">
<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><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex">This kind of binding was intentionally designed =
out of the stealth<br></blockquote><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">
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><br><br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This is fundam=
entally 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><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(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">This appears incompatible with multisignature;=
 which is unfortunate.<br></blockquote><div><br></div></span><div>I agree. =
I could not find a straightforward way to express a multisignature payment =
code in less than 80 bytes.</div><span><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
I&#39;m disappointed that there isn&#39;t any thought given 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>
</blockquote></div><br></div>
</div></div></div><br></div>

--001a113eca2efbfddc0514817d49--