Topic: There needs to be a new bitcoin address format... - page 2. (Read 3416 times)

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

Heh    I should have require a foolproof system 

PGP + Due Dilligence

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

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!

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

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.

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

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.

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.

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.

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


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.

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.

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! 

That's quite clever!

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

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

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.

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.

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.


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

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)

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