Bitcoin Forum

Franky1 is the biggest advocate of this idea in the forum. I respect that, but it is very debatable. What if Bitcoin Cash increased its block size and doubled its monetary supply? Would that "bilateral split" idea be easy to accept? I believe it won't.

it could have been a bilateral split if there were actually two sides with near equal merit: bitcoin and bitcoin cash.
what we had was two sides that were equal: going with SegWit and second layer; going with block size increase hard fork.
and we shouldn't confuse the two together in my opinion. the later could have been a bilateral split but the former (which created bitcoin cash) has nothing to do with that. it was a centralized attempt to take over and create an altcoin to make money using the other rejected proposal for scaling bitcoin as an excuse to make them look legit. a very similar thing that is being repeated by BitcoinSV these days.

Did you mean to say Block Speed and not block size, as BCH has already increased block size?

Doubling their amount to 42 million coins, so in a world that has 7.7 billion people,
you think that is enough to be a global currency used by all.
It is not , a True Global Currency needs at least a billion or more coins.

US $ Fiat alone had ~80 trillion dollars according to a CIA 2017 report.

No, I said an increase in block size AND doubled the monetary supply. I am asking if there is a change in perception of Bitcoin Cash's so-called "bilateral" split if there was an increase in the cap to 42 million coins.

actually it was the devs that advocated bilateral split... its their buzzword

i am against throwing opposers off the network so minorities get a faked consensus. but the devs advocate it (UASF)

i am against the idea of mandatory forks.

i am against single brands of software deciding whole network decisions,
i advocate consensus of community acceptance via joint communication to find healthy compromise which a majority can accept on and stay one network

i am against splitting the network just so one team can get their way.

WAKE UP and stop the fud, atleast research consensus
if you dont want to research what actually happened network-wise

atleast research your topics and stop the social finger pointing unless you can prove it

show one post where i say i love and advocated bilateral split and ill show many  where i am shunning the devs for performing one

also throwing my username into the same sentance as cash is foolish too. but i can see your motivations are clear now
you really have gone full FUD.

lastly it was the cores side that were not happy with thier 35% spring 2017 support. which is why core devs (luke JR) proposed the mandatory activation.

you do realise there is this thing called the blockchain. its a immutable archive of events and transactions.
if you were to actually check the blockchain data you will see that core triggered it at block 478558.

the funny thing is core supporters actually shouted that cash didnt trigger until hours later.
(core only accepted segwit flagged blocks at 13:23)
(cash only accepted cash blocks at 18:12)

the code that achieved this split was wrote by core devs (luke JR UASF)
https://www.uasf.co/#uasf-signaling
please do your research next time

lastly. its the mindset of some that bitcoin(network) should be owned by one team brand. wherby they go on the 'defend the dev' parade and try to make it sound that anyone who is against a dev is against bitcoin. purely to continue their mantra that bitcoin should have one central team.(facepalm)

its a real shame that those people cannot distinguish the difference between one dev team control from the concept of a whole network concept of consensus of teams.
have a nice day.

The funny thing is, it takes two sides to have a disagreement and this statement was issued before SegWit was activated:

https://medium.com/@ViaBTC/statement-on-bitcoin-user-activated-hard-fork-6e7aebb67e67 (https://medium.com/@ViaBTC/statement-on-bitcoin-user-activated-hard-fork-6e7aebb67e67)

Why pretend it's all the fault of only one side?  They clearly had plans to leave the BTC network and make another one that suited their stance on scaling.



Is that really what you've been blathering on about for all this time?  Seriously?  A dev pointed out something that users and miners are free to do if they wanted to, so because of that, you think developers are somehow "in control"?  Congratulations on proving once again you don't understand consensus.  

Tell me, what makes you think users and miners can't do what gmaxwell described?  Show me in the code where it says that users and miners can't change the activation threshold for a fork.  Oh right, you can't, because the code can change depending on what people run.  That's consensus in action.  People run what they want and the software automatically matches them up with other people who want the same thing.  And it goes both ways.  Some people want to run code that doesn't conform to what users on this network want.  Why should they not have that choice?  Why do you think you can force everyone to reach an agreement when they clearly don't want to?  There is no compromise that everyone would have accepted.  We had years of infighting to demonstrate that fact.  Why can't you let it go?  However it might have happened, it's done.  You can't go back and change it, nor can you stop it from happening again.  And I'll explain why:

A "single brand of software" doesn't decide consensus, users and miners do.  They do that with every single block.  You can be "against" whatever you like, even if that means you're against reality itself and reveal yourself to be totally ignorant and deluded in the process.  Bitcoin doesn't work they way you'd like it to.  Chances are, it never will.  You can't prevent users and miners from running the code they are freely choosing to run.  You can't prevent hardforks, softforks, UASFs, whatever.  You can't prevent "throwing opposors off the network".  I don't care how much you hate it or how wrong you believe it to be.  It's not your call.  It's all just a whole bunch of different people running software.  No one can control that.  If what you want falls by the wayside, that's just too bad.  C'est la vie.  Don't expect any sympathy just because other people don't want what you want.  None of us are here to go out of our way to appease you.  Perhaps it's time you accepted that?

Also, please take just a brief a moment to consider that it might not be the best idea telling people to "research consensus" just because you've come up with your own unique and highly distorted interpretation of what it means.  If you're the only one who takes exception to what gmaxwell said, then it stands to reason you're the one who is out of step with everyone else here.  In which case, perhaps you might want to go back to learning it all from scratch because you're the one who doesn't understand it.

