FYI:

I’m keeping a counterparty-lib v9.59 node on: 959.xcp.dev

The main reason is to show/educate about protocol changes, NOT to write new transactions from this version.

Sometimes it could be down because I also use that server for testing, but I try to leave it working again when I’m done.

Hey @ABlue0ne good to have you here. But I thought I shared the t.me/xcpdev chat 😆

Jeremy controls everything. What else is there to say?

Let’s continue the conversation here my intention was to share this group not the xcpchat one.

Bitcoin + Counterparty Node Setup

https://github.com/CNTRPRTY/xcpdev/tree/main/server/fednode

🎉

👋

🙌

❤️

What do you think of making a CIP specific to this message by @jp_janssen?

https://github.com/CounterpartyXCP/cips/issues/66#issuecomment-1380461706

I’m thinking that’s a more principled way to cover the original issue presented

Not sure it's worth the effort. The issuance logic is messy but it works.

The last update was not backwards compatible. When this is necessary you must use a new message id imo. But you cannot go back in time and change this now.

I recommend rather writing a cip with general rules/principles for protocol updates.

seems to me there is a pretty comprehensive guide
https://github.com/CounterpartyXCP/cips/blob/master/cip-0001.md

IF this is not correct information, then perhaps it could be updated?
The current CIP editor is Christian Moss who can be contacted at christian@mandelduck.com.

the page has the word "consensus" seven times, but does not say what happens when the implementation of the rationale has code without agreement. It seems obvious to me that if there is no longer consensus then, the CIP is not finalized.

is the right thing to do propose an edit to that document? Who approves that document at this point? or more importantly, who should have updated that information if/when Christian stepped down?

It appears to me that there are more than enough things mentioned in this document that are currently being ignored in order to cast doubt on the effectiveness of the whole current process. It is obvious to me that there is an inherent conflict of interest when the biggest private service provider in the community is also in charge of so many things, including a fork of the counterparty project on another blockchain, and worst of all exclusive rights to the github edits.

CIP25 is a great example of being above the rules as ruler. Without altering the protocol itself, many things were broken over night. The rush to finalize adoption while in draft stages show me that there is no intent to work with the community.

Cognitive dissonance keeps reaching an all time high, from my pov.

Yet still I'm continuing the work I've done to document my own upgrade to the standard meta data used. His sophomoric approach to a solution has its own benefits and drawbacks. Glad that he introduced me to the acceptance of arrays and nested keys. Now the challenge is to explain why the choices he made are in accurate, as well as introducing my innovations for interconnectedness and media expression

I hope to share my work with interested parties as soon as I get everything together and presentable. It is a considerable amt of information and is taking some time to process

Yes something like that was what I had in mind.

Then, the issuances situation as a separate CIP, which there are multiple ways to move forward.

But ignoring what happened should not be an option.

v9.60 release, CIP25, Dogeparty Foundation vs XCP Foundation…

Many things to address.

It's not a case of ignoring what has happened but rolling back the chain is not an option .. what's has happened has happened and it cant simply be undone .. but we must learn from it and ensure mistakes like that are not repeated.

The cip had been in draft a long time and there was communiity support for the reset of divisibility status having the creator possess the entire supply was seen to be a good way to ensure token holders could not be effected by a reset initiated by a token creator

Having an eternal lock on an assets description is a great idea, counterparty was created as a financial platform but its being used in different ways than imagined so well thought out updates and enhancements are essential

the objective was agreed upon.
the method was not.
an alternative was proposed.
the change was pushed through despite technical objection.
so it comes down to oversight.

the person who decided to make the change active did so because of personal benefit (even admitted as much). Not for the betterment of the community at large, but simply to strengthen the position of the biggest centralized service provider.

let us not repaint the past into a fabricated narrative of the oppressor

The process however seems to have broken

well thought out updates and enhancements are essential
and botched uninformed updates that are not agreed upon first will only cause worse problems

the difference between a Lead Dev and a Lead [pb] Dev are not visible unless you can read the difference before it is too late and the project is sunk

I just saying what I saw occur, It all happened very quick and a lot of the technicalities in the code are a bit beyond me, I have since started to get an understanding of things like message types

I saw Javier say that mistakes were made

Longer test periods are needed before non backwards compatible code changes are to be pushed

ideally backwards compatible changes aka softfork are what we should strive for .. and it seems as though message types are how that is achieved ?

all the documentation and policy in the world will be fruitless if only one person is exclusively controlling so many facets of the entire system.

read this tweet yesterday, and couldnt help but draw parallels
https://twitter.com/rodarmor/status/1619142214046851072

https://twitter.com/droplister/status/1619174575509737474?s=52&t=ycaBtZauILqKwGfFA-rAig

I agree message types are a good way to avoid forcing hard forks

I have seen counterparty called 'a one man show' and I can see why

it needs more active devs .. I am guessing that is why it's ended up this way ? .. John was great but he is gone so JDog kinda became both the biggest centralised service and then also the lead dev