what is data size of a transaction?

[uchegod-21]

I was doing research and I read this from blockchain support.

While the fee does not depend on the amount you’re sending,^{statement 1}it does depend on network conditions at the time^{statement 2}and the data size of your transaction.^{statement 3}

I separate the statements into 3 to be clear for my explanation.
If you check below you will see blockchain support how they explain data size of transaction.

Again due to the fact that a block on the bitcoin blockchain can contain no more than 1 MB of information, transaction size is an important consideration for miners. Smaller transactions are easier to validate; larger transactions take more work, and take up more space in the block. For this reason, miners prefer to include smaller transactions. A larger transaction will require a larger fee to be included in the next block[/green]

What is small transaction and what is larger transaction?
If transaction with small bitcoin is small transaction and the transaction with big bitcoin is large transaction. Then statement 1 is wrong.
Read more from Blockchain support...

[1714038575]

1714038575

[1714038575]

1714038575

[LoyceV]

miners prefer to include smaller transactions.

This isn't accurate: miners prefer transactions with the highest fee per (v)byte. The size of the transaction and total fee aren't relevant: Bitcoin block space is scarce, miners try to fill it with the transactions from which they earn the most.

What is small transaction and what is larger transaction?

Transaction sizes are measured in (v)bytes, not in Bitcoins.

If transaction with small bitcoin is small transaction and the transaction with big bitcoin is large transaction. Then statement 1 is wrong.

Statement 1 is correct. Statement 2 and 3 are also correct.

Suggestion: play around with CoinB.in's Bitcoin Fee Calculator.

[jackg]

miners prefer to include smaller transactions.

This isn't accurate: miners prefer transactions with the highest fee per (v)byte. The size of the transaction and total fee aren't relevant: Bitcoin block space is scarce, miners try to fill it with the transactions from which they earn the most.

They will try to make blocks as efficient as possible thought by including smaller transactions that don't pay as much per byte if they're only a few bytes in size and have a small amount of space to fill (in my experience this seems to happen anyway) - at most it'll only be a few per block.

[o_e_l_e_o]

While the fee does not depend on the amount you’re sending^{statement 1}

This is correct. The amount of bitcoin you are sending is largely irrelevant to how much fee you need to pay. A transaction sending 0.01 BTC might be larger and require a larger fee than a transaction sending 100 BTC, and vice versa.

it does depend on network conditions at the time^{statement 2}

This is referring to the mempool. You can get a visual representation of the mempool at these two sites: https://jochen-hoenicke.de/queue/#1,8h and https://mempool.space/. If there are lots of other transactions sitting in the mempool waiting to be mined, then you will have to pay a larger fee to be at the top of the waiting list. If, on the other hand, the mempool is empty, then you will be able to get away with a much lower fee.

and the data size of your transaction.^{statement 3}

The size or weight of the transaction depends on the number of inputs in your transaction, the number of outputs in your transaction, the type of addresses you are sending to and from, and the exact script requirements (such as a standard transaction, a multi-sig transaction, etc.) This is what is meant by the data size. The actual amount of bitcoin contained within that data is largely irrelevant.

[RickDeckard]

miners prefer to include smaller transactions.

This isn't accurate: miners prefer transactions with the highest fee per (v)byte. The size of the transaction and total fee aren't relevant: Bitcoin block space is scarce, miners try to fill it with the transactions from which they earn the most.

They will try to make blocks as efficient as possible thought by including smaller transactions that don't pay as much per byte if they're only a few bytes in size and have a small amount of space to fill (in my experience this seems to happen anyway) - at most it'll only be a few per block.

OP, to see this "tetris" in action that jackg mentions, and especially to see how a block is composed, I highly advise you to look to this[1]website (All credits should go to TryNinja, I saw his post here[2]). In that website you see two very important pieces of information : How "full" is the Mempool - all the transactions that are bound to be processed and their size (you can order by value or by (v)byte) - and how the "inner" configuration of the last mined block looks like (blocks of different sizes). If you wait around until the block is mined you'll even see a cool animation of the new block being mined!
[1]https://bits.monospace.live/
[2]https://bitcointalk.org/index.php?topic=5373221.0

[nc50lc]

I was doing research and I read this from blockchain support.
-snip-

That is quite the wrong place to do research.
You may need to go to somewhere else reputable, like the websites "The Bitcoin Wiki" and "Learn Me a Bitcoin".
Links:

• Bitcoin Wiki: https://en.bitcoin.it/wiki/Main_Page
• learnmeabitcoin: https://learnmeabitcoin.com/technical/

For example: Bitcoin Wiki has an entry about 'fee rate' under "Miner Fees" article - https://en.bitcoin.it/wiki/Miner_fees#Feerates

[o_e_l_e_o]

(you can order by value or by (v)byte)

That's certainly a cool visualization, and I was also unfamiliar with that site, but I don't understand why its default setting is to vary the size of the boxes based on the value of the transaction. Indeed, that is the exact opposite of what is actually relevant when consider blocks/mining/the mempool, and would be very confusing for any newbies, OP included. I also think coloring the blocks based on how long they have been in the mempool is dumb as well, since that metric is also irrelevant to whether or not a transaction is included.

It would be far better to make the default size of the boxes be based on the size of each transaction in vbytes, and perhaps make the color of the boxes vary depending on the fee rate each transaction pays in sats/vbyte. Then when a new block is mined, it would very obvious why each transaction was being included.

[RickDeckard]

-snip-
It would be far better to make the default size of the boxes be based on the size of each transaction in vbytes, and perhaps make the color of the boxes vary depending on the fee rate each transaction pays in sats/vbyte. Then when a new block is mined, it would very obvious why each transaction was being included.

Thinking of it, I agree with your point of view. If we think of it, the actual information provided by the color of the boxes is very basic - Everyone is able to see that the sooner the transactions enters the mempool, the longer they'll stay in it and the more "greenish/blueyish" they'll get. Not only the default selection should be in vbytes, and the color grading based in the fee rate, but whenever the block is mined it could still keep the colors of the blocks instead of turning all orange (I think I do know why it turns orange though). That way most people could see - in a very visual way - that the miners will favor transactions with higher fees than the ones who don't carry them (but will still try to optimize the block whenever they can). He could even add a small analytical regarding the average fee per block (with both biggest and smallest fee just as an extra information).

On a brighter side, this color grading is already on the backlog of the developer according to this[1] tweet. I'll try to send him some other suggestions that we've mentioned and we'll see how it goes...
[1]https://twitter.com/superenrico/status/1464653485631279107

[HCP]

What is small transaction and what is larger transaction?

If transaction with small bitcoin is small transaction and the transaction with big bitcoin is large transaction. Then statement 1 is wrong.

It's not small bitcoin or big bitcoin... it's the fee rate as mentioned above... that is to say, the number of sats per (v)byte that a given transaction is paying that will generally determine any given transactions priority.

They only have a finite amount of space in a block, so by including transactions paying the highest "rate" (not necessarily just a large total fee amount), they are more likely to receive the optimal payout for finding a block.

For arguments sake, if you only have 1,000,000 bytes of space... and you have 1 transaction that is 1,000,000 bytes and pays 0.01 BTC in fee... you think, that's a BIG fee... I'll use that one... well, the actual fee rate on that is 1,000,000 sats / 1,000,000 bytes = 1 sat/byte.

If you have 10 transactions of 100,000 bytes each paying 0.002 BTC in fees... then because their rate is 200,000 sats / 100,000 bytes = 2 sat/byte... you're better off taking the multiple "smaller" transactions with the larger rate. 10 X 0.002 = 0.02.


Outside of the logical choice being to maximise the amount of fees received, miners are essentially free to do whatever they like with regards to prioritising transactions... for instance, a miner could elect to ignore any transaction going to a specific address or group of addresses if they really wanted to... they'd be foolish to do so, because they'd be ignoring potential income, but they could do it.

[uchegod-21]

and the data size of your transaction.^{statement 3}

The size or weight of the transaction depends on the number of inputs in your transaction, the number of outputs in your transaction, the type of addresses you are sending to and from, and the exact script requirements (such as a standard transaction, a multi-sig transaction, etc.) This is what is meant by the data size. The actual amount of bitcoin contained within that data is largely irrelevant.

Thanks for remembering this for me. The article on Blockchain Support nearly confuse me.
This show why sigwit transaction is faster has less fee because the witness is separate from the 1mb block of transaction.

