On Fri, Dec 16, 2011 at 12:54 PM, Andy Parkins 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
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 fi
On Friday 16 Dec 2011 17:41:25 Rick Wesson wrote:
> Its a negative example -- in that the IETF does not specify anything
> in the PATH part of the URI. The scheme, sure, but not in the path,
> there are many types of URI schemes ( start with RFC 2396 )
You seem to have jumped off the topic; you me
Agreed, I find measured dialog much more valuable. I also agree that
standards take time and are messy, though choosing a standard allows
additional participation and can drive interopability. One does not
need to accept IBANN but we should participate in the dialog in its
development. internet-dra
First: everybody please try to focus on the issues/ideas, and try to
avoid this becoming a flame war.
Second: I think Walter Stanish made several good points that may have
been missed in all the long posts and discussion, the main one being:
The banking industry has been dealing with many of thes
, December 16, 2011 5:41 PM
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Its a negative example -- in that the IETF does not specify anything
in the PATH part of the URI. The scheme, sure, but not in the path,
there are many types of URI schemes ( start with RFC 2396 )
There is signific
On Fri, Dec 16, 2011 at 12:36 PM, Khalahan wrote:
> Namecoin is a peer-to-peer generic name/value datastore system.
> Don't forget it's not limited to .bit usage ! So, directly mapping
> things to .bit url would not be the optimal way of using namecoin.
>
> Namecoin is specificaly designed to map
Its a negative example -- in that the IETF does not specify anything
in the PATH part of the URI. The scheme, sure, but not in the path,
there are many types of URI schemes ( start with RFC 2396 )
There is significant upside to having your own scheme and having apps
understand how to integrate wit
Namecoin is a peer-to-peer generic name/value datastore system.
Don't forget it's not limited to .bit usage ! So, directly mapping
things to .bit url would not be the optimal way of using namecoin.
Namecoin is specificaly designed to map things to names in a fully
decentralized way. So, it's the p
On 2011 December 16 Friday, Rick Wesson wrote:
> On Thu, Dec 15, 2011 at 4:07 PM, slush 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
OK, I'm ignoring your sarcastic style, I just wanted to support the URL
idea, which is KISS attitude, in the oposite of everything else proposed
here. I'm really affraid of over-engineering the aliases, which will make
it hard to implement in clients. Somebody noticed account implementation in
stan
On Thu, Dec 15, 2011 at 4:07 PM, slush 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 whe
On Thu, Dec 15, 2011 at 04:26:38PM +0800, Walter Stanish wrote:
> 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
>> 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 wi
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:" or anything else) are very clear solution, easy to
implem
> 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 in
tect it now. Please make a donation today:
> http://www.wikimediafoundation.org/wiki/Donate
>
>
> --- On *Wed, 12/14/11, Kyle Henderson * wrote:
>
>
> From: Kyle Henderson
>
> Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
> To: "Zell Faze"
> Cc: "Luke-Jr"
> 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 store
2011/12/15, Walter Stanish :
> 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
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 ://
>> 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 effe
2011/12/15, Jordan Mack :
> I believe it is also worth mentioning the possible susceptibility of a
> DOS attack on a publicly available alias system. Assuming that an alias
> lookup triggers the creation of a new Bitcoin address, the private key
> would need to be retained indefinitely. If gone unn
Andy sounded very convincing when talking in favor of URLs. What's
wrong with his proposal?
2011/12/15, Walter Stanish :
> 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 a
I believe it is also worth mentioning the possible susceptibility of a
DOS attack on a publicly available alias system. Assuming that an alias
lookup triggers the creation of a new Bitcoin address, the private key
would need to be retained indefinitely. If gone unnoticed, this could
consume con
>> 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 ev
pedia 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 wrote:
From: Kyle Henderson
Subject: Re: [Bitcoin-develo
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 wrote:
> Could we combine this proposal and the HTTPS proposal?
>
> The DNSSEC TXT record could give instructions on how to query an H
, 12/14/11, Rick Wesson wrote:
> From: Rick Wesson
> Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
> To: "Luke-Jr"
> Cc: bitcoin-development@lists.sourceforge.net
> Date: Wednesday, December 14, 2011, 8:22 PM
> understand that not *everyone* wants
&
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 :
> 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
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..
Don't confuse BTC (Bitcoin unit) with BC (Bitc
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
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
On Wed, 2011-12-14 at 15:07 -0500, Luke-Jr wrote:
> > "Sure, send it to david.bitcoin.se".
>
> That's not a valid URI.
I realize I'm responding to an useless nitpick with another useless
nitpick but here goes.
It doesn't have to be a valid URI. As long as the recipient (or the
software he's usin
>> "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.
On Wednesday, December 14, 2011 2:22:12 PM D.H. wrote:
> > 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
> 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
> 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: 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
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
> (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
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
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
1:06 PM
Subject: 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 '@ef
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
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 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
>
> 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
even more sense since namecoin started merged mining.
On 13 December 2011 08:03, Cameron Garnham wrote:
>
> Sent from my Windows Phone
> De: Amir Taaki
> Enviado: 13/12/2011 0:43
> Para: bitcoin-development@lists.sourceforge.net
> Asunto: Re: [Bitcoin-development] Fwd: [BIP 1
On Mon, Dec 12, 2011 at 9:37 PM, Amir Taaki wrote:
> lol, way to miss the point nanotube.
>
> FirstBits *is* useless, but not for the reasons you specified. But simply
> because the resources it needs rises exponentially as the number of
> participants in the network grows linearly.
>
> The poin
On Monday, December 12, 2011 9:37:06 PM Amir Taaki wrote:
> In our revised history, I simply send 1 BTC to brmlab
And then Joe Address Squatter gets 1 BTC. BOOM.
--
Systems Optimization Self Assessment
Improve efficiency
to send 1 BTC.
In our revised history, I simply send 1 BTC to brmlab
BOOM.
Club Mate
- Original Message -
From: Daniel F
To: Amir Taaki
Cc: "bitcoin-development@lists.sourceforge.net"
Sent: Tuesday, December 13, 2011 2:32 AM
Subject: Re: [Bitcoin-development] Fwd: [BIP 15
> 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
> 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 type
53 matches
Mail list logo
