BIP-0070 extension: instantconfirmation

[greenaddress]

As per discussion in bitcoin-dev IRC, this adds a protocol extention that can be reused by both various merchant and end users as well as various providers of instant confirmation. Feedback and comments very welcome.

[schildbach]

Without having fully understoof the contents of this pull, I feel it should go into a separate BIP extending BIP70 rather than info BIP70 itself. If we keep on amending BIP70, we'll never be able to finalize it.

[greenaddress]

@schildbach I think what you say may well be true but we've done it this way because we were told it was the process in a discussion in bitcoin-dev on IRC yesterday as well as because bip70 draft currently states:

Implementations that need to extend messages in this specification shall use tags starting at 1000, and shall update the extensions page via pull-req to avoid conflicts with other extensions.

We need to improve the context of the change but basically it is meant to be a generic way, via the payment protocol, to ask for instant confirmation and validate it via a signature from a trusted third party that can control whether the wallet end user can or can't double spend.

This is meant as a security and privacy improvement over the greenaddress concept by making all transaction multisignature and avoid address reuse (at least in our case) with deterministic keys. More context here http://blog.greenaddress.it/2014/04/18/when-you-can-and-cant-rely-on-0-confirmations/ and http://ghgreenaddress.files.wordpress.com/2014/04/greenaddressp2sh2of2hd-61.pdf

This is not intended to a be a private extension but to be reusable.

[mikehearn]

Let's discuss the best way to extend BIP70 on the mailing list.

Comments re: this design specifically. I know X.509 can seem complicated but there are good reasons to use it.

Firstly, your current design assumes merchants have a way to manually fetch a key given the domain name of the wallet. Probably those merchants will just fetch a file on your webserver over HTTPS. So you already need a certificate and have it configured already.

Secondly, your design is very simple. If this BIP became successful then someone would observe that lots of merchants have started trusting your key, but you have no way to notify them in case you need to change your key due to e.g. a server breach. So then you might be tempted to say "a correct implementation will download the key via HTTPS each time". But now there's a lot of traffic, so you'd need to amend it once again to tell people that they must respect cache headers. Some of them will forget. You're already replicating at least two features of certificates (expiry time and domain identity) but without the reusable libraries.

Now someone observes that not all wallets are websites. Perhaps a hardware wallet like the TREZOR is upgraded to start tracking which outputs it signed for and refusing to do so again. It wants to take part in this protocol too, using a device-specific key that's embedded into the chips at the factory. But now it doesn't fit with your design because there's no way to do an HTTPS GET from a TREZOR. So you say maybe the manufacturer key could sign device keys in a chain, and then the signature contains the signed device key .... now you have a cert chain.

If this new hardware wallet gets put under a scanning electron microscope and the per-device key is extracted then used for fraud, it'd be nice if there was a way to revoke it without revoking all the devices at once. Now you have OCSP.

Rather than replicating all the features of certificates that evolved over years of improvement, it seems simpler to just reuse the existing libraries for it.

[jgarzik]

(cc mailing list)

While the payment protocol may be extended, BIP 70 should not be. Draft a new BIP for any extensions.

[greenaddress]

@jgarzik By all means! We are extending the payment protocol with protobuffer exts not the BIP!

I guess the bip70 draft needs updates to reflect the intended process as there has been a bit of confusion so far :)

One question I have is: would it be required for the BIP to be out of draft status for the extension to be includable in the list of public extensions?

Also what is considered 'extending the protocol' vs 'extending the BIP' ? I am now getting more confused :(

[gavinandresen]

It is OK to register your extension in bip-0070/extensions.mediawiki after it has been implemented and is about to be used.

It is not OK to change BIP 70; if your extension is popular, then you should write another BIP to standardize it.

So NACK to this pull request.