Do some people still believe that Bitcoin "Core and Cash bilaterally split"?

[squatter]

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.

[franky1]

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.

[DooMAD]

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.

[Jackolantern]

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

[franky1]

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,

[DooMAD]

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:

<pre>
// 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");
    }
}
</pre>

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.  

[franky1]

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

[franky1]

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.

[DooMAD]

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.

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

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.

[franky1]

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.

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

[franky1]

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.  

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

[squatter]

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.

[DooMAD]

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.