Yeah, all those tiny islands all over are hard to keep track of

Papua New Guinea is in Oceania, and the Guyanas in South America are named from an Amerindian term meaning “land of many waters”.

Your question piqued my interest, so I looked this up. The Guilf of Guinea is the name of the part of the Atlantic Ocean stretching from Gabon to Liberia and Guinea seems to have been used colloquially to refer to the entire West Coast of Africa for some time.

Via https://www.reddit.com/r/AskHistorians/comments/3450ws/why_are_so_many_countries_called_guinea/:

That’s how many of the European colonies in the region took on names like French Guinea, Spanish Guinea, Portuguese Guinea, and German Guinea.

• Portuguese Guinea became Guinea-Bissau (named after the city of Bissau).
• French Guinea became just plain Guinea (though it's sometimes called Guinea-Conakry after its capital).
• Spanish Guinea became Equatorial Guinea after its location near the equator.
• German Guinea dropped the Guinea part entirely became Togo and Cameroon, after their historical names.

deleted by author

Guinea, Equatorial Guinea, and Guinea-Bissau are also my kryptonite. I also keep mixing up Zimbabwe and Zambia.

For a softfork to be activated, it needs to gain support. To gain support, people need to talk about it and address the concerns that were raised. There seem to be few people talking about OP_CAT and, as far as I am aware, the concerns have not been adequately addressed. It currently seems to have little momentum and there hasn’t even been an activation mechanism discussed, let alone an activation client published.

At this time, there seems to be a low likelihood of OP_CAT being adopted any time soon.

Even if some bitcoiners enact OP_CAT, others might not, or they might fork another chain.

If a new feature introduced by a soft fork is enforced by a minority of the hashrate, it cannot be relied upon and therefore is unlikely to achieve any meaningful usage.

I see, that explains it. I experienced the same when I was a bit off-center for Algeria. And I outright mis clicked for Togo into Benin instead and it was accepted:

Yeah, that I2P example felt a bit off-base. Nodes self-announce their (network-respective) address for each network they support to each peer after establishing a connection, i.e., on clearnet, a node will announce its clearnet address to peers. Such peers may then forward the address when they get asked for a batch of addresses by another node. I don’t remember whether nodes only gossip addresses of the respective network on each network, or whether they generally gossip addresses from all addresses (probably the latter?), but a node that doesn’t use I2P wouldn’t announce an I2P address, so we’d never try to connect to it with I2P.

The services flags indicate which optional peer services a node offers which is different from whether nodes understand a protocol feature. I would expect that they continue to get used.

OTOH, if BIP 434 is adopted, the protocol version might not need to be bumped further after the bump for BIP 434.

Yeah, that’s why I said “fair enough”.

You don’t need my approval to believe whatever makes you happy.

Fair enough! I thought you meant to express that it required a coordinated software update with a consensus rule change.

If you think I was arguing for RDTS, you misunderstood me.

Having a hard time making sense of your reply.

"We don't need a majority of hashrate because we will eventually get a majority of hashrate."

That’s it: you have distilled the essence of the RDTS fallacy perfectly.

You only addressed the case in which 55% do enforce RDTS — the least likely case.
Anyway, please don’t take it too hard when your proposal activates with a tiny portion of the hashrate on LOT.

No, invalidateblock causes your node to treat the passed block as invalid. Naturally, any blocks succeeding it are therefore also treated as invalid. And IIRC, we ban peers that send us invalid blocks, so you also get rid of your RDTS peers all in one go.

The RDTS fork activates at a specific height. Unless they have at least close to half the hashrate, as soon as the non-RDTS chain finds a block they’ll get behind and continue to fall behind further.

The behavior you describe would apply if RDTS activated with a majority of the hashrate: every non-RDTS block would cause a short fork and then be reorged out.

A checkpoint is a commitment to a specific block, invalidateblock rules out a specific block. Is it that what you mean?

However, if RDTS doubles down on their minority chaintip, invalidating the first block of that branch in the chain makes your node consider all descending blocks invalid, too.

RDTS node runners can’t change the activation mechanism in their software without recompiling, so no, they can’t decide to accept a few invalid blocks after activation to start over at a higher height.