[Poll] If Bitcoins blocks were 10x larger, would the miners be earning 10x?

[franky1]

It's all a question of how much you're protecting an with how much you're defending, are $36 million a day enough for miners to build a wall against somebody wanting to attacks bitcoin now? Maybe! Assuming Bitcoin goes to 400k and the chain holds 8 trillions in value, does that value still project the same security, of course not.

firstly the network is not protected by $36m a day
miners do not simply buy equipment for the day and pay electric for the day

they actually bought electric and equipment for a ~2 year span
meaning the equipment protecting the network is 730x the daily reward

remember for someone tomorrow to suddenly want to 51% means they need to take delivery today not of just $36m equipment and electric to attack the network tomorrow.. but instead another 540exa of equipment is needed to 51% attack the network tomorrow
this amounts to 2.7m asics of 200thash at ~$4k each ($10.8 BILLION) hardware
plus they cant just buy one days worth of electric for those asics. to get that volume of electric in one go they would need to sign up to a contract of special electric allocation..

so although miners are reimbursed per blockshare.. the cost of security is alot higher.. yep ALOT higher

much the sale as police officers..
police officers might be told they work at hourly rate. but they dont receive hourly rate. they are instead contracted for 1 year at a salary level, given guns and training and kevlar vests and police cars. which means for every hour they are on the streets they are costing the tax payer yearly amounts of hundreds of thousands to be on the street at any given hour

cops are not actually paid per hour. where they can just come and go soo easily. EG just get paid for 1 hour and never return to work
their hourly job has a combined cost of hundreds of thousands(car, training, equipment, employment contract) to be working per hour

also it does not matter what the market cap is.. you scream about a $8trillion market cap.. but blocks are not handling $8trillion per block
someone cant steal all $8trill by messing with 1 block or one days worth of blocks

[stompix]

firstly the network is not protected by $36m a day
miners do not simply buy equipment for the day and pay electric for the day
they actually bought electric and equipment for a ~2 year span
meaning the equipment protecting the network is 730x the daily reward

Wow franky!
So your job is not paying you $10 a hour is paying you $80 a day!
And the previous job was not paying you $1000 a month it was paying you $12 000 a year!
Do you have any other such insightful facts ? 

another 540exa of equipment is needed to 51% attack the network tomorrow
this amounts to 2.7m asics of 200thash at ~$4k each ($10.8 BILLION) hardware

Just so you don't have to go and do the math every time, most manufacturers have listed the price per th/s for years, not that you would know of it since you obviously don't mine but still, the s21hydro is on sale for 12$/th and microbt is dumping the 30s for $10/th which would bring your 10 billion to 6 and 5!
Why would an attacker buy the most expensive gear for an attack when he's obviously not looking at ROI numbers?
Also you're forgetting they could simply buy the whole farms which would make the attacker even cheaper as you don't have to overpower 500exa anymore, you have bought 50exahhash so you only need 400 more. 

also it does not matter what the market cap is.. you scream about a $8trillion market cap.. but blocks are not handling $8trillion per block
someone cant steal all $8trill by messing with 1 block or one days worth of blocks

Again you're missing the point!
If Bitcoin will reach 400k then it means a ton of money is there, and a lot of interest around it, far larger than it was at just $40k, and you don't need to steal money to break that apart, just a successful re-write of 10-20 blocks and that's it! Who in his sane mind is going to pour millions into this knowing that every time he makes a transaction there is a risk of being reverted?

[pooya87]

nodes on the network do not translate to market price effects

I wasn't suggesting that either, instead I'm drawing a picture of a scenario where people start abandoning Bitcoin which would also show itself up in the market and the price.

also 10x blocks may not equal 10x transactions. and wont equate to 10x fees
 if they just expanded the metadata/witness area and not redefine the base block size

My assumption was a hard fork where we no longer need the witness computation mechanism which means a raw 10 MB space. After all the only reason for it was to have backward compatibility and capacity increase through soft-fork.

Also about the first like you are forgetting the attackers! A bigger block means more space for them to attack bitcoin and at cheaper cost too. In other words the nodes would end up processing AND storing 40 MB of garbage every 10 minutes.
It could also translate into same high fees and congestion!

