Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-13 Thread Walter Stanish
> 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 diff

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-13 Thread Gavin Andresen
RE: IIBAN numbers: Nifty! Thanks for the pointers, I think we should avoid reinventing wheels whenever possible. 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 differe

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-13 Thread Andy Parkins
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 t

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-13 Thread Jorge Timón
> (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 informatio

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-13 Thread Walter Stanish
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 interne

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-13 Thread Luke-Jr
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' aug

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-13 Thread Amir Taaki
Maybe I wasn't clear enough in the document, but this is the intent with the HTTPS proposal. 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

Re: [Bitcoin-development] Version bytes "2.0"

2011-12-13 Thread Luke-Jr
On Tuesday, December 13, 2011 6:07:17 AM Mike Hearn wrote: > 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. Bitcoin-Qt 0.6 will include a QR Code gene

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-13 Thread Gavin Andresen
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

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-13 Thread Jorge Timón
No decentralized solution for non-fixed addresses comes to mind. If we're going to always rely on servers, we should definitely offer dynamic addresses. There was a bitcoin service in the forum to which merchants send different addresses and the service manages the payments for the merchant withou

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-13 Thread Christian Decker
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 agree with Mike that a fixed address is not the way to go, because addresses should be used once for a s

Re: [Bitcoin-development] Version bytes "2.0"

2011-12-13 Thread Wladimir
> > > 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 ma

Re: [Bitcoin-development] Version bytes "2.0"

2011-12-13 Thread Mike Hearn
> > 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 mos

Re: [Bitcoin-development] Version bytes "2.0"

2011-12-13 Thread Wladimir
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/p

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-13 Thread Mike Hearn
> > 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

Re: [Bitcoin-development] Version bytes "2.0"

2011-12-13 Thread Mike Hearn
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 int

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-13 Thread Cameron Garnham
Namecoin makes sense; as we can use the same private keys to spend the namecoin as spending the bitcoins. Namecoin happens to be the only secure guaranteed global unique human rememberable string system that exists. I suggest that sending bitcoins to a namecoin name is the way to go... It makes e