A block containing only 2 transactions

[javadsalehi]

I accidentally faced a weird block that contains only 2 transactions. I don't know if there are similar blocks.
Check block number 364292
https://www.blockchain.com/btc/block/000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe
There are only 2 transactions.
One of them is related to new generated coins and there is no issue with it.
But the other one:
The size is 999657 bytes and what makes me really surprised is the zero fee.

[bitmover]

A miner can chose to include any transaction he wants in a block, even zero fee one.

It is weird because he could have added more transactions and made more money in fees

[seoincorporation]

I accidentally faced a weird block that contains only 2 transactions. I don't know if there are similar blocks.
Check block number 364292
https://www.blockchain.com/btc/block/000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe
There are only 2 transactions.
One of them is related to new generated coins and there is no issue with it.
But the other one:
The size is 999657 bytes and what makes me really surprised is the zero fee.

As you can see that's an old transaction: 2015-07-07 18:19:07

Blocks with only 2 transactions aren't weird at all, but it's hard to see them nowadays.

In the past users was able to send transactions with zero fees and isn't hard at all if you know how to create a raw transaction with bitcoin core. But i think nowadays the same software gives a warning if the user doesn't add fees or if it's too low.

[NeuroticFish]

Blocks with only 2 transactions aren't weird at all, but it's hard to see them nowadays.

The small blocks are not so rare actually. And indeed they happen when one block is mined right after another.
You can look at https://coin.dance/blocks to see the latest 1000 blocks and how many transactions they contain.
And I even found a "winner": block 592759, from yesterday, has only one transaction (the block reward).

[o_e_l_e_o]

It makes perfect sense that a user would want to mine this transaction themselves for zero fees, rather than pay a fee and broadcast it for someone else to mine. It has 5569 inputs all of 0.00001 BTC for a total of 0.05569 BTC, and comes in at 999,657 bytes. Even at a fee of 1 sat/byte, the user in question would have lost 0.01 BTC or almost 20% of the transaction value in fees. Looking at the blocks before and after, the average transaction fee at the time was around 60 sat/byte, which would have cost this user 0.6 BTC in fees, or more than 10x more than the transaction was worth.

It is weird because he could have added more transactions and made more money in fees

Not in this case. The block was essentially full from this one transaction alone.

[figmentofmyass]

It is weird because he could have added more transactions and made more money in fees

Not in this case. The block was essentially full from this one transaction alone.

isn't that precisely what makes it weird? this one transaction paid zero fees. even if the miner was mining his own transaction (and that's the only sort-of rational explanation), he could have collected 10x the fees by including transactions from the mempool. check out the next block, where fees totaled 0.59419256 BTC: https://www.blockchain.com/btc/block/000000000000000013ba348d19e2418fb49f79ea3fa7026c8c92483b4c61ba36

this miner was just being economically irrational and clearing out these brainwallets loaded with dust. they were doing the network a favor by clearing dust from the UTXO set.

edit: in fact yes, this was F2Pool, and i recall there was some discussion at the time about why they were doing this: https://www.reddit.com/r/Bitcoin/comments/3fggjj/someone_has_broadcast_a_transaction_with_20000/

It's not weird at all, when a pool/miner found 2 blocks with very short interval, it's done to make sure they receive the block mining reward.

not the case here. the prior block was found ~20 minutes earlier.

[Kakmakr]

It could have been someone just testing something, because it makes no sense mining a Block with 5569 inputs with zero fees under normal circumstances. I know some people spammed the network previously with loads of small transactions, but this does not look like any normal spam attack. <Bitcoin XT period> 

The one positive thing that can be derived from this is that miners can mine transactions like this < 999,657 bytes > with zero fees, if they wanted to, but I doubt if they would want to do that for someone else. 

[Little_king]

That might a block for miners which actually generate their reward base on the blocks mine and since that is their own work well done for then it can be mine with any fee or even less as every block just require a number of transaction to make up the size for scape through block.

[BitHodler]

The one positive thing that can be derived from this is that miners can mine transactions like this < 999,657 bytes > with zero fees, if they wanted to, but I doubt if they would want to do that for someone else. 

Nowadays that's highly unlikely with how much money there is to make by filling up the precious block space with organic transactions. If you want to test things as miner you can use the testnet do to so. It won't bother anybody in that case.

