Bitcoin Forum
September 19, 2019, 09:41:36 AM *
News: If you like a topic and you see an orange "bump" link, click it. More info.
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: A block containing only 2 transactions  (Read 313 times)
javadsalehi
Member
**
Offline Offline

Activity: 364
Merit: 12


View Profile
September 02, 2019, 03:29:10 PM
Last edit: September 02, 2019, 03:54:00 PM by javadsalehi
 #1

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
bitmover
Hero Member
*****
Offline Offline

Activity: 602
Merit: 1021



View Profile
September 02, 2019, 04:26:32 PM
 #2

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
Legendary
*
Offline Offline

Activity: 1470
Merit: 1481


BtcBoss


View Profile
September 02, 2019, 04:28:40 PM
 #3

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.

.BitDice.               ▄▄███▄▄
           ▄▄██▀▀ ▄ ▀▀██▄▄
      ▄▄█ ▀▀  ▄▄█████▄▄  ▀▀ █▄▄
  ▄▄██▀▀     ▀▀ █████ ▀▀     ▀▀██▄▄
██▀▀ ▄▄██▀      ▀███▀      ▀██▄▄ ▀▀██
██  ████▄▄       ███       ▄▄████  ██
██  █▀▀████▄▄  ▄█████▄  ▄▄████▀▀█  ██
██  ▀     ▀▀▀███████████▀▀▀     ▀  ██
             ███████████
██  ▄     ▄▄▄███████████▄▄▄     ▄  ██
██  █▄▄████▀▀  ▀█████▀  ▀▀████▄▄█  ██
██  ████▀▀       ███       ▀▀████  ██
██▄▄ ▀▀██▄      ▄███▄      ▄██▀▀ ▄▄██
  ▀▀██▄▄     ▄▄ █████ ▄▄     ▄▄██▀▀
      ▀▀█ ▄▄  ▀▀█████▀▀  ▄▄ █▀▀
           ▀▀██▄▄ ▀ ▄▄██▀▀
               ▀▀███▀▀
        ▄▄███████▄▄
     ▄███████████████▄
    ████▀▀       ▀▀████
   ████▀           ▀████
   ████             ████
   ████ ▄▄▄▄▄▄▄▄▄▄▄ ████
▄█████████████████████████▄
██████████▀▀▀▀▀▀▀██████████
████                   ████
████                   ████
████                   ████
████                   ████
████                   ████
████▄                 ▄████
████████▄▄▄     ▄▄▄████████
  ▀▀▀█████████████████▀▀▀
        ▀▀▀█████▀▀▀
▄▄████████████████████████████████▄▄
██████████████████████████████████████
█████                            █████
█████                            █████
█████                            █████
█████                            █████
█████                     ▄▄▄▄▄▄▄▄▄▄
█████                   ▄█▀▀▀▀▀▀▀▀▀▀█▄
█████                   ██          ██
█████                   ██          ██
█████                   ██          ██
██████████████████▀▀███ ██          ██
 ████████████████▄  ▄██ ██          ██
   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ ██          ██
             ██████████ ██          ██
           ▄███████████ ██████▀▀██████
          █████████████  ▀████▄▄████▀
[/]
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1764
Merit: 2029

Use SegWit and enjoy lower fees.


View Profile WWW
September 02, 2019, 05:58:20 PM
 #4

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

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.

I've see few similar cases when timestamp interval between 2 blocks is very short.

NeuroticFish
Legendary
*
Online Online

Activity: 1974
Merit: 1311


There are no mistakes. Only opportunities wasted.


View Profile
September 02, 2019, 07:02:41 PM
 #5

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
Hero Member
*****
Offline Offline

Activity: 686
Merit: 2741



View Profile
September 02, 2019, 07:03:39 PM
 #6

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
Hero Member
*****
Offline Offline

Activity: 1204
Merit: 887



View Profile
September 02, 2019, 07:20:13 PM
Merited by NeuroticFish (1), o_e_l_e_o (1)
 #7

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.

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1764
Merit: 2029

Use SegWit and enjoy lower fees.


View Profile WWW
September 03, 2019, 04:21:17 AM
 #8

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/

Then it's not weird, as far as i remember average block size is far less than 1MB in 2015.

Besides, there's no other way to include 1MB transaction if you're not miner or pool.

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

Should've checked it before make assumption Tongue

Kakmakr
Legendary
*
Offline Offline

Activity: 1778
Merit: 1355

★ ChipMixer | Bitcoin mixing service ★


View Profile
September 03, 2019, 05:53:04 AM
 #9

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>  Roll Eyes

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

Little_king
Copper Member
Newbie
*
Offline Offline

Activity: 196
Merit: 0


View Profile
September 03, 2019, 01:00:42 PM
 #10

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.

[ IXINIUM ] Transactions In Seconds, Backed By Real 100% Insured Assets.
http://ixinium.io/
BitHodler
Legendary
*
Offline Offline

Activity: 1386
Merit: 1164


View Profile
September 03, 2019, 01:51:05 PM
 #11

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.  Roll Eyes
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
Legendary
*
Offline Offline

Activity: 2520
Merit: 1462



View Profile
September 03, 2019, 11:17:57 PM
Last edit: September 04, 2019, 09:01:59 AM by franky1
 #12

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

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
BrewMaster
Hero Member
*****
Offline Offline

Activity: 1302
Merit: 789


There is trouble abrewing


View Profile
September 04, 2019, 04:51:26 AM
 #13

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
Hero Member
*****
Offline Offline

Activity: 1204
Merit: 887



View Profile
September 04, 2019, 08:46:28 AM
 #14

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
Hero Member
*****
Online Online

Activity: 1106
Merit: 966


I bit, therefore I am


View Profile
September 04, 2019, 09:23:04 AM
 #15

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
Legendary
*
Offline Offline

Activity: 2520
Merit: 1462



View Profile
September 04, 2019, 09:31:25 AM
Last edit: September 04, 2019, 04:25:12 PM by franky1
Merited by ETFbitcoin (1)
 #16

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

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
franky1
Legendary
*
Offline Offline

Activity: 2520
Merit: 1462



View Profile
September 04, 2019, 09:38:12 AM
 #17

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

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1764
Merit: 2029

Use SegWit and enjoy lower fees.


View Profile WWW
September 04, 2019, 09:56:33 AM
Merited by BrewMaster (1)
 #18

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
Hero Member
*****
Offline Offline

Activity: 1302
Merit: 789


There is trouble abrewing


View Profile
September 04, 2019, 10:42:41 AM
 #19

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
Legendary
*
Offline Offline

Activity: 2520
Merit: 1462



View Profile
September 04, 2019, 04:29:07 PM
 #20

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.

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!