What is the size and weight of a P2WPKH input?

TL;DR:
A P2WPKH input should be conservatively estimated with 68.0 vbytes. Standard P2WPKH inputs generally weigh 67.75 or 68.0 vbytes, depending on whether the r-value in the signature is low or high. A wallet using signature grinding will always produce 67.75 vbyte inputs (which is highly recommended). 68.0 vbytes is the conservative estimate allowing for high-r signatures.

Composition of a P2WPKH input

Each input commits to spending a specific UTXO by providing its transaction outpoint:

PREVOUT: hash (32 bytes)
         index (4 bytes)

The scriptsig for a P2WPKH input is empty, however, the scriptsig length must be provided as 0:

SCRIPTSIG: length (1 byte)
  <no content>

Each transaction input has its own sequence number:

sequence (4 bytes)

A P2WPKH input requires a witness in the transaction’s witness block:

WITNESS: item count (1 byte)
  signature length (1 byte)
  signature (71 or 72 bytes)¹
  pubkey length (1 byte)
  pubkey (33 bytes)

Conservative weight, vsize, and size estimate

A P2WPKH transaction input adds to a transactions…

weight:

4 × (32 + 4 + 1 + 4) + 1 + 1 + 72 + 1 + 33 = 272 WU

vsize:

32 + 4 + 1 + 4 + (1 + 1 + 72 + 1 + 33) / 4 = 68 vbytes

serialized byte length:

32 + 4 + 1 + 4 + 1 + 1 + 72 + 1 + 33 = 149 bytes

If the signing wallet uses signature grinding, the r-value is always 32 bytes, reducing the signature to 71 bytes, and the above maxima to 271 WU, 67.75 vbytes, and 148 bytes respectively.

Note that adding at least one segwit input adds 2 witness bytes to the transaction header, the witness marker and witness flag. Also, when there is at least one segwit input, the witness block must have a witness count item for every input, which must be provided as 0 for non-segwit inputs.
The overall transaction elements of a segwit transaction therefore are:

version (4 bytes)
witness marker (1 WU)
witness flag (1 WU)
input count (1 byte)
  inputs (variable size)
output count (1 byte)
  outputs (variable size)
witness item counts (1 WU per input)
  witnesses (variable weight)
locktime (4 bytes)

Mentioned for completeness, a non-standard signature with both high-s and high-r weighs 273 WU, 68.25 vbytes, and 150 bytes.


¹ also see What is the maximum size of a DER encoded ECDSA signature?.

buy bitcoins – BTC received in BECH32 (P2WPKH) format address not exist in Electrum

I sent some BTC to a BECH32 (P2WPKH) format address. (details of the transaction)

I imported the private key(wif) in Electrum, but I can’t find the income?

I am sure I sent to the right address and imported the right wif. How can I get the incomes?

Thanks a lot!

segregated witness – Transaction w/ a P2WPKH input with nonWitnessUtxo

I am reading the testing code of bitcoinJS-lib and see the line below that is about “create (and broadcast via 3PBP) a Transaction, w/ a P2WPKH input with nonWitnessUtxo’ “.

https://github.com/bitcoinjs/bitcoinjs-lib/blob/7622c58365e09ff26002b56d4a4e7fd13251c949/test/integration/transactions.spec.ts#L349

How is it possible ? I thought that transactions with Native Segwit input (P2WPKH) should be associated with the witness data.

bitcoin core: is the dust output limit the same for p2wpkh and p2wsh?

I just realized that there are, in fact, these two lines that take into account the size of CTxOut:

size_t nSize = GetSerializeSize(txout);
...
...
nSize += (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4);

Based on this, a p2wsh output (43 bytes) would have a dust limit of:

= 43 + (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4)
= 110 bytes

then using the actual_relay_tx_fee dust of 3000 sat / kilobyte (or 3 sat / byte),

110 bytes * 3 sat / byte = 330 satoshis

Therefore, p2wsh outputs with less than 330 satoshis will be considered non-standard and will be rejected.

transactions – P2WPKH regtest – non-mandatory script verification flag (signature must be zero for failed SIG CHECK (MULTI) operation) (code 64)

I have a P2WPKH address in the latest environment bcrt1qx3qf2gze70rfycwrm42lpdnl5znf5rsnvled2z with 50 bitcoins

Create raw transaction

bitcoin-cli createrawtransaction '({"txid":"'$TXID'","vout":'$VOUT'})' '({"'$ADDR_DEST'":'$AMOUNT'})'

Sign raw transaction

