Pages:
Author

Topic: Do some people still believe that Bitcoin "Core and Cash bilaterally split"? (Read 742 times)

legendary
Activity: 3724
Merit: 3063
Leave no FUD unchallenged
luke wrote the code.
luke and buddies promoted it.

Could you point out where Luke wrote the code, or was involved prior to March 2017? Why isn't Luke listed as a contributor?

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.  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.
legendary
Activity: 1666
Merit: 1196
STOP SNITCHIN'
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.

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. Could you point out where Luke wrote the code, or was involved prior to March 2017? Why isn't Luke listed as a contributor?

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.
legendary
Activity: 4214
Merit: 4458
prime example of flip flop

doomad pretends nothing happened

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

then admits one happened

That's generally how forks work, yes.   Roll Eyes
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
legendary
Activity: 4214
Merit: 4458
all while the developers have now got a back door way to change the network as they deem fit.

"Back door".   Roll Eyes

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.

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
legendary
Activity: 3724
Merit: 3063
Leave no FUD unchallenged
all while the developers have now got a back door way to change the network as they deem fit.

"Back door".   Roll Eyes

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.


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

That's generally how forks work, yes.   Roll Eyes

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.
legendary
Activity: 4214
Merit: 4458
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.
legendary
Activity: 4214
Merit: 4458
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
legendary
Activity: 3724
Merit: 3063
Leave no FUD unchallenged
4. using a mailing list post from june has nothing to do with code.

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:

Code:

// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
Consensus::Params& params)
{
    LOCK(cs_main);
    return (VersionBitsState(pindexPrev, params,
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
THRESHOLD_LOCKED_IN);
}

// SPLITPROTECTION mandatory segwit signalling.
if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
THRESHOLD_LOCKED_IN &&
     !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");
    }
}

// BIP148 mandatory segwit signalling.
int64_t nMedianTimePast = pindex->GetMedianTimePast();
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");
    }
}

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.  
legendary
Activity: 4214
Merit: 4458
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");
    }
}

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 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.

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,
member
Activity: 321
Merit: 10
WPP ENERGY - BACKED ASSET GREEN ENERGY TOKEN
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
legendary
Activity: 3724
Merit: 3063
Leave no FUD unchallenged
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");
    }
}

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 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.
legendary
Activity: 4214
Merit: 4458
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,

stick to facts. Luke Jr and chums are not "random user"

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.

mandated code was done by the segwit/core guys.

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.
legendary
Activity: 1666
Merit: 1196
STOP SNITCHIN'
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,

stick to facts. Luke Jr and chums are not "random user"

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.

mandated code was done by the segwit/core guys.

There was never any "mandated" code.
legendary
Activity: 4214
Merit: 4458
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,

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.

legendary
Activity: 4214
Merit: 4458
in future using mandated,forced,coerced, backdoor methods to change the rules should be treated as bad
and thats the ultimate point

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...   Roll Eyes

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/

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.
legendary
Activity: 4214
Merit: 4458
in future using mandated,forced,coerced, backdoor methods to change the rules should be treated as bad
and thats the ultimate point

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...   Roll Eyes

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.  

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
member
Activity: 182
Merit: 30
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.

Oh joy, more historical inaccuracies.   Roll Eyes

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

People generally supported SegWit in some form or another, 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 2mb + SegWit was "weak" because "2merkle which is cludgy code".  
Then I suggested you could be a little more mature about it.  
Eventually you capitulated and described it as "better than nothin" (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.  

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.
legendary
Activity: 2898
Merit: 1823
in future using mandated,forced,coerced, backdoor methods to change the rules should be treated as bad
and thats the ultimate point

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...   Roll Eyes

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/
legendary
Activity: 3724
Merit: 3063
Leave no FUD unchallenged
in future using mandated,forced,coerced, backdoor methods to change the rules should be treated as bad
and thats the ultimate point

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...   Roll Eyes

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. 
legendary
Activity: 2898
Merit: 1823
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.

the community is EVERYONE
devs, users, miners


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.


no
the community got divided. many were thrown off the network
not by desire to be thrown off the network.


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.

Quote

it was oh crap some nodes are gonna get banned


Banned by not upgrading their nodes? What? There was no such thing.
Pages:
Jump to: