There needs to be a new bitcoin address format...

[casascius]

There needs to be a new bitcoin address format with the capability of self-confirming that somebody is paying a known party.  In other words, there needs to be infrastructure in place where someone can paste an address into their Bitcoin client and see a confirmation: "Confirmed, you are paying Rocky Mountain Power Company", a confirmation based on cryptography and public key infrastructure.

Why?  Two big reasons.  One, the majority hasn't foreseen this, but it's only a matter of time before someone compromises some key Bitcoin website and causes it to display bogus deposit addresses, thereby stealing bitcoins.  If that happened to MtGox or BitPay, the entire market would be spooked again.  If in June 2011 people were slapped in the face with "OMG bitcoins can be stolen from my hard drive", it's possible that in June 2013, people will be slapped in the face with "OMG you can never trust whether an address you see is really paying the person you think you're paying".

The second big reason is that it would lead to features that will build credibility with the legitimate business world.  If one could download a "walled garden" Bitcoin client that was designed to only pay addresses that could be traced to their recipients via PKI, or else pay individuals after going through a bunch of warnings of the "are you really really sure this is who you're paying?" type... such a client would do very well with a very large segment of the population.

When I see an order come through on my Casascius Coins website and it's like 1000 BTC or something, I cringe and tell myself, "I hope I haven't been hacked and that the customer wasn't given a hacker's payment address".  Sometimes I will run and look at block chain and a printed list with the addresses only, and make sure I actually own the address that was paid, I'm that paranoid.  Meanwhile, somebody ought to be cringing at the prospect of sending 1000 BTC trusting the web site is secure and all... perhaps it ought to be common knowledge to verify a payment address a 2nd way, such as a telephone call or a signed PGP message.  Ideally their client should be smart enough to either say "You're paying Casascius" or "I don't know who you're paying, so you better be sure about this!"

[1715500236]

1715500236

[1715500236]

1715500236

[1715500236]

1715500236

[1715500236]

1715500236

[1715500236]

1715500236

[2112]

How (and why) is this different from the invoice/payment/receipt proposed by Gavin?

https://bitcointalk.org/index.php?topic=128442.0

[oleganza]

Mike, how can I contact you (email preferably) to discuss the problem? I have some interesting ideas about that problem.

[niko]

Interesting ideas. At this moment I wouldn't dare sending someone 1000 coins without at least confirming the last few letters of the address over the phone or through another independant channel.

[casascius]

How (and why) is this different from the invoice/payment/receipt proposed by Gavin?

https://bitcointalk.org/index.php?topic=128442.0

It probably isn't different.  It's probably much the same.  I am mostly identifying the problem rather than the solution, and it's entirely conceivable that I'm not the first.

Part of it is a social problem.  People should be reluctant to send lots of BTC without a solid technological safeguard protecting them.  Our community has not yet been stunned with the painful realization that big losses can and will occur as hackers intercept and manipulate communications.  If Gavin's proposal is it, then I need to spend more time learning about it.

[justusranvier]

Wasn't Namecoin supposed to provide a part of the solution?

[jl2012]

There is a simple way but you will lose anonymity. Publish your deterministic watch-only wallet and sign with your PGP key so people can verify the addresses easily

Few month ago there was a discussion for the idea of "anonymous donation". It used some public-private key tricks. I forgot the details but based on some information provided by the donee, donors can generate an address which only the donee may spend, while no one may link the address to the donee. Unless the donor tells the donee,  he has to check all addresses on the blockchain one-by-one to see whether he has received any donation. I think this may also work for you (just publish the deterministic account information with PGP key, and ask your customers to tell you the address they have sent)

[deepceleron]

The problem would be: a. how do you prevent an unauthorized third party from making an address that looks like or pretends to be an authentic one. b. How do you have one-time use addresses with such a scheme.

1. Vanity address: it takes a considerable amount of CPU time to replicate a long vanity address, and visually you know who you are sending to from the address. See my sig, 14 characters to have your address look like mine. Single address only.

2. Namecoin-style "Alias"->address registration. Single address only, must be created with coins from address to be registered.

Implementation: You go into your address book, there is an option called "register address on network". You press this, it asks you to create an alias that other clients can see to send money to you. If you are not the first, you get an error that the alias is already taken. The alias is permanently included in the blockchain along with some bitcoins you donate as the fee, and then the address book will list all aliases registered to your address. Other Bitcoin clients would have a searchable database of all these aliases to find you as a recipient.

Such a "first to register" alias system could possibly be used to "sign/register" more addresses to be used with the same alias/account, so that any number of addresses can be "looked up" back to the alias.

3. Something more complex. The problem is with any address currently, the sender only knows the address (made of hash+hash), they can't extract any information from that. You also can't put information in that, it would take brute force equivalent to vanitygen. Adding any info (perhaps hash+info+checksum) would make an address longer, and a third party could add the same info as you.

Anything that is simply a "add more information to an address" type system, a third party could falsify. If your ID was "casascius", someone could be lulled into a false sense of security if they were sending to a scammer's "casacious company".

[etotheipi]

I believe that this thread combined with the payment protocol is the solution.  

Right now PKI/SSL (mostly) guarantees that you are talking with the server you think you are, but it doesn't guarantee that that server hasn't been compromised.  There's nothing stopping someone the attacker from plopping their own addresses in there.

In my scheme, that was similarly described by thanke, you create a root deterministic wallet, and give out just the public key, but not the chain code.  You sign that with an offline signing key (this is the key difference here... with SSL the server must hold the signing key online, in this scheme the signature happens once, offline).  Then the server doesn't distribute addresses, it distributes the root public key (with a verifiable signature) and a multiplier.  The user's software recognizes the signature and then multiplies the public key by the multiplier and sends money to that address.  (the multiplier fits right into BIP 32, I_left, and doesn't give away the chain code so the address chain is still kept private).

Assuming the PKI is implemented properly, that means that client software can refuse to send money to any address that isn't derived from the business's known (offline) public key.  Even if an attacker compromises the webserver, the worst they can do is send a random multiplier to the customer and not record it, thus requiring the business to later contact the customer and retrieve the multiplier (probably the order number) so they can find where the money went.   It essentially enables "secure address distributors".  

I have thought about something like this in Armory.  I figured it would basically be an extension to the payment protocol:   It can easily piggyback off of existing WoT (as Gavin described), and you can keep the spirit of both offline private keys and privacy of your address chains.  


EDIT:  Just to clarify, this technique does not use static addresses.  Each customer gets a different address, and has no way of knowing what any of the other addresses are.  The signed public key that is distributed is never used for receiving coins.

[MPOE-PR]

If that happened to MtGox or BitPay, the entire market would be spooked again.

If it "happened" to MtGox or BitPay they should go out of business. End of story. Stuff doesn't "happen".

Otherwise this issue was discussed already in another thread. The problem with it is that it's about as braindamaged as dns is: if there's an authority issuing these then we don't want it, and if there's no authority, then anyone can "fake" them anyway. (Also bonus points for you blissfully ignoring how this very problem is solved already, by MPEx among others. It really looks good, deliberate cluelessness.)

More importantly, the general policy of protecting idiots from their idiocy has no place in Bitcoin. As stated in that other thread, the point is to keep the Bitcoin good and improve people, not to keep people stupid and bring Bitcoin down to their level.

[malevolent]

The problem would be: a. how do you prevent an unauthorized third party from making an address that looks like or pretends to be an authentic one.
Anything that is simply a "add more information to an address" type system, a third party could falsify. If your ID was "casascius", someone could be lulled into a false sense of security if they were sending to a scammer's "casacious company".

I think there is a solution: only associate bitcoin addresses with email addresses or GPG/PGP.

[caveden]

In my scheme, that was similarly described by thanke, you create a root deterministic wallet, and give out just the public key, but not the chain code.  You sign that with an offline signing key (this is the key difference here... with SSL the server must hold the signing key online, in this scheme the signature happens once, offline).  Then the server doesn't distribute addresses, it distributes the root public key (with a verifiable signature) and a multiplier.  The user's software recognizes the signature and then multiplies the public key by the multiplier and sends money to that address.  (the multiplier fits right into BIP 32, I_left, and doesn't give away the chain code so the address chain is still kept private).

That's quite clever!

But how would it work for addresses that represent a script?

[etotheipi]

In my scheme, that was similarly described by thanke, you create a root deterministic wallet, and give out just the public key, but not the chain code.  You sign that with an offline signing key (this is the key difference here... with SSL the server must hold the signing key online, in this scheme the signature happens once, offline).  Then the server doesn't distribute addresses, it distributes the root public key (with a verifiable signature) and a multiplier.  The user's software recognizes the signature and then multiplies the public key by the multiplier and sends money to that address.  (the multiplier fits right into BIP 32, I_left, and doesn't give away the chain code so the address chain is still kept private).

That's quite clever!

But how would it work for addresses that represent a script?

There was some debate in that thread about it... If it's P2SH, you have to distribute the individual keys that make up the P2SH script and let the user create the P2SH script after they verify all the public keys (and we need to adopt a universal convention of ordering public keys lexicographically in P2SH scripts).  It kind of defeats the purpose of P2SH, but at least you still get the space-savings of P2SH in the pruned blockchain. 

It's not ideal, but it would work as long as all the keys are signed by the the same trusted authority.  If you're talking about arbitrary scripts... good luck with that one! 

[paybitcoin]

Yay, I like this topic...

I have always thought that there really needs to be some trusted third-party verification service for Bitcoin addresses, which would work in a similar fashion to an SSL CA. I don't believe the pgp-style web-of-trust model gives enough guarantees (or has enough defense against bad actors (edit, CACert is pretty close)) and using a cryptographic solution invites namespace-collision problems (i.e. the super secure third-party escrow solution at casacius.com.)

You would in practice also have a network of trust providers such that no one player has any control over the system. Bitcoin applications would operate similar to the perspectives project and pull trust information from many providers.

This is a straightforward way to get a useful protocol going. Simply add Bitcoin-OTC metrics, add a dash of GPG sigs, and toss in some IRL identity verification, and you'd be there.

Add thanke's or etotheipi's method on top for more security and anonymization.
--
This was my old favorite solution to this problem. But wow, from retep's work with creating fidelity bonds and thinking about it a lot more I have spent the last couple of hours fleshing it out into an entire system, and I have a new favorite. Instead of hijacking the thread here which I can be prone to doing I have written this up on another thread in Alternative Currencies:

Repcoin: a decentralized reputation currency

It would be a good candidate solution for this problem.

[caveden]

There was some debate in that thread about it... If it's P2SH, you have to distribute the individual keys that make up the P2SH script and let the user create the P2SH script after they verify all the public keys (and we need to adopt a universal convention of ordering public keys lexicographically in P2SH scripts).  It kind of defeats the purpose of P2SH, but at least you still get the space-savings of P2SH in the pruned blockchain. 

That sounds complicate. The client application would need to know how the script is supposed to be built. And the server won't necessarily own all keys in a multisig...

It's not ideal, but it would work as long as all the keys are signed by the the same trusted authority.  If you're talking about arbitrary scripts... good luck with that one! 

I think you should consider making your system capable of signing arbitrary addresses too. Even if for that case it means having an online signing key. I realize that an online signing key can be compromised if the server itself is compromised, but well, it's harder than compromising users' machines and putting the MiM there.
We should encourage the use of multisig and eventually other advanced features provided by scripting.

[Atruk]

I have always thought that there really needs to be some trusted third-party verification service for Bitcoin addresses, which would work in a similar fashion to an SSL CA. I don't believe the pgp-style web-of-trust model gives enough guarantees (or has enough defense against bad actors (edit, CACert is pretty close)) and using a cryptographic solution invites namespace-collision problems (i.e. the super secure third-party escrow solution at casacius.com.)

I don't know... I kind of like keeping my recieving addresses roughly as disposable as toiletpaper. Rather than trusting the address, it seems the stronger solution is trusting the way that you are given the address.

[etotheipi]

There was some debate in that thread about it... If it's P2SH, you have to distribute the individual keys that make up the P2SH script and let the user create the P2SH script after they verify all the public keys (and we need to adopt a universal convention of ordering public keys lexicographically in P2SH scripts).  It kind of defeats the purpose of P2SH, but at least you still get the space-savings of P2SH in the pruned blockchain. 

That sounds complicate. The client application would need to know how the script is supposed to be built. And the server won't necessarily own all keys in a multisig...

It's not complicated.  It just means that the webserver can't say: "Please pay this 25-byte P2SH script". Instead it will say: "Here's 3 public keys in a 2-of-3 tx, the CA signatures of those keys, and the multiplier to use for them".  The client will verify the three public keys, multiply them all by the multiplier, then construct the P2SH script deterministically, and then send the coins there.  It also isn't so bad, because it can all be automated behind the scenes, so users won't have to juggle 200-bytes of Base58 data or anything.

You can't really do this for arbitrary scripts.  This works because of the ECDSA multiplication properties that are used in all the other "crypto tricks" throughout Bitcoin.  And if you go back to online-signing keys, then I think the whole exercise is negated:  the whole point of this is so that the signing keys are not on the same system that is distributing the addresses.  Without that property, I'm not sure what we're gaining over SSL.

[Mike Hearn]

You might want to subscribe to the Foundation blog, Mike, as Gavin posts development updates there and the work to solve the problems you raise has already started:

   https://bitcoinfoundation.org/blog/?p=85

I pushed hard for some of these ideas many months ago and wrote a first prototype, which Gavin has since hammered into a set of prototype tools:

   https://github.com/gavinandresen/paymentrequest

Work has stalled because we're all focused on the next releases of Bitcoin and bitcoinj, respectively, but it's a high priority for Gavin and I think he'll go back to it soon.

[Roy Badami]

Interesting ideas. At this moment I wouldn't dare sending someone 1000 coins without at least confirming the last few letters of the address over the phone or through another independant channel.

Be careful - it's pretty easy for someone to generate an address that has the last few characters they want (and first few, for that matter).  People do it all the time with vanity addresses, but it could just as easily be done to try and defeat a simple 'over the phone' check of a few characters of the address.

roy

[caveden]

You can't really do this for arbitrary scripts.  This works because of the ECDSA multiplication properties that are used in all the other "crypto tricks" throughout Bitcoin.  And if you go back to online-signing keys, then I think the whole exercise is negated:  the whole point of this is so that the signing keys are not on the same system that is distributing the addresses.  Without that property, I'm not sure what we're gaining over SSL.

The security level may be the same of SSL, but there should be a way for a device like Trezor to safely attribute an address to a humanly recognizable name. Otherwise all its security will be gone the day that some hacker manages to code a trojan capable of tricking Trezor and the user's browser at the same time, displaying at both interfaces an address that belongs to the attacker.

I'd  very much like it to be extensible to arbitrary addresses because I think multisig is quite important. I'm not saying this clever thing with ECDSA multipliers shouldn't be done, on the contrary, it's quite cool actually, but it doesn't cover all possible cases.

[Mike Hearn]

Allowing Trezor to print a verified human readable (domain) name is the purpose of the payment protocol work.

[tpantlik]

Oh please, do not fall for PKI monstrosity - this system is seriously flawed! (I have my own bitter experience with end-users of which ~100 have absolutely no idea how is SSL/PKI works and even how to use it securely!)

21mil BTC for the creator of trustless PKI replacement!

[Atruk]

Oh please, do not fall for PKI monstrosity - this system is seriously flawed! (I have my own bitter experience with end-users of which ~100 have absolutely no idea how is SSL/PKI works and even how to use it securely!)

21mil BTC for the creator of trustless PKI replacement!

PGP + Due Dilligence

I'll cut you a discount. Just send 5.5 BTC to the address in my signature.

[tpantlik]

Oh please, do not fall for PKI monstrosity - this system is seriously flawed! (I have my own bitter experience with end-users of which ~100 have absolutely no idea how is SSL/PKI works and even how to use it securely!)

21mil BTC for the creator of trustless PKI replacement!

PGP + Due Dilligence

I'll cut you a discount. Just send 5.5 BTC to the address in my signature.

Heh    I should have require a foolproof system 

[MatthewLM]

For all those that hate PKI, explain a better solution.

[Atruk]

Oh please, do not fall for PKI monstrosity - this system is seriously flawed! (I have my own bitter experience with end-users of which ~100 have absolutely no idea how is SSL/PKI works and even how to use it securely!)

21mil BTC for the creator of trustless PKI replacement!

PGP + Due Dilligence

I'll cut you a discount. Just send 5.5 BTC to the address in my signature.

Heh    I should have require a foolproof system 

Isn't it amazing how trustproof and fool proof are nearly opposite ends of the spectrum.

[phelix]

Wasn't Namecoin supposed to provide a part of the solution?

Within namecoin you could tie a name to a bitcoin address.
(sendtoname, namecoin/bitcoin keysharing and even throw away addresses: https://en.bitcoin.it/wiki/BIP_0015#Namecoin_ID )

As long as you don't know if the name is legit you have not really added security, though.

Other than using a (central) authoritah only a web of trust comes to mind.

[casascius]

Oh please, do not fall for PKI monstrosity - this system is seriously flawed! (I have my own bitter experience with end-users of which ~100 have absolutely no idea how is SSL/PKI works and even how to use it securely!)

21mil BTC for the creator of trustless PKI replacement!

Adobe's Acrobat/PDF document signing PKI is an example of one that appears to work and be well-managed.

The operative difference is that those who care about the quality of the signatures have a vested interest in a good PKI and would be the last to complain about a loosey goosey PKI that favors convenience over security.

On the other hand, browser makers are far less in control.  They can't just decide that they will throw out the flawed SSL'iverse in favor of their own PKI scheme, or they'd lose market share.

I don't think the idea of PKI is inherently flawed, it's just that the most prominent one is being mismanaged and suffers from poor design.

[Mike Hearn]

Yeah, I have higher hopes for the DNSSEC PKI. It's how things should have worked from the start, but of course the cost of crypto and the US Govts attempts to stifle it made doing a PKI any earlier unworkable.

Unfortunately DNSSEC is still pretty new. It'd make sense to integrate it into the payment protocol after v1 is successfully deployed.

[casascius]

How about the following things that would require no PKI:

1. Some way for a user to know if he's paying someone he has paid before, versus someone he is now paying for the first time.  (Example: imagine paying your power bill with bitcoins.  Pretend you like having a paper power bill.  Every month you get a power bill in the mail and you pay it by scanning a QR code bitcoin address unique to each month's bill.  One month, a scammer sends you a realistic looking power bill but has his bitcoin address on it.  Your bitcoin client ought to have a means to flag something's unusual... this WILL happen, it's just a matter of time!)

2. Some way for a user to get a public key and know that he is paying the owner of that public key.  (Yes, that's how Bitcoin works inherently, but I mean a secondary public key that allows a user to confirm that a certain person must own the address)

3. The "Bitcoin Messaging" system previously discussed in other threads.  This would provide very similar functionality to PGP, except that keys are Bitcoin addresses.  Importantly, functionality would include ensuring you're paying the same person you're talking to, and/or paying the same person whose public key you can verify somewhere else.  As a simple minded example, before paying someone, you could send a bitcoin message to their address and confirm their ability to confirm, verbally for example, that they received it.  If they can confirm they can decrypt the message, you can feel good paying them at the same address.

[Realpra]

... Ideally their client should be smart enough to either say "You're paying Casascius" or "I don't know who you're paying, so you better be sure about this!"

I'm not sure this is possible, the address derives from a key only you know, if it were to derive from your brand name everyone would know the private key.

Seems to me there's no way to get both.

I would suggest letting a beefed computer run a week or a month to create a vanity address for your company and then use that. 1 layer of extra security anyway.
The more serious the company the more money and CPU you could put into it.

[phelix]

What about using data from the blockchain to determine the trustworthiness of an address? If it is not a throw away address it would say a lot.

First seen
Number of tx
Coins received

A hacker would probably use a fresh address. At least for donation addresses this would work well.

You could even calculate a bitcoin inherent web of trust from the addresses you own to the address in question.

[Mike Hearn]

1. Some way for a user to know if he's paying someone he has paid before, versus someone he is now paying for the first time.

It can be useful. You can do it with the existing payment protocol by including a signature with no PKI data. Use ECDSA key recovery on the signature and then record the derived pubkey.

2. Some way for a user to get a public key and know that he is paying the owner of that public key.

That's what the payment protocol does.

[caveden]

Adobe's Acrobat/PDF document signing PKI is an example of one that appears to work and be well-managed.

Well, it works, yes... but it is expensive! I work for a company that among other things has a system that does digital signatures for official documents. They are required to pay 0€15 for each signature they issue, not to mention the enormous costs for being able to issue these signatures in the first place. And that's paying exclusively for Adobe's "recognition". Adobe does't actually do anything, they have absolutely no extra cost when these signatures are issued. But if you want their recognition, open your pockets!

I hope that this implementation for bitcoin is done in such a way that more competition in the "authority market" is available, so that prices are not so high.

[niko]

Interesting ideas. At this moment I wouldn't dare sending someone 1000 coins without at least confirming the last few letters of the address over the phone or through another independant channel.

Be careful - it's pretty easy for someone to generate an address that has the last few characters they want (and first few, for that matter).  People do it all the time with vanity addresses, but it could just as easily be done to try and defeat a simple 'over the phone' check of a few characters of the address.

roy

I thought last few bytes are the checksum. How easy is it to generate a key pair with the public address ending in 4BpiZ?

[becoin]

where someone can paste an address into their Bitcoin client and see a confirmation: "Confirmed, you are paying Rocky Mountain Power Company"

How will you force this user to distinguish between "Confirmed, you are paying Rocky Mountain Power Company" and "Confirmed, you are paying Pocky Mountain Power Company", or "Confirmed, you are paying Rocky Mountin Power Company"?

the whole point of this is so that the signing keys are not on the same system that is distributing the addresses.

Absolutely. Many people just don't understand that there is a difference between the monetary system that is supporting the very existence of a currency and the payment system that is using this currency. There is a reason why these two systems must be kept separate. What casascius is pointing out as an issue has to be solved by improvements in different competing payment systems using bitcoin as a currency. Don't mess with the blockchain, mining or transaction relaying!

[deepceleron]

I thought last few bytes are the checksum. How easy is it to generate a key pair with the public address ending in 4BpiZ?

Unlike the first characters of a Bitcoin address, the possible last characters (including the checksum) are evenly distributed among the Base58 characters, i.e. the chance of the last character of any address you generate being "Z" is 1 in 58. On average, for every 58 addresses you generate, one will end with "Z", and the average time to find a "Z" will be 58 key generations (a 50% chance).

We only need to scale the probability up; for five characters, the chance is 1 in (58^5) - that's 1 in 656356768. Running my vanitygen at 180Kkey/s, I would have a 50% chance of finding one in 3646 seconds (about an hour). In fact, it took me less time:

vanitygen -r -k BpiZ$

(at result 35, of 58 expected on average):

Address: 17piCjuatkXRi8tPJf43fN2bSNeJi4BpiZ
Privkey: 5KJshpZnAygza2goQNB7gsmyvwEwg8CquLZBPgpHCDU8Dg5xCvP

[casascius]

where someone can paste an address into their Bitcoin client and see a confirmation: "Confirmed, you are paying Rocky Mountain Power Company"

How will you force this user to distinguish between "Confirmed, you are paying Rocky Mountain Power Company" and "Confirmed, you are paying Pocky Mountain Power Company", or "Confirmed, you are paying Rocky Mountin Power Company"?

Hypothetically speaking, a properly run PKI prevents people from obtaining certificates to impersonate others, and maintains a trail of recourse.  Example, something like EV SSL, or Adobe's PDF PKI.  The fact that extended validation is even possible attests to a likelihood that you're at least paying somebody who can be identified.

[casascius]

Adobe's Acrobat/PDF document signing PKI is an example of one that appears to work and be well-managed.

Well, it works, yes... but it is expensive! I work for a company that among other things has a system that does digital signatures for official documents. They are required to pay 0€15 for each signature they issue, not to mention the enormous costs for being able to issue these signatures in the first place. And that's paying exclusively for Adobe's "recognition". Adobe does't actually do anything, they have absolutely no extra cost when these signatures are issued. But if you want their recognition, open your pockets!

I hope that this implementation for bitcoin is done in such a way that more competition in the "authority market" is available, so that prices are not so high.

Adobe folks have got to eat too!

I have an Adobe signing key and I paid for the key, there is no per-document charge for my key.  But even if there was one, there is nothing inherently wrong with that, no law of nature says that everything that does not involve an increment in manual labor per transaction must be free, and there are more variables that define value than just the price.

Ironically, the high price serves as a barrier to entry, which itself adds value.  If you represent institution A and want to authenticate a document from institution B, the fact that Joe Blow can't get a similar looking certificate at a negligible cost adds value.  I wish more people understood why "overpriced" stuff derives the price/value it does, there's always more to it than somebody just wanting to overpay for something just because they're gullible or want the satisfaction of having paid too much for something.

[niko]

I thought last few bytes are the checksum. How easy is it to generate a key pair with the public address ending in 4BpiZ?

Unlike the first characters of a Bitcoin address, the possible last characters (including the checksum) are evenly distributed among the Base58 characters, i.e. the chance of the last character of any address you generate being "Z" is 1 in 58. On average, for every 58 addresses you generate, one will end with "Z", and the average time to find a "Z" will be 58 key generations (a 50% chance).

We only need to scale the probability up; for five characters, the chance is 1 in (58^5) - that's 1 in 656356768. Running my vanitygen at 180Kkey/s, I would have a 50% chance of finding one in 3646 seconds (about an hour). In fact, it took me less time:

vanitygen -r -k BpiZ$

(at result 35, of 58 expected on average):

Address: 17piCjuatkXRi8tPJf43fN2bSNeJi4BpiZ
Privkey: 5KJshpZnAygza2goQNB7gsmyvwEwg8CquLZBPgpHCDU8Dg5xCvP

Thanks for taking time to make it clear. I stand corrected.

[casascius]

Ironically, the high price serves as a barrier to entry, which itself adds value.  If you represent institution A and want to authenticate a document from institution B, the fact that Joe Blow can't get a similar looking certificate at a negligible cost adds value.  I wish more people understood why "overpriced" stuff derives the price/value it does, there's always more to it than somebody just wanting to overpay for something just because they're gullible or want the satisfaction of having paid too much for something.

Here's your certificate from my root authority, since you've already done the work of verifying your identity to me (you'll have to find that paper wallet though).  People can be sure that's your address (or trust any other addresses you sign, since you are now a second-level certificate authority.

That'll be 50BTC. First one's free if you can write the software to make it work, you'll "just" need Bitcoin to lookup and verify a signed message and the chain of trust from the Namecoin blockchain when someone uses your address. Let it know that I am the root CA, BTW.

Linux:

Code:

./namecoind name_update id/casascius '{"cert": {"address": "16EJyLJevdfUxF8MXDSctMfWaNxk14MXoE", "id": "casascius", "info": "Mike Caldwell", "authority": "deepceleron", "authbtc": "1DCeLERonUTsTERdpUNqxKTVMmnwU6reu5", "authnmc": "N76D6hEHB55cGPk8QiG6ysgMbXb11b3nAH"}, "sig": "HAGiR4/oetIedslegs2G5br+w6UpbeIVxZK8+WcASArSroAIuWDAV9B+5Hgck/Bge+0LYQwYTq1dTgTvBMyXdeQ="}'

Windows:

Code:

namecoind.exe name_update id/casascius "{\"cert\": {\"address\": \"16EJyLJevdfUxF8MXDSctMfWaNxk14MXoE\", \"id\": \"casascius\", \"info\": \"Mike Caldwell\", \"authority\": \"deepceleron\", \"authbtc\": \"1DCeLERonUTsTERdpUNqxKTVMmnwU6reu5\", \"authnmc\": \"N76D6hEHB55cGPk8QiG6ysgMbXb11b3nAH\"}, \"sig\": \"HAGiR4/oetIedslegs2G5br+w6UpbeIVxZK8+WcASArSroAIuWDAV9B+5Hgck/Bge+0LYQwYTq1dTgTvBMyXdeQ=\"}"

This is the data signed with Bitcoin:

{"address": "16EJyLJevdfUxF8MXDSctMfWaNxk14MXoE", "id": "casascius", "info": "Mike Caldwell", "authority": "deepceleron", "authbtc": "1DCeLERonUTsTERdpUNqxKTVMmnwU6reu5", "authnmc": "N76D6hEHB55cGPk8QiG6ysgMbXb11b3nAH"}

My self-signed CA: http://explorer.dot-bit.org/n/74491

edit: looks like I "extended" the proposed spec a bit:
http://dot-bit.org/Namespace:Identity
https://en.bitcoin.it/wiki/BIP_0015#Namecoin_ID

For the most part, this is brilliant (no I'm not about to pay 50BTC though).

What you've done here is created a novel application for an existing technology that in all probability will work exactly the way it's supposed to... something I see as a viable business model, other than for a couple missing things.  If I could describe those couple missing things and you took them seriously (among other things), there is no reason you couldn't actually start a business where you did nothing other than generate cryptographic certificates at negligible cost to you, and charge real money for them.

The first thing is that I have never heard of you being in the business of vouching for people's reputation and identity.  That doesn't mean it's too late to start, by any means.  For your "authority" to have value, people need to know who you are and that you've dedicated yourself and put a serious stake in the business of being one.  The main reason why your offer isn't worth 50 BTC to me is that I can't go somewhere and point to that record and have average folks give me significant extra credibility as a result of its existence.  It's not competitive, because there are numerous other avenues where I can get that for much less.  (Note that GPG isn't a candidate here despite the free price, because most casual computer users don't use it)

The second thing is that I did not offer to purchase these services from you.  This is an important distinction.  Read this little blurb on contract law: http://tutor2u.net/law/notes/contract-elements.html ... what you have proposed is best described as an offer, and I have not accepted it.  Mr. Riley put it perfectly: "It is very important to distinguish an offer from an invitation to treat – that is, an invitation for other people to submit offers. Some everyday situations which we might think are offers are in fact invitations to treat:" (list of examples follows)

On the other hand, be aware that 50 BTC isn't an unreasonable price for cryptographic services when the value has been added.  50 BTC is about $1000, seems to me that's about what I paid to get an Adobe certificate.  The difference is, something I sign with my Adobe certificate gets instant credibility with the uninitiated public (who has never heard of PGP) because their Acrobat Reader will display a soothing blue badge and bar - within the program itself - asserting that I really signed/certified that document when they open it.  There is also a legal system accustomed to using PDF that would likely recognize it as well.  There is nowhere computer-illiterate Joe Blow can go to see the results of what you added to the namecoin database and feel he understands it well enough to be confident about trusting it, and this is what distinguishes the two.

If you had a proposition where your services were widely deemed to be worth 50 BTC, unfortunately that wouldn't just be "free money" to stuff your pocket.  You'd get to that position of authority by spending a lot of money on reputation building, advertising, and PR, and that 50 BTC would hopefully be a return on investment representing a profit after all of your expenses.  But of course it might not be, that's your risk to take.

Finally, some bit of personal reputation goes into your ability to operate trust-related services.  Having a clean criminal background, good credit history are musts, having a somewhat related career or degree, as well as connections to those with capital and other resources are a huge help as well.  Someone who started a business like this but who had, for example, a check forgery conviction in their past, could reasonably expect to see their business collapse when people started doing their due diligence.

If you ever become known in the community as operating a business like this though... I'd probably subscribe if the rate was a reasonable reflection of what I deemed its value to be in the marketplace.

[deepceleron]

Here's your certificate from my root authority,
...

For the most part, this is brilliant (no I'm not about to pay 50BTC though).
....

I was offering my "services" tongue in cheek, if you didn't catch that - I've made no great effort to establish a reputation or reveal my identity to more than members I've bought stuff from. A company like MtGox would be a likely root CA issuer - they've got your ID and bank info already, so they have already verified "trust" for many bitcoiners, and scammers might be put off going through MtGox and paying money to get a counterfeit look-alike alias.

You or any other person could offer such service though, in the spirit of "decentralized". With a "signed alias", one could simply use their own main identity to self-register other addresses (like auto-sign pregenerated one-time pay addresses), or you could "vouch" for others by signing their address and require real verification or only verifying that they've proved to you it's their address. As an issuer, you can scan for and reject any name that might be confused for an already-issued trust. A fully implemented client could not only look up the name when you put in an address, but let you "view certificate" to see who issued the trust. Like you say, charge $50 and do some checks, and your issued certificates are more trustworthy.

The work would be putting it in Bitcoin; you'd have to make a bastard-child client that accessed both blockchains (main client, very low chance of that happening), or get a BIP through that added the namecoin-like registration to Bitcoin (devs have already said Bitcoin isn't for data). That's the part that's worth 50BTC.

[casascius]

There is a bit of irony in CA services for bitcoiners.

True blue bitcoiners already have and understand PGP and thus probably wouldn't feel the need to pay for such services.

If and when PGP-like functions make their way into Bitcoin clients (not an outrageous proposition), that will be even more true.  After all, if you're already trusting in cryptography for your money, trusting in the same software to provide cryptography for your communications is a totally reasonable stretch that would make sense even to average computer users.

At that rate, the real value won't necessarily be in one guy being the "trust authority".  Instead, I see Bitcoin conferences having key-signing parties as standard fare, given that Bitcoiners put a premium on decentralized trust mechanisms.  That way, the conferences themselves will add the value... not so much that somebody will be making the money, but rather, people will be paying to attend the conference in order to receive that value among other things.  The more people who can make a business case to come to the conference, the more revenue comes in, which directly translates to a lower admission price per person, or a nicer venue, for future conferences.

[caveden]

I have an Adobe signing key and I paid for the key, there is no per-document charge for my key.  

That's probably because you always sign with the same certificate. The company I work for has to sign in the name of other people actually, so, after authentication, they generate a "minute-certificate", used only to sign the document (it expires quickly). That certificate carries the name of the client. And to generate that certificate, you gotta pay 15 cents of euro IIRC.

But even if there was one, there is nothing inherently wrong with that,

As there's nothing inherently wrong with charging a 4% fee for conducting a payment either. Yet, here are we trying to make something better.

[killerstorm]

I proposed a solution in other thread... It is possible to use blockchain as an address book without namecoinesque complexities.

To reference a public key you can reference certain transaction input. Transaction input can be identified using triple <block_index, transaction_index, output_index>.

Applying certain optimizations and trade-offs you can encode this tripple in a 32-bit (or even 24-bit) number.

PGP word list can encode 8 bits in one English word. So to encode a 32-bit ID you need four words.

So, basically, we can make public key IDs like "absurd replica cranky decadance".

And this is, like, also a name of a company...