How Bitcoin transactions work and what are their types?

[wwzsocki]

To understand how Bitcoin transactions work and what are their types, we have to start from the beginning and explain what Bitcoin addresses, transactions, scripts are and how they work?

Bitcoin address - is a string of alphanumerical characters that user can distribute to anyone who wishes to send them money. Bitcoin addresses can come in different formats, with common ones being: Pay-to-PubKeyHash (P2PKH) and Pay-to-ScriptHash (P2SH). Although anyone can send bitcoins to any given Bitcoin address, those funds can only be spent if they fulfill certain requirements laid out by Bitcoin’s scripting system.

Script - is effectively a list of recorded instructions that accompany each executed transaction; the script governs how the next person wanting to spend the sent bitcoins can gain access to them.
Scripts accompanying outputs in transactions are called PubKey Scripts (they are also known as locking scripts), which are known in code as scriptPubKey. Recipients of the sent bitcoins will then generate a signature script (also known as an unlocking script), which is a collection of data parameters that are generated by the spender which is used to satisfy a PubKey Script. Signature scripts are called scriptSig in code.

Example: when Alice decides to initiate a transaction with Bob, the output contains bitcoins that are spendable on condition that the instructions laid out by the attached PubKey Script are satisfied. Once this transaction is broadcasted and added to the blockchain, the network will categorize the transaction as an Unspent Transaction Output (UTXO), and Bob’s wallet software will recognize it as being a spendable balance. When Bob decides to spend this UTXO he will create an input that includes a signature script that must satisfy the conditions that Alice placed in the previous output’s PubKey Script.

Bitcoin transaction - is a transfer of value between Bitcoin wallets that gets included in the blockchain. Bitcoin wallets keep a secret piece of data called a private key or seed, which is used to sign transactions, providing a mathematical proof that they have come from the owner of the wallet. The signature also prevents the transaction from being altered by anybody once it has been issued. All transactions are broadcast to the network and usually begin to be confirmed within 10-20 minutes, through a process called mining. All transactions are visible in the blockchain and can be viewed with an explorer. A blockchain explorer is a site where every transaction included within the blockchain can be viewed in human-readable terms. This is useful for seeing the technical details of transactions in action and for verifying payments.

What are the Bitcoin Transaction types?

There a few standard Bitcoin transaction types at the time of writing. The developers behind Bitcoin have been continuously evolving the types of transactions to allow more functionality – the present list may change in the future. There are standard transactions which are accepted by the standard client – although some miners will accept the last type, which is a non-standard transaction but for a price.

Script > P2PK, P2PKH, P2MS, P2SH, P2WPKH, NULL DATA, NON-STANDARD



Standard types of transaction scripts: pay-to-public-key-hash (P2PKH), public-key (P2PK), multi-signature (P2MS) limited to 15 keys, pay-to-script-hash (P2SH), pay-to-witness-public-key-hash (P2WPKH) - This was a feature of Segwit which stands for Segregated Witness and data output Null Data (OP_RETURN), which are described in more detail in the following sections.
The last type is special and we call it a non-standard transaction.

Simplified explanation of transaction types for beginners.

P2PKH: "Pay To Public Key Hash" - This is how a big percentage of transactions are made. You are requiring the sender to supply a valid signature (from the private key) and public key. The transaction output script will use the signature and public key after checking the hash of the provided public key with previous output, and through some cryptographic functions will check if the signature is valid, if it was, then the funds will be spendable. This method conceals your public key in the form of a hash for extra security. If the spending condition is set to present a public key hash, then it is a P2PKH TX, and you have the std Op_Dup, Op_Hash160,... structure.

P2PK: "Pay To Public Key" - Unlike P2PKH that contained the hash of public key; this script contains the public key itself. Anyone using this method to send funds over the P2P network is showing people their public key in the transaction details. The spending condition only requires you to present your public key and signature. The public key would be recognized by your wallet (following the above mentioned coding scheme) as „type 1“ address.

P2SH: "Pay To Script Hash" - became a standard script in April 2012. The outputs of a transaction are just hash of scripts known as redeemscript that, if are executed with specific parameters, will result in a boolean of true or false. If a miner runs the output script with the supplied parameters and results in true, the money will be sent to your desired output. P2SH is used for multi-signature wallets making the output scripts logic that checks for multiple signatures before accepting the transaction. P2SH can also be used to allow anyone, or no one, to spend the funds. If the output script of a P2SH transaction is just 1 for true, then attempting to spend the output without supplying parameters will just result in 1 making the money spendable by anyone who tries. This also applies to scripts that return 0, making the output spendable by no one.

