How is a tx in a block displayed? And Segwit Question.

[?QuestionMark?]

Hi

Is a tx in a block just displayed as a txid or is the whole tx displayed (like: decoderawtransction HEX)?

Because I recently watched a video about SegWit and I learned that SegWit takes away the witness data and puts it in a additional block.

So why not just storing the txid, since the txid is stored in the mempool?

Is this just for security reasons in case someone hasn't a txid which is in a block but not in his mempool?

And when a node doesnt support segwit, how can he validate and accept a block when is bitcoin core version rejects the additional segwit block and the witness data is missing?

Thanks for your replies.

[1713965204]

1713965204

[1713965204]

1713965204

[1713965204]

1713965204

[ABCbits]

Is a tx in a block just displayed as a txid or is the whole tx displayed (like: decoderawtransction HEX)?

If you actually meant stored (rather than displayed), the answer is the block contain whole tx.

But to send block between nodes, usually compact block is used to save bandwidth/fasten verification time since the node already have most/all transaction on it's mempool and node can simply ask another node for missing transaction.

More info, https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/

Because I recently watched a video about SegWit and I learned that SegWit takes away the witness data and puts it in a additional block.

I think they're using the term incorrectly.

And when a node doesnt support segwit, how can he validate and accept a block when is bitcoin core version rejects the additional segwit block and the witness data is missing?

Node which support SegWit will send block without witness data and older node will see SegWit input as "anyone-can-see" "anyone-can-spend" script.

[?QuestionMark?]

Thanks for your fast answer.

It answers all my question.

Can you tell me more about / explain "anyone-can-see" script. Or do you have material where I could read more about it.

[pooya87]

Think of it as new nodes dumbing down the blocks for old not-upgraded nodes so that they can still operate without having to upgrade. Otherwise it is not really anyone-can-spend, it is dumbed down so that the old nodes think that way.

It is the same process as any other upgrade that bitcoin received although they didn't need dumbing down but the old nodes couldn't verify those either and they could be considered "anyone-can-spend" in the same way.
For instance when P2SH was added many years ago, an old node would simply see a bunch of data pushed in signature script and a simple hash and equality check in pubkey script without doing anything else (that includes signature verification most of the times). Same with 2 new OP codes that replaced OP_NOPs (OP_CSV and OP_CLTV), old nodes can not evaluate these.

[ranochigo]

Is a tx in a block just displayed as a txid or is the whole tx displayed (like: decoderawtransction HEX)?

I think this has been elaborated sufficiently. Just want to add that the ordering of the transactions is also determined by the merkle root.

So why not just storing the txid, since the txid is stored in the mempool?

Is this just for security reasons in case someone hasn't a txid which is in a block but not in his mempool?

Mempool is just the intermediate holding space for transactions which have yet to be included in the block. Transactions are always removed when they are included in a block. The transactions are only concrete with the POW when a block has been mined which includes the transactions. If it doesn't get included in a block, then it won't be in the blockchain.

And when a node doesnt support segwit, how can he validate and accept a block when is bitcoin core version rejects the additional segwit block and the witness data is missing?

From my understanding, I consider older nodes which cannot validate Segwit transactions akin to an SPV wallet. They cannot validate that a segwit transaction is valid but they will always follow the longest POW chain difficulty-wise.

[BrewMaster]

From my understanding, I consider older nodes which cannot validate Segwit transactions akin to an SPV wallet. They cannot validate that a segwit transaction is valid but they will always follow the longest POW chain difficulty-wise.

there need to be a good term describing this types of nodes that are too old now. they still have a UTXO set and validate that too which is something SPV clients will never do. there is also a lot of other checks such as script evaluations and validation of a lot of other consensus rules.

[ranochigo]

there need to be a good term describing this types of nodes that are too old now. they still have a UTXO set and validate that too which is something SPV clients will never do. there is also a lot of other checks such as script evaluations and validation of a lot of other consensus rules.

I don't think they are the same as SPV clients but they are similar to a certain extent, obsolete client would be a good word. There is no need for fancy naming because no one should be running those in the first place.

They can do many things that SPV can't, privacy-wise, and to some extent on it's security. But I think we can all agree that with their inability to validate segwit signatures in a block, they are kind of similar.

[?QuestionMark?]

Think of it as new nodes dumbing down the blocks for old not-upgraded nodes so that they can still operate without having to upgrade. Otherwise it is not really anyone-can-spend, it is dumbed down so that the old nodes think that way.

Thanks, now I get It even better. But why isn't Bitcoin Core designed to reject peers which run an old node after some time? Because isn't changing the block for a older node not more work. As far as I know Segwit got implemented somewhere in 2017. I think after 3-4 years its time to upgrade. I know that it would lead in an hardfork, but I don't know how many people are running still an old version and how big the consequences of that hard fork would be. I also know Is that the network needed support from 95% from the miners for segwit which they got. When I take a look at the 50 recently mined block there isn't any block with a size of just MB. Always about 1.2-1.4MB. (Except does who mine blocks just with the coinbase tx)

[ranochigo]

Thanks, now I get It even better. But why isn't Bitcoin Core designed to reject peers which run an old node after some time? Because isn't changing the block for a older node not more work. As far as I know Segwit got implemented somewhere in 2017. I think after 3-4 years its time to upgrade. I know that it would lead in an hardfork, but I don't know how many people are running still an old version and how big the consequences of that hard fork would be. I also know Is that the network needed support from 95% from the miners for segwit which they got. When I take a look at the 50 recently mined block there isn't any block with a size of just MB. Always about 1.2-1.4MB. (Except does who mine blocks just with the coinbase tx)

Honestly, one of the reasons why they decided to pursue Segwit was that it allows for the network to be soft forked so that older clients could be compatible as well. A hard fork like a sudden block size increase would result in everyone having to upgrade before it can start producing bigger blocks. Having to reject older peers wouldn't really benefit or harm the network and would just result in a portion of the network being disconnected from the rest.

I don't see the rationale in refusing connections just because they are running an older version. The incentive for them to upgrade is there and it allows them to upgrade at their own convenient time.