The only more recent instance of a miner not utilizing the block space was Antpool, where they for some (probably toxic) reason mined a couple of empty blocks a day, and that without there being two blocks found nearly at the same time.

[franky1]

i raised this issue ages ago. but core devs dont think its a problem

imagine it though.
someone is able to fill a block with just 1 transaction. secondly they could use the quadratic signature bug to make full nodes take longer to validate. thus cause network bottlenecks.

segwit HAS NOT fixed this because malicious users wanting to make a single tx still can.

core devs have refused to drop the sigops per tx, thus not reduce the risk. they foolishly say they trust the open freemarket model of trust that people simply wont do things to harm the network (bad security mindset)
 
some devs have foolishly thought to instead sooner or later, drop legacy validation, trying to force people into using segwit.(facepalm)

but as i said the cure is easy. reduce the sigops per tx,which stops people filling a block so easily

[BrewMaster]

imagine it though.
someone is able to fill a block with just 1 transaction. secondly they could use the linear signature bug to make full nodes take longer to validate. thus cause network bottlenecks.

blocks that are generated every 10 minutes on average having 1 gigantic transaction is not going to create any kind of network bottleneck! you are still verifying that 1 block by doing the same amount of checks as if there were 2000 transactions. not to mention that if that 1 transaction were a SegWit tx then the verification was actually faster than verifying 2000 transaction since you would be reusing the same hash for the most part.
that is why it is not changed at consensus level and it should not be changed.

the bottleneck you are thinking of is if "nodes" were relaying such gigantic transactions which they (by default) don't.

[figmentofmyass]

i raised this issue ages ago. but core devs dont think its a problem

imagine it though.
someone is able to fill a block with just 1 transaction. secondly they could use the linear signature bug to make full nodes take longer to validate. thus cause network bottlenecks.

segwit HAS NOT fixed this because malicious users wanting to make a single tx still can.

this doesn't pose significant problems with a 1MB base block size. that's what we've observed after all these years. the fee market is the biggest reason: it's much more profitable to mine honestly and collect fees in the context of limited block space. there are theoretical attacks where transactions could take a couple minutes to validate but the most we've seen in the wild was 25 seconds for a single block. (the problem, as you know, gets much worse at larger base block sizes)

segwit allowed us to increase the block size without limiting sigops---by leaving the base block size alone. the best of both worlds! users with lots of inputs should be able to compete on the fee market or mine their own transactions like everyone else.

[buwaytress]

this doesn't pose significant problems with a 1MB base block size. that's what we've observed after all these years. the fee market is the biggest reason: it's much more profitable to mine honestly and collect fees in the context of limited block space. there are theoretical attacks where transactions could take a couple minutes to validate but the most we've seen in the wild was 25 seconds for a single block. (the problem, as you know, gets much worse at larger base block sizes)

segwit allowed us to increase the block size without limiting sigops---by leaving the base block size alone. the best of both worlds! users with lots of inputs should be able to compete on the fee market or mine their own transactions like everyone else.

But it is still a problem posed, at least it seems to me too. Good problems to have, as they would say in some jobs, though, and these get less and less significant I believe when the incentive for bad actors become less and less plausible -- even if theoretical becomes reality, I'm pretty sure the rest of the network can very quickly punish those bad actions.

[franky1]

imagine it though.
someone is able to fill a block with just 1 transaction. secondly they could use the quadratic signature bug to make full nodes take longer to validate. thus cause network bottlenecks.

blocks that are generated every 10 minutes on average having 1 gigantic transaction is not going to create any kind of network bottleneck! you are still verifying that 1 block by doing the same amount of checks as if there were 2000 transactions. not to mention that if that 1 transaction were a SegWit tx then the verification was actually faster than verifying 2000 transaction since you would be reusing the same hash for the most part.
that is why it is not changed at consensus level and it should not be changed.

the bottleneck you are thinking of is if "nodes" were relaying such gigantic transactions which they (by default) don't.

you need to really do some research before making assumptions.
the validation time for 2000 transactions of one input is NOT the same as 1 transaction of 2000 inputs
you really need to do some research.

what your trying to flip flop about is if someone made an efficient block of one transaction where the transacter wants to use a single address to then have less processing requirements for all inputs... but take off the pink fluffy best case use.. and think of malicious use where someone wanted to create a malicious transaction.
i really find it funny how people avoid talking about the negatives and try to push a super pro use case to hide the negative.. its not helpful.
bitcoin security should be higher priority than dev hugging.

