BIP-110 / Knots Designed To Fork Off From The Beginning (and fail)

[DaveF]

Coped from:
https://www.reddit.com/r/bitcoinismoney/comments/1tionym/bip110_was_designed_to_fork_off_from_the_beginning/
But since he sums it up so well I figured it was worth a mention here. Because sooner or later the mod of r/bitcoinismoney will probably remove the post since they are pro 110 and remove a lot of anti 110 stuff.

BIP-110 nodes aggressively attempt to connect to 8 outbound BIP-110 nodes using normal Core rules, and only connect to 0-2 non-BIP-110 nodes as an optional "sidecar".

The net result is that BIP-110 nodes barely participate in the wider network; from the beginning they formed their own network that is sparsely connected to Core nodes.

The original networking code was even more aggressive; the outbound sidecar was added only after BIP-110 nodes were having trouble being connected at all, and inbound connections could not sustain them.

There's only one reason to do this: if you assume you're going to be the minority in a partition. This helps defend against eclipse attacks and stranded nodes in the event that a split/partition happens, and you are on the losing side.

This is actively harmful if you expect to be the winner though: partitioning off your nodes into a big ball doesn't do anything to pressure Core if you have majority support. And it's pointless before flag day.

The BIP-110 networking code gives away the author's true beliefs: BIP-110 would fail to attain a majority in hash or nodes, and would fork off.

Code:

 // BIP-110: Allow up to 2 non-BIP110 outbound peers.
        if (pfrom.ExpectServicesFromConn() && !(nServices & NODE_REDUCED_DATA)) {
            if (m_num_non_bip110_outbound >= 2) {
                LogDebug(BCLog::NET, "peer lacks NODE_REDUCED_DATA and already have 2 non-BIP110 outbound peers, %s\n",
                         pfrom.DisconnectMsg(fLogIPs));
                pfrom.fDisconnect = true;
                return;
            }
            ++m_num_non_bip110_outbound;
            pfrom.m_is_non_bip110_outbound = true;
            LogDebug(BCLog::NET, "connected to non-BIP110 outbound peer (%d/2), %s\n",
                     m_num_non_bip110_outbound.load(), pfrom.ConnectionTypeAsString());
        }

....

// Count the number of BIP110 full-relay peers we have (excludes non-BIP110 peers).
int GetBIP110FullOutboundConnCount() const;


....

// Non-BIP110 outbound peers are "additional" - don't count toward limits
if (pnode->IsFullOutboundConn() && !pnode->m_is_non_bip110_outbound) nOutboundFullRelay++;

BIP-110 starts at block 961,632 at that point mined blocks must signal bit 4 or BIP-110 nodes reject them.
ANY block mined after 961,632 not signaling 4 will be rejected by knots /  BIP-110 nodes as a consensus failure.

So in a little less then 3 months they are either going to change their code or fork.

Self moderated for 2 reasons.

1) Some people (well at least 1 person) has been crossing the line with personal attacks.

And this is the important one

2) If you say no that is not going to happen or anything code related. You need to post the code or at least point out in the code why what you said was true.

So I can say YES knots / 110 will reject blocks starting in early August because of this code:
in https://github.com/bitcoinknots/bitcoin/blob/29.x-knots
Looking in src/validation.cpp: The ContextualCheckBlockHeader function evaluates the block's nVersion header against active VersionBits states. If the height falls within the mandatory signaling window starting at 961,632 ending with 963,647 and the block's version bit mask does not include Bit 4 because of vbrequired, it generates a consensus error, marks the block as invalid, and rejects it

This thread is NOT to discuss knots / 110 being good or bad.
It is not to discuss what miners may or may not do.

It is just to point out the technical reasons why unless a bunch of miners do start signaling and supporting the 110 chain is going to fork off (or split off if you like that term better) and unless they do something about the difficulty, fail.

-Dave

[Satofan44]

It is just to point out the technical reasons why unless a bunch of miners do start signaling and supporting the 110 chain is going to fork off (or split off if you like that term better) and unless they do something about the difficulty, fail.

-Dave

Technically you are correct here. They only have 2 choices as you have outlined here:

So in a little less then 3 months they are either going to change their code or fork.

I am not sure if Luke-jr has the guts to fork himself away with his bullshit like Roger Ver did, as that requires a different kind of delusion -- prideful fragile-ego delusions, such as when you are sitting in a room full of people and you are by far the most stupid one but you refuse to accept it, that is what happened with Roger Ver. Luke is more of a religious fanatic, a zealot with many obsessions and inconsistencies. While there are many similarities between the two types, at times when faced with the same situation they will act differently.

