Welcome to the discussion about this section. Here you can ask questions or post feedback about this specific lecture.
no question - it makes perfect sense to me!!!
Thankyou
@filip I have a question regarding the private key signature. At the point OP_CHECKSIG checks the public key + the private key signature and validates, aren’t these values public in the network now? I would think someone else could just use the same unlocking script for other UTXO’s of the same public key, but of course this isn’t the case. So how does it work with the private key signature, is it exclusive to that specific UTXO and will not work anywhere else? How is that signature created?
EDIT: Sorry for pesking you before googling Filip, I’ve found my answer in the first link I opened http://learnmeabitcoin.com/guide/digital_signatures
There’s a nice short summary in the bottom, I’ll leave it here if someone else gets the same question:
How do digital signatures work?
- You combine the
private key
+transaction data
, and use some mathematics to create a digital signature .- You can then take the digital signature +
transaction data
+public key
, do some more mathematics with them, and the result will confirm whether a legitimate private key was used to create the digital signature.Because remember, the goal of a digital signature is to prove that you’re the owner of a public key .
Exactly! I’m glad you googled, great! That’s exactly why it works.
@filip some feedback about the quiz which is a bit confusing (no dedicated link for that, so putting it here).
- Q3 What format are serialized bitcoin transactions?
I think, binary
is the correct answer. Whereas hexadecimal
(aka base16) is just a human readable representation/encoding of binary (for humans and for JSON). That same data could be encoded in base64, base58 or any other way.
If “bitcoin transaction JSON” was implicitly meant, it would be nice to have such hint in a question.
- Why do we serialize bitcoin transactions? (Multiple Choice)
Doesn’t bitcoin core compute hashes over a binary representation?
Why is “to encrypt” answer invalid?
P.S. I know that you do not have to binary serialize something to encrypt it. But you don’t have to do so to transmit it either (generally speaking).
That might be opinionated but I’d like to understand your reasoning behind the selected etalon answers.
Thanks. I do not agree on all of your points, but I will be happy to clarify.
On your first point. I do not agree with you, because every format in computers overall could be referred to as binary. That doesn’t mean abstractions of that format don’t exist or are non-important. ASCII is also in the end just binary, that doesn’t mean we should rename ASCII to binary. Bitcoin transactions are serialized to base16, not base10, not base2.
On your second point. To encrypt something is (depending on which definition you pick) basically converting or serializing something for the purpose of preventing access to that information. If that purpose doesn’t exist, to me it’s just a conversion between number formats or any other type of serialization. To summarize, serialization is part of encryption. But they are not the same.
I’m not sure exactly how bitcoin core computes hashes. It doesn’t change the answer as to why we serialize them. But depending on how you look at it, all hash functions operate on binary representations. Because that’s how all code is executed.
@filip, thanks for the discussion. I guess I’ve been over-thinking a bit with that “binary VS. hexadecimal” stuff. Still, I hope our little discussion would help you making the quiz and the course content even better.
My reasoning was “a serialized transaction is a structure mapped on the memory, so it’s binary”. Meaning, the correct answer would be
Serialized bitcoin transactions are binary
In hexadecimal base16 encoding within the JSON payload.
Actually I’ve understood your reasoning and I agree that it can be simplified to “hexadecimal”.
P.S. I think the transaction data is encoded in hexadecimap (base16) because
- It’s human readable for computer scientists
- It is used within JSON payloads printed by
bitcoin-cli
- As far as I remember, JSON-rpc is used to exchange this data between
bitcoind
andbitcoin-cli
@filip, I also wonder your opinion and point of view on
What format are NON-serialized bitcoin transactions?
To me it’s something like a class definition or a DB schema definition. Meaning, an entity which contains
- List inputs
- List<UTXOoutputs
- byte[] scriptOpcodes
- ect.
In case we are on the same page in this aspect, then I agree that in order to both encrypt, persist on disk and send over the network this data must be serialized.
all hash functions operate on binary representations. Because that’s how all code is executed.
That also depends on the point of view, really.
Obviously, you can calculate the hash both for
- binary layout of transaction bytes (one for which you were drawing the color diagrams in the presentation)
- Bytes of the ASCII string from JSON (same data but encoded in base16)
If simplified, we are talking about “left” and “right” sides of a hex editor like this one for the same data https://hexed.it/
Well, it’s a weird way to reason. Because with your reasoning all data structures should just be called binary, since basically all data is mapped in memory. I maybe I just misunderstood you, but does not seem reasonable to me.
In regards to your second comment about NON-serialized tx. That is not a question in the quiz, just to clarify. I’m not sure what the exact data structure is, it would depend on the implementation of bitcoin.
Well, it’s a weird way to reason.
I maybe I just misunderstood you, but does not seem reasonable to me.
Ok. I respect your opinion
In regards to your second comment about NON-serialized tx. That is not a question in the quiz, just to clarify. I’m not sure what the exact data structure is, it would depend on the implementation of bitcoin.
I know it’s not in a quiz. Just wanted to understand your mental model better.
Thanks for a helpful reply.
I maybe I just misunderstood you
This is definitely the case. From my point of view,
We are on the same page.
Just formulating slightly differently
due to different background
and thus different way of thinking.
So further discussion wouldn’t be as productive, I guess.
Thanks for your patience and for great content.
Great videos Filip! I had a question about the public key hash:
Why was it necessary in the design of Bitcoin to include the public key as part of the unlocking/locking script? Wouldn’t it just be enough to include the tx ID and the signature to verify that you own the tx?
I had another but believe I found the answer for it below. The question was: Why utxo is sent to the hash of the public key rather than just using the public key itself?
It seems like it’s to reduce the size of the public key, and Satoshi either didn’t know about short form public keys or wasn’t comfortable using them.
source: https://bitcoin.stackexchange.com/questions/3600/why-are-bitcoin-addresses-hashes-of-public-keys
Thanks!
Thank you! Good questions.
Why was it necessary in the design of Bitcoin to include the public key as part of the unlocking/locking script?
Because you can’t validate the signature without the public key. You need 3 things to verify a signed message. You need the message (the tx in this case), the signature, and the public key.
On the second question you are correct. The pubkey hash takes up less space then the entire pub key.
Enjoying the course - nice vids Filip!
If anyone else is wondering how to view the transaction data in the same format as presented in the video:
# start bitcoind in regtest mode:
bitcoind -regtest
# In another terminal, get the raw transaction:
bitcoin-cli -regtest getrawtransaction 6d2808d5544748c63de8a32ca96741a5ad11922f3adf827fc3568a785e64c3ea
# Decode to view full transaction data - $RAW is output of above:
bitcoin-cli -regtest decoderawtransaction $RAW
On a *nix system you can do this at the shell prompt:
RAW=$(bitcoin-cli -regtest getrawtransaction 6d2808d5544748c63de8a32ca96741a5ad11922f3adf827fc3568a785e64c3ea)
bitcoin-cli -regtest decoderawtransaction $RAW | jq
The bitcoin-cli gettransaction
method does not return the same info, and it’s nice to follow along with the examples in the video.
Which format are you talking about?
The one displayed at the start of the “Unlocking Script” video.
Ok. I’m not sure how to get that from bitcoin-clil. The easiest way I’ve found is to look at the tx through a block explorer or use their APIs. Depending on which block explorer you use the structure can vary. But here is one example.
https://blockchain.info/rawtx/462f279a402ce135532b1ed899caaa07a7dc7ca7ca430619088a215f7fe9ef4a
This is the URL to the transacion on blockchain.info which is used in the course https://www.blockchain.com/nl/btc/tx/d084830f0b8cfadc340b0575fe4543979cd1900e8a3ade9a045b94070f848a49
I noticed a typo in Serialization quiz. In the second question: “What is Serialization?” the answer is spelled: “storage och transmission”. It should probably be or instead of och.
Thank you! I have updated it. Och is actually and in swedish