diff options
| author | James MacWhyte <macwhyte@gmail.com> | 2016-03-08 23:07:03 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-03-08 23:07:14 +0000 |
| commit | d395eda2846654b853410168e7b0141f64770861 (patch) | |
| tree | 1be56b8288403498fc6b89a012074758c5bc8ebf /7b | |
| parent | 8fb98be864ba4ed384f7216863c1c893be09bf02 (diff) | |
| download | pi-bitcoindev-d395eda2846654b853410168e7b0141f64770861.tar.gz pi-bitcoindev-d395eda2846654b853410168e7b0141f64770861.zip | |
Re: [bitcoin-dev] Proposed BIP extension to BIP 0070
Diffstat (limited to '7b')
| -rw-r--r-- | 7b/f4046899fad2a44379f3c576aee6f5a347916b | 265 |
1 files changed, 265 insertions, 0 deletions
diff --git a/7b/f4046899fad2a44379f3c576aee6f5a347916b b/7b/f4046899fad2a44379f3c576aee6f5a347916b new file mode 100644 index 000000000..21da4d92f --- /dev/null +++ b/7b/f4046899fad2a44379f3c576aee6f5a347916b @@ -0,0 +1,265 @@ +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 2D0BBBCB + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 8 Mar 2016 23:07:14 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com + [209.85.218.51]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 56F29106 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 8 Mar 2016 23:07:13 +0000 (UTC) +Received: by mail-oi0-f51.google.com with SMTP id c203so22578494oia.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 08 Mar 2016 15:07:13 -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=3sDMq/ag03KTzIHf6AIzRL1hNa5VZAzMDyZbfudJ6Kc=; + b=nUNrEzZfBAGq8eV5tUGFd5NOmoVluCaJcufzXQ45KupOea7PIVkDks4RuD0z/wx+7H + wKapO31xcwyicFCafMdnTbLrOT95F7rjvwnJOdSTkJiz5XaVhqRmgfHEPLfSOQXCHcOK + JkmWG9eawAE9fMa/cgb5M8zPgfWsf+h6rCdKczXeXE2e2JDIbXs3UsNpqU1QEyYAqrDb + AYZaCw0iPWv8Yfk9e1TiG5rcwyx1oiMe4ZVGGNlJW3QCVGyzwERqoGVyJsH9eecCndZa + uzTHPbZrn4VBxf8IA7TSOptBlNSVQLhDeDYzxSLfrrBafiw/8UnmhOSzc5W/SO1wP0Lv + QZ+A== +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=3sDMq/ag03KTzIHf6AIzRL1hNa5VZAzMDyZbfudJ6Kc=; + b=cRqDC7CYPweRn6LfoSEgOrtPn+h82aRPH6l5iSxkK4zQggXaxZl6od70sV02CQhVRh + Q+s6Bu9+ejKn7Z3IEAbF3nMFQeiW8L7IiuEcrMtkmVgjnqpZrecqMy5+5Kl7OXBIkFLy + KCDeHM1L+sn5Ws2eIJjWOSn/t6l1INpkeRBsDvW3dnx1PBZK/2Nm0BOEFcMSTP6ppayo + eqePKbj7dwZMFRW7vk/b8QiDEn45QiL/J1O88vjmnx5galJqL9jmmCNvx1Nl+nmpC/Gq + u9zqUYC+rz7pctltcr+MWhHZ+MKsNm8mb6s4SlOglukbO8sM4WDWY5W8apC50hNh6jq7 + 6D0g== +X-Gm-Message-State: AD7BkJJqBNeVbk1KflauvMFNuil4DPLF28/ZlKioVwHlk1u3u96OJ//AsGRh0eUbYnMbP6YRjbguVvy36GbUmg== +X-Received: by 10.202.193.10 with SMTP id r10mr19538801oif.126.1457478432705; + Tue, 08 Mar 2016 15:07:12 -0800 (PST) +MIME-Version: 1.0 +References: <CABqynx+gGnJ2AVByr1eKueSaohHtJVFsAVKrfS94StW2NzLWjw@mail.gmail.com> + <201603082234.14398.luke@dashjr.org> +In-Reply-To: <201603082234.14398.luke@dashjr.org> +From: James MacWhyte <macwhyte@gmail.com> +Date: Tue, 08 Mar 2016 23:07:03 +0000 +Message-ID: <CAH+Axy77qm0Ls3vNFxhbqfaG=PvraX92RqFPKZs7je=qNuSA6Q@mail.gmail.com> +To: bitcoin-dev@lists.linuxfoundation.org +Content-Type: multipart/alternative; boundary=001a113dc36e3fd361052d91a4e1 +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 00:00:23 +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: Tue, 08 Mar 2016 23:07:14 -0000 +X-List-Received-Date: Tue, 08 Mar 2016 23:07:14 -0000 + +--001a113dc36e3fd361052d91a4e1 +Content-Type: text/plain; charset=UTF-8 + +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 +> + +--001a113dc36e3fd361052d91a4e1 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><span style=3D"font-size:13px;line-height:19.5px">Our BIP = +just defines protocol definitions, and doesn't really dictate how peopl= +e use them (we're coming up with a new title for the BIP, by the way, t= +o more accurately convey that). Using our definitions as building blocks, s= +omeone could definitely accomplish what you described. For example, Joe Mob= +ile Wallet User's wallet could upload a slew of generic PaymentRequest = +messages with signatures to prove his identity, and the server could then c= +reate encryptedPaymentRequest messages using the server's key for encry= +ption 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 us= +er'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 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?</span><div><span style=3D"li= +ne-height:19.5px"><br></span></div><div><span style=3D"line-height:19.5px">= +James<br></span><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Mar= + 8, 2016 at 2:55 PM Luke Dashjr via bitcoin-dev <<a href=3D"mailto:bitco= +in-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>= +> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = +0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is there a way for 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> +> The following draft BIP proposes an update to the Payment Protocol.<br= +> +><br> +> Motivation:<br> +><br> +> The motivation for defining this extension to the BIP70 Payment Protoc= +ol is<br> +> to allow 2 parties to exchange payment information in a permissioned a= +nd<br> +> encrypted way such that wallet address communication can become a more= +<br> +> automated process. Additionally, this extension allows for the request= +or of<br> +> a PaymentRequest to supply a certificate and signature in order to<br> +> facilitate identification for address release. This also allows<br> +> for automated creation of off blockchain transaction logs that are hum= +an<br> +> readable, containing who you transacted with, in addition to the<br> +> information that it contains today.<br> +><br> +> The motivation for this extension to BIP70 is threefold:<br> +><br> +> 1. Ensure that the payment details can only be seen by the participant= +s in<br> +> the transaction, and not by any third party.<br> +> 2. Enhance the Payment Protocol to allow for store and forward servers= + in<br> +> order to allow, for example, mobile wallets to sign and serve<br> +> Payment Requests.<br> +> 3. Allow a sender of funds the option of sharing their identity with t= +he<br> +> receiver. This information could then be used to:<br> +><br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Make bitcoin logs more human readab= +le<br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Give the user the ability to decide= + who to release payment<br> +> details to<br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Allow an entity such as a political= + campaign to ensure donors<br> +> match regulatory and legal requirements<br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Allow for an open standards based w= +ay for regulated financial<br> +> entities to meet regulatory requirements<br> +>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Automate the active exchange of pay= +ment addresses, so static<br> +> addresses and BIP32 X-Pubs can be avoided to maintain privacy<br> +> and convenience<br> +><br> +> In short we wanted to make bitcoin more human, while at the same time<= +br> +> improving transaction privacy.<br> +><br> +> Full proposal here:<br> +><br> +> <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> +> .mediawiki<br> +><br> +> We look forward to your thoughts and feedback on this proposal!<br> +><br> +> 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> + +--001a113dc36e3fd361052d91a4e1-- + |