P2WPKH: "Pay To Witness Public Key Hash" - This was a feature of segwit which stands for Segregated Witness. Instead of using scriptSig parameters to check the transaction validity, there is a new part of the transaction called witness where the validity occurs. In 2015, Pieter Wuille introduced a new feature to bitcoin called Segregated Witness, also known by its abbreviated name, Segwit. Basically, Segregated Witness moves the proof of ownership from the scriptSig part of the transaction to a new part called the witness of the input.

P2MS: "MultiSignature" - (multisig) refers to requiring more than one key to authorize a Bitcoin transaction and was first applied to Bitcoin addresses in 2013. Generally used to divide up responsibility for possession of bitcoins. Standard transactions on the Bitcoin network could be called “single-signature transactions,” because transfers require only one signature — from the owner of the private key associated with the Bitcoin address. However, the Bitcoin network supports much more complicated transactions that require the signatures of multiple people before the funds can be transferred. These are often referred to as M-of-N transactions. The idea is that Bitcoins become “encumbered” by providing addresses of multiple parties, thus requiring cooperation of those parties in order to do anything with them. These parties can be people, institutions or programmed scripts. Became a standard script in January 2012.

NULL DATA: (OP_RETURN) - transaction type relayed and mined by default in Bitcoin Core 0.9.0 and later that adds arbitrary data to a provably unspendable pubkey script that full nodes don’t have to store in their UTXO database. Anyone can use a NULL DATA script to add some arbitrary data to a transaction, so you can find them scattered around the blockchain. We have to remember that not all miners accept transactions with null-data and not all nodes relay them. (OP_RETURN) outputsLook for empty outputs when browsing the blockchain, as NULL DATA scripts are almost always placed on empty outputs (because the outputs are made unspendable by the lock).
Here is a web page with a list of metadata recently embedded in the bitcoin blockchain using OP_RETURN outputs: http://coinsecrets.org/

Non-Standart - to include this type of transaction to the Bitcoin Blockchain, an agreement has to be reached with a miner: the non-standard transaction will be then included in the blockchain when the miner resolves the block. Depends on the hash rate from the miner it can be quite a while taking into consideration very high actual difficulty which is rising constantly from the start of Bitcoin. Of course, miner will take a proper fee for the non-standard transaction.



The addresses are generated from the hex pubkey a cool playground here:  http://gobittest.appspot.com/Address


Extended explanation of Bitcoin transaction types for more advanced users.

Pay-to-PubKey - (P2PK) is a simpler form of a bitcoin payment than pay-to-public-key-hash. With this script form, the public key itself is stored in the locking script, rather than a public-key-hash as with P2PKH earlier, which is much shorter. P2PK is a script pattern that locks an output to a public key. Despite being the simplest script for locking bitcoins to someone's public key, P2PK is not used as much as the similar (yet more complex) P2PKH script. This is because the original Bitcoin Core miner would use P2PK for the block reward when constructing a candidate block. You'll most commonly find P2PK in coinbase transactions in the earlier blocks in the blockchain.



Pay-to-Public-Key-Hash - (P2PKH) The vast majority of transactions processed on the bitcoin network were P2PKH transactions. These contain a locking script that encumbers the output with a public key hash, more commonly known as a bitcoin address. Transactions that pay a bitcoin address contain P2PKH scripts. An output locked by a P2PKH script can be unlocked (spent) by presenting a public key and a digital signature created by the corresponding private key.



P2PKH is the default script used by wallets when you want to "send" someone bitcoins, so you can find it in most blocks in the blockchain. This script pattern is used to "send" someone bitcoins. It's the most common script used for locking an output to someone's public key. It is similar to P2PK, but the lock contains the hash of a public key instead (and not the public key itself). Every time you send bitcoins to an address that starts with a 1 you are creating a P2PKH locking script.



Pay-to-ScriptHash - (P2SH) was introduced in Bitcoin Improvement Proposal 16 (BIP 16) by Gavin Andresen, and it resulted in a new ‘standard’ transaction type for the Bitcoin scripting system. The purpose of P2SH, according to Andresen: ‘Is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer’.



In the example above, Bob generates a redeem script, hashes the redeem script to produce the redeem script hash and provides the hash to Alice. Alice can now then create a P2SH-style output containing Bob’s redeem script hash.

P2SH transaction type produces a number of advantages, such as:

The sender can fund any arbitrary redeem script without knowing what the spending conditions attached to the script are. This is an appropriate result because the sender of the transaction does not care how sent funds will be spent in the future. This is an issue for the recipient, who does care about conditions for further spending. The reduced transaction fee for the sender of the funds. Transaction fees are directly proportional to the size of a transaction, and a cryptographic hash of a fixed length allows the sender to send funds to any arbitrary redeem script without worrying about paying higher fees. It is the recipient’s responsibility to determine how large their spending transaction will be and how much it will cost, as they have to include the redeem script in order to spend funds. In other words, the burden of constructing the script and bearing the transaction fee of a long script is shifted to the recipient.



