Diving into transaction structure

Hey, I'm trying to wrap my head around the technical side of transactions, and I figured I should kick things off with transaction structure. But as I've been studying, I've hit a few bumps and have some questions that I'm hoping someone can help me with. Not sure if I can upload images here to clarify my points, but here goes: 1. What are those two-byte markers and the flag at the start of a Segwit transaction, and why are they always 00, 01? 2. In a typical transaction, what does the sequence number field actually mean? And what's the usual value used today for fee activation? 3. How come a transaction can have the nLocktime field set to a future block height but still have inputs with sequence = 0xFFFFFFFF?

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. 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. 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?

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

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.

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.

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. Lock time (learnmeabitcoin.com)

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

In legacy and Segwit transactions, you have this: Which is verified in this way: In Schnorr signatures, it is replaced with this: Which is verified in this way: 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: And the same on public keys: 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

Can someone help explain why taproot script -path  spends include and annex field on the sign sighash preimage even though it’s usually empty, and also under what conditions an annex will be non empty in practice?

It is needed for future upgrades. It may be filled in a new version, now it is just empty.

I did not give you information that you can use learnmeabitcoin.com website for learning Bitcoin transaction structure too. This following page and Hongchao's note I shared previously can have this and that helpful learning information for you. https://learnmeabitcoin.com/technical/transaction/#structure

Yes I’ve actually gone through it but I think I prefer asking questions here because answers are concise and straightforward while Learnmeabitcoin sometimes attach links that take me to a broader page that explains another aspect that I'm not really interested in at that moment. But it’s g good recommendations though.