Bitcoin Forum

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

https://talkimg.com/images/2023/11/21/F1L9c.png

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.

https://talkimg.com/images/2023/11/21/F1hXP.png

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.

https://talkimg.com/images/2023/11/21/F1otq.png

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.

https://talkimg.com/images/2023/11/21/F14cj.png

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.

https://talkimg.com/images/2023/11/21/F150G.png

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’.

https://talkimg.com/images/2023/11/21/F19MD.png

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.

https://talkimg.com/images/2023/11/21/F1BJf.png

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.

https://talkimg.com/images/2023/11/21/F1gpZ.png

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.

https://talkimg.com/images/2023/11/21/F18S8.png

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.

https://talkimg.com/images/2023/11/21/F1K33.png

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}).

https://talkimg.com/images/2023/11/21/F1bBw.png

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.

https://talkimg.com/images/2023/11/21/F1DX9.png

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.

https://talkimg.com/images/2023/11/21/F1OzN.png

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.

https://talkimg.com/images/2023/11/21/F1Wha.png

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:

https://talkimg.com/images/2023/11/21/F1e0o.png

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://talkimg.com/images/2023/11/21/F10mT.png

---

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

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.

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.

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.


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 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.

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.

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:


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

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.

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?

FTFY

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

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/

:P

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 provided all sources as always in the post footer, but here it is: https://learnmeabitcoin.com/glossary/p2ms


https://talkimg.com/images/2023/11/21/F1xp1.png


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.


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.

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

thanks, i forgot to check out the links.

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.

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.

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.

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.

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.

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?

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?

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.


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. :)

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.

every transaction has different parts, version, input list which include previous transaction hash, signature..., output list,... if we simplify it to something like this:
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
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)

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.


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.

Lately, I have talked about the full nodes count and how the "hyper hefty blockchain size" will affect the future number of nodes and Bitcoin itself.

To be honest we haven't found the answer about the influence on BTC itself but full nodes and in particular their quantity looks to be not affected.

Despite everything, the number of full nodes increases every year and today we have already 9137 according to https://bitnodes.earn.com/.

https://i.imgur.com/pjBlOFP.png

It looks like a phenomenon to me.

The number of all full nodes is actually much higher. This website lists nodes which are reachable for others, meaning that they can share blocks with other users. Some people don't know how to configure their networks properly or might intentionally block it to save the bandwidth.

The geographical distribution of bitcoin full nodes that visually presented by the image, gives us the fact that China has much less impacts on bitcoin, technically (at least). What we saw on social media, news that China has significant effects on bitcoin (positively or negatively depends on different periods) are very incorrectly.

China obviously has some of biggest bitcoin mining farms but technically impacts on bitcoin is much smaller than what we usually thought.

In the top ten nations: 3 come from Asian continent, 2 come from American continent, and 5 come from European continent.

Exactly, I was also surprised to see Europe at the first place with 32,27% of all full nodes (exactly 2987) in countries like Germany, France, and the Netherlands. The second spot with 25.29% which is exactly 2341 full nodes goes to the USA and China is at 6th place with 3,53% which gives only 327 full nodes.

https://i.imgur.com/798PX7P.png
https://bitnodes.earn.com/

Is really surprising to see China at 6th place only with 327 full nodes because I was sure that the biggest amount will be in the biggest mining farms, but to be honest I don't know if mining is actually allowed there or not because China banned and unbanned BTC and mining so many times that I don't know what is the real situation there?

https://i.imgur.com/TK2ap9X.png
https://bitnodes.earn.com/nodes/live-map/

Miners don't have to run bitcoin full nodes for their farms. They can do this or not, this is not a must for bitcoin mining farms.
From my understanding, China has biggest mining farms globally, but they are not the leading nation in blockchain technology, and it makes sense after looking at total bitcoin full nodes in China.

From that perspective, it is reasonable to see top nations are leading ones in crypto and blockchain technology, the USA, Germany, France, Netherlands.