A common implementation of the P2SH function is the multi-signature address script. This script requires that a transaction possess more than one digital signature in order to prove ownership, and by extension spend funds. With P2SH transactions, the locking script is replaced with a redeem script hash. This hash derives from a redeem script, which functions similarly to the PubKey Script in that it too also contains conditions that must be satisfied before the output can be spent. When a transaction attempting to spend the UTXO is later initiated, the input must contain the PubKey Script (that contains the redeem script hash) and the unlocking script. In P2SH transactions, the script that houses the conditions for spending the output, which is the redeem script, is not presented in the locking script. Instead, only the hash (the redeem script hash) is included in the locking script, the redeem script itself is presented as part of the unlocking script when the output is spent. This has the effect of, as Andresen noted in BIP 16, of moving the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer.



Benefits of pay-to-script-hash:

The pay-to-script-hash feature offers the following benefits compared to the direct use of complex scripts in locking outputs:
- Complex scripts are replaced by shorter fingerprints in the transaction output, making the transaction smaller.
- Scripts can be coded as an address, so the sender and the sender’s wallet don’t need complex engineering to implement P2SH.
- P2SH shifts the burden of constructing the script to the recipient, not the sender.
- P2SH shifts the burden in data storage for the long script from the output (which is in the UTXO set and therefore affect memory) to the input (only stored on the blockchain).
- P2SH shifts the burden in data storage for the long script from the present time (payment) to a future time (when it is spent).
- P2SH shifts the transaction fee cost of a long script from the sender to the recipient, who has to include the long redeem script to spend it.
- P2WSH similar to P2SH but the hash of the script is different and the redeemscript itself goes in witness.
- P2SH-P2WPKH nested SegWit (workarounds) where it is similar to P2WPKH but the whole thing is put inside of a redeem script and hashed.
- P2SH-P2WSH same as previous one but for P2WSH.

Multi-Signature - (P2MS) scripts set a condition where N public keys are recorded in the script and at least M of those must provide signatures to release the encumbrance. This is also known as an M-of-N scheme, where N is the total number of keys and M is the threshold of signatures required for validation. For example, a 2-of-3 multi-signature is one where three public keys are listed as potential signers and at least two of those must be used to create signatures for a valid transaction to spend the funds.



At this time, standard multi-signature scripts are limited to at most 15 listed public keys, meaning you can do anything from a 1-of-1 to a 15-of-15 multi-signature or any combination within that range. The limitation to 15 listed keys might be lifted by the time this book is published, so check the isStandard() function to see what is currently accepted by the network.



Pay-to-Witness-Public-Key-Hash - (P2WPKH) has the same semantics as P2PKH, except that the signature is not placed at the same location as before. Segregated Witness (SegWit) moves the proof of ownership from the scriptSig part of the transaction to a new part called the witness of the input. Before SegWit the transaction signature was used in the calculation of the transaction id. The signature contains the same information as a P2PKH spend but is located in the witness instead of the scriptSig. The scriptPubKey is modified from.


A native P2WPKH address has prefix bc1q for Bitcoin mainnet. It uses the same public key format as P2PKH, with a very important exception: the public key used in P2WPKH MUST be compressed, i.e. 33 bytes in size, and starting with a 0x02 or 0x03. The P2WPKH scriptPubKey is always 22 bytes. It starts with an OP_0, followed by a canonical push of the keyhash (i.e. 0x0014{20-byte keyhash}).



P2WPKH address should be used when only 1 public key is used to receive payment (like a standard P2PKH address). Because the SegWit signature generating algorithm (described in BIP143) covers the value of the input being spent, a transaction spending a SegWit utxo can be signed securely by an air-gapped light-weight wallet or by a hardware wallet. P2WPKH addresses are Bech32-encoded according to BIP143: they start with bc1q.. for Bitcoin mainnet and are somewhat longer than traditional P2PKH addresses.

NULL DATA - (OP RETURN) is a script opcode which can be used to write arbitrary data on the blockchain and also to mark a transaction output as invalid. Since any outputs with OP_RETURN are provably unspendable, OP_RETURN outputs can be used to burn bitcoins. In version 0.9 of the Bitcoin Core client, a compromise was reached with the introduction of the OP_RETURN operator.



OP_RETURN allows developers to add 40 bytes of nonpayment data to a transaction output. However, unlike the use of “fake” UTXO, the OP_RETURN operator creates an explicitly provably unspendable output, which does not need to be stored in the UTXO set. OP_RETURN outputs are recorded on the blockchain, so they consume disk space and contribute to the increase in the blockchain’s size, but they are not stored in the UTXO set and therefore do not bloat the UTXO memory pool and burden full nodes with the cost of more expensive RAM. Keep in mind that there is no “unlocking script” that corresponds to OP_RETURN that could possibly be used to “spend” an OP_RETURN output.



