Topic: A block containing only 2 transactions (Read 448 times)

stop trolling. you expect us to believe that miners are throwing away free money? you know why the second block only included the coinbase transaction: the pool hadn't downloaded/fully validated the previous block and updated mempool yet because the second block was found only 24 seconds later.

they may have been engaging in validationless mining---we're talking about antpool after all.

They don't care? Uummm aaaa I don't think so. I mean why do you think they don't? Even if the block is empty with just newly generated coins being sent to the pool owner, I believe that maybe their set transaction fee limits could not have been met? Correct me if wrong.
Doesn't this look as an attack towards us who use BTC, to spend more on fees to get involved in those blocks? Can this inflate the fees if all miners unite and commit the same?

shhh stop revealing real evidence that pools dont care about fee's.. if people knew that then people will start questioning why devs are saying the fee's need to go up while not scaling bitcoins blockchain(thus ruining onchain utility) and people will start questioning why devs want users to lock funds up into custodial control, which goes against the whole purpose of bitcoins invention.

so please keep it down to a silent whisper or the dev fan girls will troll you to death but not back it up with any research of their own.
[note tone of sarcasm]

If you think it's impossible to have such a block these days, check block number 594153 which mined a few minutes ago.
Here the number of transaction included is not 2. The number is 1. Only one transaction which is generating new coins.
https://www.blockchain.com/btc/block/0000000000000000000fec146fe9cea2309e368036fd193731c4e1faf5838272
The transaction has been mined only 24 seconds after the previous one.

(facepalm)
thats like having a gun problem, but instead of just removing guns. you run a program to give out foodstamps to anyone that hands in a gun..
sorry but thos that want to kill, will still kill. voluntary options dont work against malicious risks.

again core devs refuse to fix the issue because their interests have become commercialied into wanting to push people off the network and into commercial networks and services.

but hey no one cares about network security or scaling capacity using the true bitcoin technology(blockchain) all that cor fangirls care about is the price. so that one day they can exit back to fiat, leaving bitcoin, weakening bitcoin

if yo only care about the price and dont care about bitcoins blockchain security and capacity.. dont bother replying

why are you brushing bug, issues under the carpet and then dying the carpet pink, then covering it in glitter to make things look prettier than what they are trying to hide?

miners rational, miners care about fee's.. topic creators example alone proves the opposite. (a)1tx (b)no fee..
again core devs are avoiding increasing the base block due to THEIR scare tactics and fearmongering that the network wont cope with propogation due to quadratics risks of larger base block. its them saying 'super computers are needed for full nodes'

but fix the issue, reduce the maxtxsigops to 500 and guess what. suddenly someone cant make a single bloated tx to fill a block., it would require hundreds of transactions to fill a block.. which means instead of 1 chance of being in a block, hundreds of chances by default

the risk of quadratics is real, but instead of fixing it, they are using it as a weapon of fear to say bitcoins blockchain cannot cope with scaling. just so they can sell they community onto the idea of using other networks

Is the block mined using Antpool?

Tin foil hats on, but the mempool might start growing large again, causing the fees to increase. Haha.

A sigops limit could be done with a soft fork. It just requires a patch that censors transactions that use "too many" inputs. If a majority of miners enforce it, it would be effective.

Segwit + witness discount was a much more elegant way to approach the issue. By discounting witness data, users are incentivized to transact with linear scaling sigops. So we're achieving the same ends on a voluntary basis.

is it a change in consensus or not? if it is (which i say it is) then it requires a hard fork to be enforced otherwise nodes not relaying certain transactions is already happening and it is not fixing the issue that you started the discussion with.
if you think it is an implementation bug not protocol/consensus then it is a different discussion and talking about it here is pointless, open a PR on github if you know how to fix it.

that's the thing though, they don't need to  decide they already don't include non-standard transactions and these transactions aren't being relayed in first place.
the problem was about "malicious miner" creating a "malicious block" that is valid as far as protocol/consensus is concerned.

Pools do care about fees. Many pools pay them out as incentive to attract miners. The ones that don't pocket the fees themselves.

In this specific case, the pool's short-lived incentive was to reduce UTXO bloat. The block took 25 seconds to validate and wasn't problematic for the network. Four years later, we haven't seen a similar case -- probably because miners are rational and not altruistic.

Why are you fearmongering about this?

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

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.

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.

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.

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.

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

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.


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

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.

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.

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.