Here is my personal opinion on it: They will back out in the last moment with some bullshit reasoning in the style of savior-related obsessions (I have to continue to fight to save Bitcoin even if almost nobody believes my lies, the chosen savior) , so a code change will happen. What I do wish to happen though: They change nothing, they fork away into their own useless shitcoin.

Self moderated for 2 reasons.

1) Some people (well at least 1 person) has been crossing the line with personal attacks.

And this is the important one

2) If you say no that is not going to happen or anything code related. You need to post the code or at least point out in the code why what you said was true.

This is highly recommended, this section is full of shitposting idiots and has the occasional troll. Whenever you want to hold a real discussion on something, make the thread self-moderated and you will see how many signature spammers stay away -- that is how much they care about shitposting their quota with the least amount of effort, they don't usually even want to risk getting 1 post deleted.

[PepeLapiu]

BIP-110 nodes aggressively attempt to connect to 8 outbound BIP-110 nodes using normal Core rules, and only connect to 0-2 non-BIP-110 nodes as an optional "sidecar".

I don't believe that's true. My BIP110 node has 23 peers and only 1 of them is a BIP110 node.

Furthermore, if you don't like the idea if preferencial peering, you should look into OpenRelay. It's a fork off of core by peter todd (small caps intended), with preferencisl peering to other OpenRelay nodes and all filters removed. Expressly designed to promote spam on bitcoin.

You coretards are just being silly. For the last 6 months, you kept claiming we are going to end up hard forking.. As if we would give up on bitcoin, and buy into an altcoin, surrendering BTC to the spammers and core.

And now you claim that a hard fork was our plan all along?

Coretards: Please fork off and leave us to spam bitcoin all we want.

Also coretards: Knots is secretly conspiring to hard fork.

Edit: I actually asked Luke about this. He confirmed that Knots does preferential peering. He said Knots has always done preferential peering since the very beginning. He thinks there is something wrong with my node for it to be connected only one Knots node.

[ertil]

For the last 6 months, you kept claiming we are going to end up hard forking

You still don't know the difference between hard-fork, and a minority soft-fork.

When soft-fork is supported by 51% or more hashrate (the more, the better, which is why 80% or 90% is highly recommended), then all clients land on the same chain. But: if some soft-fork is activated, even if only a small minority is supporting it, then it becomes a minority chain.

If you trace the story of Segwit, then note one important thing: it was not activated, when it was supported by minority. Which is different than in BIP-110 case, where activation is forced in the client.

Which means, that BIP-110 client will reject the heaviest Proof of Work chain, and enforce its new rules, even if it would point node users into a minority chain.

Also, to see the chain forking, there is no need to produce any "anti BIP-110 chain". The only thing, that is needed, is to use the old version, which will include any transaction, which will be rejected by BIP-110 nodes. A single transaction in a single block is all, that is needed, to fork the chain. So, do you really think, that 99% clients will upgrade, and absolutely nobody will produce a block with such transaction? Because nothing else is needed, to split the chain.

Link to the code: https://github.com/bitcoinknots/bitcoin/blob/29.x-knots/src/validation.cpp#L4651

Code:

static bool ContextualCheckBlockHeaderVolatile(const CBlockHeader& block, BlockValidationState& state, const ChainstateManager& chainman, const CBlockIndex* pindexPrev) EXCLUSIVE_LOCKS_REQUIRED(::cs_main)
{
    const Consensus::Params& consensusParams = chainman.GetConsensus();

    // Mandatory signaling for deployments approaching max_activation_height
    for (int i = 0; i < (int)Consensus::MAX_VERSION_BITS_DEPLOYMENTS; i++) {
        const Consensus::DeploymentPos pos = static_cast<Consensus::DeploymentPos>(i);
        const ThresholdState deployment_state = chainman.m_versionbitscache.State(pindexPrev, consensusParams, pos);

        if (DeploymentMustSignalAfter(pindexPrev, consensusParams, pos, deployment_state)) {
            const auto& deployment = consensusParams.vDeployments[pos];
            const bool fVersionBits = (block.nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS;
            const bool fDeploymentBit = (block.nVersion & (uint32_t{1} << deployment.bit)) != 0;

            if (!(fVersionBits && fDeploymentBit)) {
                const std::string deployment_name = VersionBitsDeploymentInfo[i].name;
                return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS,
                                   "bad-version-" + deployment_name,
                                   strprintf("Block must signal for %s approaching max_activation_height=%d",
                                           deployment_name, deployment.max_activation_height));
            }
        }
    }

    return true;
}

