Bitcoin Forum
May 02, 2024, 01:03:20 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Trying to understand Bitcoin original paper, Transaction section  (Read 91 times)
Aymeric75 (OP)
Newbie
*
Offline Offline

Activity: 8
Merit: 5


View Profile
January 23, 2024, 08:03:06 AM
Last edit: January 23, 2024, 10:35:57 AM by Aymeric75
Merited by ABCbits (4), bitmover (1)
 #1

Hi,


In BTC paper, "Transaction" section.

https://i.ibb.co/6rkP4Pk/Sans-titre.png

What I understand from this schema is:

- Agent 2 uses a hash function with inputs: the previous message (1) and its own public key (2), the output is the "signature" of the previous agent (agent 1) (3)

- At the same time, agent 1 uses its private key to "sign" (4) its own signature that was generated by agent 2 (I must have missed something here)

- Also, agent 1 can verify its own signature (5)... it does not makes sense to me either


Thanks for your help

1714611800
Hero Member
*
Offline Offline

Posts: 1714611800

View Profile Personal Message (Offline)

Ignore
1714611800
Reply with quote  #2

1714611800
Report to moderator
The forum strives to allow free discussion of any ideas. All policies are built around this principle. This doesn't mean you can post garbage, though: posts should actually contain ideas, and these ideas should be argued reasonably.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
ABCbits
Legendary
*
Offline Offline

Activity: 2856
Merit: 7436


Crypto Swap Exchange


View Profile
January 23, 2024, 10:24:05 AM
Merited by hosseinimr93 (2), bitmover (1), WatChe (1)
 #2

Learning Bitcoin technical detail from whitepaper isn't best idea. I'd suggest to use easier learning resource such as https://learnmeabitcoin.com/technical/.

- Agent 2 uses a hash function with inputs: the previous message (1) and its own public key (2), the output is the "signature" of the previous agent (agent 1) (3)

Owner 2 doesn't do anything on 2nd transaction. Owner 1 use hash of 1st transaction (1) and specify that he want to send Bitcoin to owner 2 (2).

- At the same time, agent 1 uses its private key to "sign" (4) its own signature that was generated by agent 2 (I must have missed something here)

Actually 2nd transaction means owner 1 send Bitcoin to owner 2.

- Also, agent 1 can verify its own signature (5)... it does not makes sense to me either

IIRC it actually means anyone can use owner's 1 public key to verify whether owner's 1 signature is valid or not.

p.s.: I used the "img" tag wrongly I think, I did this:   [ img  ]url_of_image [  / img], if any knows how to correct this..

1. You need to use raw image link such as https://i.ibb.co/6rkP4Pk/Sans-titre.png (not https://ibb.co/Xjqszsq).
2. If you use img tag as newbie, this forum simply show the image url.

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
Aymeric75 (OP)
Newbie
*
Offline Offline

Activity: 8
Merit: 5


View Profile
January 23, 2024, 10:42:21 AM
 #3

Learning Bitcoin technical detail from whitepaper isn't best idea. I'd suggest to use easier learning resource such as https://learnmeabitcoin.com/technical/.

- Agent 2 uses a hash function with inputs: the previous message (1) and its own public key (2), the output is the "signature" of the previous agent (agent 1) (3)

Owner 2 doesn't do anything on 2nd transaction. Owner 1 use hash of 1st transaction (1) and specify that he want to send Bitcoin to owner 2 (2).

- At the same time, agent 1 uses its private key to "sign" (4) its own signature that was generated by agent 2 (I must have missed something here)

Actually 2nd transaction means owner 1 send Bitcoin to owner 2.

- Also, agent 1 can verify its own signature (5)... it does not makes sense to me either

IIRC it actually means anyone can use owner's 1 public key to verify whether owner's 1 signature is valid or not.

p.s.: I used the "img" tag wrongly I think, I did this:   [ img  ]url_of_image [  / img], if any knows how to correct this..

1. You need to use raw image link such as https://i.ibb.co/6rkP4Pk/Sans-titre.png (not https://ibb.co/Xjqszsq).
2. If you use img tag as newbie, this forum simply show the image url.


thanks for the resource.

Regarding the explanations you provided, I still don't get it  Cry

Maybe explaning what each number (in red) corresponds to, would work

I will try the resource you sent anyway
bitmover
Legendary
*
Online Online

Activity: 2296
Merit: 5914


bitcoindata.science


View Profile WWW
January 23, 2024, 12:59:27 PM
 #4



What I understand from this schema is:

- Agent 2 uses a hash function with inputs: the previous message (1) and its own public key (2), the output is the "signature" of the previous agent (agent 1) (3)

