Published on: 2011-12-19T20:03:29+00:00
In a discussion on the Bitcoin-development mailing list, concerns are raised about the simplicity of implementing protocol buffers compared to MIME. Working with MIME libraries is highlighted as challenging due to bugs and limited support. The issues with undefined content length and text-based boundaries in MIME cause problems when working with it. Despite its limitations, the MIME module remains in the e-mail library. There is a debate on using JSON versus protocol buffers for alias resolution in Bitcoin. JSON has widespread language support but has problems with handling numbers. Protocol buffers offer advantages in speed, efficiency, and reducing data size, but may be more complex to work with. The decision to use one over the other depends on developers' needs and preferences.The conversation also revolves around the payload format for Bitcoin URIs with "amount", "label", and other parts. Suggestions include using an address in response and potentially using HTTP redirects for compatibility. Another suggestion is to use JSON for easier implementation. The debate centers on keeping the proposal simple while ensuring compatibility and ease of use.There is a discussion on the use of HTTPS as a minimum standard for Bitcoin websites dealing with financials. Some express a preference for XML over JSON, but acknowledge JSON's common support. The need to send binary data in an alias response is questioned, and base64 encoding is suggested as a solution. The debate also touches on whether HTTP alone is sufficient or if JSON/XML should be used.The issue of trust establishment in site policies is addressed. The proposal suggests generating self-signed or CA certificates instead of relying on commercial CAs. DNSSEC is mentioned as a reliable way to retrieve certificates if supported by the site. Using JSON is considered inefficient for representing binary data. Establishing trust is seen as an administrative issue with various solutions, and not every site/application requires trust. SSL/TLS is not deemed necessary for HTTP exchange if trust is established in another way.The debate on using HTTP for data interchange continues, with some advocating for HTTP multipart response and others favoring JSON due to its wide adoption and language support. The convenience and ease of use of JSON are highlighted. The argument is made that using HTTP alone should be sufficient, while others advocate for JSON/XML based on their specific requirements.The discussion includes the issue of trusting Certificate Authorities (CAs) and the need for stricter criteria for trusted CAs. There is a debate on whether it should be determined by the operating system or software. Restricting CAs could limit aliases without a key to those who can afford expensive certificates.There is a discussion about using simple standards like HTTP alone as the foundation for building. JSON is considered acceptable but has limitations in language support and representing binary data. HTTP is seen as allowing binary data in multipart content without issues.The problems with HTTPS and the reliance on CAs are mentioned. The proposal is made to restrict trusted CA certificates based on good practices for verifying identity. However, concerns are raised about the difficulty for personal or small users to obtain free certificates if restrictions are imposed.The issues surrounding TLS and DTLS protocols and the use of PKIX certificates for server authentication are addressed. DANE is suggested as a better option, leveraging DNSSEC for trust over HTTPS. Implementing DANE requires binding self-signed certificates using DNSSEC, and if DNSSEC is relied upon, publishing identifiers and securing the zone via DNSSEC is recommended.A Bitcoin developer argues against trusting software vendors to decide who should be trusted. The problems with internet CAs and their abuse of certificate validity dates are highlighted. Trusting third parties with no relationship to serve one's interests is seen as problematic. The suggestion is made to pre-trust the resolver for alias resolution, allowing users with different verification policies to choose their approach.In a separate discussion, proposals are discussed for improving the usability and security of the Bitcoin protocol. Suggestions include using URLs as address identifiers, reusing Bitcoin's code and protocol for transactions to IP addresses, and exploring different aliasing schemes. The scalability and practicality of these proposals are debated, with considerations for domain grabbing issues, alternative solutions like Namecoin, and the flaws of the Certificate Authority (CA) model.In another discussion, a decentralized solution for implementing aliases in Bitcoin is explored. Participants discuss the use of HTTPS as a client feature but not adding it to the protocol itself due to reliance on centralized CAs. FirstBits is considered likely to cause address grabbing issues. Namecoin is proposed as a decentralized alternative, but concerns about block exploring servers are raised. Different options for setting up aliases, including web services and HTTPS + CA, are suggested.The value of International Bank Account Numbers (IBANs) in relation to Bitcoin addresses is debated, with considerations for compatibility with existing software solutions and flaws in the banking system. Keeping things simple and understandable for wider adoption is emphasized.Namecoin is described as a decentralized peer-to-peer name/value datastore system that can be easily connected to Bitcoin. It offers additional security with certificate fingerprints combined with HTTPS URLs.
Updated on: 2023-08-01T02:43:54.939951+00:00