The whole point of OP_RETURN is that you can’t spend the money locked in that output, and therefore it does not need to be held in the UTXO set as potentially spendable—OP_RETURN is provably un-spendable. OP_RETURN is usually an output with a zero bitcoin amount because any bitcoin assigned to such an output is effectively lost forever. If an OP_RETURN is encountered by the script validation software, it results immediately in halting the execution of the validation script and marking the transaction as invalid. Thus, if you accidentally reference an OP_RETURN output as an input in a transaction, that transaction is invalid. A standard transaction (one that conforms to the isStandard() checks) can have only one OP_RETURN output. However, a single OP_RETURN output can be combined in a transaction with outputs of any other type. Stealth addresses offer another example of OP_RETURN in action. This scheme enables payments to be received without publicly revealing the receiver’s public key or address. Data needed to make this system work are encoded within a call to OP_RETURN. In essence, Bitcoin does double duty as a secure messaging protocol.



You can use NULL DATA for data storage, because the standard script allows for a data push at the end.
So if you want to add some arbitrary data to a transaction; include an extra (empty) output, and place a NULL DATA locking script on it:



Non Standart - to include this type of transaction to the Bitcoin Blockchain, an agreement has to be reached with a miner: the non-standard transaction will be then included in the blockchain when the miner resolves the block. Depends on the hash rate from the miner it can be quite a while taking into consideration very high actual difficulty which is rising constantly from the start of Bitcoin. Of course, miner will take a proper fee for the non-standard transaction.

Bitcoin Transaction Types:



https://learnmeabitcoin.com/glossary/p2pk
https://learnmeabitcoin.com/glossary/p2ms
https://learnmeabitcoin.com/glossary/p2sh
https://learnmeabitcoin.com/glossary/nulldata
https://learnmeabitcoin.com/glossary/p2pkh
https://www.mycryptopedia.com/p2sh-pay-to-script-hash-explained/
https://bitzuma.com/posts/op-return-and-the-future-of-bitcoin/
https://www.cryptocompare.com/wallets/guides/bitcoin-transactions-pay-to-address-pay-to-public-key-hash/
https://www.cryptocompare.com/coins/guides/bitcoin-transactions-pay-to-script-hash/
https://www.cryptocompare.com/coins/guides/what-happens-to-a-bitcoin-transaction/
https://www.cryptocompare.com/coins/guides/how-does-a-bitcoin-transaction-work/
https://www.cryptocompare.com/coins/guides/what-are-the-bitcoin-transaction-types/
https://bitcoin.stackexchange.com/questions/64733/what-is-p2pk-p2pkh-p2sh-p2wpkh-eli5
https://bitcoin.stackexchange.com/questions/72194/why-dont-p2pk-scripts-have-their-own-address
http://bitcoinscri.pt/pages/segwit_native_p2wpkh_address
https://programmingblockchain.gitbook.io/programmingblockchain/other_types_of_ownership/p2wpkh_pay_to_witness_public_key_hash
https://en.bitcoin.it/wiki/Multisignature
https://bitcoin.org/en/glossary/null-data-transaction

[wwzsocki]

I will try to add frequently multiple actualizations and additional information to this thread about the transaction types, starting from the oldest one and pushing forward to the latest developments. I didn't know or haven't expected that this subject will be so comprehensive and I had to skip a lot of useful information about particular addresses to keep the OP in an interesting form which is not too long, because as we know, long once tire us very quickly and don't work so god as much shorter/compressed articles.

If there are any questions about the addresses or suggestions regarding the thread itself, please be so kind and let me know in the comments. I will try to answer all questions and frequently update the thread with additional info, like: how the particular scripts look like, how they look like, are built or how many transactions from each kind we have actually? As I said before there are hundreds of topics to discuss regarding Bitcoin addresses.

[tbct_mt2]

There are so many technical terms that I have not known before reading this topic, so thank you for making this one, wwzsocki. I still wonder your topic belongs to Bitcoin technical support board or Beginners & help board. I don't have issue to see your topic here, because it is certainly helpful for newbies, just want to know that such topic can belong to Bitcoin technical support board or not.

[ABCbits]

If your aim is beginner, then i think you should simplify it even further or more neat formatting to make it's easier or less boring to read.

I still wonder your topic belongs to Bitcoin technical support board or Beginners & help board.

This topic clearly not belongs to Beginners & Help section & IMO doesn't belong to Bitcoin Technical Support as well since it's too detailed.

