Bitcoin Forum
November 22, 2017, 06:04:22 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 »  All
  Print  
Author Topic: There needs to be a new bitcoin address format...  (Read 3052 times)
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1358


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
January 31, 2013, 11:21:19 PM
 #1

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

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper or hardware wallets instead.
1511330662
Hero Member
*
Offline Offline

Posts: 1511330662

View Profile Personal Message (Offline)

Ignore
1511330662
Reply with quote  #2

1511330662
Report to moderator
1511330662
Hero Member
*
Offline Offline

Posts: 1511330662

View Profile Personal Message (Offline)

Ignore
1511330662
Reply with quote  #2

1511330662
Report to moderator
1511330662
Hero Member
*
Offline Offline

Posts: 1511330662

View Profile Personal Message (Offline)

Ignore
1511330662
Reply with quote  #2

1511330662
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511330662
Hero Member
*
Offline Offline

Posts: 1511330662

View Profile Personal Message (Offline)

Ignore
1511330662
Reply with quote  #2

1511330662
Report to moderator
1511330662
Hero Member
*
Offline Offline

Posts: 1511330662

View Profile Personal Message (Offline)

Ignore
1511330662
Reply with quote  #2

1511330662
Report to moderator
2112
Legendary
*
Offline Offline

Activity: 1974



View Profile
January 31, 2013, 11:44:27 PM
 #2

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

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

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
oleganza
Full Member
***
Offline Offline

Activity: 200


Software design and user experience.


View Profile WWW
January 31, 2013, 11:54:55 PM
 #3

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

Bitcoin analytics: blog.oleganza.com / 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo
niko
Hero Member
*****
Offline Offline

Activity: 742


There is more to Bitcoin than bitcoins.


View Profile
February 01, 2013, 12:10:49 AM
 #4

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.

They're there, in their room.
Your mining rig is on fire, yet you're very calm.
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1358


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 01, 2013, 12:34:24 AM
 #5

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.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper or hardware wallets instead.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
February 01, 2013, 12:50:47 AM
 #6

Wasn't Namecoin supposed to provide a part of the solution?
jl2012
Legendary
*
Offline Offline

Activity: 1722


View Profile
February 01, 2013, 01:20:36 AM
 #7

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)

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
deepceleron
Legendary
*
Offline Offline

Activity: 1512



View Profile WWW
February 01, 2013, 01:43:20 AM
 #8

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
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
February 01, 2013, 04:35:43 AM
 #9

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

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
MPOE-PR
Hero Member
*****
Offline Offline

Activity: 756



View Profile
February 01, 2013, 08:23:01 AM
 #10

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.

My Credentials  | THE BTC Stock Exchange | I have my very own anthology! | Use bitcointa.lk, it's like this one but better.
malevolent
can into space
Staff
Legendary
*
Offline Offline

Activity: 1862



View Profile
February 01, 2013, 08:28:41 AM
 #11

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
Legendary
*
Offline Offline

Activity: 1106



View Profile
February 01, 2013, 08:56:59 AM
 #12

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, Ileft, 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?

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
February 01, 2013, 09:02:27 AM
 #13

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, Ileft, 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!  Smiley

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
paybitcoin
Member
**
Offline Offline

Activity: 85


1h79nc


View Profile WWW
February 01, 2013, 09:06:50 AM
 #14

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. Wink 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
Legendary
*
Offline Offline

Activity: 1106



View Profile
February 01, 2013, 11:00:49 AM
 #15

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

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.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
Atruk
Hero Member
*****
Offline Offline

Activity: 700



View Profile
February 01, 2013, 11:02:45 AM
 #16

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
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
February 01, 2013, 11:10:24 AM
 #17

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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
February 01, 2013, 12:06:13 PM
 #18

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
Hero Member
*****
Offline Offline

Activity: 530


View Profile
February 01, 2013, 12:32:45 PM
 #19

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
Legendary
*
Offline Offline

Activity: 1106



View Profile
February 01, 2013, 12:49:50 PM
 #20

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.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!