Re: [Bitcoin-development] Version bytes 2.0
Why does anyone care what an address looks like? If the user is seeing an address, that's a usability fail right there. It's common today because AFAIK nobody finished off the URL handling support in the main client for browser integration. It'd be a much better use of time to finish off that integration and make it easy for people to create links containing a bitcoin: URL (like with copy/paste of text/html content). -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall a picture of their QR code and a bitcoin address. I don't own a mobile phone so the QR code is useless. Fixed addresses like that are a temporary thing during Bitcoins maturation period. They lead to merchants exposing data they probably don't realize they're exposing, like their income, which is basically unacceptable for any payment system. There's no point trying to optimize a case where: 1) You are in the minority (no phone?) 2) The perfect experience leaks private data in such a way that would be deemed a gross security breach by any serious payment processor. OK, some thoughts on the general proposal, from the POV of what it'd take for a large deployment, like for every Gmail or every Facebook user. In terms of ease of implementation it is ordered HTTPS/HTTP then DNS trailing by a large margin. Big sites, even small sites, typically have high-speed load balancing and demuxing already implemented for HTTP[S] and it's usually easy to add new endpoints. The same is *not* true of DNS, and whilst coding up a custom DNS server is possible it's definitely a worse fit. FirstBits seems out of the question for the same privacy reasons as given above. No banking system worth its salt would let everyone look up other peoples income. The simplest approach would be to request a full public key with an HTTPS request like foo@domain - https://domain/_bitcoin/getnewkey?user=foolabel=Payment%20from%20Bob If you then want to turn the resulting public key into an address before creating a transaction you can obviously do that. BTW the BIP is pretty hard to read. Your spec for the HTTPS proposal is a big pile of source code. I think it's the same as above, but it's hard to tell without more effort. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bytes 2.0
All, I fully agree with Mike Hearn on this. Like email addresses, bank numbers, phone numbers, IPv4/v6 addresses and such the bitcoin address is just an opaque identifier for machines to be able to send each other messages. Base58 was chosen not for human readability but to make it easy to copy/paste. Of course, sometimes for security reasons you may want to check the addresses manually, but it is not the prime usage scenario. Although fun as a nerd pasttime, I don't think we should encourage addresses with meaning to normal users. Indeed better to focus on alternative ways that don't involve typing or even seeing the addresses. Copy/paste of HTML content is currently not possible. You *can* already dragdrop the bitcoin: link to the client. Bluematt has a pull request to automatically handle bitcoin: URLs when clicked in the browser. Wladimir On Tue, Dec 13, 2011 at 11:38 AM, Mike Hearn m...@plan99.net wrote: Why does anyone care what an address looks like? If the user is seeing an address, that's a usability fail right there. It's common today because AFAIK nobody finished off the URL handling support in the main client for browser integration. It'd be a much better use of time to finish off that integration and make it easy for people to create links containing a bitcoin: URL (like with copy/paste of text/html content). -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bytes 2.0
Base58 was chosen not for human readability but to make it easy to copy/paste. It was also chosen for hand-writeability, weirdly enough. That's why it excludes some confusible characters. But Satoshi didn't really understand how people would end up using Bitcoin, he originally imagined most transactions being done directly between pairs of IP addresses. Copy/paste of HTML content is currently not possible. You *can* already dragdrop the bitcoin: link to the client. Bluematt has a pull request to automatically handle bitcoin: URLs when clicked in the browser. That's cool. I hope Matts change gets merged soon. Then the issue becomes how do people find out about this capability? Expecting people to learn how to hand-craft Bitcoin links won't work. But all modern operating systems support copy/paste and drag/drop of rich content. Qt probably makes it easy to expose an UI like this: *Pay me*[Copy to clipboard] Clicking the link in the UI would pop up an alert saying something like You can drag this link to an email, chat window or editing program. Dragging it/pushing the copy button would just set the drag/clipboard data as a bit of text/html content. So then you can just copy/paste into an email or HTML editor. It wouldn't work for forums that use bbCode, though I guess there's no particular reason the forum software can't turn a href into [url=] automatically. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
I agree with Mike Hearn and Christian Decker-- paying to 'someb...@foo.com' should become, behind the scenes, a HTTPS query to https://foo.com/something. If you just want to (say) donate to eff.org, then paying to '@eff.org' aught to work nicely. And if namecoin ever takes off you'll pay to 'someb...@foo.bit'. It seems to me that if it was DNS-based, the address should be something like 'somebody.bitcoin.foo.com'. But I think it is unlikely people will setup and run a custom DNS server just to support bitcoin payments. -- -- Gavin Andresen -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
On Tuesday, December 13, 2011 8:06:15 AM Gavin Andresen wrote: I agree with Mike Hearn and Christian Decker-- paying to 'someb...@foo.com' should become, behind the scenes, a HTTPS query to https://foo.com/something. If you just want to (say) donate to eff.org, then paying to '@eff.org' aught to work nicely. Seems like introducing a gaping security risk to me. It seems to me that if it was DNS-based, the address should be something like 'somebody.bitcoin.foo.com'. But I think it is unlikely people will setup and run a custom DNS server just to support bitcoin payments. Could always use a fixed address and email someb...@foo.com a signed message. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Interesting thread. Given the following paragraph and the limited feedback garnered upon its announcement to this list last month, I couldn't help but chime in again to mention IIBAN, an Internet Standards Draft available at http://tools.ietf.org/html/draft-iiban-00 (A related proposal for internet connected financial market identification, IMIC, is also available: http://tools.ietf.org/html/draft-imic-00) which - fair declaration of bias - I authored on behalf of my employer, Payward Inc., while working on Bitcoin-related development. I think the scope of this BIP is not so well defined right now. We need a way for merchants to translate a human readable, and more importantly human-writeable, address into a bitcoin address. I believe that IIBAN solves this problem fairly elegantly: (1) Mature transposition error detection (think Oops, that's a zero not an 'oh'! I wrote it wrong!). This functions via checksum digits using a known algorithm, leveraging decades of experience in conventional financial institutions. The same functionality provides for simple suggested error correction on common transposition errors (0-O, 1-I, etc.). (2) Fixed length. (3) Far shorter than both bitcoin addresses and many national bank account numbers at 13 characters (less than half of the size of a bitcoin address). (4) Fewer characters (no lowercase), resulting in less transposition issues and greater legibility. (5) Superset-compatible with existing financial networks utilizing the IBAN standard (mandated in Europe, increasingly popular elsewhere), resulting in greater ease of uptake. (5) Centralized, delegatable namespace allocation but with clear rules governing allocation that aim to minimize potential room for any potential abuse of power. (6) Settlement system neutral - ie: not bitcoin-centric. By leaving Bitcoin to be Bitcoin, Bitcoin developers can focus on core concerns rather than becoming embroiled in formatting and user experience concerns. Also, a single address could be paid via multiple channels (conventional financial systems, bitcoin, LETS systems, etc.) resulting in greater ease of uptake and higher user confidence over time since published banking information is no longer held hostage to the assumed longevity, liquidity, legality or other liabilities of an individual settlement system (such as Bitcoin). (7) Provides defined private address spaces for internal transfers (eg: within an organization's own systems, for financial simulations, MMORPGs, etc.) and a documentation/public works of fiction address space to address common usage concerns in similar network addressing schemes. (8) Heterogeneous management of different parts of the address space. Whilst the proposed IANA (Internet Assigned Numbers Authority) management of IIBAN's initial institution namespace is indeed centralized and will no doubt raise eyebrows from within parts of the community for that reason alone, the IIBAN draft is liberal in its assignment policy, which can be viewed within the draft document linked to above, and whose terms are binding for IANA. It's also worth noting that four of the most similar global systems deployed today, SWIFT's BIC and IBAN, the ITU's E.164 international telephone numbering scheme and IANA's IP address space management are implemented as similar centralized-but-delegated style schemes. Furthermore, due to the flat nature of the registry, a http://convergence.io/ style 'trust agility' model (ie: multiple 'centralized' parties share their network view, and user-prioritized source consensus/acceptance/approval determine end-user perspective) is wholly compatible. In closing, a quick mention that a new version of the IIBAN draft will be released very shortly including a draft IIBAN institutions registry that will be established in order to facilitate implementation and testing. Drop me an email if you'd like a portion of the address space and your early assignment will appear within that draft. Regards, Walter Stanish Payward, Inc. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
(6) Settlement system neutral - ie: not bitcoin-centric. ... Also, a single address could be paid via multiple channels (conventional financial systems, bitcoin, LETS systems, etc.) resulting in greater ease of uptake and higher user confidence over time since published banking information is no longer held hostage to the assumed longevity, liquidity, legality or other liabilities of an individual settlement system (such as Bitcoin). I like this part. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
On 2011 December 13 Tuesday, Amir Taaki wrote: Maybe I wasn't clear enough in the document, but this is the intent with the HTTPS proposal. I don't like the idea of a hard-coded mapping at all. We shouldn't be making choices on behalf of server operators. It's up to them how they arrange their domain names and paths. I also agree that DNS is not the technology to use. DNS is a nightmare. gen...@foo.org Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system responds with a bitcoin address. Whether the system gives you a new address from a pool of addresses, or contacts the merchant behind the scenes is implementation defined. I'll clarify it later. This is the relevant line: string strRequestUrl = strDomain + /bitcoin-alias/?handle= + pszEncodedNick; Between HTTPS service and server service, I lean slightly towards HTTPS (automatic encrypted connection, CAs + all benefits of DNS). But still interested in arguments in favour of a server service (daemon answering queries). Why bother with an encoding scheme at all? If the address gen...@foo.org always maps to https://foo.org/bitcoin-alias/?handle=genjix Then forget the hardcoding of https the hardcoding of bitcoin-alias and ?handle= and the original email-looking gen...@foo.org. Just use the URL. Then the author of the service can use whatever they want. Can I pay you 10 BTC? Sure, send it to 'https://bitcoinalias.foo.org/genjix/' While I might implement my alias server like this: Sure, send it to 'https://google.com/bitcoin/?andyparkins' Sure, send it to 'https://parkins.co.uk/; ... or any other URL they want -- any of which suit might suit me and my webserver better than whatever mapping would otherwise be hard-coded. The world is already very familiar with URLs so this is no more scary than the email address. What's more, the email address form looks _too much_ like an email address, and will only lead to confusion ... send it to gen...@foo.org so I use outlook express for that, right? erm, no, you put it in your bitcoin client. The URL form could easily be made to detect a browser connecting rather than a bitcoin client (and this is an area that would benefit from a standards document -- define the headers and user agent triggers that an alias server expects) and give them better instructions. https can be specified as the default, so https://; can be optional when they're typing. If, in the future, bitcoin gets a distributed peer-to-peer alias system, then a new URL type can be added easily bcalias://andyparkins might automatically find my node in the network and query it for an address (or whatever). All of the above is exactly why OpenID chose to use URLs for ID. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Nifty! Thanks for the pointers, I think we should avoid reinventing wheels whenever possible. Hear hear! When composing my last response in this thread I wrote, and then erased: There doesn't have to be one solution: I'd like to see some experimentation, with clients supporting different schemes for bitcoin address aliases, and maybe supporting plugins to extend the schemes supported (a plugin would take a string, do some behind-the-scenes-magic, and return a bitcoin address or public key). Sure. Alias systems are a usability focused requirement and as such should probably not be mandated by the network itself, anyway. Defining Bitcoin as an IIBAN institution, with 36^6 accounts, seems like a forward-thinking idea, although I'm not clear on exactly how those 2.2billion accounts would get allocated and mapped into bitcoin addresses. It seems a clarification is in order, apologies for not being clearer. Under the IIBAN scheme, whilst Bitcoin *could* define some default mechanism for automatically creating IIBANs that map to Bitcoin addresses (for example, Bitcoin client authors could provide hosted lookup), this was not the style of integration in mind while writing the IIBAN draft. Rather than simply defining Bitcoin as a single 'institution' (namespace segment) within the IIBAN standard, Payward Inc. envisages large numbers of parties (including individuals or small groups of individuals) operating individual Bitcoin-related (or LETS, or other alternate currency) services to register as institutions (really just 'namespace holders') within the IIBAN registry. Each such party may then define its own mapping system between Bitcoin, LETS, or other alternate currency financial endpoints that it 'manages' (proxies for) and IIBAN, within its namespace. As detailed within the IIBAN proposal, this process could be peer to peer or centralized, supporting one time or short-term use addresses as well as permanent addresses. A permanent address within IIBAN could map via the institution managing that portion of the IIBAN address space to a single use address on the Bitcoin network. Institutions are important for the following reasons (from http://tools.ietf.org/html/draft-iiban-00#section-4.3.2): With the advent of decentralized virtual currencies such as [BITCOIN] the conventional idea of a financial institution (such as a bank) may be seen by some as somewhat superfluous. However, the notion remains useful: * Conventional currencies will not disappear in the conceivable future, so the notion of financial institutions is expected to endure at least as providers of currency exchange and holding services. * Systems such as [BITCOIN] have quirks that require slightly delayed settlement due to the nature of their decentralized, consensus-based approach to fiscal transfer. Users requiring instant settlement MAY thus see benefit in the use of a centralized proxy system or organization as an instantaneous financial settlement provider (the 'institution'). * IANA MAY delegate management of portions of the IIBAN name space through such institutions. Furthermore from http://tools.ietf.org/html/draft-iiban-00#section-4.3.1: [Under IIBAN's combined issue paradigm] proxied issue is facilitated through IANA managed institution registration, provision for two types of privately issued addresses is reserved within this document, and registered institutions COULD provide DHT or similar mechanisms for the management of their delegated name space. The combined issue paradigm offers adequate provision for both manageability and decentralization, whilst maintaining heterogeneity. So the idea is that many institutions each provide mappings between IIBAN and Bitcoin, in a range of ways, and we do not see the emergence of a single mandated standard. There is no suggestion that Bitcoin developers should implement a hard-coded mechanism. I imagine some central organization that maps IIBAN account numbers to domain names... and then clients (or plugins in the clients) query that trusted central organization and then the account holder's domain to get a (possibly unique) public key or bitcoin address. This style of solution - in which a central organization becomes aware of every single IIBAN-based transaction in the network - is not necessary or desirable. Instead, under the IIBAN recommendation IANA would publish the registry of IIBAN institutions for everyone to use without the need to query any party. In the case of a financial transfer, a client or peer instutition seeking to send funds to an IIBAN-denominated address would use some hitherto-underfined mechanism* for translating the appropriate entry within that registry (corresponding to the transfer's destination address) to some kind of internet node representing the institution's systems. * This mechanism may necessitate the storage of public