[Theb]

I do have to agree with ETFbitcoin here you must simplify it further since even with the infographics provided the topic got a little deeper for newbies to understand each type of transactions Bitcoin have. Another suggestion is adding another topic about "Off-chain" transactions which newbies also needs to understand, not every method of sending/receiving cryptocurrencies requires the use of Blockchain some 3rd party wallet providers like Coinbase offers up off-chain transactions for their users which gives them the ability to send Bitcoin to another Coinbase user instantly and freely. Newbies needs to learn this method as well if they are trying to avoid network fees at all.

[wwzsocki]

If your aim is beginner, then i think you should simplify it even further or more neat formatting to make it's easier or less boring to read.

I still wonder your topic belongs to Bitcoin technical support board or Beginners & help board.

This topic clearly not belongs to Beginners & Help section & IMO doesn't belong to Bitcoin Technical Support as well since it's too detailed.

That's the problem that there is no way to simplify this text further.

I did all what possible to make it short and informative and still, I had to remove many interesting details about Bitcoin transactions and their particular types.

This subject was already discussed in the Bitcoin Technical Support board and I thought it could be good for beginners, especially if they desire to learn something new or expand the knowledge about Bitcoin transactions.

Additionally, I counted on moderators, that they will move this thread if this board is not the best choice and on members like you, who will comment this.

I think I will leave it here for a while and if there will be more comments to move it to Bitcoin Technical Discussion, then I will do it or let mods decide in the end.

[wwzsocki]

I do have to agree with ETFbitcoin here you must simplify it further...

When three high-rank members suggest that something needs to be changed or simplified, there is no point in discussing, only one has to do it, so I thought a bit and came to the conclusion that I will divide this article into two parts for less and more advanced users. So far I've added this:

Simplified explanation of transaction types for beginners.

P2PKH: "Pay To Public Key Hash" - This is how transactions are made. You are requiring the sender to supply a valid signature (from the private key) and public key. The transaction output script will use the signature and public key and through some cryptographic functions will check if it matches with the public key hash, if it does, then the funds will be spendable. This method conceals your public key in the form of a hash for extra security. If the spending condition is set to present a public key hash, then it is a P2PKH TX, and you have the std Op_Dup, Op_Hash160,... structure.

P2PK: "Pay To Public Key" - This is similar to P2PKH; the difference is that it does not conceal your public key. Anyone using this method to send funds over the P2P network is showing people their public key in the transaction details. When the spending condition only requires you to present your public key and signature, then it is a P2PK transaction. The public key would be recognized by your wallet (following the above mentioned coding scheme) as „type 1“ address.

P2SH: "Pay To Script Hash" - The outputs of a transaction are just scripts that, if are executed with specific parameters, will result in a boolean of true or false. If a miner runs the output script with the supplied parameters and results in true, the money will be sent to your desired output. P2SH is used for multi-signature wallets making the output scripts logic that checks for multiple signatures before accepting the transaction. P2SH can also be used to allow anyone, or no one, to spend the funds. If the output script of a P2SH transaction is just 1 for true, then attempting to spend the output without supplying parameters will just result in 1 making the money spendable by anyone who tries. This also applies to scripts that return 0, making the output spendable by no one.

P2WPKH: "Pay To Witness Public Key Hash" - This was a feature of segwit which stands for Segregated Witness. Instead of using scriptSig parameters to check the transaction validity, there is a new part of the transaction called witness where the validity occurs. In 2015, Pieter Wuille introduced a new feature to bitcoin called Segregated Witness, also known by it's abbreviated name, Segwit. Basically, Segregated Witness moves the proof of ownership from the scriptSig part of the transaction to a new part called the witness of the input.

P2MS: "MultiSignature" - (multisig) refers to requiring more than one key to authorize a Bitcoin transaction and was first applied to Bitcoin addresses in 2013. Generally used to divide up responsibility for possession of bitcoins. Standard transactions on the Bitcoin network could be called “single-signature transactions,” because transfers require only one signature — from the owner of the private key associated with the Bitcoin address. However, the Bitcoin network supports much more complicated transactions that require the signatures of multiple people before the funds can be transferred. These are often referred to as M-of-N transactions. The idea is that Bitcoins become “encumbered” by providing addresses of multiple parties, thus requiring cooperation of those parties in order to do anything with them. These parties can be people, institutions or programmed scripts.