segwit allowed us to increase the block size without limiting sigops---by leaving the base block size alone. the best of both worlds! users with lots of inputs should be able to compete on the fee market or mine their own transactions like everyone else.

ok so your saying 1mb legacy 3mb witness.. ok well imagine 7mb witness with 1mb legacy.. oh look. no extra capacity boost, just room for more lumpy bloated scripts.
but when you expand the legacy 1mb to 2mb it actually does boost the tx capacity..
but now imagine a tx with twice the sigops limit.. twice the problem because it does increase transaction capacity(the thing people want) but also causes issues. which can be fixed and should have been fixed ages ago by just limiting tx sigops.

basically ask yourself WHO THE F**K deserves to have a whole block to themselves.. bitcoin is meant to be a international payment system for people, not person. so letting just 1 person get a block to themselves and have the ability to be malicious with that. is foolish

just like brewmaster should, can you both stop throwing out the pink glitter best case scenario of utopian use, and try to think about things from malicious user ability risk.

thinking that bitcoin should stay at 1mb legacy is stupid. 1mb is not practical for an international payment system. the problem is not the 1mb but how the space is used. reducing the sigops reduces the bottleneck risk, which allows more expansion

pre-empting the glitter rebuttals.
1. dont reply with fluffy glitter best case scenario
2. dont reply with ignorance of quadratics issue
3. dont reply with assuming malicious people will use segwit(as a way to hide the issue)
4. dont reply that 1mb should remain as it would benefit miners, it doesnt..(as a way to hide the issue)
5. miners do not care about fee's. thy just care about having fast validation speeds so that when they form a block they can include transactions to then b the quickest at solving a block. no fee games would sway a pool to want to lose speed to win a block reward.
6. dont even try to presume pools wont include malicious transactions due to points 5 rational.. this very thread proves that a pool HAS included a transaction, with no fee that was just 1 transaction(blockreward is separate)
7.assume worse case scenario possibilities and risks. again as point 1&2 suggests dont try twisting rebuttals to advertise to pian best case scenarios.. truly think about the risks
8. do your research

[franky1]

I believe when the incentive for bad actors become less and less plausible -- even if theoretical becomes reality, I'm pretty sure the rest of the network can very quickly punish those bad actions.

but thats the issue. there is no punishment.
if core limited a block to say 500 sigops a tx, then anyone trying to do the quadratic bug wont get their tx accepted, plus it would allow the base legacy block area to increase without the risk.
the reason they cry about not increasing to 2mb is because they dont want the validation delay of quadratics to cause issues.
again reducing sigops per tx fixes it.. and they could have fixed it 4 years ago during the initial scaling debates

also for those discussing the fee element. pools could choose to only include tx's above a certain fee amount even without filing a block. thus forcing wallets when they do thier fee estimations to base it on the calculated averages of previous blocks(of high fees) to cause the cost of a tx to go up. even if blocks are not full. and that goes unpunished

cores "free market" is a security and utility risk. they keep abusing that buzzword purely to sell people onto the idea of using other networks

[ABCbits]

blocks that are generated every 10 minutes on average having 1 gigantic transaction is not going to create any kind of network bottleneck! you are still verifying that 1 block by doing the same amount of checks as if there were 2000 transactions. not to mention that if that 1 transaction were a SegWit tx then the verification was actually faster than verifying 2000 transaction since you would be reusing the same hash for the most part.
that is why it is not changed at consensus level and it should not be changed.

the bottleneck you are thinking of is if "nodes" were relaying such gigantic transactions which they (by default) don't.

Few transaction have quadratic growth on verification time (also called time complexity), see :
https://bitcoincore.org/en/2016/01/26/segwit-benefits/#linear-scaling-of-sighash-operations
https://bitslog.com/2017/04/17/new-quadratic-delays-in-bitcoin-scripts/

While there are limitation to prevent such abuse, miner could bypass it since the rule only apply when broadcast a transaction.

[BrewMaster]

ok. i didn't know about that, thanks for the links.
but the numbers still don't make sense enough to call it a serious issues. 2-3 minutes of confirming a valid block that is mined (which means is worth $130k at current rate) only if a malicious miner created that block is not a serious threat in my opinion and to fix that we need a possibly hard fork to change this in consensus and the drama that forks cause is more serious than this issue.