I have question.
If the mempool full or congested and miners start to add the transaction with high transaction fee. What will happens to the transaction with very low transaction fees if the ones with high transaction keep coming into the mempool after each one get confirm.
Will the ones with low fee need to wait until anytime or anyday the mempool will become empty. What of If the mempool stay very long without bin empty.

[pooya87]

This show why sigwit transaction is faster because the witness is separate from the 1mb block of transaction.

SegWit transactions are not faster or slower, they have smaller weight compared to similar legacy transactions which means you end up paying lower fee in comparison.
The witness is also not separate, it is part of the transaction and a part of each block in the maximum 4 MB weight.

What will happens to the transaction with very low transaction fees if the ones with high transaction keep coming into the mempool after each one get confirm.

They remain in that nodes mempool until it is their turn to be confirmed or until the node drops it after a predefined period (default is 2 weeks) or they become invalid (like in case of double spending through RBF).

[o_e_l_e_o]

In addition to pooya's reply above:

The limit on block size is not 1 MB anymore, but rather 4,000,000 weight units, which is the same as 1,000,000 virtual bytes or vbytes. Segwit transactions have a similar amount of raw data to legacy transactions (often slightly more in fact), but a smaller weight and a smaller vbyte footprint because of the way that data is counted.

It is fairly uncommon for the mempool to be so full that transactions start dropping out the bottom, or for it to take so long to confirm that they are dropped after two weeks. Additionally, you can use methods such as CPFP or transaction accelerators to boost your unconfirmed transaction and get it confirmed sooner.

[HCP]

If the mempool full or congested and miners start to add the transaction with high transaction fee. What will happens to the transaction with very low transaction fees if the ones with high transaction keep coming into the mempool after each one get confirm.
Will the ones with low fee need to wait until anytime or anyday the mempool will become empty. What of If the mempool stay very long without bin empty.

You weren't using Bitcoin in Dec 2017/Jan 2018 were you? Or indeed, for the first 4-5 months of this year?

It would seem not:

Date Registered:   2021-09-01, 11:17:57

Well, to answer your question, this graph shows the size of the mempool... basically, the amount of unconfirmed transactions... remembering that as a rough guide, 1 meg = 1 block worth of unconfirmed transactions.

source: https://www.blockchain.com/charts/mempool-size

You can see that the mempool at some points had in excess of 80 blocks worth of transactions for months on end.

So, basically, confirmation times for low fee transactions will stretch into days/weeks rather than minutes/hours. There are literally hundreds (if not thousands) of threads on this forum in the "Beginners & Help" section (and littered in the Tech Support section) about "stuck transactions": https://www.google.com/search?q=site%3Abitcointalk.org+stuck+transaction

[uchegod-21]

If the mempool full or congested and miners start to add the transaction with high transaction fee. What will happens to the transaction with very low transaction fees if the ones with high transaction keep coming into the mempool after each one get confirm.
Will the ones with low fee need to wait until anytime or anyday the mempool will become empty. What of If the mempool stay very long without bin empty.

You weren't using Bitcoin in Dec 2017/Jan 2018 were you? Or indeed, for the first 4-5 months of this year?

No. I started using bitcoin 2020. I am not good in following trend. But now I love bitcoin so much and I want to know the technical.

[DannyHamilton]

Since you're here in the "Technical" Support section of the forum asking questions of a somewhat technical nature, here's some additional information that I don't see in this thread that might be helpful to know:

You'll see people write about "the mempool" as if there is a single mempool somewhere that everyone has access to and which represents the current list of all unconfirmed transactions.  This is not how it actually works.  Every node maintains it's own mempool.  The transactions in one node's mempool will generally be pretty similar to the transactions in another node's mempool simply because they've both received the same transactions relayed throughout the entire network, and the same blocks.  However, there is no guarantee that any one node has exactly the same list of transactions in their mempool as any other.  One node may not have heard about a transaction that another node did, or one node may have already dropped a transaction from it's mempool that another node has not. While it is commonly stated that transactions will hang around in a mempool for 2 weeks, that is not a requirement of the system.  Anyone can modify or configure their software to increase or decrease the amount of time they are willing to hold transactions in their own mempool.

