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
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
>
> 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
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
>
> 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
>
>
> 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
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
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
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
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
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
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
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
> (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
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: 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
> 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
17 matches
Mail list logo