Feature request : signing a text with a wallet key

[grondilu]

I'd like to be able to use one of my wallet keys to sign an ASCII text.

syntax of the command would be :

Code:

$ bitcoind signwithaddress BITCOIN_ADRESS < somefile > somefile.asc
$ bitcoind verifysignature < somefile.asc
correct signature done on DATE by address BITCOIN_ADRESS
Message was :
....

somefile.asc could be written in a form such as :

---- BEGIN ECDSA SIGNED MESSAGE ----
...
---- END ECDSA SIGNED MESSAGE ----

Or something like that.

[1714010181]

1714010181

[1714010181]

1714010181

[1714010181]

1714010181

[1714010181]

1714010181

[caveden]

This would be nice.

Actually it would be even nicer if we could treat our wallet.dat file as a generic keystore, importing and exporting keys.
This would allow merging and splitting of wallets as well, besides signatures as suggested above.

[grondilu]

Actually it would be even nicer if we could treat our wallet.dat file as a generic keystore, importing and exporting keys.
This would allow merging and splitting of wallets as well, besides signatures as suggested above.

+1

[gene]

This violates the "one job and do it well" philosophy. There already exist established standards for cryptographic signatures.

[grondilu]

This violates the "one job and do it well" philosophy. There already exist established standards for cryptographic signatures.

Ok then someone tells me how I can :

- extract an ECDSA private key from a wallet file ;
- use this key to sign data ;
- verify data signed this way ;

[gene]

This violates the "one job and do it well" philosophy. There already exist established standards for cryptographic signatures.

Ok then someone tells me how I can :

- extract an ECDSA private key from a wallet file ;
- use this key to sign data ;
- verify data signed this way ;

My point is that bitcoin is a currency. It shouldn't be in the business of general-use public key crypto. If you want to sign data, something like gpg would do a better job. You can already associate a gpg key to an account. I think it would be best to avoid encumbering bitcoin with redundant functionality. We should be mindful that with features come code. Code which must be written, debugged, maintained... and code which may potentially be exploited. The slimmer bitcoin remains, the better.

[grondilu]

We should be mindful that with features come code. Code which must be written, debugged, maintained... and code which may potentially be exploited. The slimmer bitcoin remains, the better.

Well, I guess you're right.

[davout]

This violates the "one job and do it well" philosophy. There already exist established standards for cryptographic signatures.

That's a unix principle, not a bitcoin one.

I like this feature, it's not overloading the protocol in any way and I can see a bunch of potential uses.

Opened a git issue : https://github.com/bitcoin/bitcoin/issues/issue/6

[gene]

This violates the "one job and do it well" philosophy. There already exist established standards for cryptographic signatures.

That's a unix principle, not a bitcoin one.

I like this feature, it's not overloading the protocol in any way and I can see a bunch of potential uses.

Opened a git issue : https://github.com/bitcoin/bitcoin/issues/issue/6

It all depends on what you want bitcoin to be. If you wish for it to become a monolithic application which can perform arbitrary cryptographic functions, by all means, go for it. I think this would be exactly the wrong way to go. I want bitcoin to succeed as a currency. The slimmer the standard and codebase, the easier it is to develop portable implementations and improve chances for adoption. Really, how hard is it to associate a pgp key to an account?

Security is also of paramount importance for bitcoin, and you can't exploit code that doesn't exist.

[caveden]

My point is that bitcoin is a currency. It shouldn't be in the business of general-use public key crypto.

Signing with a bitcoin private key provides proof of ownership. This may have many use cases. It's a good feature.

Also, being able to split/merge wallets is interesting too. Today maybe not much, since transfers are free. But they won't remain free forever, and even today, each transfer does imply in a small cost to the entire network. Merging/splitting wallets would be a way to move money around without using the chain. It's also a good feature to have.

You can already associate a gpg key to an account.

Can you? I don't know how... I thought the account feature wasn't even public... can anyone knows how much I own on account X just by checking the block chain?
How do I create a key related to this account and use it to sign something, proving that I am the owner of such amount?

[caveden]

It all depends on what you want bitcoin to be. If you wish for it to become a monolithic application which can perform arbitrary cryptographic functions, by all means, go for it.

It doesn't need to be monolithic. The code that manages the wallet doesn't have to be the same that interacts to the network. They'd better not be, imho.

The wallet is a specific type of keystore. As a keystore, it would be nice to be able to import/export keys, and actually using them.

For example, another use case would be to encrypt some message for the owner of address X only. It could be encrypted using the public key of such address. The receiver must be able to retrieve the corresponding private key and use it to decrypt the message.

[gene]

My point is that bitcoin is a currency. It shouldn't be in the business of general-use public key crypto.

Signing with a bitcoin private key provides proof of ownership. This may have many use cases. It's a good feature.

Proof of ownership of an account number? Or of funds in an account? Proof of ownership of an account number can be done with pgp.

Also, being able to split/merge wallets is interesting too. Today maybe not much, since transfers are free. But they won't remain free forever, and even today, each transfer does imply in a small cost to the entire network. Merging/splitting wallets would be a way to move money around without using the chain. It's also a good feature to have.

Perhaps, but I see this as an issue separate from signatures.

You can already associate a gpg key to an account.

Can you? I don't know how... I thought the account feature wasn't even public... can anyone knows how much I own on account X just by checking the block chain?
How do I create a key related to this account and use it to sign something, proving that I am the owner of such amount?

You can associate a public key to an arbitrary identity, not just a name or email address. Gpg allows this. If you want to prove you hold certain funds in an account, I am not sure how extending bitcoin to perform cryptographic signatures can help.

[davout]

Proof of ownership of an account number? Or of funds in an account? Proof of ownership of an account number can be done with pgp.

Proof of ownership of the actual funds.

Can you? I don't know how... I thought the account feature wasn't even public... can anyone knows how much I own on account X just by checking the block chain?
How do I create a key related to this account and use it to sign something, proving that I am the owner of such amount?

You can associate a public key to an arbitrary identity, not just a name or email address. Gpg allows this. If you want to prove you hold certain funds in an account, I am not sure how extending bitcoin to perform cryptographic signatures can help.

You can't associate a key with an account. They're managed internally by the client.

Point is you can prove ownership of funds by signing arbitrary data with a private key, so I see this feature as very useful.

[caveden]

Proof of ownership of an account number? Or of funds in an account? Proof of ownership of an account number can be done with pgp.

I meant the funds. But even the account number, how do you prove it's yours? The account numbers go to the chain somehow?

Also, being able to split/merge wallets is interesting too. Today maybe not much, since transfers are free. But they won't remain free forever, and even today, each transfer does imply in a small cost to the entire network. Merging/splitting wallets would be a way to move money around without using the chain. It's also a good feature to have.

Perhaps, but I see this as an issue separate from signatures.

Well, if you can export keys, you can sign with them using an external tool at least.

You can associate a public key to an arbitrary identity, not just a name or email address. Gpg allows this.

As far as I understand, the link "gpg key" => "arbitrary identity" is possible, since proof of gpg key ownership is possible though signature.
But "arbitrary identity" => "gpg key" I can't see how, since there's no generic way to prove ownership of an arbitrary identity.

Like, I can create a GPG key and link it to your name. But that isn't my name. See what I mean?

If you want to prove you hold certain funds in an account, I am not sure how extending bitcoin to perform cryptographic signatures can help.

You just sign something with the same private key that owns the coins and that's it, you prove you own such coins. The other party just need to check the block chain to confirm.

[gene]

Proof of ownership of an account number? Or of funds in an account? Proof of ownership of an account number can be done with pgp.

Proof of ownership of the actual funds.

Interesting. To what ends? What good is the proof after the proof has been generated?

Can you? I don't know how... I thought the account feature wasn't even public... can anyone knows how much I own on account X just by checking the block chain?
How do I create a key related to this account and use it to sign something, proving that I am the owner of such amount?

You can associate a public key to an arbitrary identity, not just a name or email address. Gpg allows this. If you want to prove you hold certain funds in an account, I am not sure how extending bitcoin to perform cryptographic signatures can help.

You can't associate a key with an account. They're managed internally by the client.

What about this?

Code:

$ gpg -k yourbitcoinaddresshere
pub   1024D/deadb33f 2010-01-11 [expires: never]
uid                  yourbitcoinaddresshere
sub   2048g/beefd34d 2010-01-11 [expires: never]

Point is you can prove ownership of funds by signing arbitrary data with a private key, so I see this feature as very useful.

You can prove ownership of funds at the time you make a signature? What good does that do you after the time of signature?

===

Proof of ownership of an account number? Or of funds in an account? Proof of ownership of an account number can be done with pgp.

I meant the funds. But even the account number, how do you prove it's yours? The account numbers go to the chain somehow?

That's where trust comes in. The old PKI/WOT issue.

