3

I understand how asymmetric cryptosystems and digital signatures work:

You generate a (private key, public key) pair. You never share the private key, you make the public key ... well, public.

You have a set of functions:

  • encrypt(public key, plain text) = cipher text
  • decrypt(private key, cipher text) = plain text
  • sign(private key, plain text) = signed text
  • verify_signature(public key, signed text) = is_signature_valid_bool

However, in Bitcoin, the addresses are hashed versions of the public key. There is no way to "undo" the hashing. Hence I'm uncertain how transactions are verified.

I guess the question then is what is actually transferred to whom / stored, when I want to make a transaction. I assumed:

  • Input Bitcoin addresses
  • Output Bitcoin addresses
  • Signature of the transaction with all input address private keys (I guess in order of the inputs)

... but then I don't see how the validation is done. So I assume you sent your public key(s) when you create a transaction. This would explain why you shouldn't use any address again after you spent money from it. The point that confuses me is that I don't see any public keys here

The next unclear thing is the order. Is there an implicit order in which the signatures have to be applied? I assumed this would be done with Script, but I don't see this in the block explorer.

Can somebody shed some light on it?

Non-Answers

2 Answers 2

7

When you spend from a Bitcoin address, your transaction includes both the public key corresponding to the hashed address you're trying to spend from, as well as a signature that can be verified with that public key.

Your link is to a block, which is not signed itself. However, let's look at a transaction from your block: https://www.blockchain.com/btc/tx/b8f925d09c647904e428d902c8404fc91e5dbe53773b82d717cf13374785ca20

Scroll down to 'inputs', and under Sigscript, 3045022100c89735ddbb5e231044610590c086d41f1e871067987087ed48e041f8999314830220011deba08ad9a67ddafe51dc530f3f60c8974373bf2f25953a89c139d238216201 is the ECDSA signature, and 023aa5b3f24a2b8fc8f64b69ba383b148892deef94cf060288cc99e81be0f9722e is the public key corresponding to the address.

4

A bitcoin transaction will create outputs, which can later be used as input to a new transaction. Each output will be locked to what is called a scriptpubkey, which basically sets up the cryptographic puzzle that must be satisfied (ie, return true when run) in order for those coins to be spent. Any transaction spending those coins will need to provide a scriptsig (unlocking script) that satisfies this puzzle.

So for example, when creating a transaction that pays to a 'pay-to-public-key-hash' (P2PKH) bitcoin address, the pubkey related to the address will not be known to the network. But when this output is later used as an input to a new transaction, the scriptsig that unlocks those coins would include the pubkey, alongside a valid signature, and thus network nodes will be able to verify that the rightful owner of those coins is making the spend (by hashing the provided pubkey, and verifying that the hash output matches the bitcoin address the coins are locked to).


As for the ordering of signatures, here are a few questions/answers with some good details:

What exactly is hashed and signed in a segwit transaction

Redeeming a raw transaction step by step example required

How to redeem a basic Tx?

How to sign a SegWit transaction via NBitcoin?

What is the signature digest for Segwit outputs


Other relevant Qs I found:

How do Scripts work?

What is relation between scriptSig and scriptPubKey?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.