[POLL] Is bigger block capacity still a taboo?

[alani123]

Circa 2014 the block size wars took bitcoin by storm.
Eventually after a lot of drama that has been well documented elsewhere (I made my own attempt documenting a time line of the blocksize wars, its outcomes and conclusions here).

But I'm starting this poll in hopes of getting the community's opinion. So for this post I'll not go through my opinion in the OP.
Please feel free to answer the question in the poll and even better if you can also explain your answer.

Back in 2015, and after the adoption of a compromise in the form of SegWit, the topic of the block capacity was very taboo.
Well, we're in 2023 now, and for different reasons congestion is still an issue. Increasing the capacity of bitcoin blocks could potentially be a solution to the issues of high fees and congestion.

So I think it's worth exploring what people think about this issue. Please share your thoughts below.

[1715331386]

1715331386

[1715331386]

1715331386

[1715331386]

1715331386

[1715331386]

1715331386

[1715331386]

1715331386

[alani123]

I'll start by dedicating this thread to stompix (honestly, no hate, debate with him is enjoyable even though we sometimes disagree) who dared me to make this thread.

Be my guest to open a topic about increasing the capacity, I'm grabbing my popcorn!
Common, do it, I can't wait for it!

It's already 2023 now and I think having a taboo over mere discussion of block capacity shouldn't be shunned or considered taboo.

Continuing the debate:

As for me, I was just this week shown how it's physically impossible to have blocks larger than 4MB because only nodes that own a Titan computer and their own private global fiber optic cables would be able to cope with larger blocks!

Well well well... This is an age old arguement.
Quoting my post that I also linked in the OP:

The concerns over big and dynamic blocks in 2015
It's important to not forget what the talking points for each proposed solution were back when it was decision time.
In early 2016, Jonas Schnelli, a full time bitcoin Core maintainer, was quoted stating the following against 2MB blocks.

There are consequences with 2-megabyte blocks. Chinese miners -- they are now [for] 2- megabyte blocks, but maybe it will turn out to be a problem for them . . . Every second really counts . . . When you mine a block that is no longer valid and you don’t get the information that a new block is here, you’re wasting lots of energy. If it’s just ten seconds you mine on the wrong block, you lose energy, and you lose coins in the end. That’s why, with Chinese miners [especially], every second counts, and [with] 2-megabyte [blocks], it’s twice the bandwidth you need.

In this quote its easy to see how conservative bitcoin developers sought to be with the blockchain size, and how an increase in block size might severely affect the decentralization of bitcoin due to bandwidth constraints in many parts of the world. Contrary to the path projects like Ethereum have followed by having a full blockchain size in the terrabytes, bitcoin still chooses to form its network with full nodes. Users of bitcoin can still to this day download and easily synchronize the full blockchain therefore also contributing to decentralization. This lack of compromise is what has defined bitcoin through the years.

Yet, in the end, we got 4MB blocks and still no super computers are needed. It's probably safe to say that even higher max block size increases could be easily accommodated by a run in the mill home computer. Moore's law is still a thing. Computing and storage space becomes cheaper. So, surpassing 1MB blocks didn't destroy BTC. Even 4MB blocks didn't. But now, so many years after 2015, storage, memory and computing power are cheaper than ever. So this argument doesn't stand.

But what do you know! It doesn't even matter if bitcoin full node requirements are raised. Why? Because decentralization doesn't necessarily guarantee trustlessness and immutability. And in a way, mining nodes are already way fewer and with much higher requirements than normal network nodes. So we've already been beyond the point where maximizing decentralization mattered ever since ASICs were introduced for bitcoin. Even satoshi admitted to such:

The current system where every user is a network node is not the intended configuration for large scale.  That would be like every Usenet user runs their own NNTP server.  The design supports letting users just be users.  The more burden it is to run a node, the fewer nodes there will be.  Those few nodes will be big server farms.  The rest will be client nodes that only do transactions and don't generate.

Besides, 10 minutes is too long to verify that payment is good.  It needs to be as fast as swiping a credit card is today.

See the snack machine thread, I outline how a payment processor could verify payments well enough, actually really well (much lower fraud rate than credit cards), in something like 10 seconds or less. If you don't believe me or don't get it, I don't have time to try to convince you, sorry.
http://bitcointalk.org/index.php?topic=423.msg3819#msg3819

But people often forget that satoshi didn't romanticize decentralization over trustlessness and immutability. Instead only this part of the quote became famous.

If you don't believe me or don't get it, I don't have time to try to convince you, sorry.

[franky1]

i no longer see that period as a blocksize war era...
after all those fighting against increasing it even fighting against 2mb, ended up being the ones making it 4mb*
*(1mb base tx (input-output-value) count | 3mb bloaty weighted junk space(signing policy doesnt need 3x space))

i instead call it the war to fight for brand control of bitcoin. where core are now the central point of failure
we no longer have a bitcoin that used the solutions to the byzantine generals problem. we just have one master general and obediant soldiers

we are no longer in the era of dial-up or base 0.5mb ADSL.. internet has sped up alot more than certain people want to admit
hard drives can store more then all historic, PLUS a decade of future blockdata for less than 10 bitcoin fees this week

the issue is not hard drive costs if people can store a decade of data for less than doing 10 payments this week. the real problem is the desire of certain people to hinder transaction counts, to not allow the spread of miner bonuses across more users. but instead force less users to pay more.. or what they prefer is people to move to their middle men services to get extra fee's not going to miners bonus

[Kruw]

Increasing block space capacity is even more of a taboo now than it was in the 2015-2017 era.  Since then, we have proof that:

- Lightning works to provide far lower fees and far faster confirmation than on chain payments
- There is an infinite amount of demand for block space (inscriptions) no matter how big you make the blocks
- Competing chains with more block space than Bitcoin (specifically, Ethereum) still have even higher fees than Bitcoin

With these above results, one could only conclude big block proponents are attempting blockchain suicide.  The only improvement since 2015 that vindicates big block proponents is zerosync (still in progress*).

[CreepyUncleJoe]

In 2017, the high fees and slow confirmation times pushed many large merchants away from Bitcoin. Increasing block capacity could help address these issues and encourage broader merchant acceptance.

[franky1]

Increasing block space capacity is even more of a taboo now than it was in the 2015-2017 era.  Since then, we have proof that:

- Lightning works to provide far lower fees and far faster confirmation than on chain payments
- There is an infinite amount of demand for block space (inscriptions) no matter how big you make the blocks
- Competing chains with more block space than Bitcoin (specifically, Ethereum) still have even higher fees than Bitcoin

With these above results, one could only conclude big block proponents are attempting blockchain suicide.  The only improvement (still in progress*) since 2015 that vindicates big block proponents is zerosync.