Also, being able to split/merge wallets is interesting too. Today maybe not much, since transfers are free. But they won't remain free forever, and even today, each transfer does imply in a small cost to the entire network. Merging/splitting wallets would be a way to move money around without using the chain. It's also a good feature to have.

Perhaps, but I see this as an issue separate from signatures.

Well, if you can export keys, you can sign with them using an external tool at least.

You can associate a public key to an arbitrary identity, not just a name or email address. Gpg allows this.

As far as I understand, the link "gpg key" => "arbitrary identity" is possible, since proof of gpg key ownership is possible though signature.
But "arbitrary identity" => "gpg key" I can't see how, since there's no generic way to prove ownership of an arbitrary identity.

Like, I can create a GPG key and link it to your name. But that isn't my name. See what I mean?

See above.

If you want to prove you hold certain funds in an account, I am not sure how extending bitcoin to perform cryptographic signatures can help.

You just sign something with the same private key that owns the coins and that's it, you prove you own such coins. The other party just need to check the block chain to confirm.

Maybe I am overlooking something critical. What is the point of telling somebody how much money you have at some instant, when at any subsequent time, the proof is no longer valid?

[caveden]

That's where trust comes in. The old PKI/WOT issue.

If you depend on trust you're not proving anything. Normally proofs are asked exactly when there isn't enough confidence.

Maybe I am overlooking something critical. What is the point of telling somebody how much money you have at some instant, when at any subsequent time, the proof is no longer valid?

The proof is valid while the funds remain in the same address. They may remain there for a long time.

[Gavin Andresen]

I like this feature request; I think it will enable even more interesting uses of bitcoin.  I created a feature request at github for it.

Example:  a store that accepts bitcoins could verify that a customer sending in a question about some transaction actually IS the same person who sent them the bitcoins, by asking the customer to sign their message using one of the same bitcoin addresses they used to sign the coins.

If the "store" is a privacy-focused VPS provider and the question is "Hey, I lost the root password to the virtual server, could you generate a new one and encrypt it with this gpg public key", then tying that message to a bitcoin transactions is extremely useful.

[davout]

Interesting. To what ends? What good is the proof after the proof has been generated?

It's still good and can be re-checked at any time against the block chain data.

What about this?

Code:

$ gpg -k yourbitcoinaddresshere
pub   1024D/deadb33f 2010-01-11 [expires: never]
uid                  yourbitcoinaddresshere
sub   2048g/beefd34d 2010-01-11 [expires: never]

Point is you can prove ownership of funds by signing arbitrary data with a private key, so I see this feature as very useful.

You can prove ownership of funds at the time you make a signature? What good does that do you after the time of signature?

That's basically what's being discussed here, being able to use the bitcoin wallet as a keystore, which it ultimately is.
Also, as stated earlier, signatures prove you own the private key that matches an address, an address balance can be checked at any time.

That's where trust comes in. The old PKI/WOT issue.

No trust is involved, at any point.

Well, if you can export keys, you can sign with them using an external tool at least.

The point is not to sign the keys, but sign using the keys.

See above.

That is pretty much what is being requested as a feature.

If you want to prove you hold certain funds in an account, I am not sure how extending bitcoin to perform cryptographic signatures can help.

Performing the signatures or exporting the keys pretty much solve the problem of easily proving ownership of funds.
I would like to see the signature part in the main client, it does not add overhead to the protoco/blockchainl *at all* and can be forked and patched by you if you disagree with the consensus that seems to emerge.

Maybe I am overlooking something critical. What is the point of telling somebody how much money you have at some instant, when at any subsequent time, the proof is no longer valid?

You are overlooking lots of things and you should probably spend some time reading about how bitcoin works.

[Gavin Andresen]

Oh, and RE: extracting private keys from the wallet:

I'm less excited about that idea.  What if the private keys are stored in a tamper-proof "trusted security module" hardware doo-hickey, and are impossible to export?

[grondilu]

Gosh I've just noticed that this thread has gone long.

I haven't read everything, but I'd like to explain why I wanted this feature.

I am writing a CGI script for my private stockholdings brokerage system.

To that end, instead of using passwords, I wanted to use private keys.  So naturally I was planning to use GnuPG.  But during writing, I realised at some point the owner should send a bitcoin address where to receive dividends.  It seemed to me that I was using two keys pairs (a GnuPG one, and a ECDSA one), in order to identify the same person.  Since only ECDSA is really necessary (dividends have to go somewhere in the end), I realised that it might be better to identify owner with this pair.  It would also be better for confidentiallity (since most GnuPG keys use real names).