if 1mb base had a lean tx count potential of 4200tx a block(calculated by satoshi himself in 2010)

It is not possible considering the number of "consolidating" transactions people and major services push to the blockchain. That is transactions with many inputs and outputs that have a high size.

common sense, logic shows uncludging the blocks. make tx lean and then scale up by just 3x can allow better then 10x fee less per transactor without taking amounts away from pools and without needing to LEAP to 10x blocks of junk

Ignoring your weird fetish to bash SegWit, if we some day end up doing a hard-fork there is a lot of ideas that can be implemented to "make tx lean" or better say compress them. For example right at the beginning of each tx there is 4 wasted bytes for version which is completely useless! AFAICT the only place tx version comes to play is in OP_CLTV which nobody uses that option, not to mention it can be reworked.
Things like that would also speed up verification since we could end up with a smaller message to hash (smaller serialized tx when verifying signatures).

[franky1]

my opinion has never been to jump to 40mb at all.. nor any jump of blocksize under the current cludge model of base vs witness
i dont think there ever has been a proper proposal to jump so high in one go..

the natural common sense method is to decludge what we have now to make things more lean and then only need scaling by smaller adjustments over time. with no dev politics involved, that way we can scale up to more transactions using less space then the topics mention of 10x

EG
block size increases dont need dev politics. it can be based on blockdata deciding. EG if lets say 105000 blocks are 95% full then adjust blocksize. this can all be hard coded
it can also be hard coded by evaluating fee's per block. there are many hard data statistic stuff that code can use to automatically adjust parameters without dev politics involvement. (see: difficulty adjustments, see: reward halving)

fee's also do not need to drop to base levels. fee's can also have tiers too. where by spammers spending 1confirm utxo pay 144x more then someone that spends a utxo of 144confirm age
also the fee's can be tiered whereby certain opcodes cost more than other opcodes

end result is less spam unless it pays mining pools. but without punishing everyones fee

Ignoring your weird fetish to bash SegWit,

you do know by now that cores promises of the 4x blocksize did not result in 4x tx count
you do know by now that cores promises of segwit=leaner tx did not flourish either
you do know that segwit is the cause of allowing 1tx to utilise 3.99mb of space
heck even cores latest promise of taproot being less than one legacy signature length is not less than one signature length

heck even as far back as 2016 i was calling out how segwit would cause people to publish books and malicious data into the blockchain.. so i do hope you understand how 7 years later, when seeing ordinals and other junk crap.. that its not a empty fetish but instead highlighting the problems that were foreseen yet people want to ignore and just obediently adore cores roadmap unscrutinised

[Dunamisx]

No, i will rather believe this may be the only reason to make it more less congested for the mempool to get busy and the transactions to get confirmed on time even with lover fee, but by then, it will have to be given a stipulated amount of ordinals each block could contain as well as bitcoin, why i said it may be the reason to ease the high transaction fee is because there won't be competitiveness between the transactions with higher transaction fee and that with lower fee since they are not clogged together on the mempool awaiting confirmation.

[franky1]

Ignoring your weird fetish to bash SegWit, if we some day end up doing a hard-fork there is a lot of ideas that can be implemented to "make tx lean" or better say compress them. For example right at the beginning of each tx there is 4 wasted bytes for version which is completely useless!

not useless.. just not yet utilised
as you know things like mid transaction opcodes allow things to change after the opcode to new formatting based on rules of expectation after the opcode

and like this, the first few bytes of a tx can be used to introduce new things for the entire transaction format, from the beginning

EG
the spending UTXO
imagine transactions are no longer identified by a TXID in SHA256 (32bytes)
but instead hash160(20 bytes)
by using a new versionbit at the start the network can make new nodes validate transactions via a new TXID that is shorter. thus savign 12 bytes per input
heck what if due to blocks immutability instead of UTXO being TXID, they instead just ID'd a tx by blockheight+tx position in block+output position in tx
EG
3byte block height (16777215 blockmax (319years))
2byte tx position in block (65535tx per block)
1byte output in tx (256 outputs per tx)

