On Thu, Dec 20, 2012 at 12:43 PM, Mike Hearn <mike@plan99.net> 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.