NULL DATA: (OP_RETURN) - transaction type relayed and mined by default in Bitcoin Core 0.9.0 and later that adds arbitrary data to a provably unspendable pubkey script that full nodes don’t have to store in their UTXO database. Anyone can use a NULL DATA script to add some arbitrary data to a transaction, so you can find them scattered around the blockchain. We have to remember that not all miners accept transactions with null-data and not all nodes relay them. (OP_RETURN) outputsLook for empty outputs when browsing the blockchain, as NULL DATA scripts are almost always placed on empty outputs (because the outputs are made unspendable by the lock).
Here is a web page with a list of metadata recently embedded in the bitcoin blockchain using OP_RETURN outputs: http://coinsecrets.org/

Non Standart - to include this type of transaction to the Bitcoin Blockchain, an agreement has to be reached with a miner: the non-standard transaction will be then included in the blockchain when the miner resolves the block. Depends on the hash rate from the miner it can be quite a while taking into consideration very high actual difficulty which is rising constantly from the start of Bitcoin. Of course, miner will take a proper fee for the non-standard transaction.



The addresses are generated from the hex pubkey a cool playground here:  http://gobittest.appspot.com/Address

Of course, I will Null Data and Non-standard transactions to this shortlist when I write it finally. What you think is better now?

[pooya87]

in my opinion it is wrong to call these "transaction" types because these are "script" types. in bitcoin we only have 1 form of transaction and if you wanted to be so strict you could say 2 types: legacy and SegWit (a tx containing witness data in it). otherwise since the structure of a transaction is exactly the same we can't categorize them as different "transaction" types.

P2MS

this is the first time i am hearing this term. where did you get it from?
is it the one where you place the redeem script (m<pub1><...><pubn>n checkmultisig) inside the scriptPub?

P2PKH: "Pay To Public Key Hash" - This is how a big percentage of transactions are made. You are requiring the sender to supply a valid signature (from the private key) and public key. The transaction output script will use the signature and public key and after checking the hash of the provided public key with previous output, through some cryptographic functions will check if the signature is valid, if it was, then the funds will be spendable. This method conceals your public key in the form of a hash for extra security. If the spending condition is set to present a public key hash, then it is a P2PKH TX, and you have the std Op_Dup, Op_Hash160,... structure.

FTFY

P2PK: "Pay To Public Key" - Unlike P2PKH that contained the hash of public key; this script contains the public key itself. Anyone using this method to send funds over the P2P network is showing people their public key in the transaction details. The spending condition only requires you to present your public key and signature. The public key would be recognized by your wallet (following the above mentioned coding scheme) as „type 1“ address.

the first crossed out part is misleading. you reveal your public key whenever you spend any of these outputs.

P2SH: "Pay To Script Hash" - The outputs of a transaction are just hash of a scripts known as redeem script that, if are executed with specific parameters, will result in a boolean of true or false. If a miner node runs the output script with the supplied parameters and results in true, the money will be sent to your desired output. P2SH is commonly used forin multi-signature wallets making the output scripts logic that checks for multiple signatures before accepting the transaction. P2SH can also be used to allow anyone, or no one, to spend the funds. If the output script of a P2SH transaction is just 1 for true, then attempting to spend the output without supplying parameters will just result in 1 making the money spendable by anyone who tries. This also applies to scripts that return 0, making the output spendable by no one.

FTFY

missing:
- P2WSH similar to P2SH but the hash of the script is different and the redeemscript itself goes in witness
- P2SH-P2WPKH nested SegWit (workarounds) where it is similar to P2WPKH but the whole thing is put inside of a redeem script and hashed
- P2SH-P2WSH same as previous one but for P2WSH
read more: https://bitcoincore.org/en/segwit_wallet_dev/

Non Standartd

[wwzsocki]

in my opinion it is wrong to call these "transaction" types because these are "script" types. in bitcoin we only have 1 form of transaction and if you wanted to be so strict you could say 2 types: legacy and SegWit (a tx containing witness data in it). otherwise since the structure of a transaction is exactly the same we can't categorize them as different "transaction" types.

As you see from the source links everybody calls these as transaction types and this is why I did the same. Everything has been explained in the OP, what is the script, transaction, etc, so I think there should be no problem with understanding what is what.

P2MS this is the first time i am hearing this term. where did you get it from?

I provided all sources as always in the post footer, but here it is: https://learnmeabitcoin.com/glossary/p2ms

is it the one where you place the redeem script (m<pub1><...><pubn>n checkmultisig) inside the scriptPub?

FTFY

Thanks for FTFY but to be honest I cut these sentences by myself to make it shorter and easy to understand. As you see this is in the first part for beginners.

Of course, I should do it properly, without changing the meaning completely and I thought is ok but added your corrections too.

missing:
- P2WSH similar to P2SH but the hash of the script is different and the redeemscript itself goes in witness
- P2SH-P2WPKH nested SegWit (workarounds) where it is similar to P2WPKH but the whole thing is put inside of a redeem script and hashed
- P2SH-P2WSH same as previous one but for P2WSH

Members advised above to make it shorter, so I did it and removed a couple of additional sentences. I have talked about this in my post above, that I found it really hard and to be honest this article was a lot longer in original form. I had to make compromises and cut out all I found or thought is not so important, but everything is important here and that is why I will update this thread further. Don't want to write more in the OP, only add all additional information in the posts during the discussion. Just like now.

[pooya87]

As you see from the source links everybody calls these as transaction types and this is why I did the same. Everything has been explained in the OP, what is the script, transaction, etc, so I think there should be no problem with understanding what is what.

i wasn't trying to say you were wrong, that is why i said it is my "opinion".

I provided all sources as always in the post footer, but here it is: https://learnmeabitcoin.com/glossary/p2ms

thanks, i forgot to check out the links.

Members advised above to make it shorter, so I did it and removed a couple of additional sentences. I have talked about this in my post above, that I found it really hard and to be honest this article was a lot longer in original form. I had to make compromises and cut out all I found or thought is not so important, but everything is important here and that is why I will update this thread further. Don't want to write more in the OP, only add all additional information in the posts during the discussion. Just like now.

well, i think when you begin to look under the hood it automatically becomes a lot more complicated, when the part  you are looking at is scripts, then the complication is even more. so don't try too hard to make it any easier, that is impossible. i guess focusing on being short and complete is better.
you've already done a good job summarizing and gathering all this here though. kudos for that.

[wwzsocki]

...you've already done a good job summarizing and gathering all this here though. kudos for that.

I was surprised how detailed your posts were because the majority of people read only the topic line and max a couple of sentences before they comment.
Thanks for your help one more time, you've made a good job too. It's a pleasure to discuss with members like you.

I see that you have a lot of knowledge about this subject and want to ask you about it. Are you a programmer or is your profession related to cryptocurrencies, like coding or something?

Typical crypto enthusiast doesn't have such knowledge. I started this thread when I was confused with segwit addresses some time ago. I was writing it for some time because transactions and scripts are quite a challenge for an average cryptocurrencies user, especially with no programming knowledge.

This is the best way for me to expand my knowledge and learn constantly new things about crypto. Simply when I don't know something and especially when I have problems with something then start to study this subject, until I know maybe not everything but so much that I fill me confident.

[pooya87]

I see that you have a lot of knowledge about this subject and want to ask you about it. Are you a programmer or is your profession related to cryptocurrencies, like coding or something?

no, even my field of study has nothing to do with programming. i just always liked computers so at some point in my life i picked up programming as a hobby and slowly learnt more about it (on my own). also ever since i found out about bitcoin, i was fascinated so i also started looking under the hood and slowly learned more about the technical aspect of it. you can call it being "self taught".
although i still have a lot to learn, but i certainly enjoy it.

[wwzsocki]

I tried to find information about new developments and what is the future for the Bitcoin transactions because they are evolving constantly during the time.

Unfortunately, I wasn't able to find anything and even was afraid that I missed something, but all comments in this thread assured me that I have them all so far.

If anybody knows something about Bitcoin development and the future of transactions then please share.

[wwzsocki]

...This topic clearly not belongs to Beginners & Help section & IMO doesn't belong to Bitcoin Technical Support as well since it's too detailed.

I don't know how I missed this sentence in your post when I was reading for the first time?

Sometimes is hard to choose the best-suited board for published text and I always count in such a situation for comments like this one or moderators to move the thread to the right section.

I think you are right, so I will move it to the suggested Bitcoin Technical Support board and look there for more activity and discussion.

[Stedsm]

I tried to find information about new developments and what is the future for the Bitcoin transactions because they are evolving constantly during the time.

Unfortunately, I wasn't able to find anything and even was afraid that I missed something, but all comments in this thread assured me that I have them all so far.

If anybody knows something about Bitcoin development and the future of transactions then please share.

The network clogs and mining pool games of increasing transaction fees are few of the most important topics I'm trying to get a resolution to. Please also try to focus on these things while sharing knowledge about the type of scripts and transactions. Great thread, appreciated. There's been a debate about Bitcoin's block size increment over time to involve more and more transactions, do you believe that's actually a form that can scale it in the long run considering the hyper hefty blockchain size that's technically too high for an average sized hard disk of a PC if people decide to run a node through downloading the whole blockchain?

[wwzsocki]

...do you believe that's actually a form that can scale it in the long run considering the hyper hefty blockchain size that's technically too high for an average sized hard disk of a PC if people decide to run a node through downloading the whole blockchain?

