Topic: Mempool Observer Topic - page 75. (Read 20218 times)

as ETFbitcoin said using bsv as an example is a poor attempt..
first bsv has never been a viable real world use coin.. so users/nodes/mining were centralised from the start even before the data bloat

if you had an inbred offspring with disabilities. and then that offspring had an inbred offspring with further disabilities
you would then use the inbred malformaties to decide the future of your lineage. rather then learn from it and stop inbreding to cause disabled offspring. and instead fix the problem(inbreding/centralisation) to have healthy future lineage to carry on your legacy without junk dna in your bloodline

secondly the reason BSV is not a good example because its only 5 years old with 10tb meaning 2tb a year
no one on the entire planet is proposing blocks that result in 2tb a year. no discussion over the last 14 years have ever proposed bitcoin leap to 2tb a year growth
that strawman of "gigabyte blocks asap" is the empty argument of dev politics empty rebuttle to say "2gb a year LEAPS wont help so lets not even discuss SCALING at smaller adjustment"

the only reason dev politics want everyone to leave bitcoin and use subnetworks is for middle men fee's that the dev sponsors will earn to get ROI for sponsoring devs to create gateways to subnetworks

you sound like a scripted snake oil salesman. not someone that cares to make bitcoin useful for bitcoiners

the funny thing is because subnetworks have no blockchain nor network wide auditing/policy. those subnetworks could have designed their systems privately/independently in a multitude of ways that fit a niche utility/feature promise and still communicate with bitcoin.. they actually had alot more freedom to develop anything without needing to consider consensus/network readiness. because their subnetwork doesnt need such.. . yet the sponsored deals and arm twisting occured to change bitcoin, purely to promote a buggy subnetwork. rather then make a subnetwork that meets its niche promise to promote itself.. while leaving bitcoin devs to just concentrate on bitcoin features that benefit bitcoiner that want to use bitcoin

these buggy subnetworks are not the solution because they are buggy from the start and failed to fix issues over the last 6 years
yes new(yet to be made) subnetworks can facilitate niches for certain utility.. but promoting the current failed line up is a fools errand

lastly i do find it funny how in one sentence you pretend to be against bloat.. but in other sentences/posts you dont want the nonsense junk bloat to stop, and instead you want bitcoiners to stop being bitcoiners.. you are trying to censor bitcoiners off the network whilst defending the bloat junk

you prefer the junk to run on bitcoin and for bitcoiners to become subnetworkers (facepalm)
again you sound like a failed door to door salesman selling snake oil

you are not making any comments to preserve bitcoins utility. you sound like a subnetwork salesman that doesnt want bitcoin to be for bitcoiners

and dont bother even replying with the empty statement of "censorship" until you have done your research of core accepted buzzwords like
"drop" "eviction" "prune" "reject" "ban"...  and realise bitcoin DID have code to decide whats fit for the network and those rules WERE respected as it was good for the network... . and CORE did relax the rules to allow the junk exploit but now refuse to fix their error..

There are a handful of miners as compared to the users of Bitcoin who are suffering from these high fees at the moment. Today is Sunday and usually, the mempool should not be congested during the weekends but still, the mempool fee is around 200 vbyte/sat, which is on the higher side.

Most of the retailers and ordinary users are waiting for this high fee issue to be resolved and we can do our transactions at cheaper fees.

SegWit was necessary to make L2 solutions more viable, that's why. L2 is where the future of regular user transactions are headed, like it or not.


All the Faketoshi stuff aside, its blockchain is approaching 10 terabytes and is supported by less than 100 nodes. One mining pool dominates with 54% of the hash rate. There couldn't be a clearer picture of why large blockchains leads to centralization. You can say, "ah but nobody wants to run a coin led by Faketoshi," and you'd be right, but even if he stepped out of the picture completely, I sincerely doubt things would be any different.


Agreed. The conversation has been played out from every angle imaginable 10 times each since 2017.

To sum it up:

BTC core devs have zero power to enforce their opinion/vision, EVEN if that includes larger blocks. So the argument "you're gonna support BTC with bigger blocks if BTC core devs decide it" holds no water.

BTC mining pools (the first 5 have almost 85% of the hashrate, Pareto Principle 101) have the power to change things (since they secure the network), BUT they have zero inclination to increase the block size and therefore destroy the lucrative fee market.

Am I missing something?

