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.