I’m inclined to agree, as this was discussed on multiple occasions and seems to fix a lot of the address re-use problems. With hot topics like “coin validation”, I think it’s important to highlight the privacy that generating fresh addresses from public extended keys grants us.

Also thinking about implications regarding non-merchant use of Payment Protocol, encouraging the exchange of extended public keys instead of a single address could be a boon for Payment Protocol to actually be useful for users. Initially, the idea was that the merchant would generate a new address from an extended key and include that in the Payment Request. How do we handle pushing the extended public key down to the wallet itself? Do we just shoehorn the exchange of keys into the Payment Protocol itself via a special tag or would this require more substantive change? Services could develop to facilitate the exchange (acting as a sort of “PP gateway”) or wallet software might be able to directly communicate, perhaps by exchanging PGP-encrypted files in Payment Protocol format via Bluetooth, AirDrop, email, BitMessage, or whatever future communications channel comes into being.

Thanks again to Peter for putting together a consolidated list of topics!

Taylor



On Dec 19, 2013, at 2:40 PM, caedes <caedes@???> wrote:

> I feel it's missing mention of using (or not) *extended public keys*
> from bip 32 to share multiple addresses in one go, so regular payments
> can be done without asking for further addresses. Also since whoever has
> the extended key can generate public keys this might help P2SH where the
> public key is also needed.