thus a UTXO id can be as small as 6bytes
also knowing not everyone will spend 8bytes of output "value" meaning max
18446744073709551615
184,467,440,737btc   09551615sats
it doesnt need to represent 187Billion btc(21m limit after all)

heck no one is going to move 3million in one output so this could go to 6bytes
2,814,749     76710655

thus saving 2 bytes per output

the first bit of a tx can actually be utilised in the future. so saying its useless is not correct.. it simply has not been used yet.

..
also this version bit can be used in different ways such as users own tx can use it as a flag bit for voting

..
but yes them 4 bytes, allowing for 4,294,967,295 different transaction versions. is too many future options
this could also be reduced to 1 byte of 256 versions of future options, seeing as how the tx version is after 15 years only at version 2

[ranochigo]

I think this topic has gone from a simple yes/no, or if not how much question into something that is politicized and peppered with the arguments that we cannot do it. Now with that aside, I think we should focus on the economics aspect of things.

This will actually depend on how elastic the demand for the block space is. At its current stage, Bitcoin is not mainstream enough and there are plenty of alternatives to transfer funds. I would expect the total revenue to be lesser than expected. It would be a different story if Bitcoin is mainstream and demand can be sustained throughout. If we can't have close to full blocks with the increment, then I expect totally revenue to be disproportionately lesser.

[franky1]

I think this topic has gone from a simple yes/no,

but its not a yes/no

when bitcoin moved from 1mb allotment to 4mb allotment it did not result in 4x transaction count nor a direct economic impact on fee's
instead the code changes had other edits to it that manipulated fees (legacy * 4) yep they made legacy more expensive as part of additional code, rather then letting the "freemarket" decide

there are other things that can be done to undo some of the changes, make tx leaner, and allow more transactions thus reducing the per tx fee per user even without further scaling blocks

which if done right, then scaling blocks would allow more tx thus not require so much congestion/bidding wars, further reducing fees

however thats not the direct devs want to take bitcoin

[ranochigo]

but its not a yes/no

Again, the topic IS a yes/no. The following sentence below:

[Poll] If Bitcoins blocks were 10x larger, would the miners be earning 10x?

Is indeed a yes or no question.

Segwit did increase the total revenue from pre-segwit with the theoretical increase in potential transaction volume, not to mention the subsequent development in layer 2. Yes, it resulted in a higher miner revenue from fees. Again, besides the point. The topic discusses the possibility of a proportional increase given the increment in Bitcoin block size. What is your answer?

[franky1]

but its not a yes/no

Again, the topic IS a yes/no. The following sentence below:

[Poll] If Bitcoins blocks were 10x larger, would the miners be earning 10x?

Is indeed a yes or no question.

Segwit did increase the total revenue from pre-segwit with the theoretical increase in potential transaction volume, not to mention the subsequent development in layer 2. Yes, it resulted in a higher miner revenue from fees. Again, besides the point. The topic discusses the possibility of a proportional increase given the increment in Bitcoin block size. What is your answer?

you are not understanding the question nor answers

because the answer is notstraight forward

EG
10x more blocksize does NOT mean 10x more transactions at current fee rate
so it may not mean 10x more fee

instead 10x more blocksize may end up that the limited transactions +junkweight pay less sats per byte per tx because te junkweight gets more discount

again without understanding al the details you cant give a yes/no.
the question does not say if there will be 10x more transactions or if the extra blocksize is actual tx utility or just witness space just for junk

if doesnt say if blocksize increase also includes fixing the cludgy bloat spam to make things leaner

EG current 4mb is about 4200tx which 10x would be 42k tx in 40mb
which if fee rates per byte stayed same would be 1x(same) fee per user but 10x fee total for the pool
hoever with less congestion could see 10x LESS fee per user but 1x(same) fe total for the pool

however
making leaner tx allowing for 16k tx in 4mb.. meaning 160k tx in 40mb
fes per user can go 40x LESS while still being 1x total fees for pool

[ranochigo]

EG
10x more blocksize does NOT mean 10x more transactions at current fee rate
so it may not mean 10x more fee

instead 10x more blocksize may end up that the limited transactions +junkweight pay less sats per byte per tx because te junkweight gets more discount

