PROTOCOL MINOR UPDATE: V9.61

[jotapea]

Let this be the space to discuss the next protocol-changing release, a consensus hashes affecting PROTOCOL MAJOR / MINOR UPDATE.

---

Federated node operators, separate from the develop- branch leader, MUST participate and express support, or not, to one (1) of the release candidates that activates a new counterparty-lib protocol. Without "proper" node operator support, no new MAJOR / MINOR version branch should be merged to master.

The number of users voicing yes or no has less "weight" than the users' repository "reputation". But all these ("proper", "weight", "reputation") are deliberately subjective measurements. Clearly stating this is necessary, because anyone can pretend anything.

The fact is that ULTIMATE CONTROL is in hands of an individual, one with repository privileges to control master.

Currently (2023-11-27 edit), with around 500 blocks left before the @jdogresorg set activation (at block 819300), there is an imminent CONSENSUS WAR. We are at this critical point because:

1. When reviewing the proposed new version of the protocol, conflicts brought up by other node operators (some even earlier in their development) were not resolved.
2. The proposed new version of the protocol proceeded to be merged into master (in this specific case, the develop branch step was completely skipped).
3. The consensus war begins when the activation block is reached.

Naturally, there is a SIMPLE way to avoid the war, which is 100% in the hands of the individual who is triggering it in the first place, the one with control of the master branch. So, keeping the non-updated protocol is the recommendation for the undecided node operators. Continue like nothing happened, just like an uninformed would.

The other ways to avoid a consensus war are:

1. Centralized infrastructure, nobody to convince. Everything in the code goes, including mistakes. Lower quality.
2. "Forcing" (how?) the rest of the federated nodes to update against their will. Social pressure.
3. Coordination of activation block between node operators. Code was reviewed and verified. Decentralized. Higher quality.

The war SHOULD BE AVOIDED in the first place! But if it starts, I believe, it should end quickly, because it should favor the conservative if they have substantial ledger activity.

Consensus forks that spread will devalue the protocol's TRUST the most. The social consensus of "What is Counterparty?", which is what the battle is for.

---

YES candidates:

• [1] "skipped-develop-jdog" Release candidate: 2023-11-17 Activation block at 819300 by Jeremy Johnson (@jdogresorg).
  • CRITICAL: Consensus war imminent, ready to activate a new protocol. Code already merged to master and release built.
• [2] Release candidate: 2023-11-18 Activation block at 999999 by Juan Alemán (@jotapea).
  • Changes to work led by @jdogresorg:
    • Deactivates the new protocol - CounterpartyXCP/counterparty-lib@a15d7a1.

NO (top relevant discussions):

• Holding off the update by JP Janssen (@Jpja)

---

Comment to:

• Raise your voice
• Ask for edits to this original post
• Offer general feedback about the process itself

[jotapea]

The main purpose behind this discussion is that I believe 2 weeks is only an acceptable time for what @Jpja calls the issue option, which sound like REVISION releases.

• issue (no tradeoffs, not very urgent, add to general updates and give weeks to review)

2 weeks to review non-mandatory updates, incentivizing continuous improvements that don't affect consensus hashes, is great! And more importantly, other federated nodes are not REQUIRED to update or verify anything, as hashes should match. And changes are reversible (if necessary).

But for MAJOR / MINOR consensus hashes affecting updates, 2 weeks is way too little time! It isn't even enough time to VERIFY the code with a full parse! This short time can only rely on a centrally made bootstrap, which is just a convenience, not a core protocol requirement.

I believe that one part of @Jpja process improvement can be that all protocol-changing (new MAJOR / MINOR consensus hash affecting versions) release candidates (ideally much earlier than the final code PR) MUST specify at least 1 CIP. And for those that don't merit a whole "Standards" CIP, then these should AT LEAST have a CIP-Discussion.

THIS is that CIP-Discussion, a space where the release candidate and activation block is AGREED on. Specifically, not unilaterally centrally set by the master controlling individual. The protocol repository MUST show other nodes of the federation in agreement, a truly decentralized network.

