Let's compare a 2 input and 2 output transaction for variants of pay-to-pubkeyhash. (Full data below.)
P2PKH has no witness, so raw size is equal to stripped size is equal to virtual size. A P2PKH transaction with two inputs and two outputs has 374 bytes (= 374 vBytes).
P2SH-P2WPKH (wrapped segwit) locks funds to a P2SH output in which it redirects to a ...
This structure contains data required to check transaction validity
but not required to determine transaction effects. In particular,
scripts and signatures are moved into this new structure.
The witness is a serialization of all witness data of the transaction.
Each txin is associated with a witness field. A witness field starts
with a var_int to indicate ...
SegWit blocks aren't limited in bytes anymore but rather in weight. The maximum weight for a block is 4M. The weight of non-witness data is 4x its number of bytes.
So, yes, decreasing the amount of signature-data frees up some weight which can then be filled by more transactions. Yet those new transactions also contain some non-witness data which is more ...
The scriptPubKey is the script as it is placed in the transaction output.
The redeemScript (P2SH only) is the script pushed as the last scriptSig item. In P2SH scripts, the scriptPubKey is equal to OP_HASH160 <Hash160(redeemScript)> OP_EQUAL.
The witness script (P2WSH only) is the script in the last witness stack position.
The witness program is ...
Bitcoin signatures have two components: s and R. To sign a Bitcoin transaction with private key k, the signing algorithm generates an ephemeral private key r. The R component of the signature is the x-coordinate of that ephemeral public key. The s component of the signature is calculated in the following way: s = r-1 (Hash(m) + k * R) mod p; where Hash(m) is ...
Have a look: https://blockchair.com/bitcoin/block/0000000000000000000cbbceb342e07071f9621607e044ec909aa86fcdf88e8a
Size = 1,158,038 bytes
Weight units = 3,992,825 WU
Now what does it mean? So the size is what you probably understand well – when you have a file on disk, its size is measured in bytes and this is exactly what the size means here. It is the ...
6 types of Bitcoin addresses (in parentheses are the data they keep):
P2PKH 1... (a public key's hash)
P2SH 3... (a script's hash) (defined in BIP16)
SegWit (P2WPKH/P2WSH) nested in P2SH (defined in BIP141)
P2SH-P2WPKH 3... (a public key's hash)
P2SH-P2WSH 3... (a script's hash)
(these start with three because these addresses are meant to be ...
For the segwit variants of an output (P2PKH becomes P2WPKH and P2SH becomes P2WSH), the witness contains the same data that would be found in the scriptSig. For P2PKH, in the scriptSig, you would have a signature and a pubkey. The same is in the witness for a P2WPKH.
For P2SH, you would have a redeemScript, signatures, and other stuff in the scriptSig. For ...
additional to JBaczuk and Andrew Chow, here is a detailed tx decoding.
This is a mixed transaction, with three "normal" inputs, and a 4th segwit type input (TX_IN). Therefor after the version field of the tx we see bytes "0001", with 0x01 indicating a segwit data structure is included in the tx. In the input section, there are three following "standard" ...
Bech32 encoding, apart from the checksum, is a simple matter of converting base-256 (8-bits) to base-32 (5-bits). Base-256 is the byte array (octet string) that you get from a hash function. Only focusing on first 3 bytes of the hash:
as hex = 0x18 0x63 0x14
as bytes = 24 99 20
as binary = 00011000 01100011 00010100
In order to ...
A reindex will not redownload the block. However, after safely shutting down Bitcoin Core, you can delete the block file containing that block. When you start it again, you will need to reindex, but once it gets to the blocks that you deleted, it will redownload them.
It's a native segwit output. 0x00 signifies the segwit version (which is v0 in this case), 0x14 is the bytes to push and 2f82e61a98eb7027672760c691784d5fbccf7ce3 is the hash160 of the public key. Native segwit addresses uses bech32 encoding as defined in BIP 173 and begin with bc1. Use this for reference implementations in various programming languages. The ...
I compared to the following 9 types of transaction's weight. And then I found that No9 (P2WPKH => P2WPKH) was the lightest.
// 1 transaction consists of 1 txin and 1 txout
1. (in)P2PKH => (out)P2PKH [weight = 764]
2. (in)P2PKH => (out)P2SH-P2WPKH [weight = 756]
3. (in)P2PKH => (out)P2WPKH [weight = 752]
4. (in)P2SH-P2WPKH =&...
Pruned nodes forget blocks after a while after processing. However, this is independent from whether those blocks have a witness.
SegWit does permit a half-pruned state, where witnesses are removed but the rest of the block is kept. That state is enough to serve lightweight nodes (which don't care about witnesses), but not enough to serve other full nodes. ...
Note that the scriptSig field is not just the ECDSA signature itself (65 bytes) but also the public key in the case of a P2PKH input, or the redeem script for a P2SH input, and a couple more bytes for sizes. Also, there is a scriptSig for every input, not just one per transaction. You are looking at the average transaction size, most of which contain ...
BIP 144 equipped nodes doesn't fetch blocks from old nodes since they are only capable of providing witness stripped blocks.
If someone sent it a stripped block (e.g. by lying about their support or whatnot) and it contained any segwit using transactions then it would get dropped and the peer disconnected-- basically treated like merkle tree malleability.
The data of the scriptSig is mooved from TransactionInput to RawTransaction, so the Raw transaction doesn't is malleability? maybe I can't imagine what really happened to non-witness transactions during malleability, can you give me an example?
The transaction ID is a hash of the entire transaction data structure (the version, inputs, outputs, signatures, ...
The only constraint on this value is that it must be 32 bytes. Otherwise there are no constraints. This is done to allow for a future soft fork to commit to new data and have non-upgraded nodes still be able to store something in the block that commits to the new data. As such, the witness reserved value must remain unconstrained to allow for a future soft ...
If your question is about how witness data is transmitted to other peers in the P2P protocol, the right place to look is BIP-144; the P2P side of the segwit specification.
In short, the witness data is inserted after the transaction output data in every individual transaction, together with a special marker after the version number to indicate whether or not ...
Why the witness data is stored outside the block? what do you mean? I think I don't
understand the sense of this space-saving because the witness data is present inside the blk file.
The signatures are in the block. All signatures of a block form another merkle tree and are keeping in an output of the coinbase tx. I think this refers to the "UTXO set" ...
All transaction data is committed to the WTXID, unlike in the case of TXID's.
Malleability is found in the unlocking script/data of a transaction. It is malleable, because is not committed to the signature (circular dependency).
Sources of TX Malleability:
Input Script Malleability
See BIP62 for a great overview of TX ...
For SegWit node, is witness necessary to verify a block? Because I know witness are committed as wtxid merkle node in coinbase. What's the purpose of the wtxid merkle node?
If a block contains transactions that have witnesses, if the block then does not have a witness, the Segwit node will still validate it, but it will find it to be invalid. Because segwit ...