- At the same time, agent 1 uses its private key to "sign" (4) its own signature that was generated by agent 2 (I must have missed something here)

- Also, agent 1 can verify its own signature (5)... it does not makes sense to me either

...

Maybe explaning what each number (in red) corresponds to, would work

From what I understand :

1 and 2 is how the transaction HASH is generated (with the owner 2 public key and owner 1 public key + prev hash + signature)

3 is how the signature is generated (which is all you need to spend). Owner 2 never sees the Owner 1 private key, just the owner 1 signature.

4 is how the signature is generated (with the private key and then the signature is sent to owner 2)

5 means that anyone can verify the signature.

I hope other members with more technical knowledge can expand this answer.

.
.BLACKJACK ♠ FUN.
█████████
██████████████
████████████
█████████████████
████████████████▄▄
░█████████████▀░▀▀
██████████████████
░██████████████
████████████████
░██████████████
████████████
███████████████░██
██████████
CRYPTO CASINO &
SPORTS BETTING
▄▄███████▄▄
▄███████████████▄
███████████████████
█████████████████████
███████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████████████
█████████████████████
███████████████████
▀███████████████▀
█████████
.
ranochigo
Legendary
*
Offline Offline

Activity: 2954
Merit: 4165


View Profile
January 23, 2024, 02:42:16 PM
Merited by ABCbits (3)
 #5

Certain things in the whitepaper is quite abstract and can be quite difficult to understand if you aren't very conversant with the public key cryptography. I'd explain it simply and hopefully I'd be able to link it to whatever you've seen.

In each of the transaction, there are quite a few key components and I'll omit those that aren't discussed here. Namely, it would be the previous transaction (as denoted by the transaction ID), the public key that contains the amount of Bitcoins, public key that corresponds to the recipient and the amount that is supposed to be sent to that. In a normal transaction, you would need to prove that you are allowed to spend the coins that you have. Hence, that is the signature that is generated by the spender's public key.

Think of a transaction like this:

Public Key A -> Public Key B
                       Public Key C

Number 1 would be the transaction ID of the previous transaction.
Number 2 would be the public key of the intended recipient (B and C) (as well as the amount).
Number 3 and 4 would involve using the private key of the of the corresponding public key of the previous transaction to sign the entire transaction, thereby producing a signature.

Number 5: On a network level, others want to know if your transaction is indeed valid. Part of the checks would be using the signature to check if the corresponding private key of public key A has signed the transaction. To do so, we need to check if the Public Key A and the signature checks out.

.
.HUGE.
▄██████████▄▄
▄█████████████████▄
▄█████████████████████▄
▄███████████████████████▄
▄█████████████████████████▄
███████▌██▌▐██▐██▐████▄███
████▐██▐████▌██▌██▌██▌██
█████▀███▀███▀▐██▐██▐█████

▀█████████████████████████▀

▀███████████████████████▀

▀█████████████████████▀

▀█████████████████▀

▀██████████▀▀
█▀▀▀▀











█▄▄▄▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.
CASINSPORTSBOOK
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀▀█











▄▄▄▄█
WatChe
Hero Member
*****
Offline Offline

Activity: 896
Merit: 543


View Profile WWW
January 23, 2024, 05:19:36 PM
 #6

Learning Bitcoin technical detail from whitepaper isn't best idea. I'd suggest to use easier learning resource such as https://learnmeabitcoin.com/technical/.

Thanks for sharing this useful resource. I have gone through Bitcoin whitepaper and honestly speaking you can't understand if you don't have proper understanding of how Bitcoin works in the background. That's why it's called Whitepaper since its gives an abstract idea about working of Bitcoin.
DannyHamilton
Legendary
*
Offline Offline

Activity: 3388
Merit: 4612



View Profile
January 23, 2024, 06:57:16 PM
Merited by Cricktor (1)
 #7

You've received several responses, and much of what I'm about to say will probably just be a re-phrasing of what's already been written in this thread.  However, I'll attempt to provide a more complete and detailed explanation if I can.

The first thing you'll need to understand is that the Whitepaper does NOT describe exactly how Bitcoin works.  The whitepaper was released before Satoshi had finished writing the software and provided an overview of one way that proof-of-work, and a chain of signatures could be used to create a digital currency.  Several improvements were made in the final version of the actual software, and this transaction structure therefore changed significantly.

The additional educational resources you've been provided by others (such as learnmeabitcoin) will give a better understanding of how Bitcoin actually works, but may cause additional confusion if you try to apply what you learn there to what you see in the whitepaper.

