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

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