Understanding transaction structure

[hmbdofficial]

Hi trying to understand the technical part of the transactions and it was necessary that I start with the transactions structure but during the course of studying I got some questions I wasn’t really clear with. and I believe I could get some help here I don’t know if I could upload images to make my questions clearer
1. what are the two bytes makers and flag that is always put at the beginning of a Segwit transaction and why are they always 00, 01?
2. In a standard transaction what does the sequence number field represent? And what value is commonly use today to enable by fee?
3.why can a transaction with nLocktime field set to a feature block height still have inputs with sequence  =0xFFFFFFFF?

[stwenhao]

what are the two bytes makers and flag that is always put at the beginning of a Segwit transaction and why are they always 00, 01?

It simply means "zero inputs, one output" in the old format. And then, old decoders mark it as invalid, if some transaction has zero inputs.

So, the first zero is needed, to simply crash the old decoders, because there is a format they cannot fully understand. Which means, that if the new format is accidentally passed to the old decoders, then it will crash. All old decoders should receive a transaction without any witness, in the old format.

And later, the "01" is just the version of the encoding, which is set to one, and can be incremented in the future, if needed.

In a standard transaction what does the sequence number field represent?

The number of replacement. In a naive implementation, where transaction version was below 0x00000002, you could start from 0x00000000, then make it 0x00000001, and replace some transaction 2^32 times. In transaction versions equal or greater than 0x00000002, this field is used by BIP-68.

why can a transaction with nLocktime field set to a feature block height still have inputs with sequence  =0xFFFFFFFF?

Because when all inputs have sequence equal to 0xffffffff, then locktime is ignored, and can be set to anything.

[hmbdofficial]

what are the two bytes makers and flag that is always put at the beginning of a Segwit transaction and why are they always 00, 01?

It simply means "zero inputs, one output" in the old format. And then, old decoders mark it as invalid, if some transaction has zero inputs.

So, the first zero is needed, to simply crash the old decoders, because there is a format they cannot fully understand. Which means, that if the new format is accidentally passed to the old decoders, then it will crash. All old decoders should receive a transaction without any witness, in the old format.

And later, the "01" is just the version of the encoding, which is set to one, and can be incremented in the future, if needed.

In a standard transaction what does the sequence number field represent?

The number of replacement. In a naive implementation, where transaction version was below 0x00000002, you could start from 0x00000000, then make it 0x00000001, and replace some transaction 2^32 times. In transaction versions equal or greater than 0x00000002, this field is used by BIP-68.

why can a transaction with nLocktime field set to a feature block height still have inputs with sequence  =0xFFFFFFFF?

Because when all inputs have sequence equal to 0xffffffff, then locktime is ignored, and can be set to anything.

Sorry  just needed to add this to my question I’m just curious to know what is actually placed in the scriptsig field of a transaction with a pay to witness public key hash (P2WPKH) input in Segwit transaction?

[stwenhao]

what is actually placed in the scriptsig field of a transaction with a pay to witness public key hash (P2WPKH) input in Segwit transaction?

Nothing. Because from the legacy perspective, Segwit is just some push on the stack, so nothing is needed in legacy part of scriptSig for Segwit inputs. Which is also why changing witness data does not change transaction ID, because it is calculated only from legacy parts, to make things compatible with the old nodes.

[hmbdofficial]

what is actually placed in the scriptsig field of a transaction with a pay to witness public key hash (P2WPKH) input in Segwit transaction?

Nothing. Because from the legacy perspective, Segwit is just some push on the stack, so nothing is needed in legacy part of scriptSig for Segwit inputs. Which is also why changing witness data does not change transaction ID, because it is calculated only from legacy parts, to make things compatible with the old nodes.

I get it now..and if I get your explanation right which you say “changing witness data does not change transaction ID” because it is calculated from the legacy part with nothing on the scriptsig field for Segwit transaction is actually what fixes  transaction malleability right because the signature i.e the witness is not part of the transaction ID again

[Mia Chloe]

~snip

Nice question I must say. I can barely remember but I think In Bitcoin SegWit BIP141 the marker 0x00 and flag 0x01 appear after the version field because 0x00 is an invalid legacy input count. while 0x01 indicates the presence of witness data and is fixed by consensus.

