rich1.0npub1w7tezshngplj3fd8r9twxv6zujrwaxq7v98q6t4rdhd0y7u2tfnsmwj55chttps://nostr.ae/npub1w7tezshngplj3fd8r9twxv6zujrwaxq7v98q6t4rdhd0y7u2tfnsmwj55cnjumphttps://nostr.ae📅 Original date posted:2011-12-16 🗒️ Summary of this message: Bitcoin needs to maintain its decentralized feature, but people want alternate representations of bitcoin addresses. Blockchain bloat is an issue, and an extra-blockchain aliasing system must prioritize usability and absolute security. Arbitrary aliases are not in use in mature financial systems, and checksum systems detect transposition errors. 📝 Original message:> Bitcoin itself is decentralised by design, in my opinion it seems obvious > that it needs to continue to maintain this feature. What's the real issue? - People want to use alternate representations ('aliases') of bitcoin addresses, for various reasons. - The blockchain is the only way to create distributed consensus within the bitcoin network. - Very few people - even those who wish to have a permanent alias - want to have it map to a permanent bitcoin address, since this discloses their financial history (eg: income for a business) to the public - Some people want throw-away (single use) aliases, others want permanent ones. This means many addresses. - Blockchain bloat is already acknowledged as an issue. - The blockchain is not really a good option. Leaving out the blockchain, there are still ways to implement aliasing. What is the core problem for an extra-blockchain aliasing system? At the core is usability - people basically want aliases to make it easier to type in or remember addresses. So a solution that sacrifices usability too far is a broken one. Another requirement is absolute security. A user of the aliasing system is going to trust it to translate a particular alias to a bitcoin address - ie: 'where my money goes with absolutely zero chance (by default) of getting it back if it's sent somewhere wrong by accident'. Such an accident might be mistyping an alias. It might also be a hijacking of the alias resolution system (eg: a DNS based system without DNSSEC, etc.). As a case in point, we already see very well organized attacks by domain squatters in order to steal traffic or effect phishing under the DNS system. So... to help see which qualities are meaningful for such an alias system, let's look at what types of solutions to these problems exist within conventional (ie: mature) financial systems. First, arbitrary aliases are not in use. This means that memory-based mnemonics are not subject to predictable squatting-style attacks. For our purposes, this means that if you are payments at business1.com, I can't go and register payments at busines1.com and take a portion of your inbound cash whenever a client tries to pay you and typos on the send address. Likewise, if you're 'someuser at hostedwalletservice.com' I can't go and register as 'someuse at hostedwalletservice.com' and pull the same heist. IIBAN is the only aliasing proposal I have seen mentioned within this thread that adopts this strategy, the others all maintain this vulnerability through DNS. HTTP relies on DNS. Second, checksum systems detect transposition errors. This is a very powerful feature, which (I can't be bothered googling for stats, but just think about it) cuts out the vast majority of such errors instantly, at the time of input, before money changes hands or anything touches the financial settlement networks. IIBAN adopts exactly the same mature and proven MOD97-based two digit checksum feature that is used within the IBAN standard, proposed by the European Union with the benefit of decades of banking experience in many member states and now growing rapidly in use around the world. (For something as expensive and painful to implement as a nationally-mandated banking standard affecting all member banks, a growth rate of 'a few countries per year' is a pretty serious growth curve!) With checksums, it's even possible to auto-suggest corrections based upon common transposition errors and help the user to check those parts of the alias for common errors more quickly. Third, conventional financial systems typically require recipient name (and sometimes address, or business tax numbers in some countries' domestic schemes) as part of the transaction. This secondary data facilitates error checking since an incorrectly supplied destination address can be checked against these properties. Of course, Bitcoin presently has no such secondary input with which to verify the destination of a transfer, and since blockchain bloat is an acknowledged issue and very few bitcoin users would like to see their names appear against their transactions within the blockchain (visible to all, for eternity!) it also seems that this feature is not going to be added and for good reason. However, within an external (and not necessarily bitcoin specific) higher-level 'transaction negotation' protocol (alluded to in earlier posts as a logical extension of the pre transaction alias resolution mechanism, and being a pre transaction connection of some nature between a payer and payee, or their proxying/representing institution, in the case of hosted wallets/aliases), such external destination validation features could be added. (Many types are possible... data-based as per name/address validation, cryptographic validation schemes, etc.) Finally, an increasing number of countries use an aliasing scheme (IBAN) that is familiar to users. Doing so for digital currencies such as Bitcoin increases usability (by eliminating novelty, and in the case of IIBAN which is not specific to any given currency, the need to register, recall and manage yet another account identifier), which was one of the original goals. None of the other proposals mentioned have this property. I won't go in to other benefits previously mentioned of the IIBAN proposal, but I still cannot see any reason to either: - Include aliasing within bitcoind itself - Re-invent the wheel - Scare off non-technical users - Dodge the fact that there are unique properties of bitcoin that will always remain and should perhaps simply be acknowledged and worked around OUTSIDE of the codebase, rather than within. Unix/internet philosophy is that it's usually best to keep code as simple as possible, to 'do one thing' and 'do it well'. For bitcoind (despite sharing a codebase with the GUI), that something is achieving a distributed internet-based financial system that is free from legacy centralized currencies. It is *not* worrying about making it look pretty or easy to use, which can be achieved by layering totally external systems through simply translating various alternate representations ('aliases') to the well defined bitcoin addressing scheme. Just to avoid any notion of table-banging (Hah! A lost cause?), this will be the last IIBAN-related post I will make on this thread, but there will be some further announcements in the near future. Keep up the good work everyone. Regards, Walter Stanish Payward Inc.