[jotapea]

This should be enough:

The current v9.61 simply did not follow the release procedure.

[reinamora137]

I would strongly suggest this being put on hold as it will diverge the entire bitcoin stamps community from xchain data. With all of the work going into releasing a public indexer for stamps integrated with counterparty we are not prepared to handle and verify the implications of such changes with such short timelines. We will be required to stay on the prior version along with xcp.dev to validate consensus until further verification is done.

A potential fork of the stamps ecosystem from xchain has been our drive in many decisions including removing src-20 from counterparty. Forcing this change now will only divide the collective communities when we are pushing to foster more collaboration and dev in both stamps and counterparty through this public release.

stampchain operates two CP nodes for the stampchain api which is the lynchpin of data for all development on stamps.

[jdogresorg]

Reposting a comment which I already posted elsewhere, but which you may not have seen.
https://github.com/CounterpartyXCP/counterparty-lib/pull/1280#issuecomment-1817666648

... I am simply following the same procedure for picking activation block that Counterparty has been doing for years. The original founders themselves set activation blocks 2 weeks out from release, that is what is happening in the 9.61.0 release.... nothing surprising here.

A full parse IS NOT NECESSARY (and has been typically been done by CP devs BEFORE a release). If you choose to run your CP node and always do a full parse on every release, that is your right..... but you can not expect other node operators to want to spend a week in downtime doing a full parse, or even 24 hours doing a reparse.

Quick Example: Exchanges on Counterparty integration? Downtime is a no-no for them... They want a simple list of commands to run and get back up ASAP, forced full parse or reparse are NOT viable options for them, nor for MOST node operators.

The bootstrap is validated via a reparse BEFORE every release, so that the end user does not HAVE to do the reparse (unless they want, which they can easily do so at any time by running a command... not by being FORCED to)

If you choose to do a full-parse, that is entirely your right, and had you started the reparse when the release was announced 2 weeks ago in chat rooms, forums, twitter, etc, your full parse would probably be pretty close to finished right now.

A REPARSE is much faster than a full parse, because it doesn't have to search every block for a CP transaction, like a full parse does.

A REPARSE parses all existing CP transactions using the new code, and verifies data quickly using the following hashes :
TXLIST (transactions)
LEDGER (credits/debits/balances)
MESSAGES (messages)

The MESSAGES hashes can change / be overwritten as the messages stored in the messages table, but the TXLIST and LEDGER hashes ensure that data is parse the same way, and that the transactions and state (credits/debits/balances) match between versions.

You still have options to get up faster than a full parse:

1. When running the commands to update to the latest release, just leave out the command that deletes your counterparty databases (done for you below).... the new counterparty-lib v9.61.0 will start up, and because the DATABASE version doesn't match, a full REPARSE will be triggered.

