Hey all,
Interestingly enough, the original BIP75 idea started by trying to move the Payment Protocol to use JSON, but because of all of the reasons mentioned by Andreas, we ended up with protobuf. There is quite a bit of language support on both desktop and mobile platforms so that's become mostly a non-issue.
Regarding the lack of optional client-supplied identification, BIP75 was designed to solve this issue. It allows both parties in a transaction to share identity information in an out-of-band fashion in order to keep specific identity information off-chain.
With regards to extensibility of PKI usage, both BIP70 and BIP75 provide plenty of flexibility. Both the InvoiceRequest and PaymentRequest contain the pki_type and pki_data fields to allow for the use of non X.509 certificates. Currently, the only pki_types specified in both BIPs are none or x509_sha256, but there isn't any specific limit on what can be used as long as you can define a PKI type to be used, include a public key and a signature that proves control of the keypair. Perhaps a new BIP allowing for additional PKI types can be submitted, similar to how RFCs extend usage of ciphers for TLS (ie., RFC 5932).
Regarding subscriptions, and as proposed in the address book example use case in BIP75, a wallet can be setup to automatically create BIP75 transactions in order to retrieve a wallet address to pay for a subscription on whatever frequency you would like to use. The service provider can approve the first BIP75 transaction and then store the public key for that client for future use. For subsequent subscription payments, the service provider may automatically return wallet addresses for each BIP75 transaction, understanding that the subsequent BIP75 transactions are linked to the public key that was used for the first transaction and therefore the subscription has been paid for. Additionally, the BIP75 InvoiceRequest message contains a memo field that can be used to include any additional subscription information required by the subscription provider (and can be different for both first and subsequent BIP75 transactions).
This is a very interesting idea and I'd love to see how the community can work together to make Bitcoin more user and mainstream friendly while increasing security for all parties involved. All movement toward this is really the goal at Netki.
Best,
Matt David
Sr. Software Engineer
Netki, Inc.
Thanks for starting this discussion, Erik.
Should this be a new BIP? I know netki's BIP75 is out there - but I think it's too specific and too reliant on the domain name system.
This is not quite accurate. BIP75 is designed to be independent of any name resolution system. You could use it with a static URL that you share, for example, or even use it to implement a mesh-network payment system over bluetooth. Netki's wallet names do use DNS, but that isn't related to this discussion.
What BIP75 *does* do is provide a way for a client to get a new payment address for every payment. I personally think it is better than BIP47 for the uses you mentioned (subscriptions, etc).
I'm glad you brought up identity methods other than x509. At breadwallet we are thinking about how to establish the most universal system, and letting users identify themselves with any of a selection of identity systems is ideal. I think the pki_data slot should be constantly expanded to allow new identity types, but they should be explained/standardized in the BIPs that add them and use universal names. "netki://" wouldn't be appropriate, for example, if their method is open sourced and possibly used by others--it should instead be given a product name like "dnswallet://" or something more clever.
James
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev