(I am not Justin Newton)
BIP 75 — Improving blockchain usability and privacy
I wanted to take a moment to share some of the history of how and why I originally proposed what is now known as BIP75. In order to get the full context, let’s first go back a few decades, to the mid ‘90’s when the Internet was first starting to really take off. We were at a point in time that was pretty similar to where we are at in the blockchain ecosystem now. We all knew that we were building a world changing technology, and it was critical that early designs and decisions had to set us on the right path for the future. There was even fierce debate between engineers about the best way to scale the network. Sound familiar? ;)
SUED BY SCIENTOLOGY
Another similarity between then and now is the importance of doing the right thing for the ecosystem and our users. In August of 1995, I was running technology for an ISP called Digital Gateway Systems, based outside of Washington D.C. During a typical day at the office, I answered the phone fully expecting a normal customer call. It was not. The person on the other end of the line was Helena Kobrin, then legal counsel for the Religious Technology Center. For those of you who are not familiar, they are responsible for managing all the super secret documents of the Church of Scientology. Apparently, one of our users, Arne Lerma, had posted some materials on USENET for which the Church claimed they held a copyright. I informed Ms. Kobrin that I would be more than happy to take the materials down, if they sent me proof of the copyright. They refused. In that moment, I knew that we were at a critical point, and understood how important it was to set the right precedent in terms of preserving the rights of Internet users moving forward. The entire DGS team knew that the Church of Scientology was on a lawsuit rampage, and that this was going to get very costly, very fast. Rather than backing down to their demands we (myself, the engineering team, and the exec team) chose to forgo our salaries in order to fight back for the rights of our users, future users, and for the ecosystem as a whole. DGS was named in the lawsuit and we got served a few days later.
CONGRESS ATTEMPTS TO IDENTIFY ALL INTERNET USERS
Shortly after the case was over, I saw the need for a group that could represent and protect the industry and our users, and I co-founded what became the largest trade association for ISP’s, the ISP/C. Working as a core engineer by day, and as our Public Policy Director by night, I focused my efforts on ensuring that any new laws or regulations supported the open, permissionless nature of the Internet, as well as protected the rights of individuals on the Internet.
The first issue we tackled was spam legislation, which was becoming a rapidly growing problem that stood to adversely impact both ISPs and end users alike. As Congress was drafting one of the early anti-spam bills, the Netizens Protection Act of 1997, Representative Chris Smith’s office reached out to me to see if ISP/C would endorse the bill. After waiting for them to fax it over (yeah I know, crazy), I finally got the draft, and was shocked to find a line in the bill which would have made it ILLEGAL to send ANY email without attaching your real name to it. Online anonymity was a right that needed to be protected, and this legislation would set a dangerous precedent that the ISP/C could not endorse. More than just not endorsing the bill, it was important for us to get Chris Smith and his team to understand why this was such a critical issue, as soon as possible. I was able to get in touch with the legislative analyst for the bill, and had several in-depth conversations with him about the right to privacy, user protections, and the goals we were working towards at ISP/C. Eventually, we were able to get that language removed, and replaced with language that instead only required a valid return email address, for users sending out unsolicited commercial emails: a solution that, I think, everyone is probably thankful for, well, except the spammers. ;)
I wanted to share these stories to demonstrate a long and ongoing commitment to protecting the rights of individuals online, and also to show how strategic, collaborative engagement works to produce better outcomes.
WHY WE STARTED NETKI
When we started Netki in 2014, we wanted to find ways to make bitcoin (and all blockchains) easier for normal individuals to use. Our first step was to build out our Wallet Name Service. Wallet Name service, (based on DNSSEC and optionally the Namecoin blockchain) gave people the ability to share an easy to use name, such as “justin.bi.tt” in place of their complicated wallet address. When we designed this, we thought not just about ease of use, but also security and privacy, both of which we wanted to improve, compared to current processes.
First, we required the use of DNSSEC so that the address transfer was cryptographically signed (in a manner similar to bitcoin transactions), and that the sender’s wallet could validate that the chain of trust was complete, and therefore ensure that the address hadn’t been tampered with in transit. This was a major improvement over then current practices of sending wallet addresses over unencrypted email, or via social media.
HOW NETKI HAS ALWAYS BEEN PRIVACY FIRST
From a privacy perspective, we implemented BIP32 (HD Wallet) into our product before it even launched, allowing users to share their Wallet Name with as many people as they want, and still know that each person will only be able to tie the Wallet Name and the wallet address used for the transaction to their OWN transactions. The fact that the use of a unique wallet address for each transaction hasn’t already been made automated for end users has led to CoinLab to announce they have successfully ‘de-anonymized bitcoin’ https://coinlab.com/blog/post/exploring/ . We saw this risk coming and wanted to make it brain dead simple for end users to use HD wallets, and therefore improve on-chain privacy. We hope that most major wallets and exchanges will support this, or some other mechanism to protect their users’ privacy, by making HD address generation automatic in their users’ wallets, without making the users themselves have to do any extra work.
We also included support for the Payment Protocol, BIP70 so that the sender could know who they were sending to, before confirming a transaction. The user experience for this would be: type in an easy to remember Wallet Name, and get back the “little green lock” that people are used to when browsing the web, and the ‘identity’ (self signed, e.g. their email address; or 3rd party validated) of the party they are sending to. We saw this as a major step forward in terms of both improving the current user experience, making bitcoin feel more comfortable for the users we all, as a community are trying to get onto the network.
Sometime in mid-2015, we read an article proposing Store & Forward servers as a way to allow for offline message passing between bitcoin wallets. We loved the idea so much, that we decided to start building an open-source service that acted as a Store & Forward server, called Addressimo. During the development phase we uncovered a hole in the security model of the proposed idea. All messages stored on the service were almost completely open for anyone to view. In the event of a compromise, an attacker would most certainly have access to all of the messages being passed between wallets, and along with that, all of the wallet addresses included in the PaymentRequest messages.
So we started to think amongst ourselves and eventually spoke to the folks at Breadwallet about a solution to this problem. Eventually we decided that all messages should be end-to-end encrypted using shared, ephemeral keys such as the scheme employed by TLS. To that end we began to write and refine what would eventually become BIP75, an extension to the already existing BIP70 Payment Protocol. The primary focus of BIP75 was, and is, to enhance user privacy and security in an open-standards way for an open-standards network.
We liked the option, present in BIP70, that allowed the user sending funds to see and verify with their own eyes that the receiver was, in fact, who they purported to be. A natural extension of this, we concluded, was that it would be helpful if this existing facility in BIP70 could be included in an ‘Invoice Request” message, so that both parties to a transaction could share information, that would allow them (and ONLY those parties) to know something more about ‘who’ (this information can be something as basic as an email address) they are transacting with.
The culmination of months of ideation, design, and implementation work brought together many things that we at Netki believed were missing from current bitcoin applications that would be hugely helpful towards continued mainstream adoption, including improved ease of use, and increased security and privacy. The major features of BIP75 are:
Allows for end-to-end, fully encrypted two-way communication of payment information between the parties to a transaction (and ONLY those parties)
Makes Store & Forward services usable and secure for mobile wallet applications
Optional information sharing between users who choose to share (about ‘who’ they are), via an encrypted, private channel
Application-level protocol that does not in any way interfere with or change the core Bitcoin protocol
Permissioned wallet address release
Allows for an address book feature on wallet applications without static wallet addresses
Finally by using BIP75 we encourage the use of a unique address per transaction, which improves user privacy, by protecting against potential leakages that can be acquired using analytics tools, and other forms of ‘prying eyes’. In summary, we designed a protocol that makes it easy to share information with who you want, while at the same time making it harder for outside eyes to spy on what you are doing.
WHY A BIP?
Originally, we at Netki were unsure if BIP75 should actually be proposed as a BIP. When we starting digging in and looked at things, however, it became apparent that this was really the only proper route to take. First, the work we are doing here is an extension of the work that was already done on BIP70. If we are to use history as our guide, the core development community (at the time) that authored and contributed to BIP70, must have believed that the BIP process was appropriate for this kind of proposed extension. Next, we took a closer look at the details themselves. This kind of communication between wallets can clearly benefit from a standard, and the method for creating such a standard can clearly benefit from the peer review generated by an open, standards based process. In the bitcoin ecosystem, that place is in BIPs. We have already seen the benefits of engaging in this process, and improved the proposal multiple times based on the feedback we have received from other developers.
We also believe that we as a community will end up with a better mechanism for the handling and sharing of identity, if we work together in an open manner rather than allowing things to transpire behind closed doors without proper community input or oversight.
KYC
Currently, there are many bitcoin companies that must comply with existing AML/KYC reporting requirements (e.g. exchanges and custodial wallets in the U.S. that are classified as MSBs), and as a result, have to employ certain ‘Know Your Customer’ measures as part of their ‘risk-based approach’ to compliance. There are also many bitcoin applications that do not have to comply with these regulations (e.g. non-custodial wallets with no exchange feature), and therefore do not have stringent requirements surrounding the collection of identity information about their customers. The bitcoin ecosystem is a diverse and growing community of users that clearly finds utility in both kinds of applications. In terms of the regulated service providers, a problem with some of the approaches to these measures, today, is that they can work to isolate transactions within ‘walled gardens’, where a user on one service can’t send funds to a user on a different provider. We see the potential for these walled gardens to reduce user choice, and constrain the overall ‘openness’ of the ecosystem, by boxing users into certain institutions, if they want to exchange funds with certain parties. With BIP75, via the encrypted two-way data exchange, we saw the opportunity to allow transactions to take place in a truly open network while maintaining the ‘on-chain’ privacy of the transacting parties. With the existing challenges surrounding compliance with regulatory reporting requirements, we ultimately see the development of standardized means to meet these requirements in a way that fundamentally protects and improves user privacy as a critical step in the development of real world solutions that utilize and/or interact with Bitcoin and other blockchains.