Also, you can see DeploymentMustSignalAfter implementation, to get the exact block number, when the split will likely happen: https://github.com/bitcoinknots/bitcoin/blob/29.x-knots/src/deploymentstatus.h#L60

Code:

inline bool DeploymentMustSignalAfter(const CBlockIndex* pindexPrev, const Consensus::Params& params, Consensus::DeploymentPos dep, ThresholdState state)
{
    assert(Consensus::ValidDeployment(dep));
    const auto& deployment = params.vDeployments[dep];
    if (deployment.max_activation_height >= std::numeric_limits<int>::max()) return false;
    if (state != ThresholdState::STARTED) return false;  // If must_signal height is reached before start time, abstain from enforcement
    const int nPeriod = params.nMinerConfirmationWindow;
    const int nHeight = pindexPrev == nullptr ? 0 : pindexPrev->nHeight + 1;
    return nHeight >= deployment.max_activation_height - (2 * nPeriod)
        && nHeight < deployment.max_activation_height - nPeriod;
}

Which means, that DeploymentMustSignalAfter will return "true" for "nHeight >= deployment.max_activation_height - (2 * nPeriod)", which means block number "965664-(2*2016)", so "961632" is the first block, where the chain will split.

Relevant counter: https://jlopp.github.io/knotzi-death-march/

I don't believe that's true.

If you say no that is not going to happen or anything code related. You need to post the code or at least point out in the code why what you said was true.

I guess you missed something.

It is just to point out the technical reasons

Then, it should be probably in a technical board, like this one: https://bitcointalk.org/index.php?board=6.0

But even in that board, it would be new, to require links to the code, to post anything.

[ABCbits]

For other reader, you can verify the code actually exist by visiting
https://github.com/bitcoinknots/bitcoin/blob/29.x-knots/src/net_processing.cpp#L3546
https://github.com/bitcoinknots/bitcoin/blob/29.x-knots/src/net.h#L1247
https://github.com/bitcoinknots/bitcoin/blob/29.x-knots/src/net.cpp#L2711

Furthermore, if you don't like the idea if preferencial peering, you should look into OpenRelay. It's a fork off of core by peter todd (small caps intended), with preferencisl peering to other OpenRelay nodes and all filters removed. Expressly designed to promote spam on bitcoin.

Stop hallucinating, i checked both https://petertodd.org/ and https://github.com/petertodd, but there's zero mention of "OpenRelay". I also verify it with quick search with these keyword.

Code:

site:petertodd.org "OpenRelay"
site:github.com/petertodd "OpenRelay"

[PepeLapiu]

You still don't know the difference between hard-fork, and a minority soft-fork.

I do know the difference. One produces two separate coins, the other doesn't. Successful or not, a soft fork doesn't result in two coins.

When soft-fork is supported by 51% or more hashrate (the more, the better, which is why 80% or 90% is highly recommended), then all clients land on the same chain. But: if some soft-fork is activated, even if only a small minority is supporting it, then it becomes a minority chain.

If you trace the story of Segwit, then note one important thing: it was not activated, when it was supported by minority. Which is different than in BIP-110 case, where activation is forced in the client.

You are missing some details here. BIP141 was the miner activated fork, and it was not going anywhere for almost a year with no more than 30% of the miners signalling for it.

The other 70% had no desire to sign up for 50% discount coupons on miner fees at a time when miner fees were at an all time high and everyone expected them to keep going up.
Furthernore, they had no desire to willingly cut 20% of their ASICs performance either.

That's when user activation came in with BIP148. Less than 5% of the nodes were running BIP148 and threatening to reject non-signalling blocks. That's when all the miners finally got on board with Segwit. Now we have Segwit, you're welcome.

An intolerant minority is all it took to force miners to hand out 50% miner fee discounts and cut their ASIC performance by 20%, reluctantly. Because they had no desire to see the nodes reject their blocks.
What do you think will happen when twice as many nodes threaten to reject their blocks? Especially when you consider miners had a lot more incentive to stay on the legacy chain with Segwit, and they basically stand to lose nothing with the BIP110 chain.