So now it's two choices, we are getting to something, yes, I have always said the same thing, if you don't like how things are, start doing something, run your own client, email mining pools, and exchanges, don't just sit here and complain, it's the same thing I say to those who want larger blocks and those who are today nagging about Ordinals and demanding core devs to change the protocol just to ban ordinals.

I hope that the two of us are talking about the exact same point here, I am ONLY opposing the "If you don't like how things are with BTC, go use xyz" I am only against this particular stupid statement, why? because I think it's stupid, but any other rational argument against those who want to change the protocol is always welcomed.

Now in this context let me quote DooMAD reply to mine




In another topic discussion block size, I said

if thats live data API it might be worth stompix putting it into the OP post so new readers can see live data in top post rather then old data

obviously stompix can then archive daily data in subsequent posts

I made this api some time ago, which always shows recommended fees.
Data from mempool.space



It will fit  this topic about high fees

That's exactly the reason we need to decrease the blocksize to 100 kb to kill all possible spam!  


It happens more often than you think, just a quick heads-up since this is mainly a topic about the state of the mempool, block 823575 was 34 minutes late:



Happy 2024 oh wait 374sat/vb!


Oh god no, I'm protestant!

LE:


I'm unable to connect to my server right now so I'm not able to get any data from my node, question to the guys running one a default 300MB, is the number accurate? I changed that months ago and I know it broke though over 1GB weeks ago but that much in purging?

LLE:
Thanks bitmover, and I need to grab another mouse since my current one committed suicide while meriting franky1

you debunked nothing. and know nothing about treating opcodes differently
you instead implied that a whole class of opcodes that are conditioned should be treated the same as unconditioned opcodes and all premiumised.. as your lame attempt of debunking(which failed)

for instance certain opcodes for specific tapscript have got formatting conditions set to know what to expect. where as other opcodes created since segwit and taproot still do not have conditions set, yet do validation bypass tricks.. which allow abuse of blockspace. so  THE PARTICULAR UNCONDITIONED opcodes can be set to have particular fee tiering. its not an all or nothing thing..
please learn  

also you keep crying about FORKS
learn that it does not require 2 separate blockchains paths..(a fork) learn some basic bitcoin concepts and realise not everything ends up creating an altcoin
when core added new subset of opcodes there was no fork. when core added conditions to specific opcodes there was no fork.. learn that things can be done without a fork.

But isn't there a non-zero chance that it would also open more opportunities for some entities to send larger payloads of "spam" per block and store them in the Bitcoin blockchain?

Plus Dogecoin and every other major altcoin don't give the same security assurances as Bitcoin. Solana I believe, during the last bull cycle, stopped producing blocks for hours because of network congestion. That should ever happen to Bitcoin.

In case anyone thinks franky1 is right on his "fee formula" solution, I suggest them to read the following discussion in which I believe I have debunked why it can't even be implemented without a fork: https://bitcointalksearch.org/topic/m.63379182.

The tl;dr is: his "solution" requires from the Bitcoin client to treat certain op codes the same as with segwit transactions, where there's an extra witness part. For example, if your transaction does not contain tapscript, you gain an extra space (as in segwit), thereby punishing financially those who will use tapscript.

its feasible to implement a fee formulae tier system where transactions using certain opcodes pay multiples of base fee estimate rate
after all legacy pays more then segwit. and thats without any block rejection enforcement..

but trying to convince core to put fee formulae's that benefit bitcoiners.. goodluck. core prefer high fee's because it annoys bitcoiners and becomes an advert to migrate people to other networks core prefer users to use(subnetworks of core dev parent/sponsor design)

And is it technically feasible to make it impossible to carry out a transaction where the fee would be higher than the overall sum (which would mechanically prevent BRC20 registrations) ?

^ funny how doomad pretends that he wont immediately REKT any node that opposes cores design
he has always said no one should scrutinise core nor oppose core.

he has been part of the PR army that adore core control. he wants any other brand to be seen as a altcoin proposal not a bitcoin network upgrade proposal

people have proposed things many times over the many years. and got slammed down by the core dev control of moderation of IRC, mailing list, github and this forums technical discussion.. purely for the proposal not fitting into or agreeing with the core roadmap

there are only a handful of core devs with the maintainer/merge key privilege but thousands of devs that have seen the wraith of their moderation and ended up taking their projects elsewhere to altcoins or just retired from coding bitcoin entirely.. (which is what core devs ultimately want)

cores backward compatibility does not even need core to propose a candidate and hope people use it. core can add new tx formats without network readiness.

Again, sad interpretation. Rather, if you dislike how things operate, you have two choices:

- Confirm your rationale by talking about it. Propose change. Convince other individuals you are right. Convince developers you are right, or write the code that implements your vision yourself. 
- Go elsewhere.

This conversation is so extensively discussed over the years, that it has lost its intellectual spirit. Now more it is just utter complaining. Complaining about what the developers should have done; what they should be writing. People have to move on. Tomorrow, it'll be 2024 and we are talking as if it's still 2017.

Oh, but I am very much aware they know it. What is questionable is whether they recognize it as the mature option. In my opinion, migrating to a community that respects your standards is more preferable than continually complaining about the deficiencies of your current community.

In that case, he will be given the two choices presented above.

I think I have already answered the rest of your questions.

Taking it back to basics, why even ask permission?  If you don't like what's in the current code, create your own client.  Create an account on GitHub, select the option to fork the codebase, make whatever changes you like.  Then release it.  Share it around.  That way, you start to get a sense of what support a given proposal truly has.  Remove talk from the equation.  Talk is cheap.

Also, people talk about "voting" as though they have some sort of influence on what appears on a candidate's manifesto and election pledges.  But that's not how that works.  The candidates tell you what they stand for and then you pick the candidate.  But it's better than that here, because you can make yourself a candidate!  When discussion fails, just go ahead and do it anyway.  Don't waste time bleating false equivalences about "voting".  Just create what you like, see who runs the code and let the consensus mechanism sort it all out.

And if you don't know how to code, you can pay a coder to write code.  You could pay a whole bunch of them.  Fund an entire dev team.  If you don't have money, you can crowdsource.  But no, people just want to complain and do nothing constructive to even try to change the situation.  And that's why the status quo remains.

No one actually wants to lift a finger to make something happen.  It's just a bunch of noisy armchair pundits.  What else is there to tell them?  

the use of the word censorship is overly abused.. without any context of understanding of the word
when in contrast core dev love the words
eviction, rejection, drop, abandon, pruning, banning

bitcoin always had policies to not allow certain transactions/data..
.. in recent years they relaxed the rules which ended up with more junk. not a better system

Would you consider it censorship to make it impossible to carry out a transaction where the fee is higher than the overall sum (which would mechanically prevent BRC20 inscriptions) ?

to even have a system that veers away from core governance requires non core devs to write nodes that have the ability to vote away from core obediance. and populate the network
years of REKT campaigns put core in central control. along with their sponsors(NYA) that mandated to follow core or have their blocks rejected.

a mining pool cant just make bigger blocks. unless the network is ready for it. and with how core have settled in their control mechanisms, we have become obedient to need to beg core to do things. because other brands even if offering good options will never beat cores control mechanisms
cores main aims for the last 6 years have not been to benefit bitcoiners use of bitcoin. but instead add features that benefit subnetworks of middlemen they want to push people over to.


when you finally are ready to stop blindly idolising core devs as gods. and ready to see their management structure, pay structure, sponsorship deals. you will notice they are not as open and honest as promoted. but ill leave you to your own awakening where you are suppose to scrutinise the rule makers, instead of adoring them and letting them do as they please

the biggest failure is when a community dont scrutinise those in control

no one really ever heard of "glozow" before her employment and github key privileges promotion. and now looking at all of her bitcoin core edits of the modules she is in charge of(mempool), you can see why the mempool has become soo affected (not in a good way)

If we stick to this notion of "you dislike how things currently operate, you go else where" this means there is nothing more to discuss on bitcoin, we use it as is, and wait for everyone to be a millionaire.


I disagree, just because many people blindly worship core devs does not mean core devs are bad, i think for the most part they are genuine people who want whats best for bitcoin, and then among them will be people are somewhat biased due to whatever personal reasons they have.

But again, blocks have not increased in size isn't the sole responsibility for core team, as i said again, if a few large pools and exchanges wanted to increase it, core will have to follow, it just seems like the majority of the powerful entities have no issue with how bitcoin currently is, and I agree with them, i do not see the need for a change now given how I view and treat bitcoin.

If everyone else opt-in for larger blocks and core rejects (which they can't anyway) then we can blame them, until then, everyone seems happy about it except a few dozen folks.