im not a "big blocker" because the group that push the term "big blocker" are pushing it to mean GB blocks asap extremes
Everything above 4 MB is "big blocks" in my opinion.
4.1mb is not big blocker..
heck we are 8 years passed the cries that 2mb was big. we are even 7 years passed where core devs thought(admitted) that 4mb was not detrimental to the network
thing have moved on since (moores law), even 6mb 8mb today is not "big blocker" detrimental to the network. but dev politics are not ready to change their roadmap
hard drives of 4TB are not $thousands, heck they are not even multiple $hundreds. heck they are not even sing $hundred any more..
a 4TB hard drive that can store ANOTHER ten more years* of block data for the whopping hard drive purchase price of 2tx fee's of 2 months ago congestion rate rate or just 20 tx fee minimum whilst no congestion
i find it funny how people think a $50 hard drive for 14year of old data +10 years* of future data is a economical threat to bitcoin.. but a $25 fee for 1 tx is in their silly minds not a threat but a expectation for the future (facepalm)
funny part is more people have avoided bitcoin due to the fee. not due to hard drives..
so hard drives are not the problem so please do the actual maths and realise those idiots you copy screaming "big blockers" are not talking about 4.1-8mb blocks.. they are talking about GB blocks.. as their exaggeration to their exaggeration of how they want to make bitcoin scaling feel like a non-option by the idiot screamers you copy words of pretending when others talk about scaling (small progressive adjustments via many methods, efforts) are in the minds of the screamers you copy words from pretend scaling is GB network threatening blocks just to try to get the scaling talk to stop. so that the only solution talk is of migrating everyone to subnetworks, because they want to promote the faulty subnetwork as the only option, plus its free promotion if they can get people to not offer other options
by them screaming exaggerations of 'blockchain cant cope with 'big blocks' (exaggerated GB size leaps).. its their attempt to try to quash people from even discussing or making proposals for actual rational SCALING(which is not just increasing blocksize but scaling tx count within blocks via many option),.. the silly idiots want to pretend the only bitcoin options was GB or migrate people offchain..
they dont want people talking about the multitude of rational options.. and just want to pretend those wanting scaling must belong in some GB group of threat.. (facepalm, tut, laugh, shakes head)
(*<600gb so far plus 10years of 4mb(4*525000) = <2.7TB)
a. de cludging the 4mb block code to not be 1mb base 3mb witness and instead a open 4mb space that can be fully utilised by even legacy and or the other tx formats
thus allowing more transactions, rather then junk unrelated to transacting
b. penalising the spammers and bloaters(not everyone) so that less spam/bloat = more room for genuine transactions
You actually contradict yourself here. If you try to "penalize" spammers then you'll get even more difficult to cleanup spam like
Doginals or
Stampchain, which are more difficult to detect because they use transactions resembling ordinary "payment" transactions. OP_RETURN was created to prevent that.
The witness discount has its reasons.
do you know whats great about code.. code creates rules, creates formulaes and creates policy
code can limit how many op returns can be used. to ensure tx stay lead.
code can do alot of things..
c. re-implementing hard validation code that counts and validates all bytes to have a purpose and lean preference = more transactions
Again, how do you want to detect spam not using a known scheme like Ordinals, but another obscuranted method?
bloat is detectable by bytes not part of the input output of value
spam can be detected by the UTXO age being spent to often
EG someone with a 1 confirm can be set as a 144x fee to attain priority
someone with a 144 confirm only needs to pay 1x fee to attain priority
d. not LEAPING blocksize, nor moving blocksize via core dev politics, but SCALING in adjustments based on fill rate and fee of a math formulae that if reaching a threshold of prolonged congestion, then the blocksize can increase at a set milestone all nodes know the formulae of(much like node know difficulty formulae), a rule in nodes to be in consensus to agree on. without dev politics(god mode) decisions
In general I'm not against this idea, I have supported it actually multiple times. It could however be quite challenging to find a formula which can't be gamed.
and you think dev politics cant be gamed...
And I guess if you're against L2 solutions then I guess your formula would be quite elastic, i.e. reacting fast to congestion. But as you can't distinguish spam from legit transactions (it's impossible, believe me) then you invite the spammers to spam the network even more with such a formula -> and then you're again helping centralization (Yeah! We're back on topic!). The formula thus would have to be extremely conservative, also to ensure a fee market can develop (fee market does not mean $100 fees though, but it should be able to go significantly over $0.10 in times of high demand.)
subnetworks (next gen not the current flawed sandbox offerings) will have niches.. but to presume every needs to migrate away from bitcoin into the singular flawed subnetwork you promote and idolise.. thats where you lose me and i laugh at you
as for your other assumptions... ill just tut and laugh.. ill give you some more time to actually think about a proper rebuttal rather then the one you gave
hint: recently conjestion was 2500 average tx per 4mb cludgy bloated block paying $20 each last month is where people give up using bitcoin daily and just didnt bother using bitcoin for months.. which leads to centralisation via avoidance
however
(in a congestion scenario of blocks of~ 8mb best case (if things got fully efficient, lean where every byte counts again)
30,000 tx (of lean tx, uncludged block format, de spammed, debloated) $2 per tx during congestion is more for a mining pool then the 2500 x $20 current congestion.. but users pay less
.. its economics. more space for more tx(and more erognomics of the space, and other things) means people pay less.. but total fee becomes more
if you had a level head. and a actual inclination to think for yourself about whats best for bitcoin
you would not be following the idiot brigade diatribe of trying to get everyone else off bitcoin and whilst saying that the junk should not be stopped
I suppose that you have good intentions for BTC, but you're simply unrealistic if you think spamming can be stopped "the Luke-Jr way", i.e. with a hard-coded "spam control" like Ordisrespector.
again ill give you time to come up with a better rebuttal then you just said, and just laugh and tut
the presumptions you make of me are more laughable of the ones i make of you
i have never even said anything that sounds like "lukes way" yet i can quote you many times sounding like the idiot brigade that promote off-ramping everyone over to the single subnetwork they call "solution" and your other sily buzzword you repeat without independent thought
PS: My personal hopes on how spam could be stopped or at least made less attractive is
ZK tech like in this thread, which would allow full nodes to ignore arbitrary data.
nodes without FULL storage..
nodes without FULL verification..
are not.. wait for it.. [drum role]..... FULL nodes
they would be considered pruned, stripped, bridged, downstream nodes
ill give an example
in the 2016-2017+ era of node versions
a 0.11 (presegwit node) peer connecting to a segwit activated node.. has the segwit active node strip the witness and hands the pre segwit node a stripped block where it does not have the (witness)signatures/scripts/bloat of segwit/taproot .. but BLINDLY passes them as valid due to the opcode trick segwit/taproot uses to deem data after opcode should be passed without inspection, even if missing signature witness)
these older nodes are not full nodes as they dont validate all data and dont store all data.. so they cant then act as IBD seeds for other FULL node peers to leach blockchain data from
those older nodes then due to how peerconnect works become a under layer of nodes at the bottom of the tier system of network peers
even gmax and his team called these nodes downstream, bridged, stripped nodes