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

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

[Zell Faze]

I agree with Luke-Jr.  We need to try to find a decentralized solution if we are going to implement BIP 15.  Bitcoin needs to remain decentralized in every aspect of the protocol or we lose its greatest strength.

I feel like the HTTPS idea would be a great idea for a client feature, but not really something that should be added to the protocol.

--- On Mon, 12/12/11, Luke-Jr <luke@dashjr.org> wrote:

> From: Luke-Jr <luke@dashjr.org>
> Subject: Re: [Bitcoin-development] [BIP 15] Aliases
> To: bitcoin-development@lists.sourceforge.net, "Amir Taaki" <zgenjix@yahoo.com>
> Date: Monday, December 12, 2011, 5:32 PM
> FirstBits looks nice at glance, but
> is bound to create a gold-rush to grab 
> every nice-looking FirstBits address.
> 
> HTTPS is only as secure as the (centralized) CAs, thus not
> really any better 
> than TXT records.
> 
> I don't think an address of some form is avoidable.

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

[Jorge Timón]

I don't think Amir wants to put it into the protocol, but I still
don't like much the proposal if it has to rely on servers.
As an aside, even if firstbits it's not useful enough for the human
memory, it is still useful for QR-codes like in the case of green
addresses's POS instant payments.

Would it be too strange to use namecoin?
Some devices may need to rely on block exploring servers, but it is
the easiest decentralized solution that comes to mind.


2011/12/13, Zell Faze <zellfaze@yahoo.com>:
> I agree with Luke-Jr.  We need to try to find a decentralized solution if we
> are going to implement BIP 15.  Bitcoin needs to remain decentralized in
> every aspect of the protocol or we lose its greatest strength.
>
> I feel like the HTTPS idea would be a great idea for a client feature, but
> not really something that should be added to the protocol.
>
> --- On Mon, 12/12/11, Luke-Jr <luke@dashjr.org> wrote:
>
>> From: Luke-Jr <luke@dashjr.org>
>> Subject: Re: [Bitcoin-development] [BIP 15] Aliases
>> To: bitcoin-development@lists.sourceforge.net, "Amir Taaki"
>> <zgenjix@yahoo.com>
>> Date: Monday, December 12, 2011, 5:32 PM
>> FirstBits looks nice at glance, but
>> is bound to create a gold-rush to grab
>> every nice-looking FirstBits address.
>>
>> HTTPS is only as secure as the (centralized) CAs, thus not
>> really any better
>> than TXT records.
>>
>> I don't think an address of some form is avoidable.
>
>
> ------------------------------------------------------------------------------
> 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
>


-- 
Jorge Timón

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

[Will]

[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]

Are there any PGP key servers that support EC key pairs?  OpenPGP Spec
RFC2440 defines key types for EC, just not sure if they were ever
implemented on the keyserver side.  Could even have a similar 'web of
trust' using private keys to sign people's identities similar to PGP.

Will

On 12 December 2011 23:16, Zell Faze <zellfaze@yahoo.com> wrote:

> I agree with Luke-Jr.  We need to try to find a decentralized solution if
> we are going to implement BIP 15.  Bitcoin needs to remain decentralized in
> every aspect of the protocol or we lose its greatest strength.
>
> I feel like the HTTPS idea would be a great idea for a client feature, but
> not really something that should be added to the protocol.
>
> --- On Mon, 12/12/11, Luke-Jr <luke@dashjr.org> wrote:
>
> > From: Luke-Jr <luke@dashjr.org>
> > Subject: Re: [Bitcoin-development] [BIP 15] Aliases
> > To: bitcoin-development@lists.sourceforge.net, "Amir Taaki" <
> zgenjix@yahoo.com>
> > Date: Monday, December 12, 2011, 5:32 PM
> > FirstBits looks nice at glance, but
> > is bound to create a gold-rush to grab
> > every nice-looking FirstBits address.
> >
> > HTTPS is only as secure as the (centralized) CAs, thus not
> > really any better
> > than TXT records.
> >
> > I don't think an address of some form is avoidable.
>
>
>
> ------------------------------------------------------------------------------
> 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
>

[-- Attachment #2: Type: text/html, Size: 2760 bytes --]

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

[Luke-Jr]

On Monday, December 12, 2011 6:37:56 PM Jorge Timón wrote:
> Would it be too strange to use namecoin?

This has the same problem as FirstBits, except .bit domains are dirt cheap, 
whereas vanitygen at least slows down grabbing all the common words...

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

[Matt Corallo]

On Tue, 2011-12-13 at 00:37 +0100, Jorge Timón wrote:
> I don't think Amir wants to put it into the protocol, but I still
> don't like much the proposal if it has to rely on servers.
> As an aside, even if firstbits it's not useful enough for the human
> memory, it is still useful for QR-codes like in the case of green
> addresses's POS instant payments.
Firstbits isn't acceptable for anything.  As Amir originally pointed
out, it doesn't scale well and worst of all it fills the blockchain with
a ton of crap to get 1 satoshi at an address so that it is
"registered".  
> 
> Would it be too strange to use namecoin?
> Some devices may need to rely on block exploring servers, but it is
> the easiest decentralized solution that comes to mind.
Firstbits is unacceptable because it causes unnecessary harm to each
Bitcoin node.  However, if one were to use a chain specifically crafted
for such a purpose isn't terrible.  That said, it still doesn't scale
well and if it becomes popular virtually every implementation would have
to rely on trusted servers at which point you are better off going back
to an HTTPS/DNSSEC-based implementation

Matt

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

[Jorge Timón]

Is the point is to have different hosts like in jtimon@gmail.com,
jtimon@timon.es, etc. so if jtimon is already taken I can take another
host?

What about reserving directly the string "jtimon@nottaken.org" or
"jtimon::public::receiving::bitcoin" in namecoin?

I'm confused about the problem we're trying to solve.


2011/12/13, Luke-Jr <luke@dashjr.org>:
> On Monday, December 12, 2011 6:37:56 PM Jorge Timón wrote:
>> Would it be too strange to use namecoin?
>
> This has the same problem as FirstBits, except .bit domains are dirt cheap,
> whereas vanitygen at least slows down grabbing all the common words...
>

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

[Amir Taaki]

> 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

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

[Daniel F]

> 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.

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

[Amir Taaki]

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 point is that if FirstBits were built into the implementation, that would allow me to simply send to 1brmlab. The proposal here is not for a website where people can lookup bitcoin addresses, but a shared naming scheme between bitcoin implementations. Here's the story again:

> 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.

In our revised history, I simply send 1 BTC to brmlab

BOOM.

Club Mate



----- Original Message -----
From: Daniel F <nanotube@gmail.com>
To: Amir Taaki <zgenjix@yahoo.com>
Cc: "bitcoin-development@lists.sourceforge.net" <bitcoin-development@lists.sourceforge.net>
Sent: Tuesday, December 13, 2011 2:32 AM
Subject: 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.

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

[Stefan Thomas]

>> Would it be too strange to use namecoin?
> This has the same problem as FirstBits, except .bit domains are dirt cheap,
> whereas vanitygen at least slows down grabbing all the common words...

Grabbing is no more an issue than mining Bitcoins is an issue. Sure, 
domain grabbers will have the domains first, but they want to profit and 
therefore are willing to sell them for whatever price they can get. Just 
like the trading of any other limited resource, this process sounds like 
somebody is getting rich for nothing, but it does tend to put the 
limited resources to good use as people who waste good domains can't 
afford them in the long run. The problem with Firstbits is that the 
names already grabbed have fixed private keys that are known by their 
originators. That makes the names untradable. This may be fixable with 
split keys, but a lot of "good" 1firstbits are already made useless in 
this way.

Names in Namecoin can be transferred/traded securely, strong 
cryptography is built in and it shares mining without bloating the 
Bitcoin block chain. I see it as a decentralized DNS alternative at a 
time when domain seizures are on the rise, even absent any court order.

So I would use one of the DNS-based solutions that Amir suggested and 
simply require standard-compliant clients to be able to look up .bit 
(i.e. Namecoin) domains as well. That way we have a pragmatic solution, 
but one that also provides security and true decentralization for the 
more paranoid of our users.


On 12/13/2011 12:41 AM, Luke-Jr wrote:
> On Monday, December 12, 2011 6:37:56 PM Jorge Timón wrote:
>> Would it be too strange to use namecoin?
> This has the same problem as FirstBits, except .bit domains are dirt cheap,
> whereas vanitygen at least slows down grabbing all the common words...
>
> ------------------------------------------------------------------------------
> 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

[Luke-Jr]

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.

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

[Daniel F]

On Mon, Dec 12, 2011 at 9:37 PM, Amir Taaki <zgenjix@yahoo.com> 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 point is that if FirstBits were built into the implementation, that would allow me to simply send to 1brmlab. The proposal here is not for a website where people can lookup bitcoin addresses, but a shared naming scheme between bitcoin implementations. Here's the story again:

well, it's easy to miss the point when the example you use doesn't
make the point you think you're making. :D
but ok, yes, it would be nice to send directly to something like
1brmlab from the client. i suppose figuring out how to make sure that
1brmlab actually does send to whom you think it sends, is left to the
details of implementation, but that's a separate question.

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]

>
> 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=foo&label=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.

[-- Attachment #2: Type: text/html, Size: 2347 bytes --]

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

[Christian Decker]

[-- Attachment #1: Type: text/plain, Size: 3822 bytes --]

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 single transaction to be able to track payments.

While firstbits sounds attractive at first, I think we can all agree that
it just isn't feasible and would not allow per-transaction addresses. DNS
sounds interesting for fixed addresses, but caching and propagation make it
difficult to use for per-transaction addresses that are to be generated
ad-hoc.

HTTP(S) is the best option I think, merchants are probably using HTTP
anyway for their shops. So something like
http://merchant.com/btc/transaction/1234 sounds reasonable. But I think it
should not be over-engineered, it should be a simple HTTP(S) request to a
merchant specified URL that returns an ASCII document containing either a
bitcoin: URI or simply the bitcoin address or even a 301 redirect. It's no
use to start defining URL schemes, it should be left to the merchants to
define how to structure them.

This would allow a merchant to decide if he prefers per-transaction
addresses, per-user transactions, fixed addresses or any combination.

Regards,
cdecker


On Tue, Dec 13, 2011 at 11:55 AM, Mike Hearn <mike@plan99.net> wrote:

> 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=foo&label=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
>
>

[-- Attachment #2: Type: text/html, Size: 4946 bytes --]

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

[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 without holding his private keys. The service identified each
shopping cart by a combination of the total amount and the selected
address for that cart. I don't remember the name of the service
though.
It could easily implement aliases (the same alias for various rotating
addresses). Of course, the service provider still knows your income
and you still need to provide new addresses to maintain your privacy.
I say this just in case it inspires someone.

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

[Gavin Andresen]

I agree with Mike Hearn and Christian Decker-- paying to
'somebody@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 'somebody@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

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

[Amir Taaki]

Maybe I wasn't clear enough in the document, but this is the intent with the HTTPS proposal.

genjix@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).


----- Original Message -----
From: Gavin Andresen <gavinandresen@gmail.com>
To: Jorge Timón <timon.elviejo@gmail.com>
Cc: "bitcoin-development@lists.sourceforge.net" <bitcoin-development@lists.sourceforge.net>
Sent: Tuesday, December 13, 2011 1:06 PM
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

I agree with Mike Hearn and Christian Decker-- paying to
'somebody@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 'somebody@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

[Luke-Jr]

On Tuesday, December 13, 2011 8:06:15 AM Gavin Andresen wrote:
> I agree with Mike Hearn and Christian Decker-- paying to
> 'somebody@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 somebody@foo.com a signed message.

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

[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
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.

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

[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 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.

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

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 2925 bytes --]

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.

> genjix@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

  genjix@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 "genjix@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 genjix@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
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[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 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)."

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.

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.

As long as IIBANs are not the ONLY way of aliasing bitcoin addresses
to more-human-friendly strings I think that would be a fine way to do
it.

-- 
--
Gavin Andresen

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

[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 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 keys within the
IIBAN institution registry and will be addressed within the next
version of the IIBAN draft.  Community input is encouraged.

In a second yet-to-be-define protocol**, various settlement-system
neutral (ie: not specific to Bitcoin, LETS, or any other system)
transaction-related metadata would then be exchanged, prior to any
actual transaction.  Such metadata could include aspects of the
transaction such as description, financial system endpoint ('account')
holder name, account exists verification, settlement path negotiation
(based upon feasibility, transaction overheads, latency, etc.), which
party is to pay overheads, information mandated by local jurisdiction
such as business tax numbers (required in some countries of Europe, I
believe, for domestic B2B settlements), etc.

** This mechanism does need to be defined, and Payward Inc. has
completed a not insubstantial amount of research in to existing
protocols and concerns within this area, which touches upon high
frequency automated banking, financial market support, and interbank
settlement policy.  An additional Internet Draft proposing one such
potential mechanism will probably be published 'soon'.

At the conclusion of this metadata exchange, the two nodes would have
either aborted the transaction, suspended it to seek human input (such
as settlement path selection based upon fee and latency metadata
garnered), or agreed upon financial settlement system specific
information to use in executing the transaction itself, likely out of
band. In the case of Bitcoin, this *might* include information such as
the blockcount after which the transaction will be considered settled
by the receiving institution, an effective 'gentleman's agreement' on
the terms of any opt-in notion of reversibility, a one time Bitcoin
address provided by the recipient institution for the sender to make a
Bitcoin transaction to, etc.

From the perspective of a settlement system such as Bitcoin, IIBAN's
provision of settlement system neutral financial endpoint
identification provides the benefits outlined in the previous email,
as well as the possibility to publish a permanent, fixed address
without disclosing one's corresponding Bitcoin-derived income.  From
the broader perspective of effective financial system innovation, it
hopes to provide a common basis upon which many such systems can
conceivably interoperate, regardless of their underlying systemic
differences.

> As long as IIBANs are not the ONLY way of aliasing bitcoin addresses
> to more-human-friendly strings I think that would be a fine way to do
> it.

Thank you for your vote of confidence.

Regards,
Walter Stanish
Payward Inc.

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

[D.H.]

> Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" and> "?handle=" and the original email-looking "genjix@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.

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

[Luke-Jr]

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 "genjix@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".

That's not a valid URI.

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

[D.H.]

>> "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.

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

[Joel Joonatan Kaartinen]

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 using) can make it into a valid URI. My web-browser
definitely would open http://david.bitcoin.se/ from that. For bitcoin
clients, https:// should be the guess it tries.

- Joel

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

[Jorge Timón]

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.53&green_address=r
bitcoin://rest_of_url?amount=10.53&green_address=r&green_address_list=address1,address2,address3

Whatever the community have planned for bitcoin URIs.

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

[Rick Wesson]

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
rick@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.elviejo@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.53&green_address=r
> bitcoin://rest_of_url?amount=10.53&green_address=r&green_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

[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 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.

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

[Rick Wesson]

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 <luke@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.

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

[Zell Faze]

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 <rick@support-intelligence.com> wrote:

> From: Rick Wesson <rick@support-intelligence.com>
> Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
> To: "Luke-Jr" <luke@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 <luke@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

[Kyle Henderson]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

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 <zellfaze@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.
>
>

[-- Attachment #2: Type: text/html, Size: 739 bytes --]

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

[Zell Faze]

[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]

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" <zellfaze@yahoo.com>
Cc: "Luke-Jr" <luke@dashjr.org>, "Rick Wesson" <rick@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 <zellfaze@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.






[-- Attachment #2: Type: text/html, Size: 2342 bytes --]

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

[Walter Stanish]

>> 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.

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

[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 unnoticed, this could 
consume considerable resources over time. Unlike system logs and such, 
this is not something that can be so easily pruned.

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

[Jorge Timón]

Andy sounded very convincing when talking in favor of URLs. What's
wrong with his proposal?

2011/12/15, Walter Stanish <walter@stani.sh>:
> 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 @ ).

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.

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

[Jorge Timón]

2011/12/15, Jordan Mack <jordanmack@parhelic.com>:
> 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 considerable resources over time. Unlike system logs and such,
> this is not something that can be so easily pruned.

You're right. Then servers should not use a different address with
every lookup. Maybe don't change it more than once per
min/hour/whatever, maybe wait to see a payment to that address to
start giving another one...

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

[Walter Stanish]

>> 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.

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

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 2680 bytes --]

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
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Jorge Timón]

2011/12/15, Walter Stanish <walter@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.

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

[Christian Decker]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

> 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).
>

Exactly, I think we should starting separating the minimal protocol that is
to be supported by everybody, and the rest can be summed up in a few best
practices, no need to standardize the part that to the user is transparent.
I was on the same lines as Andy, which is that in order to have require a
payment I probably have an order/transaction pending with my vendor or have
an account to be filled, so there's a 1-to-1 mapping between the details
page and the bitcoin address I have to send to.

As a further possibility we could use <meta> tags like the OpenID server
delegation mechanism. It would allow customers to open the transaction
details page, see that everything is ok, then paste the same URL into the
bitcoin client, the bitcoin client retrieves the URL, parses the meta tag
and knows what to send where. Alternatively the Bitcoin Client sends an
Accept header which tells the server to return just the address.

As for the format I'd say either a Bitcoin address or a Bitcoin URI [1]
which ought to be flexible enough as it includes amount and messages, for
the customer to be able to track transactions.

Regards,
Chris

[1] https://en.bitcoin.it/wiki/URI_Scheme

[-- Attachment #2: Type: text/html, Size: 1952 bytes --]

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

[Rick Wesson]

[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]

Are we designing protocols or applications, its easier and better for all
involved if we design a protocol and then let the applications implement
it.

Lets stick to understanding how labels (dns) or URIs can be leveraged to
securly obtain a bitcoin address, rather than reviewing capabilities of
current applications.

-rick

On Wed, Dec 14, 2011 at 10:04 PM, Zell Faze <zellfaze@yahoo.com> wrote:

> 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*
> <http://2e740a1a.qvvo.com/>
>
> 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" <zellfaze@yahoo.com>
> Cc: "Luke-Jr" <luke@dashjr.org>, "Rick Wesson" <
> rick@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 <zellfaze@yahoo.com<http://mc/compose?to=zellfaze@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.
>
>
>

[-- Attachment #2: Type: text/html, Size: 3358 bytes --]

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

[Rick Wesson]

> 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

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

[slush]

[-- Attachment #1: Type: text/plain, Size: 4219 bytes --]

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 <andyparkins@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.
>
> > genjix@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
>
>  genjix@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 "genjix@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
> genjix@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
> andyparkins@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
>
>

[-- Attachment #2: Type: text/html, Size: 5930 bytes --]

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

[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 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.

Sure, but this falls short of requirements for most users.

> -The servers stores the recipient private keys and generates a new one
> for each payment.

Equivalent to hosted wallet, which is decentralization in a BIG way,
but apparently a very popular choice (for pragmatic reasons).
Probably not going away.

> -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).

True.  However, probably a poor user experience for most users re:
provision of temporary addresses to the alias host.  Also the
knowledge of which entity for which inbound payment has been allocated
which temporary address would be a significant complexity in the alias
host / end user relationship that you gloss over.  This is important
for businesses, since inbound payments are only really possible to
track - AFAIK (correct me if I'm wrong, the two exceptions being the
edge case of people requesting inbound transactions where every single
transaction is of a unique amount and no 'partial payment' (2x
transactions for one inbound payment) and the case where every single
inbound payer's sending address is previously known) - by issuing
unique recipient addresses to each client.  In short, it's kind of
similar to hosted wallet as well, since you need to absolutely trust
your host (they could tell people wishing to make payments to you to
pay someone else instead!).

> 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.

Many people can get namespace management rights as
'institutions' (in the current draft's terminology), then manage
the assignement of IIBANs within that space as they wish.
There would be many institutions with many IIBANs.  The
association of a bitcoin address (or many addresses, or
the capacity to generate temporary addresses as required)
with an IIBAN would be the responsibility of either that
namespace manager ('institution') or the individual who
has acquired that IIBAN via that namespace manager
('insitution').

> "    * 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.

Many institutions, many policies, no absolute centralization, though
admittedly increased centralization. However, this is a problem shared
with two of your proposals (the subset not disqualified as failing to
meet most user's requirements) when you consider that most users (if
you consider 'the whole world's mobile devices' a potential userbase,
as I prefer to do) do not have the technical skills to configure,
secure and manage their own 'always on' alias service hosts, nor the
capacity to host blockchain copies on those devices (either due to
space or bandwidth requirements. As an aside, this is a large part of
the unfortunate reality that is tending to push Bitcoin towards hosted
wallet solutions)

> I can't find the answer of Gavin's question "How is the mapping done?"
> in your post. I'll re-read it though.

Near the top, beginning "It seems a clarification is in order,
apologies for not being clearer."  (Re-reading, it's still not that
clear!)

Regards,
Walter Stanish
Payward, Inc.

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

[Pieter Wuille]

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 of the new address cannot be done without
> interacting with the entity hosting the wallet (unless I'm missing
> something?).

Just replying to this one comment: yes, some interaction is always
necessary, but not necessarily directly with the entity hosting the wallet.
There are some EC crypto tricks to do this (often mentioned under
"deterministic wallets" before):

The wallet-hosting entity has a private key x, with public key X.
The address-generating entity knows X, and generates a fresh private
key y for each transaction. For each, it calculates Z=y*X, and asks
the client to pay to hash160(Z). Afterwards, it can send a bunch of
y's to the wallet hosting service, which can reconstruct z=y*x for
each. Alternatively, the y's can be generated according to a predefined
scheme instead.

-- 
Pieter

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

[Rick Wesson]

On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@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.

-rick

> 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 <andyparkins@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.
>>
>> > genjix@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
>>
>>  genjix@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 "genjix@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
>> genjix@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
>> andyparkins@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

[slush]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

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
standard client - yes, it's good example of fail.

I still don't see any serious issue with the URL proposals. And sipa's idea
of posting back the transaction ID is also interesting, prividing yet
another flexibility in implementation and possible usage.

Btw, Rick, feel free to provide me some relevant RFCs which are solving
similar problems like BIP 15. And no, it's not sarcasm, I really want to
learn something new. Until now I just feel we're reinventing wheel or
raping some stuff which we should not touch at all (DNS).

slush

On Fri, Dec 16, 2011 at 4:52 PM, Rick Wesson
<rick@support-intelligence.com>wrote:

> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@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.
>
> -rick
>
>

[-- Attachment #2: Type: text/html, Size: 1950 bytes --]

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

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 569 bytes --]

On 2011 December 16 Friday, Rick Wesson wrote:
> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@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
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Khalahan]

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 perfect starting point to map names to
other things (a public bitcoin address, an url, etc)
You won't have all the advantages of namecoin when using other systems
like DNS and HTTP(S) as the first entry point.

What is namecoin ?

* proven technology :
- do not mix the namecoin technology and the dot-bit namespace with .bit
domains (dot-bit domains needs dot-bit compatible dns servers or proxies
+ namecoin and have a small visibility due to the nature of
top-to-bottom domain name system controlled by ICANN, namecoin needs
only namecoin to store data !)
- as proven and secure as bitcoin
- merged mining provides a secure network

* decentralized :
- a lot of nodes, and you can have your own node
- everybody can register his own name, by itself with the namecoin
software (bitcoin could even allow registration directly from it,
easily) or by using a name provider
- everybody can become a name provider (register for your friends and
resell names).

* no single point of failure :
- DNS and HTTPS have several limitations (Man in the Middle attacks, no
reliable authority of certifications, domain seizure, ...)

* designed for that :
- namecoin uses a system of namespaces to separate each usages :
http://dot-bit.org/Main_Page#Namespaces.
For example, the "personal namespace" draft
(http://dot-bit.org/Personal_Namespace) could be extended to support
mapping to a bitcoin address, or a dedicated namespace can be used if
prefered (the "bitcoin/" or "alias/" or "map/" prefixes for example).

* easily connectable to bitcoin
- they both use RPC and json to exchange informations, so connecting one
to the other is really easy
- bitcoin could even allow registration of names by sending an RPC
request to namecoin

* extensible and not limited :
- you are not forced to store a bitcoin address directly in namecoin,
you can also store an url or a domain name
- allows additional security : add a certificate fingerprint combined
with an https url (so, using DNS or HTTP(S) is not a major problem
anymore if the first point of entry is really secure and configurable
[and you use and self-signed certificate])
- really easy to update
- simple for simple cases
- possibility to use a nick, an email address or a domain as name
- other methods to get bitcoins addresses can be added later, protocol
is extensible


Examples of possible registered names in namecoin with the "personal
namespace" (with the "p/" prefix) :

* An individual person with well known public addresses :
"p/khal":
{
    "email": "khal@dot-bit.org",
    "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}

* Another individual person with well known public addresses :
"p/khal@dot-bit.org":
{
    "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}

* A merchant accepting payments in bitcoin, namecoin, paypal or
othercoin (to show you how the whole namespace could be used) :
"p/mymerchant.com":
{
    "bitcoin": {
        "url": "https://payto.mymerchant.com/bitcoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"
        "cert": "https://payto.mymerchant.com/certificate.pem",
    },
    "namecoin": {
        "url": "https://payto.mymerchant.com/namecoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"
    },
    "paypal": "xxxxxx@yyyyyyyyy.zzz",
    "othercoin": "oxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

* A merchant with a public address, an url to generate custom addresses
and a domain name (not sure if this case is really usefull, maybe as
fallback)
"p/mymerchant2":
{
    "bitcoin": {
        "url": "https://payto.mymerchant.com/bitcoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926",
        "dns": "_bitcoin.payto.mymerchant.com",
        "address": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    }
}


* How to use it in bitcoin ?

Several possibilities of address syntax :
- khal, khal@dot-bit.org, mymerchant.com, mymerchant2 : no syntax limit
- mymerchant2@bitcoin : will conflict with names already containing a @
- mymerchant2@namecoin : same
- namecoin:mymerchant2 : strange syntax, confusing with the "uri scheme"
- namecoin://mymerchant2 : same
- other ?


Here is how things would be processed when people put an address to pay
to in the bitcoin client :

* address : khal
-> RPC to namecoin for "p/khal"
-> json processing for "p/khal->bitcoin"
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T

* address : khal@dot-bit.org
-> RPC to namecoin for "p/khal@dot-bit.org"
-> json processing for "p/khal@dot-bit.org->bitcoin"
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T

* address : mymerchant.com
-> RPC to namecoin for "p/mymerchant.com"
-> json processing for "p/mymerchant.com->bitcoin"
-> json processing for "p/mymerchant.com->bitcoin->url" and
"p/mymerchant.com->bitcoin->fpr"
-> https request to "https://payto.mymerchant.com/bitcoin/"
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy

* address : mymerchant2
-> RPC to namecoin for "p/mymerchant2"
-> json processing for "p/mymerchant2->bitcoin"
-> json processing for "p/mymerchant2->bitcoin->url" and
"p/mymerchant2->bitcoin->fpr"
-> https request to "https://payto.mymerchant.com/bitcoin/"
-> result : error (website unavailable, page not found, timeout, etc)
-> json processing for "p/mymerchant2->bitcoin->dns"
-> dns request for "_bitcoin.payto.mymerchant.com"
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy

Le 13/12/2011 14:06, Gavin Andresen a écrit :
> I agree with Mike Hearn and Christian Decker-- paying to
> 'somebody@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 'somebody@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.
>


-- 
Best Regards,
Khalahan
http://dot-bit.org/

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

[Rick Wesson]

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 with it. Frankly, having just one client
(I understand there are more) is an artifact that hinders acceptance
and participation. If you want to go the route of https then
specifying a scheme is your path forward

I still believe that it is experience that is leading this thread down
the rat-hole of CGI and HTTP requests. The stuff isn't magic, it is
just what you are used to. Review the bitcoin protocol, there is an
elegance there -- not found  in the https schemes proposed thus far.
CGI isn't a protocol, nor does it address usability/identity issues.

Providing a mapping from user@authority.tld addresses usability and
identity. I'd like to see an elegant transformation, specifically I
take to task anyone that advocates
https://authority/foo/user?tx=1zhd789632uilos as elegant.

-rick


On Fri, Dec 16, 2011 at 9:10 AM, Andy Parkins <andyparkins@gmail.com> wrote:
> On 2011 December 16 Friday, Rick Wesson wrote:
>> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@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
> andyparkins@gmail.com

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

[Gregory Maxwell]

On Fri, Dec 16, 2011 at 12:36 PM, Khalahan <khal@dot-bit.org> 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 things to names in a fully
> decentralized way. So, it's the perfect starting point to map names to
> other things (a public bitcoin address, an url, etc)
> You won't have all the advantages of namecoin when using other systems
> like DNS and HTTP(S) as the first entry point.


How can one construct a zero-trust (or nearly zero trust) namecoin
resolver without having a copy of the ever growing complete namecoin
block chain?

The bitcoin lite node mechanism will not work because a peer could
return stale records or no-result and you would have no evidence of
their deception.  (In the case of lite bitcoin nodes, telling you
about old transactions is harmless because you control your own
transactions).

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

[Amir Taaki]

[-- Attachment #1: Type: text/plain, Size: 3424 bytes --]

You have to be seriously joking to call the bitcoin protocol elegant. A message based system over TCP with constantly changing endians that needs to lookup its own IP address on several websites is not elegant. It is functioning, not elegant.

Also it is kind of dick to come guns blaring and start insulting slush who runs one of the biggest mining pools and is working on electrum, and sipa who develops the satoshi bitcoin.

Khalahan said:

> Namecoin is a peer-to-peer generic name/value datastore system

Namecoin has the same problem as DNS. From the document:

"The disadvantage of DNS TXT records is that updating a record takes 
time. This encourages people to not use new addresses per transaction 
which has certain security issues."


________________________________
 From: Rick Wesson <rick@support-intelligence.com>
To: Andy Parkins <andyparkins@gmail.com> 
Cc: bitcoin-development@lists.sourceforge.net 
Sent: Friday, 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 significant upside to having your own scheme and having apps
understand how to integrate with it. Frankly, having just one client
(I understand there are more) is an artifact that hinders acceptance
and participation. If you want to go the route of https then
specifying a scheme is your path forward

I still believe that it is experience that is leading this thread down
the rat-hole of CGI and HTTP requests. The stuff isn't magic, it is
just what you are used to. Review the bitcoin protocol, there is an
elegance there -- not found  in the https schemes proposed thus far.
CGI isn't a protocol, nor does it address usability/identity issues.

Providing a mapping from user@authority.tld addresses usability and
identity. I'd like to see an elegant transformation, specifically I
take to task anyone that advocates
https://authority/foo/user?tx=1zhd789632uilos as elegant.

-rick


On Fri, Dec 16, 2011 at 9:10 AM, Andy Parkins <andyparkins@gmail.com> wrote:
> On 2011 December 16 Friday, Rick Wesson wrote:
>> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush@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
> andyparkins@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

[-- Attachment #2: Type: text/html, Size: 5069 bytes --]

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

[Gavin Andresen]

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 these issues for
years; I think we should not dismiss their experience.

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 don't really care what happens behind the scenes, as long as it is
as secure as an HTTPS connection (RE: CA pwnage:  there's no such
thing as perfect security, and until a more secure solution comes
along HTTPS is the best we've got).

And I'll reiterate that there doesn't have to be just one solution.

My only concern is that IIBAN is Yet Another Fledgling Standard, and
those little details that remain to be worked out could take years to
actually work out.

-- 
--
Gavin Andresen

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

[Rick Wesson]

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-drafts don't make it through the process
unchanged. IBANN is a starting point not the end of the discussion.

-rick

On Fri, Dec 16, 2011 at 11:06 AM, Gavin Andresen
<gavinandresen@gmail.com> wrote:
> 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 these issues for
> years; I think we should not dismiss their experience.
>
> 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 don't really care what happens behind the scenes, as long as it is
> as secure as an HTTPS connection (RE: CA pwnage:  there's no such
> thing as perfect security, and until a more secure solution comes
> along HTTPS is the best we've got).
>
> And I'll reiterate that there doesn't have to be just one solution.
>
> My only concern is that IIBAN is Yet Another Fledgling Standard, and
> those little details that remain to be worked out could take years to
> actually work out.
>
> --
> --
> Gavin Andresen
>
> ------------------------------------------------------------------------------
> 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

[Andy Parkins]

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 mentioned that there were 
thousands of RFCs that we should review over why we shouldn't use a URI; and 
you've pointed at an RFC that shows how a URI can be used.

While you're right that CGI and HTTP aren't magic; they are commonplace; and 
it's important when we want an infinitely expandable mapping system that 
people can use technology they are already familiar with. People already 
have web servers, people already understand URIs.  It's not "just what we 
are used to"; people who can cope with development of the bitcoin protocol 
aren't going to be worried about protocol complexity.  It is a concern about 
what the rest of the world will have to do to get a bitcoin alias.

> Providing a mapping from user@authority.tld addresses usability and

No it doesn't address usability at all, because it falls down on the first 
attempt: what if I want to supply a URI that allows my web service to link 
an invoice number to an issued bitcoin address?  You've forced every mapping 
service to be identical, and limited.

> identity. I'd like to see an elegant transformation, specifically I
> take to task anyone that advocates
> https://authority/foo/user?tx=1zhd789632uilos as elegant.

You've been unfair, the equivalent of your "user@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 
"user@authority.tld"?



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

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

[Andy Parkins]

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
andyparkins@gmail.com

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

[Rick Wesson]

On Fri, Dec 16, 2011 at 12:54 PM, Andy Parkins <andyparkins@gmail.com> wrote:

[snip]

>
> You've been unfair, the equivalent of your "user@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
> "user@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

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

[Jordan Mack]

I don't think protocol buffers are as simple to implement as some would 
like. I would still opt for it over MIME though.


On 12/19/2011 10:50 AM, Jorge Timón wrote:
> I don't have a strong position for or against JSON but...What about
> protocol buffers?
> Would it be too much too? Would it be simple enough for developers?

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

[Jordan Mack]

I wish that was the case. It would have made my life a lot easier in the 
past. A lot of the MIME libraries out there are extremely buggy. MIME is 
just difficult to work with, and support is still weak.

Undefined content length + text based boundaries = pain in the ass.

It is in the e-mail module because that's all MIME was originally 
intended for. It's now grown beyond that now, but you will find the MIME 
functions still live in the e-mail libraries. When dealing with raw MIME 
encoded data, e-mail is still the most common case.


On 12/19/2011 11:16 AM, Luke-Jr wrote:
> MIME has been around much longer, and should have sufficient support in every
> language by now. For some reason, Python calls the module 'email'.

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

[Jordan Mack]

If alias resolution was guaranteed to always be just the address, then 
yes, I would opt for no serialization at all. A simple plain text 
response of an address is about as simple as it can get.

There are already a lot of good ideas floating around about how the 
alias protocol could be extended. Is it really going to stay that simple 
for long? I would personally much just have a serialized response 
upfront, rather than having to worry about backward compatibility in the 
future.

On 12/19/2011 10:17 AM, slush wrote:
> In my opinion, there's not necessary any payload format (json, xml,
> multipart). In keeping stuff KISS, everything we need is just an address
> in response + potentially some stuff like HTTP redirects (for providing
> additional compatibility for proposal of bitcoin URIs with "amount",
> "label" and other parts). I don't see reason why we need some extra
> payload yet.

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

[Luke-Jr]

On Monday, December 19, 2011 1:52:54 PM Jordan Mack wrote:
> I believe I'm missing something here. I was under the interpretation
> that alias resolution was going the KISS route, of basically a single
> HTTP request and response. How do you see binary data fitting into this?

Bitcoin is a binary system. Not all payment outputs are necessarily 
serializable into addresses, and assuming they are would be broken-by-design.
In other words, why send the user's *software* "pay to address foo" just to 
have it turn that into a script (of limited subset), when you can send the 
script itself and avoid all the possible problems? Doing this right also means 
that if the user's client doesn't support version 255 addresses, it still 
works fine.

> I'm not going to pretend that I know all the details of the difficulties
> that were encountered with JSON-RPC. But in the argument of developer
> accessibility, it still serves a purpose. If JSON-RPC support is
> removed, you will immediately lose a large pool of high level language
> developers.

JSON isn't problem-free at high-level either. To summarize one of the issues, 
almost every implementation of JSON treats Numbers differently based on 
whether they have a '.' in them or not.

MIME has been around much longer, and should have sufficient support in every 
language by now. For some reason, Python calls the module 'email'.

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

[Jordan Mack]

I believe I'm missing something here. I was under the interpretation 
that alias resolution was going the KISS route, of basically a single 
HTTP request and response. How do you see binary data fitting into this?

I'm not going to pretend that I know all the details of the difficulties 
that were encountered with JSON-RPC. But in the argument of developer 
accessibility, it still serves a purpose. If JSON-RPC support is 
removed, you will immediately lose a large pool of high level language 
developers. I would hope that support would not be dropped, even if it 
only remains as a secondary protocol with limited capability. Most high 
level developers are only going to use it for basic functions anyhow.



On 12/19/2011 10:15 AM, Luke-Jr wrote:
> Because computers work with binary. I don't think anyone wants to implement a
> fully functional script assembler just to send funds.
>
> JSON-RPC won't go on forever. In any case, bitcoind's use of JSON-RPC is
> exactly why I (and many other developers) have come to the realization how
> poorly supported JSON really is. Most of the common languages do have a
> library, but almost all of them have one issue or another (particularly around
> the very undefined Number type).

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

[Jorge Timón]

I don't have a strong position for or against JSON but...What about
protocol buffers?
Would it be too much too? Would it be simple enough for developers?

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

[slush]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

In my opinion, there's not necessary any payload format (json, xml,
multipart). In keeping stuff KISS, everything we need is just an address in
response + potentially some stuff like HTTP redirects (for providing
additional compatibility for proposal of bitcoin URIs with "amount",
"label" and other parts). I don't see reason why we need some extra payload
yet.

slush

On Mon, Dec 19, 2011 at 7:13 PM, Jordan Mack <jordanmack@parhelic.com>wrote:

> If the idea is to "KISS", and provide a method that is both quick and
> easy to implement for the average developer, then JSON is a stand out
> option. Using HTTP for the data interchange will make things difficult
> for a lot of developers if multipart responses are used. JSON will be
> greeted with open arms.
>
>

[-- Attachment #2: Type: text/html, Size: 1124 bytes --]

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

[Luke-Jr]

On Monday, December 19, 2011 12:04:34 PM Jordan Mack wrote:
> I still think HTTPS should be used, at the minimum. Using HTTPS is
> standard to every website out there that deals with financials, even if
> it is not a perfect system. Why should Bitcoin adopt a more lax policy
> than everyone else?

Sure, I meant HTTP as the underlying protocol.
TLS/SSL should of course be required in some form.

> I thought that JSON support was fairly common these days. I personally
> prefer XML in most cases, but since JSON is already used with the RPC,
> it seemed like a natural fit here. 

JSON-RPC won't go on forever. In any case, bitcoind's use of JSON-RPC is 
exactly why I (and many other developers) have come to the realization how 
poorly supported JSON really is. Most of the common languages do have a 
library, but almost all of them have one issue or another (particularly around 
the very undefined Number type).

XML shares the same binary-data problem as JSON, too.
As slush mentioned, no additional serialization is necessary anyway.

> Binary data can be base64 encoded, although I'm not sure why you would need
> to send back binary in an alias response.

Because computers work with binary. I don't think anyone wants to implement a 
fully functional script assembler just to send funds.

> What exactly do you mean by "custom output script"?

This suggests you need to learn more about how Bitcoin works ;)
https://en.bitcoin.it/wiki/Script

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

[Jordan Mack]

With all due respect, I continue to disagree on the topic of using HTTP 
for data interchange.

Yes, an HTTP multipart response will accomplish the need for multiple 
named resources. The problem is that parsing of a multipart response 
isn't simple, and library support is weak across many languages. The 
widely adopted cURL library does not support multipart response parsing 
at all.

JSON is widely adopted, human readable, and has parsing libraries 
available for every major language. There is a bit of additional bloat, 
but I believe it is warranted in this case because of the convenience 
and ease it brings to developers.

If the idea is to "KISS", and provide a method that is both quick and 
easy to implement for the average developer, then JSON is a stand out 
option. Using HTTP for the data interchange will make things difficult 
for a lot of developers if multipart responses are used. JSON will be 
greeted with open arms.



On 12/19/2011 9:09 AM, slush wrote:
> I agree with Luke that HTTP standard has everything necessary and
> bloating payload with json/xml is not necessary.
>
> Btw that argument "we have json in client already" seems pretty wrong,
> because json in server rpc solves another problem (and solve it in wrong
> way, because of data type issues, but it's another story).

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

[solar]

Using commercial CAs to establish trust is a site local administrative policy..

Bitcoin and operating systems have no technical need to concern themselves with this.  It is a shame that the system has been abused by CAs paying off operating system and web browser vendors but this is not the only way to use it.. my policy may be (as an example) to require each party I deal with to generate their own self signed cert or their own CA cert (same thing really) and then I can trust that and only that.  Obviously, commercial CAs will sell a certificate to anyone which means you trust anyone that is their customer.  This is a valid site policy but not for everyone.

Rick Wesson's suggestion about DNSSEC and such is interesting since it would provide a system for that 'first contact' exchange where you can more reliably retrieve the certificate, if the site supports it.  Some policies may not require this however - you can always get the trust established another way like downloading a cert file from a website or whatever else you consider adequately secure for your organization.

I think 3rd party CA lists and the DNSSEC/DANE idea are both useful ways to automatically establish trust out of band, but this is independent of the actual implementation of alias resolution, which happens after a trusted connection is made.  Automatically establishing trust with the alias resolver is perhaps a useful feature, but not a requirement for either side to support alias resolution.

In any case, it sounds like using HTTPS and x.509 certs would allow many of these automatic trust establishment systems to be implemented on top, allowing flexible policy configuration, which seems to be important to several people in this thread of discussion.

I think using JSON would be ok but like it's been said, you either have to serialize your binary data into some text format like base64/UUencode or represent it as an integer array, both of which are inefficient.. probably cancelling out any benefit of using JSON in the first place :)

Maybe there is no need for binary data for alias resolution though.. I imagine it would be as simple as submitting a name to resolve, and giving back a base58 address string, perhaps along with a textual comment or other extra, information data.

Being strict or lax or anything else is not really a concern for alias resolution - establishing trust is an administrative issue with a lot of different solutions and not every site or application requires trust.  HTTPS and mutual authentication may be desirable for general cases, however HTTP should work just as well if trust is established another way and thus SSL/TLS is not a requirement for the HTTP exchange to work.  As an example use case, I may be using IPsec or any number of other systems external to bitcoin and alias resolution itself.

Laszlo



On Dec 19, 2011, at 4:35 PM, Luke-Jr wrote:

> On Monday, December 19, 2011 6:44:59 AM Andy Parkins wrote:
>> Perhaps we should be more strict about which CA certificates are trusted by
>> the bitcoin client: say restrict it to those who have demonstrably good
>> practices for verifying identity; rather than the ridiculous amount of
>> trust that comes pre-installed for me in my browser.
> 
> Accepted CAs is/should be a property of your *operating system*, not any 
> particular software. Anyhow, restricting this further just makes it even more 
> unusable. Already there is only 1 or 2 CAs that will provide a gratis 
> certificate for personal/small users. If you only allow high-class CAs, I 
> imagine that will restrict "no key in the URI" aliases to those who will fork 
> over a lot of money.
> 
> ------------------------------------------------------------------------------
> 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] [BIP 15] Aliases

[slush]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

I agree with Luke that HTTP standard has everything necessary and bloating
payload with json/xml is not necessary.

Btw that argument "we have json in client already" seems pretty wrong,
because json in server rpc solves another problem (and solve it in wrong
way, because of data type issues, but it's another story).

slush

On Mon, Dec 19, 2011 at 6:04 PM, Jordan Mack <jordanmack@parhelic.com>wrote:

> I thought that JSON support was fairly common these days. I personally
> prefer XML in most cases, but since JSON is already used with the RPC,
> it seemed like a natural fit here. Binary data can be base64 encoded,
> although I'm not sure why you would need to send back binary in an alias
> response.
>

[-- Attachment #2: Type: text/html, Size: 1028 bytes --]

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

[Jordan Mack]

I still think HTTPS should be used, at the minimum. Using HTTPS is 
standard to every website out there that deals with financials, even if 
it is not a perfect system. Why should Bitcoin adopt a more lax policy 
than everyone else?

I thought that JSON support was fairly common these days. I personally 
prefer XML in most cases, but since JSON is already used with the RPC, 
it seemed like a natural fit here. Binary data can be base64 encoded, 
although I'm not sure why you would need to send back binary in an alias 
response.

What exactly do you mean by "custom output script"?


On 12/19/2011 8:30 AM, Luke-Jr wrote:
> I'd prefer we stick to simple standards.
> HTTP alone should really be fine to build on...
>
> JSON in particular has very poor language support, and cannot reasonably
> represent binary data (such as a custom output script). The HTTP
> specification, however, allows binary data in multipart content just fine.

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

[Luke-Jr]

On Monday, December 19, 2011 6:44:59 AM Andy Parkins wrote:
> Perhaps we should be more strict about which CA certificates are trusted by
> the bitcoin client: say restrict it to those who have demonstrably good
> practices for verifying identity; rather than the ridiculous amount of
> trust that comes pre-installed for me in my browser.

Accepted CAs is/should be a property of your *operating system*, not any 
particular software. Anyhow, restricting this further just makes it even more 
unusable. Already there is only 1 or 2 CAs that will provide a gratis 
certificate for personal/small users. If you only allow high-class CAs, I 
imagine that will restrict "no key in the URI" aliases to those who will fork 
over a lot of money.

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

[Luke-Jr]

On Monday, December 19, 2011 2:56:09 AM Jorge Timón wrote:
> For the "answer format" JSON seems ok,

I'd prefer we stick to simple standards.
HTTP alone should really be fine to build on...

JSON in particular has very poor language support, and cannot reasonably 
represent binary data (such as a custom output script). The HTTP 
specification, however, allows binary data in multipart content just fine.

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

[Rick Wesson]

You are describing the problem DANE addresses, see
http://tools.ietf.org/html/draft-ietf-dane-protocol-12


Using Secure DNS to Associate Certificates with Domain Names For TLS

Abstract

   TLS and DTLS use PKIX certificates for authenticating the server.
   Users want their applications to verify that the certificate provided
   by the TLS server is in fact associated with the domain name they
   expect.  TLSA provides bindings of keys to domains that are asserted
   not by external entities, but by the entities that operate the DNS.
   This document describes how to use secure DNS to associate the TLS
   server's certificate with the intended domain name.


For those of you against DNSSEC, DANE leverages it significantly.

The point I have been attempting to make is if one to rely on HTTPS,
leveraging DANE will allow you to mitigate CAs and use self signed
cers but you will need to leverage DNSSEC to bind the self signed cert
using DANE and if you are going to rely on DNSSEC for DANE to support
HTTPS, why not short-circut this madness and just publish your
identifiers and secure the zone via DNSSEC and link in a stub resolver
in the client.

Short story: transform user@authority.tld  --> _btc.user.athority.tld TXT 1z....

A short i-d is probably a better way to explain, so I will task myself
to do that.

-rick


On Mon, Dec 19, 2011 at 6:46 AM, solar <solar@heliacal.net> wrote:
> I think HTTPS, and more specifically x.509 PKI certs and CAs are generally a good idea and (historical implementation bugs aside) the concept is technically sound and secure.  What is a bad idea (in my opinion) is to trust a software vendor to decide who you should trust.. thus it is a bad idea for bitcoin software to promise any trust.
>
> The part where the concept becomes flawed is trusting 3rd parties who have no relationship with you, to serve your interests.  Now I'm just generalizing here and this is not universally true.. but internet CAs just want to sell certificates - they generally don't care beyond that, and they abuse the certificate validity dates to charge more money.  All this is done under the guise of wanting to provide a secure experience to users without a prior relationship to the entity being identified.  I propose that trying to follow this paradigm in bitcoin alias resolution is a bad idea because it tries to solve 2 problems at once, one of which does not have any 'good' solution, and forces a specific policy.
>
> First, we need to resolve an alias to a bitcoin address somehow.. but secondly we need to establish trust with the entity doing the alias resolution - to make sure that we can trust the response.
>
> When resolving an alias you will have to query an untrusted server, possibly being proxied by an 'attacker'.  Presumably, an x.509 certificate will be presented, possibly self signed or chained off a self generated CA or whatever else.. but if it's your first contact then there is no possible way to know if it's correct or not.  You would have to retrieve the correct public key of the CA to compare to first, possibly out of band.  Get it from my website, compare it to my business card, send me an email and I'll send it to you, or get it from some other source using some other pre existing trust (a centralized and possibly private directory perhaps).  The point is, the reason there is so much disagreement is because there is no good way to trust the resolver if you don't create that trust relationship prior to resolving an alias from it.
>
> I think that having to pre-trust the resolver would be an acceptable solution to all.. Those whose policy requires a simpler process can get a 3rd party CA list, much like the ones provided with web browsers and operating systems.  Those with strict verification policies can choose to pre verify every public key.. and these processes are familiar to many organizations using PKI for other things already.  In a client, presenting the usual certificate detail dialog, showing the public key, subject, issuer, and thumbprint would be sufficient to allow users to implement their own policies without forcing it one way or another.
>
> Please consider that while some organizations or users might require strong anonymity and pre existing trust, there are others who may want to do the opposite and that is just as valid, even if you or 'everyone else' disagrees with that.  In the case of bitcoin, it will be used as part of a larger system, and whatever concerns are created by 'insecure' alias resolution may well be addressed in another part of the system.  The most successful standards and implementations are the ones which provide the most flexibility - primarily because that allows users to extend them in ways the original designers didn't necessarily plan for.
>
> Thanks,
> Laszlo
>
>
>
> On Dec 19, 2011, at 11:44 AM, Andy Parkins wrote:
>
>> On 2011 December 19 Monday, Jorge Timón wrote:
>>> Ok, so HTTP is not an option unless it shows a huge warning. I don't
>>> know the HTTPS possible attack, but maybe it needs a warning message
>>> too, from what you people are saying. Although using namecoin to
>>
>> The problems with HTTPS have been social rather than technical.  Multiple CAs
>> have been strong-armed by governments or tricked into issuing fake
>> certificates by scammers.  There is no technical measure around that.  By
>> using the CA certificate we are saying to the system "here is someone I trust
>> to issue a certificate".  So far, with a large number of CAs, that trust is
>> misplaced.
>>
>> I'm of the opinion though that this problem is outside the remit of bitcoin to
>> solve.
>>
>> Perhaps we should be more strict about which CA certificates are trusted by
>> the bitcoin client: say restrict it to those who have demonstrably good
>> practices for verifying identity; rather than the ridiculous amount of trust
>> that comes pre-installed for me in my browser.
>>
>>
>>
>> Andy
>>
>> --
>> Dr Andy Parkins
>> andyparkins@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
>
>
> ------------------------------------------------------------------------------
> 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] [BIP 15] Aliases

[solar]

I think HTTPS, and more specifically x.509 PKI certs and CAs are generally a good idea and (historical implementation bugs aside) the concept is technically sound and secure.  What is a bad idea (in my opinion) is to trust a software vendor to decide who you should trust.. thus it is a bad idea for bitcoin software to promise any trust.

The part where the concept becomes flawed is trusting 3rd parties who have no relationship with you, to serve your interests.  Now I'm just generalizing here and this is not universally true.. but internet CAs just want to sell certificates - they generally don't care beyond that, and they abuse the certificate validity dates to charge more money.  All this is done under the guise of wanting to provide a secure experience to users without a prior relationship to the entity being identified.  I propose that trying to follow this paradigm in bitcoin alias resolution is a bad idea because it tries to solve 2 problems at once, one of which does not have any 'good' solution, and forces a specific policy.

First, we need to resolve an alias to a bitcoin address somehow.. but secondly we need to establish trust with the entity doing the alias resolution - to make sure that we can trust the response.

When resolving an alias you will have to query an untrusted server, possibly being proxied by an 'attacker'.  Presumably, an x.509 certificate will be presented, possibly self signed or chained off a self generated CA or whatever else.. but if it's your first contact then there is no possible way to know if it's correct or not.  You would have to retrieve the correct public key of the CA to compare to first, possibly out of band.  Get it from my website, compare it to my business card, send me an email and I'll send it to you, or get it from some other source using some other pre existing trust (a centralized and possibly private directory perhaps).  The point is, the reason there is so much disagreement is because there is no good way to trust the resolver if you don't create that trust relationship prior to resolving an alias from it.

I think that having to pre-trust the resolver would be an acceptable solution to all.. Those whose policy requires a simpler process can get a 3rd party CA list, much like the ones provided with web browsers and operating systems.  Those with strict verification policies can choose to pre verify every public key.. and these processes are familiar to many organizations using PKI for other things already.  In a client, presenting the usual certificate detail dialog, showing the public key, subject, issuer, and thumbprint would be sufficient to allow users to implement their own policies without forcing it one way or another.

Please consider that while some organizations or users might require strong anonymity and pre existing trust, there are others who may want to do the opposite and that is just as valid, even if you or 'everyone else' disagrees with that.  In the case of bitcoin, it will be used as part of a larger system, and whatever concerns are created by 'insecure' alias resolution may well be addressed in another part of the system.  The most successful standards and implementations are the ones which provide the most flexibility - primarily because that allows users to extend them in ways the original designers didn't necessarily plan for.

Thanks,
Laszlo



On Dec 19, 2011, at 11:44 AM, Andy Parkins wrote:

> On 2011 December 19 Monday, Jorge Timón wrote:
>> Ok, so HTTP is not an option unless it shows a huge warning. I don't
>> know the HTTPS possible attack, but maybe it needs a warning message
>> too, from what you people are saying. Although using namecoin to
> 
> The problems with HTTPS have been social rather than technical.  Multiple CAs 
> have been strong-armed by governments or tricked into issuing fake 
> certificates by scammers.  There is no technical measure around that.  By 
> using the CA certificate we are saying to the system "here is someone I trust 
> to issue a certificate".  So far, with a large number of CAs, that trust is 
> misplaced.
> 
> I'm of the opinion though that this problem is outside the remit of bitcoin to 
> solve.
> 
> Perhaps we should be more strict about which CA certificates are trusted by 
> the bitcoin client: say restrict it to those who have demonstrably good 
> practices for verifying identity; rather than the ridiculous amount of trust 
> that comes pre-installed for me in my browser.
> 
> 
> 
> Andy
> 
> -- 
> Dr Andy Parkins
> andyparkins@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] [BIP 15] Aliases

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 1088 bytes --]

On 2011 December 19 Monday, Jorge Timón wrote:
> Ok, so HTTP is not an option unless it shows a huge warning. I don't
> know the HTTPS possible attack, but maybe it needs a warning message
> too, from what you people are saying. Although using namecoin to

The problems with HTTPS have been social rather than technical.  Multiple CAs 
have been strong-armed by governments or tricked into issuing fake 
certificates by scammers.  There is no technical measure around that.  By 
using the CA certificate we are saying to the system "here is someone I trust 
to issue a certificate".  So far, with a large number of CAs, that trust is 
misplaced.

I'm of the opinion though that this problem is outside the remit of bitcoin to 
solve.

Perhaps we should be more strict about which CA certificates are trusted by 
the bitcoin client: say restrict it to those who have demonstrably good 
practices for verifying identity; rather than the ridiculous amount of trust 
that comes pre-installed for me in my browser.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Jorge Timón]

Ok, so HTTP is not an option unless it shows a huge warning. I don't
know the HTTPS possible attack, but maybe it needs a warning message
too, from what you people are saying. Although using namecoin to
identify hosts may be the more secure option, it's integration with
the client seems more difficult and probably most clients won't
support it. Using namecoin to directly specify the payment address
seems a bad idea for most cases for the reasons that have been said.

For the "answer format" JSON seems ok, but I mean a "negotiating
protocol" like luke-jr says. I'd even include green addresses there
but probably many of you don't like the idea.

2011/12/19, slush <slush@centrum.cz>:
> And if I need to choose between easy solution or secure solution for
> aliases, I'll pick that easy one. I mean - we need some solution which will
> be easy enough for daily use; it is something what we currently don't have.
> But if I want to be really really sure I'm using correct destination for
> paying $1mil for a house, I can every time ask for real bitcoin addresses,
> this is that secure way which we currently have.

I agree.

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

[slush]

[-- Attachment #1: Type: text/plain, Size: 2720 bytes --]

Pieter, it was more rhetorical question than asking for explanation, but
thanks anyway. As an Internet application developer, I of course understand
security issues while using HTTPS and CA.

I have a gut feeling that there simply does not exist any single solution
which is both easy to use and secure enough. At least nobody mentioned it
yet. And if I need to choose between easy solution or secure solution for
aliases, I'll pick that easy one. I mean - we need some solution which will
be easy enough for daily use; it is something what we currently don't have.
But if I want to be really really sure I'm using correct destination for
paying $1mil for a house, I can every time ask for real bitcoin addresses,
this is that secure way which we currently have.

slush

On Mon, Dec 19, 2011 at 2:14 AM, Pieter Wuille <pieter.wuille@gmail.com>wrote:

> On Mon, Dec 19, 2011 at 12:58:37AM +0100, slush wrote:
> > Maybe I'm retarded, but where's the point in providing alliases
> containing
> > yet another hash in URL?
>
> Any DNS-based alias system is vulnerable to spoofing. If I can make
> people's
> DNS server believe that mining.cz points to my IP, I'll receive payments
> to
> you...
>
> If no trusted CA is used to authenticate the communication, there is no way
> to be sure the one you are asking how to pay, is the person you want to
> pay.
> Therefore, one solution is to put a bitcoin address in the identification
> string itself, and requiring SSL communication authenticated using the
> respective key.
>
> This makes the identification strings obviously less useful as aliases,
> but pure aliases in the sense of human-typable strings have imho
> limited usefulness anyway - in most cases these identification strings
> will be communicated through other electronic means anyway.
>
> Furthermore, the embedded bitcoin address could be hidden from the user:
> retrieved when first connecting, and stored together with the URI in
> an address book. Like ssh, it could warn the user if the key changes
> (which wil be ignored by most users anyway, but what do you do about
> that?)
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> 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
>

[-- Attachment #2: Type: text/html, Size: 3552 bytes --]

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

[Luke-Jr]

On Sunday, December 18, 2011 8:14:20 PM Pieter Wuille wrote:
> Furthermore, the embedded bitcoin address could be hidden from the user:
> retrieved when first connecting, and stored together with the URI in
> an address book. Like ssh, it could warn the user if the key changes
> (which wil be ignored by most users anyway, but what do you do about
> that?)

Like SSH, don't make it easy to ignore.
eg, to ignore it, you need to manually go in and remove it from the URI.

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

[Pieter Wuille]

On Mon, Dec 19, 2011 at 12:58:37AM +0100, slush wrote:
> Maybe I'm retarded, but where's the point in providing alliases containing
> yet another hash in URL?

Any DNS-based alias system is vulnerable to spoofing. If I can make people's
DNS server believe that mining.cz points to my IP, I'll receive payments to
you...

If no trusted CA is used to authenticate the communication, there is no way
to be sure the one you are asking how to pay, is the person you want to pay.
Therefore, one solution is to put a bitcoin address in the identification
string itself, and requiring SSL communication authenticated using the
respective key.

This makes the identification strings obviously less useful as aliases,
but pure aliases in the sense of human-typable strings have imho
limited usefulness anyway - in most cases these identification strings
will be communicated through other electronic means anyway.

Furthermore, the embedded bitcoin address could be hidden from the user:
retrieved when first connecting, and stored together with the URI in
an address book. Like ssh, it could warn the user if the key changes
(which wil be ignored by most users anyway, but what do you do about
that?)

-- 
Pieter

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

[Luke-Jr]

On Sunday, December 18, 2011 6:58:37 PM slush wrote:
> Maybe I'm retarded, but where's the point in providing alliases containing
> yet another hash in URL?

The point of the extended URI is to allow the server to negotiate payment 
details (payment/order information, fees, new privacy address, etc) rather 
than merely sending a simple payment to a single fixed address.

I am not convinced *aliases* are practical, without CA trust. An organization 
that wants to trust a CA with all their funds can leave off the address 
portion, to provide more human-friendly URIs.

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

[slush]

[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]

Maybe I'm retarded, but where's the point in providing alliases containing
yet another hash in URL?

slush

On Sun, Dec 18, 2011 at 10:44 PM, Luke-Jr <luke@dashjr.org> wrote:

> On Sunday, December 18, 2011 4:05:11 PM Jorge Timón wrote:
> > If we chose the simple URI proposal namecoin can still be integrated
> > to map the IP of the server by those who want to.
> > Does it removes the necessity of the certificates?
> > If so, we should let people decide between HTTP, HTTPS, namecoin or
> > whatever they trust.
>
> How are you going to authenticate the host? Certificates from CAs are how
> HTTPS does it. HTTP is vulnerable. If the URI contains an address (eg,
> bitcoin://remotehost/base58key), the remote host could sign its
> (self-signed)
> SSL key with the ECDSA key to prove authenticity. DNSSEC/namecoin
> presumably
> has some way to do this as well.
>
> > Shouldn't we be also discussing the valid format of the answered
> > message? I mean fields like "amount", "concept" and such.
>
> At some point, a proper protocol to negotiate payment is needed for
> anything
> like this.
>
>
> ------------------------------------------------------------------------------
> 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
>

[-- Attachment #2: Type: text/html, Size: 2407 bytes --]

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

[Luke-Jr]

On Sunday, December 18, 2011 4:05:11 PM Jorge Timón wrote:
> If we chose the simple URI proposal namecoin can still be integrated
> to map the IP of the server by those who want to.
> Does it removes the necessity of the certificates?
> If so, we should let people decide between HTTP, HTTPS, namecoin or
> whatever they trust.

How are you going to authenticate the host? Certificates from CAs are how 
HTTPS does it. HTTP is vulnerable. If the URI contains an address (eg, 
bitcoin://remotehost/base58key), the remote host could sign its (self-signed) 
SSL key with the ECDSA key to prove authenticity. DNSSEC/namecoin presumably 
has some way to do this as well.

> Shouldn't we be also discussing the valid format of the answered
> message? I mean fields like "amount", "concept" and such.

At some point, a proper protocol to negotiate payment is needed for anything 
like this.

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

[Jordan Mack]

I can't speak for Namecoin. As for the HTTPS requirement, I'm on the 
fence. Without it, the resolution is open to a man in the middle attack. 
Perhaps HTTPS should be required, and if HTTP is used, a large warning 
message is displayed.

As for the answered message format, is JSON the assumed structure that 
would be used?


On 12/18/2011 1:05 PM, Jorge Timón wrote:
> If we chose the simple URI proposal namecoin can still be integrated
> to map the IP of the server by those who want to.
> Does it removes the necessity of the certificates?
> If so, we should let people decide between HTTP, HTTPS, namecoin or
> whatever they trust.
>
> Shouldn't we be also discussing the valid format of the answered
> message? I mean fields like "amount", "concept" and such.
>

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

[Jorge Timón]

If we chose the simple URI proposal namecoin can still be integrated
to map the IP of the server by those who want to.
Does it removes the necessity of the certificates?
If so, we should let people decide between HTTP, HTTPS, namecoin or
whatever they trust.

Shouldn't we be also discussing the valid format of the answered
message? I mean fields like "amount", "concept" and such.

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

[Rick Wesson]

On Fri, Dec 16, 2011 at 1:52 PM, Khalahan <khal@dot-bit.org> wrote:
> The number of proposals is not infinite, here are their problems :
>
> - FirstBits : centralized
> - DNS TXT Records : DNSSEC is required to have a minimum of security, limits
> usage to engineers, limits usage to some domain names (i won't be able to
> use a gmail address for example, because i don't control the gmail.com
> domain)

The same goes for http(s) one would not be able to use
http://google.com/user unless google offers the services.

ALSO look at DANE for getting around the certificate requirement for https

> - Server Service (DNS + a daemon) : Same as DNS TXT records

DNS TXT are not the only way forward, also registry/registrars can facilitate.

> - HTTPS Web service : relies on HTTPS and CA, bitcoin needs to be able to
> check the full certificate chain and access a list of up-to-date certificate
> authorities (installed on the OS or provided with bitcoin). And don't forget
> the CA model is not 100% reliable (several CA hacked this year + possible
> government control...).

This most likely relies on a paid, valid certificate (that expires),
no self signed certs. I admit that running a secured https server with
a valid CA signed  cet is as simple/hard as running a DNSSEC authority
zone.

using a x.509 certificate to secure a bitcoin transaction removes some
of the anonymity of the transaction by allowing the lookup to identify
the certification, ca, crl etc thus connecting a transaction/bitcoin
address to the cert and to its issuing authority. No matter the
frequency of the destination bitcoin address changing.

IMNSHO, leveraging CAs to secure http to provide a lookup translation
to a bitcoin address will only erode anonymity. While DNS is connected
to whois there are provision for hiding behind a proxy where to the
best of my knowledge there are no such provisions offered by CA's
issuing x.509 certificates.

Should self signed cers be "allowed" or encouraged only decreases
security. Clearly DANE would be the only way to mitigate this
situation but then you are back to relying on DNSSEC to bind the x.509
cert.

wash, rinse,  ...

-rick

> - IP Transactions : This proposal seeks to enable DNS lookups for IP
> transactions => same as above
>
> I know that providing a namecoin daemon with bitcoin is not the lighter
> solution, but, if a better one existed i guess it would have already been
> integrated into bitcoin... (see in what state is my first attempt with the
> HTTPS proposal : Send payments to emails, urls and domains in GUI - khalahan
> opened this pull request April 20, 2011)
>
> So, what's next ?
>
> Le 16/12/2011 20:54, slush a écrit :
>
> Khalahan, honestly, using namecoin for aliases is (for me) clean example of
> over-engineering. I mean - it will definitely work if implemented properly.
> I played with a namecoin a bit (as my pool was the first 'big' pool
> supporting merged mining), but I think there's really long way to provide
> such alias system in namecoin and *cleanly integrate it with bitcoin*. Don't
> forget that people who want to do lookup need to maintain also namecoin
> blockchain with their bitcoin client. It goes against my instinct of keeping
> stuff easy.
>
> For example, yesterday I implemented HTTPS lookup for addresses into my fork
> of Electrum client. I did it in 15 minutes, it works as expected, it does
> the job and the implementation is really transparent, becuase implementation
> is 20 lines of code. There's no magic transformation, no forced "?handle="
> parameters or whatever. And I don't care if somebody provide URL
> https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True
>
> And everybody can do the same in their clients, in their merchant solutions,
> websites or whatever. Everybody can do HTTPS lookup. But try to explain DNS,
> Namecoin, IIBAN, email aliases to other programmers...
>
> Those IIBAN - well, why not. At least I see the potential in PR. So far I
> understand it as some teoretic concept which is not supported by anything
> else right now. Give it few years until it matures and then add IIBAN alias
> to Bitcoin client too.
>
> Maybe I'm repeating myself already, but the way to go is to make aliases as
> easy as possible, so everybody can implement it in their own solution and
> thus practially remove the need of using standard bitcoin addresses for
> normal users. Using some superior technology, which is hard to implement or
> even understand won't solve the situation, because it will ends up with some
> reference implementation in standard client only and nobody else will use
> it.
>
> slush
>
>
> --
> Best Regards,
> Khalahan
> http://dot-bit.org/
>
>
> ------------------------------------------------------------------------------
> 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] [BIP 15] Aliases

[Khalahan]

[-- Attachment #1: Type: text/plain, Size: 3459 bytes --]

The number of proposals <https://en.bitcoin.it/wiki/BIP_0015> is not
infinite, here are their problems :

- FirstBits : centralized
- DNS TXT Records : DNSSEC is required to have a minimum of security,
limits usage to engineers, limits usage to some domain names (i won't be
able to use a gmail address for example, because i don't control the
gmail.com domain)
- Server Service (DNS + a daemon) : Same as DNS TXT records
- HTTPS Web service : relies on HTTPS and CA, bitcoin needs to be able
to check the full certificate chain and access a list of up-to-date
certificate authorities (installed on the OS or provided with bitcoin).
And don't forget the CA model is not 100% reliable (several CA hacked
this year + possible government control...).
- IP Transactions : /This proposal seeks to enable DNS lookups for IP
transactions/ => same as above

I know that providing a namecoin daemon with bitcoin is not the lighter
solution, but, if a better one existed i guess it would have already
been integrated into bitcoin... (see in what state is my first attempt
with the HTTPS proposal : Send payments to emails, urls and domains in
GUI <https://github.com/bitcoin/bitcoin/pull/174> - /khalahan opened
this pull request April 20, 2011/)

So, what's next ?

Le 16/12/2011 20:54, slush a écrit :
> Khalahan, honestly, using namecoin for aliases is (for me) clean
> example of over-engineering. I mean - it will definitely work if
> implemented properly. I played with a namecoin a bit (as my pool was
> the first 'big' pool supporting merged mining), but I think there's
> really long way to provide such alias system in namecoin and *cleanly
> integrate it with bitcoin*. Don't forget that people who want to do
> lookup need to maintain also namecoin blockchain with their bitcoin
> client. It goes against my instinct of keeping stuff easy.
>
> For example, yesterday I implemented HTTPS lookup for addresses into
> my fork of Electrum client. I did it in 15 minutes, it works as
> expected, it does the job and the implementation is really
> transparent, becuase implementation is 20 lines of code. There's no
> magic transformation, no forced "?handle=" parameters or whatever. And
> I don't care if somebody provide URL
> https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True
> <https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True>
>
> And everybody can do the same in their clients, in their merchant
> solutions, websites or whatever. Everybody can do HTTPS lookup. But
> try to explain DNS, Namecoin, IIBAN, email aliases to other programmers...
>
> Those IIBAN - well, why not. At least I see the potential in PR. So
> far I understand it as some teoretic concept which is not supported by
> anything else right now. Give it few years until it matures and then
> add IIBAN alias to Bitcoin client too.
>
> Maybe I'm repeating myself already, but the way to go is to make
> aliases as easy as possible, so everybody can implement it in their
> own solution and thus practially remove the need of using standard
> bitcoin addresses for normal users. Using some superior technology,
> which is hard to implement or even understand won't solve the
> situation, because it will ends up with some reference implementation
> in standard client only and nobody else will use it.
>
> slush

-- 
Best Regards,
Khalahan
http://dot-bit.org/


[-- Attachment #2: Type: text/html, Size: 4666 bytes --]

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

[Harald Schilly]

On Fri, Dec 16, 2011 at 21:10, Amir Taaki <zgenjix@yahoo.com> wrote:
> Especially when we already have bitcoin addresses with their own checksums-
> what value do IBANs add?

Well, I'm not an expert like you, but one benefit would be to be
compatible with existing software solutions that are based on using
IBANs.

H

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

[Amir Taaki]

[-- Attachment #1: Type: text/plain, Size: 4234 bytes --]

I think IBANs are not such a good idea. Note that as someone who has spent the last year of my life dealing with hundreds of bank transactions a day and interacting with the banking system (both on a technical, systematic and personnel level), the entire system is a gigantic mess.

The banks are in fact looking to us for answers. That's why we (Bitcoin Consultancy) were invited to the SWIFT conference to join their panel on bank 2.0.

I don't even mind the maxim "take everything the banks have done and do the complete opposite" :)

I invite anyone who is skeptical to read the ECB's specification on SEPA payments. It really is an example of a system made to work alongside legacy systems that rely on inefficient people. The interchange fees are dependent on a totally arbitrary test of merchant indifference and various antitrust regulations.

These systems are usually built not by engineers or hackers, but by finance people. IBAN has no place in bitcoin IMO.

I don't mean to sound too critical, but I'm skeptical of its usefulness. Especially when we already have bitcoin addresses with their own checksums- what value do IBANs add? Nothing except negatives.



________________________________
 From: slush <slush@centrum.cz>
To: Khalahan <khal@dot-bit.org> 
Cc: bitcoin-development@lists.sourceforge.net 
Sent: Friday, December 16, 2011 7:54 PM
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
 

Khalahan, honestly, using namecoin for aliases is (for me) clean example of over-engineering. I mean - it will definitely work if implemented properly. I played with a namecoin a bit (as my pool was the first 'big' pool supporting merged mining), but I think there's really long way to provide such alias system in namecoin and *cleanly integrate it with bitcoin*. Don't forget that people who want to do lookup need to maintain also namecoin blockchain with their bitcoin client. It goes against my instinct of keeping stuff easy.

For example, yesterday I implemented HTTPS lookup for addresses into my fork of Electrum client. I did it in 15 minutes, it works as expected, it does the job and the implementation is really transparent, becuase implementation is 20 lines of code. There's no magic transformation, no forced "?handle=" parameters or whatever. And I don't care if somebody provide URL https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True

And everybody can do the same in their clients, in their merchant solutions, websites or whatever. Everybody can do HTTPS lookup. But try to explain DNS, Namecoin, IIBAN, email aliases to other programmers...


Those IIBAN - well, why not. At least I see the potential in PR. So far I understand it as some teoretic concept which is not supported by anything else right now. Give it few years until it matures and then add IIBAN alias to Bitcoin client too.

Maybe I'm repeating myself already, but the way to go is to make aliases as easy as possible, so everybody can implement it in their own solution and thus practially remove the need of using standard bitcoin addresses for normal users. Using some superior technology, which is hard to implement or even understand won't solve the situation, because it will ends up with some reference implementation in standard client only and nobody else will use it.

slush


On Fri, Dec 16, 2011 at 6:23 PM, Khalahan <khal@dot-bit.org> 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.
>
>
------------------------------------------------------------------------------
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

[-- Attachment #2: Type: text/html, Size: 6266 bytes --]

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

[slush]

[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]

Khalahan, honestly, using namecoin for aliases is (for me) clean example of
over-engineering. I mean - it will definitely work if implemented properly.
I played with a namecoin a bit (as my pool was the first 'big' pool
supporting merged mining), but I think there's really long way to provide
such alias system in namecoin and *cleanly integrate it with bitcoin*.
Don't forget that people who want to do lookup need to maintain also
namecoin blockchain with their bitcoin client. It goes against my instinct
of keeping stuff easy.

For example, yesterday I implemented HTTPS lookup for addresses into my
fork of Electrum client. I did it in 15 minutes, it works as expected, it
does the job and the implementation is really transparent, becuase
implementation is 20 lines of code. There's no magic transformation, no
forced "?handle=" parameters or whatever. And I don't care if somebody
provide URL
https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True

And everybody can do the same in their clients, in their merchant
solutions, websites or whatever. Everybody can do HTTPS lookup. But try to
explain DNS, Namecoin, IIBAN, email aliases to other programmers...

Those IIBAN - well, why not. At least I see the potential in PR. So far I
understand it as some teoretic concept which is not supported by anything
else right now. Give it few years until it matures and then add IIBAN alias
to Bitcoin client too.

Maybe I'm repeating myself already, but the way to go is to make aliases as
easy as possible, so everybody can implement it in their own solution and
thus practially remove the need of using standard bitcoin addresses for
normal users. Using some superior technology, which is hard to implement or
even understand won't solve the situation, because it will ends up with
some reference implementation in standard client only and nobody else will
use it.

slush

On Fri, Dec 16, 2011 at 6:23 PM, Khalahan <khal@dot-bit.org> 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.
>
>

[-- Attachment #2: Type: text/html, Size: 2820 bytes --]

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

[Khalahan]

[-- Attachment #1: Type: text/plain, Size: 7601 bytes --]

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 perfect starting point to map names to
other things (a public bitcoin address, an url, etc)
You won't have all the advantages of namecoin when using other systems
like DNS and HTTP(S) as the first entry point.

What is namecoin ?

* proven technology :
- do not mix the namecoin technology and the dot-bit namespace with .bit
domains (dot-bit domains needs dot-bit compatible dns servers or proxies
+ namecoin and have a small visibility due to the nature of
top-to-bottom domain name system controlled by ICANN, namecoin needs
only namecoin to store data !)
- as proven and secure as bitcoin
- merged mining provides a secure network

* decentralized :
- a lot of nodes, and you can have your own node
- everybody can register his own name, by itself with the namecoin
software (bitcoin could even allow registration directly from it,
easily) or by using a name provider
- everybody can become a name provider (register for your friends and
resell names).

* no single point of failure :
- DNS and HTTPS have several limitations (Man in the Middle attacks, no
reliable authority of certifications, domain seizure, ...)

* designed for that :
- namecoin uses a system of namespaces to separate each usages :
http://dot-bit.org/Main_Page#Namespaces.
For example, the "personal namespace" draft
(http://dot-bit.org/Personal_Namespace) could be extended to support
mapping to a bitcoin address, or a dedicated namespace can be used if
prefered (the "bitcoin/" or "alias/" or "map/" prefixes for example).

* easily connectable to bitcoin
- they both use RPC and json to exchange informations, so connecting one
to the other is really easy
- bitcoin could even allow registration of names by sending an RPC
request to namecoin

* extensible and not limited :
- you are not forced to store a bitcoin address directly in namecoin,
you can also store an url or a domain name
- allows additional security : add a certificate fingerprint combined
with an https url (so, using DNS or HTTP(S) is not a major problem
anymore if the first point of entry is really secure and configurable
[and you use and self-signed certificate])
- really easy to update
- simple for simple cases
- possibility to use a nick, an email address or a domain as name
- other methods to get bitcoins addresses can be added later, protocol
is extensible


Examples of possible registered names in namecoin with the "personal
namespace" (with the "p/" prefix) :

* An individual person with well known public addresses :
"p/*khal*":
{
    "email": "khal@dot-bit.org",
    "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}

* Another individual person with well known public addresses :
"p/*khal@dot-bit.org*":
{
    "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}

* A merchant accepting payments in bitcoin, namecoin, paypal or
othercoin (to show you how the whole namespace could be used) :
"p/*mymerchant.com*":
{
    "bitcoin": {
        "url": "https://payto.mymerchant.com/bitcoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"
        "cert": "https://payto.mymerchant.com/certificate.pem",
    },
    "namecoin": {
        "url": "https://payto.mymerchant.com/namecoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"
    },
    "paypal": "xxxxxx@yyyyyyyyy.zzz",
    "othercoin": "oxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

* A merchant with a public address, an url to generate custom addresses
and a domain name (not sure if this case is really usefull, maybe as
fallback)
"p/*mymerchant2*":
{
    "bitcoin": {
        "url": "https://payto.mymerchant.com/bitcoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926",
        "dns": "_bitcoin.payto.mymerchant.com",
        "address": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    }
}


* How to use it in bitcoin ?

Several possibilities of address syntax :
- khal, khal@dot-bit.org, mymerchant.com, mymerchant2 : no syntax limit
- mymerchant2@bitcoin : will conflict with names already containing a @
- mymerchant2@namecoin : same
- namecoin:mymerchant2 : strange syntax, confusing with the "uri scheme"
- namecoin://mymerchant2 : same
- other ?


Here is how things would be processed when people put an address to pay
to in the bitcoin client :

* address : khal
-> RPC to namecoin for "p/khal"
-> json processing for "p/khal->bitcoin"
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T

* address : khal@dot-bit.org
-> RPC to namecoin for "p/khal@dot-bit.org"
-> json processing for "p/khal@dot-bit.org->bitcoin"
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T

* address : mymerchant.com
-> RPC to namecoin for "p/mymerchant.com"
-> json processing for "p/mymerchant.com->bitcoin"
-> json processing for "p/mymerchant.com->bitcoin->url" and
"p/mymerchant.com->bitcoin->fpr"
-> https request to "https://payto.mymerchant.com/bitcoin/"
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy

* address : mymerchant2
-> RPC to namecoin for "p/mymerchant2"
-> json processing for "p/mymerchant2->bitcoin"
-> json processing for "p/mymerchant2->bitcoin->url" and
"p/mymerchant2->bitcoin->fpr"
-> https request to "https://payto.mymerchant.com/bitcoin/"
-> result : error (website unavailable, page not found, timeout, etc)
-> json processing for "p/mymerchant2->bitcoin->dns"
-> dns request for "_bitcoin.payto.mymerchant.com"
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy


Le 15/12/2011 20:59, theymos a écrit :
> Bitcoin already has code and a protocol for transactions to IP
> addresses. Why not reuse that for dynamic address lookup? Just a few
> changes are necessary to enable complete user@server.com handling:
> - Extend the protocol so that "reply" messages can be signed by a fixed
>   public key
> - Extend "checkorder" messages so they can specify an account to
>   send BTC to. Or standardize on how to put the account into the
>   message field.
> - Enable DNS lookups for IP transactions. The DNS-only proposals could
>   also be used here to avoid having to use the IP transaction protocol
>   sometimes. The public key for signing "reply" messages can be gotten
>   from TXT records. This will be safe with DNSSEC and Namecoin. With
>   plain DNS Bitcoin could take a SSH-like approach and ask the user to
>   verify the public key the first time it is used, remembering it later.
>
> DoS attacks are already handled by the IP transactions code: the same IP
> address is always given the same bitcoin address until it pays to that
> bitcoin address.
>
> ------------------------------------------------------------------------------
> 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
>


-- 
Best Regards,
Khalahan
http://dot-bit.org/


[-- Attachment #2: Type: text/html, Size: 11135 bytes --]

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

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 1567 bytes --]

On 2011 December 16 Friday, Rick Wesson wrote:

> I believe that any URI scheme will still leverage DNS and inherit any
> base issues you would have with TXT records. I suggest looking at DANE

HTTPS takes care of that.

> and reviewing their work on hardening certificate (x.509)
> infrastructure as your HTTPS scheme will inherit the issues we
> currently experience with CAs getting p0wned.

This is the only real problem with HTTPS: we would be centralising part of our 
otherwise decentralised system.  CAs are certainly a risk.

However, trust is needed somewhere in the communication.  There is no way to 
securely communicate between A and B without the use of some previously 
trusted secure channel -- in Joe Sixpack's case it's by assuming that the 
browser he downloaded came with an untainted CA list, and that the CAs are 
trustworthy.  Neither of which is guaranteed.  Until and unless we get PGP 
support in browsers, CAs are all that we have.

Worrying about CAs misses the point anyway; if we're being that paranoid -- 
how did A tell B the appropriate alias to use for a lookup?  Was that channel 
secure too?  I could set up a MITM server that simply looks for the alias 
"RICKWESSON@bitcoinaliases.org" and rewrites it to 
"ANDYPARKINS@bitcoinaliases.org".  When the answer to that problem is HTTPS 
(or some other system that requires a previously authorised secure channel for 
transfer of trust), then we're back where we started, and HTTPS is acceptable.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Rick Wesson]

On Fri, Dec 16, 2011 at 8:17 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> On Fri, Dec 16, 2011 at 08:03:28AM -0800, Rick Wesson wrote:
>> Hardening the protocols and usability are related. Please look at some
>> of the work done in the IETF which has a long history in addressing
>> many of the issues you are considering. Review some of the elegance in
>> the bitcoin protocols. The proposals in this thread are neither clear
>> nor elegant. If you can't reach nearly the same level of
>> sophistication then I suggest you rethink your scheme.
>
> That's why you use URI + bitcoin address pairs, and use SSL communication
> authenticated using the respective bitcoin pubkey. They may spoof your DNS
> server, they can't fake having the requested corresponding private key.

You are making my point (again) regarding usability and security.
Aliases are not a https secured URI+bitcoin address.

-rick

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

[Pieter Wuille]

On Fri, Dec 16, 2011 at 08:03:28AM -0800, Rick Wesson wrote:
> Hardening the protocols and usability are related. Please look at some
> of the work done in the IETF which has a long history in addressing
> many of the issues you are considering. Review some of the elegance in
> the bitcoin protocols. The proposals in this thread are neither clear
> nor elegant. If you can't reach nearly the same level of
> sophistication then I suggest you rethink your scheme.

That's why you use URI + bitcoin address pairs, and use SSL communication
authenticated using the respective bitcoin pubkey. They may spoof your DNS
server, they can't fake having the requested corresponding private key.

Obviously, this moves the problem to getting the URL + address securely
to the client that wants to interact with it, but that is inevitable if
you're not going to rely on a pre-trusted certificate authority and PKI.

Also, the client software can cache the address corresponding to a particular
server or URL, making it similar to an ssh client that caches host keys and
warns when they change.

-- 
Pieter

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

[Rick Wesson]

On Fri, Dec 16, 2011 at 12:35 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> On Mon, Dec 12, 2011 at 02:21:09PM -0800, Amir Taaki wrote:
>> I wrote this pre-draft:

[snip]

>
> To conclude: my suggestion would be to use URLs as address identifiers,
> optionally suffixed with a bitcoin address for authentication.
> This means my "address" would be either "sipa.be/pw.btc" or
> "sipa.be/pw.btc$14TYdpodQQDKVgvUUcpaMzjJwhQ4KYsipa" (where "https://")
> is an implicit default. Initiating a payment to either of these would
> result in a GET of https://sipa.be/pw.btc. When a transaction is
> constructed, it is POSTed back to that URL.
>
> If we can agree on reasonable hardcoded mapping, pw@sipa.be could just
> be a shorthand for either of these (though vulnerable to proofing...).

I believe that any URI scheme will still leverage DNS and inherit any
base issues you would have with TXT records. I suggest looking at DANE
and reviewing their work on hardening certificate (x.509)
infrastructure as your HTTPS scheme will inherit the issues we
currently experience with CAs getting p0wned.

Hardening the protocols and usability are related. Please look at some
of the work done in the IETF which has a long history in addressing
many of the issues you are considering. Review some of the elegance in
the bitcoin protocols. The proposals in this thread are neither clear
nor elegant. If you can't reach nearly the same level of
sophistication then I suggest you rethink your scheme.

-rick

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

[Pieter Wuille]

On Mon, Dec 12, 2011 at 02:21:09PM -0800, Amir Taaki wrote:
> I wrote this pre-draft:
> 
> 
> https://en.bitcoin.it/wiki/BIP_0015
> 
> It's merely a starter for discussions.

Interesting discussion so far, with many nice ideas.

I'll try to give my opinion and comment on some in batch here.

First of all, I'm a big proponent of moving away from using base58 strings
as addresses. They are not flexible and not human-friendly. I did an own
proposal to improve the situation some time ago, see

  https://gist.github.com/1237788

There was little reaction, and maybe the reason is we shouldn't try to solve/fix
everything at once.

a) IP transactions-like system with DNS resolution

Not only does this give you nice identifiers, but it also moves the
responsibility of getting the transaction accepted by the network from the
sender to the receiver - the one who actually cares about getting his
money.

The authentication problem that was present in the original IP transactions
system can either be mitigated by trusting the existing SSL public-key
intrastructure (which not everyone may like) or (as Satoshi suggested) adding
bitcoin address-based authentication on top (separate from the address used in
the transaction itself). So you get an identifier like <url>$<btcaddress>, and
the communication to <url> would be authenticated using <btcaddress>. This
is obviously not useful as human-typable alias, but is no problem for
clickable URLs on websites that want to provide the additional security.

I'm not sure about using the bitcoin p2p protocol here - i think there are
easier (or at least more widely deployed) protocols like HTTP. So maybe ...

b) HTTPS Web Service

we can just use an HTTPS web service, that provides the bitcoin address to
be used in the transaction to a client that queries a URL. This immediately
makes the identifier double as a clickable URL, and a merchant could add
metadata to the URL to make the transaction easily trackable.

As for the possibility for spoofing: relying on DNSSEC is currently
difficult i believe (though i'm not entirely up-to-date about its
deployment). Again, alternatives are the SSL PKI, or bitcoin address-based
authentication (basically doing SSL but using bitcoin pubkeys to
authenticate)

c) user@hostname-like identifiers

These look very good, and conveniently match the e-mail system's identifiers.
However, I believe they are only useful for one purpose: user-to-user
payments. For anything somewhat more business-y you probably want to use
a clickable URL, and hide all address information entirely from the user.
Still, for user-to-user payments they are nice.

I'm not convinced about the hardcoding of the "https://" and
"/bitcoin-alias/?handle=" parts, though. These seem very arbitrarily
chosen to me, but if you consider an HTTPS-based variant of a bitcoin
ip-transactions-like system, the proposed "account" parameter to
checkorder would probably become a CGI parameter anyway...

d) DNS TXT lookups

I'm not entirely against this, but only allowing a fixed bitcoin address
to be returned would far too strongly encourage the use of fixed
addresses in transactions. If anything, it should be an identifier
for one of the other proposals (which do allow interaction, or at least
creation of a fresh bitcoin address) that is returned. 



To conclude: my suggestion would be to use URLs as address identifiers,
optionally suffixed with a bitcoin address for authentication.
This means my "address" would be either "sipa.be/pw.btc" or
"sipa.be/pw.btc$14TYdpodQQDKVgvUUcpaMzjJwhQ4KYsipa" (where "https://")
is an implicit default. Initiating a payment to either of these would
result in a GET of https://sipa.be/pw.btc. When a transaction is
constructed, it is POSTed back to that URL.

If we can agree on reasonable hardcoded mapping, pw@sipa.be could just
be a shorthand for either of these (though vulnerable to proofing...).

-- 
Pieter

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

[Walter Stanish]

> Bitcoin itself is decentralised by design, in my opinion it seems obvious
> that it needs to continue to maintain this feature.

What's the real issue?

 - People want to use alternate representations ('aliases') of bitcoin
addresses, for various reasons.
 - The blockchain is the only way to create distributed consensus
within the bitcoin network.
 - Very few people - even those who wish to have a permanent alias -
want to have it map to a permanent bitcoin address, since this
discloses their financial history (eg: income for a business) to the
public
 - Some people want throw-away (single use) aliases, others want
permanent ones.  This means many addresses.
 - Blockchain bloat is already acknowledged as an issue.
 - The blockchain is not really a good option.

Leaving out the blockchain, there are still ways to implement aliasing.

What is the core problem for an extra-blockchain aliasing system?

At the core is usability - people basically want aliases to make it
easier to type in or remember addresses.  So a solution that
sacrifices usability too far is a broken one.

Another requirement is absolute security.  A user of the aliasing
system is going to trust it to translate a particular alias to a
bitcoin address - ie: 'where my money goes with absolutely zero chance
(by default)  of getting it back if it's sent somewhere wrong by
accident'.  Such an accident might be mistyping an alias.  It might
also be a hijacking of the alias resolution system (eg: a DNS based
system without DNSSEC, etc.).  As a case in point, we already see very
well organized attacks by domain squatters in order to steal traffic
or effect phishing under the DNS system.

So... to help see which qualities are meaningful for such an alias
system, let's look at what types of solutions to these problems exist
within conventional (ie: mature) financial systems.

First, arbitrary aliases are not in use.  This means that memory-based
mnemonics are not subject to predictable squatting-style attacks.  For
our purposes, this means that if you are payments@business1.com, I
can't go and register payments@busines1.com and take a portion of your
inbound cash whenever a client tries to pay you and typos on the send
address.  Likewise, if you're 'someuser@hostedwalletservice.com' I
can't go and register as 'someuse@hostedwalletservice.com' and pull
the same heist. IIBAN is the only aliasing proposal I have seen
mentioned within this thread that adopts this strategy, the others all
maintain this vulnerability through DNS. HTTP relies on DNS.

Second, checksum systems detect transposition errors. This is a very
powerful feature, which (I can't be bothered googling for stats, but
just think about it) cuts out the vast majority of such errors
instantly, at the time of input, before money changes hands or
anything touches the financial settlement networks.  IIBAN adopts
exactly the same mature and proven MOD97-based two digit checksum
feature that is used within the IBAN standard, proposed by the
European Union with the benefit of decades of banking experience in
many member states and now growing rapidly in use around the world.
(For something as expensive and painful to implement as a
nationally-mandated banking standard affecting all member banks, a
growth rate of 'a few countries per year' is a pretty serious growth
curve!)  With checksums, it's even possible to auto-suggest
corrections based upon common transposition errors and help the user
to check those parts of the alias for common errors more quickly.

Third, conventional financial systems typically require recipient name
(and sometimes address, or business tax numbers in some countries'
domestic schemes) as part of the transaction.  This secondary data
facilitates error checking since an incorrectly supplied destination
address can be checked against these properties.  Of course, Bitcoin
presently has no such secondary input with which to verify the
destination of a transfer, and since blockchain bloat is an
acknowledged issue and very few bitcoin users would like to see their
names appear against their transactions within the blockchain (visible
to all, for eternity!) it also seems that this feature is not going to
be added and for good reason.  However, within an external (and not
necessarily bitcoin specific) higher-level 'transaction negotation'
protocol (alluded to in earlier posts as a logical extension of the
pre transaction alias resolution mechanism, and being a pre
transaction connection of some nature between a payer and payee, or
their proxying/representing institution, in the case of hosted
wallets/aliases), such external destination validation features could
be added. (Many types are possible... data-based as per name/address
validation, cryptographic validation schemes, etc.)

Finally, an increasing number of countries use an aliasing scheme
(IBAN) that is familiar to users.  Doing so for digital currencies
such as Bitcoin increases usability (by eliminating novelty, and in
the case of IIBAN which is not specific to any given currency, the
need to register, recall and manage yet another account identifier),
which was one of the original goals. None of the other proposals
mentioned have this property.

I won't go in to other benefits previously mentioned of the IIBAN
proposal, but I still cannot see any reason to either:
 - Include aliasing within bitcoind itself
 - Re-invent the wheel
 - Scare off non-technical users
 - Dodge the fact that there are unique properties of bitcoin that
will always remain and should perhaps simply be acknowledged and
worked around OUTSIDE of the codebase, rather than within.
Unix/internet philosophy is that it's usually best to keep code as
simple as possible, to 'do one thing' and 'do it well'. For bitcoind
(despite sharing a codebase with the GUI), that something is achieving
a distributed internet-based financial system that is free from legacy
centralized currencies. It is *not* worrying about making it look
pretty or easy to use, which can be achieved by layering totally
external systems through simply translating various alternate
representations ('aliases') to the well defined bitcoin addressing
scheme.

Just to avoid any notion of table-banging (Hah! A lost cause?), this
will be the last IIBAN-related post I will make on this thread, but
there will be some further announcements in the near future.

Keep up the good work everyone.

Regards,
Walter Stanish
Payward Inc.

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

[Matt Corallo]

On Thu, 2011-12-15 at 13:59 -0600, theymos wrote:
> Bitcoin already has code and a protocol for transactions to IP
> addresses. Why not reuse that for dynamic address lookup? Just a few
> changes are necessary to enable complete user@server.com handling:
I'm not against this, but I think its way overcomplicated when compared
to the DNS or HTTPS methods.
> - Extend the protocol so that "reply" messages can be signed by a fixed
>   public key
> - Extend "checkorder" messages so they can specify an account to
>   send BTC to. Or standardize on how to put the account into the
>   message field.
OK, not too debatable, but considering how terrible bitcoind's account
handling is, the second might not be easy to get right...
> - Enable DNS lookups for IP transactions. The DNS-only proposals could
>   also be used here to avoid having to use the IP transaction protocol
>   sometimes. The public key for signing "reply" messages can be gotten
>   from TXT records. This will be safe with DNSSEC and Namecoin. With
>   plain DNS Bitcoin could take a SSH-like approach and ask the user to
>   verify the public key the first time it is used, remembering it later.
This is where I think this method becomes way overcomplicated.  Not only
do you have to update the IP-Transaction code, but now you have to
implement the full DNS System that is the other option as well.  Note
that to make this secure, we have to have a full DNSSEC-capable resolver
built-into bitcoind (there are libs, but it has to happen).  Yes you can
ask the user "does this fingerprint look right to you? Y/N" but that
always opens you up to a ton of users getting screwed out of coins and I
don't think it should be enabled, except in bitcoind, and since the main
target of this whole alias system is bitcoin-qt users, well...

Matt

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

[Kyle Henderson]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

This is the first proposal I've seen regarding mapping something like
user@host that actually makes sense to me.

Bitcoin itself is decentralised by design, in my opinion it seems obvious
that it needs to continue to maintain this feature.


On Fri, Dec 16, 2011 at 8:59 AM, theymos <theymos@mm.st> wrote:

> Bitcoin already has code and a protocol for transactions to IP
> addresses. Why not reuse that for dynamic address lookup? Just a few
> changes are necessary to enable complete user@server.com handling:
> - Extend the protocol so that "reply" messages can be signed by a fixed
>  public key
> - Extend "checkorder" messages so they can specify an account to
>  send BTC to. Or standardize on how to put the account into the
>  message field.
> - Enable DNS lookups for IP transactions. The DNS-only proposals could
>  also be used here to avoid having to use the IP transaction protocol
>  sometimes. The public key for signing "reply" messages can be gotten
>  from TXT records. This will be safe with DNSSEC and Namecoin. With
>  plain DNS Bitcoin could take a SSH-like approach and ask the user to
>  verify the public key the first time it is used, remembering it later.
>
> DoS attacks are already handled by the IP transactions code: the same IP
> address is always given the same bitcoin address until it pays to that
> bitcoin address.
>
>

[-- Attachment #2: Type: text/html, Size: 1769 bytes --]

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

[Amir Taaki]

[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]

This is maybe the best idea. I added it:
https://en.bitcoin.it/wiki/BIP_0015#IP_Transactions

Things I like about this:
- IP transactions are useful, but have a security flaw. This mitigates their security problems.
- The code for IP transactions is already in Satoshi client. If other clients want to add IP transactions, then it can be done with minimal fuss/bloat.
I feel that for any protocol extension, less is more. The less code 
needed, the better the extension. Not always but generally we want to 
avoid bitcoin protocol bloat which *will* happen far in the future. The 
only way to mitigate how spaghettified the standard will be in the 
future, is by careful cautious planning now.

- We can have a proxy node running 24/7 for us, serving our public keys in lieu of us.



________________________________
 From: theymos <theymos@mm.st>
To: bitcoin-development@lists.sourceforge.net 
Sent: Thursday, December 15, 2011 7:59 PM
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
 
Bitcoin already has code and a protocol for transactions to IP
addresses. Why not reuse that for dynamic address lookup? Just a few
changes are necessary to enable complete user@server.com handling:
- Extend the protocol so that "reply" messages can be signed by a fixed
  public key
- Extend "checkorder" messages so they can specify an account to
  send BTC to. Or standardize on how to put the account into the
  message field.
- Enable DNS lookups for IP transactions. The DNS-only proposals could
  also be used here to avoid having to use the IP transaction protocol
  sometimes. The public key for signing "reply" messages can be gotten
  from TXT records. This will be safe with DNSSEC and Namecoin. With
  plain DNS Bitcoin could take a SSH-like approach and ask the user to
  verify the public key the first time it is used, remembering it later.

DoS attacks are already handled by the IP transactions code: the same IP
address is always given the same bitcoin address until it pays to that
bitcoin address.

------------------------------------------------------------------------------
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

[-- Attachment #2: Type: text/html, Size: 3729 bytes --]

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

[theymos]

Bitcoin already has code and a protocol for transactions to IP
addresses. Why not reuse that for dynamic address lookup? Just a few
changes are necessary to enable complete user@server.com handling:
- Extend the protocol so that "reply" messages can be signed by a fixed
  public key
- Extend "checkorder" messages so they can specify an account to
  send BTC to. Or standardize on how to put the account into the
  message field.
- Enable DNS lookups for IP transactions. The DNS-only proposals could
  also be used here to avoid having to use the IP transaction protocol
  sometimes. The public key for signing "reply" messages can be gotten
  from TXT records. This will be safe with DNSSEC and Namecoin. With
  plain DNS Bitcoin could take a SSH-like approach and ask the user to
  verify the public key the first time it is used, remembering it later.

DoS attacks are already handled by the IP transactions code: the same IP
address is always given the same bitcoin address until it pays to that
bitcoin address.

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

[Jorge Timón]

@Matt
I didn't thought about firstbits scalability, but the "registering
crap" and squatting arguments don't apply to green addresses because
no one wants fancy or easy to memorize names there. Is just a way to
make the bitcoin addresses shorter in the green addresses protocol to
be able to have various of them in the same QR-code.

@Amir
I see, the point is to be able to type the alias directly into the client.

I like the DNS proposal. This would allow for both well known working
centralized technology and namecoin (not proven, but decentralized)
options to be used.


2011/12/13, theymos <theymos@mm.st>:
> I like the user@server.com model. The protocol should be done entirely
> in DNS, though, not using HTTP connections to the server. Then the
> protocol can easily be used with Namecoin or other DNS
> replacements/enhancements later. Crypto to prevent MITM attacks can be
> an optional part of the protocol.
>
> Almost all users will be unable to set up *any* always-on Internet
> service to answer queries, so I'm not too concerned about how easy it is
> to set up the server software.
>
> I agree that FirstBits is bad for this. Unlike DNS, "registrations" last
> forever because private keys can't be transferred safely. All short
> names will be taken quickly. It will also be very expensive for clients
> to query this themselves.
>
> The CA model is broken and it should never be used by Bitcoin.
>
> ------------------------------------------------------------------------------
> 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
>


-- 
Jorge Timón

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

[theymos]

I like the user@server.com model. The protocol should be done entirely
in DNS, though, not using HTTP connections to the server. Then the
protocol can easily be used with Namecoin or other DNS
replacements/enhancements later. Crypto to prevent MITM attacks can be
an optional part of the protocol.

Almost all users will be unable to set up *any* always-on Internet
service to answer queries, so I'm not too concerned about how easy it is
to set up the server software.

I agree that FirstBits is bad for this. Unlike DNS, "registrations" last
forever because private keys can't be transferred safely. All short
names will be taken quickly. It will also be very expensive for clients
to query this themselves.

The CA model is broken and it should never be used by Bitcoin.

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

[Luke-Jr]

FirstBits looks nice at glance, but is bound to create a gold-rush to grab 
every nice-looking FirstBits address.

HTTPS is only as secure as the (centralized) CAs, thus not really any better 
than TXT records.

I don't think an address of some form is avoidable.

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

[Amir Taaki]

OK, my thoughts. My order of preference is: web service, server service, DNS TXT records.

FirstBits + Vanitygen is out of the question in my mind. Not robust enough.

I like web service since anyone can trivially set one up. You can provide a PHP script and a text file (that users edit) that people upload to XFreeWebHost and then they're instantly set to go. Setting up a web host is very easy nowadays- as easy as click click click.

The other ideas are not so easy.

Also HTTPS + CA is the most secure of the bunch.

I'm curious to hear any other ideas too.

Thanks.



----- Original Message -----
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net" <bitcoin-development@lists.sourceforge.net>
Cc: 
Sent: Monday, December 12, 2011 10:21 PM
Subject: [BIP 15] Aliases

I wrote this pre-draft:


https://en.bitcoin.it/wiki/BIP_0015

It's merely a starter for discussions.

Aliases are a way to lookup bitcoin addresses so I can type genjix@genjix.net instead of 1jkddsjdskjwnk2j3kj232kjdkj

[Bitcoin-development] [BIP 15] Aliases

[Amir Taaki]

I wrote this pre-draft:


https://en.bitcoin.it/wiki/BIP_0015

It's merely a starter for discussions.

Aliases are a way to lookup bitcoin addresses so I can type genjix@genjix.net instead of 1jkddsjdskjwnk2j3kj232kjdkj