every miner must connect to a bitcoin full node to receive a constructed block to mine, whether they connect to a full node that they run themselves directly or through an intermediary like a pool is the only difference. for mining farms that own a lot of hashrate it is more secure and profitable to connect to a node they control instead of trusting a pool and also having to pay fees to that pool!

I don't think this is the reason why there are not so many full nodes in China. What @Pooya87 has written is very important:


From my understanding, there are not so many full nodes in China because they need only a couple of them even for big mining farms. They have thousands of miners and a few or a dozen full nodes is enough for their needs. In other countries like the USA, Germany, France, Netherlands mining farms are a lot smaller and they have also a few or a dozen full nodes, just like the big once.

Now let's sum it up to better understand what I mean. There are only a few very big farms in China with only a couple of nodes and a lot more of smaller mining farms in the other countries, with the same or even bigger full nodes amounts. Additionally, all these bans for crypto mining in China for sure prevented many ordinary people from buying a miner and to start mining. So we can assume that in the other countries there is a lot more mining done by small investors on one or a few miners maximum and for safety reasons they need full nodes.

Large BTC mines in China do not translate into the number of full nodes because not every miner must be a full node and just a few or a dozen is enough, to meet their safety needs, even with hundreds of miners or more.

If someone is confused, it's probably because at least historically transactions with these scripts were referred to as 'standard multisig' or 'raw multisig'.

I think the best way to call it would be colloquial speech and that's correct because I found in posts or questions on Stackoverflow.com such words/names when it comes to the transactions itself and MultSig transactions. I have seen in discussion how people use these names like "raw" or "standard" when they talk about BTC transactions as a whole, but also in detailed talks about specific MultSig transactions. However, you will not you won't find this naming in professional publications, so I did not use these rather colloquial names and not mention them to not complicate this text anymore. Cryptocurrencies' language is evolving so fast that sometimes is hard to catch up.

This thread has been translated to the Russisch language and here is the link: Кaк paбoтaют тpaнзaкции Биткoйн и иx типы (https://bitcointalk.org/index.php?topic=5191689.0)

In my opinion, such translations confirm the quality of the text, additionally, it is also important that now monolingual people will be able to learn about the subject of Bitcoin transactions too.

Is there anything new about BTC transactions? Any innovations or maybe something needs to be added/updated to already mentioned types of BTC transactions in this thread?

I wanted to update this useful thread because is quoted many times in many other source threads and summaries.

Of course, I tried to find news about BTC transactions on my own but it seems that there were no changes or new developments regarding this matter.

I wonder if there is something planned, already in development, or maybe I just missed something when I was doing the last research?

I will be happy to hear suggestions and thanks in advance for any help provided.

any change would involve the protocol and it requires a fork. the last for we had was the SegWit soft-fork that took place mid 2017. so, no there is nothing new.

there is the Schnorr signature proposal that has been a BIP for some time now which you can check it if you haven't already. and there are 2 more BIPs that come after involving Taproot scripts.
Schnorr Signatures for secp256k1: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
Taproot: SegWit version 1 spending rules: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
Validation of Taproot Scripts: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

You can add the new feature of blockchair.com, Privacy-o-meter. It is privacy relates to how people move their bitcoins.

Privacy-o-meter, a free tool to assess the privacy level of your BTC transaction (https://bitcointalk.org/index.php?topic=5258274.0). Their document (https://blockchair.com/api/docs#link_M6) is there.

They classify transactions into following types:

• CB: Coinbase transaction
• N1: Transaction with just 1 output (either a sweep to another address by the same owner, or a transfer using a "send everything I have" option)
• N2: Transaction with 2 outputs — most common in wallets — where one of the outputs is the recipient, and the other one is the change address
• NN: Transaction with more than 2 outputs — most common in exchanges and services that use payout batching

Blockstream.info (https://blockstream.info) has similar feature as well.

• Bitcoin Privacy Improves With BTCPay Server's P2EP Implementation (https://blockstream.com/2020/04/16/en-bitcoin-privacy-improves-with-btcpay-servers-p2ep-implementation/)