To be honest, debate about the size of the Bitcoin block does not bring anything and even if, then it is only a temporary solution. With the time passing, we see new problems emerging and we still haven't solved old once. We have the Lightning Network running, which is a good thing of course and we have to help, to get it fully adopted, but still, this does not solve any of the problems with: transactions, speeds onchain, blocks and blockchain size, etc. Everybody was so focused on the LN start that we have forgotten about other important aspects or just naively believed, that Lightning will magically solve all these problems.

Bitcointalk was the place for the biggest discussions about BTC development and future plans, so if there are any discussions actually ongoing, please point me to them because  
I would really like to know what the future plans for Bitcoin development are and what is the (so-called) roadmap if there is any?

[Stedsm]

...do you believe that's actually a form that can scale it in the long run considering the hyper hefty blockchain size that's technically too high for an average sized hard disk of a PC if people decide to run a node through downloading the whole blockchain?

To be honest, debate about the size of the Bitcoin block does not bring anything and even if, then it is only a temporary solution. With the time passing, we see new problems emerging and we still haven't solved old once. We have the Lightning Network running, which is a good thing of course and we have to help, to get it fully adopted, but still, this does not solve any of the problems with: transactions, speeds onchain, blocks and blockchain size, etc. Everybody was so focused on the LN start that we have forgotten about other important aspects or just naively believed, that Lightning will magically solve all these problems.

I believe LN is a solution for those believing in the offchain transactions with lesser fee involved, but even after doing it through LN can't resolve the size and scaling just because we are bound to take those transactions online in the future and add that size to our current blockchain, I believe that compression of Blockchain could be the only possible scenario that could help but don't really know how it'd be put in action by the devs if they ever decide to do so because the biggest risk of doing that will be - losing some old (and even new) transactional data possibly if it poses a glitch that could remove a piece of the transaction to reduce the size through compressing it, nothing else comes to my mind as of now.

Bitcointalk was the place for the biggest discussions about BTC development and future plans, so if there are any discussions actually ongoing, please point me to them because  
I would really like to know what the future plans for Bitcoin development are and what is the (so-called) roadmap if there is any?

Well, to what I've seen, these guys always try to dig a well whenever fire takes place so I haven't clearly seen any such development related debates especially through developers (maybe they are doing it behind the curtains) or it is possible that they believe in actions rather than just words.

[hd49728]

The topic on types of bitcoin transaction is meaningful, but after reading I still don't know that how cheaper transaction with Segwit address is in comparison with Legacy address.

If you can, please consider adding this part into your topic. Personally, I would prefer to have more technical things on your topic, includes what I discussed above.

[pooya87]

The topic on types of bitcoin transaction is meaningful, but after reading I still don't know that how cheaper transaction with Segwit address is in comparison with Legacy address.

every transaction has different parts, version, input list which include previous transaction hash, signature..., output list,... if we simplify it to something like this:

Code:

[version][outpoint][signature][outscript][locktime]

in legacy transactions, this is the structure and the entire thing is used for calculating the size and paying the fee based on that.
when you use SegWit this structure changes a little

Code:

[version][outpoint][outscript][signature][locktime]

and the size is calculated by using everything except the signature so you'll end up with a smaller size and pay a smaller fee in total.

of course the more correct thing to say is that we are no longer using "size" we are using "virtual size" which is 1/4 of the tx weight which is calculated by using 3x base size (without witness) + total size (with witness)

[wwzsocki]

...If you can, please consider adding this part into your topic. Personally, I would prefer to have more technical things on your topic, includes what I discussed above.

Thanks for this suggestion but I have to take all suggestions from members into consideration and some of them think that this thread is too overwhelming already and others (like you) wish to have even more detailed information.

As you see there is no way to satisfy everybody and the best solution will be to leave this thread as it is and only add new content in the comments during discussion.

But I will not leave you empty-handed and will try to write a new thread about transaction sizes and fees, additionally, there are many interesting things to talk about, like "vbytes" when it goes to transaction sizes.

The topic on types of bitcoin transaction is meaningful, but after reading I still don't know that how cheaper transaction with Segwit address is in comparison with Legacy address.

every transaction has different parts, version, input list which include previous transaction hash, signature..., output list,... if we simplify it to something like this:

Code:

[version][outpoint][signature][outscript][locktime]

in legacy transactions, this is the structure and the entire thing is used for calculating the size and paying the fee based on that.
when you use SegWit this structure changes a little

Code:

[version][outpoint][outscript][signature][locktime]

and the size is calculated by using everything except the signature so you'll end up with a smaller size and pay a smaller fee in total.

of course the more correct thing to say is that we are no longer using "size" we are using "virtual size" which is 1/4 of the tx weight which is calculated by using 3x base size (without witness) + total size (with witness)

Great explanation, short and detailed. I think even a newbie can now understand why fees are smaller in SegWit transactions.

It's because the smaller size which equals a smaller fee.