bitcoin-cli signrawtransactionwithkey $TX_DATA '("'$PK'")' '({"txid":"'$TXID'","vout":'$VOUT',"scriptPubKey":"'$SCRIPTPUBKEY'","amount":'$AMOUNT'})'

is my signed transaction data

02000000000101d82c9c0273fcebe538611f1ee69019fc5c75f148185fcefc9539e4969d2fee300000000000ffffffff016036f829010000001976a91413808e045e0fe98c47c4034309f0268dd915c7e888ac02473044022024f0b86b16834ea3c301a8585e10d76e97c2054484bbb5816826d225e9a3a0dc02205885f84737eadb5da55b1f9624bbb9118f696f132cd87e4e0f0211e1fad47715012102d409de18736dc9d903aa900b29b3b5fc3a9f77e5a2a8af8cb4c737d3491a6a3400000000

deserialized:

   (
      {
        "txid": "9e669f99ea0ebca3376e89918f2bfeeab0bd4d8a3f05157d25f8b12a8e9b9760",
        "vout": 0,
        "address": "bcrt1qx3qf2gze70rfycwrm42lpdnl5znf5rsnvled2z",
        "label": "",
        "scriptPubKey": "00143440952059f3c69261c3dd55f0b67fa0a69a0e13",
        "amount": 50,
        "confirmations": 101,
        "spendable": false,
        "solvable": false,
        "safe": true
      }
    )

then I create transaction and sign it. 
It is my transaction data signed
{
  "txid": "a9535cf94eccb2aea80a4f725e84ae541bf30e3c1c125a551c167c50f9b9acde",
  "hash": "504264845a478d405a831ee68774a59b774240ceee6f6dd6ce8b4939a6f4331a",
  "version": 2,
  "size": 194,
  "vsize": 113,
  "weight": 449,
  "locktime": 0,
  "vin": (
    {
      "txid": "30ee2f9d96e43995fcce5f1848f1755cfc1990e61e1f6138e5ebfc73029c2cd8",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": (
        "3044022024f0b86b16834ea3c301a8585e10d76e97c2054484bbb5816826d225e9a3a0dc02205885f84737eadb5da55b1f9624bbb9118f696f132cd87e4e0f0211e1fad4771501",
        "02d409de18736dc9d903aa900b29b3b5fc3a9f77e5a2a8af8cb4c737d3491a6a34"
      ),
      "sequence": 4294967295
    }
  ),
  "vout": (
    {
      "value": 49.99100000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 13808e045e0fe98c47c4034309f0268dd915c7e8 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91413808e045e0fe98c47c4034309f0268dd915c7e888ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": (
          "mhJ58qf2iH6XzRrXjpP5mLvfRk5tYMDmTW"
        )
      }
    }
  )
}

When I try to send the transaction:

$ bitcoin-cli sendrawtransaction 02000000000101d82c9c0273fcebe538611f1ee69019fc5c75f148185fcefc9539e4969d2fee300000000000ffffffff016036f829010000001976a91413808e045e0fe98c47c4034309f0268dd915c7e888ac02473044022024f0b86b16834ea3c301a8585e10d76e97c2054484bbb5816826d225e9a3a0dc02205885f84737eadb5da55b1f9624bbb9118f696f132cd87e4e0f0211e1fad47715012102d409de18736dc9d903aa900b29b3b5fc3a9f77e5a2a8af8cb4c737d3491a6a3400000000
error code: -26
error message:
non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code 64)

I saw this problem on Github. Could it be the same?

bitcoin kernel – Generate P2WPKH on regtest, invalid address

I want to generate P2WPKH to study segwit.
I create a script to generate it and it works because I use that public key (0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798) and I get tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx like https://en.bitcoin.it/wiki/BIP_0173.

