Author

Topic: Private/Public key in transactions (Read 490 times)

hero member
Activity: 593
Merit: 505
Wherever I may roam
May 22, 2013, 10:53:14 AM
#10
Perfect, I guess you gave me a better understanding about the "change" transaction: depending on the client, it may go back to the sender address (blockchain.info) or be sent to a new (but pre-existing) one (Bitcoin-QT).

And sure, in case I use bitcoins from my paper wallet, I'll send the remaining value to a new address and print it out.

Thanks!
legendary
Activity: 3472
Merit: 4801
May 22, 2013, 10:43:19 AM
#9
Great, thanks Danny. This really makes sense. I suppose that's why Bitcoin-QT comes with 100 pre-created pubkeys (and 100 associated privkeys, of course). I guess you mean that the client will choose one of them.

For example, I use the first one you mentioned, blockchain. It shows to me my Bitcoin address (1...). Do you think that, if I make any transaction from there, blockchain is going to show to me, at that point, 2 addresses? Or just the new one created for the purpouse of receiving the "change"?
This is important since I made a paper wallet from that address, which is stored in my house. So I wonder if I have to make a new printout whenever I make a new transaction from that particular address. Since it shows both the keys, I thought that shpouldn't be renewed everytime.

Thanks!

As far as I know, blockchain.info re-uses your existing receiving addresses for the "change", so it shouldn't show 2 addresses unless you choose to create a new receiving address.  If you choose to use some other wallet (such as Bitcoin-Qt) to spend the bitcoins associated with your paper wallet, then you'll need to make sure you understand how that wallet works.  As long as you stick with blockchain.info for your wallet, you should be able to re-use your paper wallet if you wish to (assuming that blockchain.info doesn't change their default behavior in the future).

Keep in mind that each time you use a paper wallet, the private key is susceptible to being intercepted.  If security is important enough to you that you are choosing to use a paper wallet in the first place, then it's generally safer to consider a paper wallet as being compromised as soon as you spend the funds from it, and send any unspent balance to a new paper wallet.  
newbie
Activity: 42
Merit: 0
May 22, 2013, 10:39:55 AM
#8
Yes you can
hero member
Activity: 593
Merit: 505
Wherever I may roam
May 22, 2013, 10:21:34 AM
#7
Still I cannot fully understand this: where and how the "change" goes back to me? Does it goes back to the same originating address or to a third new one?


And this is completely independent of the fact whether the "change" of your transaction is sent to the same address or a different one. Normally, the bitcoin client sends the "change" to a new address that it created to obfuscate the flow of money a little bit. There are heuristics to guess which part of a transaction stays with the sender as change, and which part actually goes to a recipient, but AFAIK these can be wrong.

Onkel Paul

If the "change" goes to a new address, how do I have the private key linked to that pubkey (the new address). That's why my understanding was that it goes back to the originating address.

Please tell me if I'm wrong! And thanks for your time!

This depends entirely on how the particular wallet you are using chooses to implement it.  Wallets such as MultiBit and https://blockchain.info/wallet choose to send the change back to an already existing address that you can see in your wallet.  Wallets such as Bitcoin-Qt choose to send the change back to a brand new address for each transaction.  This is implemented by the wallet itself as it builds the transaction.  If the wallet is going to send the change back to a visible address from your user interface, then the wallet is programed with some logic for choosing one of those addresses and then builds the transaction output to send to that address.  If the wallet is going to send the change to a new address, then it is programmed with some logic for getting a new random private key, computing the address, tracking the private key and address in the wallet database, and keeping these details hidden from you so you don't see a new address pop into your user interface every time you create a transaction.



Great, thanks Danny. This really makes sense. I suppose that's why Bitcoin-QT comes with 100 pre-created pubkeys (and 100 associated privkeys, of course). I guess you mean that the client will choose one of them.

For example, I use the first one you mentioned, blockchain. It shows to me my Bitcoin address (1...). Do you think that, if I make any transaction from there, blockchain is going to show to me, at that point, 2 addresses? Or just the new one created for the purpouse of receiving the "change"?
This is important since I made a paper wallet from that address, which is stored in my house. So I wonder if I have to make a new printout whenever I make a new transaction from that particular address. Since it shows both the keys, I thought that shpouldn't be renewed everytime.

Thanks!
legendary
Activity: 3472
Merit: 4801
May 22, 2013, 10:06:04 AM
#6
Still I cannot fully understand this: where and how the "change" goes back to me? Does it goes back to the same originating address or to a third new one?


And this is completely independent of the fact whether the "change" of your transaction is sent to the same address or a different one. Normally, the bitcoin client sends the "change" to a new address that it created to obfuscate the flow of money a little bit. There are heuristics to guess which part of a transaction stays with the sender as change, and which part actually goes to a recipient, but AFAIK these can be wrong.

Onkel Paul

If the "change" goes to a new address, how do I have the private key linked to that pubkey (the new address). That's why my understanding was that it goes back to the originating address.

Please tell me if I'm wrong! And thanks for your time!

This depends entirely on how the particular wallet you are using chooses to implement it.  Wallets such as MultiBit and https://blockchain.info/wallet choose to send the change back to an already existing address that you can see in your wallet.  Wallets such as Bitcoin-Qt choose to send the change back to a brand new address for each transaction.  This is implemented by the wallet itself as it builds the transaction.  If the wallet is going to send the change back to a visible address from your user interface, then the wallet is programed with some logic for choosing one of those addresses and then builds the transaction output to send to that address.  If the wallet is going to send the change to a new address, then it is programmed with some logic for getting a new random private key, computing the address, tracking the private key and address in the wallet database, and keeping these details hidden from you so you don't see a new address pop into your user interface every time you create a transaction.

hero member
Activity: 593
Merit: 505
Wherever I may roam
May 22, 2013, 09:44:40 AM
#5
Thank you guys for the reply!

Read up on ECDSA signatures and Elliptic Curve Cryptography to better understand how they work.  It is not necessary to reveal your private key in order to "sign with your private key":

http://en.wikipedia.org/wiki/ECDSA
http://en.wikipedia.org/wiki/Elliptic_curve_cryptography

The private key is used to generate the signature, but the public key is used to verify the signature.  The signature created with the private key is only valid for the specific thing being signed.  If you try to use that same signature with any other set of data, it will not be verifiable.

Thanks, that was in fact one of my readings, but didn't understand how to apply it to transactions, i.e. if I had to give my private key with the transaction, or just using it to digitally sign the transaction itself. I now understand is the latter.

Still I cannot fully understand this: where and how the "change" goes back to me? Does it goes back to the same originating address or to a third new one?


And this is completely independent of the fact whether the "change" of your transaction is sent to the same address or a different one. Normally, the bitcoin client sends the "change" to a new address that it created to obfuscate the flow of money a little bit. There are heuristics to guess which part of a transaction stays with the sender as change, and which part actually goes to a recipient, but AFAIK these can be wrong.

Onkel Paul

If the "change" goes to a new address, how do I have the private key linked to that pubkey (the new address). That's why my understanding was that it goes back to the originating address.

Please tell me if I'm wrong! And thanks for your time!

legendary
Activity: 3472
Merit: 4801
May 22, 2013, 09:34:20 AM
#4
Read up on ECDSA signatures and Elliptic Curve Cryptography to better understand how they work.  It is not necessary to reveal your private key in order to "sign with your private key":

http://en.wikipedia.org/wiki/ECDSA
http://en.wikipedia.org/wiki/Elliptic_curve_cryptography

The private key is used to generate the signature, but the public key is used to verify the signature.  The signature created with the private key is only valid for the specific thing being signed.  If you try to use that same signature with any other set of data, it will not be verifiable.
legendary
Activity: 1039
Merit: 1005
May 22, 2013, 09:27:55 AM
#3
Signing is not encryption.

Basically, the signature is the hash of the transaction encrypted with your private key. Checking the signature just means to calculate the hash of the transaction, decrypt the signature with the public key, and check whether the two are equal.
The signature just proves that the holder of the private key has signed the transaction. To check that proof, only the public key is needed, so your private key is never sent anywhere.
But the transaction is fully readable even without checking the signature.

And this is completely independent of the fact whether the "change" of your transaction is sent to the same address or a different one. Normally, the bitcoin client sends the "change" to a new address that it created to obfuscate the flow of money a little bit. There are heuristics to guess which part of a transaction stays with the sender as change, and which part actually goes to a recipient, but AFAIK these can be wrong.

Onkel Paul
newbie
Activity: 11
Merit: 0
May 22, 2013, 09:15:48 AM
#2
Is maybe that I "simply" sign the transaction with my private key (which would allow anybody who knows my public key to verify that I am the true sender of the transaction)? But in this case, how could the system "read" the transaction if it's encrypted and it cannot read it without my private key?

Thats how it works, they can decrypt it using your public key.
hero member
Activity: 593
Merit: 505
Wherever I may roam
May 22, 2013, 09:09:17 AM
#1
Hi everybody!

Even if I am studying studying studying Bitcoin and how the transaction work, there is something I still cannot grasp and hope someone here will help me.

The scenario is: I have 20 BTC in my wallet (let's say is a public address starting with 1fed..). I need to send 5 BTC to my famous friend Bob, whose address is 1bob..

What I understood is that the transaction will have two outputs, one of 5 BTC to 1bob.. and one of 15 BTC that will come back to me. That creates me a problem: I understood that, sending BTC to someone, I sign the transaction with my private key which is associated with my public key (my address).

But this seems to me wrong because, revealing to the system my private key, the second output of 15 BTC can't go to the address from which the transaction originated (1fed..).

So I guess I am wrong in one of the following two assertions:
1) I sign the transaction with my private key
2) the second output goes back to the originating address

Can anybody explain to me which is wrong and why?
Is maybe that I "simply" sign the transaction with my private key (which would allow anybody who knows my public key to verify that I am the true sender of the transaction)? But in this case, how could the system "read" the transaction if it's encrypted and it cannot read it without my private key?

Thanks a lot guys for any input.

Jump to: