> Backing up a step, I'm not sure what the threat model is for signing the
> refund address? The same process that's signing the transaction is doing an
> HTTPS POST with the refund address.
>
It's a real threat, albeit an exotic one. The threat model is a malware
compromised host, with a wallet (possibly a low power hardware wallet like
a Trezor) that can understand the payment protocol and sign transactions,
but maybe not do a whole lot more than that. For instance, probably it
cannot do HTTPS connections itself. So a virus on the host could swap the
refund address for one that is owned by the attacker, and then try to make
the merchant issue an automatic refund, thus bouncing the funds back off
the merchant to the them.
If there are merchants that offer large, automatic refunds, it could be an
issue. I'm not sure how common that might be in reality. Steven or Tony
would know. Timo's protocol is an interesting solution, but again, at this
point the feature set for v1 is pretty much locked down.
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
