Quote from: franky1 on Today at 02:23:26 AM

Quote from: DooMAD on Today at 01:34:39 AM

Also, I'm still waiting on a response on my previous post about consensus. Kindly answer some of my questions before you attempt to add more of your own.

i did answer your question. but without having to play around with blue writing to edit the question, i just wrote some out to get to the real context of the contention/argument/debate
(second half of this post)
https://bitcointalk.org/index.php?topic=5380215.msg59001987#msg59001987

You're skipping ahead. Let's get the fundamentals nailed down first. If someone can't accept that 2+2=4, then I'm not going to acknowledge any opinions they might have on quantum mechanics, because their views are meaningless. Similarly, if someone can't accept that devs can create whatever code what they want and users can run whatever code they want, then their opinions on consensus are equally meaningless in my view.

There is an important reason why this understanding is crucial. I'll take the opportunity to repeat something I said in 2018 (with a small portion removed in the spirit of keeping things civil):

Quote from: DooMAD on December 07, 2018, 12:43:23 PM

It's all well and good saying that the community should have a bigger say on what the code is, but then you have the chicken and egg problem where users can't agree or disagree with code until it actually exists and then they can all see what that code does. Then you have the small, but insurmountable, obstacle where Bitcoin is not some sort of committee or parliament with points of order and rules governing social conduct. There is no way for anyone to enforce a rule that says people can't write code with an arbitrary activation date. There's no way to enforce a rule saying we aren't allowed to have softforks. It's just people writing and running code. If you want to write some code, go ahead. If you want to run some code, go ahead. (...) That's about the extent of your influence here.

I assert that this is how Bitcoin works. I also assert no one has provided a viable alternative.

Another reason we need the fundamentals pinned down is because you have said things in the past which indicate confusion on your part. Take for example:

Quote from: franky1 on April 01, 2021, 07:09:03 PM

dont cause a fork before a consensus change.

This makes no rational sense. A fork is a consensus change. Further, no one individual is in a position to determine when consensus can or cannot change. This should be self-evident.

Quote from: franky1 on October 06, 2018, 04:36:42 PM

we need to get back to a level playing field where multiple pieces of full node full validating full archival software all have equal level as core.

Who decides what qualifies as "level" or "equal"? There are no individuals in a position to make that determination.

Quote from: franky1 on October 06, 2018, 04:36:42 PM

core, if it wants to be a reference client should only run current rules.

There is no way to enforce that. Along with being a failure to understand consensus, I would also describe this as an egregious assault on freedom.

All of these comments are highly problematic if you wish to engage further about how consensus "should" work or that we're somehow doing it "wrong". First you have to demonstrate you understand how it does work before we can accept any of your assertions that you know how to make it "better". So again, before you skip ahead to add new questions, please, at the very least, just answer the first two:

Any developer is free to code what they want.
agree[ ] disagree[ ]

Everyone will be free to run any code they choose.
agree[ ] disagree[ ]

Please demonstrate your understanding of these key aspects of consensus.

Quote from: franky1 on Today at 02:23:26 AM

he stated that bips91 and 148 were never used.

False:

Quote from: DooMAD on April 01, 2021, 05:50:38 PM

My stance is, and always has been, that BIP91 bit 4 flag is what activated Segwit with 90+% of the hashrate

BIP91 bit 4 flag is what activated SegWit. I'm not sure how many more times I need to repeat it.

"Mandatory" BIP148, to the best of my knowledge, was only implemented in the UASF client. However, I never ran that client, so I don't personally recognise it as part of Bitcoin. That code never had the opportunity to activate as BIP91 activated first and superseded it. We could also easily spend the next few years arguing about what "mandatory" means and how I disagree with shaolinfry's use of the word, but it's entirely inconsequential now.