Precisely, and we would be talking about increasing the vMB instead of the raw size. I think that your fundamental misunderstanding is with how the calculation of transaction fee rates should be done. SW tx have discounts, and rightfully so. You can fit more into a block, as opposed to an entire block with only legacy TXes. The fee rates would be compensated for with SW TXes and legacy TXes, all in all, your total revenue will rise.

Again, when replicating the practical scenarios, the question in this topic concerns if miners revenue could rise if blocks were larger and with typical usage patterns. Again, this would concern the economics of the fee market and talking about any other types of scaling Bitcoin would throw this topic on a tangent again.

[franky1]

Precisely, and we would be talking about increasing the vMB instead of the raw size. I think that your fundamental misunderstanding is with how the calculation of transaction fee rates should be done. SW tx have discounts, and rightfully so. You can fit more into a block, as opposed to an entire block with only legacy TXes. The fee rates would be compensated for with SW TXes and legacy TXes, all in all, your total revenue will rise.

Again, when replicating the practical scenarios, the question in this topic concerns if miners revenue could rise if blocks were larger and with typical usage patterns. Again, this would concern the economics of the fee market and talking about any other types of scaling Bitcoin would throw this topic on a tangent again.

SW does not discount.. the actual code is they premium'd legacy
there is a difference

by making legacy 4x more yes it made segwit cheaper than legacy, but not due to discounting segwit. but due to multiplying legacy
learn the difference

.. "if miners revenue could rise  if blocks are larger" is still not a yes/no. unless you are emphasising the "could".
because the fee's per user and the congestion also could decrease meaning the miners could get less total fees
so the answer to "could" is a yes. but to "would" is both yes and no

and there is always many variables to think about. its never straight forward

for instance. even now. blocksize has been same for years. yet individual miners get less sats per hashrate due to halvings and hashrate competition with other miners.
yep someone owning an s19 since 2020 is getting less sats now then they did in 2020

with that said. comparing the MARKET price, those sats are worth more
so its all adjustable to variables

which in short if asking WOULD 10x blocks =10x fee.. the answer is more then likely a no if you really wanted to fixate on a short answer without understanding the reasons, details, context

[ranochigo]

by making legacy 4x more yes it made segwit cheaper than legacy, but not due to discounting segwit. but due to multiplying legacy
learn the difference

It's pretty easy to see that most of the reference to Segwit's calculation are termed as "discounts". The actual method used to calculate can be different, but I believe we are not too concerned about the technicality here.

.. "if miners revenue could rise  if blocks are larger" is still not a yes/no. unless you are emphasising the "could".
because the fee's per user and the congestion also could decrease meaning the miners could get less total fees
so the answer to "could" is a yes. but to "would" is both yes and no

and there is always many variables to think about. its never straight forward

for instance. even now. blocksize has been same for years. yet individual miners get less sats per hashrate due to halvings and hashrate competition with other miners.
yep someone owning an s19 since 2020 is getting less sats now then they did in 2020

with that said. comparing the MARKET price, those sats are worth more
so its all subjective to variables

Thanks, that is what I thought the topic was about. Halving is still in play because it still constitutes a significant portion of miners' revenue, but that could change in the near future. Revenue per hashrate wouldn't be that accurate of a metric to look at; obsolescence is normal for miners and it would be better for us to evaluate the ROI given a specific lifespan of a device.

I think congestion could decrease, but it would depend on how much of an urgency or necessity Bitcoin transactions are. Even if congestion, or the scarcity of block space becomes periodic, if Bitcoin transactions turns out to be a necessity for some, I predict the overall revenue could still be sustained or increased.

[BayAreaCoins]

Thank god the fees are finally coming back to Earth.

I do think 10mb blocks would be tits (good).

[348Judah]

I don't think the miners will get more than they are having already even if the block is 10x bigger than it was now, that will even solve more problems of having long queue on the mempool when a block can accommodate as many as possible transactions to be all confirmed at the same time, we can only have more increase in the fee charged if this new development was just implemented now, but if it were added already since the very first time the block size was increased, nothing is likely to happen than we do see today, we may even have lesser than this maybe.