# Gavin Andresen
# 2012-12-13 03:28:02
# https://bitcointalk.org/index.php?topic=130456.msg1396585#msg1396585

Wow, great paper! @p{par}

I like the idea of the "bill" (aka contract aka "PaymentRequest") determining the payment address, and the merchant's private bitcoin-signing key or keys being stored off their web server. @p{par}

I'll append some half-baked thoughts below on melding the current PaymentRequest proposal with your ideas. @p{par}

Using a Merkle tree to reveal (or not) parts of the bill is a nifty idea, but I think that is orthogonal to the payment protocol, and could be a generic way of encoding any document. I tend to agree with Mike, it feels like a complex solution to something that really isn't a problem right now (maybe if we ever have CyberCourts to adjudicate disputes between anonymous customers and merchants it will be useful). @p{par}

PS: I was amused by: @p{brk}

Code:
An implementation with bitcoin would require little effort.
Writing the code should be fairly straightforward; getting everybody to agree to the dozens of details we'll need to work out will be more than a little effort. @p{par}


@p{hrule}
 @p{brk}
So in the PaymentRequest protocol, a SignedPaymentRequest contains a PaymentRequest that you know came from the merchant's web server (leveraging the SSL/TLS/PKI/X.509 certificate system that we all agree is the worst PKI system there is, except for all the other that have been tried): @p{par}


Code:
SignedPaymentRequest @p{brk}
  pki_type = "x509" @p{brk}
  pki_data = ... certificate chain... @p{brk}
  signature = ... @p{brk}
  serialized_payment_request = ...PaymentRequest containing Outputs where payment will go... @p{brk}
  etc @p{brk}

 @p{brk}
As your paper points out, if an attacker compromises the webserver then they can redirect bitcoins to their wallet. @p{par}

It would be nice if that was impossible, and your paper shows how to do that.  In the PaymentRequest scheme, one way of doing that might be: @p{par}


Code:
SignedPaymentRequest @p{brk}
  pki_type = "x509_homomorphic" @p{brk}
  pki_data = ... certificate chain... @p{brk}
  signature = ... @p{brk}
  serialized_payment_request = ...PaymentRequest containing no Outputs... @p{brk}
  etc @p{brk}

 @p{brk}
The merchant's certificate in the certificate chain would have to contain their base bitcoin public key (or as you point out in the paper, generalized to a "base script"). I think that could be done using an X.509 extended attribute (anybody know if certificate authorities will sign certificates that contain non-standard extensions?). @p{par}

The customer would hash the serialized_payment_request, combine it with the base key/script, and pay to that address/script. @p{par}


@p{hrule}
The TODO list for implementing the simpler "x509" payment requests is fairly long (help appreciated by the way, see @s{(link)} ); implementing "x509_homomorphic" would make it even longer. I think we need to implement the simpler protocol first, because I think small merchants will want to re-use their existing web server certificates instead of paying for a new "x509_homomorphic" certificate that contains their "bitcoin identity" public key. @p{par}