[franky1]

ok. i didn't know about that, thanks for the links.
but the numbers still don't make sense enough to call it a serious issues. 2-3 minutes of confirming a valid block that is mined (which means is worth $130k at current rate) only if a malicious miner created that block is not a serious threat in my opinion and to fix that we need a possibly hard fork to change this in consensus and the drama that forks cause is more serious than this issue.

doesnt require a hard fork at all(if core implemented/allowed it). but i do like how you are trying to prevent a fix by crying that it will cause disruption.. sorry but it wont, there are many ways to implement it without forking.

[figmentofmyass]

this doesn't pose significant problems with a 1MB base block size. that's what we've observed after all these years. the fee market is the biggest reason: it's much more profitable to mine honestly and collect fees in the context of limited block space. there are theoretical attacks where transactions could take a couple minutes to validate but the most we've seen in the wild was 25 seconds for a single block. (the problem, as you know, gets much worse at larger base block sizes)

segwit allowed us to increase the block size without limiting sigops---by leaving the base block size alone. the best of both worlds! users with lots of inputs should be able to compete on the fee market or mine their own transactions like everyone else.

But it is still a problem posed, at least it seems to me too.

it's a theoretical attack that's mitigated by rational mining incentive. this is basically a microcosm for how the entire mining incentive works in bitcoin. the example in the OP is a case in point: a sustained poison block attack requires miners to throw away lots of high value fee revenue. in the situation of static base block size and increasing adoption, the mining incentive would only further secure us from such attacks.

miners also risk having poison blocks orphaned since they propagate to the network so slowly. if nodes take 2-3 minutes to validate, other miners could publish a longer chain before the poison block propagates to the network. that's additional economic disincentive against performing the attack.

[franky1]

this doesn't pose significant problems with a 1MB base block size. that's what we've observed after all these years. the fee market is the biggest reason: it's much more profitable to mine honestly and collect fees in the context of limited block space. there are theoretical attacks where transactions could take a couple minutes to validate but the most we've seen in the wild was 25 seconds for a single block. (the problem, as you know, gets much worse at larger base block sizes)

segwit allowed us to increase the block size without limiting sigops---by leaving the base block size alone. the best of both worlds! users with lots of inputs should be able to compete on the fee market or mine their own transactions like everyone else.

But it is still a problem posed, at least it seems to me too.

it's a theoretical attack that's mitigated by rational mining incentive. this is basically a microcosm for how the entire mining incentive works in bitcoin. the example in the OP is a case in point: a sustained poison block attack requires miners to throw away lots of high value fee revenue. in the situation of static base block size and increasing adoption, the mining incentive would only further secure us from such attacks.

miners also risk having poison blocks orphaned since they propagate to the network so slowly. if nodes take 2-3 minutes to validate, other miners could publish a longer chain before the poison block propagates to the network. that's additional economic disincentive against performing the attack.

1. a pool can pre validate a bulk tx prior to the block creation..(not relay it so other pools cant pre validate) and then add it to a block.
2. the created block can then be relayed and hold up the other pools validation times as they have to receive and validate before updating utxoset to then create their own next block potential
3. while other pools are delayed the malicious pool can just start their next attempt, having a head start basically
4.thus getting an extra blockheight ahead of the other pools
5. adding 2000 tx's with fee's or just creating an empty block.. the empty block would get solved faster.
6. in a race of 20 pools (5% chance if all pools had equal hash) its more important to chase the block reward of 25 coins rather than risk losing the 25 coins, for a smaller chance of 25.3 coins

would you really mess around for 25.3 but have better chance getting just 25

i find it strange that instead of adding code to limit the risk. some fools just want to say 'people wont do it because fee's' .. the topic creators example shows pools dont care about fee's

also the other point in previous message about quadratics becoming a problem if base block is expanded... exactly. so instead of crippling btc's capacity.. cripple the maxtxsigops instead and allow capacity to grow.
i find it foolish that people think crippling btc's capacity is a good thing. especially when REAL fixes exist

again people spouting out 'trust the hearts and pockets of people to do the right thing'.. to avoid real fixes.. makes btc have security risks and rely on human emotion more then coded rules

last ranting point. dont cal it a theoretical threat when there actually have been blocks in btc created maliciously