cd federatednode/
git pull
fednode stop
fednode update
fednode stop
fednode rebuild bitcoin bitcoin-testnet --no-cache
fednode rebuild addrindexrs addrindexrs-testnet --no-cache
fednode rebuild counterparty counterparty-testnet --no-cache
fednode stop
sudo su
rm -rf data/addrindexrs/*
exit
fednode start

2. Follow the normal update proceedure laid out in the release notes (which downloads the bootstrap which has already had a REPARSE done on it), and then run a fednode reparse counterparty to perform a REPARSE on the downloaded bootstrap.

[jotapea]

Great, so your ONLY feedback to the whole situation is to repeat the instructions to follow your imposed upgrade.

Let me also post instructions to revert to the version we are ALL still in agreement (until block 819300, which then is your node the one that stops being in consensus).

cd federatednode/src/counterparty-lib
git checkout 09b20b3e
fednode stop counterparty counterparty-testnet
fednode rebuild counterparty counterparty-testnet --no-cache
fednode start counterparty counterparty-testnet

Simple. Is 100% in your hands to stop this whole situation, if you just play nicer with other node operators man. What is the rush?

[jotapea]

@jdogresorg Thanks for the details on the HASHES, very relevant info.

[reinamora137]

The instructions are definitely not the problem. The process flow and the forced timeline is the issue for these major consensus changes. If the documented process can be broken for the release surely the 2 week release schedule can be deferred.

What is the problem with pushing non-consensus changes in this release while deferring consensus related changes?

[keyuno]

there is an imminent CONSENSUS WAR.

Referring to this situation as a "war" is counterproductive and hyperbolic.

Without "proper" node operator support, no new MAJOR / MINOR version branch should be merged to master.

Consensus isn't dictated by node operators; anyone can set up a node. The true decision-makers in determining what Counterparty actually is are the asset owners.

Having said that, considering extending the update timeframe until the code undergoes a comprehensive review by all parties is probably the way to go. This will help prevent unnecessary forks and ensure a more thorough evaluation of the changes.

Especially in light of a core maintainer's admission to shifting focus away from counterparty operations, there is concern that the introduction of destructive elements into the code may be influenced by this change in direction. It's important to note that this isn't a personal matter but rather an acknowledgment of a shifting power dynamic. The objective is to avoid a fork, demonstrate good faith, and uphold a positive reputation.

[jotapea]

It is ALL about power dynamics.

The master branch controlling individual also runs the PRIVATELY OWNED top (for now still) user tools (FreeWallet / xchain)... but this same person is supposed to also work on the protocol tools for other developers to build on. In my experience, he doesn't care much about improving the protocol side alternatives (Counterwallet / (no protocol repo open source explorer)).

The establishment just ignores all mistakes as that will show weakness. In my opinion, for these people appearances WILL ALWAYS TAKE TOP PRIORITY, and integrity takes a back seat.

The facts are:

• The release procedure was not followed.
• The central infrastructure approach to avoid "wars" is the way everyone has been used to (so all this, even using the word, seems weird).
• The WAR has been declared single-handedly by the master controlling individual by instead of encouraging other nodes to be a part of the process and grow, keep his central power.

[jotapea]

@keyuno is all connected #97

[jotapea]

The failure to see how centralization affects the BIG PICTURE of Counterparty has always been surprising to me. Is obvious that initially every protocol needs to start centralized. But after a certain point, in order to build a foundation for others to build on and GROW, stability is required.

Instead, the establishment seems to prefer their control over everything else, and their strategy is to constantly change the rules, so then everyone has to follow them.

STAMPS are the opportunity brought up by the MARKET to achieve this stability. Is not a single developer yelling any more lol

But the social pressure might still be too big to bear. I can understand that...

[jotapea]

What can be the middle ground here? Something like this:

[2] https://github.com/CounterpartyXCP/counterparty-lib/pull/1280 Activation block at 999999 by Juan Alemán (@jotapea).

Most (all?) of the people commenting in the repo seems to be agreeing to at least a delay.

Thinking that later, on a v9.62, is when actual activation of some / all of these changes happen. None are urgent, so there is really NO REASON to force this specific protocol update to the rest of the nodes and continue with this unwarranted "consensus war", which IS 100% caused by the activation block.

No need to backtrack, this is forward looking. But this must become v9.61.1 asap (before block 819300).

Thinking this can be a new part of the release procedure, ODD releases are the first step to final evaluation of changes by node operators. Then the EVEN releases activate all that pass this "final evaluation". Or this is just a one-off as part ALL PARTS trying to improve the processes.

I see it as a middle ground between established centralized procedures, and the reality WE ALL WANT which is that the protocol is growing, requiring more stability, and starting to decentralize.

Thoughts? @jdogresorg @Jpja @reinamora137 @keyuno @droplister @loon3 @pataegrillo

[loon3]

Not to beat a dead horse but the process @jdogresorg followed for this release is the same process that he's followed for every release, that John followed before him, and that Devon followed before John. We've all agreed that the process itself needs to change and its something that @Jpja, @genecyber and I plan to address before any new releases AFTER v9.61.0 which leads to the inevitable question...

Why v9.61.0 now?

Continuity.

We have a process which @jdogresorg didn't invent but has been following dutifully for years. He announced this release with the two week activation time in the same way he has done the previous releases. There are no technical issues with the release which is mostly benign changes and fixes that benefit all users of Counterparty. It has not been rushed any more than any prior release as the same process was followed. It has already been announced publicly with the activation block as with every change before it. Honoring eleventh hour appeals to delay activation due to a disagreement in the process itself with threats of forks and wars is a dangerous precedent to set and not something we've ever done. It is not in the best interest of Counterparty for new maintainers to come in and immediately make decisions prior to implementing a process change.

For all these reasons we should stay the course, activate as planned then focus on formalizing the release process to make it more transparent and keep everyone informed going forward.

[speaktech]

"demanding that things function how you say they should function in counterparty"

And this crazy mixed up world common sense is a rarity and you sir have no insight into irony. It is this psychological projection that is the root of the issue that you are causing for everyone for the last several years. Try to refrain from telling everyone they are personally attacking you because they use logic or insight to question your dogma. Your stepping down is long overdue. I'm grateful for it. But you can't have it both ways. So pull the update. You're unwilling to discuss the fact that you are laying down what is going to happen and disregarding input from the community members in multiple channels.

Thanks for all the lulz "wizard of xcp"

[jdogresorg]

[jotapea]

Great (welcoming) development community!

@loon3 with friends like this, who needs enemies right? Karma is now on you @jdogresorg, kind of sad you don't realize it.

Venting is human, like you did (DM me). Don't worry, I won't share a screenshot.

[jdogresorg]

@jotapea Juan, I replied to your DM on telegram saying I had no interest in meeting you personally, given I have observed enough of your behavior to know your character... Not a long rant, a respectful reply to your request to meet in person... Once again, it seems your trying to spin things to make it sound like more is going on than reality.

FYI, Since you once again may not know the counterparty history ... let me fill you in on @speaktech . He was a former community manager whom I hired, after one month, he rage-quit the job when I had to take away his moderator powers in the telegram channel after numerous (10+ CP community members) complaints of him randomly kicking people. Ever since then he has had a personal grudge against me, and ONLY speaks up to voice opposition to anything I say or do... Duncan had his chance to contribute/steer counterparty on the counterparty foundation for 2 years, and community manager for 1 month... IMO he contributed nothing... So yeah.. bye Felicia! :)

At least you object (generally) for technical reasons... I may not agree with your drama-based approach, but I can respect your viewpoint.

[jotapea]

@speaktech is one of the MAIN reasons I didn't give up earlier. He has been great support, and I truly consider him friend I can trust.

Lets just move forward. I'm already working towards the seemingly inevitable consensus change. Still, I will be ready to update to v9.61.1 if you do.

Sorry we had to get to these levels. But I guess we both just have been doing what WE BELIEVE we should do. And in the end, lets all learn and grow from this.

[jotapea]

With less than 150 blocks until activation, this will be my last attempt for the master controlling to show consideration of other node operators for this release. 99% your way, and 1% compromise. Is this too much to ask?

The ONLY change I ask now to not activate changes in the issuance data packing logic. New PR. Is only 2 variable changes, and avoids proving to the rest of time(chain) that the development team in this era doesn't understand the implications of changing these root protocol rules WITHOUT A CIP!

Lets make this v9.61.1 and move on?

[arwyn6969]

I wanted to come here to say that I appreciate everything that people contribute, in this case. Im strongly in favour of what @jotapea is doing, and i think that if we are talking about "community" wishes, then clearly github isnt getting community wide traction. I see that as a problem. So I'm supporting here as clearly as i can.

I agree with a lot of new users and devs, people should be allowed more time to understand the implications of changing these root protocol rules https://github.com/CounterpartyXCP/cips/issues/66!

[adamkrellenstein]

My perspective on this is that there do need to be channels for truly official communication, but they should really be limited to dealing just with protocol changes, which uniquely require perfect agreement, from literally everyone, where there's any possibility of controversy, bias, profit motive, etc.

The protocol must be kept sacrosanct. 🫡 Let's keep protocol discussions totally separate from everything else.