Proposal: extend bip70 with OpenAlias [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2015-07-31T20:34:55+00:00


Summary:

In an email conversation between Thomas Voegtlin and Justin W. Newton, the idea of hiding the "_oa2" portion of the domain name to facilitate the delegation of wallet names in a zone was discussed. Thomas proposed using "@" as a symbol to denote the hidden portion in the alias. He also provided an example of how Bitcoin aliases could be delegated to Netki using this system.The OpenAlias standard was created to simplify the process of creating aliases for cryptocurrency transactions. However, using a tiered system adds complexity for the alias creator and makes it easier to make mistakes. Retaining forward and backward compatibility is also more challenging with a Key-Value (KV) pair system. The proposal suggests using "_oa2_keys" for listing TXT records under a name and introducing "_oa2" as an intermediate level for delegation, translating to "@" in the alias.Another email thread on the bitcoin-dev mailing list discussed the idea of having an intermediate "_wallet" level for zone delegation. However, it was later suggested to separate the listing of TXT records from zone delegation. The proposal introduced the use of "_oa2" for the intermediate level and "_oa2_keys" for key listing. Examples of how this system could work with Bitcoin aliases being delegated to Netki were provided.The discussion also explored the efficiency of a two-tier lookup solution. While some argued that it would be more efficient, others believed that the efficiency does not come from using two-tier lookup. Instead, using an intermediate level like "_wallet" allows for zone delegation. It was further suggested that instead of separate records for each currency, it would be better to have a record specific to the currency, which would allow wallets supporting only one currency to skip the currencies lookup.To sign up for certain online services, users may need to create a new identity under a DNS tree they are not currently using. This can help ensure security and privacy while using online services. Services like netki.com provide the option to create a new digital identity or "root" associated with the user's online activities.In an email exchange between Mike Hearn and an unknown recipient, OpenAlias and its potential success were discussed. There was confusion over the terms "alias" and "DNS key" but it was concluded that "alias" refers to the domain name corresponding to the TXT record. The conversation also explored alternative options such as compact cert+optimized BIP70 and using pastebin for storing small bits of data. There was a suggestion to use a 150-byte QR code using base43 encoding for data storage, although legal issues may arise with services providing this type of storage.The discussion focused on two separate issues: DNSSEC and payment requests. DNSSEC attests to an EC key stored in the wallet used to sign payment requests or URIs. It was suggested not to include the proof in the payment request, as it is unnecessary for the payer to verify. DNSSEC's value lies in providing easy and canonical access to the proof. The possibility of using EC signatures with DNSSEC was questioned, as it was believed to be an all-RSA system. The author proposed using optimized BIP70 with compact cert and no DNSSEC in a QR code if creating a network for storing small bits of data proves difficult.The use of DNSSEC in payment requests and its drawbacks due to the size of the DNSSEC proof and RSA signature were discussed. The proposal suggested not including the proof in the request and only using the final signature. It also considered the use of SSL certificates for lightweight payment requests. The idea of building a new PKI for individuals that includes only a signature and a UTF-8 string without sacrificing revocability was proposed. The pubkey of the Certificate Authority would be obtained by running the pubkey recovery algorithm on the signature and verifying it against trusted pubkeys.In a conversation about convenience in Bitcoin transactions, the exchange of large data packets without a server acting as a dropbox was discussed. Possible solutions included using other people's web servers or making the data packets small. The limitations of QR codes were also mentioned, prompting the idea of finding a better replacement. The use of SSL certificates for lightweight payment requests was suggested. The benefits and drawbacks of creating a Bitcoin-specific or independent PKI for individuals were explored.Justin Newton raised concerns about including Namecoin in the standardization of DNS records holding Bitcoin addresses. He argued that .bit records cannot be easily verified by lightweight/spv wallets without a copy of the Namecoin blockchain. The proposal to include Namecoin was initially made to provide a censorship-resistant option and low-cost name registration for individuals. However, discussions are needed to consider the trade-offs for mobile wallets. The focus should be on standardizing DNS records holding Bitcoin addresses for Netki and Electrum, while other types of lookups such as Namecoin can be considered separately.The author proposed extending BIP70 to bring the benefits of public proof of payment request to user-to-user transactions.


Updated on: 2023-08-01T14:20:02.486768+00:00