Assuming all the inputs you are spending are from regular "pay to address" transactions, each input will contribute 180 (plus or minus 1) bytes to the transaction. Each output adds 34 bytes to the transaction. And there's a fixed extra 10 bytes which are always present.
The "plus or minus 1" comes from the fact that each input needs a signature to be ...
Here are some calculations based on the Protocol Documentation.
A Bitcoin Transaction is composed of the following:
Version (4 Bytes)
TxIn Count (1 ~ 9B)
For each TxIn:
Script Length (1 ~ 9B)
TxOut Count (1 ~ 9B)
For each TxOut:
Script Length(1 ~ 9B)*
Assuming a standard ...
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 ...
There are a number of different address formats and other standard transaction types:
Pay to Public Key (P2PK) outputs tie payments directly to the public key of the recipient instead of the derived address. These have been almost completely replaced by P2PKH, although sometimes mining rewards are still paid out to P2PK.
Input: 114 B
Output: 44 B (...
Since the activation of Segwit, transaction size is expressed in Weight Units (WU). Weight Units can be converted to a "virtual size" or virtual bytes (vB) by dividing by 4 and rounding up. The virtual size dictates how large your transaction is when paying fees.
For now, let's focus on Non-Segwit transactions. Each Non-Segwit byte ...
The first number does not include the prevout, sequence number, or the length byte for the scriptSig. It also uses 65 bytes for the public key (which is correct if it is uncompressed, but compressed keys of 33 bytes are more common now). Correcting it gives 139 + 36 + 4 + 1 + (33 or 65) = 148 or 180.
The developer in the third case forgot to include the ...
There is no minimum size restraint on blocks and transactions. However, due to the nature of blocks and transactions, there is a practical minimum.
The smallest transaction I can think of is 61 bytes. It is a transaction that spends an OP_TRUE anyonecanspend output and creates 1 OP_TRUE anyonecanspend output. The smallest block I can think of is 146 bytes. ...
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. ...
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 ...
In general, Segwit v1 is cheaper than segwit v0 to spend but slightly more expensive to create.
Segwit v1 output scripts as defined by the proposed taproot BIP will always be 35 bytes in length. However Segwit v0 output scripts are either 22 bytes (for the single key case) or 34 bytes (script hash case). This means that the person sending to segwit v1 will ...
what happens if size of a transaction is larger than maximum block size?
Then the transaction can never be included in a block.
There is no mechanism for dividing it up into multiple blocks, or anything like that. Any block that includes it would be invalid, since the block would become too large for the network's rules.
This may be of interest: Block ...
Nick Odell answers the original question:
The maximum transaction size is the size of the block. Source.
Transactions larger than 100 kilobytes (including witness at a 75% discount rate) are non-standard. Source 1. Source 2.
so the case that you are describing will not occur as transactions lager than the blocksize will be sorted out.
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 =&...
What about the second one ? That can be 61 bytes long ?
Also, does each transaction carry a counter ?
No. There is a global counter in the block that is right after the block header. That counter is the number of transactions included in the block. It is not part of any transaction and its size does not affect the size of any transaction in the ...
Depends on the number of inputs, the types of scripts the inputs are redeeming, the number of outputs, and the type of scripts that the ouputs are paying to.
The absolute minimum for a transaction that might appear on chain is 60 bytes :
The Bitcoin scripting language allows for a decent variety of transaction constructions, but only a subset of those are considered "standard". In particular, Bitcoin Core will only relay transactions by default that pass the isStandard() check. However, miners are still free to include (valid!) non-standard transactions in their blocks.
Transactions larger ...
What is a "maximum standard weight"?
It is a property that nodes follow to prevent processing large transactions with number of rules and signatures. It is standardness not consensus. If a node receives a transaction greater than 400,000 WU, it will discard the transaction and not relay it further. I can however, definitely create a transaction greater than ...
Let's re-write and calculate from scratch as the calculations that you have posted might not be self-explanatory in itself and some of them are not entirely accurate. From the question, I presume you are trying to find the size of transaction for spending bitcoins from a multi-sig address.
Redeem Script Size
I think there is an error in the size of redeem ...
In Bitcoin Optech Newsletter #46, the costs are compared as follows:
Overall, this makes the cost to create and spend a Taproot single-sig output about 5% more expensive than P2WPKH.
P2PKH P2WPKH Taproot
scriptPubKey 25 22 35
scriptSig 107 0 0
witness 0 26.75 16.25
That limit (which is different today) pertains to node policy and transaction standardness. It is important to keep in mind that something that is non-standard is not necessarily invalid. Validity and standardness are two different things, although standardness is a subset of validity.
A transaction smaller than the standardness minimum can still be valid. ...
Typically people will store arbitrary data in a separate output in a transaction beginning with OP_RETURN.
Any output with this OP code will be considered invalid or provably unspendable, but will still exist as part of the blockchain.
As mentioned in this thread Bitcoin-core options will allow for up to 80 bytes of arbitrary data by default. It is worth ...
Yes, but for a different reason than you think. ;)
Transactions bigger than 100,000 bytes are considered non-standard and won't be relayed by most nodes and probably not included by most miners in their block candidates.
Besides that, especially for a transaction paying a thrifty fee, a larger transaction might take longer to confirm. Block templates are ...