Is there a way to get to the hash160 address from bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c
Yes, you could use the reference implementations in various languages to encode and decode a bech32 address. For example, I have decoded the sample address you mentioned in the question, bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c, using python below. The decode ...
Yes, they are referring to two different metrics: virtual size (vsize) and size.
The size in [bytes] of a transaction refers to the raw byte length of its serialized format. It is used to measure the data footprint of transactions when relayed on the network or stored on disk.
The vsize in [vbytes] refers to a transaction's weighted size under segwit rules. ...
A P2WPKH PubKey is shorter than a P2WSH PubKey.
No, not quite. A p2wpkh address is shorter than a p2wsh address. The addresses are both based on a hash of the underlying witness program (i.e. the locking conditions of the output). In the case of pay-to-witness-pubkey-hash (p2wpkh) the witness program contains only the pubkey. On the other hand, pay-to-...
In this point, if Bob make a fraud transaction with Segwit, legacy
node will accept, but it is not accepted in terms of fresh node. so,
some group(legacy nodes) accept, other some groups(fresh nodes)
doesn't accept. it means that proportion of fresh node should be
bigger than proportion of legacy node. I think that this is really
critical issue but ...
For non-segwit transactions, vbytes = bytes.
With the implementation of SegWit, we now see the weight of the block/transactions rather than seeing the absolute size on the wire. While calculating the weight of a transaction, we use a weight of four for the normal transaction components (ex signature) and weight of one for the witness components. Now vbyte ...
The txid of a segwit transaction is computed by first dropping all the witnesses, and encoding it in legacy notation, and then computing the double-SHA256 hash of it.
This is the only possible way, as anything else wouldn't be compatible with old clients (which is required by it being a softfork).
I also believe I read that the signature part can account for 65% of the block size.
This is not entirely correct. The typical size of a block depends on the make-up of transactions in that block. The size of signatures to overall block size will depend on the number of inputs in a transaction. More the number of inputs in a transaction, higher the ...
SegWit doesn't save space, per se.
What it does do is:
From the perspective of a non-upgraded node, it makes transactions seem smaller. The witness part is not recognized or considered by pre-fork nodes, so more of them can fit in a block.
From the perspective of an upgraded node, the block size is calculated differently. Less weight is assigned to witness ...
It's important to point out that segwit doesn't prevent malleability: in many ways the actual transaction data can still be changed by third parties. It just makes it harmless for the purposes of dependant transactions/higher level protocols, because when malleated, the resulting transaction will still have the same txid as the original.
To get this ...
it means that proportion of fresh node should be bigger than proportion of legacy node.
The requirement for segwit's activation was that the majority of the hashrate signaled readiness for activation. Although this process was frequently misconstrued as a "vote of miners", the activation proposal actually requests that miners judge whether the majority of ...
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 ...
At a protocol level, they are all compatible. Transactions can spend any of them, and send to any of them.
Wallet software may of course have restrictions, but these are usually not about combinations. E.g. some wallets may be unable to generate a p2sh-segwit address to receive on, or be unable to send to bech32. However, I have not heard about software ...
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 ...
When forwarding the block to a non-segwit peer, a segwit-enabled node strips the block before transmission.
If a segwit-enabled node were to receive a stripped block, it would consider the block invalid due to the missing witness data on transactions with segwit inputs. However, a segwit-enabled node will never request blocks from legacy peers as they ...
The wtxid and txid are the same if and only if the transaction does not contain any segwit inputs. The wtxid is the hash of the entire transaction including all segwit data (i.e. the marker and flag bytes and the witness fields themselves). The txid is the hash of the non-segwit parts of the transaction. Because a transaction that does not have any segwit ...
It's not particularly required and may be considered redundant as that information is generally implied from the transaction outpoints referenced in the input. However, this form of transaction serialization allows wallet softwares to explicitly commit to the fees involved in the transaction. This is particularly useful if say you are using a hardware wallet ...
As noted in BIP 143, the CODESEPARATOR opcode operates by truncating the scriptCode value that is included in the digest. While rarely used, CODESEPARATOR does provide a method to create signatures that are bound to specific code paths taken by Script, even when the same pubkey key used for redeeming the UTXO.
If the scriptCode were removed from the digest ...
This is unrelated to segregated witness.
Since Bitcoin Core version v0.17, signatures have low R signatures. The signing operating is repeated until an R value is constructed that's below 2255. On average this only takes 2 attempts, but it makes all signatures equally long (71 bytes; rather than 50% 71 bytes and 50% 72 bytes), making them more predictable ...
Does that mean that non-SegWit transactions are still malleable?
Yes. Segwit does not change non-segwit inputs so the malleability fixes it introduces only apply to segwit inputs.
If so, what types of malleability could still happen in practice?
All of them (except the ones where the sender modifies the transaction himself). None of these are consensus ...
As Anonymous says, you simply cannot.
I'll try to highlight the important part of MCCCS's answer:
In Bitcoin Cash, cashaddr ("bitcoincash:...", similar to, but not quite bech32) and legacy addresses ("1..." and "3...", base58) are two different ways of representing the same onchain output in a human-readable way. One can be converted into the other because ...
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 ...
I thought vbytes were equal to weight units divided by 4
It is *, but rounded up to the next integer, so the implementation in bitcoind is :
int64_t GetVirtualTransactionSize(int64_t nWeight, int64_t nSigOpCost, unsigned int bytes_per_sigop)
return (std::max(nWeight, nSigOpCost * bytes_per_sigop) + WITNESS_SCALE_FACTOR - 1) / WITNESS_SCALE_FACTOR;
What you can spend, and what you can send to depends on the wallet software and nothing else.
There are no inherent restrictions on any combination.
In case someone uses old software, they may not be able to send to bech32 addresses. But they'll get an error that the software doesn't recognize the address; no funds will be lost.
The public key that you mentioned is indeed the key that was used to derive the P2SH(P2WPKH) address: 35yfMa3CRBiWny8DFdb4tUu9fn7fcdvVp9. The way in which a P2SH(P2WPKH) address is derived is as follows:
1. witness_script = hash160(pub_key) #this is equal to '4b9d2d3dd1174ad656754a0c664e7a129b131f3b'
2. witness_version = 0x00 #current SegWit version
As per BIP 173, the data part consists of:
The data-part values:
1 byte: the witness version
A conversion of the 2-to-40-byte witness program (as defined by BIP141) to base32:
Start with the bits of the witness program, most significant bit per byte first.
Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.
Translate those bits ...
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, ...