Some reasons to the causes of bitcoin UTXO?

[348Judah]

Are there some reasons to the causes of UTXO when comparing the bitcoin Legacy address from bitcoin SegWit address

To validate an unspent transaction output of a bitcoin transaction using unlocking script which is also referred to as ScriptSig while in other way, we have the Script PubKey in locking script in which gives the command needed to spending a transaction from the receiver's end, else every unconfirmed transactions are directed to stay on mempool.

In a legacy bitcoin transaction, a Script PubKey set a  combination with that of a ScriptSig in making a unique, valid and complete script, is bitcoin segregated witness (SegWit) a solution to avoiding Unconfirmed transaction output (UTXO) part of which was made as an improvement over legacy bitcoin address?

What are the approachs we can adopt to avoid the event of double spending?

[1715098835]

1715098835

[1715098835]

1715098835

[bitmover]

In a legacy bitcoin transaction, a Script PubKey set a  combination with that of a ScriptSig in making a unique, valid and complete script, is bitcoin segregated witness (SegWit) a solution to avoiding Unconfirmed transaction output (UTXO) part of which was made as an improvement over legacy bitcoin address?

What are the approachs we can adopt to avoid the event of double spending?

It is not possible to double spend from segwit address format.

You are making a lot of confusion between terms, and the explanation is much simpler.

Segwit basically remove witness (signatures) data from transactions, this is why it is called segregated witness.
This makes transactions smaller, so we can put more transactions inside a block, virtually increasing block size.

From bitcoin wiki:

Segregated Witness (abbreviated as SegWit) is an implemented protocol upgrade intended to provide protection from transaction malleability and increase block capacity. SegWit separates the witness from the list of inputs. The witness contains data required to check transaction validity but is not required to determine transaction effects. Additionally, a new weight parameter is defined, and blocks are allowed to have at most 4 million weight units (WU). Non-witness and pre-segwit witness bytes weigh 4 WU, but each byte of Segwit witness data only weighs 1 WU, allowing blocks that are larger than 1 MB without a hardforking change.

https://en.bitcoin.it/wiki/Segregated_Witness

[odolvlobo]

Are there some reasons to the causes of UTXO when comparing the bitcoin Legacy address from bitcoin SegWit address

Your questions are not clear, perhaps because you are confused by the terms.

A UTXO (unspent transaction output) is simply the output of a transaction that has not yet been spent. For example if you send 1 BTC to an address (legacy or segwit), you will create a UTXO that remains until that 1 BTC has been spent.

[pooya87]

Segwit basically remove witness (signatures) data from transactions, this is why it is called segregated witness.
This makes transactions smaller, so we can put more transactions inside a block, virtually increasing block size.

This is incorrect. SegWit does NOT remove anything from the transaction. It moves signature script from its previous place to a new place (still part of the transaction) called witness that comes right before the transaction locktime.

It also does NOT reduce transaction size, in fact it slightly increases the size. The weight is smaller because of the way it is calculated. What SegWit does is allowing more transactions to be placed in blocks by increasing the block size in a backward compatible way. This is sometimes falsely interpreted as tx size being smaller.

[Zaguru12]

Are there some reasons to the causes of UTXO when comparing the bitcoin Legacy address from bitcoin SegWit address

To validate an unspent transaction output of a bitcoin transaction using unlocking script which is also referred to as ScriptSig while in other way, we have the Script PubKey in locking script in which gives the command needed to spending a transaction from the receiver's end, else every unconfirmed transactions are directed to stay on mempool.

In a legacy bitcoin transaction, a Script PubKey set a  combination with that of a ScriptSig in making a unique, valid and complete script, is bitcoin segregated witness (SegWit) a solution to avoiding Unconfirmed transaction output (UTXO) part of which was made as an improvement over legacy bitcoin address?

What are the approachs we can adopt to avoid the event of double spending?

Comparing segwit transactions with legacy's. The improvement it has over the legacy transactions are:

1. It has a larger size than legacy

2. It requires less network fees for confirmation

3. It is less prone to malleablity attacks compare to legacy transactions

In the case of double spending which is almost impossible although theoretically possible. Bitcoin solves by confirming and verifying one of the transactions from the mempool (where both the unconfirmed transactions temporary stored) then the second transaction becomes invalid.

It can only be possible if the attacker can control 51% of the networking power. So it's almost impossible

Check https://www.investopedia.com/ask/answers/061915/how-does-block-chain-prevent-doublespending-bitcoins.asp

[NotATether]

This question is about "Does segwit eliminate UTXOs" and the answer to that is no. UTXO stands for Unspent Transaction Output and works independently of the address format.

A UTXO is created as transaction outputs in transactions utilizing both legacy and segwit addresses (or both) - only the locking script is specified in the output [P2PKH, P2WPKH etc etc...], not the address, but the format for specifying a transaction input inside the raw transaction is a little different for each address type.

[o_e_l_e_o]

1. It has a larger size than legacy

A larger raw size, but a smaller weight or virtual size.

It can only be possible if the attacker can control 51% of the networking power. So it's almost impossible

This is not accurate. Double spending can happen if an attacker controls far less than 51% of the hash rate, or even without an active attacker at all and just someone taking advantage of a natural chain split and getting lucky.

Bitcoin solves by confirming and verifying one of the transactions from the mempool (where both the unconfirmed transactions temporary stored) then the second transaction becomes invalid.

"The mempool" is not a centralized entity. Each node has its own mempool. Any individual mempool will not store both unconfirmed transactions in such a case, as one of them will be rejected as a potential double spend. Some individual mempools will store one transaction, while other individual mempools will store the other.