Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TllsB-0008G2-Sh for bitcoin-development@lists.sourceforge.net; Thu, 20 Dec 2012 19:33:39 +0000 Received: from mail-la0-f41.google.com ([209.85.215.41]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Tlls9-0001En-NC for bitcoin-development@lists.sourceforge.net; Thu, 20 Dec 2012 19:33:39 +0000 Received: by mail-la0-f41.google.com with SMTP id m15so3668619lah.28 for ; Thu, 20 Dec 2012 11:33:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=8T2OEuc5M4xrpvs/PuQsD4U0mtgGnAU7njIhGB1ba6Y=; b=Qvlil7UGgygES/gI9A9CwkWwwKYHKOLy48Ox3si5xloYb8+D9R57Y7kD7l+A4V41lo Ec6uRY1zyWOfDHoKA15CEJ/f1xvbfmImF1f2usYl4JQh1/4qpd3r1kMx8uA9FZHVR9wM 2VvAa57eqHhlKv/ba/MUF6XGLShOAtEmyQZ0hvFrLwoMaEZyGQpl1eCtUln27hLOvnwc ElS1Bu+yrazNuz670apnJV2ElxJQ20C0mkpZOJo4nOAaoTmV7qIz4hMS9s1vcfB+pLO/ PCxgBrhNqFBQQF4mqb7quK/hyHx8Srr14O57WEsdu+ET4pSEqA8uLFO8MimmzqvvV97K /XOQ== X-Received: by 10.152.132.137 with SMTP id ou9mr10046973lab.7.1356032010721; Thu, 20 Dec 2012 11:33:30 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by mx.google.com with ESMTPS id ns7sm2375032lab.5.2012.12.20.11.33.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 11:33:29 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id s15so3686291lag.15 for ; Thu, 20 Dec 2012 11:33:28 -0800 (PST) Received: by 10.152.106.163 with SMTP id gv3mr9808169lab.55.1356032007998; Thu, 20 Dec 2012 11:33:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.17.231 with HTTP; Thu, 20 Dec 2012 11:32:46 -0800 (PST) X-Originating-IP: [71.204.90.78] In-Reply-To: References: <20121128233619.GA6368@giles.gnomon.org.uk> <20121129170713.GD6368@giles.gnomon.org.uk> <20121129185330.GE6368@giles.gnomon.org.uk> From: Stephen Pair Date: Thu, 20 Dec 2012 14:32:46 -0500 Message-ID: To: Mike Hearn Content-Type: multipart/alternative; boundary=f46d04083aad240c5a04d14dcea7 X-Gm-Message-State: ALoCoQmi8NjbHev7YPLvG6EPirxNQVya94+LX9MNG2s0bWFEnG33DfuV5T0oHiXMze1OsHlS1NVx 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: 1Tlls9-0001En-NC Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 19:33:40 -0000 --f46d04083aad240c5a04d14dcea7 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 20, 2012 at 12:43 PM, Mike Hearn wrote: > > you may find yourself in a situation needing to parse a protobuf > > message in a web browser > Nothing stops you converting them into whatever form you want on the > server side. If you don't care about the signature checking then it's > no problem to use a server. If you do then you'd need to ship all the > code for verifying signatures that to the client anyway, at which > point a small protobuf parser is hardly a deal killer. No, it's not a killer...just a hassle. JSON is convenient and ubiquitous and there is something to be said for that (and I wanted to point out that the JOSE objection was invalid). Protobufs are nice and efficient, but who cares. You're talking about direct communications rather than something that will be bounced around every node in the mesh network. I don't really care much either way, it's not worth debating. I'm just thankful no one is arguing for XML or IIOP. :) > ...like what about the casual user that wants to create a payment request > to > > send to their friend over email > > They can send an unsigned payment request. Note that if you mail it as > an attachment from a competent, up to date email provider then the > attachment isn't really unsigned. The whole thing is covered by the > emails DKIM signature which is applied transparently by the ESP. If > the signature fails to verify then the mail client can show that or > treat the mail differently (as Gmail does). This is easy to use for > the end user - they don't have to think about cryptography or PKI. As > long as their email account is secure then they can send signed mails > asserting to their identity. > This leaves too much to chance for my taste. Forget email, what about jabber, ICQ, skype, IRC? Email is just one communications medium, there are many others for which there would be no assurance that the payment request hasn't been tampered with. You could at a minimum allow a person to create a normal ECC key, but have it used as an identity in communications rather than a payment address. You store it in a separate file in ~/.bitcoin/id ...you don't have to solve the whole set of PKI problems, people could exchange identities using any secure channel they are comfortable with (email + phone verification of a short hash id would be sufficient). In another scenario, an id could be made available over https, using the normal SSL certificate and CA infrastructure to verify authenticity. This way all messages could be signed and/or encrypted without the user having to go out of their way to use external tools or infrastructure that is often not very user friendly. You also need encryption for the "cheque" feature...asking people to use GPG would be too much of a burden (and email DKIM doesn't offer encryption). >>> wandering off topic >>> Indeed, "cheques" could become the dominant method of person to person payments...first, you would obtain someone's id, which you might already have on file (rather than obtaining a bitcoin address), then you would generate a "cheque" for the amount desired and send it to them...the recipient then has full control over what address they want to sweep the funds to as well as whether they'd like to include a miner fee to speed the confirmation along. Despite the fact that you may send many payments to the same identity, the only thing showing up on the p2p network and the block chain is the one time use address for the cheque and the recipient's wallet address. This means the recipient has much more control over the address policy used (compared with simply giving out a bitcoin address that may be reused). <<< > Refund addresses...this is not going to be as useful as people might > > think...most refunds that bitpay needs to process happen days or even > months > > after the initial purchase > > Useful feedback, thanks. Still, there may be other types of merchants > for whom it's useful, and many users won't change their wallet. It > certainly simplifies things if you can present the refund address and > give a one-click option to use it. If the user wants to use a > different address, then they can go onto the slow/complicated path. > > This current spec deliberately punts on the topic of identifying end > users. It's a difficult problem. > I know, but as I was responding, I began to realize this is a mistake. It's worthwhile to tackle that problem first...if done right, it would pay huge dividends. Also, identity is one thing, an elaborate trust based identity verification system (like CA's) is a whole other thing. I think the former is pretty simple actually...and it's all that's really needed for the time being (as I alluded, a bitcoin identity could be communicated or verified using the existing X.509/CA infrastructure if desired...you could also use the PGP infrastructure). > > I like the use of merchant_data...this means that you no longer will > need a > > unique bitcoin address for every invoice. > > It's still a good idea to use one for privacy reasons. Actually, I was speaking more in terms of relying on the address to match up a transaction to an invoice. The merchant_data field frees you from having to do that. > The merchant > data is there so you can stuff whatever state you want into it. So > it's like cookies. You don't have to keep state on the server side. > Just encrypt/sign it, put it in the invoice, and when you get a > payment message back there's no need to do database lookups or > anything, you can just do some crypto and know who is submitting it. > Yeah, that's neat...I hadn't thought of that possibility. > > Generally speaking, I'm not a fan of embedding things like that > > What's wrong with it? Isn't your proposal more complex? I don't see > why it's better than just embedding it. > It's not a big deal, I just think a referential model is more general than embedding objects within each other. > > The Receipt should be signed...it could be used as proof of payment by > > wallets. > > There's no Receipt message, a SignedPaymentRequest + transactions that > pay to the requested outputs are together the proof of payment. > Ah, I see it was renamed PaymentACK...the point of signing a PaymentACK is that while you could prove that you paid according to a PaymentRequest, a signed PaymentACK is proof that the recipient acknowledged you have made that payment. --f46d04083aad240c5a04d14dcea7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 20, 2012 at 12:43 PM, Mike Hearn <mike@plan99.net> wro= te:
> you may find yourself in a= situation needing to parse a protobuf
> message in a web browser
Nothing stops you converting them into whatever form you = want on the
server side. If you don't care about the signature checking then= it's
no probl= em to use a server. If you do then you'd need to ship all the
code for verif= ying signatures that to the client anyway, at which
point a = small protobuf parser is hardly a deal killer.

=
No, it's not a killer...just a hassle. =A0JSON is conv= enient and ubiquitous and there is something to be said for that (and I wan= ted to point out that the JOSE objection was invalid). =A0Protobufs are nic= e and efficient, but who cares. =A0You're talking about direct communic= ations rather than something that will be bounced around every node in the = mesh network. =A0I don't really care much either way, it's not wort= h debating. =A0I'm just thankful no one is arguing for XML or IIOP. =A0= :) =A0

> ...like what about the casual user that wants to cre= ate a payment request to
> send to their friend over email

They can send an unsigned payment request. Note that if you mail it a= s
an attachment from a competent, up to date email provider then the
attachment isn't really unsigned. The whole thing is covered by the
emails DKIM signature which is applied transparently by the ESP. If
the signature fails to verify then the mail client can show that or
treat the mail differently (as Gmail does). This is easy to use for
the end user - they don't have to think about cryptography or PKI. As long as their email account is secure then they can send signed mails
asserting to their identity.

This= leaves too much to chance for my taste. =A0Forget email, what about jabber= , ICQ, skype, IRC? =A0Email is just one communications medium, there are ma= ny others for which there would be no assurance that the payment request ha= sn't been tampered with. =A0You could at a minimum allow a person to cr= eate a normal ECC key, but have it used as an identity in communications ra= ther than a payment address. =A0You store it in a separate file in ~/.bitco= in/id =A0...you don't have to solve the whole set of PKI problems, peop= le could exchange identities using any secure channel they are comfortable = with (email + phone verification of a short hash id would be sufficient). = =A0In another scenario, an id could be made available over https, using the= normal SSL certificate and CA infrastructure to verify authenticity. =A0Th= is way all messages could be signed and/or encrypted without the user havin= g to go out of their way to use external tools or infrastructure that is of= ten not very user friendly. =A0You also need encryption for the "chequ= e" feature...asking people to use GPG would be too much of a burden (a= nd email DKIM doesn't offer encryption).

>>> wandering off topic >>&g= t;
Indeed, "cheques" could become the dominant me= thod of person to person payments...first, you would obtain someone's i= d, which you might already have on file (rather than obtaining a bitcoin ad= dress), then you would generate a "cheque" for the amount desired= and send it to them...the recipient then has full control over what addres= s they want to sweep the funds to as well as whether they'd like to inc= lude a miner fee to speed the confirmation along. Despite the fact that you= may send many payments to the same identity, the only thing showing up on = the p2p network and the block chain is the one time use address for the che= que and the recipient's wallet address. =A0This means the recipient has= much more control over the address policy used (compared with simply givin= g out a bitcoin address that may be reused).
<<<=A0

> Refund addresses...this is not going to be as useful as people might > think...most refunds that bitpay needs to process happen days or even = months
> after the initial purchase

Useful feedback, thanks. Still, there may be other types of merchants=
for whom it's useful, and many users won't change their wallet. It<= br> certainly simplifies things if you can present the refund address and
give a one-click option to use it. If the user wants to use a
different address, then they can go onto the slow/complicated path.

This current spec deliberately punts on the topic of identifying end
users. It's a difficult problem.

I know, but as I was responding, I began to realize this is a mistake. = =A0It's worthwhile to tackle that problem first...if done right, it wou= ld pay huge dividends. =A0Also, identity is one thing, an elaborate trust b= ased identity verification system (like CA's) is a whole other thing. = =A0I think the former is pretty simple actually...and it's all that'= ;s really needed for the time being (as I alluded, a bitcoin identity could= be communicated or verified using the existing X.509/CA infrastructure if = desired...you could also use the PGP infrastructure).
=A0
> I like the use of merchant_data...this means that you no longer will n= eed a
> unique bitcoin address for every invoice.

It's still a good idea to use one for privacy reasons.

Actually, I was speaking more in terms of rely= ing on the address to match up a transaction to an invoice. =A0The merchant= _data field frees you from having to do that.
=A0
The merchant
data is there so you can stuff whatever state you want into it. So
it's like cookies. You don't have to keep state on the server side.=
Just encrypt/sign it, put it in the invoice, and when you get a
payment message back there's no need to do database lookups or
anything, you can just do some crypto and know who is submitting it.

Yeah, that's neat...I hadn't th= ought of that possibility. =A0
=A0
> Generally speaking, I'm not a fan of embedding things like that
What's wrong with it? Isn't your proposal more complex? I don= 't see
why it's better than just embedding it.

=
It's not a big deal, I just think a referential model is mor= e general than embedding objects within each other.
=A0
> The Receipt should be signed...it could be used as proof of payment by=
> wallets.

There's no Receipt message, a SignedPaymentRequest + transactions= that
pay to the requested outputs are together the proof of payment.

Ah, I see it was renamed PaymentACK...the po= int of signing a PaymentACK is that while you could prove that you paid acc= ording to a PaymentRequest, a signed PaymentACK is proof that the recipient= acknowledged you have made that payment.

--f46d04083aad240c5a04d14dcea7--