Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
On 2011 December 16 Friday, Rick Wesson wrote: On Thu, Dec 15, 2011 at 4:07 PM, slush sl...@centrum.cz wrote: I really like this proposal with standard URLs. All other proposals like DNS mapping or email aliases converted to URLs with some weird logic looks strange to me. wow, really. Maybe you could review some RFCs, there are thousands of examples where some really smart engineers chose the exact opposite path which you propose below. Could you point me at an example? Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ 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 Friday 16 Dec 2011 19:06:52 Gavin Andresen wrote: I think there is also a huge public relations benefit to using a standard like IIBAN instead of inventing our own. Having a Bitcoin Payment Routing Address (or whatever it ends up being called) that looks like the number issues by big financial institutions will give people the warm fuzzies. I can see the PR advantages, but isn't mapping from one massively long, multi-character, human-opaque number (IBAN) to another (bitcoin address) a bit of a waste of time? Surely the point of all this is to provide at least the possibility of a human-readable name for a bitcoin-address? Isn't there a possibility that one day we might want to be able to say send me those bitcoins you owe me to bitcoin.yahoo.co.uk/andyparkins? Or similar? Andy -- Dr Andy Parkins andypark...@gmail.com -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ 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 Fri, Dec 16, 2011 at 12:54 PM, Andy Parkins andypark...@gmail.com wrote: [snip] You've been unfair, the equivalent of your u...@authority.tld is https://authority.tld/user; or https://user.authority.tld/; or https://google.com/bitcoin/user; or any of an infinite number of other variations that _I_ as the mapper get to choose rather than whoever wrote the BIP; all of which are arguably no less elegant than that simple email. There is no equivalent in the other direction though. For someone who want's to supply the TX to their mapping server... where does it go in u...@authority.tld? actually there are many differences. Specifying a standard using a HTTP(s) transport for a look-up isn't something that has been done in the PATH portion of the URI and that I was pointing out that there is *NO* RFC that specifies such for a look-up provide the inverse of many protocol specifications that did *not* choose that methodology. What has happened is various schemes are specified, developed and deployed. I am sure you are familure with many. sip:// ftp:// etc:// many are described at http://en.wikipedia.org/wiki/URI_scheme NAPTR records (see http://en.wikipedia.org/wiki/NAPTR_record) are another area that deserves research for those that desire URI schemes. Understand that I am mearly advocating that as a group this work be done in standards development process, and that IBANN is one such effort. -rick -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Why don't just...
bitcoin://url.without.explicitly.specifying.provider
bitcoin://alias@provider
bitcoin://IIBAN@authorizedBitcoinInstitution ??
Andy sounded very convincing when talking in favor of URLs. What's
wrong with his proposal?
A URI identifies a resource and is in effect an alias itself.
Identifying a resource is different from interacting with it. So,
while resource-type://resource-type-specific-alias will work
sufficiently for the identification, it does not explain the
interaction.
Interaction is a requirement, since there seems to be a widely felt
need to preserve anonymity through the use of temporary addresses.
Generating a temporary address requires some actual processing to
achieve, since the issuing of the new address cannot be done without
interacting with the entity hosting the wallet (unless I'm missing
something?).
By the way, I don't like the fact that a single authorized institution
needs to map the IIBANs to bitcoin addresses.
This is not the case. Please read my earlier response to Gavin and the
IIBAN specification itself to clarify. That would be a total breach
of privacy since the entity would have access to financial information
on all transactions using the IIBAN identifiers... prior to
transactions being executed.
It *is* true that under the current IIBAN proposal there would be one
entity (IANA) in charge of issuing namespace portions ('institution
codes' - probably best to rename these...), however:
- The policy is strict and something similar to 'give one out to
anyone except existing financial instutions with the pre-existing
capacity to issue IBAN'.
- IANA have a pretty reasonable track record
- This suggestion, like the entire proposal, is open for discussion
and modification. If you can think of a more efficient and fair way
of assigning namespace prefixes to random entities on the internet
that doesn't require someone *without* an established track record of
doing this for the internet community to take up IANA's place, then
I'd be happy to hear it. Whilst a bitcoin-like 'community consensus'
system is conceivably possible to deploy in its place, I don't think
it's necessary.
Regards,
Walter Stanish
Payward, Inc.
--
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.
But none more important than the need to reduce IT complexity
while improving strategic productivity. Learn More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/
___
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 15 Thursday, Walter Stanish wrote: Andy sounded very convincing when talking in favor of URLs. What's wrong with his proposal? A URI identifies a resource and is in effect an alias itself. Identifying a resource is different from interacting with it. So, while resource-type://resource-type-specific-alias will work sufficiently for the identification, it does not explain the interaction. Quite so; the BIP15 standard shouldn't be setting the format of the URI; it should be setting what the format of the client-server conversation is. Effectively, what headers will a requesting client send? What headers should a server require? What will a server respond? Interaction is a requirement, since there seems to be a widely felt need to preserve anonymity through the use of temporary addresses. I think that's missing the point; any aliasing scheme is definitely reducing your anonymity, neccessarily so -- the alias has to be looked up somewhere, that somewhere reduces anonymity. If anonymity is what you want, stick with just a bitcoin address. The point of an aliasing server is surely to be able to give a single, unchanging, well known label to a transacting party, but still enable that party to generate a new address per transaction. I want my webshop to be able to say please pay 3.20 BTC to https://mywebshop.com/payments/orderid=27282; to enable the automatic connection from orderid to bitcoin address (which my payment system can then monitor for payment receipt). (This is just one example). Generating a temporary address requires some actual processing to achieve, since the issuing of the new address cannot be done without interacting with the entity hosting the wallet (unless I'm missing something?). Well yes; but then the client has no idea what address to send to unless it connects to that URI... interaction/address generation is done when that connection is made. In short: I don't really think that this aliasing system should be concerning itself with preserving anonymity of the receiving party. That is almost certainly already gone (I'm hardly likely to send money to someone I don't know unless I like gifting random cash). The sending party loses a little anonymity because their IP is revealed when they connect to the aliasing system. But there is very little anonymity in a supplier-client relationship anyway (you have to say what goods you want, and where you want them, and you had to interact with a website when you were ordering already). Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
2011/12/15, Walter Stanish wal...@stani.sh:
Interaction is a requirement, since there seems to be a widely felt
need to preserve anonymity through the use of temporary addresses.
Generating a temporary address requires some actual processing to
achieve, since the issuing of the new address cannot be done without
interacting with the entity hosting the wallet (unless I'm missing
something?).
I thought the interaction was just the server answering with an
address (maybe also amount and other details). But we don't have to
define how the server will get that address.
Some possibilities:
-A static address: less anonymity, but some people may not care. Say a
donation address.
-The servers stores the recipient private keys and generates a new one
for each payment.
-The server stores a set of addresses provided by the recipient and it
manages what address it gives in each request (like in the web service
I told you I can't find).
It *is* true that under the current IIBAN proposal there would be one
entity (IANA) in charge of issuing namespace portions ('institution
codes' - probably best to rename these...), however:
...
IANA reserves some namespace for bitcoin. All right.
The problem comes later.
* 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').
As I understand it (probably I'm wrong, because I haven't read the
whole IIBAN draft) there would be a bitcoin institution that would
map bitcoin addresses to the bitcoin subspace of the IIBAN.
* IANA MAY delegate management of portions of the IIBAN name space
through such institutions.
If we can find a deterministic method to map the subspace the all
possible bitcoin addresses, everything's fine again. But if that's not
possible, we would need a central institution to manage the mapping
and that would be a step back in decentralization.
I can't find the answer of Gavin's question How is the mapping done?
in your post. I'll re-read it though.
--
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.
But none more important than the need to reduce IT complexity
while improving strategic productivity. Learn More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Why don't just... bitcoin://url.without.explicitly.specifying.provider bitcoin://alias@provider bitcoin://IIBAN@authorizedBitcoinInstitution ?? By the way, I don't like the fact that a single authorized institution needs to map the IIBANs to bitcoin addresses. The IANA is a good institution to rely on for mapping things, much history and wise execution there. -rick -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ 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 really like this proposal with standard URLs. All other proposals like DNS mapping or email aliases converted to URLs with some weird logic looks strange to me. Plain URLs (returning address in response body, redirecting to URI bitcoin:address or anything else) are very clear solution, easy to implement in clients and very easy to understand by people. It's also extremely flexible - almost everybody can somewhere setup static file containing his personal addresses or it's very easy to integrate such solution with eshops (providing custom address for given order) etc. I'm definitely for this solution. Best, slush On Tue, Dec 13, 2011 at 5:22 PM, Andy Parkins andypark...@gmail.com wrote: 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 -- 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 -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
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. I like this a lot. It's very simple to understand and would be very easy to implement and set up. Sure, send it to david.bitcoin.se. D.H. -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Sure, send it to david.bitcoin.se. That's not a valid URI. I'm not sure I get your point. If someone tells you hey, check out the web page at xkcd.com, is that your response or do you just open up your web browser and type xkcd.com? D.H. -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
What if we specify bitcoin to make it easier for software (maybe the browser, a plugin for the browser, the bitcoin client analyzing the clipboard...) to easily detect that you expect a bitcoin address when going to url? If puted in the bitcoin client, the bitcoin:// is optional (? and can also be replaced by http ?) since from the context you already expect an address or an url that will give you the address. In the browser: bitcoin://address bitcoin://rest_of_url In the bitcoin client: address rest_of_url bitcoin://address bitcoin://rest_of_url http://rest_of_url ?? Maybe in the bitcoin client you can put any site and the client downloads the web to look for occurrences of bitcoin:// (? or just valid addresses ?) in it. It caches and shows them to you to decide what to do with each one. I have used other programs (jdownloader) that read the clipboard looking for patterns in links and is very convenient. Maybe then parameters for the client can be added to this. bitcoin://address?amount=10.53 bitcoin://rest_of_url?amount=10.53green_address=r bitcoin://rest_of_url?amount=10.53green_address=rgreen_address_list=address1,address2,address3 Whatever the community have planned for bitcoin URIs. -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ 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 looking at the wiki entry for this and noticed that your description of DNSSEC is incorrect. It is an internet standard and is widely deployed in the root (.), many TLDs, ccTLDs and second leverl domains. Also understand when the IETF or ICANN adopts new (we worked on DNSSEC no less than 10 years) standard the horizon is at least 20 years. Nothing and I really mean nothing is adopted in mass over shorter time scales. I also am largely in favor of using secured zones to publish TXT records to digital currencies. I've been thinking mainly about TXT using the following format for bitcoin. _btc.lhs.rhs you can look up the following record _btc.rick.wesson.us (from r...@wesson.us) which yealds ; DiG 9.6-ESV-R4-P3 _btc.rick.wesson.us txt ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 45136 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;_btc.rick.wesson.us. IN TXT ;; ANSWER SECTION: _btc.rick.wesson.us.299 IN TXT BTC=1\; 1GCVXLfF1TcpnnDLJRHk845NZhuJWQTnUD ;; Query time: 147 msec while this isn't a secured zone, any leverage of DNSSEC would require the application to have direct hooks into the stub-resolver, rather than just leveraging the OS's implementation. just some food for thought... -rick 2011/12/14 Jorge Timón timon.elvi...@gmail.com: What if we specify bitcoin to make it easier for software (maybe the browser, a plugin for the browser, the bitcoin client analyzing the clipboard...) to easily detect that you expect a bitcoin address when going to url? If puted in the bitcoin client, the bitcoin:// is optional (? and can also be replaced by http ?) since from the context you already expect an address or an url that will give you the address. In the browser: bitcoin://address bitcoin://rest_of_url In the bitcoin client: address rest_of_url bitcoin://address bitcoin://rest_of_url http://rest_of_url ?? Maybe in the bitcoin client you can put any site and the client downloads the web to look for occurrences of bitcoin:// (? or just valid addresses ?) in it. It caches and shows them to you to decide what to do with each one. I have used other programs (jdownloader) that read the clipboard looking for patterns in links and is very convenient. Maybe then parameters for the client can be added to this. bitcoin://address?amount=10.53 bitcoin://rest_of_url?amount=10.53green_address=r bitcoin://rest_of_url?amount=10.53green_address=rgreen_address_list=address1,address2,address3 Whatever the community have planned for bitcoin URIs. -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ 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 Wednesday, December 14, 2011 6:02:25 PM Rick Wesson wrote: I also am largely in favor of using secured zones to publish TXT records to digital currencies. I've been thinking mainly about TXT using the following format for bitcoin. _btc.lhs.rhs Don't confuse BTC (Bitcoin unit) with BC (Bitcoin in general / protocol)... The hard part of using DNS will be sticking to the standard good practice of using a new address for every transaction. -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
understand that not *everyone* wants or will adhere to that best practice and in my NSHO it isn't. -rick 2011/12/14 Luke-Jr l...@dashjr.org: On Wednesday, December 14, 2011 6:02:25 PM Rick Wesson wrote: I also am largely in favor of using secured zones to publish TXT records to digital currencies. I've been thinking mainly about TXT using the following format for bitcoin. _btc.lhs.rhs Don't confuse BTC (Bitcoin unit) with BC (Bitcoin in general / protocol)... The hard part of using DNS will be sticking to the standard good practice of using a new address for every transaction. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Could we combine this proposal and the HTTPS proposal? The DNSSEC TXT record could give instructions on how to query an HTTPS server to get the address. Then we get the dynamism of HTTPS without having a rigid URL scheme for querying the server along with the advantages of DNSSEC. --- On Wed, 12/14/11, Rick Wesson r...@support-intelligence.com wrote: From: Rick Wesson r...@support-intelligence.com Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases To: Luke-Jr l...@dashjr.org Cc: bitcoin-development@lists.sourceforge.net Date: Wednesday, December 14, 2011, 8:22 PM understand that not *everyone* wants or will adhere to that best practice and in my NSHO it isn't. -rick 2011/12/14 Luke-Jr l...@dashjr.org: On Wednesday, December 14, 2011 6:02:25 PM Rick Wesson wrote: I also am largely in favor of using secured zones to publish TXT records to digital currencies. I've been thinking mainly about TXT using the following format for bitcoin. _btc.lhs.rhs Don't confuse BTC (Bitcoin unit) with BC (Bitcoin in general / protocol)... The hard part of using DNS will be sticking to the standard good practice of using a new address for every transaction. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
It is a lot easier to set up an HTTP server to dynamically respond with addresses than a DNS record. It is considered a good practice to use a different address for every payment. It stopped being just a website a long time ago. For many of us, most of us, Wikipedia has become an indispensable part of our daily lives. — Jimmy Wales, Founder of Wikipedia Help protect it now. Please make a donation today: http://www.wikimediafoundation.org/wiki/Donate --- On Wed, 12/14/11, Kyle Henderson k...@old.school.nz wrote: From: Kyle Henderson k...@old.school.nz Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases To: Zell Faze zellf...@yahoo.com Cc: Luke-Jr l...@dashjr.org, Rick Wesson r...@support-intelligence.com, bitcoin-development@lists.sourceforge.net Date: Wednesday, December 14, 2011, 11:56 PM Just so we're clear, what is the need for HTTP at all? A query for a string and an answer can all be handled via DNS. On Thu, Dec 15, 2011 at 4:57 PM, Zell Faze zellf...@yahoo.com wrote: Could we combine this proposal and the HTTPS proposal? The DNSSEC TXT record could give instructions on how to query an HTTPS server to get the address. Then we get the dynamism of HTTPS without having a rigid URL scheme for querying the server along with the advantages of DNSSEC. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Just so we're clear, what is the need for HTTP at all? A query for a string and an answer can all be handled via DNS. It is a lot easier to set up an HTTP server to dynamically respond with addresses than a DNS record. Interesting that you bring up the effort factor. The notion that every individual will want to run their own DNS or HTTP based alias system to dispense transaction-specific bitcoin addresses seems - on this basis - alone a little far fetched. Such a system would provide very little added value at significant hassle to the small subset of users who could be bothered setting up such a scheme. Also, remember that most people in the world don't even know what DNS is, nor do they have the capacity or motivation to set up a program on a web server for what amounts to minor ongoing time savings and some vanity thrills. To my mind, it is far more likely that third party hosted services (such as providers of hosted wallet, conventional currency holding and exchange services) will provide aliasing resolution, and that these alias resolution services will operate on an alias@provider mechanism (for example, IIBAN and its 'institution' codes @ ). In addition, during the 'pre-transaction exchange' that the alias resolution process essentially represents, additional value could be added by these types of service providers by providing functionality presently excluded from Bitcoin but relevant to real world financial systems. For example this 'pre-transaction exchange' process might include, in addition to alias resolution, transaction metadata exchange (transaction description, invoice/order number, taxation information, schedules of fees and charges, pre-arranged currency exchange rates if filling an payment for an amount quoted in another (eg: conventional) currency, shipping terms, transaction reversal (cancellation) terms, escrow terms, etc.) Regards, Walter Stanish Payward Inc. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ 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] 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
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
I'm confused about the problem we're trying to solve. 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. Then I remembered FirstBits, went to my terminal and typed 1brmlab. I got their bitcoin address from the website and copied that, then opened my terminal and pasted that in to send 1 BTC. And these proposals for Namecoin, would make bitcoin implementations dependent on unproven technology. HTTPS/DNSSEC have been around a long time and are responsible for many mission critical systems. There's a lot of momentum behind those projects. Namecoin by contrast, could die tomorrow. And it isn't a big deal that they're centralised. This is a convenience for end users and does not affect the core system much. tl;dr: usability -- 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. Then I remembered FirstBits, went to my terminal and typed 1brmlab. I got their bitcoin address from the website and copied that, then opened my terminal and pasted that in to send 1 BTC. ok, imagine if firstbits didn't exist. instead of going to firstbits, you would have gone to your terminal, opened up brmlabs website, and copied the address from there? there may be some arguments for name- address translation, but i'm sorry to say, that your example is not one of them. if anything, it seems to suggest that firstbits is completely useless, since it saves approximately zero 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
