Even more proposed BIP extensions to BIP 0070
39 messages, 20 to 24 Jun 2016. Started by Erik Aronesty.
Erik Aronesty (9), Peter Todd (8), James MacWhyte (4), Andy Schroder (3), Justin Newton (3), Pieter Wuille (3), Andreas Schildbach (2), Luke Dashjr (2), +5 more
BIP 0070 has been a a moderate success, however, IMO:
- protocol buffers are inappropriate since ease of use and extensibility is desired over the minor gains of efficiency in this protocol. Not too late to support JSON messages as the standard going forward
- problematic reliance on merchant-supplied https (X509) as the sole form of mechant identification. alternate schemes (dnssec/netki), pgp and possibly keybase seem like good ideas. personally, i like keybase, since there is no reliance on the existing domain-name system (you can sell with a github id, for example)
- missing an optional client supplied identification
- lack of basic subscription support
*Proposed for subscriptions:*
- BIP0047 payment codes are recommended instead of wallet addresses when establishing subscriptions. Or, merchants can specify replacement addresses in ACK/NACK responses. UI confirms are *required *when there are no replacement addresses or payment codes used.
- Wallets must confirm and store subscriptions, and are responsible for initiating them at the specified interval.
- Intervals can *only *be from a preset list: weekly, biweekly, or 1, 2,3,4,6 or 12 months. Intervals missed by more than 3 days cause suspension until the user re-verifies.
- Wallets *may *optionally ask the user whether they want to be notified and confirm every interval - or not. Wallets that do not ask *must *notify before initiating each payment. Interval confirmations should begin at *least *1 day in advance of the next payment.
*Proposed in general:* - JSON should be used instead of protocol buffers going forward. Easier to use, explain extend.
- "Extendible" URI-like scheme to support multi-mode identity mechanisms on both payment and subscription requests. Support for keybase://, netki:// and others as alternates to https://.
- Support for client as well as merchant multi-mode verification
- Ideally, the identity verification URI scheme is somewhat orthogonal/independent of the payment request itself
Question:
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.
Maybe an identity-protocol-agnostic BIP + solid implementation of a couple major protocols without any mention of payment URI's ... just a way of sending and receiving identity verified messages in general?
I would be happy to implement plugins for identity protocols, if anyone thinks this is a good idea.
Does anyone think https:// or keybase, or PGP or netki all by themselves, is enough - or is it always better to have an extensible protocol?
- Erik Aronesty
Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen because of its strong types, less vulnerability to malleability and very good platform support. Having coded both, I can say Protobuf is not more difficult than JSON. (Actually the entire Bitcoin P2P protocol should be based on Protobuf, but that's another story.)
Yes, all extensions to BIP70 should go into new BIPs. Note the plural here: if you have orthogonal ideas I strongly suggest one BIP per idea so they can be discussed and implemented (or rejected) separately.
On 06/20/2016 07:33 PM, Erik Aronesty via bitcoin-dev wrote:
Quoted text (73 lines)
> BIP 0070 has been a a moderate success, however, IMO: > > - protocol buffers are inappropriate since ease of use and extensibility > is desired over the minor gains of efficiency in this protocol. Not too > late to support JSON messages as the standard going forward > > - problematic reliance on merchant-supplied https (X509) as the sole > form of mechant identification. alternate schemes (dnssec/netki), pgp > and possibly keybase seem like good ideas. personally, i like keybase, > since there is no reliance on the existing domain-name system (you can > sell with a github id, for example) > > - missing an optional client supplied identification > > - lack of basic subscription support > > /Proposed for subscriptions:/ > > - BIP0047 payment codes are recommended instead of wallet addresses when > establishing subscriptions. Or, merchants can specify replacement > addresses in ACK/NACK responses. UI confirms are /required /when there > are no replacement addresses or payment codes used. > > - Wallets must confirm and store subscriptions, and are responsible for > initiating them at the specified interval. > > - Intervals can /only /be from a preset list: weekly, biweekly, or 1, > 2,3,4,6 or 12 months. Intervals missed by more than 3 days cause > suspension until the user re-verifies. > > - Wallets /may /optionally ask the user whether they want to be notified > and confirm every interval - or not. Wallets that do not ask /must > /notify before initiating each payment. Interval confirmations should > begin at /least /1 day in advance of the next payment. > > /Proposed in general: > / > - JSON should be used instead of protocol buffers going forward. Easier > to use, explain extend. > > - "Extendible" URI-like scheme to support multi-mode identity mechanisms > on both payment and subscription requests. Support for keybase://, > netki:// and others as alternates to https://. > > - Support for client as well as merchant multi-mode verification > > - Ideally, the identity verification URI scheme is somewhat > orthogonal/independent of the payment request itself > > Question: > > 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. > > Maybe an identity-protocol-agnostic BIP + solid implementation of a > couple major protocols without any mention of payment URI's ... just a > way of sending and receiving identity verified messages in general? > > I would be happy to implement plugins for identity protocols, if anyone > thinks this is a good idea. > > Does anyone think https:// or keybase, or PGP or netki all by > themselves, is enough - or is it always better to have an extensible > protocol? > > - Erik Aronesty > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (6 lines)
> Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen > because of its strong types, less vulnerability to malleability and very > good platform support. Having coded both, I can say Protobuf is not more > difficult than JSON. (Actually the entire Bitcoin P2P protocol should be > based on Protobuf, but that's another story.) >
I like protobuf, personally, for C++ stuff. I just imagined it would be harder on mobile, or in some languages, to implement. I'll focus on the scheduling issue. Really, that's the only thing I want hashed out.
Quoted text (6 lines)
> > Yes, all extensions to BIP70 should go into new BIPs. Note the plural > here: if you have orthogonal ideas I strongly suggest one BIP per idea > so they can be discussed and implemented (or rejected) separately. > >
I think the intervals should *not* be flexible, even at the protocol level, to prevent attacks designed to confuse users - plus for shorter intervals, you need payment channels anyway. Also, I think the spec should be rigid with respect to response times, retry periods, etc.... to encourage consistency among wallet vendors. Not sure how anyone else feels about that. I suspect the netki guys should have opinions, since they are working on similar UI-stuff.
Should UI standards go somewhere else - not in a BIP? I do think there need to be UI standards. Something with RFC-style should/must/will/wont language, like "Wallet software *must* show unconfirmed transactions as distinct from confirmed", and "Wallet software *should *show some visual indication of other levels of confirmation" .... stuff like that.
Bluetooth exchange of payment requests already has a noticeable lag with protocol buffers, so that would be another reason to argue against JSON, because JSON is less efficient size wise, correct? I will say that although protocol buffers have good platform support, I don't know that the documentation for each platform is very good. This is the main drawback I see with them. One additional advantage of protocol buffers is that the .proto file is a specification, whereas with JSON, you'd just have an example file, right?
Isn't keybase a centralized infrastructure? Are you against a blockchain based identification? There are a few out there. There is some confusion because onename's efforts are breaking away from namecoin though.
I like the idea of PGP signatures of payment requests. This allows for manual verification (in my mind, the highest quality) of key authenticity (or, with PGP you also have the option to opt into some centralized service for key verification). This can be useful when dealing with semi-manually issued invoices for goods and services. The local bitcoin wallet could just interact with the local PGP keyring. Although, one can already just send the payment request in a PGP signed e-mail, so I'm not sure if PGP signing is really needed if you're using PGP email. The main benefit may just be consolidating/itemizing into your bitcoin wallet's transaction history whether the payment destination/request was securely received or not. It may also be useful for someone to be able to extract a signed payment request from a signed PGP e-mail and send it to someone else to make a payment for you (maybe you don't want your accounting person to need your entire e-mail correspondence with a supplier to be able to just verify the payment request and make a payment for your company).
I'm concerned about extending the URI scheme too much. Isn't this going to reach the practical size limit of NFC and QR codes pretty quickly?
Andy Schroder
On 06/21/2016 05:43 AM, Andreas Schildbach via bitcoin-dev wrote:
Quoted text (85 lines)
> Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen > because of its strong types, less vulnerability to malleability and very > good platform support. Having coded both, I can say Protobuf is not more > difficult than JSON. (Actually the entire Bitcoin P2P protocol should be > based on Protobuf, but that's another story.) > > Yes, all extensions to BIP70 should go into new BIPs. Note the plural > here: if you have orthogonal ideas I strongly suggest one BIP per idea > so they can be discussed and implemented (or rejected) separately. > > > On 06/20/2016 07:33 PM, Erik Aronesty via bitcoin-dev wrote: >> BIP 0070 has been a a moderate success, however, IMO: >> >> - protocol buffers are inappropriate since ease of use and extensibility >> is desired over the minor gains of efficiency in this protocol. Not too >> late to support JSON messages as the standard going forward >> >> - problematic reliance on merchant-supplied https (X509) as the sole >> form of mechant identification. alternate schemes (dnssec/netki), pgp >> and possibly keybase seem like good ideas. personally, i like keybase, >> since there is no reliance on the existing domain-name system (you can >> sell with a github id, for example) >> >> - missing an optional client supplied identification >> >> - lack of basic subscription support >> >> /Proposed for subscriptions:/ >> >> - BIP0047 payment codes are recommended instead of wallet addresses when >> establishing subscriptions. Or, merchants can specify replacement >> addresses in ACK/NACK responses. UI confirms are /required /when there >> are no replacement addresses or payment codes used. >> >> - Wallets must confirm and store subscriptions, and are responsible for >> initiating them at the specified interval. >> >> - Intervals can /only /be from a preset list: weekly, biweekly, or 1, >> 2,3,4,6 or 12 months. Intervals missed by more than 3 days cause >> suspension until the user re-verifies. >> >> - Wallets /may /optionally ask the user whether they want to be notified >> and confirm every interval - or not. Wallets that do not ask /must >> /notify before initiating each payment. Interval confirmations should >> begin at /least /1 day in advance of the next payment. >> >> /Proposed in general: >> / >> - JSON should be used instead of protocol buffers going forward. Easier >> to use, explain extend. >> >> - "Extendible" URI-like scheme to support multi-mode identity mechanisms >> on both payment and subscription requests. Support for keybase://, >> netki:// and others as alternates to https://. >> >> - Support for client as well as merchant multi-mode verification >> >> - Ideally, the identity verification URI scheme is somewhat >> orthogonal/independent of the payment request itself >> >> Question: >> >> 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. >> >> Maybe an identity-protocol-agnostic BIP + solid implementation of a >> couple major protocols without any mention of payment URI's ... just a >> way of sending and receiving identity verified messages in general? >> >> I would be happy to implement plugins for identity protocols, if anyone >> thinks this is a good idea. >> >> Does anyone think https:// or keybase, or PGP or netki all by >> themselves, is enough - or is it always better to have an extensible >> protocol? >> >> - Erik Aronesty >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>
On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote:
Quoted text (5 lines)
> BIP 0070 has been a a moderate success, however, IMO: > > - protocol buffers are inappropriate since ease of use and extensibility is > desired over the minor gains of efficiency in this protocol. Not too late > to support JSON messages as the standard going forward
IMO JSON is too prone to gratuitous inefficiency (both at network and CPU level), parser bugs, etc. Even the best C implementation (jansson) has serious issues with Number handling.
A few years ago, I looked into binary alternatives to JSON and concluded they all had problems, while it seems more than reasonable to do even dynamic parsing of protobuf messages. So to conclude, I prefer to stick to protobuf unless a clearly superior protocol turns up.
Quoted text (5 lines)
> - problematic reliance on merchant-supplied https (X509) as the sole form > of mechant identification. alternate schemes (dnssec/netki), pgp and > possibly keybase seem like good ideas. personally, i like keybase, since > there is no reliance on the existing domain-name system (you can sell with > a github id, for example)
X509 is entrenched, so it should remain supported. PGP might make sense for people already using it (it provides no real security for un-WoT-networked users), but unforunately, few people use it. Correct me if I'm wrong, but IIRC Keybase uses blockchain spam, so definitely not something to be encouraged if so. Namecoin seems like a more than reasonable decentralised solution, but will probably take some real work to implement (not that this is avoidable for a general-usage decentralised solution).
Quoted text (1 line)
> - missing an optional client supplied identification
What do you mean by this? There's the memo field at least.
Quoted text (8 lines)
> - lack of basic subscription support > > *Proposed for subscriptions:* > > - BIP0047 payment codes are recommended instead of wallet addresses when > establishing subscriptions. Or, merchants can specify replacement > addresses in ACK/NACK responses. UI confirms are *required *when there > are no replacement addresses or payment codes used.
I'd discourage anything using BIP 47 due to its serious design flaws. No reason a regular BIP 32 pub seed can't be used instead.
What do you mean by "replacement addresses" and "UI confirms" here?
Quoted text (6 lines)
> - Wallets must confirm and store subscriptions, and are responsible for > initiating them at the specified interval. > > - Intervals can *only *be from a preset list: weekly, biweekly, or 1, > 2,3,4,6 or 12 months. Intervals missed by more than 3 days cause > suspension until the user re-verifies.
Disagree with hard-coding intervals, or mandating specific policies from the service providers.
Quoted text (4 lines)
> - Wallets *may *optionally ask the user whether they want to be notified > and confirm every interval - or not. Wallets that do not ask *must > *notify before initiating each payment. Interval confirmations should > begin at *least *1 day in advance of the next payment.
This is wallet policy, but maybe makes sense as a "best practices" BIP.
Quoted text (29 lines)
> *Proposed in general:* > - JSON should be used instead of protocol buffers going forward. Easier to > use, explain extend. > > - "Extendible" URI-like scheme to support multi-mode identity mechanisms on > both payment and subscription requests. Support for keybase://, netki:// > and others as alternates to https://. > > - Support for client as well as merchant multi-mode verification > > - Ideally, the identity verification URI scheme is somewhat > orthogonal/independent of the payment request itself > > Question: > > 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. > > Maybe an identity-protocol-agnostic BIP + solid implementation of a couple > major protocols without any mention of payment URI's ... just a way of > sending and receiving identity verified messages in general? > > I would be happy to implement plugins for identity protocols, if anyone > thinks this is a good idea. > > Does anyone think https:// or keybase, or PGP or netki all by themselves, > is enough - or is it always better to have an extensible protocol? > > - Erik Aronesty
Thanks for starting this discussion, Erik.
Quoted text (3 lines)
> 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
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.
matt@netki•com
Quoted text (20 lines)
> On Jun 21, 2016, at 1:56 PM, James MacWhyte via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote: > > 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•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Quoted text (1 line)
> keybase spam
good point about keybase spam, but i think it's limited to once hash per hour (?), not really too bad... the tx's are just root signatures, so you can verify a whole keybase tree (up to the last hour) with very minimal bitcoin blockchain impact.
Quoted text (1 line)
> What do you mean by "replacement addresses" and "UI confirms" here?
"Replacement addresses" would take the place of BIP 32/47 support, if someone thought maybe that was too difficult to deal with. So each time i paid Alice, Alice could generate a new payment address for the next monthly payment. If you support BIP 32 pub seed, then there's no need for this. I don't know any wallets that support a BIP 32 pub seed (and then what, some random number generator?) as a destination address yet.
Quoted text (1 line)
> Disagree with hard-coding intervals, or mandating specific policies from
the service providers.
I think mandating is a harsh word here, but i I'm a strong believer in providing strict guidelines that if people break, others can call them on. Giving someone a 12.3 +/- 5 day interval for payments using this protocol would suck. You should use payment channels for that stuff. The idea is a lightweight protocol for getting monthly subscriptions working.
On Tue, Jun 21, 2016 at 4:44 PM, Luke Dashjr <luke@dashjr•org> wrote:
Quoted text (111 lines)
> On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote: > > BIP 0070 has been a a moderate success, however, IMO: > > > > - protocol buffers are inappropriate since ease of use and extensibility > is > > desired over the minor gains of efficiency in this protocol. Not too > late > > to support JSON messages as the standard going forward > > IMO JSON is too prone to gratuitous inefficiency (both at network and CPU > level), parser bugs, etc. Even the best C implementation (jansson) has > serious > issues with Number handling. > > A few years ago, I looked into binary alternatives to JSON and concluded > they > all had problems, while it seems more than reasonable to do even dynamic > parsing of protobuf messages. So to conclude, I prefer to stick to protobuf > unless a clearly superior protocol turns up. > > > - problematic reliance on merchant-supplied https (X509) as the sole form > > of mechant identification. alternate schemes (dnssec/netki), pgp and > > possibly keybase seem like good ideas. personally, i like keybase, > since > > there is no reliance on the existing domain-name system (you can sell > with > > a github id, for example) > > X509 is entrenched, so it should remain supported. PGP might make sense for > people already using it (it provides no real security for un-WoT-networked > users), but unforunately, few people use it. Correct me if I'm wrong, but > IIRC > Keybase uses blockchain spam, so definitely not something to be encouraged > if > so. Namecoin seems like a more than reasonable decentralised solution, but > will probably take some real work to implement (not that this is avoidable > for > a general-usage decentralised solution). > > > - missing an optional client supplied identification > > What do you mean by this? There's the memo field at least. > > > - lack of basic subscription support > > > > *Proposed for subscriptions:* > > > > - BIP0047 payment codes are recommended instead of wallet addresses when > > establishing subscriptions. Or, merchants can specify replacement > > addresses in ACK/NACK responses. UI confirms are *required *when there > > are no replacement addresses or payment codes used. > > I'd discourage anything using BIP 47 due to its serious design flaws. > No reason a regular BIP 32 pub seed can't be used instead. > > What do you mean by "replacement addresses" and "UI confirms" here? > > > - Wallets must confirm and store subscriptions, and are responsible for > > initiating them at the specified interval. > > > > - Intervals can *only *be from a preset list: weekly, biweekly, or 1, > > 2,3,4,6 or 12 months. Intervals missed by more than 3 days cause > > suspension until the user re-verifies. > > Disagree with hard-coding intervals, or mandating specific policies from > the > service providers. > > > - Wallets *may *optionally ask the user whether they want to be notified > > and confirm every interval - or not. Wallets that do not ask *must > > *notify before initiating each payment. Interval confirmations should > > begin at *least *1 day in advance of the next payment. > > This is wallet policy, but maybe makes sense as a "best practices" BIP. > > > *Proposed in general:* > > - JSON should be used instead of protocol buffers going forward. Easier > to > > use, explain extend. > > > > - "Extendible" URI-like scheme to support multi-mode identity mechanisms > on > > both payment and subscription requests. Support for keybase://, > netki:// > > and others as alternates to https://. > > > > - Support for client as well as merchant multi-mode verification > > > > - Ideally, the identity verification URI scheme is somewhat > > orthogonal/independent of the payment request itself > > > > Question: > > > > 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. > > > > Maybe an identity-protocol-agnostic BIP + solid implementation of a > couple > > major protocols without any mention of payment URI's ... just a way of > > sending and receiving identity verified messages in general? > > > > I would be happy to implement plugins for identity protocols, if anyone > > thinks this is a good idea. > > > > Does anyone think https:// or keybase, or PGP or netki all by > themselves, > > is enough - or is it always better to have an extensible protocol? > > > > - Erik Aronesty >
On Tue, Jun 21, 2016 at 08:44:37PM +0000, Luke Dashjr via bitcoin-dev wrote:
Quoted text (15 lines)
> On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote: > > BIP 0070 has been a a moderate success, however, IMO: > > > > - protocol buffers are inappropriate since ease of use and extensibility is > > desired over the minor gains of efficiency in this protocol. Not too late > > to support JSON messages as the standard going forward > > IMO JSON is too prone to gratuitous inefficiency (both at network and CPU > level), parser bugs, etc. Even the best C implementation (jansson) has serious > issues with Number handling. > > A few years ago, I looked into binary alternatives to JSON and concluded they > all had problems, while it seems more than reasonable to do even dynamic > parsing of protobuf messages. So to conclude, I prefer to stick to protobuf > unless a clearly superior protocol turns up.
I'll second that statement.
Ease of use isn't a very good criteria for security-critical software handling money, and the JSON standard has a very large amount of degrees of freedom in how people have implemented it historically. Even protobuf I'd personally avoid using on that basis, as protobuf encoding isn't deterministic: you can encode the same data in multiple ways.
Unfortunately there isn't a viable alternative, so we're probably stuck with protobuf right now for standards that want to see wide adoption in the near future; I've got a few projects that need an alternative, which I'm working on, but that's a ways off.
On Mon, Jun 20, 2016 at 05:33:32PM +0000, Erik Aronesty via bitcoin-dev wrote:
Quoted text (13 lines)
> BIP 0070 has been a a moderate success, however, IMO: > > - protocol buffers are inappropriate since ease of use and extensibility is > desired over the minor gains of efficiency in this protocol. Not too late > to support JSON messages as the standard going forward > > - problematic reliance on merchant-supplied https (X509) as the sole form > of mechant identification. alternate schemes (dnssec/netki), pgp and > possibly keybase seem like good ideas. personally, i like keybase, since > there is no reliance on the existing domain-name system (you can sell with > a github id, for example) > > - missing an optional client supplied identification
Note that "client supplied identification" is being pushed for AML/KYC compliance, e.g. Netki's AML/KYC compliance product:
http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/
This is an extremely undesirable feature to be baking into standards given it's negative impact on fungibility and privacy; we should not be adopting standards with AML/KYC support, for much the same reasons that the W3C should not be standardizing DRM.
On Tue, Jun 21, 2016 at 08:44:37PM +0000, Luke Dashjr via bitcoin-dev wrote:
Quoted text (4 lines)
> X509 is entrenched, so it should remain supported. PGP might make sense for > people already using it (it provides no real security for un-WoT-networked > users), but unforunately, few people use it. Correct me if I'm wrong, but IIRC > Keybase uses blockchain spam, so definitely not something to be encouraged if
How else would you have keybase accomplish what they're accomplishing, with the same security model?
Quoted text (14 lines)
> Note that "client supplied identification" is being pushed for AML/KYC > compliance, e.g. Netki's AML/KYC compliance product: > > > http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/ > > This is an extremely undesirable feature to be baking into standards given > it's > negative impact on fungibility and privacy; we should not be adopting > standards > with AML/KYC support, for much the same reasons that the W3C should not be > standardizing DRM. > >
KYC isn't the only use case. There are other situations in which you would want to confirm who is sending you money. Making it *required* would of course be a horrible idea, but allowing people to identify themselves, in many cases with an online-only identity that isn't tied to their real world identity, will be very useful to newly-developing use cases.
On Tue, Jun 21, 2016 at 10:50:36PM +0000, James MacWhyte wrote:
Quoted text (19 lines)
> > Note that "client supplied identification" is being pushed for AML/KYC > > compliance, e.g. Netki's AML/KYC compliance product: > > > > > > http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/ > > > > This is an extremely undesirable feature to be baking into standards given > > it's > > negative impact on fungibility and privacy; we should not be adopting > > standards > > with AML/KYC support, for much the same reasons that the W3C should not be > > standardizing DRM. > > > > > KYC isn't the only use case. There are other situations in which you would > want to confirm who is sending you money. Making it *required* would of > course be a horrible idea, but allowing people to identify themselves, in > many cases with an online-only identity that isn't tied to their real world > identity, will be very useful to newly-developing use cases.
It's easy to confirm who is sending you money: give out different addresses to different people, and keep those addresses private.
On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (18 lines)
> On Mon, Jun 20, 2016 at 05:33:32PM +0000, Erik Aronesty via bitcoin-dev > wrote: > > > - missing an optional client supplied identification > > Note that "client supplied identification" is being pushed for AML/KYC > compliance, e.g. Netki's AML/KYC compliance product: > > > http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/ > > This is an extremely undesirable feature to be baking into standards given > it's > negative impact on fungibility and privacy; we should not be adopting > standards > with AML/KYC support, for much the same reasons that the W3C should not be > standardizing DRM. >
Hi Peter, Certainly AML/KYC compliance is one of the use cases that BIP 75 and our certificates can support. As a quick summary,
There are individuals and entities that would like to buy, sell, and use bitcoin, and other public blockchains, but that have compliance requirements that they need to meet before they can do so. Similarly, companies and entrepreneurs in the space suffer under the potential threat of fines, or in extreme cases, jail time, also for not meeting AML or sanctions list compliance. We wanted to build tools that allowed entrepreneurs to breathe easy, while at the same time allow more people and companies to enter the ecosystem. We also believe that the solution we are using has the characteristics that you want in such a solution, for example:
1> Only the counterparties (and possibly their service providers in the case of hosted services) in a transaction can see the identity data, protecting user privacy.
2> The counterparties themselves (and possibly their service providers in the case of hosted services) decide whether identity information is required for any given transaction.
3> No trace is left on the blockchain or anywhere else (other than with the counterparties) that identity information was even exchanged, protecting fungibility
4> The solution is based on open source and open standards, allowing open permissionless innovation, versus parties building closed networks based on closed standards. The very fact that this solution went through the BIP process and was adapted based on feedback is an example of how this is better for users than the inevitable closed solution that would arise if the open source, community vetted version didn’t already exist.
I don’t know if you are opposed to organizations that have AML requirements from using the bitcoin blockchain, but if you aren’t, why wouldn’t you prefer an open source, open standards based solution to exclusionary, proprietary ones?
BIP 70 and BIP 75 are standards for voluntary information exchange between counterparties in a transaction. This is exactly the kind of thing we want standards for, in my experience.
On Tuesday, June 21, 2016 9:42:39 PM Erik Aronesty wrote:
Quoted text (6 lines)
> > What do you mean by "replacement addresses" and "UI confirms" here? > > "Replacement addresses" would take the place of BIP 32/47 support, if > someone thought maybe that was too difficult to deal with. So each time i > paid Alice, Alice could generate a new payment address for the next monthly > payment. If you support BIP 32 pub seed, then there's no need for this.
I suppose it makes sense that since every payment requires communication with the recipient, that the recipient could give you a new scriptPubKey each time. No need to save [potentially compromised] payment info in advance?
Quoted text (2 lines)
> I don't know any wallets that support a BIP 32 pub seed (and then what, > some random number generator?) as a destination address yet.
The point, as I see it, of payment protocol(s) is to deprecate addresses. ie, this new protocol *could be* the BIP 32 pub seed destination address. ;)
Quoted text (9 lines)
> > Disagree with hard-coding intervals, or mandating specific policies from > > the service providers. > > I think mandating is a harsh word here, but i I'm a strong believer in > providing strict guidelines that if people break, others can call them > on. Giving someone a 12.3 +/- 5 day interval for payments using this > protocol would suck. You should use payment channels for that stuff. > The idea is a lightweight protocol for getting monthly subscriptions > working.
Maybe just a field specifying how far in advance payments should be sent, then?
Luke
IMO the moderate success of BIP70 is caused by its complexity. Since the amount of data in a BIP70 payment request does not fit in a bitcoin: URI, an https server is required to serve the requests.
Only large merchants are able to maintain such an infrastructure; (even Coinbase recently failed at it, they forgot to update their certificate). For end users that is completely unpractical.
The main benefit of BIP70 is that the payment request is signed by the requestor; this gives the sender a proof that they are sending to the right person, and that the person actually requested the payment.
The same benefit can be achieved without the complexity of BIP70, by extending the Bitcoin URI scheme. The requestor is authenticated using DNSSEC, and the payment request is signed using an EC private key. A domain name and an EC signature are short enough to fit in a Bitcoin URI and to be shared by QR code or SMS text.
bitcoin:address?amount=xx&message=yyy&name=john.example.com&sig=zzz
The URI scheme is extended with two fields: name: DNS name containing a public key or bitcoin address sig: signature
That extension is sufficient to provide authenticated requests, without requiring a https server. The signed data can be serialized from the URI, and DNSSEC verification succeeds without requesting extra data from the requestor. The only assumption is that the verifier is able to make DNS requests.
I am willing to write a BIP if other wallet developers are interested.
Le 20/06/2016 19:33, Erik Aronesty via bitcoin-dev a écrit :
Quoted text (73 lines)
> BIP 0070 has been a a moderate success, however, IMO: > > - protocol buffers are inappropriate since ease of use and extensibility is > desired over the minor gains of efficiency in this protocol. Not too late > to support JSON messages as the standard going forward > > - problematic reliance on merchant-supplied https (X509) as the sole form > of mechant identification. alternate schemes (dnssec/netki), pgp and > possibly keybase seem like good ideas. personally, i like keybase, since > there is no reliance on the existing domain-name system (you can sell with > a github id, for example) > > - missing an optional client supplied identification > > - lack of basic subscription support > > *Proposed for subscriptions:* > > - BIP0047 payment codes are recommended instead of wallet addresses when > establishing subscriptions. Or, merchants can specify replacement > addresses in ACK/NACK responses. UI confirms are *required *when there > are no replacement addresses or payment codes used. > > - Wallets must confirm and store subscriptions, and are responsible for > initiating them at the specified interval. > > - Intervals can *only *be from a preset list: weekly, biweekly, or 1, > 2,3,4,6 or 12 months. Intervals missed by more than 3 days cause > suspension until the user re-verifies. > > - Wallets *may *optionally ask the user whether they want to be notified > and confirm every interval - or not. Wallets that do not ask *must *notify > before initiating each payment. Interval confirmations should begin at *least > *1 day in advance of the next payment. > > > *Proposed in general:* > - JSON should be used instead of protocol buffers going forward. Easier to > use, explain extend. > > - "Extendible" URI-like scheme to support multi-mode identity mechanisms on > both payment and subscription requests. Support for keybase://, netki:// > and others as alternates to https://. > > - Support for client as well as merchant multi-mode verification > > - Ideally, the identity verification URI scheme is somewhat > orthogonal/independent of the payment request itself > > Question: > > 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. > > Maybe an identity-protocol-agnostic BIP + solid implementation of a couple > major protocols without any mention of payment URI's ... just a way of > sending and receiving identity verified messages in general? > > I would be happy to implement plugins for identity protocols, if anyone > thinks this is a good idea. > > Does anyone think https:// or keybase, or PGP or netki all by themselves, > is enough - or is it always better to have an extensible protocol? > > - Erik Aronesty > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Quoted text (4 lines)
> Only large merchants are able to maintain such an infrastructure; (even > Coinbase recently failed at it, they forgot to update their > certificate). For end users that is completely unpractical. >
Payment protocol is for when you buy stuff from purse.io, not really needed for face-to face transfers, end users, IMO.
Quoted text (8 lines)
> The same benefit can be achieved without the complexity of BIP70, by > extending the Bitcoin URI scheme. The requestor is authenticated using > DNSSEC, and the payment request is signed using an EC private key. A > domain name and an EC signature are short enough to fit in a Bitcoin URI > and to be shared by QR code or SMS text. > > bitcoin:address?amount=xx&message=yyy&name=john.example.com&sig=zzz >
I agree. A TXT record at that name could contain the pubkey.
Quoted text (6 lines)
> That extension is sufficient to provide authenticated requests, without > requiring a https server. The signed data can be serialized from the > URI, and DNSSEC verification succeeds without requesting extra data from > the requestor. The only assumption is that the verifier is able to make > DNS requests. >
The problem is that there's no way for a merchant to *refuse *a payment without a direct communication with the merchant's server. Verify first / clear later is the rule. Check stock, ensure you can deliver, and clear the payment on the way out the door.
Also, as a merchant processing monthly subscriptions, you don't want the first time you hear about a user's payment to be *after *it hits the blockchain. You could add a refund address to deal with it after the fact... stuff a refund address int OP_RETURN somehow?
bitcoin:address?amount=xx¤cy=ccc&message=yyy&name=john.example.com &offset=3d&interval=1m&sig=zzz
... But what if the merchant simply goes out of business. No OP_RETURN will help you here. You'll be posting transactions into a dead wallet. You could have some way of posting a "ping" transaction, and then monitoring for a valid response. But this is "spamming the blockchain for communications".
No, I think BIP075 is fine. You just need to extend the *PaymentAck *with a single field, instead of just having a memo.
next_payment_days : integer
The wallet, when it sees this field, re-initiates an invoice request after the selected number of days, after presenting the user with the content of the memo field which will presumably explain the subscription. Wallet vendors can let users "auto approve" vendors as needed.
This is, I think, the absolute minimum needed to update BIP0070/0075 for subscriptions.
Quoted text (10 lines)
> > Only large merchants are able to maintain such an infrastructure; > (even > Coinbase recently failed at it, they forgot to update their > certificate). For end users that is completely unpractical. > > > Payment protocol is for when you buy stuff from purse.io > <http://purse.io>, not really needed for face-to face transfers, end > users, IMO.
I disagree with your statements. There are many face to face use cases where the payment protocol is essential. Pretty much anything where the payee's hardware device that the payer interacts with is automated in public and/or operated or accessible by untrusted employees. In any of those cases the software on the payee's hardware device can be modified. Providing a signed payment request gives the payer additional confidence that they are paying the correct person.
See some examples here: http://andyschroder.com/BitcoinFluidDispenser/2.3/
There was a secure bluetooth protocol that Andreas Schildbach and Eric Voskuil and I were working on, but we never pulled it all the way together. This would also need a two way exchange for a face to face payment. This could be used without using some sort of key/certificate verification service if being done between two humans who are the direct senders and receivers of the payment and are using hardware that they personally own (not necessarily the case of untrusted employees or public vulnerable machines).
Quoted text (12 lines)
> The same benefit can be achieved without the complexity of BIP70, by > extending the Bitcoin URI scheme. The requestor is authenticated using > DNSSEC, and the payment request is signed using an EC private key. A > domain name and an EC signature are short enough to fit in a > Bitcoin URI > and to be shared by QR code or SMS text. > > bitcoin:address?amount=xx&message=yyy&name=john.example.com > <http://john.example.com>&sig=zzz > > > I agree. A TXT record at that name could contain the pubkey.
Did you not see my previous message about the size of the bitcoin: URI getting too big for NFC and QR codes? Do you not care about giving the payer the option of using multiple destination payment addresses? This is important for many reasons.
Quoted text (14 lines)
> That extension is sufficient to provide authenticated requests, > without > requiring a https server. The signed data can be serialized from the > URI, and DNSSEC verification succeeds without requesting extra > data from > the requestor. The only assumption is that the verifier is able to > make > DNS requests. > > > The problem is that there's no way for a merchant to /refuse /a > payment without a direct communication with the merchant's server. > Verify first / clear later is the rule. Check stock, ensure you can > deliver, and clear the payment on the way out the door.
So, are you saying first the payer should send an unsigned transaction for review, and then once the payee has agreed it's good, they can send an ACK message back and then wait for the signed version? I don't think this is a bad option to have. Many wallets simultaneously broadcast a signed transaction to their peers and and also back to the payee via https or bluetooth. So, you'd have to add another step to do the unsigned transaction review in order to avoid a transaction being accidentally broadcast that both parties don't like.
Quoted text (8 lines)
> > Also, as a merchant processing monthly subscriptions, you don't want > the first time you hear about a user's payment to be /after /it hits > the blockchain. You could add a refund address to deal with it after > the fact... stuff a refund address int OP_RETURN somehow? > > bitcoin:address?amount=xx¤cy=ccc&message=yyy&name=john.example.com > <http://john.example.com>&offset=3d&interval=1m&sig=zzz
Again, my comments above about issues with using bitcoin: URI for everything. Also, why do you want to bloat the blockchain with unnecessary refund transaction data?
Quoted text (1 line)
> Again, my comments above about issues with using bitcoin: URI for
everything. Also, why do you want to bloat the blockchain with unnecessary refund transaction data?
I don't, sorry - I was just kind of thinking out loud and explaining what happens when you stuff that into a URL.
My conclusion at the bottom of that post was to keep BIP 75 the same, don't change a bit, and stick any subscription information (future payment schedule) in the PaymentACK. Then the wallet then re-initiates an invoice (unattended or attended.. up to the user), after the subscription interval is passed. Subscriptions are pretty important for Bitcoin to be used as a real payment system.
I understand the need for people to make repeated payments to individuals in real life that they know, without the payee every even taking the effort to make a formal payment request (say you're just paying a family member of friend back for picking something up for you at the store, and you've already payed them many times before).
For a subscription, wouldn't it be better to promote payment channels or just send another payment request? I've been brainstorming recently about a model where service providers could deliver invoices, receipts, and payment requests in a standardized and secure way. In addition to having a send, receive, and transaction history tab in your bitcoin wallet, you'd also have an open payment channels tab (which would include all applications on your computer that have an open real time payment channel, such as a wifi access point, web browser, voip provider, etc.), as well as a "bills to pay" tab. Since everything would be automated and consolidated locally, you wouldn't have to deal with logging into a million different websites to get the bills and then pay them. If it were this easy, why would you ever want to do a recurring payment from a single payment request? I understand why you may think you want to given current work flows, but I'm wondering if it may be better to just skip over to a completely better way of doing things.
Andy Schroder
On 06/22/2016 11:30 AM, Erik Aronesty wrote:
Quoted text (6 lines)
> My conclusion at the bottom of that post was to keep BIP 75 the same, > don't change a bit, and stick any subscription information (future > payment schedule) in the PaymentACK. Then the wallet then > re-initiates an invoice (unattended or attended.. up to the user), > after the subscription interval is passed. Subscriptions are pretty > important for Bitcoin to be used as a real payment system.
- Payment channels seem clearly inappropriate for things like monthly subscriptions, the use of nlocktime, etc.
- Merchants cannot send requests to users for future payments, because users don't run servers that they can connect to. That's why BIP0070 works the way it does.
- Need to have an interval for subscriptions, at a minimum, and stored in the wallet so next months payment can go out on time
- Support for varying currency conversion needs to be baked in to wallets. Fortunately, by adding advisory subscription info to the paymentrequest, this is left up to the wallet to secure/validate/repeat/convert/etc. as needed for each subscription.
- The UI you describe is nice - but not unique to the solution.
On Wed, Jun 22, 2016 at 12:20 PM, Andy Schroder <info@andyschroder•com> wrote:
Quoted text (37 lines)
> I understand the need for people to make repeated payments to individuals > in real life that they know, without the payee every even taking the effort > to make a formal payment request (say you're just paying a family member of > friend back for picking something up for you at the store, and you've > already payed them many times before). > > For a subscription, wouldn't it be better to promote payment channels or > just send another payment request? I've been brainstorming recently about a > model where service providers could deliver invoices, receipts, and payment > requests in a standardized and secure way. In addition to having a send, > receive, and transaction history tab in your bitcoin wallet, you'd also > have an open payment channels tab (which would include all applications on > your computer that have an open real time payment channel, such as a wifi > access point, web browser, voip provider, etc.), as well as a "bills to > pay" tab. Since everything would be automated and consolidated locally, you > wouldn't have to deal with logging into a million different websites to get > the bills and then pay them. If it were this easy, why would you ever want > to do a recurring payment from a single payment request? I understand why > you may think you want to given current work flows, but I'm wondering if it > may be better to just skip over to a completely better way of doing things. > > > Andy Schroder > > > On 06/22/2016 11:30 AM, Erik Aronesty wrote: > >> My conclusion at the bottom of that post was to keep BIP 75 the same, >> don't change a bit, and stick any subscription information (future payment >> schedule) in the PaymentACK. Then the wallet then re-initiates an invoice >> (unattended or attended.. up to the user), after the subscription interval >> is passed. Subscriptions are pretty important for Bitcoin to be used as a >> real payment system. >> > > >
Thomas,
I like your idea about expanding Bitcoin URI's to include signatures. For BIP75 store and forward servers we are already thinking the DNS record would have the user's public key as well as the URL of their store and forward endpoint, so as soon as that becomes a standard you could use it just for the public key part. Expanding the Bitcoin URI should be done as well, for people who want to go the simpler route and not rely on servers.
Erik, Andy, everyone else,
I don't understand why subscriptions would need to be built into the protocol. With BIP75 the merchant could automatically issue a PaymentRequest message every X amount of time, and the customer's wallet would either display the request like normal or be set to pre-authorize requests from the merchant. If the merchant goes out of business, the requests would stop coming. This sounds like a UI issue and not a protocol-level requirement.
If you think I'm wrong, please explain why :)
On Wed, Jun 22, 2016 at 12:35 PM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (65 lines)
> - Payment channels seem clearly inappropriate for things like monthly > subscriptions, the use of nlocktime, etc. > > - Merchants cannot send requests to users for future payments, because > users don't run servers that they can connect to. That's why BIP0070 works > the way it does. > > - Need to have an interval for subscriptions, at a minimum, and stored in > the wallet so next months payment can go out on time > > - Support for varying currency conversion needs to be baked in to > wallets. Fortunately, by adding advisory subscription info to the > paymentrequest, this is left up to the wallet to > secure/validate/repeat/convert/etc. as needed for each subscription. > > - The UI you describe is nice - but not unique to the solution. > > > > > On Wed, Jun 22, 2016 at 12:20 PM, Andy Schroder <info@andyschroder•com> > wrote: > >> I understand the need for people to make repeated payments to individuals >> in real life that they know, without the payee every even taking the effort >> to make a formal payment request (say you're just paying a family member of >> friend back for picking something up for you at the store, and you've >> already payed them many times before). >> >> For a subscription, wouldn't it be better to promote payment channels or >> just send another payment request? I've been brainstorming recently about a >> model where service providers could deliver invoices, receipts, and payment >> requests in a standardized and secure way. In addition to having a send, >> receive, and transaction history tab in your bitcoin wallet, you'd also >> have an open payment channels tab (which would include all applications on >> your computer that have an open real time payment channel, such as a wifi >> access point, web browser, voip provider, etc.), as well as a "bills to >> pay" tab. Since everything would be automated and consolidated locally, you >> wouldn't have to deal with logging into a million different websites to get >> the bills and then pay them. If it were this easy, why would you ever want >> to do a recurring payment from a single payment request? I understand why >> you may think you want to given current work flows, but I'm wondering if it >> may be better to just skip over to a completely better way of doing things. >> >> >> Andy Schroder >> >> >> On 06/22/2016 11:30 AM, Erik Aronesty wrote: >> >>> My conclusion at the bottom of that post was to keep BIP 75 the same, >>> don't change a bit, and stick any subscription information (future payment >>> schedule) in the PaymentACK. Then the wallet then re-initiates an invoice >>> (unattended or attended.. up to the user), after the subscription interval >>> is passed. Subscriptions are pretty important for Bitcoin to be used as a >>> real payment system. >>> >> >> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Quoted text (1 line)
> I don't understand why subscriptions would need to be built into the
protocol.
Simple: Because the PaymentRequest is somewhat counter-intuitively a /response/ to a customer initiated action. It's not something the merchant can initiate (of course, logically this makes sense... how can a merchant know how to connect to some random android app).
Customers initiate all InvoiceRequests BIP0075 clarifies this. BIP0070 merely says that the customer "somehow indicates they are ready to pay". BIP0075 formalizes a standard way to do this.
In no way do merchants initiate anything (of course). Subscription information must reside in the customers wallet, in response to a merchant's advice to set up subscription. Tacking parameters on to a PaymentRequest or PaymentAck is the only good way to do this within BIP 70/75.
The only thing to hash out is exactly what fields to tack on and what they mean. ( subscription amount / currency / interval / interval_type ... can't think of anything else )
Wallets are responsible for initiating the subscriptions on behalf of the user. Recommendations on how to do this should go into the spec.
Of course any wallet can, with BIP0075 add support for subscriptions without any spec - just let the user set them up manually. But it would be nice if a user didn't have to enter the main parameters for subscriptions... too easy to get times amounts, etc wrong.
On Wed, Jun 22, 2016 at 4:11 PM, James MacWhyte <macwhyte@gmail•com> wrote:
Quoted text (90 lines)
> Thomas, > > I like your idea about expanding Bitcoin URI's to include signatures. For > BIP75 store and forward servers we are already thinking the DNS record > would have the user's public key as well as the URL of their store and > forward endpoint, so as soon as that becomes a standard you could use it > just for the public key part. Expanding the Bitcoin URI should be done as > well, for people who want to go the simpler route and not rely on servers. > > Erik, Andy, everyone else, > > I don't understand why subscriptions would need to be built into the > protocol. With BIP75 the merchant could automatically issue a > PaymentRequest message every X amount of time, and the customer's wallet > would either display the request like normal or be set to pre-authorize > requests from the merchant. If the merchant goes out of business, the > requests would stop coming. This sounds like a UI issue and not a > protocol-level requirement. > > If you think I'm wrong, please explain why :) > > On Wed, Jun 22, 2016 at 12:35 PM Erik Aronesty via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > >> - Payment channels seem clearly inappropriate for things like monthly >> subscriptions, the use of nlocktime, etc. >> >> - Merchants cannot send requests to users for future payments, because >> users don't run servers that they can connect to. That's why BIP0070 works >> the way it does. >> >> - Need to have an interval for subscriptions, at a minimum, and stored in >> the wallet so next months payment can go out on time >> >> - Support for varying currency conversion needs to be baked in to >> wallets. Fortunately, by adding advisory subscription info to the >> paymentrequest, this is left up to the wallet to >> secure/validate/repeat/convert/etc. as needed for each subscription. >> >> - The UI you describe is nice - but not unique to the solution. >> >> >> >> >> On Wed, Jun 22, 2016 at 12:20 PM, Andy Schroder <info@andyschroder•com> >> wrote: >> >>> I understand the need for people to make repeated payments to >>> individuals in real life that they know, without the payee every even >>> taking the effort to make a formal payment request (say you're just paying >>> a family member of friend back for picking something up for you at the >>> store, and you've already payed them many times before). >>> >>> For a subscription, wouldn't it be better to promote payment channels or >>> just send another payment request? I've been brainstorming recently about a >>> model where service providers could deliver invoices, receipts, and payment >>> requests in a standardized and secure way. In addition to having a send, >>> receive, and transaction history tab in your bitcoin wallet, you'd also >>> have an open payment channels tab (which would include all applications on >>> your computer that have an open real time payment channel, such as a wifi >>> access point, web browser, voip provider, etc.), as well as a "bills to >>> pay" tab. Since everything would be automated and consolidated locally, you >>> wouldn't have to deal with logging into a million different websites to get >>> the bills and then pay them. If it were this easy, why would you ever want >>> to do a recurring payment from a single payment request? I understand why >>> you may think you want to given current work flows, but I'm wondering if it >>> may be better to just skip over to a completely better way of doing things. >>> >>> >>> Andy Schroder >>> >>> >>> On 06/22/2016 11:30 AM, Erik Aronesty wrote: >>> >>>> My conclusion at the bottom of that post was to keep BIP 75 the same, >>>> don't change a bit, and stick any subscription information (future payment >>>> schedule) in the PaymentACK. Then the wallet then re-initiates an invoice >>>> (unattended or attended.. up to the user), after the subscription interval >>>> is passed. Subscriptions are pretty important for Bitcoin to be used as a >>>> real payment system. >>>> >>> >>> >>> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >
On Tue, Jun 21, 2016 at 05:14:31PM -0700, Justin Newton wrote:
Quoted text (38 lines)
> On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev < > Hi Peter, > Certainly AML/KYC compliance is one of the use cases that BIP 75 and our > certificates can support. As a quick summary, > > There are individuals and entities that would like to buy, sell, and use > bitcoin, and other public blockchains, but that have compliance > requirements that they need to meet before they can do so. Similarly, > companies and entrepreneurs in the space suffer under the potential threat > of fines, or in extreme cases, jail time, also for not meeting AML or > sanctions list compliance. We wanted to build tools that allowed > entrepreneurs to breathe easy, while at the same time allow more people and > companies to enter the ecosystem. We also believe that the solution we are > using has the characteristics that you want in such a solution, for example: > > 1> Only the counterparties (and possibly their service providers in the > case of hosted services) in a transaction can see the identity data, > protecting user privacy. > > 2> The counterparties themselves (and possibly their service providers in > the case of hosted services) decide whether identity information is > required for any given transaction. > > 3> No trace is left on the blockchain or anywhere else (other than with the > counterparties) that identity information was even exchanged, protecting > fungibility > > 4> The solution is based on open source and open standards, allowing open > permissionless innovation, versus parties building closed networks based on > closed standards. The very fact that this solution went through the BIP > process and was adapted based on feedback is an example of how this is > better for users than the inevitable closed solution that would arise if > the open source, community vetted version didn’t already exist. > > I don’t know if you are opposed to organizations that have AML requirements > from using the bitcoin blockchain, but if you aren’t, why wouldn’t you > prefer an open source, open standards based solution to exclusionary, > proprietary ones?
In some (most?) countries, it is illegal to offer telecoms services without wiretap facilities. Does that mean Tor builds into its software "open source" "open standards" wiretapping functionality? No. And interestingly, people trying to add support for that stuff is actually a thing that keeps happening in the Tor community...
In any case, I'd strongly argue that we remove BIP75 from the bips repository, and boycott wallets that implement it. It's bad strategy for Bitcoin developers to willingly participate in AML/KYC, just the same way as it's bad for Tor to add wiretapping functionality, and W3C to support DRM tech. The minor tactical wins you'll get our of this aren't worth it.
On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (1 line)
> In any case, I'd strongly argue that we remove BIP75 from the bips
repository,
Quoted text (1 line)
> and boycott wallets that implement it. It's bad strategy for Bitcoin
developers
Quoted text (1 line)
> to willingly participate in AML/KYC, just the same way as it's bad for
Tor to
Quoted text (1 line)
> add wiretapping functionality, and W3C to support DRM tech. The minor
tactical
Quoted text (1 line)
> wins you'll get our of this aren't worth it.
I hope you're not seriously suggesting to censor a BIP because you feel it is a bad idea.
On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote:
Quoted text (15 lines)
> On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" < > bitcoin-dev@lists•linuxfoundation•org> wrote: > > > In any case, I'd strongly argue that we remove BIP75 from the bips > repository, > > and boycott wallets that implement it. It's bad strategy for Bitcoin > developers > > to willingly participate in AML/KYC, just the same way as it's bad for > Tor to > > add wiretapping functionality, and W3C to support DRM tech. The minor > tactical > > wins you'll get our of this aren't worth it. > > I hope you're not seriously suggesting to censor a BIP because you feel it > is a bad idea.
For the record, I think the idea of the bips repo being a pure publication platform isn't a good one and doesn't match reality; like it or not by accepting bips we're putting a stamp of some kind of approval on them.
For example, I suspect I wouldn't be able to get a BIP for a decentralized assassination market protocol standard into the repository, regardless of whether or not it was used - it's simply too distastful and controversial for us to want to merge that. Would you call that rejection censorship?
I have zero issues with us exercising editorial control over what's in the bips repo; us doing so doesn't in any way prevent other's from publishing elsewhere.
On 06/22/2016 04:25 PM, Erik Aronesty via bitcoin-dev wrote:
Quoted text (9 lines)
> > Only large merchants are able to maintain such an infrastructure; (even > Coinbase recently failed at it, they forgot to update their > certificate). For end users that is completely unpractical. > > > Payment protocol is for when you buy stuff from purse.io > <http://purse.io>, not really needed for face-to face transfers, end > users, IMO.
What Andy said, plus there is an (unencrypted) version of BIP70 via Bluetooth already in place. And its used in several thousand face-to-face trades per day.
On Thu, Jun 23, 2016 at 1:39 PM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (20 lines)
> On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote: >> On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" < >> bitcoin-dev@lists•linuxfoundation•org> wrote: >> >> > In any case, I'd strongly argue that we remove BIP75 from the bips >> repository, >> > and boycott wallets that implement it. It's bad strategy for Bitcoin >> developers >> > to willingly participate in AML/KYC, just the same way as it's bad for >> Tor to >> > add wiretapping functionality, and W3C to support DRM tech. The minor >> tactical >> > wins you'll get our of this aren't worth it. >> >> I hope you're not seriously suggesting to censor a BIP because you feel it >> is a bad idea. > > For the record, I think the idea of the bips repo being a pure publication > platform isn't a good one and doesn't match reality; like it or not by > accepting bips we're putting a stamp of some kind of approval on them.
We? I don't feel like I have any authority to say what goes into that repository, and neither do you. We just give technical opinion on proposals. The fact that it's under the bitcoin organization on github is a historical artifact.
Quoted text (2 lines)
> I have zero issues with us exercising editorial control over what's in the bips > repo; us doing so doesn't in any way prevent other's from publishing elsewhere.
Editorial control is inevitable to some extent, but I think that's more a matter of process than of opinion. Things like "Was there community discussion?", "Is it relevant?", "Is there a reference implementation?". I don't think that you objecting for moral reasons to an otherwise technically sound idea is a reason for removal of a BIP. You are of course free to propose alternatives, or recommend against its usage.
On Thu, Jun 23, 2016 at 02:01:10PM +0200, Pieter Wuille wrote:
Quoted text (10 lines)
> On Thu, Jun 23, 2016 at 1:39 PM, Peter Todd <pete@petertodd•org> wrote: > > On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote: > > For the record, I think the idea of the bips repo being a pure publication > > platform isn't a good one and doesn't match reality; like it or not by > > accepting bips we're putting a stamp of some kind of approval on them. > > We? I don't feel like I have any authority to say what goes into that > repository, and neither do you. We just give technical opinion on > proposals. The fact that it's under the bitcoin organization on github > is a historical artifact.
That's simply not how the rest of the community perceives bips, and until we move them elsewhere that's not going to change.
No matter how much we scream that we don't have authority, the fact of the matter is the bips are located under the github.com/bitcoin namespace, and we do have editorial control over them.
Quoted text (10 lines)
> > I have zero issues with us exercising editorial control over what's in the bips > > repo; us doing so doesn't in any way prevent other's from publishing elsewhere. > > Editorial control is inevitable to some extent, but I think that's > more a matter of process than of opinion. Things like "Was there > community discussion?", "Is it relevant?", "Is there a reference > implementation?". I don't think that you objecting for moral reasons > to an otherwise technically sound idea is a reason for removal of a > BIP. You are of course free to propose alternatives, or recommend > against its usage.
Right, so you accept that we'll exert some degree of editorial control; the question now is what editorial policies should we exert?
My argument is that rejecting BIP75 is something we should do on ethical/strategic grounds. You may disagree with that, but please don't troll and call that "advocating censorship"
On Jun 23, 2016 14:10, "Peter Todd" <pete@petertodd•org> wrote:
Quoted text (1 line)
> Right, so you accept that we'll exert some degree of editorial control;
the
Quoted text (1 line)
> question now is what editorial policies should we exert?
No, I do not. I am saying that some degree of editorial control will inevitably exist, simply because there is some human making the choice of assigning a BIP number and merging. My opinion is that we should try to restrict that editorial control to only be subject to objective process, and not be dependent on personal opinions.
Quoted text (2 lines)
> My argument is that rejecting BIP75 is something we should do on > ethical/strategic grounds. You may disagree with that, but please don't
troll
Quoted text (1 line)
> and call that "advocating censorship"
I think that you are free to express dislike of BIP75. Suggesting to remove it for that reason is utterly ridiculous to me, whatever you want to call it.
On Thu, Jun 23, 2016 at 02:16:48PM +0200, Pieter Wuille wrote:
Quoted text (20 lines)
> On Jun 23, 2016 14:10, "Peter Todd" <pete@petertodd•org> wrote: > > > Right, so you accept that we'll exert some degree of editorial control; > the > > question now is what editorial policies should we exert? > > No, I do not. I am saying that some degree of editorial control will > inevitably exist, simply because there is some human making the choice of > assigning a BIP number and merging. My opinion is that we should try to > restrict that editorial control to only be subject to objective process, > and not be dependent on personal opinions. > > > My argument is that rejecting BIP75 is something we should do on > > ethical/strategic grounds. You may disagree with that, but please don't > troll > > and call that "advocating censorship" > > I think that you are free to express dislike of BIP75. Suggesting to remove > it for that reason is utterly ridiculous to me, whatever you want to call > it.
In the future we're likely to see a lot of BIPs around AML/KYC support, e.g. adding personal identity information to transactions, blacklist standards, etc. Should we accept those BIPs into the bips repo?
AML/KYC is a *side-effect *of a some very important features of BIP0075.
Features that have nothing to do with public names for wallet seeds, and moniker *consistency *should be scrapped.
BIP 75 formalises what someone could do today with a bunch of PGP emails back and forth.
I create a public key, and I exchange it via QR code with you. From then on, You can initiate invoice requests with me, knowing my moniker is the same as it was the last time. I publish this key to a server (via DNSSEC) so anyone can obtain it. Sounds exactly like PGP.
Identity in BIP 75 is merely "moniker consistency". Nothing says that identity has to be "real"... only publicly verifiably consistent and accessible. This consistency and the ability to have public names for both merchants and users are the important features of BIP 075.
Other features linking monikers to real-world identity should be surgically removed from the standard.
- Users need to be able to send Bitcoin to an address without MITM attacks during the address exchange.
- Merchants need to be able to supply memorable names linked to internet services, like web servers and email addresses.
- Merchants and users both need to be able to initiate transaction off-chain, with a workflow that allows things like rejection, subscription, etc.
On Thu, Jun 23, 2016 at 6:56 AM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (69 lines)
> On Tue, Jun 21, 2016 at 05:14:31PM -0700, Justin Newton wrote: > > On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev < > > Hi Peter, > > Certainly AML/KYC compliance is one of the use cases that BIP 75 and > our > > certificates can support. As a quick summary, > > > > There are individuals and entities that would like to buy, sell, and use > > bitcoin, and other public blockchains, but that have compliance > > requirements that they need to meet before they can do so. Similarly, > > companies and entrepreneurs in the space suffer under the potential > threat > > of fines, or in extreme cases, jail time, also for not meeting AML or > > sanctions list compliance. We wanted to build tools that allowed > > entrepreneurs to breathe easy, while at the same time allow more people > and > > companies to enter the ecosystem. We also believe that the solution we > are > > using has the characteristics that you want in such a solution, for > example: > > > > 1> Only the counterparties (and possibly their service providers in the > > case of hosted services) in a transaction can see the identity data, > > protecting user privacy. > > > > 2> The counterparties themselves (and possibly their service providers in > > the case of hosted services) decide whether identity information is > > required for any given transaction. > > > > 3> No trace is left on the blockchain or anywhere else (other than with > the > > counterparties) that identity information was even exchanged, protecting > > fungibility > > > > 4> The solution is based on open source and open standards, allowing open > > permissionless innovation, versus parties building closed networks based > on > > closed standards. The very fact that this solution went through the BIP > > process and was adapted based on feedback is an example of how this is > > better for users than the inevitable closed solution that would arise if > > the open source, community vetted version didn’t already exist. > > > > I don’t know if you are opposed to organizations that have AML > requirements > > from using the bitcoin blockchain, but if you aren’t, why wouldn’t you > > prefer an open source, open standards based solution to exclusionary, > > proprietary ones? > > In some (most?) countries, it is illegal to offer telecoms services without > wiretap facilities. Does that mean Tor builds into its software "open > source" > "open standards" wiretapping functionality? No. And interestingly, people > trying to add support for that stuff is actually a thing that keeps > happening > in the Tor community... > > In any case, I'd strongly argue that we remove BIP75 from the bips > repository, > and boycott wallets that implement it. It's bad strategy for Bitcoin > developers > to willingly participate in AML/KYC, just the same way as it's bad for Tor > to > add wiretapping functionality, and W3C to support DRM tech. The minor > tactical > wins you'll get our of this aren't worth it. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org >
On Thu, Jun 23, 2016 at 3:56 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (12 lines)
> > In any case, I'd strongly argue that we remove BIP75 from the bips > repository, > and boycott wallets that implement it. It's bad strategy for Bitcoin > developers > to willingly participate in AML/KYC, just the same way as it's bad for Tor > to > add wiretapping functionality, and W3C to support DRM tech. The minor > tactical > wins you'll get our of this aren't worth it. > >
Peter, BIP75 gives the parties transacting complete control over who they choose to share their identity information with. This was the entire point of the proposal. You authorize who you choose to give your payment address to, and the sender can verify who they are sending payment to. All communication and payment info are encrypted against third party snooping, while still allowing asynchronous communication to accommodate ephemeral mobile connections.
The fact that some people will choose to use this identity information for AML/KYC purposes doesn't detract at all from the fact that it gives bitcoin users the tools they need to keep their payment information private, and only communicate it with the parties they choose.
Aaron Voisine co-founder and CEO breadwallet <http://breadwallet.com/>
On 6/23/2016 1:56 PM, Peter Todd via bitcoin-dev wrote:
Quoted text (18 lines)
>> >> I don’t know if you are opposed to organizations that have AML requirements >> from using the bitcoin blockchain, but if you aren’t, why wouldn’t you >> prefer an open source, open standards based solution to exclusionary, >> proprietary ones? > > In some (most?) countries, it is illegal to offer telecoms services without > wiretap facilities. Does that mean Tor builds into its software "open source" > "open standards" wiretapping functionality? No. And interestingly, people > trying to add support for that stuff is actually a thing that keeps happening > in the Tor community... > > In any case, I'd strongly argue that we remove BIP75 from the bips repository, > and boycott wallets that implement it. It's bad strategy for Bitcoin developers > to willingly participate in AML/KYC, just the same way as it's bad for Tor to > add wiretapping functionality, and W3C to support DRM tech. The minor tactical > wins you'll get our of this aren't worth it. >
Exactly! Totally agree with Peter Todd. There's absolutely no gain for Bitcoin to willingly participate in AML/KYC. Plus this might come with strings attached: for example when running a Tor relay in some countries if you interfere with the traffic (censor, limit, filter, etc.) you become responsible for it, while when you only relay anonymous traffic without interfering or having the possibility to do so (installing certain tools, using a modified Tor which allows you to do so, etc.) you cannot be held responsible for the traffic.
Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw expectations from _all_ users from authorities. Companies or individuals who want and/or need AML/KYC can find ways and do it at their side isolated from the entire network, and the solutions shouldn't come from upstream. AML/KYC/<insert other regulation here> differ from country to country and will be hard to implement in a global consensus network even if it would be worth it.
On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (12 lines)
> > > > Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw > expectations from _all_ users from authorities. Companies or individuals > who want and/or need AML/KYC can find ways and do it at their side > isolated from the entire network, and the solutions shouldn't come from > upstream. AML/KYC/<insert other regulation here> differ from country to > country and will be hard to implement in a global consensus network even > if it would be worth it. > >
This was precisely our thinking as well.
This is actually exactly why BIP 75 was designed the way that it was. Any (voluntary) identity exchange is done at the application level, on an encrypted https (or other) connection between the sender and receiver. Identity data is not passed through or stored on the blockchain, and there is actually no mark left on the blockchain that identity was even exchanged on that transaction.
The only people who know identity info was exchanged, or what the identity was is the counterparties in the transaction, and depending on implementation, their service provider. (At a high level, many software based wallet providers wouldn’t have any visibility into identity info, where many hosted services would, for example)
We did this to protect user privacy as well as fungibility.
We are allowing the people who want or need to exchange identtity info (either self signed or 3rd party validated) the option to exchange it, in a standards based way, directly between peers, without touching the blockchain or network itself.
Is this more clear?
In England under RIPA 2000 legislation, it's irrelevant whether you have the data or not. If the authorities compel you to hand over that information, and it is within your means to obtain it then you are obliged to do so under threat of criminal offense.
So any mechanism whereby data could be collected from Bitcoin users, whether it's stored ephemerally or not, if the police have reasonable suspicion to think it exists then they can compel all parties to work to get them the data they require.
If the mechanism flat out does not exist, that is miles better than could exist. Deniability is not a defense when served with a police notice for disclosing data.
You have to think not only about the end result, but also about how these mechanisms can be used for intimidating users or leveraging technologies.
Justin Newton via bitcoin-dev:
Quoted text (46 lines)
> On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > >> >> >> >> Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw >> expectations from _all_ users from authorities. Companies or individuals >> who want and/or need AML/KYC can find ways and do it at their side >> isolated from the entire network, and the solutions shouldn't come from >> upstream. AML/KYC/<insert other regulation here> differ from country to >> country and will be hard to implement in a global consensus network even >> if it would be worth it. >> >> > This was precisely our thinking as well. > > This is actually exactly why BIP 75 was designed the way that it was. Any > (voluntary) identity exchange is done at the application level, on an > encrypted https (or other) connection between the sender and receiver. > Identity data is not passed through or stored on the blockchain, and there > is actually no mark left on the blockchain that identity was even exchanged > on that transaction. > > The only people who know identity info was exchanged, or what the identity > was is the counterparties in the transaction, and depending on > implementation, their service provider. (At a high level, many software > based wallet providers wouldn’t have any visibility into identity info, > where many hosted services would, for example) > > We did this to protect user privacy as well as fungibility. > > We are allowing the people who want or need to exchange identtity info > (either self signed or 3rd party validated) the option to exchange it, in a > standards based way, directly between peers, without touching the > blockchain or network itself. > > Is this more clear? > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Hi there, For users who don’t wish a service provider to be able to see their information, even ephemerally, and they would like to exchange information via BIP75, they can use a software wallet, such as a breadwallet or others, and that data will only exist on their phone, and the phone of their counterparty (assuming the counterparty also chose to exchange info, and was running on a software wallet).
In this way, we allow users to exchange data as they choose, without having the risk that a service provider be asked for that data.
If a user chooses to use a hosted platform, and also to store their identity data there, I do agree it could be subject to a subpoena, the same as when they host their email, and other services.
Finally, they could choose not to use BIP75 at all, and no one would know whether they did or didn’t (other than their counterparts) as we don’t leave any residue on the blockchain, or anywhere else in the public eye.
We believe that this solution, due in part to its narrow data aperture, is the best solution available to the problem we are solving. We are eager to engage in any discussions about how to improve the proposed solution, with an eye to fungibility, privacy, and usability.
That said, there is a real need for people to know who they are transacting with for usability reasons, for fraud reduction, and also of regulatory reasons for some players. To NOT solve it with a carefully crafted standard means that it is more likely to be solved with back room, quick and dirty solutions that are not available for community review and feedback.
Thanks!
Justin
On Thu, Jun 23, 2016 at 2:31 PM, Police Terror via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (75 lines)
> In England under RIPA 2000 legislation, it's irrelevant whether you have > the data or not. If the authorities compel you to hand over that > information, and it is within your means to obtain it then you are > obliged to do so under threat of criminal offense. > > So any mechanism whereby data could be collected from Bitcoin users, > whether it's stored ephemerally or not, if the police have reasonable > suspicion to think it exists then they can compel all parties to work to > get them the data they require. > > If the mechanism flat out does not exist, that is miles better than > could exist. Deniability is not a defense when served with a police > notice for disclosing data. > > You have to think not only about the end result, but also about how > these mechanisms can be used for intimidating users or leveraging > technologies. > > Justin Newton via bitcoin-dev: > > On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev < > > bitcoin-dev@lists•linuxfoundation•org> wrote: > > > >> > >> > >> > >> Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw > >> expectations from _all_ users from authorities. Companies or individuals > >> who want and/or need AML/KYC can find ways and do it at their side > >> isolated from the entire network, and the solutions shouldn't come from > >> upstream. AML/KYC/<insert other regulation here> differ from country to > >> country and will be hard to implement in a global consensus network even > >> if it would be worth it. > >> > >> > > This was precisely our thinking as well. > > > > This is actually exactly why BIP 75 was designed the way that it was. > Any > > (voluntary) identity exchange is done at the application level, on an > > encrypted https (or other) connection between the sender and receiver. > > Identity data is not passed through or stored on the blockchain, and > there > > is actually no mark left on the blockchain that identity was even > exchanged > > on that transaction. > > > > The only people who know identity info was exchanged, or what the > identity > > was is the counterparties in the transaction, and depending on > > implementation, their service provider. (At a high level, many software > > based wallet providers wouldn’t have any visibility into identity info, > > where many hosted services would, for example) > > > > We did this to protect user privacy as well as fungibility. > > > > We are allowing the people who want or need to exchange identtity info > > (either self signed or 3rd party validated) the option to exchange it, > in a > > standards based way, directly between peers, without touching the > > blockchain or network itself. > > > > Is this more clear? > > > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Sometimes I think there's concerted resistance to making Bitcoin usable for the average person. Clearly the primary purpose of BIP0075 is to enshrine a DNSSEC protocol for giving wallet addresses memorable names.
On Thu, Jun 23, 2016 at 6:44 PM, Justin Newton via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (140 lines)
> Hi there, > For users who don’t wish a service provider to be able to see their > information, even ephemerally, and they would like to exchange information > via BIP75, they can use a software wallet, such as a breadwallet or others, > and that data will only exist on their phone, and the phone of their > counterparty (assuming the counterparty also chose to exchange info, and > was running on a software wallet). > > In this way, we allow users to exchange data as they choose, without > having the risk that a service provider be asked for that data. > > If a user chooses to use a hosted platform, and also to store their > identity data there, I do agree it could be subject to a subpoena, the same > as when they host their email, and other services. > > Finally, they could choose not to use BIP75 at all, and no one would know > whether they did or didn’t (other than their counterparts) as we don’t > leave any residue on the blockchain, or anywhere else in the public eye. > > We believe that this solution, due in part to its narrow data aperture, is > the best solution available to the problem we are solving. We are eager to > engage in any discussions about how to improve the proposed solution, with > an eye to fungibility, privacy, and usability. > > That said, there is a real need for people to know who they are > transacting with for usability reasons, for fraud reduction, and also of > regulatory reasons for some players. To NOT solve it with a carefully > crafted standard means that it is more likely to be solved with back room, > quick and dirty solutions that are not available for community review and > feedback. > > Thanks! > > Justin > > > > > > > On Thu, Jun 23, 2016 at 2:31 PM, Police Terror via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > >> In England under RIPA 2000 legislation, it's irrelevant whether you have >> the data or not. If the authorities compel you to hand over that >> information, and it is within your means to obtain it then you are >> obliged to do so under threat of criminal offense. >> >> So any mechanism whereby data could be collected from Bitcoin users, >> whether it's stored ephemerally or not, if the police have reasonable >> suspicion to think it exists then they can compel all parties to work to >> get them the data they require. >> >> If the mechanism flat out does not exist, that is miles better than >> could exist. Deniability is not a defense when served with a police >> notice for disclosing data. >> >> You have to think not only about the end result, but also about how >> these mechanisms can be used for intimidating users or leveraging >> technologies. >> >> Justin Newton via bitcoin-dev: >> > On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev < >> > bitcoin-dev@lists•linuxfoundation•org> wrote: >> > >> >> >> >> >> >> >> >> Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw >> >> expectations from _all_ users from authorities. Companies or >> individuals >> >> who want and/or need AML/KYC can find ways and do it at their side >> >> isolated from the entire network, and the solutions shouldn't come from >> >> upstream. AML/KYC/<insert other regulation here> differ from country to >> >> country and will be hard to implement in a global consensus network >> even >> >> if it would be worth it. >> >> >> >> >> > This was precisely our thinking as well. >> > >> > This is actually exactly why BIP 75 was designed the way that it was. >> Any >> > (voluntary) identity exchange is done at the application level, on an >> > encrypted https (or other) connection between the sender and receiver. >> > Identity data is not passed through or stored on the blockchain, and >> there >> > is actually no mark left on the blockchain that identity was even >> exchanged >> > on that transaction. >> > >> > The only people who know identity info was exchanged, or what the >> identity >> > was is the counterparties in the transaction, and depending on >> > implementation, their service provider. (At a high level, many software >> > based wallet providers wouldn’t have any visibility into identity info, >> > where many hosted services would, for example) >> > >> > We did this to protect user privacy as well as fungibility. >> > >> > We are allowing the people who want or need to exchange identtity info >> > (either self signed or 3rd party validated) the option to exchange it, >> in a >> > standards based way, directly between peers, without touching the >> > blockchain or network itself. >> > >> > Is this more clear? >> > >> > >> > >> > _______________________________________________ >> > bitcoin-dev mailing list >> > bitcoin-dev@lists•linuxfoundation•org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > > -- > > Justin W. Newton > Founder/CEO > Netki, Inc. > > justin@netki•com > +1.818.261.4248 > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
Quoted text (4 lines)
> Clearly the primary purpose of BIP0075 is to enshrine a DNSSEC protocol > for giving wallet addresses memorable names. > >
I can't tell if you're being sarcastic or not, but if you aren't, I don't think this is an accurate description at all. BIP75 is, at its most simplest, nothing more than an encrypted/encapsulated version of BIP70. All we did was make it safe for people to exchange BIP70 messages through an intermediary.
The only identity information included in BIP75 is the pki_data field, which wasn't even introduced in BIP75--it was already in BIP70. I'm guessing Peter would also have us remove BIP70 altogether?