That all being said, here's my attempt to explain what you're seeing in that image:

Let's start by making it clear that the "transaction" on the left is not a transaction being sent by "Owner 1". It is the transaction whereby "Owner 1" initially received the value that they will be using. "Owner 0" signed that transaction when they created and broadcast it to initially pay "Owner 1" (which is why you see an "Owner 0's signature" in that transaction).

Next, let's go over a brief explanation of public key cryptography, and digital signatures. A person generates a pair of keys. One that they keep secret and secure (the "private" key) and another that they share with others (the "public" key).  The "signature" is a value that is calculated by using some source of data and a private key. A person can use their private key to sign some set of data (generate the signature value using the appropriate calculations). If they then provide the data, the public key, and the signature, then it is possible with another calculation to verify the signature.  In that case, the verifier can perform a calculation using the provided data and the result makes it clear that the ONLY way to have generated the signature value is if 2 things are BOTH true:
  • The data is the EXACT same data that was used by the person that created the signature (if the data changed, then the verification calculation would no longer work).
  • The signature was generated using the private key that is associated with the given public key, meaning that ONLY someone with acess to that private key could have created the signature

When transactions are used for the data, this combination of facts means that anyone with access to the transaction, the public key, and the signature can verify that the transaction they are looking at is definitely the one that was signed (hasn't been modified) and that the signature came from someone that has access to the private key.

At some point in time prior to the image that you provided, "Owner 0" offered to send a transaction to pay "Owner 1". "Owner 1" generated a key pair
 and provided "Owner 0" with the public key, telling "Owner 0" to embed that public key in the transaction. The concept that Satoshi is suggesting in that part of the whitepaper is that we can create a requirement that the ONLY way someone can be allowed to spend value in a given transaction is if they can provide a signature that can be verified with the public key that is embedded in the transaction.

So, "Owner 0" creates the transaction that you see on the left, and they sign it. It has embedded in it the public key provided to "Owner 0" by "Owner 1". This means that the ONLY way to now spend the value in the transaction is if you can provide a signature that can be verified by the public key that is embedded in the transaction. Since "Owner 1" is the person that generated that key-pair, as long as they do a good job of keeping their private key secure, they are the only person in the world that will be able to provide a valid signature.

Now that we understand what the important pieces are of that transaction on the left , let's look at what happens when "Owner 1" needs to pay "Owner 2". It can get very big if every time you create a transaction you need to embed the entire previous transaction in the new transaction so that you have all the necessary pieces to validate.  Instead, Satoshi suggests that we use a digest. A much smaller value that can be trusted to represent the data that is being used. Then, you can go back and look at the original transaction, and compare against it's hash to make sure that you are looking at an accurate representation.

  • "Owner 2" generates a key pair and provides "Owner 1" with the public key, telling "Owner 1" to embed that public key in the transaction that they create.
  • "Owner 1" creates the transaction that you see in the middle column. They embed the public key that was supplied by "Owner 2", and they embed a hash generated from a set of data that includes both that public key (2) and the earlier transaction where they received the value that they are spending (1)
  • "Owner 1" generates a signature of this hash using their private key (4), and include this signature in the transaction that they are creating (3)
  • "Owner 2" (and the rest of the world) are now able to verify (5) that "Owner 1" has the authority to spend the value from the transaction in the first column

The reason that they can all verify this is because they can hash the data in the left transaction (along with "Owner 2" public key from the middle transaction) and compare that to the hash embedded in the middle transaction to prove that neither the data in the left transaction nor the embeded "Owner 2" public key has been altered. They can then use the signature provided in the middle transaction along with the hash and the public key from the first transaction to verify that the signature could ONLY have been calculated by someone that has access to the private key that is associated with the public key in the left transaction, and that the hash in the middle transaction hasn't been altered.

With the signature provided by "Owner 1" in the middle transaction, he has proven that he is has the authority to spend the value he received in the left transaction (verifiable by using the public key from the left transaction)

With "Owner 1" embedding the public key of "Owner 2" in the middle transaction, "Owner 1" has created a requirement that the value from the middle transaction can ONLY be spent by the person that has access to the associated private key.

The hash that is embedded in the middle transaction links the two transactions together, since any change to any of the data in either transaction would result in a different hash. This makes it possible for EVERYONE to verify that the transactions have not been modified/manipulated and that the value from the left transaction is now under the control of the middle transaction.

I'll repeat, THIS IS NOT HOW BITCOIN WORKS.  Some of the concepts and ideas were re-used, and there are some similarities, but there are also some significant differences.



Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!