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/