I now fully expect you to start talking about social dramas and poking bears (you're not a bear by the way, you seem more like a weasel or rodent) and do some whining about insults.  All the usual Franky1 deflections to avoid admitting you don't understand the first thing about permissionless freedom and consensus.  Again, it's just people running code.  In the grand scheme of things, none of what is said here changes anything.  The market decides, not me or you.

here you go. forgetting your own "compatibility" flip flops

nodes that are "compatible" did not get to opt-out. they were sheepishly treated as accepting without option
those that chose to use nodes that oppose and want something else were thrown out.

(block rejections) (ban node)

consensus is not about rejecting blocks/banning nodes.
consensus is about having proposals. and those proposals only activate when there is majority community agreement

banning nodes and rejecting blocks first is not consensus. its about apartheid. (splitting the community and only accepting votes from one side) to fake a consensus

EG apartheid analogy
july 2017: 2 black people, 4 mixed race, 4 white people on a bus.
august1st 2017: get the 2 blacks off the bus and then not be concerned about the 4 mixed race
mid august: get the bus driver to count the votes of white people who want only white people on a bus.(4/4)
november 2017: now buses are only for white people


july 2017: 20% nonsegwit, 45% compatible, 35 segwit ready.
august1st 2017: get the 20% nonsegwit off the network and then not be concerned about the 45% compatible
mid august: get the corecode to count the votes of segwit1x flag who want only segwit1x on the network (35/35=100%)
november 2017: now the network only has segwit1x

remember 45% "compatible" were not voting. they were sheeped as abstainers

Let's imagine for a moment that I accept your definition that Non-SegWit nodes are not full nodes.  If that's the case, why does it even matter what the opinion of non-SegWit users are?  You can't rationally argue that you're not a full node but you should still have a say in what consensus is.  That makes no sense.  Would you like me to formally declare that you don't matter and leave that as the final argument?  Because I can do that if you want.  But it betrays the reality that you still have a voice in the rules that govern the network.  As I've stated before, if enough users ran the client you use, consensus would change.  If the software you run wasn't a full node, how could it possibly achieve that feat?



That's certainly one interpretation of the timeline.  Here's another:

Feb 25th 2017:  Shaolinfry, a Litecoin developer, posts the topic Moving towards user activated soft fork activation (https://bitcointalk.org/index.php?topic=1805060.0).  A small, but vocal, number of users like the idea.

March 31st 2017:  I compare UASF to a 'cold war' scenario (https://bitcointalk.org/index.php?topic=1805060.msg18404613#msg18404613), giving an indication that I wasn't partial to the idea.

April 14th 2017:  Gregory Maxwell goes on record as stating he does not support UASF (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html).

June 14th 2017:  Bitmain announce their "contingency plan" of launching an altcoin with a 72 hour premine.  Almost everyone thinks it's hilarious and/or terrible.  It is dubbed "bitmaincoin" and widely ridiculed.

July 16th 2017:  The Bitcoin cash fork is fomally announced by ViaBTC (https://medium.com/@ViaBTC/statement-on-bitcoin-user-activated-hard-fork-6e7aebb67e67) in response to something a Litecoin developer said on a forum.  

July 19th 2017:  BIP91, A "compatible" softfork proposal created by a non-Core developer, began to be signalled by miners.  

July 21st 2017:  Technically, BIP91 signalling wasn't due to commence until the 21st July.  Proof again that no one is in control.  It also marks the date I described UASF as a "User Anticipated Spectacular Falter" due to a total lack of support from nodes.

August 1st 2017:  BCH forked away as they announced they would in July.  No one forced them.  They freely chose to do it.  UASF was a total non-event.  I laughed.

August 8th 2017:  BIP91 was locked in by 90+% of the hashpower on the BTC network.  Some UASF supporters were extremely upset by this, as they felt their consensus had been bypassed, even though that's not actually a thing.  They thought their vision for Bitcoin was best and didn't care that they didn't have adequate support for their ideas.  Remind you of anyone?  The only difference is, many of the hardcore UASF supporters had the decency to move on with their lives instead of whining about it like a spoiled child for the next year or more.

Mid-August 2017:  BTC1/Segwit2x (which is unrelated to BCH and I don't see why you always conflate them unless it's to deliberately mislead users who weren't around at the time and wouldn't know any better) continued to raise the possibility of a hardfork and chose not to implement replay protection, so some users took the decision to run code that would disconnect them from the network.  BTC1/SegWit2x failed to launch anyway, so it didn't even matter in the end.

August 23rd 2017:  Segregated Witness is activated.

August 24th to November 2017:  Franky1 is still trying to figure out what's going on.  Apparently, he never does.

November 2017 to present day:  Franky1 eventually arrives at the conclusion that Core is somehow at fault for everything written above, even though anyone rational can see that's not correct and they really had very little involvement in any of it.  Franky1 perceives the above events as a dastardly conspiracy by a tyrannical group of developers who rule with a vice-like grip on power.  No one else appears to see it that way and naturally assume that Franky1 may have been dropped on his head a few too many times as an infant.

im laughing

the segwit supporters announced in spring (feb/march)
and even you show that the cash side didnt announce until june/july

so saying segwit side reacted to cash is funny..
cash reacted to segwit side

the uasf campaign began before april (USAF.co was Creation Date: 2017-03-22T22:19:32Z)
the UASF mentioned the august 1st date

bitcoin ABC began months later(bitcoinabc.org was Creation Date: 2017-05-09T14:59:42Z)

check the blockchain. you will see that all the events lead to the block 478558 being the target block

(core only accepted segwit flagged blocks at 13:23)

nodes opposing segwit couldnt stay on the network as is, so had to shift
(cash only accepted cash blocks at 18:12)

but it is funny how you try to down play segwit activation attempts as just small social stuff that didnt happen and how you avoid mentioning core devs.

goodluck in life. but blockchain data dont lie and even domain who-is search shows who started what

anyway putting doomad interuption aside.

having upgrade proposals that use mandated dates/blockheights is not consensus.
diluting the community in half is not the solution

if a proposal cannot get majority. devs need to compromise and say they need to go back to the drawing board and make a new proposal
not double down on same proposal by adding a new method to force the proposal acceptance via a date/blockheight threat of adopt or get banned/rejected, which fakes a vote by only counting less than half the community

Yes, UASF announced a split first, so Cash announced a split in response.  I thought I made that clear.  You don't need a domain whois search to show when UASF started, because that was literally the first thing listed in the timeline I posted.  Try to keep up.  But UASF didn't happen.  There was dedicated code for UASF.  If you wanted a compiled version of that code, you had to get it from a repository which was forked from Core's (https://github.com/UASF/bitcoin/releases).  It even says so right at the top of the page:

http://www.wearedecentralised.co.uk/forked.png

But when the time came, hardly anyone was running it.  UASF was a dismal failure in terms of actual participation.  It was an empty threat with no real weight behind it.  The BCH split clearly had a little bit more impetus, since it actually resulted in a legitimate fork.  You could certainly argue that the threat of a fork was enough to set events in motion, but then it could also be argued that they were jumping at shadows and, in the end, UASF was a big pile of nothing.  

SegWit was activated by miners.  Argue about it all you like, that's what actually happened.  It's only a "bilateral split" (see, I'm still on-topic  :P ) in the sense that neither side were going to back down and something had to give.



So tell us how you'd prevent anyone from doing that without jeopardising permissionless freedom.  Show your work, don't just provide an "answer".  How do you stop any one of the billions of human beings on this planet from creating code that divides the Bitcoin community?  Please explain.  I'd love to hear this.



Which developers are you referring to?  They don't all have to agree.  Developers are not a single, unified entity.  And they certainly don't "need" to make a new proposal just because you think they should.  Some of them did come up with new proposals.  Not all of them were well received.  That's how the split occurred.  People didn't agree.  You can't make them agree.  People do whatever they want, regardless of how much you whine about it.  And again, if we had to wait for all the developers and the entire community to agree on everything, you wouldn't even have that client you're running right now.  Every single argument you've ever put forward about consensus would result in a worse Bitcoin than the one we already have now.  I strongly recommend you stick to what you're good at and focus on that fee priority thing instead.

gotta love doomads persistance with person attacks and social drama.



by having the original consensus bip and the community stick to it.

you do realise if core did actually stick with the 2015 consensus of the early version community compromise of segwit2mb. core would have got segwit activated in 2016 without the august 2017 hard fork (THEY call bilateral split)
without the diluting the community. without all the delay.

and i do laugh that you still think core should control the network without community "permission"
seems you forget consensus and again flip flop in and out of it

make up your mind. EG
"Tell me, what makes you think users and miners can't do what gmaxwell described?  Show me in the code where it says that users and miners can't change the activation threshold for a fork.  Oh right, you can't, because the code can change depending on what people run."

^ so greg does need users and miners "permission" - "depending on what people run"

but yea i expect a fip flop about how greg can push his code through because he doesnt need communities "permission"
then later a post that greg has to abide by what the community "permit"

but you forget that if greg is using a inflight upgrade that makes 45% of nodes not need to opt-in or out. for something to activate or not. then greg adds code for his 35% friends to kill off the 20% that vote out.
then only counts his 35% friends.

thats not consensus.
the code to allow th backdoor activate or F**k off should not be used again. and should be stripped out.
but now we the community have no control because core would just say "we dont need your permission"
and dilute the community down to any opposers of core.

if you cant see that core are now a central power house. or your going to flip flip to deny they are central.. (the core) your missing the whole point of decentralisation and your missing why bitcoin was created to solve the byzantine generals issue without having to have a CORE general

(dont reply with a flip or a flop about saying does or doesnt need permission until you have convinced youself which. and then decide to stick to that narrative..
you have for months flip flopped in and out of needing or not needing. so try not to state other people are wrong unless you are ready to stick to one narrative)
)

anyway putting doomads personal conversation aside.. yet again

back to the topic.
if cash wanted to do as windfury said. who cares they are an altcoin.
it has no relevance to bitcoin

so heres an idea
if core wanted to propose something for the bitcoin network should we let them do another mandated certain date/blockheight upgrade which involves diluting the community again. or use the original consensus mechanism whereby if they dont get consensus they should tuck their tail between their legs and go back to the drawing board and think of something the community would accept without any splits

imagine core had a consensus vote of
20% strongly oppose
45% abstain
35% opt for

There is no flip flop, you simply don't understand what I'm saying.  Your grasp of the English language is atrocious.  Allow me to break it down for you in a way you might possibly comprehend (fingers crossed, but I won't hold my breath).  Here's the quote again:


Greg is pointing out that it is those securing the network who ultimately decide if/when a fork is activated, not developers.  Oddly enough, I agree with this statement, because it's true.  It is users and miners who decide consensus.  There is no permanent rule in the code saying that it always has to be 95% support to activate a change.  To demonstrate that this statement is correct and that users and miners decide, I asked you to show me in the code where it says users and miners can't change threshold for activating a fork.  Only it should be obvious that if code were introduced to say it always has to be 95%, that rule itself could still change if people ran different code.  So again, you can't make an argument as to why the above quoted statement is incorrect.  You don't actually have an argument, you just have a series of overly emotive and misguided pleas that don't actually mean anything.

The point is no one needs permission to code anything.  Not me, not you, not XT, not UASF, not BU, not Core, nor any other person or group.  You are the only one advocating that developers aren't allowed to code what they want.  And even if someone did agree with you (and there's no sign of that happening yet), there's no practical way to enforce it.  There is no code to prevent softforks.  You are advocating a social change because there is no code to achieve your desired goal.  You then cry "social drama" when anyone points out that what you are advocating is yet more social drama because what you want isn't even based on code or logic.  It's just one emotional plea after another with you.  You say it's about the code, but every "argument" you make boils down to a plea for people to not code stuff you don't personally approve of.  I'll say it again, none of us are here to go out of our way to appease you.  You don't always get what you want.  People can code stuff you don't like.  It's allowed.

No amount of you calling them "inflight updates" instead of softforks will change reality to prevent them from happening in future.  There isn't code you can "strip out" to prevent "backdoor activate or F**k off".  What you want is not possible.  Go play with fiat if you don't like softforks.  That's the only solution anyone can offer you.   


//EDIT:  Oh god, there's more.  For the love of fuck stop double posting.


"The original consensus mechanism", is not fixed.  You do not personally get to decide that we have to set in stone forever what the threshold for fork activation has to be.  It's just another one of those things that is not your call to make.  If everyone happened to agree with you that it has to be 95% forever, fair enough.  But I think that's an incredibly dumb idea and would result in a totally ossified codebase where nothing ever changes.  Maybe that's precisely what you want; a completely dormant and stagnant Bitcoin, mired in petty squabbling forever, while it is gradually surpassed by other market contenders you happen to hodl <cough>BCH</cough>.  I mean, who can even tell anymore with you?  There must be some reason for the insane drivel you spout.  It's only natural for some of us to assume it's malicious at this stage.



Imagine you actually understood consensus and realised it doesn't matter who the developer is.  Devs don't decide consensus.  How many more times?

he does flip flop

one minute devs can do what they please no one can stop them. next minute devs dont decide but the community does..

"there is no code to prevent softforks"        = users dont decide on changes
"devs dont decide consensus"                    = users do decide on changes
"devs dont need permission"                      = users dont decide on changes
"users and miners decide"                         = devs do need permission

flipity flop

also inflight upgrades is what Luke JR calls them

funny thing with you doomad is you argue if i dont use your dev buddies terms then argue when i do
funny thing with you doomad is you argue that community voted for segwit .. then argue core didnt need a vote and nothing to stop core activating
funny thing with you doomad is you argue that events didnt happen then argue they did.

now heres the point.
a dev can write code all he likes he can write it on a buttcheek of a thai bride, on paper, on github.
that has never been my argument. (thats your flaw)

the thing i am always addressing yet again for the upteenth time you meander topics into personal attacks. is about MANDATING enforcement that their code ACTIVATES within the network

how many times do i have to say mandate and consensus.
while you cry about writing code as your deflection

last funny part
doomad
show me cod where i an enforcing anything.
you keep on trying and failing to make things sound like i am authoritarian yet i am not the one with the code that demands, mandates and splits the network.

if you dont like my words hit the ignore button
the only people who are mandating network changes are devs.
so go argue with them about what they can and cant do because code doesnt write itself. rules dont write itself. the dvs write the rules so go argue with them about if they should b doing what they are doing.

oh wait.. your response "no one should tell a dev what to do...". while hypocritically doomad wants to cry and tell people on a forum to have no say, no opinion and not talk. purely because ......... well who knows why doomad dislikes opposing opinions
truly funny he thinks my words on a forum actually changes networks rules...
this forum is not github. its not compiled into a binary. so i do laugh when doomad thinks my words are stopping devs

you gotta laugh doomad really thinks this forum gets compiled into code and actually affects the network.
when he wakes up and realises only developers write code and its what they write that actually changes the network. he will realise that malicious changes to the network are the fault of devs.. not forum users.

anyway putting doomads personal conversation aside.. yet again

back to the topic.
if cash wanted to do as windfury said. who cares they are an altcoin.
it has no relevance to bitcoin

so heres an idea
if core wanted to propose something for the bitcoin network should we let them do another mandated certain date/blockheight upgrade which involves diluting the community again. or use the original consensus mechanism whereby if they dont get consensus they should tuck their tail between their legs and go back to the drawing board and think of something the community would accept without any splits

imagine core had a consensus vote of
20% strongly oppose
45% abstain
35% opt for

But when the UASF happened, would you agree that Segwit as an inclusive soft fork was better for the network because it did not throw anyone out of the network?


Were you against Roger Ver's "must fork to big blocks or be left behind" which caused a chain-split?


Is it FUD? You are the person who first told me about the idea of Bitcoin and Bitcoin Cash bilaterally split into two. Would you still have the same perception if Bitcoin Cash hard forked to double the monetary supply to 42 million?

The fork was actually a way to segregate the races, because they did not want to drive on one bus together, so they created two busses, one for the whites and one for the blacks. So, the fork was actually unforced "Apartheid" in the Bitcoin world.  ;D

Why should people be forced to ride in one bus, if there are enough busses for each of the races? They can even "fork" a bus for people who wants to ride together.  :D

The fork gives people the opportunity to decide what they want to do and this is why consensus is so important in the Crypto currency world. <Fork off and do your own thing>

Plus I believe franky1 has "community" and "miners" clumped in one group. The community wanted Segwit but Jihan and the mining cartel didn't. Miner signalling for its readiness to activate something does not represent the community.

Well you managed to get 1 out of the 4 correct.  That's actually not bad for you.

"There is no code to prevent softforks" = a user can either opt in or not, the choice is yours, but you can't stop others opting in.  Softfork code doesn't activate unless there is consensus.  SegWit was activated with 90+% of the network hashrate.  Cry moar.

"Devs don't decide consensus" = Correct.  Users and miners decide.

"Devs don't need permission" = They can code whatever they like, but if no one runs it, then they've wasted their time.  Case in point, UASF.  Hardly any users.  A developer made UASF but the code didn't do anything because there weren't enough users supporting it.  Clearly it's in the interests of devs to create code that users want to run.  Code doesn't do anything if no one runs it.  Stop pretending that just because Core code something, it means they're deciding what consensus is.  That's flagrantly dishonest.  As always, you refuse to acknowledge that users are freely choosing to run the code Core are creating.  Note that this is nothing to do with "giving permission", because permission doesn't count for anything here.

"Users and miners decide" = nothing whatsoever to do with "giving permission" to anyone.  What part of permissionless do you fail to comprehend?  Why would you want to introduce permission to a system that works perfectly well without it?  Users and miners run what they want, devs code what they want.  

Again, it's all just a bunch of people doing anything they want to do and market forces take care of the rest.  You can't stop people from doing the things they want to do.  And even if you could, it would be terrible for Bitcoin.  At all times, the network will naturally choose what its users believe is the best code overall at that given moment in time.  

november 2016-spring 2017 = natural normal consensus.

summer 2017=forced mandated= not natural

i said many many many times if core wrote segwit2mb as they said they would in 2015 the community would have accepted NATURALLY via original consensus segwit. because the opposers would have also got more base block.. thus majority happy naturally.
the thing is. what got activated was not done naturally hense why a year later (3 years of debate so far) people are still waiting for bitcoin scaling solutions


again
a dev can write code all he likes he can write it on a buttcheek of a thai bride, on paper, on github.
that has never been my argument. (thats your flaw)

again
a dev can write code all he likes he can write it on a buttcheek of a thai bride, on paper, on github.
that has never been my argument. (thats your flaw)

and again
a dev can write code all he likes he can write it on a buttcheek of a thai bride, on paper, on github.
that has never been my argument. (thats your flaw)

i know you want to deflect the topic and try to make is sound like im talking about what code they can write.

but no.. what im talking about is what code should be activated on the network.
segwit august 2017 was not activated by a united community vote of users and miners.
united communiy vote of majority=consensus
bilateral split=not comsensus
mandated or ban =not consensus
apartheid=not consensus

again
the thing i am always addressing yet again for the upteenth time you meander topics into personal attacks. is about MANDATING enforcement that their code ACTIVATES within the network

the thing i am always addressing yet again for the upteenth time you meander topics into personal attacks. is about MANDATING enforcement that their code ACTIVATES within the network

the thing i am always addressing yet again for the upteenth time you meander topics into personal attacks. is about MANDATING enforcement that their code ACTIVATES within the network

to other readers i am sorry for repeating myself but certain people poke into topics and meander into personal social dram of twisting information and making is sound like things such as
i was advocating splitting the network.. no i my opinion has always been CONSENSUS without MANDATED threats /forks
and
i want to stop devs writing code.. no my opinion is devs shouldnt use backdoors to change the network without consensus
and
how im authoritarian.. no i am not the one with the mandated threats and backdoor code that is a security risk to the network

its strange how certain people want to argue and defend the devs then realise the point is bitcoin network security again malicious activations/backdoors

my opinion use consensus to stay united and upgrade feature the majority community want = consensus
some others opinions if you dont like it f**k off = not consensus

to the point of the topic
to make it clear
I DO NOT ADVOCATE BILATERAL SPLITS

the community is EVERYONE
devs, users, miners

i think you and doomad have core devs and community confused. the core DEVS wanted segwit. but the community of all 3 circles couldnt agree

before the mandated threats. segwit only had 35% opt-in agreement of pools
before the mandated threats. segwit only had no real uptake/growth of core nodes
core didnt like those results. hense why lukeJr double downed with the backdoor method.

i think when i say bitcoin you only think of core..  and when i say core you only think of bitcoin. which is where the confusion you have begins

when i point out issues with core thats not me attacking the bitcoin network (again your confusion of it)
my opinion is the network/community should not be solely reliant on core. should not kiss their royal ring and sheepishly follow core devs whims.

now if you imagine the community being everyone. you start to actually picture how consensus should be a united community. and not a opportunity to kick half certain cirlces out if one circle wants something.
the endless cicle of cries that certain people have that core devs should have absolute right to do anything they like to the network is wrong.
yes let the write code. whether it be on github, a thai brides thigh or paper. release code. but saying they have the right to mandate its activation. is wrong.. as thats centralising the network to a core team

there needs to be united agreement where if for instance core propose something. they shouldnt simply get it activated due to them having a backdoor. or because they make threats and set deadlines.
if core dont get majority.. like they didnt in november 2016-spring 2017 then they should put their tail between their legs and redesign things / make a few tweaks to produce something the WHOLE community would like.

to save tim, not cause delay and actually save face. they could have actually listened to the community and obided by the late 2015 consensus which was a combination of users, merchants, devs and miners. who majority agreed to a segwit2mb
meaning by late 2016 they would have got their segwit AND the community also get 2mb baseblock
no drama. no delay. no fingerpointing, no splitting the network. no problems

Oh joy, more historical inaccuracies.   ::)

Events as they unfolded were once again totally different to the distorted events you describe:

People generally supported SegWit in some form or another (https://bitcointalk.org/index.php?topic=1969978.0), but could not agree on which form it should take.  Tell me which compromise you could even somehow manage to convince that small sample of the community to agree on, let alone the entire network.  8 responders out of 22 stated categorically that they would not accept 2mb + SegWit.  That doesn't quite fit your definition of "natural consensus", now, does it?  Come back when you have a clue and remember history as it actually was.

Even you clearly said (https://bitcointalk.org/index.php?topic=1969978.msg19602066#msg19602066) 2mb + SegWit was "weak" because "2merkle which is cludgy code".  
Then I suggested you could be a little more mature about it (https://bitcointalk.org/index.php?topic=1969978.msg19622938#msg19622938).  
Eventually you capitulated and described it as "better than nothin (https://bitcointalk.org/index.php?topic=1969978.msg19732155#msg19732155)" (which, technically, wasn't really an improvement over "weak").  
But sure, keep telling us how you supported 2mb + SegWit all along and that everyone in the community "would have accepted 2x naturally" when they clearly didn't.  Even you didn't agree with it until you eventually realised it was probably the closest thing to your beliefs that you ever had a remote chance of actually getting.  

(facepalm)
never said i fully supported or advocated for segwit2mb
as i have said.. community COMPROMISE to come to a consensus

EG the group that wanted 16mb, 8mb, 4mb  ended up compromising to 2mb
other groups that just wanted legacy compromised to accept segwit as long as it was more then 1mb base block

but yea just to end the debate and get things running if core actually held onto the 2015 consensus debate of segwit2mb they woulda had much more progress in late 2016

.. the funny part is the colourful chart you supplied. was a poll done AFTER certain events and drama. which swayed peoples minds in one direction or another.

but its usual for you and your buddies to pretend i say one thing . that i advocate things. when in fact i dont.
but anyway your deflecting
it clearly says better than nothing.. not love and adoration and full advocation of segwit
it clearly says better than nothing.. not love and adoration and full advocation of forking the network

this topic is about the split/fork. caused by MANDATED activation via events of august first. which the august 1st date was chosen by the segwit side.

anyway. you are still just trying to defend a dev and not talking from a secure blockchain network mindset.
so have a nice day.
(you might have a better day hugging a dev than trying to poke people that dont kiss a devs ass, because we value bitcoin security far more than dev reputation)

If it increases the block size and total supply will make things worse. If this happens, will the price drop by half? And who are the owners of the supply of additional supply? Who owns it get benefits from this? Any reason I believe in this?

if it doubles the total coin supply. then deflation is dead. mindset changes from "guaranteed limit" to "if they done it once they will do it again"
trust is lost and people dont value the coin anymore as a store of value

summary
its funny that people poke and finger point at me. yet i am not the one writing code that mandates crap.

if people dont like my opinion
if people dont like that i simplify explanations with analogies
if people dont like that i dont kiss a devs ass
if people dont like that i dont use devs buzzwords.. but then dont like it when i do use their buzzwords

then just get on with your lives. hit the ignore button and enjoy your blissful life of dev hugs

ill continue to care about the bitcoin networked utility and security. i care not for a devs reputation.. they will move on retire, change jobs, get bored at somepoint way before bitcoin. so ill concentrate on long term security of bitcoin. not short term financial security of a devs sponsorship ability
the core devs have plenty of funds, well over $100m to split between themselves so its not like they are starving and going to be eating chicken nuggets as their christmas meal.. so its not like they need protecting

i know some people want this forum to only contain a utopian empty promise rather than real open discussions of flaws. but in the real world its better to speak up when there are flaws. to atleast seek to get the flaws solved, or atleast warn others that things are not as they seem

if you only want to see the utopian fluffy clouds. press the ignore button and go find the fluff you seek

Ok, then we are in agreement that Segwit truly had consesus when it was activated without "2X" last year. The economic majority expressed themselves on what they wanted, and the miners followed. Consensus.

Claiming an idea which Bitcoin and Bitcoin Cash bilaterally split into two does not make it real. I wouldn't say Bitcoin Cash hard forked to double the monetary supply to 42 million. I understant that they want to leave the BTC network and make another one. But free fall of bitcoin price is not an opportunity for them, because these prices effect badly everything on the market.

no
the community got divided. many were thrown off the network
not by desire to be thrown off the network. it was oh crap some nodes are gonna get banned

so they ended up a couple months after being told they are getting thrown off they had to:
.agree and rewrite their nodes to be full nodes
.just stall out if they had code that received full blockdata that disagreed with segwit1x
.became not full node by recieving stripped data just to remain on the network (become "compatible" <-devs buzzword)
.or create an altcoin

there wasnt a option to just say no to segwit1x on august 1st and prevent an activation. it was mandated

seriously this is not a thing you can decide by conversations. its something you have to realise by looking at the statistics and seeing what actually happened.
many stats exist

i have a question for you. are you trying to change history for a reason?
is it just entertainment for you and your buddies?
is it that your one of those flat earther/holocaust deniers that just loves twisting things?
is it that you cant actually research?

if you cant see that a true consensus bip had a november 2016 to november 2017 date, with no mandatory obligation or bans
where that consensus had no code related to anything around august.

if you cant see that a controversial hardfork bip occured in august due to code stating in august something will happen whereby it was mandated. thus not consensual .
cutting the community up and coercing the vote via diluting out opposers, ignoring some abstainers and only counting those that agree

then maybe best to you do some research.
it was not natural consensus. it was mandated
learn mandated
the word contains two word  man-date
a date chosen by man

august 1st was not consensus of do not activate unless 95% of whole community agree. because the consensus 95% was not counting the whole community because the community got divided to fake count an activation

and i can pre-empt your next ploy
it was not a consensual agreement to split it was a controversial split.
its the devs that call it "bilateral" where they wish to think the words mean joint agreement to split. again no it was a reluctant controversial split
some define the bilateral split to mean 2 splits because segwit split away from just being legacy code and cash split away from segwit

but long story short there was no way to avoid segwit1x activation due to the mandate
and who created the mandate. those wanting segwit1x

anyway moving on
in future using mandated,forced,coerced, backdoor methods to change the rules should be treated as bad
and thats the ultimate point

"The SegWit side"?  Not all supporters of SegWit supported UASF. 

So, not only are you deliberately and misleadingly conflating the actions of UASF with the actions of Core (separate repositories, the UASF client was forked from Core's GitHub), you're also deliberately and misleadingly conflating the actions of UASF with the actions of every single person who thinks SegWit is a good idea. 

If a random user you've never heard of created a new client with a flag-day activation of Aug 1st 2019 which implemented an idea Core are currently developing, say Schnorr for example, would you instinctively blame Core, along with everyone who has ever said Schnorr is a good idea, for that too?  Even if they weren't actually supporting that particular flag-day activation?  Is that how your reasoning works?

Segwit is an inclusive soft fork, if a small group in the community did not want to upgrade their nodes, then they were free not to upgrade. The network would still be whole.

The "many", are not many, and they hard forked and split away from the network. It was their desire to change the consensus rules by increasing the block size, and thrown off the network.


Banned by not upgrading their nodes? What? There was no such thing.

So, you're advocating putting aside any kind of technical arguments for or against and encouraging people to just jump on a bandwagon and bash anything you don't like the sound of under some vague assumption that it's "bad"?

And there I was with the impression that you didn't like REKT campaigns...   ::)

I guess they're suddenly okay when it's something you don't like.  I'm glad we've taken this valuable opportunity to get your moral compass figured out. 

But you have to appreciate the debate from franky1's perspective. Although, some of them believe what they want to believe, and gaslight their way to win a debate because they know some newbies will pick it up and believe it as the truth.

Read this, https://whowhatwhy.org/2016/01/27/disinformation-part-1-how-trolls-control-an-internet-forum/

Well its a TWO-FER as we call these things, either way BITMAIN wins cuz they own both, ... so to diversify the risk, in case the segwit is the right idea party A spawns a clone of A called B, and B become successful or not.

What difference does it make when the OWNER owns both A & B, and then back to this forum where the minions quabble about how many segwits can dance upon a needle, in the MEANTIME "JACK MA" is counting real money, and selling BITMAIN-GPU-ML-ID boxes by the millions to the chinese GOV.

I love how at one time BITMAIN only accept btc-cash for an S-9 which meant you had to sell BTC to get BTC-CASH, had he not done that I think Bcash would have had ZERO capitalization.

funny part is. you have not read code.

under bip9 its not a "dont like it F**K off" its just a well you didnt get adoption. so put tail between legs and go back to drawing board. dont mandate.

in the last 9 years only one team/group mandated change. because THEY were not happy with the result.

my mindset is if your proposal doesnt have TRUE majority.. then rip up your roadmap and try a new road design. dont just throw tarmac down and demand crap.

but i do laugh how you pretend how those that never had any mandating code are some how the badguys.
logic fails you everytime.

as for windfurys "gaslighting" buzzword of the season. couple years ago the word your friends group followed was "ad-hom".. then "conservative". i think its time you ask your preacher for the next buzzword for you to mention.

im starting to thing the over use of certain buzzword when making personal comments might has some sort of point system behind it. like a game how many times can you slip it into a conversation unnoticed

so my defense is the immutible blockchain height numbers. locked in history which shows who flipped the switch.
so my defense is the bip CODE that was the switch. which can easily show "i cant force sgwit2mb' luke Jr hypocrit coding the mandate

your defense.
a blog post from some website that core defenders probably treat as their bible
come on. show some stats, blockheights, chainhash heights. something real thats not just social drama..

you do realise the propagandists follow the bible of quoting quotes from social sites as "proof". meanwhile i just tell people about real data they they can do real research on.

stick to facts. Luke Jr and chums are not "random user"
mandated code was done by the segwit/core guys.
even mr samson Mow earned a job from blockstream due to his role in it.
he even made a baseball cap and got the group to wear them and social drama the hell out of it.

The author was an unknown developer named Shaolin Fry. As I remember it, Luke Jr audited the code after Shaolin Fry posted on the mailing list and he later promoted it. But there was a lot of division among Core developers, which is why Core never merged the code.


There was never any "mandated" code.

lol im laughing so hard
luke JR was talking about soft forking it in since 2015
shaolin puppeted it in 2016
luke wrote the code.
luke and buddies promoted it.

go research it.. oh and that does not mean reddit research or quotes of conversations.

im laughing that people are pretending august 2017 never happened..
such a shame.. but the blockchain never lies. its wrote in the blockchain if you know what to look for

and yes there was code
heres one early version
if ( (nMedianTimePast >= 1501545600) &&  // Tue 01 Aug 2017 00:00:00 UTC
     (nMedianTimePast <= 1510704000) &&  // Wed 15 Nov 2017 00:00:00 UTC
     (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&  // Segwit is not locked in
      !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )   // and is not active.
{
    bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS;
    bool fSegbit = (pindex->nVersion & VersionBitsMask(chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGWIT)) != 0;
    if (!(fVersionBits && fSegbit)) {
        return state.DoS(0, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
    }
}


anyway while you lot ramble on for pages trying to social drama deny history like some nazi holocaust deniers...
ill carry on pointing out that core centralists are not decentralists.

if you want to kiss core ass, carry on.
ill carry on highlighting issues that are aimed at raising awareness of things that negatively affect the bitcoin network

have fun in your little cabin of circular talking about how great your kings are.
oh and before you continue denying luke Jr's involvement. you might want to actually check because he had been actively promoting his involvement. so it's very strange for you to denie his connection to UASF

its like your defending people that dont need defending. thus i go back to my other topics points of you lot just created social drama about things you know nothing about just to twist history.

That code was specifically designed to prevent a chain split, you utter putz.  Your ability to take well-intentioned ideas out of context and portray them as something malicious is truly astounding.  The code was written by James Hilliard, whose primary contribution is BIP91, which was largely responsible allowing miners to activate SegWit with consensus, which was the nail in the coffin for UASF.  What point are you even trying to make?

Here's the full mailing list post (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014508.html) for anyone who would like to take a look for themselves at the motivation and rationale behind that code.

Franky1 frequently likes to alert the readers' attention to the 'ignore' button under his avatar, so I'll do that for him now just in case anyone needs assistance finding it.

I believe in btc as it is a great coin to consider for the long-term investment. To my mind, it is really great to invest in it because it is going to be the best one with time and it will be able to become viral

1. rejecting legitmately good block formats that are valid for 8 years is what that code done
it rejects blocks that are not segwit. again anyone opposing segwit gets rejected

2. wait you said there was no USAF and USAF done nothing.. now your saying it done something by preventing the actual thing it caused.. dang.. thats your worse flip flop ever.
what the mandated code does is reject any opposers who want to continue relaying a full block thats not segwit
SEPARATELY there is other code that prevents cores sheep from forking by the "compatibility" stripping of blockdata.

atleast read some code. ill give you a hint to where your research about the compatibility stripping and the ability to be a full node differ --iswitness

3. you can spend 30 years flip flopping social drama. all i need to do is show the code and anyone reading iit can see it. i can show the blockchain data.. and you will have to then restart 30 years of your social fakery..
all it takes is looking at the facts. block data is immutable. your flip flops are just temporary drama.

4. using a mailing list post from june has nothing to do with code.
oh and if you want to pretend luke JR had nothing to do with it.. you should check with him first. he will tell you he was involved. he's even promoting his involvement in his linked in profile

so i see no reason why your trying to down play his actions when he himself wants to highlight his actions.
he loves that he trojaned in segwit its his number one accomplishment

5. seeing as how u like to go around in circles refer to point 3 then re read point 5,

Taking small segments of code out of context isn't going to help your cause (Nor is whining about past events after the fact, for that matter *).  Anyone who understands code would naturally want to see the whole thing (including all the parts you deliberately withheld because you're a shitweasel) to understand the full effects of that code.  Me linking to "a post from june" provides the full code you are trying to conceal:


That first part is kind of important for context.  Split protection.  Avoid splits.  Splits bad.  

IF SegWit is locked in (via consensus, learn consensus)
THEN reject non-SegWit (to avoid splits, splits bad)

Got it?

I don't know how much more simple anyone can make it for you.  But congratulations on undermining your own argument once again.


* Say what you will about REKT campaigns, but at least all the ones prior to the REKT campaign you're currently failing to get off the ground had the common sense to torpedo the things they didn't like before it was 15+ months too late to do anything about it.  Even by your standards, what you're trying to do is dumb.  

LOL

read it properly
just because someone puts a //comment called splitprotection
does not actually protect nodes from splitting.

also the first part called splitprotection
if { segwit split protection threshold is met & segwit not locked in and not active then reject non segwit blocks }

your chums were saying there was no bip148 code.. so thats why i shown bip 148 code, which basically is

bip 148
if ( date is after august 1st and segwit not locked in and not active then reject non segwit blocks }

both are saying to reject non segwit. and both are 2 separate functions.
you can tell by the {} which make the separate

what you fail to understand is that the "self protection". rejects
what you fail to understand is that the "bip 148" is the bypass to reject even if threshold is not met (b making it date prescribed reject)
they are 2 separate things.
your group of chums wanted to deny the existance of bip 148 code. so i provided 148 code.

now your flip flopping to the meander of trying to now talk about a different function outside of bip148, a different function that is commented as being called splitprotection but does not actually mean split protecting


again elsewhere SEPARATELY you will find the way they kept the abstainers inline and not split off the sheep side with the "compatibility" you dont get a vote trick..
so here is the hint again --iswitness
where you find that reference is the area you need to read specifically how that 'call' also has a part where nodes that dont call it get stripped data.(the bypass)

however objecters/opposers that wanted to stick to old rules.. would get split off..

but it seems you cant even read and be able to count {} to realise splitprotection function is a separate function to 148.
.. once you understand that. then you can go read more and realise that both function reject blocks.

you cant avoid a split by rejecting blocks, as thats how splits are caused.

again you can spend 30 years with your social campaign to pretend things didnt happen. but they did.
the code shows the date of august 1st. even you have it. so you cant deny it now either

but i do find it funny how you think naming a function split protection means it magically protects.. yet just a few lines down you read the actual actions cause rejections.

..
how about you go learn something and go social drama some noob where you might get a chance to pretend you know something

so while doomad spends his life flip flopping with his chums
lets address this topic

the whole point of this topic appears to be
some group of people that cant read code and are defending developers that dont need defending because the developers are happy to admit their involvement.

this same group are then pretending code doesnt exist. and then when shown it does. meanders the conversation to talk about a separate function that is named something. but does not achieve its namesake

all to social drama meander away from the point that:
on august first a split did happen. theres code. theres even blockheight data proof
the name bilateral split came from the mouths of the developers (gmax buzzword) not me.
the developers are proud of their trojan
they are proud to have bypassed objectors

thus all this lil social drama group has done is caused social drama
all while the developers have now got a back door way to change the network as they deem fit.

"Back door".   ::)

Anyone who ran the UASF client clearly knew exactly what the effects of that code were.  Some were purely interested in activating SegWit as swiftly as possible, while some also wanted to give the miners a bloody nose as they felt miners held too much influence.  Plus, as stated before, not many people were actually running that client anyway.  BIP91 is the code that effectively broke the deadlock and avoided a split.  A "back door" implies that devs can do something in secret that users aren't aware of.  It can't simultaneously be something they're doing in secret whilst also being "luke and buddies promoted it".  Devs can't just "change the network" at a whim because their code does nothing if users and miners don't use it.  As always, your problem boils down to the fact that users and miners did run code that you don't like and there is absolutely nothing you can do about it, other than whine incessantly.

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.  If you want to cry like an infant because supposedly bad people did supposedly bad things, go ahead.  That's about the extent of your influence here.  It's not a conspiracy.  People did what they wanted to do and now SegWit is activated.  Similar changes could happen again in future and there's nothing you could do to stop it.  Choose the blockchain or blockchains you want to be on and get over yourself.



That's generally how forks work, yes.   ::)

You'll notice, however, that you still have the choice to be here on the BTC network even though you haven't embraced the new rules.  Some might be grateful for that opportunity, but apparently all you can do is complain about the fact that you haven't been forked off yet.  I suppose that's probably the best argument against softforks you've come up with so far.  It means we still have to share a network with you.  That is a real concern, now that you mention it.  Tangible and lasting consequences that we'll have to deal with for many years to come.

consensus is suppose to be where the network opt-in and agree a new feature if wanted
compatibility is where a feature is added without opt-in
the mandated date is the attack date with no opt-out while remaining on the network

i can guarantee you that if a non-core dev team done the exact same thing. you would cry how its an attack on the network

but you can continue flip flopping in and out of consensus and non mandated. to then compatible and mandated  for th next 30 years.
but the data is what the data is.
might be worth you spnding time reading it.

as for "anyone who ran UASF"... those were the trojan army of segwit. not the native community.
calling a horse compatible and just let it roll on in. from august 1st or else is not letting people have free choice.

but anyway. carry on with your social drama. but data is data. blockheights, code and even th devs themselves are literally telling people that they done what they done but actually coming up with terms like bilateral splits(gmax).. luke is happy with his inflight upgrades

he spend months and months saying how things can be done without a vote.
yet august 1st still happened where blocks were rejected, and peers relaying those blocks got banned.
a fork did actually occur on august 1st.

i find is so strange how you are denying such obvious things.

anyway waste years of your life defending devs for reasons unknown to me, and probably unknown to them because they admit what occurred.

i meanwhile will highly things that affect the network. i dont care about kissing a devs ass.. dvs are temporary. they get old, they retire they move on to other projects. there is no reason to treat them like immortal kings..
to me bitcoin network is the immortal thing we should defend. not developers

but you carry on with your blurred vision that devs are immortal and that they should own the network and do as they please to the network

prime example of flip flop

doomad pretends nothing happened


then admits one happened

flip flop flip flop

he cant agree with himself if a split was avoided or occured.....
maybe he should take a few hours out, sit on a sofa with a cup of coffe and argue with himself until he can agree with himself if one occured or not. before getting into social drama trying to prove then disprove one happened to other people

meanwhile blockheight data of the chains, code and even dev quotes and even devs own buzzwords which THEY advocate. prove a split happened

you can spend years arguing with yourself about if a split happened or didnt happen. all ur doing is arguing with urself.

meanwhile the reeal debate is HOW and WHY
which goes back to the mandated, compatability, nya 3 card trick

Why does any of that matter?

Luke pointed out Segwit could be implemented as a soft fork in 2015. That later resulted in BIP141. What does that have do with BIP148, the subject of discussion? (Hint: It doesn't -- you're just trying to distract people)

This was shaolinfry's first post on the mailing list about the issue (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html). Could you point out where Luke wrote the code, or was involved prior to March 2017? Why isn't Luke listed as a contributor (https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki)?

Anyway, Luke doesn't represent Core by any means -- thank goodness. He's been ridiculed pretty harshly by other Core developers at times. Prominent Core devs like Pieter Wuille, Greg Maxwell, Matt Corallo, Jorge Timon and Alex Morcos opposed BIP148. It wasn't merged into Core for good reason.

Luke-jr's commits are all over the UASF GitHub (https://github.com/UASF/bitcoin/commits?author=luke-jr).  He definitely either wrote or ported a decent chunk of the UASF client code.  But, as you point out, that doesn't mean the code was endorsed by other members of the Core team.  I don't know why Franky1 thinks devs are some sort of hive-mind who act in unison.  Or why he thinks any developer is going to listen to him when he tells them not to write code utilising softforks or arbitrary activation dates.  I certainly didn't agree with the UASF project, but I still defend their right to create it.