rich1.0npub1w7tezshngplj3fd8r9twxv6zujrwaxq7v98q6t4rdhd0y7u2tfnsmwj55chttps://nostr.ae/npub1w7tezshngplj3fd8r9twxv6zujrwaxq7v98q6t4rdhd0y7u2tfnsmwj55cnjumphttps://nostr.ae📅 Original date posted:2012-11-27 📝 Original message:> This is the next big "lets all agree to do things the same way" thing > I think we should tackle. I'm particularly looking for feedback from > other bitcoin client developers, even if it is just a quick "looks > reasonable, if everybody else is going to do it then I will > (eventually) too..." I agree this is a very pertinent subject, and with a bit of looking around it is clear that there is a requirement here for emerging financial ecosystems of many types, certainly not just for the Bitcoin community, which until now seems to have been getting along just about OK despite the current levels of complexity. That said, I have a number of serious concerns with the proposal. 1. Undue Broadening of Scope: From an architectural perspective, if one accepts the unix mantra of "do one thing and do it well" as reasonable and time-proven doctrine, given that Bitcoin is already trying to be both a commodity and a distributed consensus-based settlement system, does it really make sense to attempt to tack-on business-level functions? 2. X.509: I have read (somewhere or other, recently) that it is generally considered bad form to mandate specific cryptographic systems in new protocols where open support is possible. Given the recent issues with X.509, the security nightmare that already exists with the volume of (sometimes cracked, sometimes government-compromised?) issuers, and the complexity of the scheme, it seems a little strange to singularly mandate X.509, despite its widespread use at present. There are also a swathe of potential issues around DNS interdependence, information leakage within certificates themselves and/or their DNS-interpretation by clients, etc. I would consider suggesting open support with initial support for GPG, as it is apparently preferred as a simple and further decentralized solution by the majority of the open source and cryptographic software development community. 3. Failure to Review Existing Work: I would urge anyone to be wary of adopting any proposal that does not inform itself through reference to existing protocols in the same area. In this area there are a few protocols in current use (chiefly in Europe) such as those listed at http://en.wikipedia.org/wiki/Invoice#Electronic_invoices as well as various hosted platforms such as http://xero.co.nz/ (chiefly Australia/New Zealand). Often, existing work shows its age with after-the-fact alterations that sit poorly with initial assumptions: exactly the kind of situation one can walk in to developing against a proposal before adequately researching the area. 4. Complexity of Metadata: Physical and digital invoicing for businesses operating at scale often requires delivery terms, product classification codes, locale-specific taxation (often at multiple levels), various fees and discounts (sometimes fulfillment-speed linked with multiple tiers/thresholds), and other features that I am skeptical are ever going to be made fully available within a business protocol tacked on to a hybrid digital currency/settlement system (like Bitcoin) as a secondary concern. 5. Non-BTC Currencies/Currency-like Commodities: No approach to non-BTC currencies appears to have been made, which makes the "invoice" of limited utility for almost all businesses, save those willing to accept all of the 'capital risk' (exchange rate fluctuation risk) inherent in a BTC-based fulfilment process with a potential term long enough to justify an invoicing process. (Does this narrow scope actually cover any existing business?) 6. DNS: As already mentioned with regards to X.509: a huge red flag as an area of potential vulnerability, or at least information leakage. I must now admit that in raising the above I am definitely biased. My employer (Payward, Inc.) and other organizations (OpenCoin, Inc., etc.) have been working with the Internet Engineering Task Force (IETF) on tabling some open proposals within this area under the auspices of the Internet Financial Exchange Project (http://ifex-project.org/). Our hope is to facilitate the requisite standardisation within internet-connected systems to deal with what is perhaps fairly characterised as a relatively heterogeneous outlook on the rise of cryptographic (and other alternate) currencies and commodities, and emerging settlement infrastructures. Whilst the current Bitcoin proposal is admirable for correctly raising the area as one of immediate concern, I hope that the above points out some of the perhaps as-yet unconsidered complexities and draws in to question whether Bitcoin is in fact the appropriate place to implement a solution, given the hassles that will entail. After all, wouldn't Bitcoin developer time would be better spent improving the core of bitcoin (ie. distributed settlement system and commodity) rather than adding new features? I would invite parties within the Bitcoin community with an interest in non directly settlement-linked financial transaction negotiation and reporting features to consider contributing to the existing, re-usable efforts at the IFEX Project, rather than supporting the extension of one currency/commodity and settlement infrastructure (ie. Bitcoin) which IMHO is likely to detract from developer time, increase complexity, and perhaps result in a less polished and re-applicable solution overall. Our proposals: - X-ISO4217-A3 (X-ISO4217-A3). A published proposal that provides a mechanism for the open identification of currencies or currency-like commodities on the internet. (Bitcoin is registered as XBTC). http://www.ifex-project.org/our-proposals/x-iso4217-a3 - Internet IBAN (IIBAN). A published proposal that provides a mechanism for the open identification of financial endpoints on the internet. (IBAN compatible, checksum-included, name-squatting problem avoiding. The registry of entities is IANA-managed, encourages GPG use, and avoids the X.509 requirement.) http://www.ifex-project.org/our-proposals/iiban - Internet MIC (IMIC). A published proposal that provides a mechanism for the open identification of financial markets on the internet. (Such as most Bitcoin exchanges) http://www.ifex-project.org/our-proposals/imic - Internet Financial EXchange (IFEX). A proposal under development that facilitates the negotiation of financial transactions between internet-based financial endpoints. (The area we would love your input) http://www.ifex-project.org/our-proposals/ifex Sincerely and with the utmost respect for the Bitcoin project's excellent work, Walter Stanish