Bitcoin Forum
December 04, 2016, 02:03:38 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Is hash of receiver's public key in transaction?  (Read 607 times)
eschaefer
Newbie
*
Offline Offline

Activity: 5


View Profile
February 03, 2012, 07:30:17 PM
 #1

Let’s say that in transaction-1, Alice got 100 BTC. In transaction-2, Alice wants to give Bob 80 BTC and herself 20 BTC (for simplicity, we’ll ignore transaction fees). Will the hash of Bob’s public key be included in (the output for) transaction-2?
(I know Alice's will.)

If not, why can’t Eve create a transaction-3 where she gives Frank 80 BTC with i) the hash of transaction-2, ii) the hash of Eve’s public key and iii) Eve’s signature on the hash of the (simplified) transaction-3, iv) an index pointing to the value 80 in transcation-2?

Thanks.
1480817018
Hero Member
*
Offline Offline

Posts: 1480817018

View Profile Personal Message (Offline)

Ignore
1480817018
Reply with quote  #2

1480817018
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480817018
Hero Member
*
Offline Offline

Posts: 1480817018

View Profile Personal Message (Offline)

Ignore
1480817018
Reply with quote  #2

1480817018
Report to moderator
1480817018
Hero Member
*
Offline Offline

Posts: 1480817018

View Profile Personal Message (Offline)

Ignore
1480817018
Reply with quote  #2

1480817018
Report to moderator
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 03, 2012, 08:08:56 PM
 #2

No.

To your second question that would be called a double spend.  Nodes will invalidate an unconfirmed transaction which has same inputs as a transaction they are already aware of.  They will also refuse to broadcast that transaction to other nodes.

If some portion of the network has one transaction using a set of inputs and another portion of the network has a different transaction with  the same set of inputs a double spend has occurred.

One can protect themselves from double spends by waiting until the transaction is confirmed.  The "split" in the network will be resolved once one of the transactions is hashed into the next block.  Only one of them can join the blockchain the other is lost.  All clients will remove the "lost" transaction and accept the transaction in the blockchain as canonical.
eschaefer
Newbie
*
Offline Offline

Activity: 5


View Profile
February 03, 2012, 10:12:56 PM
 #3

Thank you DeathAndTaxes for the response. Bob might not try to give the 80BTC to anyone for months. Eve might post her fraudulent transaction immediately. It seems Eve's would then be accepted (unless Bob's software tells him that someone else is trying to spend his 80BTC).

And if Bob and Eve did both send new transactions almost simultaneously and the nodes notice the double-spend, then how can Bob (aliased by his public key) ever convince the network that he is the proper owner?
Cheers, Ed
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 03, 2012, 10:25:59 PM
 #4

Thank you DeathAndTaxes for the response. Bob might not try to give the 80BTC to anyone for months. Eve might post her fraudulent transaction immediately. It seems Eve's would then be accepted (unless Bob's software tells him that someone else is trying to spend his 80BTC).

And if Bob and Eve did both send new transactions almost simultaneously and the nodes notice the double-spend, then how can Bob (aliased by his public key) ever convince the network that he is the proper owner?
Cheers, Ed

I misunderstood your first post and thus answered a question not asked likely adding confusion.


A transaction contains the outputs of the prior transaction.  You must have the private key that corresponds to those outputs to transfer them.

So
Alice -> Bob.  To spend Bob uses this output and signs it w/ his private key (only he has).
Alice -> Bob.  Eve can't spend because to include this output she would need Bob's private key.   Time doesn't matter.  She will never be able to create a valid transaction from this input.

The output of that transaction is Bob's ADDRESS (which yes is a hash (along with error checking & meta data of the public key but not the public key itself).  To spend Bob includes his public key, the prior transaction output, the new destination, amount ,etc and signs everything w/ his private key.  

With the public key they can reconstruct the prior output's address.
With the public key they can verify the signature.

This ensures other nodes can:
a) verify this output hasn't been used before  (prevent double spend)
b) this transaction is signed by the right private key (ensure only owner can transfer).

Now "a" is only partially complete because no node can know it has seen all transactions.  "a" is "solved" once it has been hashed into a block making a canonical record of the transaction preventing those outputs from being used again (well baring 51% attack).


eschaefer
Newbie
*
Offline Offline

Activity: 5


View Profile
February 04, 2012, 12:32:52 AM
 #5

Thanks again DeathAndTaxes for your answer (and patience). I want to double-check that I'm understanding.

When you wrote: Alice -> Bob you mean that Alice transferred BTC to Bob?

You wrote: "Alice -> Bob. To spend Bob uses this output".
When he spends, you are talking about a later transaction from Bob to Carol (of BTC Bob got from Alice).

When you wrote "the new destination" that would be the hash of Carol's public key?
So in the transaction from Bob -> Carol, the hash of Bob's public key (in the input) and the hash of Carol's public key (in the output) are included?

So the transaction from Bob to Carol contains 1) The Alice->Bob output, 2) hash(Bob's public key), 3) the amount ,4) hash(Carol's public key) (the destination), 5) Bob's signature on 1) - 4)?

I'll be teaching this in my cryptography course in a few weeks, which is why I am trying to get understanding and grateful for the help.

Thanks, Ed
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 04, 2012, 12:50:31 AM
 #6

Quote
So the transaction from Bob to Carol contains 1) The Alice->Bob output, 2) hash(Bob's public key), 3) the amount ,4) hash(Carol's public key) Carol's address (the destination), 5) Bob's signature on 1) - 4)?

Part 1)
You are correct but just for clarification we call this the INPUT of the Bob -> Carol transaction.  The input of every transaction is the output of a prior transaction(s).  The only exception to that is a coinbase transaction (where new coins are minted).
(yes I am using -> to indicate transfer to).

Part 2)
It isn't the hash of Bob's public key but his actual public key.  That is necessary because Part 1 (the output) Contains Bob's address so we need Bob's public key.  Other nodes can use the public key to reconstruct the address in the input.  They use the signature to ensure it was Bob who created this transaction.

Part 5)
We say Carol's address because it isn't just the hash of the public key.  The address is derived from the public key by hashing but it is a multi step progress.  It contains meta data and a checksum to prevent accidentally sending funds to "nowhere".

Also I would recommend reading Satoshi's paper I likely am leaving something out, or abstracting too much.
http://bitcoin.org/bitcoin.pdf
eschaefer
Newbie
*
Offline Offline

Activity: 5


View Profile
February 04, 2012, 08:32:02 PM
 #7

Dear DeathAndTaxes. It is 100% clear to me now. I am extremely grateful to you (as will be my students). It all makes sense now. I did read the original white paper, but did not find it completely clear what is in a transaction (for example in Satoshi's paper he shows Carol's public key getting hashed with the previous transaction). Cheers and over and out, Ed
Pages: [1]
  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!