Also, to see the chain forking, there is no need to produce any "anti BIP-110 chain". The only thing, that is needed, is to use the old version, which will include any transaction, which will be rejected by BIP-110 nodes. A single transaction in a single block is all, that is needed, to fork the chain. So, do you really think, that 99% clients will upgrade, and absolutely nobody will produce a block with such transaction? Because nothing else is needed, to split the chain.

You fail to see the big picture here. The majority of blocks right now already are BIP110 compliant. There is very little incentives for miners to add one or two tx in their block to see their block rejected by the intolerant minority.

And BTW, I believe you are in for a surprise. It's likely the number of BIP110 nodes will go up before September 1st.

If you say no that is not going to happen or anything code related. You need to post the code or at least point out in the code why what you said was true.

Actually, I already edited my last post. It turns out Knots has been doing preferencial peering for a very long time. Long before the spam war and BIP110 were started. The reason for this has nothing to do with plans to hard fork anything. LibreRelay also does it. I don't think either LibreRelay nor Knots are planning on hard forking.

Keep spinning your grand conspiracy gears.

[BattleDog]

The hard fork / soft fork argument is mostly turning into a word salad here. The thing that matters is simpler: if a client reaches height X and its consensus path says "this otherwise valid block is invalid", then that client is off the network the moment miners produce such a block and the rest of the economy accepts it. Call it a minority soft fork, a failed UASF, a self-own with version bits, whatever. The node does not care what label we put on it.

Policy knobs are one thing. Relay preferences, peering, filters, OP_RETURN drama, spam wars, all of that is messy but survivable because it does not necessarily change what block you accept. But once you move into "reject this block" territory, you are no longer just expressing taste. You are making a consensus bet. If almost everyone follows you, history calls it activation. If almost nobody follows you, history calls it a funny GitHub branch with casualties.

The SegWit comparison only works up to a point. BIP148 had social pressure, miner game theory, exchanges watching, wallets watching, and a very public standoff. You cannot just cargo-cult the shape of that event and assume the same magic smoke comes out. If Knots has code that will force rejection past some activation condition, then yes, the honest discussion is not "Luke would never" or "miners probably won't." The honest discussion is exactly what Dave is asking for: point at the code, point at the height/condition, and explain what happens when the first non-compliant block lands. Everything else is just noise.

[DaveF]

Pepe,

I removed your last post. From the 1st post:

This thread is NOT to discuss knots / 110 being good or bad.
It is not to discuss what miners may or may not do.

It is just to point out the technical reasons why unless a bunch of miners do start signaling and supporting the 110 chain is going to fork off (or split off if you like that term better) and unless they do something about the difficulty, fail.

Also, from this AM

Furthermore, if you don't like the idea if preferencial peering, you should look into OpenRelay. It's a fork off of core by peter todd (small caps intended), with preferencisl peering to other OpenRelay nodes and all filters removed.

Show the code of where this exists or edit it out of your post.

It is just to point out the technical reasons

Then, it should be probably in a technical board, like this one: https://bitcointalk.org/index.php?board=6.0

But even in that board, it would be new, to require links to the code, to post anything.

Yeah, I'm just being a bit of a hardass on this. I am so tired of people saying 'because' that I decided to be a high school math teacher and tell everyone to show their work. But, yeah should probably move it to the tech board.

-Dave

[DaveF]

I'm not a C++ coder, I don't read C++ code. You need a C++ coder to make a point? Really?

To post anywhere else, no.
To post in this thread also, no.
To say in this thread that "X" does something, yes. Prove your point.

......LibreRelay also does it. I don't think either LibreRelay nor Knots are planning on hard forking.

Keep spinning your grand conspiracy gears.

Then show in the LibreRelay code where it rejects blocks that are valid.
Oh, wait you can't because that code does not exist. LR is not planing to fork. lukecoin is.

in code has been shown that lukecoin will reject blocks that are valid except for those in his worldview.
The rest of the network will march on without him.


-Dave

[gmaxwell]

What do you think the knotzis would do if Bitcoin Core adopted preferential peering that prevented nodes from getting surrounded by censorus (and soon to be consensus inconsistent) knots peers? -- it's not currently an issue, doesn't seem like it's likely going to be an issue... but if it were done I think they'd absolutely lose their shit and throw all kinds of incredible accusations.

I think core probably should have some logic to try to get at least three outbound peers to be "equivalent or better" (e.g. have to be at least the prior version of core, or if the release is sufficiently old have to be at least its own version).  Any time there are all 8 full outbound peers connected and fewer than three are "equivalent or better", disconnect the most recent non-"equivalent or better" peer.

But I'm somewhat doubtful the developers would implement such a thing-- no matter how prudent it would be-- because they refuse to expel dramabombers like luke and any such improvement would just be exploited to hurl invective.

[PepeLapiu]

What do you think the knotzis would do if Bitcoin Core adopted preferential peering

You mean like LibreRelay? The core fork by peter toad, your friend who designed a client precisely to make spam easier and more abundant on bitcoin?

Because LibreRelay does it with preferential peering and the removal of all filters.

And somehow the coretards have no problems with preferential peering when it's in favor of spam, but it becomes a problem when it's for anti-spam reasons?


 

[ertil]

You mean like LibreRelay?

It is not a part of Bitcoin Core. It is just a fork of it, like Bitcoin Knots. However, at least the history is preserved, unlike in Knots, where imported commits are marked as "written by Luke".

Another git repository concern is that Luke just pulls the code in manually from pull requests and then commits it himself, causing anyone who wants to audit it to have to manually re-examine the Luke commit compared to the pull request code that others might have reviewed. This is getting really deep in the weeds of software development lifecycle integrity assurance, but the point is that Luke must be changing the commits in some way for them to have a different hash. While that may only be a changed commit message or fixing merge conflicts, the problem is that nobody knows. It might be obvious to other engineers that Luke could have changed something, but I doubt it's clear to the average person.

This is not a part of Bitcoin Core: https://github.com/petertodd/bitcoin/tree/libre-relay-v30.2

As well as this: https://github.com/batmanbytes/bitcoin/tree/testnet4-softfork

And as well as many others. The first step to contribute, is to clone the repository, make your changes in your space, and then create a Pull Request. But: as long as it is not merged, it is not a part of Bitcoin Core. It is only a custom setup, used by a given developer.

Which means, that saying "Bitcoin Core does this" is wrong, if it is outside of this place: https://github.com/bitcoin/bitcoin/

[PepeLapiu]

You mean like LibreRelay?

It is not a part of Bitcoin Core. It is just a fork of it, like Bitcoin Knots.

You are correct. LibreRelay is a fork off of core. The OP claims that the only reason to do preferential peering is to hard fork from the network.
If you agree, if you believe that the only reason to do preferencial peering is to hark fork from the network, than you have to claim that LibreRelay wants to hard fork the miners from the rest of the network.




So you wanna see code?
You think it's appropriate to demand code to back up everything non-coretard people say on a general forum, not on a technical forum?

I got you. See how long before you delete to following:

https://github.com/aeonBTC/Knots-Banlist

Software to do far worst than preferential peering, but instead outright keep a ban list of all the nodes who filter spam.

You accuse Knots/BIP110 to not have enough coretard peers?
Well, the spamware in the link above would allow you to have no Knots peers at all, and complety ban them all.

I say it would allow you to do so. But the AeonBTC Knots Banlist doesn’t work anymore because it uses the Bitnodes.io address list. Bitnodes stopped working a few weeks ago. Difficult times for spam lovers!

[DaveF]

You mean like LibreRelay?

It is not a part of Bitcoin Core. It is just a fork of it, like Bitcoin Knots.

You are correct. LibreRelay is a fork off of core. The OP claims that the only reason to do preferential peering is to hard fork from the network.
If you agree, if you believe that the only reason to do preferencial peering is to hark fork from the network, than you have to claim that LibreRelay wants to hard fork the miners from the rest of the network.




So you wanna see code?
You think it's appropriate to demand code to back up everything non-coretard people say on a general forum, not on a technical forum?

I got you. See how long before you delete to following:

https://github.com/aeonBTC/Knots-Banlist

Software to do far worst than preferential peering, but instead outright keep a ban list of all the nodes who filter spam.

You accuse Knots/BIP110 to not have enough coretard peers?
Well, the spamware in the link above would allow you to have no Knots peers at all, and complety ban them all.

I say it would allow you to do so. But the AeonBTC Knots Banlist doesn’t work anymore because it uses the Bitnodes.io address list. Bitnodes stopped working a few weeks ago. Difficult times for spam lovers!

Not sure what point you are making here.
In knots the code says use knots for the most part and kind of connect to core / other nodes.
What you linked to is some code that is not in core or any other distribution that I am aware of that people have to manually download and put into a config file.

Many people have been doing that or something similar for months to improve their node performance since not having all the TXs causes your node to have to do more when it gets a block that it does not have all the TXs for. So making sure you don't connect to nodes that are not sending the full mempool helps you.

-Dave

[PepeLapiu]

(coretard slop removed)

I'm not replying here. You are too stupid and you will likely come up with an excuse to delete my post. I'll see later if I have time to reply to it in my own thread.

The hard fork / soft fork argument is mostly turning into a word salad here.

I agree. LibreRelay already does preferential peering and pretty nobody in the coretard circles have a problem with that.
There is software out there to outright ban BIP110 abs Knots nodes, essentially a black list. Coretards don't have a problem with that.
Knots was doing preferential peering since it's inception. The coretards didn't have a problem with that.
It only became a nitpicking problem for coretards when it's convenient to them. And only for Knots/BIP110 now. Not before the spam war, not with core, not with LibreRelay.

Policy knobs are one thing. Relay preferences, peering, filters, OP_RETURN drama, spam wars, all of that is messy but survivable because it does not necessarily change what block you accept.

I disagree. We need to resist spam if we want bitcoin to survive, grow, and scale. Bitcoin is too important a project to treat spam as "new use cases we have today".

The SegWit comparison only works up to a point. BIP148 had social pressure, miner game theory, exchanges watching, wallets watching, and a very public standoff.

Yes, while BIP110 has less institutional support than BIP148, we do already have twice the node support. And miners stand to lose virtually nothing with BIP110, far less than with Segwit.

With Segwit, a lot of miners were going to lose 20% of their ASIC performance, along with cheaper fees. Miners don't have those drawbacks with BIP110.

[gmaxwell]

Yes, while BIP110 has less institutional support than BIP148, we do already have twice the node support.

The claim that bip148 had any relevance at all is disputed and mostly promoted by Luke-jr. In any case Bitcoin Core never supported it.

The reality is that at the time segwit activated >95% of all nodes supported segwit.  And the metric was the same even if you eliminated VPSes or recently started nodes.  If you eliminate the knots stuff that looks like it's probably astroturf the count falls to very low figures.  Even you have been challenged to prove you're a bitcoiner and not some false flagging shitcoiner and you've failed to meet the challenge--  there is good reason to doubt that BIP110 has more than trivial support among people who own bitcoin and aren't investors or employees in Ocean.

And miners stand to lose virtually nothing with BIP110, far less than with Segwit. a lot of miners were going to lose 20% of their ASIC performance

Bitmain vigorously denied that they were using covert asicboost, but in any case it was only them-- and they solved it by moving those miners to BCH, then when bch made a consensus change with similar effect they presumably moved to BSV.  Had they raised the issue-- rather than denying it-- we would have tried to find a way around it.  So no, miners in general didn't stand to lose anything other than the reduction in income from having larger blocks with almost all said they wanted.

In the case of 110 miners would stand to lose dramatically-- both from undermining the value of the coin by hobbling its functionality and extensibility and by undermining the philosophical underpinnings of Bitcoin (that you can transact without third party permission and that you can store your coins safely without having to move them to avoid losing them), not to mention the culpability they would face for causing losses to others.

[PepeLapiu]

The claim that bip148 had any relevance at all is disputed and mostly promoted by Luke-jr.

The truth is that the miner activation had been stuck at 30% for a year. It wasn't going anywhere. Only when BIP148 threated miners to force them into Segwit, did they suddenly get on board with Segwit.

In any case Bitcoin Core never supported it.

I don't think that's true. Core had divergent devs on Segwit. But yeah, a handful of computer nerds should not be deciding on the faith of Bitcoin. Especially the new batch of retarded devs we have now in core.

The reality is that at the time segwit activated >95% of all nodes supported segwit.

I think you mean >95% of the hash rate, not >95% of all nodes.

And the metric was the same even if you eliminated VPSes or recently started nodes.  If you eliminate the knots stuff that looks like it's probably astroturf the count falls to very low figures.

The exact same theory could be said of core 30 spamwade nodes. It's retarded to argue this because it can't really proven one way or the other.

Even you have been challenged to prove you're a bitcoiner and not some false flagging shitcoiner and you've failed to meet the challenge

Personal attacks is where you really shine Greg. Don't stop doing it. I'm not stupid enough to publish my stash on a public forum. It's absurd.

I'm not revealing my identity or my stash. Get lost with that nonsense. I know you would be only too happy to find out more about me so you could go after my person instead of going after what stand for. Not gonna happen.

there is good reason to doubt that BIP110 has more than trivial support among people who own bitcoin and aren't investors or employees in Ocean.

This is absurd. I've been to two bitcoin conferences here in El Salvador in the last year. The hatred and disapproval of core is palpable. And if you look at any video discussing it on YT, the comment section is 95% on the anti-spam side. You are getting too complaisant, Greg.

You could make the argument that all the YT comments are bots, but the same can't be said for BTC meet ups I've been to.

If you are surrounded by pro-spam pro-core pro-large-op_return people, you likely spend too much time with coretards paid by Brink and BlockStream.

Bitmain vigorously denied that they were using covert asicboost

Of course they did.

but in any case it was only them

Only Bitmain? Like 30% of the ASICs out there at the time was not significant?

and they solved it by moving those miners to BCH, then when bch made a consensus change with similar effect they presumably moved to BSV.

So they denied using asicboost, but they behaved exactly as if they were? Even going as far as pointing their ASICs only to coins that kept allowing asicboost?

I would argue Bcash would have had a lot less suscess (not that it did have any) and Segwit would have had more success, had Bitmain been pro-Segwit.

Had they raised the issue-- rather than denying it-- we would have tried to find a way around it.

Only they didn't. Instead they opposed Segwit and never revealed their real motive.

So no, miners in general didn't stand to lose anything other than the reduction in income from having larger blocks with almost all said they wanted.

That is a big incentive to reject Segwit, when miner fees were far higher than they are now, with everybody predicting miner fees would keep going up.

I find it particularly amusing how you re-write history. Are we all going to pretend that BIP141 was not going anywhere for over a year and no more than 30% miner signalling?

Are we all going to pretend miners didn't feel threatened when just 5% of the nodes threatened to reject their blocks?

In the case of 110 miners would stand to lose dramatically-- both from undermining the value of the coin by hobbling its functionality and extensibility

I find it particularly interesting that you would reframe anti-malware measures as "hobbling its functionality and extensibility". A very pro-spam reframing of the issue. You miss your buddy Epstein much, Greg?

and by undermining the philosophical underpinnings of Bitcoin (that you can transact without third party permission

Funny how you manage to talk about the "philosophical underpinning of Bitcoin" without ever mentioning the words currency, cash, or money. Did you ever read the tittle of the white paper, Greg?

and that you can store your coins safely without having to move them to avoid losing them), not to mention the culpability they would face for causing losses to others.

Still stuck on the confiscatory FUD, Greg? Still claiming that if you delete your keys, BIP110 will steal your coin?

Greg, are there any other existing scenarios where deleting your keys will cause you to lose your coin?

[ertil]

Did you ever read the tittle of the white paper

Let's see, what is really written in the whitepaper:

Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending.

And now, BIP-110 changes that model from "you can transact, without a third party" into "you can transact, if Knots will not consider your transaction to be a spam".

Which means, that BIP-110 introduces transaction blocking into consensus. And then, if you want to block any transaction, you can just:

1. Announce publicly, that it is a spam, that needs to be blocked.
2. Write a client, which will always enforce it, no matter how many miners will support it.
3. Fork into a minority chain, where a given transaction is blocked, and call everyone else a spammer.

Because it is always possible to block more transactions, you can never be sure, if your transaction will be marked as a spam later, or not. Developers, who introduce protections, will never give you any examples of things, that can be safely used, and won't be blocked. So they can always block everything, using any excuse they want.

are there any other existing scenarios where deleting your keys will cause you to lose your coin?

You don't need to delete your keys, all that is needed is just any multisig, where you don't have all keys. Which means, that if there is any 2-of-2 multisig, and Alice wants BIP-110, while Bob rejects it, then coins can be lost, because one presigned transaction will be blocked, and another one will be confirmed.

And then, warning users upfront won't help, no matter how early someone would know, that BIP-110 is there.

By the way: it is funny, that BIP-110 enthusiasts only observe the on-chain UTXOs, and claim, that "no users are affected". If you close your eyes, then you won't see anything. I wonder, how they want to handle timelocked transactions: because you can never be sure, when exactly a given transaction was created. And if it is timelocked, then even if you know all keys, it may be not enough to migrate funds to anything else upfront, because that timelock will be always enforced by consensus rules, for example by opcodes like OP_CHECKLOCKTIMEVERIFY.