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.
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
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
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
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
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
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
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
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
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.
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
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
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
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
, 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
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
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
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
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
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
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
(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
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
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
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
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
26 matches
Mail list logo
