The main culprit is some of the services that refuses to adopt segwit address types.
Additionally, it makes more people to use P2SH-SegWit by default rather than P2WPKH (bc1 address).
Topic: Segwit Questions (Read 443 times)
Additionally, it makes more people to use P2SH-SegWit by default rather than P2WPKH (bc1 address).
I have been looking at the latest confirmed Block Sizes today and most are under 1.5 MB. I read that Segwit should provide savings of around 60-65% which should put the Block Size well above 2 MB.
That's in theory. In practice, the best real world estimates still puts it below 2MB.So it it safe to say that the large majority of nodes are presently Seqwit nodes but there are still many Bitcoin Addresses that haven't upgraded to bc1?
Segwit was activated for quite a long time and that Bitcoin Core has adopted segwit for quite a few revisions already. Majority of the nodes (based on bitnodes) is running on a segwit-compatible version.It's not quite the right phrasing to upgrade Bitcoin addresses but it's more accurate to say converted. The main culprit is some of the services that refuses to adopt segwit address types. You also cannot tell a normal P2SH from a P2WSH transaction until it is spent at least once. I would say the statistics might be slightly skewed.
I have been looking at the latest confirmed Block Sizes today and most are under 1.5 MB. I read that Segwit should provide savings of around 60-65% which should put the Block Size well above 2 MB. So is it safe to say that the large majority of nodes are presently Seqwit nodes but there are still many Bitcoin Addresses that haven't upgraded to bc1?
The short answer is yes, that article is a very (over) simplified and somewhat inaccurate explanation of SegWit... 
Good to know. I assumed the referenced article did a decent job at explaining Segwit but apparently not.
Thanks for all the responses. I am learning a lot from this forum.
The short answer is yes, that article is a very (over) simplified and somewhat inaccurate explanation of SegWit...
Thanks for your response pooya87.
What you are describing is not in complete alignment with the article I referenced. Is the article a simplified version of what you are now explaining to me?
Thanks
What you are describing is not in complete alignment with the article I referenced. Is the article a simplified version of what you are now explaining to me?
Thanks
I am not sure where OP_number fits in since it's not mentioned in the article I referenced at the start of my thread.
OP_number is any OP code that is followed by a number is is simply pushing an integer to the stack. anything except negative one is used in SegWit outputs that is OP_0, OP_1, OP_2,.... OP_16.here are two examples:
Code:
0014ecd2c537b2222dc367110450e2526beef3f2d110
OP_0
OP_0
Code:
52207713dd0580bec75aa5e74f53b9f34657c4af0cd9bcedbae7cfd062afb3d16b15
OP_2 <7713dd0580bec75aa5e74f53b9f34657c4af0cd9bcedbae7cfd062afb3d16b15>
currently only version 0 (OP_0) is defined.OP_2 <7713dd0580bec75aa5e74f53b9f34657c4af0cd9bcedbae7cfd062afb3d16b15>
The Segwit Miners made scriptPubKey: Empty in the coinbase transaction.
no, an empty pubkey script means nothing special. a SegWit node verifies all transactions including those that have witnesses and constructs the block and its coinbase transaction as before with 2 additional steps:- add a single witness reserved value in coinbase witness
- add the witness commitment as a new pubkey script using OP_Return
ax explained in BIP-141
Quote
So scriptPubKey: Empty indicates that this is a Segwit UTXO.
no, a pubkey script that is in the way i explained above (OP_0 to OP_16 followed by a single push of between 2 to 40 bytes) is indicating a SegWit UTXO.\this is similar to P2SH softfork. a pubkey script that is OP_HASH160 <20 bytes> OP_EQUAL demands extra steps that only new nodes understand and old nodes (before P2SH upgrade) can not verify.
Quote
A non-Segwit node will ignore all UTXO where scriptPubKey: Empty but a Segwit node will know which Bitcoin Address this UTXO belongs to.
no. nodes don't ignore anything and they must know which UTXO they belong to. keep in mind UTXO is not fetched by the script but by using the hash and index inside tx_in outpoint. the old nodes don't see the witness. Quote
SegWit output is also a very simple script to them (OP_number )
I am not sure where OP_number
https://medium.com/@BlockTalkChain/how-does-non-segwit-legacy-node-verify-segwit-transaction-c3bc0872842b
But I think this may be used to acquire the actual Witness data that is stored beyond the regular limits of a Non-Segwit Block?
Quote
It doesn't. Segwit style signing is only used for segwit style outputs. Old style outputs are spent using the old means.
So that means the Segwit process started with the Miners that updated their Software. The Segwit Miners made scriptPubKey: Empty in the coinbase transaction.
So scriptPubKey: Empty indicates that this is a Segwit UTXO. A non-Segwit node will ignore all UTXO where scriptPubKey: Empty but a Segwit node will know which Bitcoin Address this UTXO belongs to. When a Segwit node builds a new transaction with a Segwit UTXO it will construct it with Standard Scripts containing (Digital Signature + PubKey and a Locking Script). However, when a Segwit Miner places the new Segwit transaction into the block they will put scriptSig: OP_TRUE scriptPubKey: Empty to continue the Segwit UTXO chain.
When a Segwit Transaction is seen by a Non-Segwit node it rejects it because the Locking Script for the input UTXO is a non-standard script but a Non-Segwit node accepts blocks with scriptSig: OP_TRUE scriptPubKey: Empty which enables Segwit to work.
Is my understanding correct now?
Thank you
The Segwit Node makes scriptSig: OP_TRUE, and scriptPubKey: Empty and places this in the Block.
So how was this backwards compatible when Segwit first kicked off?
So how was this backwards compatible when Segwit first kicked off?
think of SegWit as some additional steps and a new field added to transactions that old nodes don't see but new nodes see and know what those steps are.
to an old node, everything that happened before is still happening the same exact way (eg. OP_DUP, OP_HASH160
however when the new nodes see (OP_number
However, how does scriptSig: OP_TRUE unlock the original Pre-Segwit input UTXO A with scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG on the Non-Segwit node?
It doesn't. Segwit style signing is only used for segwit style outputs. Old style outputs are spent using the old means.
I am still confused about something.
The Segwit Node makes scriptSig: OP_TRUE, and scriptPubKey: Empty and places this in the Block.
However, how does scriptSig: OP_TRUE unlock the original Pre-Segwit input UTXO A with scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG on the Non-Segwit node?
The Non-Segwit node should reject scriptSig: OP_TRUE as the unlocking Script for UTXO A and not include this block.
I can see how the Non-Segwit node would accept scriptSig: OP_TRUE if UTXO A scriptPubKey: Empty but when Segwit was initially implemented none of the UTXO's contained scriptPubKey: Empty
So how was this backwards compatible when Segwit first kicked off?
Thanks
The Segwit Node makes scriptSig: OP_TRUE, and scriptPubKey: Empty and places this in the Block.
However, how does scriptSig: OP_TRUE unlock the original Pre-Segwit input UTXO A with scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG on the Non-Segwit node?
The Non-Segwit node should reject scriptSig: OP_TRUE as the unlocking Script for UTXO A and not include this block.
I can see how the Non-Segwit node would accept scriptSig: OP_TRUE if UTXO A scriptPubKey: Empty but when Segwit was initially implemented none of the UTXO's contained scriptPubKey: Empty
So how was this backwards compatible when Segwit first kicked off?
Thanks
Thanks for everyone's responses.
Quote
In fact, SegWit node will strip the witness data before sending the block to legagy node.
Interesting, so a SeqWit node sends out two versions of the Mined Block? The stripped version for Legacy Nodes and the Extended Witness Data Block for Segwit nodes?
Thanks
If it's connected to an old non-segwit peer it'll send that peer a stripped block. All blocks it receives are the complete blocks, and of course any it sends to modern nodes are complete too.
There aren't that many pre-segwit nodes on the network anymore since segwit has been out for something very close to four years now. E.g. my node at home has 45 peers right now and every one of them is node_witness.
Quote
In fact, SegWit node will strip the witness data before sending the block to legagy node.
Interesting, so a SeqWit node sends out two versions of the Mined Block? The stripped version for Legacy Nodes and the Extended Witness Data Block for Segwit nodes?
Thanks
AFAIK the witness data is stored at the end of the block.
Witness is not something separate to be stored separately, it is a part of each transaction like the transaction's version, locktime, outpoint and so on. Each witness of each transaction is stored inside that transaction as a new field right after the last txout and right before the locktime.
On this site it states that the Bitcoin Block has the field Blocksize which demarks the end of the block. So the Witness data is stored after this point on Segwit Nodes?
https://en.bitcoin.it/wiki/Block
That is a mistake, the is NOT block structure. That looks like a half cut off P2P Block message.https://en.bitcoin.it/wiki/Block
The message starts with a magic (byte[] { 0xf9, 0xbe, 0xb4, 0xd9 }), then message name/type (block\0\0\0\0\0\0\0), message data length, checksum, message data.
in this case the "message data" part is a block which has the following structure:
block header, number of transactions, array of transactions
On this site it states that the Bitcoin Block has the field Blocksize which demarks the end of the block. So the Witness data is stored after this point on Segwit Nodes?
https://en.bitcoin.it/wiki/Block
https://en.bitcoin.it/wiki/Block
The below short article explains how Seqwit works.
https://medium.com/@BlockTalkChain/how-does-non-segwit-legacy-node-verify-segwit-transaction-c3bc0872842b
Does this mean a SeqWit miner will transmit a successfully mined Bitcoin Block that is > 1 MB. The data beyond the 1 MB point in the Block stores the scriptSig and scriptPubKey?
A non-SegWit (Legacy) Miner will just store the traditional 1 MB block? What marks the end of a traditional Bitcoin Block, marking the beginning of the witness data in the extended Segwit Block?
Thank you
https://medium.com/@BlockTalkChain/how-does-non-segwit-legacy-node-verify-segwit-transaction-c3bc0872842b
Quote
When running a verification on transaction like this, a SegWit miner or node knows where to find the signature data for verification
Does this mean a SeqWit miner will transmit a successfully mined Bitcoin Block that is > 1 MB. The data beyond the 1 MB point in the Block stores the scriptSig and scriptPubKey?
A non-SegWit (Legacy) Miner will just store the traditional 1 MB block? What marks the end of a traditional Bitcoin Block, marking the beginning of the witness data in the extended Segwit Block?
Thank you
Jump to: