On Thu, Apr 25, 2013 at 09:07:07PM -0400, Gavin Andresen wrote: > On Thu, Apr 25, 2013 at 3:12 PM, Jeremy Spilman > <jeremy.spil...@gmail.com>wrote: > > > Right now I'm leaning towards writing a prototype using a single cert with > > a fingerprint of PubKey in the Subject Alternate Name, and getting PubKey > > and InvoiceID in the Payment Request. Gavin, would the best way to work on > > this be to just fork your code on Github? > > > > As usual, our bottleneck is code review / testing, so it would be nice if > you spent some time reviewing code and helping test v0.9 so we can actually > ship a v1 sometime in the next several months before you start working on a > v2.
How does the current protocol protect the refund address? Protecting the payee against a compromised webserver may be out of scope for now, due to the lack of a suitable PKI, as Mike Hearn explained. But signing the refund address is a more immediate issue. There is no obvious key that the payer can use to sign the refund address. However, this can be solved right now with marginal changes to the protocol, like this: - Payee creates his PaymentDetails message with an explicit pubkey in output.script, not an address. - If payment_url is not specified then payer pays as before (he cannot sign his refund address) - If payment_url is specified then payer hashes his Payment message (with transactions zeroed out) and pays to h*pubkey, where h is the computed hash; then submits his Payment message. - Upon receiving the Payment message, payee computes the same hash and can pick his funds from h*pubkey. As long as it is trivial to reconstruct the Payment message this is completely safe. But probably this isn't the case in general. So the drawback is that the payer has to backup the Payment message before submitting it or before broadcasting the transaction, in order to keep a proof. If the payer trusted the payee then it would suffice to wait for an ACK before broadcasting. Because of the backup issue, refund address signing should probably be an option that the payer can choose after reading a backup warning. ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