You'll also see people write that miners choose transactions from the mempool when building the blocks that they mine.  As you can perhaps deduce from my previous paragraph, mining pools choose transactions from their own mempool running on their own node.  Therefore, they may choose a transaction that nobody else has in their own mempool, and they may not choose a transaction that nearly everybody else does have in their own mempool.

Additionally, most mining pools are trying to generate a profit, so they generally will choose the transactions from their mempool that pay the highest fee per vByte.  However, they are not required to use that criteria when choosing transactions.  They can use any criteria they want.  As such, many pools won't include non-standard transactions (even if they include a high transction fee per vByte). Some pools may choose to be altruistic and helpful to the community overall and as such may choose to include a limited number of very low fee transcation in each of their blocks (a bit like a type of charity).  Some pools may allow the mining participants to submit a limited number of low fee or even free transactions for a block. Some pools may provide an alternative means for people to pay the pool directly in exchange for a promise that a specified low fee transaction will be included in the next block that the pool successfully mines.  It's even possible that a pool operator might coordinate with a scammer to include the scammer's transaction in their block in exchange for a share of the scammer's profits (or the pool operator might even BE a scammer themselves).

[uchegod-21]

You'll see people write about "the mempool" as if there is a single mempool somewhere that everyone has access to and which represents the current list of all unconfirmed transactions. This is not how it actually works.  Every node maintains it's own mempool. 

Therefore, they may choose a transaction that nobody else has in their own mempool, and they may not choose a transaction that nearly everybody else does have in their own mempool.

It's even possible that a pool operator might coordinate with a scammer to include the scammer's transaction in their block in exchange for a share of the scammer's profits (or the pool operator might even BE a scammer themselves).

Thank you for still replying in this thread. I have learn many things. I quote some of your statement for learning.
You said is possible for a pool operator to coordinate with a scammer to include the scammer's transaction in their block.
If transaction is verified by a node operator it will stay in the operator's mempool until a miner will add it to a block.
A miner can chose a transaction to confirm. Does a node operator has the opportunity to chose the transaction to stay in his mempool. If yes, scammer can manipulate. But if no, please explain a little how the scammer and pool operator coordination will work.

[pooya87]

You said is possible for a pool operator to coordinate with a scammer to include the scammer's transaction in their block.
If transaction is verified by a node operator it will stay in the operator's mempool until a miner will add it to a block.

The only scenario that could work is this:
The scammer creates tx1 and tx2 that are spending the same exact UTXOs (double spend) but have different outputs. The scammer sends tx1 to the bitcoin network so it propagates among all nodes and sends tx2 to the participating pool so only that pool sees the double spend and nobody else.
So at this point, everyone's mempool has tx1 so the person receiving the funds in tx1 sees the good propagation and lack of double spend and accepts the unconfirmed transaction and makes the trade. Then the first block found by that pool contains tx2 and invalidates tx1, effectively ripping off the receiver.
Obviously this is solved if the receiver waits for confirmation.

A miner can chose a transaction to confirm.

Miners connect to a mining pool that is running its own node and can decide which transactions to mine.

[Pmalek]

Every node maintains it's own mempool.  The transactions in one node's mempool will generally be pretty similar to the transactions in another node's mempool simply because they've both received the same transactions relayed throughout the entire network, and the same blocks.  However, there is no guarantee that any one node has exactly the same list of transactions in their mempool as any other.  One node may not have heard about a transaction that another node did, or one node may have already dropped a transaction from it's mempool that another node has not.

And as a node operator, I could configure my node not to accept transactions with low transaction fees. For example, anything below 3 sat/vByte won't be included in my mempool. Another node might not include transactions below 5 sat/vByte. The reasons why they might want to do that aren't important, but it is possible. With such a difference in the configurations, nodes A, B, and C can't possible have the same unconfirmed transactions in their mempools because Node A accepts a minimum fee of 1 sat/vByte, Node B requires 3 sat/vByte, and Node C accepts nothing below 5 sat/vByte.

[DannyHamilton]

You said is possible for a pool operator to coordinate with a scammer to include the scammer's transaction in their block.
If transaction is verified by a node operator it will stay in the operator's mempool until a miner will add it to a block.