lightning has flaws and bugs.. even the LN devs admit to it. they admit they cant code a fix for their flaws, its why then then create middlemen services(for extra fee's/rents/subscriptions)  to work as workarounds
lightning has not solved anything.

lightning has not proved its aim at reducing congestion.. lightning does not even do "confirmation" value transfer security
bitcoin can if core deem it their plan. close the exploits that allow 'inscriptions'

if you want to go play on another network thats less secure. you are ok to.. but bitcoiners want bitcoin solutions

[jrrsparkles]

the issue is not hard drive costs if people can store a decade of data for less than doing 10 payments this week. the real problem is the desire of certain people to hinder transaction counts, to not allow the spread of miner bonuses across more users. but instead force less users to pay more.. or what they prefer is people to move to their middle men services to get extra fee's not going to miners bonus

Valid point but increasing the block size further will end up in empty/half filled blocks all the time if the ordinals don't spam the network even right now so 1MB block size still is being effective and also keeps the rewards as much as possible for the miners.

[digaran]

Stompix is the expert listen to him. Lol^8196.
Taboo is: not talking about miners scamming users, large pools I mean.
Taboo is: not talking about the inaction of developers.
Taboo is: staying silent and let potential long term userbase migrate to other networks.

I would say if someone comes up with a plan that doesn't involve lining up their own pockets, that has no ties to corporations, with a decent upgrade proposal that could keep everyone or the majority fairly happy and satisfied, that doesn't alter the true nature of Bitcoin, that doesn't betray Satoshi's vision the essence of true decentralized banking system where transfer of monetary values is the top priority, that doesn't want to comply with regulations and work for governments, that the code is very well written to make necessary upgrades easier than before.  PLEASE don't wake me up and let me join them. It was a good dream though.🥱

[alani123]

Increasing block space capacity is even more of a taboo now than it was in the 2015-2017 era.  Since then, we have proof that:

- Lightning works to provide far lower fees and far faster confirmation than on chain payments
- There is an infinite amount of demand for block space (inscriptions) no matter how big you make the blocks
- Competing chains with more block space than Bitcoin (specifically, Ethereum) still have even higher fees than Bitcoin

With these above results, one could only conclude big block proponents are attempting blockchain suicide.  The only improvement (still in progress*) since 2015 that vindicates big block proponents is zerosync.

Aren't you a developer? I thought you'd know the difference between Ethereum and Bitcoin. Even though the Ethereum Blockchain is above 15 TB, minimum gas requirements put it in a situation where fees can never be low. And to think, these gas requirements were programmed while ETH had an ICO pricing it at 30 or so cents. So this is entirely irrelevant to our discussion. It's a different architecture, very inefficient, and built on a very different approach.

As of the lightning network, it has been in development for so many years and still no end on sight to ever being viable. I wrote about it here: https://bitcointalk.org/index.php?topic=5471172.40

Also, economic wise, lower fees will result in higher transaction numbers which will potentially balance out the total amount of fees to a bigger number. It's basic economic principles: https://bitcointalk.org/index.php?topic=5474087.0

[PrivacyG]

If the Block capacity increases.  Do we get the Network congestion problem solved or do we get even more problems?

Think of it like this.  I, along many others, avoid moving Coins at all during congestion time.  But once the congestion is over, I start moving the Coins I wanted to move.  If Block size permits more, I imagine I will broadcast Transactions more often unless the congestion happens again.  And we get back to the same cycle.

How will the Block size increase help in this situation and not create even more problems?

-----

Yes.  I think it is still a taboo subject.  Many Bitcoiners do not even want to hear about the idea of Block size change.

[BlackHatCoiner]

Neither in favor, nor against.

Bigger blocks pros:
- Less congestion.

Bigger blocks cons:
- More time required for verification (right as well as storage requirement).
- Mining becomes less competitive.

I agree, though, that even lightning is getting expensive to work with 4 MB block size limit (and there isn't a lot of demand for lightning yet).

[franky1]

Neither in favor, nor against.

Bigger blocks cons:
- More time required for verification (right as well as storage requirement).
- Mining becomes less competitive.

lets handle black hatters cons
more time required for verification... LIE
nodes verify 99% of transactions as they are relayed pre confirm.. nodes can handle hundreds of megabytes (as proven by bitcoins node mempools of each node).. and funnily enough devs own admissions that nodes on mainnet and subnetworks can sign and pass millions of transactions a second)
(yep when LN "co-signs a state" both parties can sign relay and check in the same time as verifying a bitcoin transaction.. and if LN can do that then its admitting bitcoin nodes can verify the same "millions of transactions a second" unconfirmed too)


mining becomes less competitive... LIE
there is more to the reward vs fee vs market price economics than just "tx pay more"
16000 X $1 (using unified 4mb instead of segregated 4mb) = $16000
4000 X $2 (usual segregated 4mb when not spammed) = $8000

as you can see mining can get a bigger fee bonus by letting in more transactions without having to cost users more

and by the way.. every time there is a halving idiots think this is the time to 2x+ the fee's to offset the reward halving.. another lie..
its actually where the MARKET increases to compensate the reward halving. but that makes fee's $ more so fee's need to decrease to prolong bitcoin utility and desire of people to want to use bitcoin..

if you want to keep the bitcoin market alive you need to keep BITCOIN usable. otherwise people move over to altcoins that have the same crappy subnetworks. but have cheaper fees

trying to suggest halt bitcoin growth and promote subnetworks solves nothing. because people will just use the same subnetwork. but with an altcoin as a the settlement..

i find it absolutely hilarious how sponsored devs pretending to be bitcoin devs but having subnetwork adoring motives, say how LN can verify a channel partners "state" to the tune of 1million x/sec... but then tries to say bitcoin is broke can cant verify more then 4k/10min before breaking
such lies, such deceit , such scumbag methods of promoting an underclass subnetwork but trying to say its a network "ontop" of bitcoin.. SHAMEFUL tactics
reality is when doing the tests on how fast LN can sign, relay and verify states.. they are admitting how fast bitcoin pre-confirm relay can be

[cryptosize]

Every attempt to increase the block size limit via hard forks (BCH, BSV etc.) has produced blockchains with less security (aka shitcoins):

https://cointelegraph.com/news/bitcoin-sv-rocked-by-three-51-attacks-in-as-many-months
https://www.coindesk.com/tech/2019/05/24/bitcoin-cash-miners-undo-attackers-transactions-with-51-attack/

I wish there was an easy solution, but there isn't in the IT space. I mean, if you could invent an algorithm to compress 4GB of data into a 4MB block, then sure, everyone will applaud it.

People still don't understand why the inferior IPv4 (32-bit) is the dominant protocol compared to the superior IPv6 (128-bit).

Either you understand that backwards compatibility rules the IT sector, or you don't. IT-savvy folks get it.

[franky1]

Every attempt to increase the block size limit via hard forks (BCH, BSV etc.) has produced blockchains with less security (aka shitcoins):

correction.. every attempt done without cores consent has been treated as an opposition
it requires kissing cores ass to get them to code it, other wise all other non core node attempt will get REKT

core reference client dominance is obvious to the network and users.. but "politicallly" they want to tongue in cheek hint they know they are in power without saying it. because saying it admits to the central point of failure problem and it opens them up to litigation..
.. however they do not want to release their control. by being open to other brands offering  protocol level proposals.. because they dont want to relinquish their power

they pretend to be more decentralised by splitting their blockstream dev group into (fake) separate companies of chaincodlabs and brinks but its obviously they are still collectively sister companies of the blockstream group who manage core.

so again it still requires appeasing the core gatekeepers to get the core devs to write code to fix their exploit..
.. but right now due to litigation risk where other parties can ask them to put code in.. they want to pretend they cant put code in on request.

[franky1]

FRANCY1, save me from the sensors who deleted my subject like common spam. Is the truth disturbing? Sorry to impose on myself like this before my probable disappearance...
---------------------

Why Is Money Valuable?

Interestingly enough, the peculiar procedure of economic measurement is opposed to the methods of measurement in science. Indeed measurement in science is based on the impartiality of the measuring technician. Measuring by money is actually based on the bias of everyone involved. What is more, in science units of measurement are presumably stable, yet money as a standard of economic measurement is constantly changing value.
Before I discuss the instability of money, the following question should be answered: why money generally retains value despite many reasons for value variations, why we somehow expect money to be stable despite the knowledge that it is not?

The utility of a certain consumable commodity be it cattle or sheep skin when that commodity played the role of money was an understandable reason for that money to retain value. In the case of gold or paper money rarity, social convention or respect for the government which issued the money can be the reason behind the fact that such things can start playing the role of money but not yet the reason why that money will retain its value.
The actual reason for money to remain valuable is the fact that people want more of it and once they get it, they choose to hold it and not give it away easily.

this explanation alone is wrong
but your post is in the wrong topic

[philipma1957]

Neither in favor, nor against.

Bigger blocks pros:
- Less congestion.

Bigger blocks cons:
- More time required for verification (right as well as storage requirement).
- Mining becomes less competitive.

I agree, though, that even lightning is getting expensive to work with 4 MB block size limit (and there isn't a lot of demand for lightning yet).

Good post.

now sha-256  btc 10 blocks in 1 hour  plus LN

and scrypt doge/LTC 120 blocks in 1 hour plus LN

this is a constant. 

Sha-256 miners earn about 32,400,000 in rewards daily plus whatever the fees are.
scrypt miners earn about 1,200,000 in rewards daily plus what ever the fees are.

btw this conflict will always make LTC/Doge look to jack BTC fees to attract customers.

This dynamic is a driving force for btc fees to get jacked.

I can see six or seven angles here not sure where we go to down the road.

[OgNasty]

I have said many times that I feel satoshi’s biggest mistake with Bitcoin was not putting in a block size adjustment feature similar to the way difficulty is adjusted. I believe the blocksize limit was put in place as a knee jerk reaction to the chain being spammed and if satoshi had more time on this earth a method to adjust the blocksize limit would have been put in place.

[alani123]

Every attempt to increase the block size limit via hard forks (BCH, BSV etc.) has produced blockchains with less security (aka shitcoins):

https://cointelegraph.com/news/bitcoin-sv-rocked-by-three-51-attacks-in-as-many-months
https://www.coindesk.com/tech/2019/05/24/bitcoin-cash-miners-undo-attackers-transactions-with-51-attack/

I wish there was an easy solution, but there isn't in the IT space. I mean, if you could invent an algorithm to compress 4GB of data into a 4MB block, then sure, everyone will applaud it.

People still don't understand why the inferior IPv4 (32-bit) is the dominant protocol compared to the superior IPv6 (128-bit).

Either you understand that backwards compatibility rules the IT sector, or you don't. IT-savvy folks get it.

What makes BCH and BSV shitcoins is a plethora of reasons other than just having bigger blocks. Mind you, bitcoin was very close to having double the block capacity it has now when SegWit got activated. It was called SegWit2x. And in the end even without the 2x part, bitcoin went from 1MB blocks to 4MB. So it BTC a shitcoin as well?
No! Because bitcoin has a community, some fragments of democracy (unlike the two aforementioned coins that are self centered projects), the best developers, the biggest and most active community.

I have said many times that I feel satoshi’s biggest mistake with Bitcoin was not putting in a block size adjustment feature similar to the way difficulty is adjusted. I believe the blocksize limit was put in place as a knee jerk reaction to the chain being spammed and if satoshi had more time on this earth a method to adjust the blocksize limit would have been put in place.

Satoshi could have only done so much himself.
And it's funny how these days many people bring up sidechains and lightning as potential solutions to bitcoin's scalability issue, based on the argument that bitcoin should change as little as possible, when satoshi himself admitted that the infrastructure as it stood when he was around in the community was insufficient for scaling, and would eventually need to be changed.

Not changing bitcoin at least slightly to accommodate for biger volumes of transactions, especially when there's demand for that, is actually against satoshi's very vision.

[hatshepsut93]

It's not a taboo, it has never been a taboo, you could always post topics about it on this forum, it's just that most users are against it, because they understand the danger of having high requirements for running a full node, which would make the network much smaller as only large entities would be able to afford to run a full node, so nodes would be more like datacenters rather than the regular users.

[cryptosize]

What makes BCH and BSV shitcoins is a plethora of reasons other than just having bigger blocks. Mind you, bitcoin was very close to having double the block capacity it has now when SegWit got activated. It was called SegWit2x. And in the end even without the 2x part, bitcoin went from 1MB blocks to 4MB. So it BTC a shitcoin as well?
No! Because bitcoin has a community, some fragments of democracy (unlike the two aforementioned coins that are self centered projects), the best developers, the biggest and most active community.

Sure, but this topic is strictly about the block size. No?

Should I also mention the sad fact about BSV implementing censorship/coin confiscation features?

There you go:

https://twitter.com/BobSummerwill/status/1577714409618931713
https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v1.0.13

[DooMAD]

The biggest hurdle remains that those running non-mining nodes carry the burden of helping to secure the chain while receiving no economic reward.  They gain benefits like privacy and not relying upon trusting others.  But, financially, there's no recompense for the service they provide.  As such, they will only offer to carry a greater burden at a time of their choosing and not merely when others complain about it.

Make all the arguments about decentralisation, propagation and politics you want, but all those points largely fall by the wayside the moment you start asking others to do more than they're already doing, just so it might benefit you and give you lower tx fees.

When the majority of nodes are willing, that's when it'll happen.  

[BlackHatCoiner]

Sha-256 miners earn about 32,400,000 in rewards daily plus whatever the fees are.

Which, as we speak, are really high. Most recent block - 817080 - was mined with 193 sat/vb median fee (!), gathering a total of 2.1 BTC (!!!) from transaction fees alone.

And it's funny how these days many people bring up sidechains and lightning as potential solutions to bitcoin's scalability issue

Their reasoning goes as following: whether we rise the block size or not, there will still be scalability problem. Even if the block size limit was 1 GB, the spam attack would cost nearly zero, and there would probably still exist a fee market (much less intensive than now of course). People would really take advantage of the 144 gigabytes of space every day. You can verify that on BSV blockchain, where they have saved whole movies. Needless to say that with 1 GB of block space, one mining pool can take advantage of the time it takes to verify the block and kill off the competition.

This is an indication that we need more than just one layer.

[alani123]

What makes BCH and BSV shitcoins is a plethora of reasons other than just having bigger blocks. Mind you, bitcoin was very close to having double the block capacity it has now when SegWit got activated. It was called SegWit2x. And in the end even without the 2x part, bitcoin went from 1MB blocks to 4MB. So it BTC a shitcoin as well?
No! Because bitcoin has a community, some fragments of democracy (unlike the two aforementioned coins that are self centered projects), the best developers, the biggest and most active community.

Sure, but this topic is strictly about the block size. No?

Should I also mention the sad fact about BSV implementing censorship/coin confiscation features?

There you go:

https://twitter.com/BobSummerwill/status/1577714409618931713
https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v1.0.13

I don't understand the point then. If you agree that BCH and BSV are shitcoins for reasons other than the blockchsize increase, what makes you be against block size increases then?
If bitcoin increases its block capacity it wouldn't make it lose all that makes it good, right?

The biggest hurdle remains that those running non-mining nodes carry the burden of helping to secure the chain while receiving no economic reward.  They gain benefits like privacy and not relying upon trusting others.  But, financially, there's no recompense for the service they provide.  As such, they will only offer to carry a greater burden at a time of their choosing and not merely when others complain about it.

Make all the arguments about decentralisation, propagation and politics you want, but all those points largely fall by the wayside the moment you start asking others to do more than they're already doing, just so it might benefit you and give you lower tx fees.

When the majority of nodes are willing, that's when it'll happen.  

If we are to examine the specs of those running a bitcoin full node right now, how many would 100% be unable to sync with a block size increase? And what would cause it? If let's say the block size goes from 4 MB now to 8 MB, maybe a concern would be CPU power. But bitcoin core already works great with even the weaker CPUs. The only requirement listed in bitcoin.org is for the CPU to be above 1GHz. These days it's actually hard to find a CPU that old for sale.

The other requirement might be disk space. Well with even the maximum expansion of 4 MB per 10 minutes, the BTC blockchain can't grow more than 210240 MB a year (525600 minutes in a year / 10 minute block time * 4 MB block capacity). So a 2 fold increase could generate 400GB blockchain files in a year at MAXIMUM utilization. Honestly it's not that bad. Disk space is very cheap when we talk about these sizes. A 1 TB HDD costs 20$ new now.

And also one does not need to store the full historical record of transactions to host a trustless node. A node without the full blockchain stored can still produce trustless network information so long as it's connected to the network.

The biggest issue might be bandwidth. Currently bitcoin.org lists 15 GB/month as a requirement to run bitcoin core. Many parts of the world have slow internet but honestly 15 GB a month is nothing.
What connection speed translates to 15 GB a month. Let's see. 15 GB is 120000 Megabits. If you divide 120k to the seconds in a month, you get 0.04566 Mbits per second or 45.66 Kilobits. Speeds such low aren't even commercially available anymore. 2g and EDGE connections have been taken out of commision in most places for at least 3 years now and so has been ISDN/Dial up etc.. Anyone with signal or an internet connection to his residence should be able to run a bitcoin node reliably even if the bandwidth requirement was increased 10 fold.

And all that IF the blocksize increase is utilized fully (which is unlikely to happen imminently)


tl;dr my calculations show that even with a substantial block size increase at full utilization most hosting a bitcoin node won't need to upgrade their infastracture. And those that will probably will still be able to host a node by spending an extra 50$ maximum once.

[franky1]

The biggest hurdle remains that those running non-mining nodes carry the burden of helping to secure the chain while receiving no economic reward.  They gain benefits like privacy and not relying upon trusting others.  But, financially, there's no recompense for the service they provide.  As such, they will only offer to carry a greater burden at a time of their choosing and not merely when others complain about it.

Make all the arguments about decentralisation, propagation and politics you want, but all those points largely fall by the wayside the moment you start asking others to do more than they're already doing, just so it might benefit you and give you lower tx fees.

When the majority of nodes are willing, that's when it'll happen.  

you love fee's being $4-$20
you dont want fee's being $0.10-$0.50

but have you done the math
people that run a node 24-7 also are people that use bitcoin to transact regularly, so want it uptodated(synced) and ready to use..
now imagine a pc costing $400 that can store all historic data and the next 10 years.. (4tb hard drive is not even $100)
so how much is that computer again, yep $400 as said for 10 years utility (with alot of space left over for normal computer tasks)

now lets imagine tx's fees cost for 10 years of 1 tx a day
$0.10 = $365, ok reasonable it costs less to use bitcoin than it does to secure it
$0.50 = $1,825 hmm. well thats $185 a year. but still more then the PC price so more to use than to secure
$4.00 = $14600 hmm. well thats $1,480 a year. now thats alot to use it especially compared to securing it
$20.00= $73,000 .ugh.. do i even need to say it. $7.3k a year just to use it but only $40 a year to secure it

now if you want to cry that node users need to cover their $40 a year node costs.. how come you are happy to see tx fee's costing $7.3k for daily use..
.. oh wait you dont want people to use bitcoin daily..
.. but now the question becomes if people are only doing sessions 2 times a year to have $40 fee cost.. they are not going to run a node all year . they will just run it for a week per year to sync, transact shut down

making bitcoin harder to TRANSACT daily will be the reason normal users dont use full nodes.. it wont be due to hardware costs
all that will be left is commercial services running nodes and offering utxo data to lite wallets. and you love that idea. you love middle men services charging fee's and giving commissions

[alani123]

And it's funny how these days many people bring up sidechains and lightning as potential solutions to bitcoin's scalability issue

Their reasoning goes as following: whether we rise the block size or not, there will still be scalability problem. Even if the block size limit was 1 GB, the spam attack would cost nearly zero, and there would probably still exist a fee market (much less intensive than now of course). People would really take advantage of the 144 gigabytes of space every day. You can verify that on BSV blockchain, where they have saved whole movies. Needless to say that with 1 GB of block space, one mining pool can take advantage of the time it takes to verify the block and kill off the competition.

This is an indication that we need more than just one layer.

I think that the issue of anti-spam measures kind of solves itself when we have a deflationary and scarce coin like bitcoin.
The minimum on-chain unit is 1 satoshi, which with current prices is at 0.0003604 USD. Ste standard segwit transaction is 140 vBytes according to mempool.space. So even at fees of 1 satoshi per vByte one would have to pay at least 5 dollar cents per btc transaction. Of course, a block size increase doesn't have to completely decimate the fee market, which is a useful feature. A block-size increase could be dynamic and adjustable. There were such solutions presented even circa 2015 with the bitcoin XT and bitcoin classic clients. Under these measures, a spam attack could in par to how expensive it is now.

[cryptosize]

I don't understand the point then. If you agree that BCH and BSV are shitcoins for reasons other than the blockchsize increase, what makes you be against block size increases then?
If bitcoin increases its block capacity it wouldn't make it lose all that makes it good, right?

It's not that simple, it's more complicated.

Propagation time would increase, orphan blocks would increase, centralization would increase.

And what about people storing 4K pedo pr0n inside the blockchain? Why make it so easy?

Who the hell would wanna run a node that stores pedo pr0n? Unless you wanna destroy the BTC blockchain (to promote CBDC or whatever), it makes zero sense.

[alani123]

I don't understand the point then. If you agree that BCH and BSV are shitcoins for reasons other than the blockchsize increase, what makes you be against block size increases then?
If bitcoin increases its block capacity it wouldn't make it lose all that makes it good, right?

It's not that simple, it's more complicated.

Propagation time would increase, orphan blocks would increase, centralization would increase.

And what about people storing 4K pedo pr0n inside the blockchain? Why make it so easy?

Who the hell would wanna run a node that stores pedo pr0n? Unless you wanna destroy the BTC blockchain (to promote CBDC or whatever), it makes zero sense.

From a theoretical standpoint, anyone can post whatever imagery in the Blockchain even now, no matter how expensive. Ordinals tech which utilizes Taproot along with SegWit discount make that even easier to happen on bitcoins chain.

As of orphan blocks, I think miners will be able to handle having access to decent latency internet... Even most miners connect to pools these days and let them handle block propagation so this affects very few parties which are big enough to work on it I think. They were complaining about going above 1MB blocks then but handled 4MB well...

Can anyone tell me if the data I see on Blockchain.info is true? Is it true that there hasn't been a single orphan block since 2017 or did they just stop counting?

[DooMAD]

you love fee's being $4-$20
you dont want fee's being $0.10-$0.50

What I love is how you literally can't post in a topic without proclaiming what I supposedly do or don't want.  Get it through your sociopath skull, what I want or don't want is wholly immaterial.  I'm not the network.  It's what all the other participants want which matters.  Obsess over me all you like, as you appear to be my number one fangirl.  But try to understand, in the grand scheme of things, I don't matter in the slightest.

It's as though you don't grasp the fact that other people exist and have thoughts and opinions of their own.  There always has to be some boogeyman with you.  Some nefarious characters pulling the strings.  And only franky1 can save us all from the horrors.  You're fucking insane.

[pooya87]

Your poll can not be answered because it is missing the important part about "time". In other words it is unclear when you ask "What are your thoughts on increasing bitcoin's block capacity?" when do you mean?
For example if it is a hard fork to increase block size in the future when the need arises, then my answer is a big fat YES. We definitely need to increase the on-chain capacity at some point but the important part is the "at some point" part.

Right now we do not need a block capacity increase. The reason is pretty simple: the adoption hasn't grown enough for the current block capacity to not-be enough for the legitimate usage. Since I have to dot all the eyes and cross all the tees: Legitimate use is anything that is not a spam attack, meaning where people use bitcoin to transfer money or in other words when Bitcoin is the "peer to peer digital cash system" that it was intended to.
When it is used as "cloud storage" it is considered abuse and the transactions are spam. Meaning right now that the congestion is caused by abusing the protocol to perform an attack on bitcoin, this is not natural and the exploit should be fixed instead of increasing the capacity to let bigger spam in.

P.S. I don't think increasing block capacity has ever been a "taboo" as some like to exaggerate it. HOW it is increased has been the source of a lot of disagreement.

[stompix]

I'll start by dedicating this thread to stompix (honestly, no hate, debate with him is enjoyable even though we sometimes disagree) who dared me to make this thread.

Well, congratulations, you took the bait challenge!
Unlike in my topic which I timed to the situation, I did make a big mistake with this challenge, and I realized it too late, my bad
You asked this question when fees are high, so it's pretty obvious the army of pitchforks will not dare to come in the open to stone you to death for proposing something only Roger Ver would do /s
Yup messed up this whole opportunity of having a bloody blockwar, that's on me!

As for me, I was just this week shown how it's physically impossible to have blocks larger than 4MB because only nodes that own a Titan computer and their own private global fiber optic cables would be able to cope with larger blocks!

Well well well... This is an age old arguement.

As I see Franky going on a rampage here, normal people do understand that there was a truckload of sarcasm in that comparison, right? Right?!!

you love fee's being $4-$20
you dont want fee's being $0.10-$0.50

but have you done the math
people that run a node 24-7 also are people that use bitcoin to transact regularly, so want it uptodated(synced) and ready to use..
now imagine a pc costing $400 that can store all historic data and the next 10 years.. (4tb hard drive is not even $100)
so how much is that computer again, yep $400 as said for 10 years utility (with alot of space left over for normal computer tasks)

now lets imagine tx's fees cost for 10 years of 1 tx a day
$0.10 = $365, ok reasonable it costs less to use bitcoin than it does to secure it
$0.50 = $1,825 hmm. well thats $185 a year. but still more then the PC price so more to use than to secure
$4.00 = $14600 hmm. well thats $1,480 a year. now thats alot to use it especially compared to securing it
$20.00= $73,000 .ugh.. do i even need to say it. $7.3k a year just to use it but only $40 a year to secure it

now if you want to cry that node users need to cover their $40 a year node costs.. how come you are happy to see tx fee's costing $7.3k for daily use..

And now I think I will have to make a trip to the emergency room since obviously by the end of the day I will have to butcher the mouse and chop the hand I've used to give franky merit for this..

It's not that simple, it's more complicated.
Propagation time would increase, orphan blocks would increase, centralization would increase.

ETH was pushing over 1 MB blocks every 30 seconds and if we look at the times it was POW the hashrate and the nodes were far more decentralized than BTC, so no, the whole thing holds no water. Dogecoin does so over 60 seconds, only for BTC would those pose problems, because...no reason!
If 1MB was small enough to achieve decentralization in 2009 I can hardly see why an increase of an order of magnitude would be hard now.

[Wind_FURY]

Circa 2014 the block size wars took bitcoin by storm.
Eventually after a lot of drama that has been well documented elsewhere (I made my own attempt documenting a time line of the blocksize wars, its outcomes and conclusions here).

But I'm starting this poll in hopes of getting the community's opinion. So for this post I'll not go through my opinion in the OP.

Please feel free to answer the question in the poll and even better if you can also explain your answer.

Back in 2015, and after the adoption of a compromise in the form of SegWit, [/b]the topic of the block capacity was very taboo[/b].

It wasn't "taboo", ser. It was because there were some people in the community, like Roger Ver, who were trying to turn it into a philosophical debate, and there were developers, like Mike Hearn, who were spreading FUD and disinformation, when it was merely a technical debate.

Well, we're in 2023 now, and for different reasons congestion is still an issue. Increasing the capacity of bitcoin blocks could potentially be a solution to the issues of high fees and congestion.

So I think it's worth exploring what people think about this issue. Please share your thoughts below.

That's true, but DYOR. Change one parameter on-chain, and it will definitely affect other parameters that could be used as attack vectors against the network.

[HmmMAA]

Since I have to dot all the eyes and cross all the tees: Legitimate use is anything that is not a spam attack, meaning where people use bitcoin to transfer money or in other words when Bitcoin is the "peer to peer digital cash system" that it was intended to.

If the sole purpose of bitcoin was just to transfer money what's the role of OP_pushdata ? And especially OP_pushdata4 ?
Seems that the creator had a different view than yours .

[BlackHatCoiner]

The reason is pretty simple: the adoption hasn't grown enough for the current block capacity to not-be enough for the legitimate usage.

And how do you measure that? Even if we were to follow that route, and have a block size limit that corresponds to the "legitimate usage", how do we begin? In my opinion, the adoption has grown a lot since the last time the Bitcoin community had had this debate.

ETH was pushing over 1 MB blocks every 30 seconds and if we look at the times it was POW the hashrate and the nodes were far more decentralized than BTC, so no, the whole thing holds no water. Dogecoin does so over 60 seconds, only for BTC would those pose problems, because...no reason!

When Ethereum supported Proof-of-Work, it had so called "uncle blocks" (the respective stale blocks in Bitcoin), but that came with additional economic complexity (I wouldn't suggest comparing Bitcoin with Ethereum as they are different in almost everything). As for Dogecoin, lol. If you believe anyone takes this seriously, then I don't know what to say.

[stompix]

As for Dogecoin, lol. If you believe anyone takes this seriously, then I don't know what to say.

Then you should start saying that to everyone on this board who suggests using dogecoin instead of Bitcoin for small purchases, and there is a ton of them trust me, you'll be done by the time the mempool is empty. And if you don't believe it:
https://bitinfocharts.com/comparison/transactions-btc-doge.html#6m
This happens every single time Bitcoin fees spike, thousands move to doge!
Is LTC also laughable, or does it simply work ?

Common this is so 640k RAM will be enough for everyone is getting old!
People torrent TB of data every day on their home computers and we're scared of 1TB of storage over a year for a thing that is supposed to threaten a trillion fiat-based economy. Seriously? Latency, data transfer, FML, you have tens of thousands of ....models.....live streaming in 4k but somehow it's magically impossible to push 10MB in 10 fucking minutes to every single hole in this world.
But Bitcoin is going to replace banks while serving 600k customers a day!  

And furthermore, when some other coins manage to do the impossible, it's laughable! We're going to colonize Mars in 2240 and while beaming in one split second an entire cargo from planet to planet some will still say more than 4MB in 10 minutes it's technically impossible!

When Ethereum supported Proof-of-Work, it had so called "uncle blocks" (the respective stale blocks in Bitcoin), but that came with additional economic complexity (I wouldn't suggest comparing Bitcoin with Ethereum as they are different in almost everything).

Weird..
Block 817,119 was mined at 04:44:31
817,118 at 04:43:10,
817,117 at 04:42:19
3 blocks in 2 minutes, how was that possible if 1MB blocks over 60 seconds is such a danger?

Oh, maybe a one in a year event, let's go just 30 blocks further over last night:
817,089   2023-11-16 23:49:47
817,088   2023-11-16 23:47:59
817,087   2023-11-16 23:47:34

Did I miss the news on the blockchain breaking down and bitcoin becoming unusable last night when those 3 blocks in under 90 seconds happened?

We constantly mine blocks under 60 seconds from each other for years by the thousands and there has been no problem whatsoever, how could one even think this would be a threat?

[vapourminer]

When Ethereum supported Proof-of-Work, it had so called "uncle blocks" (the respective stale blocks in Bitcoin), but that came with additional economic complexity.

yeah stales happened so often that you could get rewarded some amount of eth for submitting stale blocks and i cant see bitcoin doing that.

[franky1]

P.S. I don't think increasing block capacity has ever been a "taboo" as some like to exaggerate it. HOW it is increased has been the source of a lot of disagreement.

the great thing about the blockchain. is that there is piles of data to accumulate statistics from

over X period
XX%+ of blocks are XX%+ filled
blocks total fees are >X sats per byte  (block total fees / block total byte)
transaction count vs sat/byte fee

heck you can even formulate if blocks are prefering "batch" vs "individual"
EG individuals usually only do a couple outputs.. (destination+change) so if transactions have too many outputs it shows users are prefering to batch up transactions or use centralised services that batch

..
it does not have to be a political decision done by devs. it can be a programmed trigger based on the data

[franky1]

Weird..
Block 817,119 was mined at 04:44:31
817,118 at 04:43:10,
817,117 at 04:42:19
3 blocks in 2 minutes, how was that possible if 1MB blocks over 60 seconds is such a danger?

Oh, maybe a one in a year event, let's go just 30 blocks further over last night:
817,089   2023-11-16 23:49:47
817,088   2023-11-16 23:47:59
817,087   2023-11-16 23:47:34

Did I miss the news on the blockchain breaking down and bitcoin becoming unusable last night when those 3 blocks in under 90 seconds happened?

We constantly mine blocks under 60 seconds from each other for years by the thousands and there has been no problem whatsoever, how could one even think this would be a threat?

also it didnt break the tor nodes that relay/propagate at very slow internet speeds.. so the "speed" drama risk is also a myth,

its also worth noting that CORE stop supporting windows versions when windows stop supporting their old versions
windows 7 bbecame unsupported in 2020 so windows 8 is min standard core devs find viable for bitcoin now
windows 8 was first released in 2012. and 3TB hard drives in 2012 were only $150 back then.
thus the cost myth of running a ~$400 pc from 2012 being unable to handle bitcoin for next 10 years is a myth

[BlackHatCoiner]

Then you should start saying that to everyone on this board who suggests using dogecoin instead of Bitcoin for small purchases

Can you point me to who does that? You know, who actually installs a Dogecoin full node and lets it sync. Because, you know. Cryptocurrency is about eliminating the third party, and last time I used Dogecoin, it was more like peer-to-CEX-to-peer cash.

And furthermore, when some other coins manage to do the impossible, it's laughable!

It is laughable to pretend that the same levels of security and decentralization exist in BSV, Solana, etc. If other coins "manage to do the impossible", how come they are still shitcoins? Has it ever crossed your mind that there is much less activity in both Dogecoin and Litecoin? Have you considered the fact that these are pretty much prone to the same problem? It's just that only 1% of the userbase uses them to transact.

And for once more, the problem isn't the storage requirement for running a full node. It's part of the problem. The greatest problem is the time that it'll take to verify the entire chain, there will be great concern in breaking backwards compatibility, you make spamming costing less, and in the end, you don't solve the problem. You're just delaying it.

[apogio]

Has it ever crossed your mind that there is much less activity in both Dogecoin and Litecoin? Have you considered the fact that these are pretty much prone to the same problem?

That's exactly the thought I have for Monero.

I mean, the only chain I like apart from Bitcoin is Monero. I own some XMR too. I know that monero has a dynamic block size, depending on the congestion, which I also think is not the best idea.

But if you  look into Monero's average block size against Bitcoin's average block size, you will see Monero's is lower. Why? Bexause the traffic / activity in Monero is much smaller than the traffic in Bitcoin's blockchain.

[cryptosize]

As for Dogecoin, lol. If you believe anyone takes this seriously, then I don't know what to say.

Then you should start saying that to everyone on this board who suggests using dogecoin instead of Bitcoin for small purchases, and there is a ton of them trust me, you'll be done by the time the mempool is empty. And if you don't believe it:
https://bitinfocharts.com/comparison/transactions-btc-doge.html#6m
This happens every single time Bitcoin fees spike, thousands move to doge!
Is LTC also laughable, or does it simply work ?

Common this is so 640k RAM will be enough for everyone is getting old!
People torrent TB of data every day on their home computers and we're scared of 1TB of storage over a year for a thing that is supposed to threaten a trillion fiat-based economy. Seriously? Latency, data transfer, FML, you have tens of thousands of ....models.....live streaming in 4k but somehow it's magically impossible to push 10MB in 10 fucking minutes to every single hole in this world.
But Bitcoin is going to replace banks while serving 600k customers a day!  

And furthermore, when some other coins manage to do the impossible, it's laughable! We're going to colonize Mars in 2240 and while beaming in one split second an entire cargo from planet to planet some will still say more than 4MB in 10 minutes it's technically impossible!

When Ethereum supported Proof-of-Work, it had so called "uncle blocks" (the respective stale blocks in Bitcoin), but that came with additional economic complexity (I wouldn't suggest comparing Bitcoin with Ethereum as they are different in almost everything).

Weird..
Block 817,119 was mined at 04:44:31
817,118 at 04:43:10,
817,117 at 04:42:19
3 blocks in 2 minutes, how was that possible if 1MB blocks over 60 seconds is such a danger?

Oh, maybe a one in a year event, let's go just 30 blocks further over last night:
817,089   2023-11-16 23:49:47
817,088   2023-11-16 23:47:59
817,087   2023-11-16 23:47:34

Did I miss the news on the blockchain breaking down and bitcoin becoming unusable last night when those 3 blocks in under 90 seconds happened?

We constantly mine blocks under 60 seconds from each other for years by the thousands and there has been no problem whatsoever, how could one even think this would be a threat?

What's your opinion about the blockchain trilemma? Is it BS?

[franky1]

It is laughable to pretend that the same levels of security and decentralization exist in BSV, Solana, etc. If other coins "manage to do the impossible", how come they are still shitcoins?

you do know that ASICS do not store blockdata right.. they just hash a hash
(a hash is the same length no matter the blocksize.. a blockheader is the same length no matter the tx data total)

the "security" of hash cost has NO correlation to block size

the reason altcoins are shit is due to the fact that the social steer towards them does not exist.
most altcoins have no underlying value and their market price is artificially held up. they have no good 'store of value'


the market speculation vs underlying economic store of value... has nothing to do with block bytes
the block bytes have nothing to do with hashpower cost/security

What's your opinion about the blockchain trilemma? Is it BS?

as just told to blackhat.. the
scalability(blocksize/tx count) <> security(mining) are not correlated
scalability(blocksize/tx count) <> decentralisation are not in opposition

the more transactions individuals can do the more individuals
the less transactions, means users tend to not run nodes and just used centralised services for daily use

once you get passed the myth ("PC's from a decade ago is not bitcoin capable"). you stop believing the myth
instead you realise people can use old computer and not "servers" to run bitcoin even if it scales

[cryptosize]

its also worth noting that CORE stop supporting windows versions when windows stop supporting their old versions
windows 7 bbecame unsupported in 2020 so windows 8 is min standard core devs find viable for bitcoin now
windows 8 was first released in 2012. and 3TB hard drives in 2012 were only $150 back then.

You do realize that Windows is a far more popular desktop OS (compared to Linux) due to the fact it offers backwards compatibility with multi-decade old apps (like 32-bit apps from the 90s), right?

Hell, sometimes you're even allowed to install old drivers, just because the Windows kernel offers a stable ABI (unlike the Linux kernel). Good luck doing that with Linux closed-source drivers/binary blobs.

32-bit Windows OSes still support running 16-bit apps. Same for x86 CPUs. Are they superior compared to RISC CPUs? Not really.

Windows is not a superior OS compared to Linux, but it offers the best backwards compatibility out there.

I've experienced every kind of IT debate you can possibly imagine (Windows vs Linux, CISC vs RISC) and let me tell you that backwards compatibility always wins, for better or worse. Even game consoles these days offer BC.

I get it that some people prefer using superior solutions, but it's all a matter of network effect (aka Metcalfe's law).

Even the IBM PC won against Amiga... where is Commodore now?

People (especially those that claim to be "old" enough, let alone youngsters) should read some IT history.

[franky1]

its also worth noting that CORE stop supporting windows versions when windows stop supporting their old versions
windows 7 bbecame unsupported in 2020 so windows 8 is min standard core devs find viable for bitcoin now
windows 8 was first released in 2012. and 3TB hard drives in 2012 were only $150 back then.

You do realize that Windows is a far more popular desktop OS (compared to Linux) due to the fact it offers backwards compatibility with multi-decade old apps (like 32-bit apps from the 90s), right?

point was.. when core set the standards and put a age limit on their support.. it funny how some of them and their fangirls then try to incite some taboo that bitcoin cant run on windows 98 thus must(in their eyes) require quantum computer server farm.. (one extreme to another, no middleground)
i was simply using their standards against them that even their 12 year old computers can be $400 back then and still able to handle historic data PLUS many years of future data even if bitcoin scales.. simply to debunk their own myths using their own standards

its fun to us their own standards against them

[stompix]

Has it ever crossed your mind that there is much less activity in both Dogecoin and Litecoin?

Nope, I looked at the graph and saw how for two days of high fees Litecoin outperformed Bitcoin by 200 and 400 thousand per day.

Again you're making the same mistake, by saying that if a shitcoin doesn't have the needed popularity for 10MB capacity Bitcoin should either.
It's much like saying the USA doesn't need highways because the Vatican doesn't have either! Or like it's perfectly normal to cram a Walmart in a 100 sqm shop because the previous MomnPop grocery on that lot wasn't getting more than two customers per hour.

What's your opinion about the blockchain trilemma? Is it BS?

Yes, bs, because things have changed in the last 10 years.
If internet speed would be the same all over the glove with half of it not going above 10Mbit per second it would cost you $100
 for that 10Mbit connection yeah, if a black Friday deal would involve a 500GB HDD for 70$ yeah, it would be a trilema.
Now it's exactly bullshit!

And the most ridiculous thing is that we anchor ourselves in this stupid node thing for the sake of decentralization when half of the world won't be able to even power on a nowadays miner as 5300W over 380~415V would blow the fuse and burn your house in most countries.
But yeah, the 4TB drive is the problem.



The last 8 blocks were mined in 18 minutes, on average 2.25 minutes per block, I guess I should go an sell my coins because it's obvious the chain is going to explode as the impossible did become possible, right?

 

[BlackHatCoiner]

Again you're making the same mistake, by saying that if a shitcoin doesn't have the needed popularity for 10MB capacity Bitcoin should either.

No, you misinterpreted me. All I'm saying is that even with 10 MB, you will still sooner or later run out of block space, and fee market will arise. The difference is that you will have traded a percentage of the expenses of the user for the risk to split the network in half, and that there will be greater incentive to use it as a cloud storage.

I have pointed out that your analogy with the roads isn't accurate. If we double the roads, it doesn't mean the cars will double. But if the block size limit is 10 MB, then you should expect it to be full. If the block size is 100 MB, same. And same with 1 GB. If you take a look into BSV, they save entire movies. That is a verification nightmare, kills off the competition for small mining pools, and turns the currency into a shitcoin.

[stompix]

I have pointed out that your analogy with the roads isn't accurate. If we double the roads, it doesn't mean the cars will double. But if the block size limit is 10 MB, then you should expect it to be full. If the block size is 100 MB, same. And same with 1 GB. If you take a look into BSV, they save entire movies. That is a verification nightmare, kills off the competition for small mining pools, and turns the currency into a shitcoin.

And have you looked at the fees they pay for the spam on BSV?

To have the same current fees on Bitcoin but with 100 MB you would need spammer to pay at least 29 000 BTC, yeah 1 billion! in fees!
Every fucking day! Does it sound to you like something spammers would be able to do? 

Me and I'm sure everyone around doesn't give a damn if spammers fill blocks with 1sat/byte, what matters is that they are not forcing me to pay 100sat/b!

kills off the competition for small mining pools,

2013 called, 5 pools hold 90% of the hashrate nowadays! 

[BlackHatCoiner]

To have the same current fees on Bitcoin but with 100 MB you would need spammer to pay at least 29 000 BTC

You'll have to walk me through on this calculation.

Every fucking day! Does it sound to you like something spammers would be able to do?

You must have misinterpreted me again. Spammers don't care what other people are paying in fees. They only care if their spamming can pass as much cheaply as possible. If block size is 100 MB, then, besides the expectation that it'll always be full, you should expect that it'll be mostly consisted of data junk like Ordinals.

Me and I'm sure everyone around doesn't give a damn if spammers fill blocks with 1sat/byte, what matters is that they are not forcing me to pay 100sat/b!

If everyone doesn't give a damn about that, how come everyone stays on 4 MB block size network and doesn't move to BSV? You will probably never be forced to pay anything beyond 1 sat/vb there.

Edit:

2013 called, 5 pools hold 90% of the hashrate nowadays! 

Umm.. It's going to be a lot worse. Until the block is propagated from one pool to the other, the pool might have solved another block.

[Hamza2424]

After reading most of the posts, I'm sticking to my views, it's Taboo if by increasing the blocksize to avoid network congestion the individual miners are getting eliminated from the Network, Increasing Blocksize can be a potential solution for Bitcoin but it is inefficient, because with this solution there will be another mess about the decentralized nature of the Bitcoin.

The proposal accepted is open if increasing the blocksize individual miner's power is not affected because we don't want our node to be controlled by only large entities. Network congestion can be a problem but having a solution risking the entire nature of the network is a big mess. Simply avoid moving coins in network congestion in such scenarios until we have a better solution to scaling rather than increasing the block size only.

[franky1]

Again you're making the same mistake, by saying that if a shitcoin doesn't have the needed popularity for 10MB capacity Bitcoin should either.

No, you misinterpreted me. All I'm saying is that even with 10 MB, you will still sooner or later run out of block space, and fee market will arise. The difference is that you will have traded a percentage of the expenses of the user for the risk to split the network in half, and that there will be greater incentive to use it as a cloud storage.

whilst worrying about "expense of the user" a $150 hard drive bought in 2012 and is 3TB which is enough for historic data plus future data of next 5 yearsof 10mb blocks... thus dividing cost by 17 years is less then $10 a year

you are ignoring that instead of 2500 average legacy transactions there can be 25,000 legacy average
you are ignoring that instead of 4000 lean legacy transactions there can be 40,000 legacy average
where by instead of paying $2 a day for daily use ($730/year) they can pay $73/year, saving them $637/year

so while you point fingers at the $10/year hardware cost your ignoring the $730/year transaction cost for daily use

I have pointed out that your analogy with the roads isn't accurate. If we double the roads, it doesn't mean the cars will double. But if the block size limit is 10 MB, then you should expect it to be full. If the block size is 100 MB, same. And same with 1 GB. If you take a look into BSV, they save entire movies. That is a verification nightmare, kills off the competition for small mining pools, and turns the currency into a shitcoin.

movies dont get verified.. thats how they get in.. they bypass verification
also transaction verication of actual bitcoin rules for transactions is done 99.99% of the time at the pre-confirm relay of zero-confirm transactions..
funnily enough your favoured subnetwork devs had admitted that verifying transaction data shows nodes can handle millions of transactions a second..
funnily enough when node mempools hold 300mb of validated transactions and a block contains only 4mb.. your arguments about what a node can handle fall flat on its face

[apogio]

I vote in favour of smaller block sizes because:

Bitcoin was created to be accessible to everyone. Thus, running a miner and running a node must be cheap hardware-wise. Don't underestimate the power of nodes for the Bitcoin networks. It's not just the miners. Increasing the block size will require more disk space. More disk space require more money. 20% of the world hold approximately 80% of the global wealth, so requiring more money isn't really fair after all.

[franky1]

After reading most of the posts, I'm sticking to my views, it's Taboo if by increasing the blocksize to avoid network congestion the individual miners are getting eliminated from the Network, Increasing Blocksize can be a potential solution for Bitcoin but it is inefficient, because with this solution there will be another mess about the decentralized nature of the Bitcoin.

The proposal accepted is open if increasing the blocksize individual miner's power is not affected because we don't want our node to be controlled by only large entities. Network congestion can be a problem but having a solution risking the entire nature of the network is a big mess. Simply avoid moving coins in network congestion in such scenarios until we have a better solution to scaling rather than increasing the block size only.

try reading again

a miner does not even see full blockdata. a miner simply hashes a header (hashes a hash of a header to be more precise)
the header and hash which miners are involved in never change their length no matter how big a transaction or blocksize is

[stompix]

To have the same current fees on Bitcoin but with 100 MB you would need spammer to pay at least 29 000 BTC

You'll have to walk me through on this calculation.

Block reward + fees in last 24h 943.75+285.07 BTC, if we have 290BTC in fees in 1MB block then to keep the same fee level in 100MB we need 29 000BTC.

You must have misinterpreted me again. Spammers don't care what other people are paying in fees. They only care if their spamming can pass as much cheaply as possible. If block size is 100 MB, then, besides the expectation that it'll always be full, you should expect that it'll be mostly consisted of data junk like Ordinals.

Yeah, and they why should I care about that?
The thing is that they will not be able to force me anymore to pay 100sat/b for a tx without spending themselves 1 billion day!

Remember, the same logic as to why the network is secure because an attacker must buy 10 billion worth of gear to attack it?
Oh and btw, they would have to pay 10 million each day just to fill the block with 1sat/b, not to mention that this would triple if BTC goes to 100k.

If everyone doesn't give a damn about that, how come everyone stays on 4 MB block size network and doesn't move to BSV?

Do I have to bring again the graph with the spike in doge and ltc txs every single time fee in Bitcoin spike?
Ok, here we go:
https://bitinfocharts.com/comparison/transactions-btc-doge-ltc.html#6m

Again, you're asking yourself why people keep waiting for weeks for a reservation at a restaurant and not eating a hot dog on the street rather than thinking of opening a new restaurant to solve the problem and make everyone happy.

[cryptosize]

I vote in favour of smaller block sizes because:

Bitcoin was created to be accessible to everyone. Thus, running a miner and running a node must be cheap hardware-wise. Don't underestimate the power of nodes for the Bitcoin networks. It's not just the miners. Increasing the block size will require more disk space. More disk space require more money. 20% of the world hold approximately 80% of the global wealth, so requiring more money isn't really fair after all

https://en.wikipedia.org/wiki/Pareto_distribution

[Wind_FURY]

As for Dogecoin, lol. If you believe anyone takes this seriously, then I don't know what to say.

Then you should start saying that to everyone on this board who suggests using dogecoin instead of Bitcoin for small purchases, and there is a ton of them trust me, you'll be done by the time the mempool is empty. And if you don't believe it:

https://bitinfocharts.com/comparison/transactions-btc-doge.html#6m
This happens every single time Bitcoin fees spike, thousands move to doge!
Is LTC also laughable, or does it simply work?

If you ask me, it merely tells us that there are times that there's too much demand for block space. But the congestion we're currently experiencing is not the normal situation.

Common this is so 640k RAM will be enough for everyone is getting old!
People torrent TB of data every day on their home computers and we're scared of 1TB of storage over a year for a thing that is supposed to threaten a trillion fiat-based economy. Seriously? Latency, data transfer, FML, you have tens of thousands of ....models.....live streaming in 4k but somehow it's magically impossible to push 10MB in 10 fucking minutes to every single hole in this world.

But Bitcoin is going to replace banks while serving 600k customers a day!  

And furthermore, when some other coins manage to do the impossible, it's laughable! We're going to colonize Mars in 2240 and while beaming in one split second an entire cargo from planet to planet some will still say more than 4MB in 10 minutes it's technically impossible!

That's because that's what you believe. In my personal opinion, it's probably better to maintain its current course of development and value decentralization and security more than the accomodation of a higher number of transactions through bigger blocks. Because technically, Bitcoin at its essence might not be a mere "consumer-product", or a network to "replace banks".

Plus do you actually believe a single decentralized database could process all of the trillions of financial transactions per day? No? Then use Netflix's centralized/federated data centers with their very-low-latency, high-rate-of-data transfer. That would probably fix the problem. But that wouldn't be a protocol called Bitcoin.

[BlackHatCoiner]

Yeah, and they why should I care about that?

Peer-to-peer cash. Not trusting third parties. Do these remind you anything? I'm pretty sure you'll have to trust some data center after the 100 MB proposal is accepted, unless you're willing to pay ~500 GB of space each year. Oh, and by the way, you'll have to upgrade to some better CPU in a couple of years, unless you're really patient with the initial block download.

Do I have to bring again the graph with the spike in doge and ltc txs every single time fee in Bitcoin spike?

What happens, happens temporarily. I do so pay in VISA sometimes. The question remains unanswered: if big blocks are superior as you say, how come everybody does not move to BSV (e.g.)? You know, not just because Bitcoin network is currently congested and it'd be temporarily cheaper to transact there, but move there because it's more reasonable in general. If you don't consider my arguments regarding the block size limit valid, then please answer why that hasn't happened yet.

[franky1]

That's because that's what you believe. In my personal opinion, it's probably better to maintain its current course of development and value decentralization and security more than the accomodation of a higher number of transactions through bigger blocks.

that is not your personal opinion. its plageurised script from a group of idiots that lulled you into repeating their narrative
just reciting the mantra of the party line.. without doing any math, or independent thought/analysis of what he is about to write

Plus do you actually believe a single decentralized database could process all of the trillions of financial transactions per day? No? Then use Netflix's centralized/federated data centers with their very-low-latency, high-rate-of-data transfer. That would probably fix the problem. But that wouldn't be a protocol called Bitcoin.

you then double down by using nonsense exaggerations, exaggerations that are not even original or well thought out

there are 8 billion people on the entire planet. and not all of them use one currency..
but lets say they did.. for "trillions of transactions" requires each person to buy 12 items a days SEPARATELY for one trillion.. you used plural so multiply it by your magic plural amount you have in your head..

but becasue not everyone uses one currency naturally, lets take yours
250m mature people(toddlers dont shop for themselves) using the dollar. they do not even do 3 billion transactions per day

so stop with the exaggeration that one currency needs to do trillions.. let alone billions of transactions a day

you training of a discussion of reasonable adjustments at regular periods vs your stupid training of pretending the argument is about "gigabytes by next year" huge leaps, make you look foolish

get away from your training officer(forum-daddy) and think for yourself. he is not helping you
try to use actual data, real statistics, math and logic.. not some story some troll you call daddy tells you

[franky1]

Yeah, and they why should I care about that?

Peer-to-peer cash. Not trusting third parties. Do these remind you anything? I'm pretty sure you'll have to trust some data center after the 100 MB proposal is accepted, unless you're willing to pay ~500 GB of space each year.

no one is saying 100MB by 2024.. you and your forum family troll scenarios numbers the exaggerations, miscounted and just make you look dumb..
but heres the thing you dont know.. math
100mb blocks at your extreme is not 500GB/year... its actually 5.2TB a year
and hard drives these days you can get 16TB for less than your household TV

you dont need to buy a $xbillion server centre

now put the cost of a few years of running a bitcoin node.. true math
and then look at logical 1tx a day cost per transaction for the same few years..

then come back and tell the forum which costs more.. securing or spending.. (hint the fee's are the problem not the hardware)

[BlackHatCoiner]

100mb blocks at your extreme is not 500GB... its actually 5.2GB a year

100 MB x 144 x 365 = 5,256,000 MB ~= 5.2TB per year. The 500 GB per year correspond to previously mentioned 10 MB block size.

Edit: You've corrected yourself. But, as I have said many times, it's not just the storage requirement (you can find HDD externals pretty inexpensive, even though 5.2 TB per year is quite too much). It's the verification process which takes most of the time, not the downloading. It already takes too much time, I can't fathom how much it'll take if we are to verify 100 MB.

[NotATether]

We are now at 33% for, 33% undecided, and 33% against! 

Actually, who cares about this. That issue was solved a long time ago by splitting BCH and BTC.

FRANCY1, save me from the sensors who deleted my subject like common spam. Is the truth disturbing? Sorry to impose on myself like this before my probable disappearance...

What does this memory dump have to do with block size?

[franky1]

We are now at 33% for, 33% undecided, and 33% against! 

Actually, who cares about this. That issue was solved a long time ago by splitting BCH and BTC.

FRANCY1, save me from the sensors who deleted my subject like common spam. Is the truth disturbing? Sorry to impose on myself like this before my probable disappearance...

What does this memory dump have to do with block size?

nothing
he posted nonsense in a topic unrelated to what he was trying to announce(newbies cant create new topics)

its some troll that every year creates a new account just to announce he knows the identity of satoshi due to some book he read.. it seems he enjoys me debunking him, i think he tries to use lessons from my debunks to improve his trolling/tweak his script later.. but he never wins..

[oldkoin]

(even though 5.2 TB per year is quite too much).

What does a lot mean? That's ~$100 per year. When users pay $10 fees per transaction.

Why didn't you calculate this for 10 MB blocks? After all, we are talking about this increase now.

Or you did the math and realized that posting such calculations is somehow inconvenient.

And you decided to take 100MB at once. blocks. Only now an error occurred. These calculations don't scare anyone.

Why be modest? Others usually go straight to 1GB blocks. There the numbers will be more impressive.

We are now at 33% for, 33% undecided, and 33% against!  

Actually, who cares about this. That issue was solved a long time ago by splitting BCH and BTC.

Creating a fork with an increased block size did not solve the block size problem for Bitcoin. Absolutely not.

This problem was and remains the same. And this problem will have to be solved. There is no scenario in which Bitcoin with its current block size will be able to reach 1 billion users. What a billion. Bitcoin in its current form cannot handle even 100 million users.

[alani123]

lol at these numbers, the beast is calling 



I hear a lot about how big blocks will reduce decentralization and make things harder for I dividual miners.

Can somebody show me some data or a paper to support this?

I am genuinely curious, bitcoin's block size from 1 MB going to 4 MB didn't cause any such issues. Propagation time on Bitcoin is already pretty good. We are not talking about decreasing block times here.

Mining is already pretty centralized, almost no blocks are mined by miners outside of pools... The difficulty is so high it's hard to mine on your own. But even with bigger blocks, how would that prevent someone from mining like he does now? If someone is going to invest hundreds of thousands $ in mining equipment, are we to assume that they can't invest at an internet connection that is at least at ADSL or 3g speeds?

[philipma1957]

it is not a solution.

1mb 4bm 8mb 16mb 32mb 64mb all fail to solve why this occurs.

scrypt has 2 viable coins for merge mining and they make 12x the blocks per hour or day or week or month or year.

scrypt is the better design for small value frequent moves.

Oh but btc added LN
and Scrypt added LN for ltc and could do so for Doge.

oh a big block fixes things and scrypt can make a big block.

A  large freighter can carry more than 1 million barrels of oil

you do not use it to carry  a few cans of oil

Sha-256/BTC will not ever really win over scrypt/LTC/DOGE  if you are doing many 100 usd or less transactions.

If BTC users understood this they would

A) hodl large  BTC in self custody 10k or higher
B) small amounts of btc ltc and doge in an exchange like coinbase maybe 1k total
C) never pay small amount of BTC to anyone use LTC or Doge

all issues solved.

this fixes fees.

end of story.


If someone can show me a way for the 12x blocks an hour edge that scrypt has I would reconsider but frankly I do not see a way for btc to win by using a freight to move 5 dollars worth of oil

[el kaka22]

This is such a weird position to be in, the results are very close to each other. All sides have super reasonable explanation for why they are feeling that way, bigger blocks people like me want cheaper and faster transactions but the ones who are against it also wants to make sure security doesn't get lower because of it, which makes sense.

I understand not wanting something like this, because in the end we are talking about something that may hurt the blockchain all together. Remember all those alts with blockchain issues and hacks? We wouldn't want that in bitcoin. I am sure in an ideal situation everyone would want it, why would we be against it, why would anyone be? But people are fearing what could go wrong about it.

[franky1]

I hear a lot about how big blocks will reduce decentralization and make things harder for I dividual miners.

Mining is already pretty centralized, almost no blocks are mined by miners outside of pools... The difficulty is so high it's hard to mine on your own. But even with bigger blocks, how would that prevent someone from mining like he does now? If someone is going to invest hundreds of thousands $ in mining equipment, are we to assume that they can't invest at an internet connection that is at least at ADSL or 3g speeds?

mining has nothing to do with blocksize and blocksize has nothing to do with mining
mining hashes a blockheader.. blockheaders and hashes remain the same size no matter the blockdata part containing transactions becomes

people can still mine from home. they can buy their own full size asics or USB miners. the hashrate is linked to difficulty but difficulty is not related to blocksize. the reward amount of sats is related hashrate and to market price not blocksize directly

here is the thing if bitcoin transaction users have to pay more per fee.. less people want to use bitcoin, less want to buy bitcoin. less people want to transact with bitcoin.. this is a bad economic game like only having one table in a restaurant thinking the restaurant can stay profitable serving one customer a day by charging that one customer huge price for a meal..

however more transactions per block does not harm miners or break miners but does allow more transactions and more users and more opportunity to get profit from more people without charging people outrageous prices.. thus more sustainable economic model

Can somebody show me some data or a paper to support this?

I am genuinely curious, bitcoin's block size from 1 MB going to 4 MB didn't cause any such issues. Propagation time on Bitcoin is already pretty good. We are not talking about decreasing block times here.

the 6 trolls against blocksize increases are not thinking with their head about pros-cons for bitcoin. they instead are thinking using their training on how to promote that people should use other networks.
the fun part is their other network promotions/training admits that nodes can handle relay/verification of millions of transactions a second.. so there is no node problem for dozens of thousands per second reasonable request

[digaran]

Anyone who is against increasing the block size is either a shill for miners or has another agenda which benefits them as it benefits mining pools. I excluded ignorant opposition.

Every online application has plans to scale when userbase increases, can you imagine what would have happened if bitcointalk never upgraded it's servers?  Or what would have happened to instagram if they had the same server capacity for more than 4 years?  I can imagine what would have happened, they'd be dead by now, why Bitcoin isn't dead yet? Because it still has support from the community, if I were a mining pool, I'd think about that before including spam into my block, loyalty has it's limit.

[cryptosize]

Every online application has plans to scale when userbase increases, can you imagine what would have happened if bitcointalk never upgraded it's servers?  Or what would have happened to instagram if they had the same server capacity for more than 4 years?  I can imagine what would have happened, they'd be dead by now, why Bitcoin isn't dead yet? Because it still has support from the community, if I were a mining pool, I'd think about that before including spam into my block, loyalty has it's limit.

Care to explain why the internet still uses 32-bit addresses (IPv4) despite the fact we have around 15 billion devices connected online?

Why don't we ditch IPv4 in favor of IPv6 (128-bit)?

Why did we invent NAT/RFC 1918 (a solution that doesn't compromise backwards compatibility, SegWit-style)?

I'm still waiting for someone to answer these questions.

I thought this forum was IT-dominated. Nobody here is an expert in computer networks/internetworking?

[digaran]

You are asking the wrong people here, IP format is related to telecommunication companies controlled by governments, also I see no backward compatibility issues if we were to have for example 6 or 8MB blocks, even if we had 8MB blocks, the spammers would keep spamming, that's why other than blocksize, we need to consider increasing the fees for non-monetary transactions somehow.

[vjudeu]

What are your thoughts on increasing bitcoin's block capacity?

I'm against it

Think about the size of the block header. It takes only 80 bytes. Only that is really mined, the whole size of the block is just committed to it. Does it mean that we only have 80-byte blocks in practice? Of course not, because 32 bytes is all you need to form a valid commitment. Which means, you can have gigabyte-sized blocks, or even terabyte-sized blocks, if you just use commitments to make them. Just tweak your R-value in your signature, and then your terabyte-sized block will be connected with your signature. And it would cost you no additional on-chain bytes.

Which means, every time you move any coins with some standard transaction, and every time you use a single ECDSA signature, you can use random R-value, and not commit to any data, or tweak your random R-value by some non-random value, and commit to any data you want, without increasing the size of your transaction.

Technical details were also explained on mailing list here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022176.html

To be able to verify sign-to-contract, you reveal R0 and data, and the verification is just checking that R=R0+SHA256(R0, data)*G. That works with both ecdsa and schnorr signatures, so doesn't require any advance preparation.

[cryptosize]

You are asking the wrong people here

Really?

I thought at least some Bitcoiners were IT-savvy. Guess I was wrong. My bad!

IP format is related to telecommunication companies controlled by governments

That's not true.

RFC documents have nothing to do with ISPs/governments. Internet is decentralized, there is no central entity controlling the infrastructure (just like Bitcoin).

also I see no backward compatibility issues if we were to have for example 6 or 8MB blocks, even if we had 8MB blocks, the spammers would keep spamming

Sure, if you can invent something like SegWit... a soft fork.

that's why other than blocksize, we need to consider increasing the fees for non-monetary transactions somehow.

Possibly.

I was never a fan of storing arbitrary data in the blockchain, but that's how BTC was designed from the get-go.

Hell, some people want 4GB blocks to store video feeds from surveillance cameras.

I can understand why Satoshi wanted to store text messages (like the bank bailout one), but storing entire HD videos in the blockchain? That's absurd!

[vjudeu]

For example if it is a hard fork to increase block size in the future when the need arises, then my answer is a big fat YES. We definitely need to increase the on-chain capacity at some point but the important part is the "at some point" part.

Only time will tell, but I guess it will be much easier to convince people to include 1 GB commitment, as an addition to 4 MB witness, than to create a hard-fork, and include this 1 GB directly. It will simply not happen. If there would be some chances to get it, then Segwit would also be a hard-fork.

Which means, people could increase witness by adding "a second witness" called "commitments" or whatever. But I don't think it will be a regular hard-fork, because the longer that change needs to wait, the more ossified and "set in stone" everything is. And in the future, it will be even harder to convince BTC users to do any hard-fork, unless strictly needed (for example in 2038, because this bug can shutdown old nodes). If you create some unnecessary hard-fork on BTC, then users will call it an altcoin, and create a competing soft-fork or no-fork, and then your hard-fork will be "outside Bitcoin", just because of backward compatibility. The only chance to get a successful hard-fork, is when the old software crashes, and if there is no way to fix them without upgrading.

When it is used as "cloud storage" it is considered abuse and the transactions are spam. Meaning right now that the congestion is caused by abusing the protocol to perform an attack on bitcoin, this is not natural and the exploit should be fixed instead of increasing the capacity to let bigger spam in.

True. Even if someone supports big blocks, then other changes are more important. And if they won't be deployed first, then the final result will contain just Ordinals flood, UTXO flood, and a lot of other, not-yet-invented forms of spamming the chain.

P.S. I don't think increasing block capacity has ever been a "taboo" as some like to exaggerate it. HOW it is increased has been the source of a lot of disagreement.

Also true. We have soft-forks, because they are backward compatible. We could have a hard-fork, but then, there is a huge risk, that some people will call it "an altcoin", and release a competing soft-fork or no-fork. Which means, if you have all development power in your hands, and you release some hard-fork, then you risk losing it. Also, Ordinals can show you that too: Core developers didn't include Ordinals to their Bitcoin Core client, but they are still present on-chain. Which means, now people know, how to add new things, without asking Core. Which means, more people will start deploying their half-baked inventions, without asking for permission, or voting for a new soft-fork, so be ready for a huge spam of no-fork projects.

If the sole purpose of bitcoin was just to transfer money what's the role of OP_pushdata ? And especially OP_pushdata4 ?

The role of OP_PUSHDATA is to push data (duh!). And why we have OP_PUSHDATA4? Well, because Satoshi released 32-bit version, and four bytes can be used to express some 32-bit number. Guess what: if the first version would be 64-bit, we could have OP_PUSHDATA8 as well.

But, I can ask you another question: if Satoshi wanted to fully use OP_PUSHDATA4, then why he limited MAX_SIZE of the P2P message into 32 MiB (0x02000000), and later limited block size into 1 MB (1000000)? Why November 2008 version was limited to only 32 MiB P2P message size? Yes, that November 2008 version, which contained quite huge Script support, what you can discover by exploring the Script of the coinbase transaction, used in that version (also note that it contained 100.00 BTC, expressed with 2-digit precision only as "10k satoshis", instead of 8-digit precision we have today, and that OP_CODESEPARATOR was mandatory at that time).

Seems that the creator had a different view than yours .

The whole Script is not necessary for Bitcoin to function. In the whitepaper, you have only P2PK, and nothing else. And it is still called Bitcoin, and people still check many coins if they implement everything from whitepaper, if they want to call something "the true Bitcoin" or not. Which means, your OP_PUSHDATA4 is not even mentioned there. We could start from P2PK-only system as well, and add commitments later, or even attach Schnorr signatures or TapScript later, directly into those public keys. Then, in such system, spending-by-pubkey would be always mandatory, but some keys (for example the private key equal to one) could require a commitment to some Script.

And how do you measure that? Even if we were to follow that route, and have a block size limit that corresponds to the "legitimate usage", how do we begin?

For that reason, I think we should not try to measure that, but instead implement some way to compress pubkey-based transactions, while leaving non-standard use cases uncompressed. In this way, users could make cheap transactions, which could be combined into more expensive ones, while Ordinals users, and other spammers, would still need to pay the full price. In general, I think the price you pay for your transaction, should be relative to the level of compression you can achieve. Public keys can be compressed by Schnorr signatures. Arbitrary data pushes will usually stay uncompressed. The Hutter Prize record at the moment of writing allowed compressing 1 GB of Wikipedia into around 114 MB. But pubkey-based transactions could be compressed much further than that, you will hit a wall during compression, only if you push regular data, you won't have such problems with signatures, that could be just combined, because you can cover 1000-of-1000 multisig with a single signature.

Edit: Also, Satoshi explicitly said something about uploading videos:

I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it.  I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.

That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...

That's one of the reasons for transaction fees.  There are other things we can do if necessary.

See? The answer was not "just use OP_PUSHDATA4, and upload it". The answer was "fees are needed to discourage that". And even more: "if fees will not be sufficient, then we can do something else to limit it further". That's what he said, as you can see above, and click on the link to the quote to confirm it.

Seems that the creator had a different view than yours .

[franky1]

Edit: Also, Satoshi explicitly said something about uploading videos:

I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it.  I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.

That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...

That's one of the reasons for transaction fees.  There are other things we can do if necessary.

See? The answer was not "just use OP_PUSHDATA4, and upload it". The answer was "fees are needed to discourage that". And even more: "if fees will not be sufficient, then we can do something else to limit it further". That's what he said, as you can see above, and click on the link to the quote to confirm it.

emphasising.. some trolls that dont want junk to stop. think the only way is fee's
they also pretend the only way via fee's is everyone pays more equally..

there are many other ways to limit it. such as adding rules to opcodes to limit length(remove assumes and add conditions). and also penalise just certain opcodes for using certain opcodes. multiply base fee by 2000x much like the dev policis decision to multiply legacy by 4

[Wind_FURY]

That's because that's what you believe. In my personal opinion, it's probably better to maintain its current course of development and value decentralization and security more than the accomodation of a higher number of transactions through bigger blocks.

that is not your personal opinion. its plageurised script from a group of idiots that lulled you into repeating their narrative

just reciting the mantra of the party line.. without doing any math, or independent thought/analysis of what he is about to write

You're right, it's not my opinion, BUT in my personal opinion, I agree with the fact that the Core Developers have made the design decisions that value maintaining decentralization and security for the network MORE than increasing the transaction througput per block.

I know you're gaslighting everyone into believing I am wrong, and therefore you are right. BUT OK, they either DYOR and learn the truth, OR they listen to you and learn the truth the HARD WAY like I did.

Plus do you actually believe a single decentralized database could process all of the trillions of financial transactions per day? No? Then use Netflix's centralized/federated data centers with their very-low-latency, high-rate-of-data transfer. That would probably fix the problem. But that wouldn't be a protocol called Bitcoin.

you then double down by using nonsense exaggerations, exaggerations that are not even original or well thought out

there are 8 billion people on the entire planet. and not all of them use one currency..
but lets say they did.. for "trillions of transactions" requires each person to buy 12 items a days SEPARATELY for one trillion.. you used plural so multiply it by your magic plural amount you have in your head..

but becasue not everyone uses one currency naturally, lets take yours
250m mature people(toddlers dont shop for themselves) using the dollar. they do not even do 3 billion transactions per day

so stop with the exaggeration that one currency needs to do trillions.. let alone billions of transactions a day

you training of a discussion of reasonable adjustments at regular periods vs your stupid training of pretending the argument is about "gigabytes by next year" huge leaps, make you look foolish

get away from your training officer(forum-daddy) and think for yourself. he is not helping you
try to use actual data, real statistics, math and logic.. not some story some troll you call daddy tells you

Is that you trying to convince me again that "bigger blocks are better"? Pardon mer ser, but I have already learned the hard way that you're wrong.

Roger Ver and Jihan Wu had a thesis that if they hard fork to bigger blocks and call their shitcoin "Bitcoin", then the community would follow because "big blocks are what the community needs". How is Bitcoin Cash today, frankandbeans?

[franky1]

windfury
none of your replies are about REAL data, code, opcodes, limits.
none of your replies are about REAL maths related to the data/limits
none of your replies are even about technology limitations IN REALITY

try for once to make an ontopic reply that show some thinking about the subject, outside of idolising certain people and insulting others.

when even your idol god devs say nodes can handle the creating, signing, relaying co-signing and relaying again and then verifying "a million payments a second" pre confirm.. it shows nodes have no issues with just a few thousand transactions. especially if mempools of nods can verify and maintain 300mb-500mb pre confirm  transactions without blowing up

when 4mb blocks are 6kb/s internet speed
when 10mb blocks(your groups suggestion) are 15kb/s internet speed
when 100mb blocks(your groups exaggeration) are 150kb/s internet speed

so please tell me the real defined reason your against it... apart from dev god cult following and wanting to appease your mentor

[pooya87]

Since I have to dot all the eyes and cross all the tees: Legitimate use is anything that is not a spam attack, meaning where people use bitcoin to transfer money or in other words when Bitcoin is the "peer to peer digital cash system" that it was intended to.

If the sole purpose of bitcoin was just to transfer money what's the role of OP_pushdata ? And especially OP_pushdata4 ?
Seems that the creator had a different view than yours .

Satoshi was not a god, he has made a lot of weird decisions when implementing Bitcoin. Unless he has explicitly expressed his intentions for a decision you can not make such conclusions like the one you just made here.

In this case if I had to guess I'd say there may be two reasons for this decision:
1- Scalability of the code.
As a developer, specially when you are creating a consensus critical code for a decentralized system, it is easier to have an functionality and never use it than not having it and wanting to add it in the future. Introduction of other functionality like interpretation of SegWit outputs, adding OP_SUCCESSx, etc. are doing exactly that.

2. Translating DER lengths.
I think this is the most possible reason. Since Satoshi was aware of DER encoding (used for signatures) and DER lengths have a similar approach to encoding data lengths and also support very large values, Satoshi might have adopted the same approach and implemented as big a size as he could.
BTW same approach is used to encode VarInt (used for script lengths) which is another way of encoding lengths some of which can never be used in Bitcoin but they can encode extremely large values nonetheless.

Otherwise I doubt that Satoshi ever intended to let anyone push 4+ GB data to the stack that only supports pushing data that is no bigger than 520 bytes.

The reason is pretty simple: the adoption hasn't grown enough for the current block capacity to not-be enough for the legitimate usage.

And how do you measure that? Even if we were to follow that route, and have a block size limit that corresponds to the "legitimate usage", how do we begin? In my opinion, the adoption has grown a lot since the last time the Bitcoin community had had this debate.

It has definitely grown but considering how fee spikes have never been severe or long lasting without spam attacks we can say with a high degree of certainty that the adoption has not yet surpassed the capacity.

[Hamza2424]

try reading again

a miner does not even see full blockdata. a miner simply hashes a header (hashes a hash of a header to be more precise)
the header and hash which miners are involved in never change their length no matter how big a transaction or blocksize is

I think I've gone wrong somewhere while expressing it what I meant by this was it will directly increase the storage required by the minner to download the entire blockchain, and it will require a higher network bandwidth. So if the minner is not reading the entire block data still it's keeping a copy of the full data if the computation resources are not increasing but the network & storage resources are.

I was generally expressing my view on it and somehow mixed the nodes & minner at the same time. Anyway, there are some concerns for both miners and Nodes as well.

[stompix]

100mb blocks at your extreme is not 500GB... its actually 5.2GB a year

100 MB x 144 x 365 = 5,256,000 MB ~= 5.2TB per year. The 500 GB per year correspond to previously mentioned 10 MB block size.

Edit: You've corrected yourself. But, as I have said many times, it's not just the storage requirement (you can find HDD externals pretty inexpensive, even though 5.2 TB per year is quite too much).

First, please don't do this, nobody said 100MB, let's not make a mockery out of it!
You are the only one that advanced this number, but just for this one time, no matter, let's play with it.

The last 24 hours' fees were 247.97 BTC
Fees for normal transactions, not ordinals represented 75% of the total, so at current price is $6.7 mill.
A Samsung EVO, so no your cheapest shit is $334.90 for 8TB on Amazon right now,  so $41 per TB.

Now, let's assume 20 000 nodes, split the $6.7mils, and you get, wow....$335, it's like god has spoken!  
So bottom line, users have paid in the last 24 hours on no ordinals transactions enough money so that 20,000 nodes would get an 8TB drive! In one F word day!

It's the verification process which takes most of the time, not the downloading. It already takes too much time, I can't fathom how much it'll take if we are to verify 100 MB.

Normally one would come with numbers on this...
So let's see what your average computer in 2009, like the core2duo could do and what your nowadays average desktop can,
So a CoreDuo E6600 vs Core i5-10600, intentionally middle processor 3 years old at the date of launch of now, ignoring the duo was $320 on launch and the i5 $210 so 50% cheaper, 18.2 gflops vs 482.3 gflops...lol!


Now let's move a bit further and do some really laughable math...

Let's assume we want everyone to hold some coins, just hold them nothing else.!!!!
We assume the blocks will be used just to distribute coins, so that would cram 25 000 outputs in a block (we need some spare space as not all inputs are already funded with that much), so that's 1,3 billion, so 6 years!!! LMAOOOOO...even if we would optimize transactions to the max, even if everyone would stop doing anything else and move a single coin on the blockchain, it will take 6 FUCKING YEARS for everyone to get coins in his wallet (you know the whole thing, not your keys, not your coins). Now assuming everyone would also want to open a LN channel, well..it's going to be 2040!
2040 till it will even be mathematically possible (impossible in real life) to get everyone on LN!

But we don't need everyone, I mean just 25% of the world, right...so 2027  
Seriously? Seriously? All because of a $300 drive? Common!

I'm pretty sure you'll have to trust some data center after the 100 MB proposal is accepted, unless you're willing to pay ~500 GB of space each year. Oh, and by the way, you'll have to upgrade to some better CPU in a couple of years, unless you're really patient with the initial block download.

You're talking to somebody who has 10KW of mining power actually securing the network as we speak in his basement.
So...you know... wrong path here

[Wind_FURY]

windfury
none of your replies are about REAL data, code, opcodes, limits.
none of your replies are about REAL maths related to the data/limits
none of your replies are even about technology limitations IN REALITY

try for once to make an ontopic reply that show some thinking about the subject, outside of idolising certain people and insulting others.

Probably not, that's because I'm a mere pleb. I'm not a coder, I'm not a very technical person although I try, BUT I understand enough to know who is LYING/spreading MISINFORMATION, and who are the trustworthy people in the community. It's NOT YOU frankandbeans, and it's there in your trust-ratings for everyone to see!

Plus who should the community listen to, to learn more about Bitcoin? Gregory Maxwell and Andrew Chow? Or a charlatan?

¯\_(ツ)_/¯

[cryptosize]

Every attempt to increase the block size limit via hard forks (BCH, BSV etc.) has produced blockchains with less security (aka shitcoins):

https://cointelegraph.com/news/bitcoin-sv-rocked-by-three-51-attacks-in-as-many-months
https://www.coindesk.com/tech/2019/05/24/bitcoin-cash-miners-undo-attackers-transactions-with-51-attack/

BCH and BSV aren't good example though. BSV doomed from start since it's associated with infamous faketoshi. BCH gain bad popularity due to community/developer action in past, especially claiming BCH as true Bitcoin while falsely say "BTC (Bitcoin Core)".

Sorry, that's not my problem.

You'll find people on this thread ferociously defending narcissists such as CSW and attacking/ignoring everyone who doesn't buy his BS (4GB Kool-Aid).

Satoshi never seeked fame, he didn't even spend his own coins...

[BlackHatCoiner]

Why didn't you calculate this for 10 MB blocks? After all, we are talking about this increase now.

For increase to 10 MB, I'll right as well vote in favor, and maybe a little higher than that. I have clarified before that I'm not strictly against anything beyond 4 MB, I'm just not of the opinion that it's going to solve the problem; it's only delaying it.

Can somebody show me some data or a paper to support this?

It's simple. When a miner mines a block, they are the first to have verified that block; it happens during mining to check for the validity of the transactions. When they broadcast their block, the rest of the miners must firstly verify it before mining on top. The bigger the block size, the more time it takes to verify the block, and hence, the more the time the lucky miner gains to continuing mining alone.

And it's not just verification, it's propagation as well. If you we had 1 GB of blocks, as in BSV, you could perhaps imagine this better. During the time that gigabyte is traveling across the network and is in the process of verification, the lucky miner gains invaluable time advantage.

First, please don't do this, nobody said 100MB, let's not make a mockery out of it!

What's the ideal block size according to you?

So bottom line, users have paid in the last 24 hours on no ordinals transactions enough money so that 20,000 nodes would get an 8TB drive! In one F word day!

Seriously? Seriously? All because of a $300 drive? Common!

You persist in presenting this as the ultimate argument, despite my repeated assertions that the storage requirement is not our foremost concern.

So a CoreDuo E6600 vs Core i5-10600, intentionally middle processor 3 years old at the date of launch of now, ignoring the duo was $320 on launch and the i5 $210 so 50% cheaper, 18.2 gflops vs 482.3 gflops...lol!

I mean, yeah, if you dedicate a modern PC to running a full node, it will take a couple of days to reach the tip, but as per my experience goes, people don't use resource-intensive machines solely for that purpose. If you use a Raspberry Pi 4, it'll take a week to finish the first 500 GB.

[alani123]

Why didn't you calculate this for 10 MB blocks? After all, we are talking about this increase now.

For increase to 10 MB, I'll right as well vote in favor, and maybe a little higher than that. I have clarified before that I'm not strictly against anything beyond 4 MB, I'm just not of the opinion that it's going to solve the problem; it's only delaying it.

Can somebody show me some data or a paper to support this?

It's simple. When a miner mines a block, they are the first to have verified that block; it happens during mining to check for the validity of the transactions. When they broadcast their block, the rest of the miners must firstly verify it before mining on top. The bigger the block size, the more time it takes to verify the block, and hence, the more the time the lucky miner gains to continuing mining alone.

And it's not just verification, it's propagation as well. If you we had 1 GB of blocks, as in BSV, you could perhaps imagine this better. During the time that gigabyte is traveling across the network and is in the process of verification, the lucky miner gains invaluable time advantage.

Nobody said we should straight up go to 1GB blocks. Indeed this would introduce issues like affecting the fee market very negatively and also inviting a lot of spam to be on chain, let alone that nodes would be hard to host.

And yes, with 1 GB blocks propagation would be hard. My upload speed with an ADSL connection that's still very common in my country, would have me taking longer than 10 minutes to download a block.
But honestly for bitcoin nobody talks about blocks that large. Even back in the day of the "blocksize wars" the proposed solutions were much more conservative.

These were the main proposals back then, circa 2015:

source: https://en.bitcoin.it/wiki/Block_size_limit_controversy

Given that so many years have passed, today there would be even less issues in terms of networking infrastructure or hardware to support these changes.

[franky1]

Why didn't you calculate this for 10 MB blocks? After all, we are talking about this increase now.

For increase to 10 MB, I'll right as well vote in favor, and maybe a little higher than that. I have clarified before that I'm not strictly against anything beyond 4 MB, I'm just not of the opinion that it's going to solve the problem; it's only delaying it.

math:    doing nothing= delaying * (avoiding problem * causing more problems)

Can somebody show me some data or a paper to support this?

It's simple. When a miner mines a block, they are the first to have verified that block; it happens during mining to check for the validity of the transactions. When they broadcast their block, the rest of the miners must firstly verify it before mining on top. The bigger the block size, the more time it takes to verify the block, and hence, the more the time the lucky miner gains to continuing mining alone.

a. miners(asics) dont verify transactions/blocks... you mean POOLS
b. POOLS verify transactions pre-confirm. and you as a LN nutcase know nodes can validate "millions of payments a second"
c. POOLS verify a hash matches header.. header has transaction merkle root. root matches leafs.. and leafs are known/checked TXID
at point C competing pools and nodes are not again validating all transactions..
d. at most if a merkle leaf does not correspond to a TXID in a nodes mempool of unconfirms, they ask their peer for that TX.
e. the amount of tx they need to call and validate due to not already having in mempool is a small % of a block

the whole "verification time" is not as big of an assault on nodes as you think it is

And it's not just verification, it's propagation as well. If you we had 1 GB of blocks, as in BSV, you could perhaps imagine this better. During the time that gigabyte is traveling across the network and is in the process of verification, the lucky miner gains invaluable time advantage.

mempools are already validating 300mb-500mb of transactions all the time right now.. stop pretending that nodes cant handle 100mb-500mb+ when all evidence shows the opposite

funny part is you are part of the crew that doesnt want to stop !ONE! transaction being 4mb yet you then say nodes cant handle a few dozen mb of transactions.. even when mempool and subnetwork "state" validtion prove nodes can handle ALOT more then your imaginary barriers

You persist in presenting this as the ultimate argument, despite my repeated assertions that the storage requirement is not our foremost concern.

but your crew is happy that fee's are(time of posting)
341.23 sat/vB ≤ 20 min. (LEAN 226sat tx = 77,066sat = $28.23)

but you want to say a 2012 $150 hard drive for the historic and next 5 years (17 years = $10 a year) is a problem

if paying $10 a year is a concern.. then the tx fee means you want people to only use bitcoin once every 3 years??

sorry but the reality is its the tx fee thats the concern. not the hardware cost..
tx fee is making people not want to transact/run nodes daily..

[stompix]

First, please don't do this, nobody said 100MB, let's not make a mockery out of it!

What's the ideal block size according to you?

You asked me a few times:

Dynamical or why not implement the opposite of halving for the block size, we have a halving in the reward a doubling in the block size. If we look at disk price and internet speed we're already 12 years behind compared to 2009, so we would have at least 2 decades to see if it works or no!

So right now it would be either 4 or 8MB (not vMB)
And before you say something:

Seems like verifying and broadcasting 8 blocks in 20 minutes is not problematic at all, a fact, proven numerous times!
Do you want me to go a bit further in time and give you even more extreme examples? cause you know there are!

You persist in presenting this as the ultimate argument, despite my repeated assertions that the storage requirement is not our foremost concern.

You keep bringing it up!

I mean, yeah, if you dedicate a modern PC to running a full node,

I compared a now 100$ ebay cpu with the 3 year old computer at the time of the first block, same thing, hardly modern or unaffordable.
On what were people running their nodes in 2012? cause...>>>next quote

If you use a Raspberry Pi 4,

There was no Raspberry at the time Bitcoin was launched, the first one came in 2012 and was hardly node material itself!
Why not cut the blocks then to 10kb so every nokia 3330 could host a node? That would do a ton for decentralization since there are millions of them and they cost 10-20$, way cheaper than a raspberry pi!

Now that I've done a lot of explaining, let me ask you something, do you have a solution for the math of everyone getting no more than two transactions till 2040? Or do you think that's not a problem for mass adoption or that mass adoption shouldn't even happen because, fuck the rest of the world, it's just about us who already have filled our stashes?

[apogio]

You asked me a few times:

Dynamical or why not implement the opposite of halving for the block size, we have a halving in the reward a doubling in the block size. If we look at disk price and internet speed we're already 12 years behind compared to 2009, so we would have at least 2 decades to see if it works or no!

Like in Monero. I agree on that, it could be a good option, but we still need a hard cap. I also believe that Bitcoin will mostly be full no matter the variable block size.

[cryptosize]

Like in Monero. I agree on that, it could be a good option, but we still need a hard cap. I also believe that Bitcoin will mostly be full no matter the variable block size.

Satoshi should have done that back in 2010, now I think it's a bit too late for a hard fork.

There were even some serious bugs back then that would be detrimental in 2023.

BTC is ossified and there's a lot of money at stake.

Yeah, I know some people hate the hodl/investing aspect, but BTC has become too valuable, for better or worse. Nobody is gonna risk it right before BlackRock's BTC ETF.

These changes are easier when the network is smaller and each BTC costs a few cents at most...

Now you risk splitting the network in half. You need to provide some sort of guarantee that we won't have another altcoin fiasco (BCH/BSV). Who can do that? BTC Core devs? They don't control the network (miners).

It's roughly the same with IPv4: nobody could have envisioned back in the early 80s that we will have more than 4 billion devices connected online, otherwise we would have gone with 128 bits from the get-go or 64 bits at least.

[BlackHatCoiner]

Let me do a summary:

- Nearly a third of the users votes against, while another third votes in favor (at least in this topic).
- Of those voting in favor, there is complete lack of consensus regarding which block size policy fits better.
- From the history, we have observed similar quarrel on that particular topic, and every single attempt of raising the block size limit has resulted in a crypto-failure. And all these attempts made in a time where Bitcoin was valuated at a small fraction of what it is now.

Hasn't anyone noticed why bigger blocks haven't been adopted yet? To me, it is crystal clear that the risk of splitting the network and breaking backwards compatibility is not worth it. People are willing to pay extra for retaining this invaluable property.

Seriously, my question remains unanswered: why haven't you moved to BSV? Or more reasonably, to BCH? Nobody answers this. These particular coins aren't alts in the traditional sense, they were Bitcoin until someone realized they are capable of enforcing their own policy, forming a network in respect to their perspective. How different is your proposal comparably to Roger Ver's?

[franky1]

Let me do a summary:

- Nearly a third of the users votes against, while another third votes in favor (at least in this topic).
- Of those voting in favor, there is complete lack of consensus regarding which block size policy fits better.
- From the history, we have observed similar quarrel on that particular topic, and every single attempt of raising the block size limit has resulted in a crypto-failure. And all these attempts made in a time where Bitcoin was valuated at a small fraction of what it is now.

not a accurate vote of community
the "against" are obvious alligned to ass kissery without actually using real data, statistics and reasoning. instead full of narratives that have been debunked but stil repeated.

the 'neither' are just too scared to form an opinion or use real data, logic to decide

the "for" actually use better rationale. but we are still fighting the whole core is god crowd so any discussion will just remain discussion, the best we can hope for is to educate the exaggerators and scripters to realise how their objections are foolish, maybe then as friends to core devs can be the soldiers that plot to get core to act from the inside
here is the thing..
the amount of topics promoting subnetworks as solutions is a smaller community of promoters(mostly trolls repeating the same publicity promises and utopia narratives).. but the ample examples of topics about scaling bitcoin shows that more people from a wider variety of mindsets want bitcoin scaling. not sold some 6yo unmet promise

[panganib999]

I remained impartial about this blocksize war, despite it being one of the most pivotal events in the history of cryptocurrencies, and I will remain impartial about it even until now. On one hand, bitcoin remaining to be in this 1 mb size limit ensures that decentralization is taken care of and that no one has to pay so much fees in the future. But at the same time, the benefits of a larger and more advanced network is something not to scoff at either. I say, if we ever feel the need to have a better and more reliable form of bitcoin for transactions and all that stuff, a fork is the only solution that would satisfy everyone's needs and it's something that I personally would be willing to follow through if need be. No more overhauling of the system, cause we don't need to fix what's not broken in the first place.

[HmmMAA]

Just voted against blocksize increase , btc community made it's choice in the past to have a fee market on L1 and scale on L2 rather than scale on L1 . I think that this should never change and each user fight by all means anyone that brings any suggestion against that . UASF can be used at any time , every non miner should send those evil miners a message that in btc there's no PoW consensus but proof of most nodes . Their decision to accept more profitable transactions is insane and they should be pay the price . I think that other SHA256 will welcome them (miners/pools) with open arms , but their hashpower is insignificant compared to the number of rapspi's according to the spirit of btc community .

What most defenders of the position that blocksize should not increase is that there is no transaction volume yet to do so . There are thousands of projects other than btc that have tremendous amounts of transactions . These people transact there because it's easier than transacting in LN . Btc maxis don't want bitcoin to work the way it was supposed to . If they open their eyes they will see that millions of people actually use crypto because the most famous doesn't work . If bitcoin scaled back then no other projects would have a reason for existence .

What you have achieved is to provide free profit to pools . Pools love that they don't have to spend a single penny for their infrastructure . Entities that earn tens of millions don't pay a single cent and users pay insane fees . This is the best way to maximise their profits , no one else wins . Of course , there are some users that love validating their transactions ( i wonder how many transactions these users do on L1 ) and they keep the network hostage to their nerdy needs . And these users are the new legendary legion that every newbie admires when entering this space .

No time to write more , i will respond to vjudeu at a later time .

Closing my message i would like to make it an open call to UASF . No more time should be spend .

PS. I don't use btc network for years , but i think i should remind the community what decision took some years back . Prove that you were right all the time and stick to your position .

[franky1]

"backward compatibility" means there is no way for a USER assisted fork.. users have become crippled
the 2017 was never a UASF

the process would actually be to use what actually happened in 2017 but mirror-reversed
ECONOMIC NODE operators to instigate/lobby NYA mandated threat to set their services to reject/not see mining pool rewards(blocks) that did not concede to show alignment to the NEW core roadmap that will fix their exploit..

where core would need to code the ruleset..  because any other brand would get REKT

i do laugh how HmmMAA formed an opinion based on the same debunked crapscripts that the other objectors have been falsely spouting
yet fo 6 years the blockdata of flag events, code and evidence of the economic node strategy has been available in just a few minutes of research
just requires looking at the data, not the social aligned blogs

[pooya87]

There were even some serious bugs back then that would be detrimental in 2023.

Any kind of bug in a major implementation like core is harmful but not the way you'd think. In 2010 there was only one implementation running and that had a bug so the whole network went on an invalid chain. Today there are more than one implementation of Bitcoin running and if one had a bug, it would be on the wrong chain and the correct chain can still grow with valid blocks with other clients.
This also highlights necessity of having multiple implementations.

Now you risk splitting the network in half. You need to provide some sort of guarantee that we won't have another altcoin fiasco (BCH/BSV). Who can do that? BTC Core devs? They don't control the network (miners).

That's a wrong comparison. The bcash fiasco was a minority trying to split off. The problem with those two shitcoins is not even with their bigger blocks, it is all about the fact that they did NOT fork by reaching majority consensus.
The guarantee is as it has always been with any fork: to vote and only lock in after we reach more than 90-95% support.

[ABCbits]

Can somebody show me some data or a paper to support this?

It's simple. When a miner mines a block, they are the first to have verified that block; it happens during mining to check for the validity of the transactions. When they broadcast their block, the rest of the miners must firstly verify it before mining on top. The bigger the block size, the more time it takes to verify the block, and hence, the more the time the lucky miner gains to continuing mining alone.

And it's not just verification, it's propagation as well.

FYI, Compact Blocks (https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/) partially mitigate this problem as you don't have to propagate whole block and the TX already verified when it arrive on your node.

On one hand, bitcoin remaining to be in this 1 mb size limit ensures that decentralization is taken care of

Actual block size limit isn't 1MB, but rather 4 kWU (4 million weight unit) or 1 vMB (1 virtual mega byte) where actual size of block can reach up to 4MB.

and that no one has to pay so much fees in the future.

How can you be sure when in this week you need to spend few dollars to ensure your TX included in next few blocks?

[Wind_FURY]

I believe some of you might start going deeper into the argument for bigger blocks that you might also start to think Roger Ver and Bitcoin Cash made the right decision, and you might also start debating for Satoshi's original vision.

They have their thesis, and the product of that thesis is BCash 32MB Blocks. It's probably a good network to test NFTs in the blockchain, no? Their miners might be very worried because their block rewards will be halved next year.

[DooMAD]

Now you risk splitting the network in half. You need to provide some sort of guarantee that we won't have another altcoin fiasco (BCH/BSV). Who can do that? BTC Core devs? They don't control the network (miners).

That's a wrong comparison. The bcash fiasco was a minority trying to split off. The problem with those two shitcoins is not even with their bigger blocks, it is all about the fact that they did NOT fork by reaching majority consensus.

The question effectively becomes:  "What does it take to get everyone on the same page?"  

Even under the pressure of Ordinals, we can't find agreement within a tiny sample of network participants.  It seems unlikely we'd find network-wide consensus, so cryptozize isn't wrong to point out the inevitable outcome if people try to rush this.

For the record (and before obnoxiousgasbag1 tries to put more words in my mouth), I'm not fully opposed to throughput increases.  I'd just rather any proposals are appropriately timed, measured, reasoned and that all the consequences are fully considered.

[Synchronice]

I have said many times that I feel satoshi’s biggest mistake with Bitcoin was not putting in a block size adjustment feature similar to the way difficulty is adjusted. I believe the blocksize limit was put in place as a knee jerk reaction to the chain being spammed and if satoshi had more time on this earth a method to adjust the blocksize limit would have been put in place.

We can't blame him, he couldn't really keep absolutely everything in mind. Sometimes, you discover new problems as time goes by but you are right, it would be the best solution to increase block size two times as reward splits.

What makes BCH and BSV shitcoins is a plethora of reasons other than just having bigger blocks.

People call BCH and BSV shitcoins because they read someone posted shit on them. Actually, they don't know the real reason why these coins are shitcoins. They have probably never heard about Craig Wright, Roger Ver, Jihan vu and others.

I read many posts and to be honest I can't understand how increased block size can make bitcoin less secure. Is 1MB any standard for security?
Also, I want to say that it's not a problem today to store bitcoin blockchain on hard drive. SSDs and HDDs are way cheaper than they were years ago, we have far more speed and capacity today for a cheap price. Please, don't call a problem something that is not a problem. Space and price is not a problem today! Increased block size won't be a problem today! If block size was a problem, someone would come up with an idea to decrease block size in 2015-2016 but no one came up with that idea because that's not true!

But to be honest, after thinking for a while, I think we have another problem besides block size and they are miners. Mining is becoming way centralized, pools are collecting all the transaction fees and people are willing to join pools that don't share transaction fees. These pools are one of the biggest pools who can flood mempool with their resources and gain more profit. They can flood it easily because they confirm the blocks and fees go back to their pockets but increased block size should make it a little bit hard for them to do.

[franky1]

The question effectively becomes:  "What does it take to get everyone on the same page?"  

For the record (and before obnoxiousgasbag1 tries to put more words in my mouth), I'm not fully opposed to throughput increases.  I'd just rather any proposals are appropriately timed, measured, reasoned and that all the consequences are fully considered.

but you REKT proposals by you scripting to your flock silly exagerations.. not real technical reasons

Even under the pressure of Ordinals, we can't find agreement within a tiny sample of network participants.  It seems unlikely we'd find network-wide consensus, so cryptozize isn't wrong to point out the inevitable outcome if people try to rush this.

but you dont beleive in the PEOPLE. you dont like consensus, you beleive there should be no consent of the people, you love the "backward compatibility" that bypasses the requirement of a consensus vote. you hate anyone not core adoring/affiliated. you love only core having the decision and development power.. so why pretend that its "people" trying to rush it.. rather than admit its core avoiding for unreasonable reasons

[CreepyUncleJoe]

The present average Bitcoin fee at 123 sat/vB, amounting to $6.29, renders it useless for everyday transactions.

[BlackHatCoiner]

I believe some of you might start going deeper into the argument for bigger blocks that you might also start to think Roger Ver and Bitcoin Cash made the right decision, and you might also start debating for Satoshi's original vision.

It really depends on what classifies as "right". Opinions fundamentally differ on block size policy.

I read many posts and to be honest I can't understand how increased block size can make bitcoin less secure. Is 1MB any standard for security?

I have explained in this post.

Also, I want to say that it's not a problem today to store bitcoin blockchain on hard drive.

Not on 4 MB blocks. Maybe neither on 10 MB or 20 MB, but if you arbitrarily increase it to something like 100, then that will also be a problem at some point.

[alani123]

Seriously, my question remains unanswered: why haven't you moved to BSV? Or more reasonably, to BCH? Nobody answers this. These particular coins aren't alts in the traditional sense, they were Bitcoin until someone realized they are capable of enforcing their own policy, forming a network in respect to their perspective. How different is your proposal comparably to Roger Ver's?

The thing is, BCH is alive only because Roger Ver was rich before he created it.
He turned blockchain.com, satoshidice, bitcoin.com and some other ventures of his into hubs for BCH. If these are gone, its questionable if BCH will also survive.
Roger Ver is bitcoin cash's strength due to his support to it, but also its biggest detriment. I think no sane bitcoiner would lend his support to a coin that's so centered around the support of a single person.

The ideal solution would be for the main bitcoin code base to implement a solution that would accommodate on-chain scaling, while keeping all its merits in decentralization, talented devs and community. Bigger blocks might address the issue of scaling but as many have rightly pointed out, it's not the single most important issue for bitcoin, and especially in 2015, it wasn't a good time to split from core over this issue. A more scalable solution for transactions is needed now more than ever. In 2017, when BCH split from core, it failed to demonstrate the need for bigger blocks, and was just seen by a greedy move. Years later and BCH is still Ver's cash cow while he has altogether stopped interacting with the bitcoin community.

So just my two cents, but saying to people that they might as well go support BCH if they want bigger blocks, isn't really something productive.
Increasing block capacity has some merits and these should be examined individually. Goal here is to improve the bitcoin we love, not shoot each other in the foot.

[franky1]

I read many posts and to be honest I can't understand how increased block size can make bitcoin less secure. Is 1MB any standard for security?

I have explained in this post.

you did not explain anything
you instead
a. thought that ASICS validate transaction data.. they dont .
ill quote you

It's simple. When a miner mines a block, they are the first to have verified that block; it happens during mining to check for the validity of the transactions.  

you are wrong about what miners do and wrong about when transaction validation happens, heck your even wrong about the term miner
asics(miners) just hash a header.. a length of header/hash doesnt change no matter the "blocksize"
pools(transaction validator, collator and blocktemplate creators) are separate things

b. then went and exaggerated a 1gb scenario of extreme irrationalness

[DooMAD]

The question effectively becomes:  "What does it take to get everyone on the same page?"  

For the record (and before obnoxiousgasbag1 tries to put more words in my mouth), I'm not fully opposed to throughput increases.  I'd just rather any proposals are appropriately timed, measured, reasoned and that all the consequences are fully considered.

but you REKT proposals by you scripting to your flock silly exagerations.. not real technical reasons

For what must be the dozenth time, if you can't present a compelling argument, the failure is yours.  Weak proposals die.  Poorly considered proposals die.  Irrational and dangerous proposals die.  Don't offer proposals like that if you want a different outcome.  

Every time you cry "REKT" because you didn't get what you want, you are admitting to the world that your idea simply wasn't good enough.  It's not my fault every half-baked idea you've ever had is ridiculously easy to tear down.  Take some ownership for your myriad failures and stop blaming others.

Better yet, take a back seat and let the grown-ups talk.  In case you weren't aware, people generally find you to be insufferable and overbearing.  I, for one, would be genuinely reluctant to be seen on the same side of an argument as you, simply because you're so utterly repellent.  It wouldn't surprise me if others felt the same. You're a hindrance to your own cause.  Literally the best thing you could do to achieve your goal is to keep your idiot mouth shut.

but you dont beleive in the PEOPLE. you dont like consensus, you beleive there should be no consent of the people, you love the "backward compatibility" that bypasses the requirement of a consensus vote. you hate anyone not core adoring/affiliated. you love only core having the decision and development power..

None of this gibberish is worth my time repudiating.  Mostly because I've already done it countless times before, but also because literally no other living creature on the face of this planet has levied such accusations against me.  These notions exist nowhere other than your deranged imagination.

[cryptosize]

But to be honest, after thinking for a while, I think we have another problem besides block size and they are miners. Mining is becoming way centralized, pools are collecting all the transaction fees and people are willing to join pools that don't share transaction fees. These pools are one of the biggest pools who can flood mempool with their resources and gain more profit. They can flood it easily because they confirm the blocks and fees go back to their pockets but increased block size should make it a little bit hard for them to do.

Actually it's the opposite.

If 4GB blocks become the norm (because that's what BSV folks envision), then FTTH would become mandatory. ADSL is still the most common (baseline) connection worldwide, hence why 1MB block size makes sense as a "baseline".

Hell, I would argue that the few remaining, hyper-competitive pools would be concentrated into a single geographical spot (maybe USA?) and they wouldn't even use FTTH.

They would just use LAN/Ethernet connections (1 Gbps symmetric) to sync with each other! Kinda like a LAN party if you will. BTC would turn from a permissionless network to permissioned (some pools already demand KYC).

You really like this scenario? This is not very different compared to fiat/central banking (i.e. ECB TARGET2 ledger).

I really wonder if big block fanatics are sincere good guys/idealists or government trojan horses/feds trying to hijack BTC, even though they pretend to preach "global adoption".

I sincerely hope we won't have to find out...

[pooya87]

I believe some of you might start going deeper into the argument for bigger blocks that you might also start to think Roger Ver and Bitcoin Cash made the right decision, and you might also start debating for Satoshi's original vision.

You should already know that the problem with bcash is not even Ver, nor was it the fact that it increased the block size to whatever MB. The problem with bcash and the reason why it is considered a shitcoin is that it is a contentious hard fork. In other words it was the minority making a change in consensus rules without having the majority's support.

The question effectively becomes:  "What does it take to get everyone on the same page?" 

We've managed to make a lot of changes in the consensus rules through over a dozen forks and all of them could get "everyone" on board (95%+ and I believe once was 75% threshold).

The problem is toxic people who also spread misinformation. As long as they don't muddy the development process and the community, it is not as hard as you'd think to get everyone on the same page.
So I'd say a better question is "how do we get rid of toxicity?"

Even under the pressure of Ordinals, we can't find agreement within a tiny sample of network participants.

Same. We still haven't been able to get rid of those who continue using the term "token" when referring to Ordinals. That's the simplest and most basic thing! As long as we fail to do that, we fail to move to the next level.

The damage of spreading such misinformation will remain in the Bitcoin community for years too. Like with SegWit that even today there are people who say "SegWit removes signatures from transactions" all because of misinformation similar toxic people spread about it in 2017.

[digaran]

If 4GB blocks become the norm

BSV, BCH etc are all irrelevant, talking about GB blocks is also irrelevant to Bitcoin block size discussions, no one is stupid enough to actually think about anything above 100MB by 2030. So I think bringing GB is bad, it makes mining centralized etc is a fallacy.
I don't know who you are but it seems you have a few pockets filled by recent spam attacks and you are trying to deviate from the actual concern, which is ; Bitcoin has to scale. I would say if we had 8MB blocks, we could hit the walls of $80,000 by now, but that's just speculation right?

[BlackHatCoiner]

a. thought that ASICS validate transaction data.. they dont .

No, I didn't. I'm just directly referring to mining pools as "miners".

heck your even wrong about the term miner

Cool it. I know what the terms mean, and all those stuff you mention. I'm just citing miners as those who broadcast the blocks for the sake of simplicity. No need to turn completely technical for every single thing we say, or we derail the thread. 

b. then went and exaggerated a 1gb scenario of extreme irrationalness

Wanna tell us what's the ideal block size limit according to you?

I would say if we had 8MB blocks, we could hit the walls of $80,000 by now, but that's just speculation right?

Right. 

[cryptosize]

I don't know who you are but it seems you have a few pockets filled by recent spam attacks

Right Mr. Sherlock, you've exposed the grand conspiracy behind the cryptosize alias!

Gosh, this forum never ceases to amaze me...

I would say if we had 8MB blocks, we could hit the walls of $80,000 by now, but that's just speculation right?

Not only it's speculation (that's fine), but it's totally unfounded.

We won't hit a new ATH by Dec 2024/Jan 2025 at the earliest, so 80k ain't happening any time soon, regardless of block size. Feel free to bookmark/screenshot my post.

BTC never reaches a new ATH, until at least 6 months have passed after the latest halving. Study the charts/patterns.

[franky1]

b. then went and exaggerated a 1gb scenario of extreme irrationalness

Wanna tell us what's the ideal block size limit according to you?

well you want to turn the debate into "gigabyte by 2024" much like your forum wife mentor used to be part of the 2016 script of anything but core design is "gigabytes by midnight"

there are many many many ways to increase transaction count
a. lean transactions where transactions cant take up full 4mb for one tx
b. not have the cludge of 1mb base 3mb witness. and just have full open access 4mb for transactions to fully utilise
c. charge (young confirm) spammers and non signing proof witness junk, multiples of base fee.. to deter such spam(using fee formulae)

and thats without even going beyond you fear of 4mb
as for going beyond. . its not about huge leaps to 1gb in hours/months.. its progressive increases.
these increases dont even need to be decided each time by dev politics of threats and blackmail. but using the blockdata to determine that things are getting congested over a reasonable period(once dev politics bothers to instigate it first and only time)

EG if 95% of blocks are >95% full and sat/byte >xxsat =peak demand over 13,104 - 26,208blocks (3-6 months)
that way its data driven not HUMAN "god" politics driven

[digaran]

Do the node owners ever ask this question: Why would I run a node and store irrelevant data, then when I want to send a transaction, I'd need to pay $10?  Imagine you want to send 1 TX per day, it would be $300 per month, mining pools better start running the nodes, right? Because they are so fond of these dust spams.

[franky1]

Do the node owners ever ask this question: Why would I run a node and store irrelevant data, then when I want to send a transaction, I'd need to pay $10?  Imagine you want to send 1 TX per day, it would be $300 per month, mining pools better start running the nodes, right? Because they are so fond of these dust spams.

actual node users do ask those questions.. they know transactions costs mean more then hardware costs.. thats why there are many transaction cost topics and not any "my PC burns out" topics
there are hundred of scaling topcs with thousands of people discussing SCALING BITCOIN. but only dozens of snake oil salesmen type topics promoting the solution as subnetworks.. you start to notice what the community care and want more

but if you look at the subnetwork promoting trolls exaggerating hardware costs, exaggerating 1gb block scenarios, want to do nothing about bloated junk transactions..
those people dont run full nodes.. their game is just to annoy actual bitcoiners to pretend nothing can/should be done and instead move over to their prefered network.. you just got to look at their post history to see their game plan and admissions they dont even full archive the blockchain themselves nor run nodes 24/7

[alani123]

But to be honest, after thinking for a while, I think we have another problem besides block size and they are miners. Mining is becoming way centralized, pools are collecting all the transaction fees and people are willing to join pools that don't share transaction fees. These pools are one of the biggest pools who can flood mempool with their resources and gain more profit. They can flood it easily because they confirm the blocks and fees go back to their pockets but increased block size should make it a little bit hard for them to do.

Actually it's the opposite.

If 4GB blocks become the norm (because that's what BSV folks envision), then FTTH would become mandatory. ADSL is still the most common (baseline) connection worldwide, hence why 1MB block size makes sense as a "baseline".

Hell, I would argue that the few remaining, hyper-competitive pools would be concentrated into a single geographical spot (maybe USA?) and they wouldn't even use FTTH.

They would just use LAN/Ethernet connections (1 Gbps symmetric) to sync with each other! Kinda like a LAN party if you will. BTC would turn from a permissionless network to permissioned (some pools already demand KYC).

You really like this scenario? This is not very different compared to fiat/central banking (i.e. ECB TARGET2 ledger).

I really wonder if big block fanatics are sincere good guys/idealists or government trojan horses/feds trying to hijack BTC, even though they pretend to preach "global adoption".

I sincerely hope we won't have to find out...

I wonder why we have to keep conflating the discussion with BSV and BCH.
Already I've seen some BSV fans here (to clarify, I'm not one of them) that voiced their opinion saying that they're against a block capacity increase for BTC.
Obviously their reasoning is that they believe they can do it bigger and better... But why should that concern us?
Is the goal to improve BTC or not? Because obviously BSV as a ton of faults, and just because CSW is acting the way he does, it doesn't mean that bitcoin would have to fall in the same traps when implementing an improvement.

At this point I find these arguments quite counterproductive to be honest.
Bitcoin's development is supported by many scientists, if we all agreed that a slight block capacity increase is warranted, they'd find a way to implement it well enough so there are no fundamental issues.

[franky1]

I wonder why we have to keep conflating the discussion with BSV and BCH.

because the trolls who say it are stuck in their 6yo narrative thats been debunked but they dont have the brain power to do any research to actually realise how wrong they are about alot of things. so they just repeat themselves hoping if they can recruit one more idiot then it must mean they are right.

they lack actually making realistic and rational observations about data, code and mechanisms that can benefit bitcoin and instead they just want to pretend if someone is not following cores roadmap, they must be some old altcoin tribe..  to them its brand war clan fight. 'if your not with core, your against bitcoin' nonsense.. rather than actually discussing REALISTIC data requirements and plausible scenarios of realistic possibilities

[cryptosize]

But to be honest, after thinking for a while, I think we have another problem besides block size and they are miners. Mining is becoming way centralized, pools are collecting all the transaction fees and people are willing to join pools that don't share transaction fees. These pools are one of the biggest pools who can flood mempool with their resources and gain more profit. They can flood it easily because they confirm the blocks and fees go back to their pockets but increased block size should make it a little bit hard for them to do.

Actually it's the opposite.

If 4GB blocks become the norm (because that's what BSV folks envision), then FTTH would become mandatory. ADSL is still the most common (baseline) connection worldwide, hence why 1MB block size makes sense as a "baseline".

Hell, I would argue that the few remaining, hyper-competitive pools would be concentrated into a single geographical spot (maybe USA?) and they wouldn't even use FTTH.

They would just use LAN/Ethernet connections (1 Gbps symmetric) to sync with each other! Kinda like a LAN party if you will. BTC would turn from a permissionless network to permissioned (some pools already demand KYC).

You really like this scenario? This is not very different compared to fiat/central banking (i.e. ECB TARGET2 ledger).

I really wonder if big block fanatics are sincere good guys/idealists or government trojan horses/feds trying to hijack BTC, even though they pretend to preach "global adoption".

I sincerely hope we won't have to find out...

I wonder why we have to keep conflating the discussion with BSV and BCH.
Already I've seen some BSV fans here (to clarify, I'm not one of them) that voiced their opinion saying that they're against a block capacity increase for BTC.
Obviously their reasoning is that they believe they can do it bigger and better... But why should that concern us?
Is the goal to improve BTC or not? Because obviously BSV as a ton of faults, and just because CSW is acting the way he does, it doesn't mean that bitcoin would have to fall in the same traps when implementing an improvement.

At this point I find these arguments quite counterproductive to be honest.
Bitcoin's development is supported by many scientists, if we all agreed that a slight block capacity increase is warranted, they'd find a way to implement it well enough so there are no fundamental issues.

A slight capacity increase is not going to solve scaling issues (assuming mass adoption is the endgame) and still risks splitting the network in half.

People need to find more ingenious solutions (soft forks like SegWit).

Who knows, maybe if AI advances enough, it could do BTC R&D by itself (assuming people won't find a good enough solution).

It won't be easy to reach a consensus regarding the "ideal" block size. Who determines what's ideal? For what purpose?

Some people want BTC to be the be-all and end-all cryptocurrency and no alts to exist (such as LTC, DOGE, XMR).

I get it, it sounds noble, but I'm afraid this is not going to happen. It hasn't happened to Linux distros AFAIK (tons of debates about the ideal distro, libraries etc.)

There's a reason so many Linux distros exist. Same with cryptocurrencies.

ps: A BTC hard fork will happen only when a real threat arises (such as mainstream quantum computing).

[digaran]

Do you know any of the core devs coming here and officially address the community about their road map, future plans, emergency plan B to mitigate such situations? I wonder why is that? Maybe they don't consider this forum as a part of community or maybe it's beneath them to interact with us normies, or maybe they are already here in disguise, who knows all we see here are 4-5 usual shills as always, and a few unknown individuals popping up from time to time to shill their own agenda.

It's extremely rare to see genuine concerned long standing and respectful members that could convince people with reasoning.

And if there are any, they have the "troll" label, so it dismisses the respectful and long standing notion. 

[Synchronice]

Why didn't you calculate this for 10 MB blocks? After all, we are talking about this increase now.

For increase to 10 MB, I'll right as well vote in favor, and maybe a little higher than that. I have clarified before that I'm not strictly against anything beyond 4 MB, I'm just not of the opinion that it's going to solve the problem; it's only delaying it.

Yes, it doesn't solve the problem but it's clear that current block size is not enough and it's not just a temporary case. What if bitcoin becomes popular and millions of people want to make transaction each day? They'll move on altcoins and this is a very serious threat.

I read many posts and to be honest I can't understand how increased block size can make bitcoin less secure. Is 1MB any standard for security?

I have explained in this post.

I missed that post, sorry.
I like your question: what's the ideal block size? Ideal size doesn't exist but size has to be chosen. Something flexible would be great, like, block size adapts to number of transactions, i.e. one block gets mined every 10 minutes and includes 5% of all transactions. If number of transactions increase, block takes more transactions and block size increases and if number of transactions decrease, so does the block size. But that's probably not possible.

Also, I want to say that it's not a problem today to store bitcoin blockchain on hard drive.

Not on 4 MB blocks. Maybe neither on 10 MB or 20 MB, but if you arbitrarily increase it to something like 100, then that will also be a problem at some point.

10MB is not a problem today but it was a problem years ago, right? 100MB is a problem today but it won't be a problem years later. I'm afraid, we may have to gradually increase block size but it's not the best solution to the problem. This problem is not easy to deal with. After all, block size increase really looks like delaying the problem but that doesn't mean we should stop on current limit even if it means delay.

[Casdinyard]

initially I don't really care much about the block size of bitcoin, since in my opinion decentralization runs deeper than just bytes and bits in this industry. But as I grew older and wiser, I realized that there's more to this than just block size and decentralization.

We haven't even broken the code just yet, we're still at a 1mb limit if I'm not mistaken and we're already getting large companies that invest large amounts of bitcoin to themselves for profit or security, just this year Tesla sold theirs which caused a decline in bitcoin's price, followed by a mini domino effect within the market that persisted until the whole situation subsided. This says to me that we're either in the dark times, where we're fucked either way, since capitalism will still take what it could take, or that the blocksize war's motives are becoming more real as time goes by.

[DooMAD]

b. not have the cludge of 1mb base 3mb witness. and just have full open access 4mb for transactions to fully utilise

This reeks of potential technical debt.  It's something you've proposed on numerous occasions for the last few years now, but have never fleshed out.  How, exactly, do you propose enacting this?  Don't just give us the wishlist, tell us step by step what this option actually entails.

Something flexible would be great, like, block size adapts to number of transactions, i.e. one block gets mined every 10 minutes and includes 5% of all transactions. If number of transactions increase, block takes more transactions and block size increases and if number of transactions decrease, so does the block size. But that's probably not possible.

I'd also rather see something adaptive and dynamic.  In the past I've advocated for such an approach.  It likely is possible, but the primary challenge is that it has to stand up to game theory.  If there are ways to manipulate or rig the system to an outcome which suits an attackers goals, then it's no good.  We can't inadvertently introduce that kind of weakness.

[philipma1957]

If 4GB blocks become the norm

BSV, BCH etc are all irrelevant, talking about GB blocks is also irrelevant to Bitcoin block size discussions, no one is stupid enough to actually think about anything above 100MB by 2030. So I think bringing GB is bad, it makes mining centralized etc is a fallacy.
I don't know who you are but it seems you have a few pockets filled by recent spam attacks and you are trying to deviate from the actual concern, which is ; Bitcoin has to scale. I would say if we had 8MB blocks, we could hit the walls of $80,000 by now, but that's just speculation right?

and it needs to scale better than the ltc/doge 12x tx capacity edge.

So are we at 4mb right now. 12x that is 48mb

maybe it tries 32mb blocks and 0.0001000 as a minimum dust send with 0.00001 as a minimum fee.

See what that does for ordinal prevention.

[franky1]

b. not have the cludge of 1mb base 3mb witness. and just have full open access 4mb for transactions to fully utilise

This reeks of potential technical debt.  It's something you've proposed on numerous occasions for the last few years now, but have never fleshed out.  How, exactly, do you propose enacting this?  Don't just give us the wishlist, tell us step by step what this option actually entails.

the technical debt already exists.. its the cludge they already put in it to get segwit working

the code sipa added when rewriting bitcoin core to make segwit work (the cludge) reeks of technical debt because it is.. however not having the cludge and getting back to simpler straight forward block sizes, proper coding, proper byte counting, proper validation.. lessens/undoes the technical debt

if you dont thing core screwed up and introduced a open door to let junk in.. explain the ordinal inscription junk that abuses cores unconditioned opcodes due to segwit/taproot

as for the cludge,
yes there are many lines of code in different sections that deal with the legacy*witness and serialised / witness.. and all the other cludge of vb and weight unit manipulations of byte counting..  but thats cores own fault for creating the cludgy way of trying to slide segwit in..

getting back to clean code where its a unified 4mb where both legacy and segwit can be side by side under a unified single merkle to allow more transactions in the full 4mb space will require undoing the cludge (technical debt)

for instance in 2016 when core was a simple blocksize=1000000
it was much easier to move to blocksize=2000000 blocksize=4000000 blocksize=8000000 without affecting other area's of code much

but the way they patched segwit together with the max block weight = 40000000 witness scale factor = 4
(1mb base 3mb witness=4mb)
its not simple to go to: max block weight = 80000000 witness scale factor = 4
(2mb base 6mb witness=8mb)
because the cludge of the other parts of the code then has to be changed too, in many places..

however undoing the cludge to have a unified, simplified blocksize=4000000 which yes will take rewriting lots of area's.. will later make it easier to go to blocksize=8000000.. but before even going to 8mb will help more transactions utilise the 4mb space in the unified blocksize=4000000

and yes while they are at it cleaning the code up. they can put conditions on the opcodes to not allow full blocksize wastage per script(witness)

[digaran]

to stand up to game theory.  If there are ways to manipulate or rig the system to an outcome which suits an attackers goals, then it's no good.  We can't inadvertently introduce that kind of weakness.

Friendly fire! Friendly fire!, lol. Are we still talking about future upgrades here? Because despite my lack of understanding about the entirety of taproot, I am pretty much certain that what you just described is happening right now, I swear I'm not lying or trolling, you can check to see those orange blocks turning to red and are about to explode on mempool.space.

Believe it or not, I'm an extremist in regards to have a central and united team of development, because despite it being the central point of failure, it keeps strangers hands off the changes in the code, and because if they start showing any signs of incompetency, we could replace them by persuading the whole community, my concern is that I can see some  yellow flags, and don't wanna wait to see the obvious red ones.

I'm confident that anyone who wants micropayments will adopt LN one way or another, sooner or later, and scaling the network to make room for non-micro transactions is begging to happen.

[franky1]

t anyone who wants micropayments will adopt LN one way or another, sooner or later, and scaling the network to make room for non-micro transactions is begging to happen.

LN subnetwork is too flawed and even proven and admitted so by LN devs themselves..
im sure for the niche that want microtransactions should start afresh and build a subnetwork that can meet its promises and learn from LN mistakes.. but users wanting microtransactions should not be looking towards LN as their saviour.. its not the solution that was promised. not matter how much they utopian dream advertise it is

millions of users have looked at LN seen its failures and decided to use other subnetwork bridges for microtransactions.. its time LN devs go back to the drawing board and learn from the mistakes

just look at DCG who was a big sponsor of blockstream(core+LN devs) to do what they did(segwit as gateway key to LN) to push to create LN. but now 6 years later if you look at DCG portfolio of sister companies and look at how LITTLE of them actually advocate and use LN. just shows even they dont see it as a ready to use product they paid for. EG  if you need to ask why coinbase(dcg sister) doesnt use LN.. you already know the answer

[thecodebear]

Circa 2014 the block size wars took bitcoin by storm.
Eventually after a lot of drama that has been well documented elsewhere (I made my own attempt documenting a time line of the blocksize wars, its outcomes and conclusions here).

But I'm starting this poll in hopes of getting the community's opinion. So for this post I'll not go through my opinion in the OP.
Please feel free to answer the question in the poll and even better if you can also explain your answer.

Back in 2015, and after the adoption of a compromise in the form of SegWit, the topic of the block capacity was very taboo.
Well, we're in 2023 now, and for different reasons congestion is still an issue. Increasing the capacity of bitcoin blocks could potentially be a solution to the issues of high fees and congestion.

So I think it's worth exploring what people think about this issue. Please share your thoughts below.

There's nothing inherently wrong with bigger blocks. But its not a real solution to anything, it's at best a temporary partial solution. You don't get mass usage through big blocks, all you'd get is a weak broken blockchain. It also requires a hard fork and the continuity of Bitcoin's blockchain being backwards compatible is kinda important. If one day the community decides for some reason to do a hard fork upgrade then I'd be fine with like a 2x or 4x increase in blocks, as I don't think that'd be enough to really have negative impacts, but it's not a real solution to much at all, maybe at best it would help miners in the decades to come when the coinbase reward gets low. Bitcoin capacity is reached off-chain, not on-chain. Off-chain solutions are the only real solution to mass adoption. This is why the community chose segwit, while those who thought a weak bitcoin would be okay created altcoins like BCH and BSV, which are useless random tokens no different than thousands of others.

LN, as well as other off-chain solutions (present and future solutions) are the only answer.

[franky1]

LN, as well as other off-chain solutions (present and future solutions) are the only answer.

LN is not a present solution
and suggesting "bitcoin do nothing, everyone use LN" is not the solution
the solution is not also "just dont transact and wait a couple months the congestion might die down by then"

there are reasons people need to use bitcoins confirmation/settlements security of the blockchain. there are security pitfuls of using other systems.. so trying to suggest people should move to other systems and stay away from bitcoin wont be helpful either..

yes subnetworks have a niche. and in the future new better ones will be made to meet the crtieria they were made for. but confirming/settling on bitcoin will still be a need so things still need to be done to bitcoin.

and its not just "bigger blocks" its actually
leaner transactions.
count every byte, make every byte count
condition all transaction formats to perform, whereby every byte serves a purpose.
limit the transaction overhead computationally
make spammers/bloaters personally penalised to not cause everyone to be expensed out of using bitcoin
penalise spammer/bloater by enough of a multiple that they actually stop due to the expense

all these things can help make genuine bitcoin transactors able to confirm/settle their transactions with less remorse of using bitcoin.

[digaran]

LN, ...snip... only answer.

Oh hi, when did you land? From mars I mean, seems you haven't been on earth for a few month.

What keeps a network really strong is it's userbase, and we all know after whales are done moving their funds around, there will only remain those end users who can only afford to pay from $1 up to $3, if they can't do that, there will be 2 certain outcomes, some will dump all they have and move to alternatives, and only half would keep a part of their funds in BTC, and they would stop transacting, and would just hodl for long term. Then we can say bye to at least %35 of loyal users, since Bitcoin is not a ponzi, we can't expect new bloods joining and keep the system strong, no because people have eyes.

If I was an online shop, I would immediately drop the Bitcoin payments, now if 5000 online shops do that, say bye to 5000 potential long standing users each of them capable of using Bitcoin dozens of times on a daily basis.

[garlonicon]

What are your thoughts on increasing bitcoin's block capacity? (please explain in response)

I am for it

Go for it. Write some code. Try to get there, and create your own altcoin, and fail (the first scenario, if you are not experienced enough), or submit a proposal, and get it rejected (the second scenario, if you know, how to write code), or make it a no-fork, and be blamed for spamming the network (Ordinals scenario, if you know, how to write a no-fork block size increase).

For now, the only thing I can see is just a discussion. I wonder, how many people, who are big blockers, actually tried to write some code, and submit it. Because if they would try it at least once, then I guess they would reach at least one of those three scenarios explained above, maybe also some other outcomes I didn't think about.

About blaming the Core: you cannot beat something with nothing. If you think their code is bad, then I guess you are using your own client. So, where is it? How can I download it? Talking is easy, but if big blockers will do nothing, then even if they will win in this poll, it will not change anything.

But of course, if I really voted "I am for it", then I should present my own solution as well, right? Good news: I did that. Been there, done that, I support sidechains, and they were officially rejected as a soft-fork, proposed by Paul Sztorc. And now, I am trying to reach the gate number three (no-fork), but without spamming the chain in the way Ordinals do. So far, so good, but the code is not fully tested yet, so it is not yet public. And finally, maybe I will join some other no-fork proposal, instead of publishing my own version, we will see.

[lottery248]

in 2019, there are 108.6 million card transactions per day.

so the block size increase should have done far sooner and radical if bitcoin is to be for mass adoption, 4MB per block under today's load is still treating bitcoin as if it is still a community currency. when we look at the mempool right now, there are more than 200k unconfirmed transactions, which you already can imagine how slow it is.

let's say a 2MiB block has 5k transactions on average, and the each block happens every 10 minutes, it means 720k transactions per day. if we have to match the 2019's rate, it is about 300MiB per block that equivalates 108m transactions per day.

but the problem is the entire blockchain which stands at about 526GB right now. we need to change the system of the blockchain synchronisation requirement to increase efficiency and decrease burden for those who do so. for example, fragmented blockchain which maintains blockchain size per user at a level they can afford to (about 15~100GB per user depending their ability and the network stability).

i still remember the earlier days using bitcoin wallet would take me at least a week just to do that at the time it was 75GB.

[HmmMAA]

But, I can ask you another question: if Satoshi wanted to fully use OP_PUSHDATA4, then why he limited MAX_SIZE of the P2P message into 32 MiB (0x02000000), and later limited block size into 1 MB (1000000)? Why November 2008 version was limited to only 32 MiB P2P message size? Yes, that November 2008 version, which contained quite huge Script support, what you can discover by exploring the Script of the coinbase transaction, used in that version (also note that it contained 100.00 BTC, expressed with 2-digit precision only as "10k satoshis", instead of 8-digit precision we have today, and that OP_CODESEPARATOR was mandatory at that time).

I can't get into the techinical details as i'm not educated in this . But , you can understand that at that time HDD's and broadband speed were not the same as today . Also the network was at it's infancy . Things changed since then .
I'll quote satoshi :

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.  Because of that, I wanted to design it to support every possible transaction type I could think of.  The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time.  It would have been an explosion of special cases.  The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.  The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

The script is actually a predicate.  It's just an equation that evaluates to true or false.  Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script.  Currently, receivers only accept two templates: direct payment and bitcoin address.  Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them.  All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

The design supports a tremendous variety of possible transaction types that I designed years ago.  Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc.  If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.

I don't believe a second, compatible implementation of Bitcoin will ever be a good idea.  So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.  The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.

"Bitcoin isn't currently practical for very small micropayments.  Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01.  The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.
Bitcoin is practical for smaller transactions than are practical with existing payment methods.  Small enough to include what you might call the top of the micropayment range.  But it doesn't claim to be practical for arbitrarily small micropayments. "

"Quote from: theymos on October 03, 2010, 08:28:39 PM
Applying this patch will make you incompatible with other Bitcoin clients.

+1 theymos.  Don't use this patch, it'll make you incompatible with the network, to your own detriment.

We can phase in a change later if we get closer to needing it."
And for the backwards compatibility part that most believe should not change , the moment satoshi proposed

"It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete. "

the road for hard forks open . If satoshi was against it , he wouldn't post such a thing , but would propose something in a backwards compatible way .

The whole Script is not necessary for Bitcoin to function. In the whitepaper, you have only P2PK, and nothing else. And it is still called Bitcoin, and people still check many coins if they implement everything from whitepaper, if they want to call something "the true Bitcoin" or not. Which means, your OP_PUSHDATA4 is not even mentioned there. We could start from P2PK-only system as well, and add commitments later, or even attach Schnorr signatures or TapScript later, directly into those public keys. Then, in such system, spending-by-pubkey would be always mandatory, but some keys (for example the private key equal to one) could require a commitment to some Script.

The answer is in the quotes above . Script is necessary for bitcoin to work as a network that apps and new type of transactions can be build upon . They're not necessary for bitcoin to work just as a medium of exchange .

Edit: Also, Satoshi explicitly said something about uploading videos:

I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it.  I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.

That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...

That's one of the reasons for transaction fees.  There are other things we can do if necessary.

See? The answer was not "just use OP_PUSHDATA4, and upload it". The answer was "fees are needed to discourage that". And even more: "if fees will not be sufficient, then we can do something else to limit it further". That's what he said, as you can see above, and click on the link to the quote to confirm it.

Nope , don't make words look like what you want them to be . He says "that's one of the reasons for transaction fees" . If you want to use the network that way you have to pay the price .
Also states " There are other things we can do if necessary" . What he meant by that ? Who knows .
He doesn't explicitly states that using OP_pushdata4 is forbidden like you make it look like .
And to put it another way , if he didn't want it he wouldn't have added it to OP's .

[vjudeu]

Script is necessary for bitcoin to work as a network that apps and new type of transactions can be build upon .

1. If it is necessary, then why it is not included in the whitepaper?
2. You won't believe how many things can be coded with public keys only. Imagine that if you have a Schnorr signature, then you can add and multiply 256-bit numbers. This is enough to implement a lot of conditions.
3. There is no need to include Script in the first version. It can be added later if needed, exactly in the same way as Taproot was added: you can spend by P2PK, or spend by P2SH, and wrap all of that in a single address type. This is how Taproot works: you never know, if there is some huge Ordinal behind some P2TR address, or if there is just a public key, and nothing else. The same could happen with P2PK back then, there were no technical difficulties in implementing that.

I can't get into the techinical details as i'm not educated in this .

This is the problem. As Garlo Nicon mentioned above, "you cannot beat something with nothing". So, if you don't know, how to write some code, then ask someone, who thinks like you, to do that. Or join some existing team. Because the best thing is when you figure out, that your ideas are already implemented, because then no additional work is needed, and you can just support the right team.

But , you can understand that at that time HDD's and broadband speed were not the same as today .

Then, I have another question: why Satoshi didn't make it gradually? Why it was not "double the size of the block every halving" or any other "gradually increase the size of the block"? Today, we even have BIPs for that! If people around 2017 thought about it before implementing Segwit, then why Satoshi didn't code it in that way, and just made it constant?

Bitcoin isn't currently practical for very small micropayments.

How do you define "very small"? Is it millisatoshi in Lightning Network, that is never enforced on-chain? Or is it microsatoshi, nanosatoshi, or even smaller unit? Been there, done that. I had some channels with a friend, when we used CPU mining (with Merged Mining) to pay each other the smallest amount we could, proportional to the amount of satoshis in the coinbase transaction, scaled down to the minimal difficulty we produced. So yes, you can send someone a millisatoshi, or even smaller unit, as long as both clients support that feature. But of course, it doesn't change the fact that to enforce it on-chain, you need to pay quite high on-chain fee. Which is why testnet, or some separate network, fits better for such purposes, because then you can use zero satoshis to have any on-chain representation, and to actually push your millisatoshis on-chain (or wrap them into a multisig, and enforce on-chain by using a proper Script).

Also note that you don't need LN to enforce such things. The minimal fees for routing any transaction is something you can change in your node settings. You can accept free transactions into your mempool, but then be prepared to deal with spam somehow. Guess what: even today, there are still transactions flying around, with fees below one satoshi per virtual byte. They are usually used by mining pools, but you can build anything on top of that, if you have two nodes, which accepts more transactions than usual. But of course, to enforce microtransactions on-chain, you need some computing power, similar to what centralized mining pools already have. Or, if you don't want that, then you can send a lot of cheap transactions, and then batch them, and broadcast into official network. If you use a proper Script, you can do that without any trust, see 2P-ECDSA and Homomorphic Encryption for more details.

the road for hard forks open . If satoshi was against it , he wouldn't post such a thing , but would propose something in a backwards compatible way .

This is quite simple: Satoshi could do some hard-fork then, because the network was small enough. In fact, the current version is not fully compatible with the first version, because there were some minor changes here and there, for example some P2P messages were changed to include checksum, and the longest chain rule was changed into the heaviest chain rule in a hard-fork way.

But even if you assume that Satoshi was pro-hard-fork, then I have another question: do you think that Satoshi would do some hard-fork today, and ignore the miners? I don't think so. Even if we have Segwit and Taproot, then still, cleaning it up doesn't mean ignoring the miners, or reverting the chain. What happened, is already set in stone. So, you can change the code to disable Segwit or Taproot, but you cannot overwrite the history. But good luck creating a proposal to roll-back those soft-forks, and make those coins spendable by anyone. It will simply not happen.

Script is necessary for bitcoin to work as a network that apps and new type of transactions can be build upon .

Technically, you can start with P2PK, and add a Script later. There are no technical problems with that approach, and also, in this case you end up with a single address type, which is P2PK, and this could be good for privacy, because then you don't know, if something is a public key, or a Script, until it is spent. And also, in this case, users can try non-standard scripts, without risking their money, because then they can always spend by public key, if their Script will turn out to be non-standard or unspendable.

Also states " There are other things we can do if necessary" . What he meant by that ? Who knows .

It means "if fees will not be sufficient, then we can do something else to limit it further". If you think I just made it up from the thin air, then you can go to the link, and read the whole context. Also, again, as Garlo Nicon said, "you cannot beat something with nothing", which means if you think that my interpretation is wrong, then what is yours? Because your answer "I don't know" will not push us any further.

He doesn't explicitly states that using OP_pushdata4 is forbidden like you make it look like .

It is "forbidden" beyond 32 MiB, because he coded it in that way. And 32 MiB takes more than two bytes, which means you need at least four bytes, to handle it correctly. But guess what: he put 32 MiB as the limit, not 4 GiB.

And to put it another way , if he didn't want it he wouldn't have added it to OP's .

You cannot handle 32 MiB with three bytes. It is 0x02000000. It needs at least four bytes.

I also have another question: if you think that Satoshi didn't care about the size, then why he introduced VarInt to compress things? Why he stored difficulty by using four bytes, instead of using 32 bytes to store the target explicitly, with arbitrary precision?

[Wind_FURY]

I believe some of you might start going deeper into the argument for bigger blocks that you might also start to think Roger Ver and Bitcoin Cash made the right decision, and you might also start debating for Satoshi's original vision.

It really depends on what classifies as "right". Opinions fundamentally differ on block size policy.

Is it because it would also depend on what that person's definition of "scaling" is?

I'm actually now very curious. What is your definition or idea of how scaling Bitcoin should actually be? Because we might not have a common definition/idea, and that's where the issues start.

It's not just for BlackHatCoiner. I want to know everyone's definition/idea about scaling.

[vjudeu]

Is it because it would also depend on what that person's definition of "scaling" is?

Yes. I like that kind of approaching the problem, by the way.

What is your definition or idea of how scaling Bitcoin should actually be?

Scaling is directly related with compression. If you can use the same resources to achieve more goals, then that thing is "scalable". So, if the size of the block is 1 MB, and your "scaling" is just "let's increase it into 4 MB", then it is not a scaling anymore. It is just a pure, linear growth. You increase numbers four times, so you can now handle 4x more traffic. But it is not scaling. Not at all.

Scaling is about resources. If you can handle 16x more traffic with only 4x bigger blocks, then this is somewhat scalable. But we can go even further: if you can handle 100x more traffic, or even 1000x more traffic with only 4x bigger blocks, then this has even better scalability.

Also, scaling is directly related to intelligence. You can read more about Hutter Prize, which was advertized by Garlo Nicon some time ago: http://prize.hutter1.net/

I want to know everyone's definition/idea about scaling.

I will add a bonus question: how do you measure if your model is scalable or not? Write it as a function in big-O-notation, or anything you like. I support "constant-based scaling", which means O(1) scaling, which means leaving current resources as they are, and improving algorithms to build things on top of that, for example through commitments.

[oldkoin]

Scaling is about resources. If you can handle 16x more traffic with only 4x bigger blocks, then this is somewhat scalable. But we can go even further: if you can handle 100x more traffic, or even 1000x more traffic with only 4x bigger blocks, then this has even better scalability.

It's strange that you count the resources spent in bytes, in "virtual bytes". When all over the world, resources spent are usually assessed in monetary terms.

Now, thanks to the development of technology, a modern computer can process blocks of 10 MB in size without problems and without significant additional costs. (It's time to record this fact and not come back again)

And it turns out that simply by rewriting the code, we can increase the capabilities of the system, which is now valued at ~$700 billion, by 10 times. I repeat, just rewriting the code.

Evaluate the ratio of the results obtained to the resources spent. Isn't this ideal scaling?

[vjudeu]

It's strange that you count the resources spent in bytes, in "virtual bytes". When all over the world, resources spent are usually assessed in monetary terms.

Testnet can handle exactly the same bytes, with exactly the same hardware, but those coins are worthless. Does it mean that we should take the current price of Bitcoin in dollars, and base our scalability on that? Because guess what: 1 BTC is worth 1 BTC. If you want to measure it "in monetary terms", then you have to use a price, relative to altcoins, or to fiat currencies (for example USD), or to goods and services you can buy with that (for example food). Is this what you want? Do you want to measure for example fees in dollars to decide, if the price is too high or not?

[oldkoin]

It's strange that you count the resources spent in bytes, in "virtual bytes". When all over the world, resources spent are usually assessed in monetary terms.

Testnet can handle exactly the same bytes, with exactly the same hardware, but those coins are worthless. Does it mean that we should take the current price of Bitcoin in dollars, and base our scalability on that? Because guess what: 1 BTC is worth 1 BTC. If you want to measure it "in monetary terms", then you have to use a price, relative to altcoins, or to fiat currencies (for example USD), or to goods and services you can buy with that (for example food). Is this what you want? Do you want to measure for example fees in dollars to decide, if the price is too high or not?

Did I understand correctly that you are trying to refute that costs are measured in money? There is nothing much to comment on here.

"1 BTC is worth 1 BTC"
OK. Let's calculate in BTC. How many bitcoins do you currently need to rewrite the code? Let’s estimate it at 1000btc. I won't be much mistaken.  Total bitcoins are ~19 million.

Spend 0.0053% of system cost to scale the entire system by 10x. Is this a good scaling?

[garlonicon]

Spend 0.0053% of system cost to scale the entire system by 10x. Is this a good scaling?

Go on, give it a try. Or find somebody, who thinks in the same way, and encourage that person into coding it. Or maybe you already did it? If so, where can I download the client?

If you want to ask me the same question, then sidechains can be downloaded here: https://www.drivechain.info/
But because they were rejected as a soft-fork, I am trying to create something else.

[BlackHatCoiner]

Is it because it would also depend on what that person's definition of "scaling" is?

I'll have to agree with vjudeu's definition of scaling, even though I'd endorse a block size increase which is based on a studied rationale.

It is just a pure, linear growth.

Sure, but why is linear growth necessarily bad? You need a linearly grown basis to base your compression model later on.

But because they were rejected as a soft-fork, I am trying to create something else.

What was the reasoning of this rejection? And by whom were they rejected?

[vjudeu]

Sure, but why is linear growth necessarily bad?

Note the difference between being "bad" and being "non-scalable". It is only non-scalable, it doesn't mean it is bad, it only means you cannot call it "scaling", because it has exactly the same scale. Unless you think that 1:1 scale is something entirely different than 10:10 scale or 100:100 scale.

You need a linearly grown basis to base your compression model later on.

Why later, and why not now? Is compressing 4 MB somehow different than compressing 32 MB? In the end, if you want to talk about scaling, you will still express your compression in percentage, or in the number of total bytes used, if your initial size is constant.

Also note that signatures are easier to compress than arbitrary data, because you can add public keys, and it is cryptographically equivalent, while you cannot losslessly drop data chunks in the middle, because then you lose that data. Which means, Ordinals are hard to compress, while signatures are easier to compress. Which also means, regular signatures should be compressed, and Ordinals should be left as they are. In this way, regular users could get any way to defend themselves, when fees are too high.

What was the reasoning of this rejection?

There were many different reasons. You can read the mailing list, or read topics like that: https://bitcointalk.org/index.php?topic=5231460.0
Maybe I will add something more, is this is not enough, but maybe not in this topic.

And by whom were they rejected?

By some of the mailing list participants, and code reviewers, of course. Also, I can look for more details, if you need them, but maybe not in this topic, because as you can see above, there were some other topics about sidechains, and they probably fit better.

Also, maybe "rejected" is a too strong word. Some people could argue, that they were "postponed" or "paused, and sent back to fix some points". It depends, who you ask, because this is how decentralization works: different people will tell you different things, and maybe a better way to say that is "those specific, and submitted BIPs, related to sidechains, failed to reach consensus (yet)".

[alani123]

Many people keep bringing the results of this poll as a way of saying that the community is divided.

First off, bitcointalk polls receive anonymous responses from any account so don't take them too seriously.

But even as a pointer, I don't think it shows any division. If anything, these results show that the discussion has matured a lot since 2015 and the community has grown a lot:



The environment was very hostile in these years circa the "block size wars" because many had jumped on the opportunity to profit against BTC itself by forking off to their own coins and whatnot.
Long time has passed since then and most of these altcoins are no longer relevant. So to me this vote indicates progress.
If a sound solution to scaling was to be proposed now it would probably receive better level headed discussion.

[franky1]

The environment was very hostile in these years circa the "block size wars" because many had jumped on the opportunity to profit against BTC itself by forking off to their own coins and whatnot.

If a sound solution to scaling was to be proposed now it would probably receive better level headed discussion.

nah, looking at the comments of those against it, they still wouldnt see it as a bitcoin proposal but a REKTing opportunity to suggest the proposal should altcoin fork itself independently so nothing changes to bitcoin but the objectors get a free airdrop
in their mind. if its not core coded its an altcoin airdrop

[stwenhao]

if its not core coded its an altcoin airdrop

If it would be "core coded", then there is a risk, that some other people would still maintain the old version, and users would land on that, because they were taught about backward-compatibility, and a lot of people believe in that. Which means, if anyone (including "core") would try it, then they could reach the same fate as BCH.

Also note what happened with ETH: they did a hard-fork, and the community splitted into ETH and ETC. Here, it could be the same outcome, but there is no guarantee, that the "core coded" version would have the same fate as ETH, and not ETC. It is unknown, until it happens, but then it is too late to change sides. By the way, ETH, as well as many other altcoins, could create so much hard-forks, only because users were used to it. By doing that on BTC, some people could consider "it is not the true core anymore", and form their own team, maintaining the old version. And guess what: the community, used to soft-forks, could then follow them, instead of following "the core, which behaves differently than in the last N years".

What are your thoughts on increasing bitcoin's block capacity? (please explain in response)

I am for it

The reason is quite simple. If you don't want bigger blocks, then tell me, what should I use instead, here and now, when fees are high, and will be higher soon? So far, I simply cannot see a better solution. And I guess, when fees will be higher, then you will see more people, complaining about it on forum. And what are you gonna tell them? To use some altcoin, because Bitcoin cannot solve its own issues, and is not ready for world-wide adoption? Good luck with bringing new users with that approach.

[franky1]

if its not core coded its an altcoin airdrop

If it would be "core coded", then there is a risk, that some other people would still maintain the old version, and users would land on that, because they were taught about backward-compatibility, and a lot of people believe in that. Which means, if anyone (including "core") would try it, then they could reach the same fate as BCH.

older nodes with no block reject fee priority added code. wont reject blocks they will just "assumevalid" as the backward compatible trick assumes .. . they would continue to accept blocks that upgraded full nodes accept and relay.. no harm, no difference.. it would be for the upgraded and consensus activated nodes(economic nodes mainly have power these days) to be the full validators.
so it still fits the "backward compatibility"
and doing the activation much the same way as the NYA mandatory threat did. force mining pools to comply or the economic nodes will reject blocks (but reject in this case if they dont check for priority. )

yes im suggesting using the tricks core already set precedent in using. just in a way that benefits the majority of the community..

..
i wont be surprised if the "fee war" loving crowd dont take this idea and suggest core do the opposite, and instead starts making nodes reject confirmed blocks if the fees are not above Xbytes/sat based on a arbitrary politic set number to push fees higher.. its the kind of thing they would love.

[Sarah Azhari]

Please share your thoughts below.

If developers get hard work to increase network capacity to accommodate rubbish and shitcoin, I'm of course against it. Bitcoin network is fine so far, I can even send with a fee of 1 satoshi before the network is littered with rubbish. I have no problem with altcoins even if they use and create another network. But if that altcoin use the Bitcoin network just to show up and marketing the product, I think that's gone too far. As far I know, The new altcoin is use various methods to sell his product, ICO, IEO, and etc. Now, they sell altcoins in the shadow of btc. They use that methode, so that buyers think all that altcoin is part of BTC (because inside on BTC network).

[pooya87]

Also note what happened with ETH: they did a hard-fork, and the community splitted into ETH and ETC. Here, it could be the same outcome, but there is no guarantee, that the "core coded" version would have the same fate as ETH, and not ETC. It is unknown, until it happens, but then it is too late to change sides.

Lets never use centralized shitcoins as examples when it comes to discussing bitcoin. Things are very different. And by the way Ether guys didn't just do a hard-fork, they rolled back blocks which means they targeted a fundamental principle of cryptocurrencies which is their immutable blockchain which is why part of the network decided to stick to immutability (ie. ETC).

[DooMAD]

to stand up to game theory.  If there are ways to manipulate or rig the system to an outcome which suits an attackers goals, then it's no good.  We can't inadvertently introduce that kind of weakness.

Friendly fire! Friendly fire!, lol. Are we still talking about future upgrades here? Because despite my lack of understanding about the entirety of taproot, I am pretty much certain that what you just described is happening right now, I swear I'm not lying or trolling, you can check to see those orange blocks turning to red and are about to explode on mempool.space.

Fair point.  Even when it seems like every reasonable precaution has been taken, there can still be unforseen consequences.  Clearly no one saw this current situation coming.  Part of the concept behind Taproot was to assist with scaling, signature aggregation, etc.  But someone found a way to exploit it to create a way to upload crap and molest mempools.  Every advancement leads us into unexplored territory, but it's still worth taking every reasonable precaution.  Even if there are no guarantees someone won't immediately look for a way to abuse the change.

People think it's easy and that devs are moving too slowly, but it doesn't always dawn on them that a few individuals with selfish interests can be a massive drain on shared communal resources.  It's incredibly challenging to advance the technology in a way that doesn't give such individuals too much room to screw about, but also keeps doors open in terms of future developments.  It's a fine line to tread.

[franky1]

Clearly no one saw this current situation coming.  

funny part is i was having lengthy debates with gmax and others in 2016 about the exploit-ability of "anyonecanspend" (unconditioned opcodes).. it is funny how things come full circle where core gods and their cult followers lie, deceive try to deny things to push their agenda using tactics that the person on other side of debate is lying and deceiving

because yea, data in the blockchain and time.. proves whos right in the end. not the circle jerkin of cultish social games

ive been highlighting the abuse of opcodes creating "FUNKY" transactions without conditions even before segwit activated, when they proposed using opcodes in this manner

for posterity (2016)

Yes, but only for spending from an output of the type OP_0 <20 bytes> or anything similar. The witness data must still be in the transaction when you are spending from an output that has anything like OP_CHECKSIG in the output script.

old clients wont check whats after 0x00(op_0).. they automatically treat the transaction as valid.

again the signatures are not in the same expected area. segwit abuses 0x00 to achieve this. thats the whole point of how segwit can work as a softfork!
because the signatures are not where they are expected. old clients treat it as just a valid funky tx.

the 20 bytes after 0x00 (op_0) are not going to be what old clients expect to see. yet they would automatically look passed it, without care.

i think you are blindly trusting the dev's to make pretty code with zero bugs. instead of thinking with a critical mind that things can break and to think that its better to have a things might break mindset rather then a devoted faith that it will elegantly work. because blind faith is the mindset of people who wont bug check/hack it to its limits. they will just do a couple standard transactions and praise their lord that funds move.. rather than trying to break it

come on.. the code is not even released and ur already thinking its perfect..

real that last line 5 times. let it settle in your head. and think about the mindset you have.
even scientists who spend years developing space rockets, still end up with them blowing up.

'funky tx'
'look passed it, without care'


again 2016

secondly. legacy(old) nodes wont benefit from it. also old nodes will have more issues to contend with. such as seeing 'funky' transactions. aswell as still not being able to trust unconfirmed transactions due to RBF and CPFP.

...

just checking the blockchain history. how often has a legitimate transaction actually required lots of signatures to the extent of causing issues.
the funny thing is limiting transactions sigops actually ensures that we never get a situation where one person can fill a block alone..
but instead, not limiting transaction sigops and just making it fast to process. along with offering a discount on signatures, actually makes it easier, cheaper and more rewarding for someone to spam the block with a single transaction. yea it wont cause network delay. but still causes the community to get peed off that someone is filling the block with one transaction.
limiting sigops was/is the obvious route that should have been taken.

and here we are 7 years after talking about the risks. we are seeing the consequences.. and again we are seeing a group of idiots pandering to the core gods saying "lets do nothing it will sort itself out, go back to sleep, dont argue unless you have a inside track to core. something core will accept"

[DooMAD]

Clearly no one saw this current situation coming.  

funny part is i was having lengthy debates with gmax and others in 2016 about the exploit-ability of "anyonecanspend" (unconditioned opcodes).. it is funny how things come full circle where core gods and their cult followers lie, deceive try to deny things to push their agenda using tactics that the person on other side of debate is lying and deceiving

because you, data in the blockchain proves whos right in the end.

Congratulations, one of your hundreds of Chicken Little "Sky is falling!" cries turned out not to be 100% wrong.  Have a cookie.  Purely by the law of averages, even a fruitloop like you has to get it right once in a while.  Don't let it go to your head.

You made a valid point.  This does not mean your vision for scaling is suddenly the correct one (mainly due to the fact it doesn't even meet most people's definition of the word "scaling").

[franky1]

wait you say "100 chicken littles"..
i thought you said i keep mentioning one big thing....

ever thought that its actually more like 3 flaws all linked by the same central point of failure.. in which actual block data, code statistics show are actually 3 flaws that are showing their repercussions now

as for scaling
YOUR cult family (mentored by you) keep pretending scaling is GIGABYTE blocks or offboarding/forking to other networks .. no. thats not scaling. thats exaggerated leaping and displacing

you keep trying to lie by pretending my opinion is some altcoin fork "bigger(massive) block" you keep pretending and inciting your cult family to recite your mantra that franky only wants "bigger blocks"

you actually ignore what i actually say. so here it is again. dumbed right down to a short summary even you might have no problems reading in 20 seconds

and its not just "bigger blocks" its actually
leaner transactions.
count every byte, make every byte count
condition all transaction formats to perform, whereby every byte serves a purpose.
limit the transaction overhead computationally
make spammers/bloaters personally penalised to not cause everyone to be expensed out of using bitcoin
penalise spammer/bloater by enough of a multiple that they actually stop due to the expense

ive also made MANY posts over 7 years of this debate not about bigger blocks=gigabyte blocks(your cultish groups story of the 'core opposing offer')
but about blocksizes that increment over time/need

[DooMAD]

as for scaling
YOUR cult family (mentored by you) keep pretending scaling is GIGABYTE blocks. of offboarding/forking to other networks .. no. thats not scaling. thats exaggerated leaping and displacing

*SIGH*

How is this not abundantly apparent to you yet?

Off-chain doesn't have a strict limit.  On chain does.  Whatever you set the on-chain limit to be, no matter how many times you increase it, the off-chain throughput always has the potential to be greater.  That's scaling.
LInear growth isn't.  And that's why we talk about gigablocks.  Because off-chain can easily handle the volume that gigablocks would theoretically enable, but without the accompanying risk to decentralisation.

If you still aren't able to grasp this after 7 years, please read more and talk less.

And before you cry too hard, yes, we can have *some* linear growth.  But if you think that's the only thing we should be doing, you are very much mistaken.

[franky1]

Off-chain doesn't have a strict limit.  On chain does.  Whatever you set the on-chain limit to be, no matter how many times you increase it, the off-chain throughput always has the potential to be greater.  That's scaling.
LInear growth isn't.  And that's why we talk about gigablocks.  Because off-chain can easily handle the volume that gigablocks would theoretically enable, but without the accompanying risk to decentralisation.

If you still aren't able to grasp this after 7 years, please read more and talk less.

doomad talks about leaping again (facepalm)

And before you cry too hard, yes, we can have *some* linear growth.  But if you think that's the only thing we should be doing, you are very much mistaken.

and only talks about blocksize rather than increasing tx count via uncludging the current code that causes spam/bloat allowed to occur

he really is stuck in his head thinking the only option that deviates away from core roadmap is "gigabyte blocks" where he then pretends its all other people talk about.. when infact its the only thing his group keep circling back to

also i said many times in many topics that the option is not just "bigger blocks" (doomads group mentorship campaign of "gigabyte blocks")
subnetworks (not current flawed ones) .. wait ill emphasise this:
future subnetworks that have purpose without flaws will have utility for their niche userbase.. but .. and i sincerely want you to take time to read this.. BUT. telling everyone to abandon bitcoin and offramp to a shady, screwed up current flawed subnetwork is not the solution

and with bitcoin blocks SCALING not leaping. to cater to those that want and need secure bitcoin confirmations and settlements. more utility can be provided to the community.. and before you check your old cult notes.. my opinion on scaling is not just bigger blocks.. as i summarised and dumbed down for you in previous post

try to read

responding to below
im not the one promoting people to offramp to subnetworks or fork to an altcoin as the solutions .. YOU ARE

edit again to respond
it can be both
YOU are offramping USERS..   and bitcoin doesnt leave the blockchain
USERS use another network to play with IOU units(borrowing unit transfer of routed middlemans balance) called millsats. millisats that sit in channels but are not settled bitcoin of the "promised"(pfft) recipient
bitcoin does not leave the blockchain, the the security of it

[DooMAD]

future subnetworks that have purpose without flaws will have utility for their niche userbase.. but .. and i sincerely want you to take time to read this.. BUT. telling everyone to abandon bitcoin and offramp to a shady, screwed up current flawed subnetwork is not the solution

and with bitcoin blocks SCALING not leaping. to cater to those that want and need secure bitcoin confirmations and settlements. more utility can be provided to the community.. and before you check your old cult notes.. my opinion on scaling is not just bigger blocks.. as i summarised and dumbed down for you in previous post

try to read

Stop writing everything like an extremist zealot and maybe your posts might be worth reading for once.

No one (other than you), is suggesting that people "abandon bitcoin", but in your fucked up zealot brain, that's what off-chain means to you.  So we're never going to find common ground.  If you can't have a mature discussion about this, then it's quite simple.  No one is going to listen to you.  Now try again and write something that could pass for the writings of a sane person.

Last chance.


//EDIT:  Responding to above:

responding to below
im not the one promoting people to offramp to subnetorks or fork to an altcoin as the solutions .. YOU ARE

If you want to maintain the ridiculous logical fallacy that bitcoins never leave the blockchain, but we're somehow simultaneously "offramping" users, then clearly you're taking a preposterous and impossible position.  

Either the funds don't leave the blockchain -or- we're offramping users.  It literally can't be both.  Now pick a shade of stupid and STFU and let the grown-ups talk.  It's utterly futile trying to engage with any kind of reasonable discussion with you.  Irrational twunt.


//EDIT AGAIN:

And even if you got what you claim you want, "lean transactions" and a totally locked-down, autocratic chain where users have no freedom and there's no witness space, just an even 4mb for all.  That volume of throughput still pales in comparison to what off-chain can offer.  Without off-chain, there would still be a finite capacity and once we grow to reach that capacity, you'd be asking for another increase.  Because you have literally nothing else to offer.  Gigablocks isn't what you're asking for now.  It's your long-term plan because you have no other plan.  Prove me wrong.

[franky1]

And even if you got what you claim you want, "lean transactions" and a totally locked-down, autocratic chain where users have no freedom and there's no witness space, just an even 4mb for all.  That volume of throughput still pales in comparison to what off-chain can offer.  Without off-chain, there would still be a finite capacity and once we grow to reach that capacity, you'd be asking for another increase.  Because you have literally nothing else to offer.  Gigablocks isn't what you're asking for now.  It's your long-term plan because you have no other plan.  Prove me wrong.

your mindset is LEAP to gigabyte blocks. then YOUR mindset is do nothing now because (in YOUR VIEW) gigabyte cant be handled now

you forget SCALING is not "gigabytes by 2024" so just stop with that rhetoric
also you keep promoting a CRAP subnetwork as the sole solution available today

YOU keep promoting that bitcoin should not do anything, should not scale BITCOIN until YOUR favoured crappy subnetwork populates to mass adoption. and then only scale BITCOIN when bitcoin cant cope with your favoured subnetworks session gates(opens/closings)

we have all read your preferences of getting everyone to use subnetworks and "dont buy coffee/pizza on bitcoin"
we have all read your preferences of telling anyone not core to not ask core to offer community benefits on the bitcoin network
we have all read your preferences of telling anyone not core. to not 'attack' the network and instead create a fork altcoin and see who follows

you dont want bitcoin network to scale because you are deeply entranched into promoting people move over to your preferred subnetwork
you dont want reasonable fee's on bitcoin because it screws up your middleman commission syphoning of the subnetwork strategy

i am not saying a new bunch of subnetworks without flaws wont have niche utility . but telling the community to do nothing for 6 years "coz LN" has not been helpful to scaling BITCOIN.. and we are seeing the repercussions of doing nothing for 6 years

as for your silly narrative that you mention about risks to decentralisation, you love cores central point existence
your other adorations:
backward stripped blocks nodes centralise a more concentrated group off less full nodes(with full archival, full verification, full IBD peer services)
pruned nodes centralise a more concentrated group off less full nodes(with full archival, full verification, full IBD peer services)
fee market causes less people to transact daily onchain so dont need/want to run a node 24/7, concentrating a less amount of 24/7 full nodes
users using subnetworks and now subnetwork litewallets like greenlight. also removes usecases to want/need to be a full node

as for your silly narrative of exaggerating "node cost"
if hardware costs of a full node are $400 for historic AND next 4+ years... but a tx fee is $20
you are saying the 'cost' that people should only transact 20 times in 4 years (if $400 is too expensive in your mind for 4 years)
5 transactions a year is not a reason to motivate someone to be a full node 24/7
the real problem of COST is not hardware.. but fees... but you love high fee's becasue it promotes the abandonment of using the bitcoinnetwork in favour of your preferred subnetwork

if you are also saying people should lock their BTC up on bitcoin network. and play with hub created channel balance on subnetwork and not settle for 3 months.. again why would they want to be a full node.

all of your preferences are not in the aid of decentralising the blockchain or the auditing of the blockdata. especially when you love to keep features that bypass verification of all bytes of the blockchain..
we all see your motivations of 'dont enhance bitcoin, instead promote LN' is the promises they made that you can syphon fee's as a router middlemen from other users..
now here is 3 questions:
how has that paid off for you?
has LN gave you a sustainable living?
or has all your time/promotions just been an empty promise?

[DooMAD]

we all see your motivations of 'dont enhance bitcoin, instead promote LN' is the promises they made that you can syphon fee's as a router middlemen from other users..
now here is 3 questions:
how has that paid off for you?
has LN gave you a sustainable living?
or has all your time/promotions just been an empty promise?

Oh, you're going to love this...  

With the notable exception of consolidating some small inputs by sending transactions to myself, I personally haven't sent a single Bitcoin transaction from any of my wallets in at least 5 years now.  I'm a HODLer.  I receive payments.  I don't generally send them.  And because I don't need to send transactions, I currently don't have any need to run a Lightning node.  Although I'd still like the option to do so in future, when the need does arise.  

So there it is.  You've spent years claiming like a loon that I've somehow been "earning middlemen fees" and that everything I say or do is somehow meant to enrich myself, but I guess we'll just add that to the list of your many, many delusions and the number of times you couldn't be more wrong about something if you tried.  

I'd be earning money from my sig campaign whether I agreed with you or not, so I don't get paid to promote anything other than the services appearing below my posts.  I only continue call you a moron to your face because I genuinely feel that's what's best for the overall benefit of the Bitcoin network.  Because you're a dangerous, unhinged whack-job and your ideas are terrible.  

Is there anything else I can answer for you while we're at it?  I've love to point out more things where you've been making a total fool out of yourself for years by talking out of your arse because you actually don't have a clue about anything.

And even if you got what you claim you want, "lean transactions" and a totally locked-down, autocratic chain where users have no freedom and there's no witness space, just an even 4mb for all.  That volume of throughput still pales in comparison to what off-chain can offer.  Without off-chain, there would still be a finite capacity and once we grow to reach that capacity, you'd be asking for another increase.  Because you have literally nothing else to offer.  Gigablocks isn't what you're asking for now.  It's your long-term plan because you have no other plan.  Prove me wrong.

you forget SCALING is not "gigabytes by 2024" so just stop with that rhetoric

I don't see how it's a rhetoric if you seriously have no other proposals and you're just going to propose the same thing over and over again.  I'll ask once more to see if you dodge the question again like a spineless coward:  

Imagine you had no SegWit, no off-chain stuff you hate, 4mb regular blocks, lean transactions, all the shit you've been screeching about (and let's put aside that if such a network existed, its throughput would be a drop in the ocean compared to what off-chain could provide).  Imagine all the devs listened to you and didn't ridicule you for being an absolute headcase.  You're in charge.  Once we are using all of that blockspace as efficiently as we possibly can, what's the next genius step from the great franky1?  

Go on.  Tell us.  Don't be shy, now.  It's your opportunity to prove you grasp the concepts of scaling and that we should all show you more respect.  Surely your response is going to be amazing...

(Watch him dodge the question again)

[franky1]

we dont need "gigabytes now"
you pretend we do

we dont need LEAPS..
you pretend we do

learn about SCALING.. stop insinuating LEAPING..  learn the difference that LEAPING is not scaling. do you atleast concede in realising that fact of basic concepts..

the options are not 2
a. gigabyte leap
or
b. LN

the scaling debate is more nuanced then that, progressive with multiple options

anyways.. your question scanerio(the 1mb lean vs 4mb lean full space utility scenario, and what to do after):
2009- 2016 1mb was (as satoshi wrote in 2010 allowing "upto 4200tx a block")
so 4mb would be 16800tx a block

yes we are congested at a <4k tx a block(but with 4mb. but not getting the 4x tx count).. so for now scaling to allow 6k 12k 16k to become 4mb full utility block would have been SCALING of the last 6 years

instead we got 4MB 6 years ago.. but not the 16k transaction ability fo that 4mb.. we are still not even above satoshis own math of the 4200tx a block average of 1mb

now read closely
if we did have a full utility 4mb block to allow upto 16ktx that would be scaling.. compared to the 1mb tx count averages

when 4mb 16k lean tx causes longterm congestion in the future.. we SCALE again..

but wait.. really try to read this.. take a couple minutes to prepare yourself to read this:
i said SCALE. meaning not dramatised/exaggerated LEAPS to 1gb
let me say it again. not LEAPS to 1gb
but scaling to a new blocksize. EG 8mb-16mb blocks

even you must realise periodic SCALING where by the time we get to 16mb blocks a 4 year PC lifecycle is only 3.4gb of added data.
the cost of a 20TB hard drive would be the cost of a 4TB hard drive now. meaning affordability

you keep pretending 1gb per block is needed now insinuating todays PC's needed 210TB hard drives now to do doomads version of "scaling".. THEY DONE, WE DONT


as for the other crap "LN is solution to scaling" .. and about subnetworks(plural)
i knew you had no clue about real experience of LN you were just reading the utopian promotional material.. that much was obvious. but i do find it strange you dedicate 6 years of your trolling to promote something you dont use but want other people to use.

i guess you were just hoping some day LN devs would notice your promotions and put you on the pay roll.. i kinda feel sorry for you now, realising you were an trolling unpaid promoting a product but gaining nothing from it.. that must hurt. all that effort you put into ass kissing LN and the dev team for nothing.

anyways
seeing as your not contracted to troll for them.. have you ever had a thought about a fresh subnetwork without the LN flaws.. are you open to that idea to have a subnetwork to fill the niche of a subset of users that want subnetworks for subclass of utility,, but without it being LN specifically .. or are you still stuck on only idolising the utopian (broken)promises of LN

[DooMAD]

if we did have a full utility 4mb block to allow upto 16ktx that would be scaling.. compared to the 1mb tx count averages

when 4mb 16k lean tx causes longterm congestion in the future.. we SCALE again..

That's all I needed to hear.  We have nothing further to discuss.  You have openly stated that linear growth is the same as scaling (it isn't) and you would do it over and over again because there are no other thoughts in the space between your ears where the brain is meant to be.

Welcome to my ignore list.  I've debunked as much of your shit as I care to.

I strongly encourage others to do the same.  Do not listen to a single thing this absolute shitweasel says.  He will lead you down dangerous paths and will take away your freedom the moment you let your guard down.  Do yourself and the forum a favour and add him to your ignore list.

[franky1]

and you think zero onchain growth is SCALING
and you think huge leaps is SCALING
but you dont think progressive adjustments is scaling.
(facepalm x3)

i also said it is not just about the blocksize. its more nuanced.. but you prefer ignorance rather then understanding. so go back to being ignorant.

as for freedoms
doomad loves to get people banned.
doomad loves to get OTHERS to lock their funds with custodian services for channel hopping via hubs, or mixing via middlemen. even if he doesnt use it himself he wants other to suffer the risks of their freedom/control of their value. he doesnt want people to have the freedom to transact reasonably onchain he loves censoring and voiding transactions unless people pay premiums

i do honestly feel sorry for him.. putting all that effort in for years but not even getting a kiss back from those he promotes

[pooya87]

Clearly no one saw this current situation coming. 

funny part is i was having lengthy debates with gmax and others in 2016 about the exploit-ability of "anyonecanspend" (unconditioned opcodes).. it is funny how things come full circle where core gods and their cult followers lie, deceive try to deny things to push their agenda using tactics that the person on other side of debate is lying and deceiving

because you, data in the blockchain proves whos right in the end.

Congratulations, one of your hundreds of Chicken Little "Sky is falling!" cries turned out not to be 100% wrong.  Have a cookie.  Purely by the law of averages, even a fruitloop like you has to get it right once in a while.  Don't let it go to your head.

Actually the thing he quoted has nothing to do with this topic and the example chosen in that comment is actually wrong and the silliest one since P2WPKH (ie. OP_0 + 20 bytes) is literally the strictest SegWit scripts that exists and there is absolutely no way of exploiting it.
The part with "anyonecanspend" nonsense that was raging on back in (mostly) 2017 is also not a valid argument since we have been using this technique since BIP16 (over a decade ago) with P2SH and "old clients" can not see that or verify that either.

[Wind_FURY]

Is it because it would also depend on what that person's definition of "scaling" is?

Yes. I like that kind of approaching the problem, by the way.

What is your definition or idea of how scaling Bitcoin should actually be?

Scaling is directly related with compression. If you can use the same resources to achieve more goals, then that thing is "scalable". So, if the size of the block is 1 MB, and your "scaling" is just "let's increase it into 4 MB", then it is not a scaling anymore. It is just a pure, linear growth. You increase numbers four times, so you can now handle 4x more traffic. But it is not scaling. Not at all.

Scaling is about resources. If you can handle 16x more traffic with only 4x bigger blocks, then this is somewhat scalable. But we can go even further: if you can handle 100x more traffic, or even 1000x more traffic with only 4x bigger blocks, then this has even better scalability.

Also, scaling is directly related to intelligence. You can read more about Hutter Prize, which was advertized by Garlo Nicon some time ago: http://prize.hutter1.net/

You, ser, are correct! In the context of Bitcoin, real actual scaling should be defined as, "increasing network throughput, without sacrificing decentralization". - That's probably where the problem is, because different people in BitcoinTalk have different definitions of "scaling". But to many, it merely means increasing the block size.

I want to know everyone's definition/idea about scaling.

I will add a bonus question: how do you measure if your model is scalable or not? Write it as a function in big-O-notation, or anything you like. I support "constant-based scaling", which means O(1) scaling, which means leaving current resources as they are, and improving algorithms to build things on top of that, for example through commitments.

If that question is just for me, then you're asking the wrong person. Although I would like to read the posts of the smarter users in the forum, to learn and get some insight.

[ABCbits]

--snip--

You, ser, are correct! In the context of Bitcoin, real actual scaling should be defined as, "increasing network throughput, without sacrificing decentralization". - That's probably where the problem is, because different people in BitcoinTalk have different definitions of "scaling". But to many, it merely means increasing the block size.

But don't forget technology continue to progress, so increasing block size doesn't always mean sacrificing decentralization.

[apogio]

But don't forget technology continue to progress, so increasing block size doesn't always mean sacrificing decentralization.

Of course, but it seriously depends on where you live. Unfortunately some people live in countries that don't advance in the same pace. Meaning that poverty is too high to be able to cope with the technological progress...

[franky1]

Clearly no one saw this current situation coming.  

funny part is i was having lengthy debates with gmax and others in 2016 about the exploit-ability of "anyonecanspend" (unconditioned opcodes).. it is funny how things come full circle where core gods and their cult followers lie, deceive try to deny things to push their agenda using tactics that the person on other side of debate is lying and deceiving

because you, data in the blockchain proves whos right in the end.

Congratulations, one of your hundreds of Chicken Little "Sky is falling!" cries turned out not to be 100% wrong.  Have a cookie.  Purely by the law of averages, even a fruitloop like you has to get it right once in a while.  Don't let it go to your head.

Actually the thing he quoted has nothing to do with this topic and the example chosen in that comment is actually wrong and the silliest one since P2WPKH (ie. OP_0 + 20 bytes) is literally the strictest SegWit scripts that exists and there is absolutely no way of exploiting it.

incorrect.. because there is no expectation of content in op_0
remember op_0 was not a strict segwit script.. because.. 2016... yep segwit wasnt even a thing!!

back then they had buzzwords for them  empty opcode, called nops, nulls.. these days for the new subclass of opcodes of segwit and then the next subclass of opcodes for taproot they buzzword names like opsuccess
LEARN THEM, learn what they do and dont do

anyways
the very next bytes you can put in a op_0 is op_push4 which say the next bytes after that can be 4,294,967,295‬ bytes(4.29GB) which are only prevented by the block limit to not actually be 4.29gb
also multisig did not use op_0 it used other operation bytes..

so it can be abused in so many ways due to its openness at the time of writing it in 2016

seems doomad and pooya have rejoined each other in the cultish narrative of merit circle jerkin and defending each other again, to prevent bitcoin scaling by not even knowing about the code or exploits that are causing the congestion that is not helping bitcoin have lean transactions or increased transaction counts

but let them pat themselves on the back merit cycling each other while not wanting to learn how things really work

i can literally hear it now, them high fiving each other shouting "Got-em'" but not realising they just proved they dont even know about the opcodes or the abuse the openness of the opcode caused by the stuff it allowed.. so give each other a pat on the back for proving you didnt know what your talking about.

it doesnt pay to learn from each others idiocies,, it pays to actually learn bitcoin. doomad already proved he cant earn an income from having blind adoration and just repeat what they told him.

so dont waste your time circle jerking things you dont know, and take the time to learn bitcoin

[HmmMAA]

Of course, but it seriously depends on where you live. Unfortunately some people live in countries that don't advance in the same pace. Meaning that poverty is too high to be able to cope with the technological progress...

There are people on the planet ( close to 50% ) that have no pc or internet access . Does that mean that the network should stop because of that ? In case you are running a node , because someone else hasn't that comfort does it mean that you should stop having one too ? If we have to follow a standard let's follow the one of the most vulnerable and quit using our pc's or phones . That would be the most fair .
I really don't get this logic .  

[apogio]

I really don't get this logic .   

There are many people who don't share the same logic that I do and it is totally fine.

There are people on the planet ( close to 50% ) that have no pc or internet access . Does that mean that the network should stop because of that ?

The network shouldn't stop. No! However, the inspiration was that everyone should be able to run a node.

To this extent, I think increasing the block size a little will not hurt, but I am against it because it will not solve the "problem" on the long run.

In case you are running a node , because someone else hasn't that comfort does it mean that you should stop having one too ?

I didn't say that. If someone doesn't have the comfort to run a node, it doesn't mean I will stop running a node. I will, however, keep the blocksize low, so that I don't make it even more difficult for them to run a node.

[franky1]

I really don't get this logic .  

There are many people who don't share the same logic that I do and it is totally fine.

There are people on the planet ( close to 50% ) that have no pc or internet access . Does that mean that the network should stop because of that ?

The network shouldn't stop. No! However, the inspiration was that everyone should be able to run a node.

To this extent, I think increasing the block size a little will not hurt, but I am against it because it will not solve the "problem" on the long run.

In case you are running a node , because someone else hasn't that comfort does it mean that you should stop having one too ?

I didn't say that. If someone doesn't have the comfort to run a node, it doesn't mean I will stop running a node. I will, however, keep the blocksize low, so that I don't make it even more difficult for them to run a node.

thats what "scaling" is for rather then "LEAPING"
just saying no is not the solution to LEAPING.. scaling is the solution to leaping

also SCALING is about the long run.. its not about the high-jump.. (two different sporting events)

dont be fooled into disregarding progress via scaling..
dont be fooled by trolls talking about the high jump when rational people are talking about the long run

[apogio]

thats what "scaling" is for rather then "LEAPING"
just saying no is not the solution to LEAPING.. scaling is the solution to leaping

also SCALING is about the long run.. its not about the high-jump.. (two different sporting events)

Unfortunately, I don't follow you. I will quote myself:

To this extent, I think increasing the block size a little will not hurt, but I am against it because it will not solve the "problem" on the long run.

I don't want to increase the blocksize "just a little" because in my opinion it will not solve the issue.
I don't want to increase the blocksize "a lot" because of the reasons I have already mentionned.

So I don't want to scale, leap, high-jump, run, dive or do any sporting event.

If the blocksize scales "a little", I will accept it, even though I disagree.
If the blocksize scales "a lot", I am leaving.

So simple!

[franky1]

thats what "scaling" is for rather then "LEAPING"
just saying no is not the solution to LEAPING.. scaling is the solution to leaping

also SCALING is about the long run.. its not about the high-jump.. (two different sporting events)

Unfortunately, I don't follow you. I will quote myself:

To this extent, I think increasing the block size a little will not hurt, but I am against it because it will not solve the "problem" on the long run.

I don't want to increase the blocksize "just a little" because in my opinion it will not solve the issue.
I don't want to increase the blocksize "a lot" because of the reasons I have already mentionned.

So I don't want to scale, leap, high-jump, run, dive or do any sporting event.

If the blocksize scales "a little", I will accept it, even though I disagree.
If the blocksize scales "a lot", I am leaving.

So simple!

SCALING is not a one time "just a little" its not a one time "alot".
 its a long run of progressive steps..
you solve the long run by doing the long run.. one foot infront of the other..

we dont need 1gb blocks today.
today we can fix the issues of the 4mb block bloat, spam, its badly utilised 3mb witness segregation space offset.  to allow more transactions to actually get to potentials of 16k transactions instead of stuck at averages under 4.2k. without adjusting more then 4mb..
then move to 8mb  and at later date progress again. and more later to progress again..
one step infront of the other.. step by step
.. this is literally the meaning of scaling..  the long run

all the other detractors/objectors talking about needing to high jump now to solve the long run later..(facepalm)
all the other detractors/objectors talking about a high jump cant happen now so lets do nothing at all..(facepalm)
all the other detractors/objectors completely ignoring/avoiding/ twist/lie about discussion of SCALING (facepalm)

even though 99% of transactions are relayed/broadcast PRE CONFIRM so the "4mb" block limit is not actually "4mb" sent in one go anymore
but lets say it was.. heck lets say it was 10mb

10mb /10min = 1mb/min = 16kb/sec
a 10mb block is less data than dial-up

those in africa who dont live near cabled internet use 4g/5g cellular, which they 'hotspot' to a PC
millions of africans livestream, watch tv and game via 4g/5g..

do you think netflix (data of gigabytes an hour to users) said "lets not start a business because customers cant handle gigabytes an hour"

as for the initial block download.. things can be done about the user interface of things like core to not be a splash screen telling people to wait to sync-up, when people just want to generate an address to get started, many things can be done to make that a better user experience. not just the user interface but also the underlying download process

[Synchronice]

If there are ways to manipulate or rig the system to an outcome which suits an attackers goals, then it's no good.  We can't inadvertently introduce that kind of weakness.

There will always be a way to manipulate the system even if we increase the block size up to 1 TB. Miners have a huge advantage, they can send transactions with very high fees while losing nothing because all the paid fees finally end up in their pocket. So, if I am a big miner and make tens of thousands of transactions and pay millions in fees, I will increase fee for everyone and collect additional money from it but I also get all my spent millions back because fees and block reward comes together to miners.

I really wonder if someone came up with a better solution that doesn't only include block size increase. I don't understand why do people join mining pools that don't share fees with their customers. Every big mining pool leaves fee for themselves instead of sharing while smaller ones give away fees but still don't attract people.

[vjudeu]

I really wonder if someone came up with a better solution that doesn't only include block size increase.

1. Sidechains: blocks can be big and small at the same time, if you have two-way-peg. Then, you decide, what you want, by making signatures.
2. Cut-through: if you have Alice->Bob->Charlie transaction chain, then you need to store only Alice->Charlie. If you have long unconfirmed transaction chains, you can batch it. If you have to show someone, that Bob was inside, then you can do so through commitments.
3. Scanners: if some data is already pushed on-chain, then you can create a scanner, that would locate it in already existing chain, instead of pushing it again, like some user, who tried to push the whitepaper again, but as an Ordinal this time (ignoring the fact, that it was already pushed long time ago with some multisig).
4. No-fork compression: you can compress things in any way you want, and stay compatible with the existing network, as long as you decompress things before sending to old nodes. If it will be standardized, then new nodes will have better performance, so people will upgrade soon.
5. Commitments: you don't have to push big data on-chain. In many cases, all you need is just proving that a given data existed on a given time, and just use Bitcoin as a timestamping server. Commitments can be used to do that, and it will cost no additional on-chain bytes.

Should I continue? Or maybe there are some questions? Coming up with some new idea is not that hard. The most difficult part is turning all of that into code. And this is what I am trying to do. One of my experimental project assumes that everything is P2PK-only, and is fully commitment-based (I don't have to care about things, that are not OP_CHECKSIG-based, because they can be easily simplified into OP_TRUE; also you cannot use a coin in any real-life scenario, without using any public key). Maybe that could make Initial Blockchain Download faster? We will see, if I will manage to do that; after all, it is also very likely to merge my ideas with someone else, than to release it alone.

I don't understand why do people join mining pools that don't share fees with their customers. Every big mining pool leaves fee for themselves instead of sharing while smaller ones give away fees but still don't attract people.

It is a matter of time. Note that with each and every halving, the basic block reward is getting smaller and smaller. So, we will eventually reach a point, where those pools would have a choice: convince miners to work for free, or lose them. Because the basic block reward will eventually be zero, and that would force those pools to change their rules.

[franky1]

Maybe that could make Initial Blockchain Download faster?

or maybe the code in bitcoin protocol nodes already has "milestones" to treat blocks older than X height as valid by default

the important part of a bitcoin block for answering "did mining pool solve a block" is actually just
the blockheader
and a list of TXID

the TXID are in an order that a node can merkle tree to a merkle root to compare to the merkle root in the blockheader.

the tests about transaction validity are mostly already done by nodes pre-confirm. when a new block is mined
the actual transactions are mostly already in most nodes mempool(relayed pre-confirm) or can be sent separately in batches on request. its not like 4mb needs to be sent as one lump in one go

with the knowledge that millions of transactions can be relayed per second, requesting just a few thousand or a batch of less then a few thousand is not a hardware/bandwidth hardship

the blockheader+txid that represents "4mb" is actually far less than actual 4mb of data people think needs to be transmitted

there are extra efficiencies that can be done(different to bloom filters)
the list of TXID can be batched into smaller lumps instead of one lump.. made into say 10 lumps of 400tx instead of 1 lump of X000tx. and if a node sees the blockheaders list of TXID and notices a TXID the node doesnt already have it can just make a request for blockID:XXXX-txbatch:4
meaning it just grabs transactions 1601-2000 of X000 instead of all X000

[vjudeu]

or maybe the code in bitcoin protocol nodes already has "milestones" to treat blocks older than X height as valid by default

This is not trustless. If we could do that, then it would be possible to make it a consensus rule. For example: only the last 210,000 blocks are stored, and the rest is automatically marked as valid. Which means, if some bug remain unnoticed for 4 years, it is then set in stone, and cannot be fixed by any chain reorganization.

Which means, in that case, it would allow us to have "const storage client". Then, you could multiply for example 210,000 blocks by 4 MB, and guarantee, that 840 GB is sufficient to run your node. Of course, UTXO set is also important, so it would be potentially bigger than that, but that approach would just mean, that pruning could be set for example to 210,000 blocks, and consensus could enforce it.

Another consequence is that new nodes would start synchronization from 210,000 blocks in the past (or would start from the latest block, and process it backwards), and check only the last N blocks. And then, the whole model should be more UTXO-based, because in your scenario, you have to also somehow remember, which coins were created for example 10 years ago, and were not moved in the last 4 years, (so they are still valid, and should not be dropped).

[vapourminer]

or maybe the code in bitcoin protocol nodes already has "milestones" to treat blocks older than X height as valid by default

This is not trustless. If we could do that, then it would be possible to make it a consensus rule. For example: only the last 210,000 blocks are stored, and the rest is automatically marked as valid. Which means, if some bug remain unnoticed for 4 years, it is then set in stone, and cannot be fixed by any chain reorganization.

wouldnt 4 year reorg basically be catastrophic anyway?

[franky1]

or maybe the code in bitcoin protocol nodes already has "milestones" to treat blocks older than X height as valid by default

This is not trustless. If we could do that, then it would be possible to make it a consensus rule. For example: only the last 210,000 blocks are stored, and the rest is automatically marked as valid. Which means, if some bug remain unnoticed for 4 years, it is then set in stone, and cannot be fixed by any chain reorganization.

Which means, in that case, it would allow us to have "const storage client". Then, you could multiply for example 210,000 blocks by 4 MB, and guarantee, that 840 GB is sufficient to run your node. Of course, UTXO set is also important, so it would be potentially bigger than that, but that approach would just mean, that pruning could be set for example to 210,000 blocks, and consensus could enforce it.

Another consequence is that new nodes would start synchronization from 210,000 blocks in the past (or would start from the latest block, and process it backwards), and check only the last N blocks. And then, the whole model should be more UTXO-based, because in your scenario, you have to also somehow remember, which coins were created for example 10 years ago, and were not moved in the last 4 years, (so they are still valid, and should not be dropped).

its not about starting a sync from block 210k(your example) its about all blocks from 0 forward are downloaded still..  but no transaction validation is done they are just treated as valid and put/taken from utxoset depending if sent or spent..  but all blockdata is stored, just less validations done on earlier blockdata
however code is a great thing and many things can be done. such as locking in a UTXOset image of the position of the 420k block where by we hash the utxoset at that position and put the hash into coinbase reward output and when nodes match their own matched-set to not reject block. then after time of having this hash locked in. the utxoset becomes a ball of data of unspent history to not need the TXdata previous due to milestoned depth agreeing the immutable data is soo deep that a re-org of that magnitude would be more of a risk event in of itself

some are calling this a ball and chain 0-420k ball of utxo and chain of 420,001-now
ofcourse the block headers and txid tree of 0-420k still remain to show the tx of the utxoset did exist in said block

code can do many great things

[DooMAD]

I don't personally believe "milestones" or "checkpoints" to be the right approach.  I outlined some reasons as to why back in 2020.  Either every block is a checkpoint or none of them are.

The ideal solution, in my mind, would be one in which users have some level of flexibility to determine their own level of involvement.  Similar to what SegWit achieved.  If users want to carry a smaller burden, they can just sync the 'legacy' blockdata and leave out the 'witness' while still contributing to, and taking part in, the network.  The opt-in nature to retain a low barrier to entry is preferable to a one-size-fits-all approach, where we risk people digging their heels in and increasing the potential for a contentious fork.  Increasing linear growth in the witness space is inherently more inclusive than forcing an increase upon everyone and risking greater division.

[cryptosize]

I don't personally believe "milestones" or "checkpoints" to be the right approach.  I outlined some reasons as to why back in 2020.  Either every block is a checkpoint or none of them are.

The ideal solution, in my mind, would be one in which users have some level of flexibility to determine their own level of involvement.  Similar to what SegWit achieved.  If users want to carry a smaller burden, they can just sync the 'legacy' blockdata and leave out the 'witness' while still contributing to, and taking part in, the network.  The opt-in nature to retain a low barrier to entry is preferable to a one-size-fits-all approach, where we risk people digging their heels in and increasing the potential for a contentious fork.  Increasing linear growth in the witness space is inherently more inclusive than forcing an increase upon everyone and risking greater division.

What you're proposing is actually an ingenious solution and reminds me of AMD's x86-64 architecture 20+ years ago.

What did AMD do? They took Intel's i386 proven architecture (despite not being perfect, especially compared to RISC behemoths) and extended it (double register width + double the amount of registers).

You can operate an AMD64 processor in various ways (legacy i386 or 64-bit mode or even 16-bit mode for DOS apps)!

On the other hand, Intel invented Itanium (a brand new, clean slate architecture) and it failed miserably. Eventually they were forced to copy AMD's approach.

What's the lesson here for IT-minded folks?

I'm honestly surprised we have this kind of discussions in the Bitcoin community... I'm really curious to know the professional background of big blockers, if they have any.

Something tells me they have almost zero IT experience, which explains their fallacious arguments...

[franky1]

The ideal solution, in my mind, would be one in which users have some level of flexibility to determine their own level of involvement.  Similar to what SegWit achieved.  If users want to carry a smaller burden, they can just sync the 'legacy' blockdata and leave out the 'witness' while still contributing to, and taking part in, the network.  The opt-in nature to retain a low barrier to entry is preferable to a one-size-fits-all approach, where we risk people digging their heels in and increasing the potential for a contentious fork.  Increasing linear growth in the witness space is inherently more inclusive than forcing an increase upon everyone and risking greater division.

people don't opt-in, 'a nature to retain a low barrier of entry'... they are opting-out of being a full node
you opt-in by upgrading your node..
you are opted out by the network when new funky tx start appearing but you did not upgrade to be ready

only downloading the legacy data is not contributing because
old 'backward' nodes dont validate pre-confirm funky tx.
old 'backward' nodes dont relay pre-confirm funky tx.
old 'backward' nodes dont validate post-confirm
old 'backward' nodes dont retain the signature proof of new funky tx in a block
old 'backward' nodes dont keep full data to then offer initial block download to other nodes

yes you are still on the network. but become a leecher not a seeder of blockdata, you become a network burden on full nodes because you become a downstream bottleneck endpoint, not an equal peer

there is a big difference between treating assume valid blocks that are 8-12 years old vs live data unconfirmed or just confirmed today being assumed as valid without as many nodes doing the full checks and archiving

there was a big reason for proper consensus votes. and that was to ensure there were a healthy amount of upgraded nodes ready to fully validate a new proposed change.. when new funky transactions were being introduced... its called decentralisation

using assume valids to allow new junk without a consensus vote of readiness hurts the network.. alot more then using a assume valid of blocks 8-12 years ago that can be audited and double milestoned into a audited utxoset

[vjudeu]

Either every block is a checkpoint or none of them are.

This is a wrong take, because one-block chain reorganization is something that can happen, no matter how high hashrate the network will reach. However, 210,000 blocks chain reorganization is something that never happened.

Also, there is a reason, why we have coinbase maturity, set to 100 blocks. If you don't agree with protecting the last 210,000 blocks, then what about last 100 blocks?

Another place when there is such assumption, is pruning: you cannot prune the last 288 blocks. So, what about 288, if 100 is not enough? Or maybe 2016, to align it with difficulty adjustments, and compress those four bytes, that are mostly identical during those two weeks?

So, if protecting a single block would be enough, then we wouldn't have coinbase maturity (100 blocks) or minimal pruning level (288 blocks, which means around 2 days).

If users want to carry a smaller burden, they can just sync the 'legacy' blockdata and leave out the 'witness' while still contributing to, and taking part in, the network.

Note that by doing things in this way, you open a potential gate in the future, to disable SegWit, or other soft-forks. It is up to you to decide, if you want that. But yes, it is possible, and can be easily achieved, for example by just running some old client. And yes, that famous block with almost 4 MB witness, is very small, if you have non-Segwit client.

Increasing linear growth in the witness space is inherently more inclusive than forcing an increase upon everyone and risking greater division.

As far as I know, increasing witness is incompatible with old nodes. You cannot change 4 MB into 32 MB, just by changing a single constant. It is consensus-level change, which means, you need a second witness to make it compatible. Which means, you probably need commitments, that can be used on legacy, witness, or whatever, and can be increased or decreased at will. In other cases, you will end up with more than one witness, and people will complain, that your code is convoluted.

[pooya87]

Your problem Franky is that you have some abstract idea of a problem and then expand that to the whole system and bash everything in your way.

back then they had buzzwords for them  empty opcode, called nops, nulls.. these days for the new subclass of opcodes of segwit and then the next subclass of opcodes for taproot they buzzword names like opsuccess
LEARN THEM, learn what they do and dont do

OP_NOPs have always existed in Bitcoin and they are a good thing. They exist to allow future expansion while having their usage restricted by standard rules. Need I remind you of how OP_CHECKLOCKTIMEVERIFY was activated?

anyways
the very next bytes you can put in a op_0 is op_push4 which say the next bytes after that can be 4,294,967,295‬ bytes(4.29GB) which are only prevented by the block limit to not actually be 4.29gb
also multisig did not use op_0 it used other operation bytes..

Wrong.
As I said witness version 0 is literally the strictest script that exists in Bitcoin. After OP_0 there can only and only be either 20 byte or 32 bytes and absolutely nothing else. If you include anything else (eg. 19 bytes) your transaction is rejected as invalid (not even non-standard, it is outright invalid).
https://github.com/bitcoin/bitcoin/blob/b5a271334ca81a6adcb1c608d85c83621a9eae47/src/script/interpreter.cpp#L1901

so it can be abused in so many ways due to its openness at the time of writing it in 2016

I don't know what SegWit was or may have been before it was activated. It is as it is right now and your statements in the previous quote chunk are in present tense not something that might have been and your bashing of SegWit is still happening today not in some distant past with all false information such as the previous quote chunk!

seems doomad and pooya have rejoined each other in the cultish narrative of merit circle jerkin and defending each other again, to prevent bitcoin scaling by not even knowing about the code or exploits that are causing the congestion that is not helping bitcoin have lean transactions or increased transaction counts

It is one thing to talk about the actual problem which is the "loose ends" in witness evaluation rules some of which introduced in version 1. Nobody has talked about them more than I did. But it is another thing to bash SegWit as a whole and use the strictest one (which is version 0) as your whole false arguments!

[franky1]

Maybe that could make Initial Blockchain Download faster?

or maybe the code in bitcoin protocol nodes already has "milestones" to treat blocks older than X height as valid by default

But is it really needed to implement the "milestone" on Bitcoin protocol when several Bitcoin full node software already do that? As reference, here are few example,

maybe read a lil