Then I change the Humanreadable part to bcrt (https://github.com/bitcoin/bitcoin/issues/12314) and I repeat the script.
My address is: bcrt1qyhdjzrazrs0ql68q0jttygjezusvd2na but when I use generatetoaddress it comes out

Invalid Bitcoin address: bcrt1qyhdjzrazrs0ql68q0jttygjezusvd2na

my bitcoind version is 0.19.0.1

$ bitcoin-cli validateaddress bcrt1qyhdjzrazrs0ql68q0jttygjezusvd2na
{
  "isvalid": false
}

It's my bitcoin.conf

regtest=1
daemon=1
txindex=1
# Options only for mainnet
(main)

# Options only for testnet
(test)

# Options only for regtest
(regtest)

address – Generate P2WPKH – Bitcoin Stack Exchange

Stack Exchange Network

The Stack Exchange network consists of 175 question and answer communities, including Stack Overflow, the largest and most trusted online community for developers to learn, share their insights, and develop their careers.

Visit Stack Exchange

segregated witness – Sign unprocessed Segwit transaction summary (P2WPKH)

I have a simple transaction from which I want to sign the summary, but I am not sure I have the correct raw transaction, therefore, my summary is incorrect.

The transaction has an entry and an exit, but with a P2WPKH transaction, I am not sure what to use in the SigScript field so you can sha256 (sha256) and get the correct summary to sign. (for P2PKH you use an OP_DUP, OP_HASH160 PUBKEY_HASH OP_EQUALVERIFY OP_CHECKSIG that you can get from the UTXO entry in the SigScript field)

This is my raw transaction:
02000000010a02214430acee2ed509798187210171bb387075ce2c82ef5a73774d6159387500000000
00
ffffffff018ca1b404000000001976a914906ec1c4804632c0b067e5a2732c41cdf620c4e688ac0000000001000000

These are the bytes in which I am calculating the sha256 (sha256) and, as you can see, I have 00 bytes in the SigScript field. Is this correct? Should I be using something else here?

I take my signature and then create the signed transaction like this:
020000000001010a02214430acee2ed509798187210171bb387075ce2c82ef5a73774d6159387500000000
17160014d99f1ea19e98d9ed10e5d442be37a44b6b63c477ffffffff  (hash160 of public key)
018ca1b404000000001976a914906ec1c4804632c0b067e5a2732c41cdf620c4e688ac
02 (number of stack items)    
(signature)
4830460221009f5d0f24faff44fc6ffd364ef4af87d366b95058c60497b87f9fd51bb3e60f59022100f768fb09286f8c9f5aba7295e6a2ce243f2f1eac29b717feb18108b6e8c0003a
(public key)    
41047d011958b661181242addd300b6d5c51f80d62674555831dd855b34358b57e05fb46477ba167a57b23bf8a492305c0085d8c34aa04d483b7f15a2d551e2ff66200000000

But this does not seem to work and says that my signature is not valid, so I can only assume that my summary is not correct. Any help would be appreciated.

Why is a 20-byte hash acceptable in p2wpkh but p2wsh needs 32 bytes?

Why is it acceptable to use a 20-byte hash to represent single sign token programs, while a 32-byte hash is used to pay for the token script hash?

How do I get the Bech32 address from the P2WPKH output script?

Okay, so I think I've discovered it for someone else to wonder what exactly You have to do to derive such an address.

In the case of the aforementioned transaction, (coinbase of block 542748) we first start by looking at the complete decoded output script.

0 PUSHDATA(20) 97cfc76442fe717f2a3f0cc9c175f7561b661997

  • First OP_0 in the decoded script is the witness version
  • Then we take the pushed data (in our case 97cfc76442fe717f2a3f0cc9c175f7561b661997) and turn it into binary
  • Then we divide the binary into 5-bit sections. In our case: 10010 11111 00111 11100 01110 11001 00010 00010 11111 11001 11000 10111 11110 01010 10001 11111 00001 10011 00100 11100 00010 11101 01111 10111 01010 11000 01101 10110 01100 00110 01100 10111
  • So let's prefix the witness version in 5 bits 00000
  • Our binary becomes 00000 10010 11111 00111 11100 01110 11001 00010 00010 11111 11001 11000 10111 11110 01010 10001 11111 00001 10011 00100 11100 00010 11101 01111 10111 01010 11000 01101 10110 01100 00110 01100 10111
  • The first part of the address is considered human readable part.
    This is always bc in the main network and tb in the testnet
  • 1 it is always the separator between the human readable portion and the rest or data
  • Now our address starts with bc1 (mainnet is bc + separator 1)
  • Now we assign every 5 bits to the table here, or this alternative graphic that I created
  • bc1 qjl8uwezzlech723lpnyuza0h2cdkvxvh
  • The remaining 6 characters are a checksum.
  • Using the Python code provided here we can calculate the checksum using the bech32_create_checksum function
  • The first argument is the human readable serving as a STRING without the separator (1)
  • The second argument is an array of converted integers from our binary data part

Our example:

bech32_create_checksum("bc", (0, 18, 31, 7, 28, 14, 25, 2, 2, 31, 25, 24, 23, 30, 10, 17, 31, 1, 19, 4, 28, 2, 29, 15, 23, 10, 24, 13, 22, 12, 6, 12, 23) )

This gives us:

(20, 21, 12, 17, 13, 19)

What can be assigned with our table to 54v3dn

Finally, we concatenate the human readable, seperator, decoded data, and the checksum For our final address: bc1qjl8uwezzlech723lpnyuza0h2cdkvxvh54v3dn