path: root/e4/748483b40aba9e066b74a0469c8592b8e74cd7

Return-Path: <keatonatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 84A35C6F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Mar 2016 01:17:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com
	[209.85.218.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2A76190
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Mar 2016 01:17:21 +0000 (UTC)
Received: by mail-oi0-f48.google.com with SMTP id d205so24560072oia.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 08 Mar 2016 17:17:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=+3Ug9T/uXCC08k2fNAaNnHBqqK0cIK/JvDJlhbYOr08=;
	b=bKxbiXDQ07MuavnxkkFRNEbcTGvGZzw4nc4yc7cPWKK0Rw/RtsBXeCYt6lcV6HptkH
	vtwRFKCU0CoSFjjRzBJmeyQ9s3fD5MGu9FQ+0m41iM77BJBUogEN6KBCM1iJHPK3Ko7m
	Lo/LdeGHmdqzsV3DbDpQTzo+qKOXBTcGC70kRuTnNhnN2Bi2aLfZjhnmSME3Fr9+7eOF
	VgMshCC+221z6nqAQzQ058kbg7tsExa3mMv2Ph1NDZavQcjiC+XXXKS2dsjyRN3BYQIT
	ObEsx6WIAeG+qX8IO8vBffCAiIGpbI7cWcCswODsq7WAum5EE8KkYMyRSiwB+KG77cT2
	ozcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=+3Ug9T/uXCC08k2fNAaNnHBqqK0cIK/JvDJlhbYOr08=;
	b=KOU7rsnZpeSbY24htruyXCrziJeB0v2ANJnJGzgjWWHwB9kSD9QB0gRjGU6uPHXR9s
	A97zLRUunJik7YgrONvk6yaSHMilLupnDY59mkEp7zTyxNl+nc9QW+hHTFKjpnijLY+2
	/zd+/WQqHh+So9oPDxBJq0EksCsidNCx7dhRArSCGzf18ekMHJwnXAOjGWOmAwg9TbpU
	ch+OWEsP1kpumeITLJmymmIH+QzCTMLEHwchly+TQlPU9pGQpVB6OtK8SZV2mEnh9kJT
	C0LOesuJxrWdnpGAIYgv9hlYyIpVuw9zXPVBE/I4hbfPYZs5UHtUYXw/DFDaKfve/TeY
	NVlQ==
X-Gm-Message-State: AD7BkJLVzijhgy20qzC2H3o0avO9WPNNmYsmGX8bMHkoXo7VCykvMr9b9FEA5xfDARrMZK8goE9nhK1QDoZp7Q==
X-Received: by 10.202.90.3 with SMTP id o3mr19195183oib.96.1457486241173; Tue,
	08 Mar 2016 17:17:21 -0800 (PST)
MIME-Version: 1.0
References: <CABqynx+gGnJ2AVByr1eKueSaohHtJVFsAVKrfS94StW2NzLWjw@mail.gmail.com>
	<201603082234.14398.luke@dashjr.org>
	<CAH+Axy77qm0Ls3vNFxhbqfaG=PvraX92RqFPKZs7je=qNuSA6Q@mail.gmail.com>
In-Reply-To: <CAH+Axy77qm0Ls3vNFxhbqfaG=PvraX92RqFPKZs7je=qNuSA6Q@mail.gmail.com>
From: James MacWhyte <macwhyte@gmail.com>
Date: Wed, 09 Mar 2016 01:17:11 +0000
Message-ID: <CAH+Axy7SsLohdeYkUbGUaX2JUf6ni5744stNbsTPJEEMtT9Xdg@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113d5edcab9610052d937588
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 09 Mar 2016 05:43:28 +0000
Subject: Re: [bitcoin-dev] Proposed BIP extension to BIP 0070
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Mar 2016 01:17:23 -0000

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

I accidentally replied to Luke off-list, and this was his reply to my last
message:

"But wouldn't the server be a trusted third-party in this case?
I'm thinking it's very close to being possible for an untrusted server to do
this..."

If you are okay with anyone being able to view your PaymentRequest
messages, then you wouldn't need to encrypt them. Just upload them to the
server and let it give them away--no trust needed as long as you include a
signature. If you want only certain people to be able to see your messages,
then you need to denote those people in some way. In this situation, you
would do that by trading public keys and uploading encryptedPaymentRequest
messages to the server that only those people could read.

Using the encrypted method doesn't require the devices to be online, but it
does require at least one of the parties to know the other party's public
key. Do you have a specific use case in mind?

James

On Tue, Mar 8, 2016 at 3:07 PM James MacWhyte <macwhyte@gmail.com> wrote:

> Our BIP just defines protocol definitions, and doesn't really dictate how
> people use them (we're coming up with a new title for the BIP, by the way,
> to more accurately convey that). Using our definitions as building blocks,
> someone could definitely accomplish what you described. For example, Joe
> Mobile Wallet User's wallet could upload a slew of generic PaymentRequest
> messages with signatures to prove his identity, and the server could then
> create encryptedPaymentRequest messages using the server's key for
> encryption and communication with the other party. In this case the server
> would essentially be a proxy for the user without having actual access to
> the user's private keys.
>
> My personal goal with the protocol was to keep it extremely flexible so
> developers could use it to build all different types of schemes while
> keeping standard messages that could be forwarded between services if
> needed. Does the above make sense?
>
> James
>
> On Tue, Mar 8, 2016 at 2:55 PM Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Is there a way for Joe Mobile Wallet User to upload a set of N
>> PaymentRequests
>> authenticated by his key to an untrusted server, which encrypts and passes
>> them on in response to InvoiceRequests? Or does this necessarily require
>> the
>> recipient to be online?
>>
>> On Tuesday, March 01, 2016 6:58:16 PM Justin Newton via bitcoin-dev wrote:
>> > The following draft BIP proposes an update to the Payment Protocol.
>> >
>> > Motivation:
>> >
>> > The motivation for defining this extension to the BIP70 Payment
>> Protocol is
>> > to allow 2 parties to exchange payment information in a permissioned and
>> > encrypted way such that wallet address communication can become a more
>> > automated process. Additionally, this extension allows for the
>> requestor of
>> > a PaymentRequest to supply a certificate and signature in order to
>> > facilitate identification for address release. This also allows
>> > for automated creation of off blockchain transaction logs that are human
>> > readable, containing who you transacted with, in addition to the
>> > information that it contains today.
>> >
>> > The motivation for this extension to BIP70 is threefold:
>> >
>> > 1. Ensure that the payment details can only be seen by the participants
>> in
>> > the transaction, and not by any third party.
>> > 2. Enhance the Payment Protocol to allow for store and forward servers
>> in
>> > order to allow, for example, mobile wallets to sign and serve
>> > Payment Requests.
>> > 3. Allow a sender of funds the option of sharing their identity with the
>> > receiver. This information could then be used to:
>> >
>> >         * Make bitcoin logs more human readable
>> >         * Give the user the ability to decide who to release payment
>> > details to
>> >         * Allow an entity such as a political campaign to ensure donors
>> > match regulatory and legal requirements
>> >         * Allow for an open standards based way for regulated financial
>> > entities to meet regulatory requirements
>> >         * Automate the active exchange of payment addresses, so static
>> > addresses and BIP32 X-Pubs can be avoided to maintain privacy
>> > and convenience
>> >
>> > In short we wanted to make bitcoin more human, while at the same time
>> > improving transaction privacy.
>> >
>> > Full proposal here:
>> >
>> >
>> https://github.com/techguy613/bips/blob/master/bip-invoicerequest-extension
>> > .mediawiki
>> >
>> > We look forward to your thoughts and feedback on this proposal!
>> >
>> > Justin
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

<div dir=3D"ltr">I accidentally replied to Luke off-list, and this was his =
reply to my last message:<br><br>&quot;<span style=3D"font-size:13px;line-h=
eight:19.5px">But wouldn&#39;t the server be a trusted third-party in this =
case?</span><br style=3D"font-size:13px;line-height:19.5px"><span style=3D"=
font-size:13px;line-height:19.5px">I&#39;m thinking it&#39;s very close to =
being possible for an untrusted server to do</span><br style=3D"font-size:1=
3px;line-height:19.5px"><span style=3D"font-size:13px;line-height:19.5px">t=
his...&quot;<br></span><br>If you are okay with anyone being able to view y=
our PaymentRequest messages, then you wouldn&#39;t need to encrypt them. Ju=
st upload them to the server and let it give them away--no trust needed as =
long as you include a signature. If you want only certain people to be able=
 to see your messages, then you need to denote those people in some way. In=
 this situation, you would do that by trading public keys and uploading enc=
ryptedPaymentRequest messages to the server that only those people could re=
ad.<div><br></div><div>Using the encrypted method doesn&#39;t require the d=
evices to be online, but it does require at least one of the parties to kno=
w the other party&#39;s public key. Do you have a specific use case in mind=
?</div><div><br></div><div>James</div><div><br></div><div>On Tue, Mar 8, 20=
16 at 3:07 PM James MacWhyte &lt;<a href=3D"mailto:macwhyte@gmail.com">macw=
hyte@gmail.com</a>&gt; wrote:<div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span style=3D"font-size:13px;line-height:19=
.5px">Our BIP just defines protocol definitions, and doesn&#39;t really dic=
tate how people use them (we&#39;re coming up with a new title for the BIP,=
 by the way, to more accurately convey that). Using our definitions as buil=
ding blocks, someone could definitely accomplish what you described. For ex=
ample, Joe Mobile Wallet User&#39;s wallet could upload a slew of generic P=
aymentRequest messages with signatures to prove his identity, and the serve=
r could then create encryptedPaymentRequest messages using the server&#39;s=
 key for encryption and communication with the other party. In this case th=
e server would essentially be a proxy for the user without having actual ac=
cess to the user&#39;s private keys.</span><br style=3D"font-size:13px;line=
-height:19.5px"><br style=3D"font-size:13px;line-height:19.5px"><span style=
=3D"font-size:13px;line-height:19.5px">My personal goal with the protocol w=
as to keep it extremely flexible so developers could use it to build all di=
fferent types of schemes while keeping standard messages that could be forw=
arded between services if needed. Does the above make sense?</span><div><sp=
an style=3D"line-height:19.5px"><br></span></div></div><div dir=3D"ltr"><di=
v><span style=3D"line-height:19.5px">James<br></span><br></div></div><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Mar 8, =
2016 at 2:55 PM Luke Dashjr via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoun=
dation.org</a>&gt; wrote:<br></div></div></div></div><div dir=3D"ltr"><div>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is there a way fo=
r Joe Mobile Wallet User to upload a set of N PaymentRequests<br>
authenticated by his key to an untrusted server, which encrypts and passes<=
br>
them on in response to InvoiceRequests? Or does this necessarily require th=
e<br>
recipient to be online?<br>
<br>
On Tuesday, March 01, 2016 6:58:16 PM Justin Newton via bitcoin-dev wrote:<=
br>
&gt; The following draft BIP proposes an update to the Payment Protocol.<br=
>
&gt;<br>
&gt; Motivation:<br>
&gt;<br>
&gt; The motivation for defining this extension to the BIP70 Payment Protoc=
ol is<br>
&gt; to allow 2 parties to exchange payment information in a permissioned a=
nd<br>
&gt; encrypted way such that wallet address communication can become a more=
<br>
&gt; automated process. Additionally, this extension allows for the request=
or of<br>
&gt; a PaymentRequest to supply a certificate and signature in order to<br>
&gt; facilitate identification for address release. This also allows<br>
&gt; for automated creation of off blockchain transaction logs that are hum=
an<br>
&gt; readable, containing who you transacted with, in addition to the<br>
&gt; information that it contains today.<br>
&gt;<br>
&gt; The motivation for this extension to BIP70 is threefold:<br>
&gt;<br>
&gt; 1. Ensure that the payment details can only be seen by the participant=
s in<br>
&gt; the transaction, and not by any third party.<br>
&gt; 2. Enhance the Payment Protocol to allow for store and forward servers=
 in<br>
&gt; order to allow, for example, mobile wallets to sign and serve<br>
&gt; Payment Requests.<br>
&gt; 3. Allow a sender of funds the option of sharing their identity with t=
he<br>
&gt; receiver. This information could then be used to:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Make bitcoin logs more human readab=
le<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Give the user the ability to decide=
 who to release payment<br>
&gt; details to<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Allow an entity such as a political=
 campaign to ensure donors<br>
&gt; match regulatory and legal requirements<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Allow for an open standards based w=
ay for regulated financial<br>
&gt; entities to meet regulatory requirements<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Automate the active exchange of pay=
ment addresses, so static<br>
&gt; addresses and BIP32 X-Pubs can be avoided to maintain privacy<br>
&gt; and convenience<br>
&gt;<br>
&gt; In short we wanted to make bitcoin more human, while at the same time<=
br>
&gt; improving transaction privacy.<br>
&gt;<br>
&gt; Full proposal here:<br>
&gt;<br>
&gt; <a href=3D"https://github.com/techguy613/bips/blob/master/bip-invoicer=
equest-extension" rel=3D"noreferrer" target=3D"_blank">https://github.com/t=
echguy613/bips/blob/master/bip-invoicerequest-extension</a><br>
&gt; .mediawiki<br>
&gt;<br>
&gt; We look forward to your thoughts and feedback on this proposal!<br>
&gt;<br>
&gt; Justin<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div></blockquote></div></div></div>

--001a113d5edcab9610052d937588--