The only scenario that could work is this:
The scammer creates tx1 and tx2 that are spending the same exact UTXOs (double spend) but have different outputs. The scammer sends tx1 to the bitcoin network so it propagates among all nodes and sends tx2 to the participating pool so only that pool sees the double spend and nobody else.
So at this point, everyone's mempool has tx1 so the person receiving the funds in tx1 sees the good propagation and lack of double spend and accepts the unconfirmed transaction and makes the trade. Then the first block found by that pool contains tx2 and invalidates tx1, effectively ripping off the receiver.
Obviously, this is solved if the receiver waits for confirmation.

That's one example.  If we want to take a look at a more extreme example, imagine the following:

uchegod-21 will play the part of the naive scam victim.
DannyHamilton will play the part of the scammer.
pooya87 will play the part of a mining pool operator willing to collude in a scam.

• DannyHamilton agrees to purchase a VERY valuable NFT from uchegod-21 for 18 BTC.
• uchegod-21 agrees to provide the NFT to DannyHamilton after he sees 1 confirmation on the Bitcoin blockchain because he heard that transactions are permanent once they are confirmed.
• DannyHamilton notices that the mining pool operated by pooya87 has a LOT of hashpower and that it OFTEN solves 2 or more consecutive blocks
• DannyHamilton contacts pooya87 and tells him that if the pool succeeds in assisting, then he'll pay pooya87 10 BTC
• pooya87 agrees to attempt to help
• DannyHamilton creates 2 transactions. Transaction_A that pays uchegod-21 18 BTC, Transaction_B that spends the exact same bitcoins but pays pooya87 10 BTC, and the remaning 8 BTC are sent to a second address that DannyHamilton controls.
• DannyHamilton provides pooya87 Transaction_B and asks pooya87 to include it in the pool's next block AND let him know when the mining pool has solved the block, but NOT to broadcast the solved block to the network.  Instead, he tells pooya87 to have the pool immediately start working on a second block on top of the solved block, and broadcast both blocks together once the second block is solved.
• As soon as DannyHamilton hears that pooya87's pool has secretly solved the first block (Secret_Block_1), he broadcasts Transaction_A paying the 18 BTC to uchegod-21. (This block is at block height x)
• At some time after that some other miner solves and broadcasts a block (Public_Block_1) that includes this Transaction_A and uchegod-21 sees a confirmation.  Transaction_A is in the blockchain. (This block is also at block height x)
• uchegod-21 immediately sends the NFT to DannyHamilton
• A short while later, pooya87's pool solves a second block (Secret_Block_2) on top of the secret block (Secret_Block_1) that contains Transaction_B (This block is at block height x+1)
• pooya87 broadcasts BOTH of the blocks (Secret_Block_1 and Secret_Block_2) that his pool has solved.
• The entire network sees that this is a longer chain (Their current chain that includes Public_Block_1 is only x blocks long, whereas this new chain that includes BOTH Secret_Block_1 and Secret_Block_2 is x+1 blocks long)
• The entire network (including the wallet that uchegod-21 is using) abandons Public_Block_1 and replaces it in their own copies of the blockchain with Secret_Block_1 AND Secret_Block_2.
• Suddenly uchegod-21 no longer has the 18 BTC. The transaction paying him those bitcoins doesn't exist.
• Initially the nodes all consider adding Transaction_A back into their mempool to be confirmed later (since it was in the block that was replaced and is not in the replacement blocks). However, when they attempt to validate Transaction_A before putting it back in their mempool, they see that those bitcoins are already spent in their blockchain (in Transaction_B). Therefore, they reject Transaction_A entirely as an invalid transaction.
• DannyHamilton quickly finds a buyer for the NFT for 16 BTC, and completes the transaction before uchegod-21 can make it publicly known to the world that he's been scammed.
• The participants of pooya87's pool all go paid their normal expected payouts, and don't even realize that they participated in the scam.
• pooya87 himself is 10 BTC richer.
• DannyHamilton is 6 BTC richer (acquired an NFT for free, sold it for 16 BTC, paid 10 BTC of that to pooya87).
• uchegod-21 lost a very valuable NFT, and in exchange, he received a very important life lesson about needing multiple confirmations on very high-value transactions.

Now, there are no risks to DannyHamilton at all.  Worst case, if pooya87's pool fails to find that second block before the public blockchain adds a second block then DannyHamilton paid 18 BTC for an NFT worth 18 BTC.  DannyHamilton gets a fair deal and so does uchgod-21 in that situation.