The nSequence field before now actually controlled replacement and today is mainly used for Replace By Fee and BIP68 where any value 0xFFFFFFFE opts into RBF and 0xFFFFFFFF marks an input as final. However a transaction can actually set nLockTime to a future block height and yet still use nSequence = 0xFFFFFFFF because  locktime is only enforced when at least one input has a non final sequence if not  the locktime field is just ignored.

[hmbdofficial]

I actually created this tread to be my reference point of my technical journey as though I will be asking more questions as I move on with my technical learning.  I hope I’m not breaking any rule here. And I will be more glad to get straight forward explanations with simplest term.

Q. So today I read about transaction layer cryptography and I was wondering how the Schnorr signature (BIP 340) used in the taproot changes the witness data as compared to the ECDSA signatures used in legacy and Segwit transactions.

[hd49728]

Hi trying to understand the technical part of the transactions and it was necessary that I start with the transactions structure

I can not explain things in your questions for you as I am not too technical but this note of Hongchao on Anatomy of Bitcoin's Raw Transactions can help you, I really hope so.

I see that the note has information on Segwit transaction, Lock time so I guess it can help answering your curious questions.

The following byte 01 represents the number of transaction inputs, which means that this particular transaction contains exactly one transaction input.

The following byte 02 represents the number of transaction outputs. As the number suggests, there are two outputs in this particular transaction.

e3b50700 is the locktime of the transaction, which dictates the block number or timestamp until which the transaction is locked.

Lock time (learnmeabitcoin.com)

[hmbdofficial]

I actually created this tread to be my reference point of my technical journey as though I will be asking more questions as I move on with my technical learning.  I hope I’m not breaking any rule here. And I will be more glad to get straight forward explanations with simplest term.

Q. So today I read about transaction layer cryptography and I was wondering how the Schnorr signature (BIP 340) used in the taproot changes the witness data as compared to the ECDSA signatures used in legacy and Segwit transactions.

Pls I’ve not gotten any response to this question I asked

[stwenhao]

how the Schnorr signature (BIP 340) used in the taproot changes the witness data as compared to the ECDSA signatures used in legacy and Segwit transactions

In legacy and Segwit transactions, you have this:

Code:

s=(z+rd)/k
s //signature
z //hashed message (not txid)
r //signature public key (x-value of that)
d //private key
k //signature private key

Which is verified in this way:

Code:

s=(z+rd)/k
sk=z+rd
k=(z/s)+(r/s)d
R=(z/s)G+(r/s)Q
R //signature public key //R=k*G
G //secp256k1 generator
Q //public key //Q=d*G

In Schnorr signatures, it is replaced with this:

Code:

s=k+ed
s //signature
k //signature private key
e //hash of (R,Q,z) (z-value is not txid)
d //private key

Which is verified in this way:

Code:

s=k+ed
k=s-ed
R=sG-eQ
R //signature public key //R=k*G
G //secp256k1 generator
Q //public key //Q=d*G

Also, because e-value is a hash of (R,Q,z) tuple, public key recovery from legacy ECDSA cannot be applied here.

So, to sum up, you have the same secp256k1, defined in exactly the same way, but you have just some different operations on the same curve, which allows combining signatures easier. For example:

Code:

s=k+ed
s1=k1+e*d1
s2=k2+e*d2
(s1+s2)=(k1+k2)+e*(d1+d2)

And the same on public keys:

Code:

sG=R+eQ
s1*G=R1+e*Q1
s2*G=R2+e*Q2
s1*G+s2*G=R1+R2+e*Q1+e*Q2
(s1+s2)*G=(R1+R2)+e*(Q1+Q2)

For many people, it looks complicated, but you can start with some smaller elliptic curves, than secp256k1, and then, if you will understand it on some small numbers, for example where some curve uses p=79, n=67, and y^2=x^3+7 equation, then for bigger numbers, the same rules apply: there are just more computations, so breaking it is harder, because of that.

But for some smaller elliptic curves, you can easily brute-force everything, and see, how it is calculated.

You can try to make ECDSA signatures, and Schnorr signatures on these smaller curves first, before trying secp256k1: https://bitcointalk.org/index.php?topic=5459153.0