pooya87 did take on some risk in this situation though, which is why DannyHamilton needed to offer pooya87 the majority of the profits in order to convince pooya87 to cooperate.  If pooya87's pool couldn't solve that second block fast enough, then he wouldn't get the 10 BTC payment from DannyHamilton (remember DannyHamilton agreed to pay pooya87 "if the pool succeeds in assisting"). If pooya87's pool doesn't solve that second block fast enough, then pooya87 will be sitting on a secret block (Secret_Block_1) that is invalid.  He therefore won't ever get paid the usual 6.25 BTC (at today's block subsidy) for having solved that block. Normally, he wouldn't get to keep most of that 6.25 anyhow (since he'd have to pay the pool participants for their shares in mining that block).  Now, if he's set this all up carefully enough, then perhaps his pool participants won't know about Secret_Block_1, and therefore they won't expect to be paid for solving it. In that case, pooya87 only loses out on the small percentage of that block reward that he would normally get to keep as a pool operator.  However, if he's paying his participants for every share they submit, then he's going to owe his participants nearly 6.25 BTC of his own money to keep them from wondering why their revenue dropped suddenly for a few blocks.

This exact same scam can be pulled off for 2 blocks (2 confirmations) or 3 blocks (3 confirmations) or more, but the risk to the pool operator grows with every additional block. First, the chances that they'll actually be able to stay ahead of the rest of the network long enough to succeed becomes much much smaller with each additional block needed. So their chances of successfully accomplishing the attack approaches 0% very quickly. Second, the amount that the pool fails to earn from the blocks that they don't broadcast increases by 6.25 BTC (at today's block subsidy level) for every additional block.  So, it becomes a more expensive attack with a smaller chance of succeeding.

This is why a lot of services are willing to accept transactions after 3 blocks.  At that point, any cooperating pool is risking 18.75 BTC (over $800,000 at today's exchange rate), and trying to hide this fact from their participants long enough to solve 3 blocks in a row without anyone noticing. Meanwhile, unless the pool controls nearly half of the entire world's hashpower, the chances that they will solve the next 3 blocks in a row before the rest of the world succesfully solves 3 blocks are very very slim.  Now, if you were accepting a transaction valued at 200 BTC or more, then there's enough of a pay-off there that it might be worth for a pool to try. In that case, the transaction recipient might require 4 confirmations (or more). For smaller amounts, 3 confirmations is probably enough.

It's up to the transaction recipient to be aware of the value of the transaction and to make a demand for a reasonable number of confirmations before allowing the transaction sender to receive whatever they are getting in exchange for the bitcoins.

Alternately, the transaction recipient can make sure that they have some other method of enforcing payment. If I have a strong personal relationship with the transaction sender, and I know with relative certainty that I'll be able to find them and force them to pay, then I can accept fewer confirmations (perhaps even 0 confirmations).  If I am holding as collateral something of value that belongs to the transaction sender, then I can perhaps accept less (even zero) confirmations with the knowledge that I can simply refuse to release the collateral. These are but a few examples where it may make sense to accept few or zero confirmations. Perhaps you can think of others. Essentially, any situation where you might be willing to accept a paper check written against a bank account is a situation where you might also be willing to accept a bitcoin transaction with zero confirmations.  A check might be written against an account with insufficient funds. A Bitcoin transaction with zero confirmations might not ever confirm, and may become invalid before it can confirm.

[o_e_l_e_o]

Now, there are no risks to DannyHamilton at all.

On the contrary, there is a huge risk to DannyHamilton from this step:

• DannyHamilton provides pooya87 Transaction_B and asks pooya87 to include it in the pool's next block AND let him know when the mining pool has solved the block, but NOT to broadcast the solved block to the network.  Instead, he tells pooya87 to have the pool immediately start working on a second block on top of the solved block, and broadcast both blocks together once the second block is solved.

pooya87 successfully mines a block containing Transaction_B, and decides to broadcast it immediately cashing in on both the 6.25 BTC block reward as well as the 10 BTC DannyHamilton just paid him, and then runs off with the 10 BTC. There is nothing DannyHamilton can do. pooya87 can simply deny all knowledge, and even if DannyHamilton can prove that pooya87 has scammed him, he can only do so by first outing himself as an attempted scammer.