Fork is everyone’s problem

I’ll take responsibility for showing Mike how to do stamps with counterwallet

which means either you are a plant, and there is more planning behind the scenes, or you are basically fucking yourself

Haha and how do you know that? I offered to help with db issues and did them on my own. That was the only problem was db performance. All easily solvable without drama

144 blocks/day
x 30 days (1 month)
---
4,320 blocks

824,700 current block
+ 4,320 blocks
---
829,020 = Activation Block (1 month)

But tbh, we need to stop all relying on jdog and his infrastructure, counterparty can’t survive if it moves with the whims of a single person

of course

Cool we are building to support the core CP

xcp.dev is the solution

right and all you ended up doing based on your proposed agenda, is rugging the whole non-stamp community

opensource

not sure where 12 days came from... but it is 30+ days before any activation... so PLENTY of time for CP community to come to consensus on what they want their 9.62.0 to be 👍️️️️

their? no ser yours

I’m here working ser. Can’t rug if you’re on the carpet

do you have your fork repo?

It’s our stamps indexer code which was originally a fork

And now is an explorer/api etc

but you dont want to post it

youve already said that

will be public but not yet

when

Well maybe this speeds up that decision lol

when ready

Sorry your right, can’t trust my brain to multiply and divide. 30 days

Seriously if you’re not a dev and not providing meaningful conversation take it somewhere else

I will make it my focus next week to open source memepool

@vm_ea you look like a sock... only here in CP dev chat and not in ANY other CP/XCP project channels.

Im allowed to exist and ask questions in this chat, sorry

I ask a simple question like 4 times about fees and this is the first thing you say😂

Slows it down really because we have to shift focus elsewhere

cuz I think your a sock... and my history / views on this fee issue are in chat history here for anyone who does the tinyiest bit of searching 🤷️️️️️️

Is your indexer both src20 and counterparty?

src20 and counterparty assets that follows stamps yes

“That follow stamps” how does that work?

that follows cip 26 and cip27

Stamp only cp transactions

stamp:base64

What happens if a stamp asset is put on the dex and sold for xcp?

We see the send

It’s not a send tho

You interpret it as a send to the buyer?

Basically still parsing get_blocks and dropping into MySQL

The indexer runs a full xcp node?

We always have had two load balances cp nodes for stamps

Just ignore the spam

Was just trying to help 🤷🏼‍♂️

yes we parse it as a send

dex is not supported yet anyway

a thing we need to work on too, now we have dividends, dispenses, sends,

needing to parse this too but we didnt yet

Ok so you run a cp node in parallel and use that for balances?

we relay on cp for the balances

yes

Welp my offer still stands on trying to evaluate and incorporate a fee structure. If not all good. I’m out of here, best of luck

when you realized the oportunity you had and you loose to give counterparty to next level will be late

i understand why devs are not paying attention to counterparty for years, they smell the shit and turn around

propositions are not taken if not coming from the same guy

I think you need to understand there is 10 years of history on counterparty

i understand

i respect

but is not excuse to dont progress

That needs to be considered when deciding a path forward

I need to turn off for the night but I would suggest thinking of paths forward rather than fighting about what could have been and what not

im totally with you, but you have to understand that xcp has not any sense to exist if cannot help to support the protocol is not enough as an spam fee and is not enough to suppport infraestructure just waiting it to pump

I understand that better than you probly think

im sure ser but we are trying to put solutions on the table

Gm.. I’m sure Theres a Pepe for this somewhere.. just checking. 🐸

Jokes aside, what a shame / mess.

some here says about improving CP performance. as the solution rather than setting an xcp fee... put your heart where your mouth is.... stop "requesting" performance, grab the keyboard and start coding to get that

So far the only devs active writing and proposing solutions have been jdog and pategrillo. That should earn everyone's respect here and listen to them.

If you believe that JDog's solution to avoid spam should not be implemented. Please start writing and push a commit with your solution.

Large scale use of numeric assets and the heavy reliance on xchain is putting excess strain on user facing infrastructure. Since @jdogresorg rate limited apis and removed numeric assets, xchain should no longer be negatively affected.

The developers who previously received permission to use xchain for their tools are now in a position (partially of their own doing for relying on someone else’s infrastructure) where we they must now spend all available resources mitigating this immediate impact.

The word spam is being used here to describe a feature of the protocol being used for its stated purpose and the ultimatum masquerading as a proposed solution to the problem of onboarding new users into the ecosystem is to add friction to the onboarding process with a fee, that if paid directly in Bitcoin would be immaterial.

Although this probably wasn’t the best way to go about it, I think counterparty will have a viable open source xchain alternative in less than 30 days

burn XCP for colored XCP ordinal sats and use them for fees.
btc only.
use ord infra for sat tracking until build into CP stack.

upgrade XCP token to be BTC and remove the friction of obtaining XCP that very few gaf about.

so you're saying drop evertyhing that is going in place to bring up an xchain alternative to shift and fix the db issue? All within 30 days (or 0 days as numeric Counterparty assets have already been removed from xchain - so who can trust anything jdog mentions as a timeline?)

I suspect it's best to pause counterparty dev work until we can collectively bring up additional infrastructure to support the loss of xchain. Then circle back for upgrades.

the goal was always to require XCP *only where necessary*. named assets were expeted to be valuable, and so they needed a fee to prevent squatting; the goal with numeric assets was to create tokens that weren't inherently valuable, and so could be registered in droves without any problem

(With the understanding that 'original intent' arguments aren't always final.)

yes, and sometimes the incentive structure is not as simple as it seems!

like a free tier of any domain system that gives you a random url if you dont pay and the domains with cool naming, shorts and easy to remember has a price right?

Yeah sometimes you just have to try something then see how things play out

Can discuss hypotheticals forever, you never know until something is live in the wild

Again, if we're going by original intent, numerics having or not having an anti-spam fee wasn't something we had irreversible opinions on, but rather the attitude was very much that described by @hodlencoinfield

Anyway, I agree with the dev consensus: the perf issues should be decoupled from the 'anti-spam incentive'

I think you might wanna try a different teacher.. this isn’t working for you

Heading off to yoga will check into it when I get back in about an hour….

This is what we discussed after the last update, focus on optimization

Yeah, makes sense. @teysol and I have discussed this some but will wait for him to weigh in.

changing the sqlite to mysql/mariadb or any othere better db engine

As you said @XJA77 it's an 8GB db. sqlite is built to handle orders-of-magnitude more writes/sec than Counterparty, so not seeing how it can be the bottleneck...

bottleneck is when for working explorers need to parse this sqlite to mysql using a php script in a cronjob

Why not just make counterparty's api more full-featured?

this is the other point too

and posible adding a counterpartyjs sdk to avoid need of doing rpc calls to cp api

and being able to do in a more friendly way but yes im with you that there are possible different approachs to this

first step is have a replacement for xchain apis and explorer opensourced

i am doing a GET BALANCES post to the CPAPI and notice every result includes the address i post in my request, the api could be made to be more efficient by not repeating the same data as in the request over n over n over again

I know I haven't been in the discussion so far but I guess I just can't see how switching dbs and risking a consensus fork (not to mention increased complexity viz. deployment from a non-embedded DB) is the right solution to a performance optimization issue when we've got such low volume. And if Counterparty's API is too primitive, we should change *that*

okey

(Just my opinion! I want to understand the thinking)

this is a good solution too we are start working here to get it working asap https://github.com/CNTRPRTY/xcpdev

this has to be the first step to recover normally

having a full explorer and api replacement for those who was using xchain apis

yeah Juan shared this yesterday, so happy to see it! I understand the community needs to recover from the loss of xchain functionality, but I just wanna hear people's thoughts: are folks against enriching counterparty-lib's API?

im not against but we need a priority order

Sure, makes sense.

also adding this explorer to fednode is anoher interesting thing so every node has its own explorer

Yeah I do think that's interesting! Does fednode script still work well?

i think so, im using the juans repo and seems to be working well, i am still syncing mine with a full parse without bootstrap but was very straightforward

yeah I agree we should focus now on extending the counterparty API, fixing the performance issues and generally making it much easier and cheaper to run an explorer (eliminating the need for any weird DB translation via PHP scripts, etc.) I'm also quite confident that SQLite can do everything we need it to

lets do it

Yes… fednode works the same… slightly different components ( addrindexrs instead of btc addrindexrs patch, xcp-proxy for real-time payment notifications, etc), but same simple structure

https://docs.counterparty.io/docs/advanced/federated-node/getting-started/

Makes a lot of sense to focus on API first, much less invasive than a db switch

And no accidental fork/consensus risk

is there a running list somewhere of what devs would like added/changed?

Not really in one place but we have discussions enabled on the GitHub repo for counterparty CIPs so we could start a comprehensive list there

In my opinion the most pressing need is more block explorers, we should never have been relying on a single one all these years

That makes sense. Procedurally, would this have its own CIP or just, say, a running checklist addressed on an issue-by-issue basis, or a milestone, or what?

There was xcpfox for a hot minute

No I don’t think we need a cip for the list, that’s just the repo that has discussions activated

I mean, for the block explorer, it seems like a good place to start is @jdogresorg 's mysql script. https://github.com/jdogresorg/counterparty2mysql

We can just add all of the tables + indexes + endpoints he lists there to the counterparty-lib db say if you initialize counterpartyd with the --explorer flag or whatever

that's interesting, i like it.

we can just create a GitHub issue for that

Perfect

have you checked xcp dev?

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

then we could add a benchmark to check that reads from every table don't get much slower as the history grows

I have, yes, but have not fully read thru what it supports. is there a diff b/t it and xchain functionality?

yes main difference is xchain is not opensource and this is

lol i meant functionality

I would say main difference is it’s written in react

also

sure sure but what I mean is: are there features supported by xcp.dev that are not supported by xchain that might be good to add to counterparty-lib

mempool in memory i think and optimiced api queries

(using @teysol's idea of taking xchain's featureset as a base from which to work.)

Do you mean running a MySQL db in parallel that’s only function is to optimize API calls? Or optimizing the current SQLite db?

the latter

Nice, would be great to just optimize in a way that all existing APIs run way quicker, and just add some addition calls if necessary

Yeah, exactly my thoughts!

Nice incremental changes.

I think that one way to obtain performance is by separating db, api, blockparser, into services, since we cannot take advantage of CPU threads in python.

i think in principle that's fine but has there been any testing done to see where the bottlenecks are?

my gut says there are a lot of quick wins with db optimizations

Last year I did a test and the response times increased to 5 seconds in 50k connections

oof okay

I talked to @pataegrillo about this.

and I suggested to @pataegrillo using a multiplexer until the architecture can be improved.

Maybe we can use the hive multiplexer. https://developers.hive.io/nodeop/jussi-multiplexer.html

there was an optimisation made recently for blockparsing which made nobootstrap a realistic option when it comes to a fednode setup/initialisation as before it would have taken months to fully parse the blockchain

Yeah I think it’s down to a week or so

nobootstrap would not have been possible with out it - well it would but wouldnt have been used

this is great. can you share a link to the PR?

Mmmm a litle more than a week I am with a no bootstrap sync for 9 days and I'm at block 728523 with 8 cores an 16 gb ram

is it this one ? https://github.com/CounterpartyXCP/counterparty-lib/pull/1212 Juan may be a better person to ask about the details

-houston, mikeinspace would you like you to "fuck off and die."

i think the time to parse a block was reduced massively - no bootstrap was an idea that needed better block parsing to become a usable reality

I like this approach. This is how we did it in the stamps indexer. A separate docker instance for each db, api/explorer, indexing. Shouldn’t be too painful in fednode. A different conversion if constrained to cp-lib however

I can make the blockparser in rust or c++ but only if we want to achieve service based architecture.

although it will probably take me a lot time to do it, but that would allow others to join us

In May last year I wrote CIP29
https://github.com/CounterpartyXCP/cips/blob/master/cip-0029.md

At the time, thousands of numeric assets with zero supply were flooding the DB (SRC20, was it?). The concern was that eventually millions of new assets would degrade counterparty performance.

These were not even real assets, just data storage in the asset description. Instead of asset issuances, broadcasts would have been better. Broadcasts have much lower impact on Counterparty nodes.

An XCP fee on issuances would incentivize broadcasts over issuances.

This was the rationale for the CIP. However, if DB optimization is realistic, then a fee is not necessary imo.

I encourage writing a competing CIP that can potentially replace my CIP.

hm I'd be very surprised if this was necessary. Python can do threading + multi-processing just fine.

having separate Python threads/processes for the API etc would be easy. but first we need to actually add the relevant functionally to *counterparty*. right now we're taking about problems with the performance of a PHP DB-mirroring script

If a Thread is killed for some reason everything breaks, There may be deadlocks, race conditions and desynchronization. Also the use of multithreads does not allow the parallelization that is achieved with a service-based architecture....

The service-based approach would also allow us to use lower-level languages to increase performance on heavy tasks. and high-level languages for simple tasks like building transactions.

https://i.gyazo.com/f31e77db94b95b9d0810e0822d149216.png

I don't think the PHP db mirroring script is of much use for the community if we can fix the lower level issues.

nice! great to see the usage uptick. that's a great sign for growth and user base

xchain parsing lagging because numeric spamming is continuing.... wont speak anymore on it... other than to say.... you all know my views, this spamming needs to stop ASAP...

that was from openstamp launching their rat nft collection

no more drama... just saying... xchain is down due to numeric spamming.... and this is why we need the XCP fee on numerics

so nft collections with valid assets are spam again

heading back to bed.... still got a 103 temp and didn't sleep last night

confused if numerics are filtered out, but nonetheless. even btns broke xchain so it seems super fragile

will deal with this tomorrow... maybe time to start immediate activation of XCP fee on 9.62.0 and start running it tomorrow.... got no more time/patience for this... i'm done

check your msgs and email.

rest up. hope you feel better soon

CP community can deal with it... apply pressure to stop the spamming.... or, let it continue and let the chips fall where the yare

now back to bed..... hope you guys have a nice day

real usage with art being considered spam means the entirety of counterparty is spam

which i guess is true

9.62.0 is the fork or merged in?

Fork

I would encourage that jdog merges it on his fork so we can move on to more important topics

Counterparty is parsing blocks good the bottleneck is in the counterparty2mysql PHP script running for xchain right?

no problems here

loads of api requests and traffic to stampchain. nearly record highs! I'm bullish!

Should Counterparty data always be in the first output? or can change be in 1st output ?

and you said you didnt want to force a fork.... spamming numerics and taking xchain down as some power play is not gonna go how you think bro..... you just lit a fire under me to ACTUALLY fork.... up til now was all just threatening fork to force CP dev to cooperate and progress.... but, this spamming just forces me mto make a choice.... have XChain down for 30+ days... or force a fork and solve these problems immediately

We aren’t forking

Didnt want to do it.... but its done now... will be updating xchain to run in 9.62.0 and add immediate fee on numerics.... suck we are where we are, but as I said before, I wont let one project attack/cripple CP

We are staying with the core CP bits

Doesn’t excluding numerics in your SQLite to MySQL script solve the problem?

You have to understand ser that the CP parse blocks is working properly and is not our fault if the script you are running is not working properly or handling good the increased usage, if instead of stamps where named assets that you don't consider spam, the problem still be there

I didn’t think the core xcp was the bottleneck?

How is your shit infrastructure the communities problem

It’s not

Is not a spam issue is a bottleneck in the counterparty2mysql parser with high transactions

Please remove all named stamps on your fork while you’re at it

Or at least is what I understand from your reports

Which is only a tool one person uses that holds everyone hostage.

All cp nodes are parsing fine

More 10k nft collections coming in the next few weeks that might be named assets so jdog will have the same problems there

It’s called growth and user adoption that you’ve had many years to prepare for

can't help if people see the value in CP assets and wannt to rapidly mint them

One thing to note is that all of this recent activity is largely facilitated by significantly reduces friction to onboarding each user.

It’s being done on mainstream browser based Bitcoin wallets using one click web infrastructure, targeted at the average Bitcoin user.

User clicks button, user gets xcp asset.

From a pool of XCP y'all own or...? How do you make it so they don't need to wait a block for the XCP?

Current mints are using numeric assets

The one today was done by openstamp.io

Lol obviously needs to wait a block for it jajaja

What's so funny?

The part of they don't need to wait a block

yes the named assets will be from a pool of xcp we own. so the user friction will be null to onboard to CP

Sorry if you have been offended was not the intention ❤️

Right, right. Makes sense.

Really great to see seamless consumer-facing products on Counterparty

the only problem is these will still potentially take down xchain so we're forced to either kill growth or just press on and keep building.

Wtf

drama again? I thought we were done with that.

yes ser.... fork is not in 30+days as he told fork is today

Perfect

fuck spam.... i will developing tools on the CP free of spam amd shits.

definitely! we are too

this is much better lol

As you can see here in this wallet available for iOS and Android I will support numeric assets. Of course, those who have only paid a fee

oh you mean on the jdogparty

okey, we have leather okx unisat we dont need your.... sorry i dont know how do you say this is called?

I'm also working on including zk-snarks proof on redeem scripts...

kid, I don't need a centralized exchange. If I have been in bitcoin for years and I am a son of satoshi, it is because I want to promote freedoms using cryptography. not promoting more centralized shit on exchanges that steal from their users.

Don't waste time on stupid things. Get coding and creating things.

stamps, CP, named assets ordinals etc.... simply use technology wisely....

this is cool anyway i like it my face is a good face

and i was not talking about cexchanges i was talking about wallets

Amen! glad to see everyone moving away from the centralization of xchain and it's censorship and control

Stamps should update to Jdogs repo and let ego go.

This is going to cause a mess for all OG assets. Emblem, Rarepepe, etc….

I mean, the Counterparty repo should be the source of truth, no?

we are supporting the coue Counterparty Repo.

Yes, but if the stamps guys update, it will be pushed for certain and we’ll still all be on the same page

We all use freewallet, how is this going to work?

It’s not

That's not how it works, to be fair.

Agree.

Yea, I get it’s not how it works but for the best interest of the community, that’s what should be done

It's definitely not what should be done. J-Dog's PR is merged into Counterparty core, THEN at that point you can make the argument that Stamps should update. But not now, no.

Well that requires Jdog to stop his update

So either or works but someone needs to do something

What are you fearing? Lack of block explorer and wallet, I guess?

we are replacing xchain apis for that to opensource ones

The entire community uses freewallet for og assets.

Once his version becomes live, are we all suppose to stop trading?

Maybe half will use another wallet, maybe the other half won’t.

Then what?

Why would we stop trading? I don't think the J-Dog fork affects OG assets.

Wouldn’t there now be duplicates on each version?

Not now, but if the PR is not merged his or counterparty could on next updates I guess

what will happend is all new numeric wont be on jdog counterparty fork, but valid in cp

he did say he was keeping his ledger hashes in line with CP. So he will just see all numerics as invalid but the hashes will stay the same at the core level.

And what happens if you use the DEX to trade a Rare for a stamp?

All named assets would be seen as the same on both sides of the fork, but perhaps someone can furhter clarify

a DEX order between a new numerical with/without fee and a named asset would make the balances different?

potentially that stamp wouldn't exist there on his version of the dex

Yea we’re fucked

so it may be seen as valid on our side

so yeah that is fucked hah

not sure how that could keep the ledger in line. have to check the lib

WRONG.... research how ledgers work.... after block 824888, xchain will be running a ledger which requires an XCP fee on numerics (ie, all your spammed numerics will not be valid).... txlist, ledger, and messages hashes will all differ.... cuz we on different ledgers now... or... will be in 7 blocks

Jdog, give them a few more blocks 825069

the core issue is numeric spamming and it will not stop until XCP fee is put in place.... Stamps devs say that this is not them, so according to them, they couldn't stop even if they wanted to.... my choice has been forced... allow xchain to be down for 30+ days or force a fork... They have had 9+ months to work with the community... sucks this is how it is going down, but its time to rip the bandaid off n move forward.

always working with ultimatums, this is not decentralization

It’s clear the community wants the fee and stamp guys are willing to accept the fee for the betterment of the community.

Let @hodlencoinfield and the others devs decide if they want to push it or not

For completeness, why isn't bringing xchain down an option?

Like, why not go down that road?

bc xchain is his product

I get that but there may even be some server costs to save if brought down for a month while this is re-assessed.

so... take down xchain and stop CP community from being able to interact with CP for 30 days... all so stamps project can keep spamming numerics?

no ser stop interacting with your product

Because of FreeWallet?

cp stll up and parsing block perfectly

Right. But is there another viable wallet?

rarepepe wallet works right?

I appreciate all your viewpoints, but from my perspective, this has been talked to death, and I am done.... let the chips fall where they may now.... all I am doing is making a change to CP to keep xchain up..... doesn't mean that my fork has to become the official CP ledger... but, i'm done dealing with all these headaches n drama.

Just delay 100 blocks and let the chips fall where they do

OK, so you're forking. That's done.

Now what? Does RPW use CP? I'd bet it does.

and have you thinked in the drama and headheaches your decission will cause?

Noob question: is Counterparty (the protocol) needed to issue Stamps? I thought the Stamps devs were moving away from XCP when this issue/debate was raised a few months ago?

I delayed 9+ months bro... done

It is.

Yea so what’s 100 more blocks

Ayyy, RPW even allows minting.

So, yeah, RPW seems like a decent wallet solution.

bc is just a problem of xchain lol

Right. And I'm betting Joe is using the CP API. So we're well and good, no?

he is treating his xchain problem as a protocol problem even the founders of counterparty has told that that is a bottleneck in counterparty2mysql service used by just xchain

yes i think he uses cp api

Bro we’re not good

Jdog is the heart of the community for the last 7 years, is sick as fuck…

We should support his push

But he should delay 100 blocks

You keep saying this.

J-Dog keeps saying no.

no ser we shouldnt support a fork when it didnt solves anything

i'm only changing xchain servers to run in 9.62.0.... CP API servers, RPW, and everything officially "CP" will stay on 9.61.1.. only xchain is changing.... ppl can continue using CP as they have been in the past

We're 60 or 70 minutes away from the activation. People will have questions. rpw.wtf is the answer there.

counterparty is workoing smooth xchain is what is not working

We're fine, ser. I've confidence in us.

Clearly the OG community wants the fee, so that should in fact mean something

No bro, you don’t get it. It will be a huge mess. It’s just stupid.

i dont see it clearly

It should, you're right. But as of now, it's still just a pull request.

Look in the official CP room, look at the pole here

stupid is that if he told 1 month and activation block he awake this morning changing it and causing more drama

The sun rises as usual.😂

I 100% agree.

But 100 blocks would atleast give the devs time to make the official decision and you guys time to think it out.

the main point is xchain is not opensource, you are all relaying on a product

we are at the same time looking for solutions and building xcp.dev a real opensource explorer relying in real counterparty db

That’s great, but that doesn’t help anyone in the OG community right now

Rarepepe is going to have huge problems

People are going to be angry

not using PHP parser anymore, he has told, this meassures where for more people working on opensource tools, we took that and start working, 1 month is time enough IMO to have it working, but if he changes the timeline not...

fork dont help anyone right, build new opensource tools really help the community of og rarepepe, og sog, og danks, og fakes, og stamps everyone is supported with this new opensource tools

How many OGs out there trading their Rarepepes for Stamps?

All it takes is 1

One person to do it

I awoke this morning to xchain being down, and the decision between letting numeric spamming take down xchain/freewallet and STOP ppl from using CP... or push a fork immediately... sucks, but if numeric spamming had been discussed and dealt with 9+ months ago, or at any time in the past 9 months, we wouldn't be here...... I understand some ppl think this is a rushed decision.... it is not, this has been a long long road, I have demonstrated tons of patience... but as I have said, I am DONE, time for CP community to rip the bandaid off and move forward.

Fair.

but you dont understand that people can use other tools people will stop using your tools until you fix YOUR problem with your extra service that is NOT in the core of counterparty, counterparty still wrking pretty smooth

more angry than when they wake up and want to sell their RARE PEPE cards and cant cuz tehy can't use Freewallet?.... more angry than when they realize they can't view dispensers on xchain and sales grind to a halt?... We can all agree this is less than ideal... but time to move forward

100 blocks man

Just give them 100 blocks, go rest, and come back

ser they can trade using other tools and seeing dispensers using other explorers.

the problem for you is that they wont need to use your tools anymore

The tricky part is that there's a whole lot of community out there to migrate over to the other wallet.

100 blocks is 1 day... nothing is going to get solved today in 100 blocks... CP database updates not ready... stamps guys say they aren't behind the src numeric spamming so they couldn't stop in 100 blocks even if they wanted to.... please stop asking for delay... its not happening.

this is what he has done with stamp comunity last day

To be fair, J-Dog always pushed for more tooling. It was just the Counterparty community sleeping on it.

we are not sleep on it anymore working on it

I think it makes a huge difference. Not much to ask

awesome... sucks this didn't happen 9 months ago

I’m asking, I think the entire OG community would ask. The stamps guys aren’t asking for the extension.

you can check last pushes on xcp(.)dev repo OPENSOURCE

respectfully... disagree... nothing changes in 100 blocks delay... or maybe tell me what happens in 100 blocks that guarantees that numeric spamming stops, and xchain can come back up? Cuz... I dont see 100 blocks changing anything other than dragging out the drama for longer.

ser xchain down is just a problem if there are not other tools, if you could wait until the original activation block other tools we are working on can arise

At a minimum, it gives the Stamps guys 100 blocks to decide if they push or not.

push what?

If they don’t do it, so be it. Your update for the fee.

Maybe pull is the word?

dont do what? we gonna have code commit changes to counterparty-lib to address this issue in 100 blocks?

I think so.

can you stop this and work in the real problem? that is counterparty2mysql repo?

you know this is the real problem but you are lazy and ill

so.. what does 100 block delay get us other than more conversation in here about how things SHOULD be done and what we COULD do?

this is very selfish in your side thinking in your product up instead of thinking in the entire ecosistem

We don’t need conversation, we need the devs to decide to push or not

And the time to do that

all the reputational damage and devaluation of the assets this will cause

I still don’t understand why you don’t exclude numerics from going into your MySQL db. That solves your problem without the xcp fork

They've decided.

because he has to work

The problem is translating from SQLite to MySQL taking to long?

deploy the fee! Its the wishes of xcp holders!

For all we know, the devs could sleeping. 100 blocks gives them time.

with this with one line of code he solves his personal product issue dont mind the full protocol issues

sorry you see it that way... I see it as keeping the one block explorer and wallet that 95% of the community use as up... and, as I've said, there has been PLENTY of time for changes on your end before we came to this point.

they will change if is down

there are alternatives up alltime

As a longtime CP member, I’d ask if you would please delay for 100 blocks, go get rest because your sick as fuck, and come back and see what happens

glad to hear it, guess stamps guys wont have any problems finding alternative wallets and explorers to use 🤷️️️️️️👍️️️️️️

we start building xcp(.)dev to solve the issue of not opensource explorers

in a month we have time

we are working to replace also xchin host from freewallet so dont need to relay on xchain aymore and people that are in all comunities can still using freewallet without being a problem for you

sorry if I doubt that the entire guts of CP database can be ripped out, replaced, indexed, and working flawlessly within 30 days.... had this on the TODO list for many years with no progress... glad everyone is focused on the optimizations now, but I have 0 confidence that huge changes like this will make it into CP in 3 months, let alone 30 days.

we are working in solution while you dinamitize it

no ser we are replacing your api endpoints without needing a mysql db

cool! I look forward to when the need for XChain and the APIs are gone.... but that isn't the world we live in currently.

it was until this morning you decided to change activation date

work is in progress

new ui for xcp(.)dev work in progress, public api replacement for your xchain api Work in progress

You guys should agree to do it within 100 blocks

all open source

Talking about infrastructure and what we’re going to do helps nothing at this second

we are not going to accept any protocol change done by a dictator again

last one broke consensus and counterwallet

That’s ego. Let it go for the community. The community wants the fee for the most part. You guys are okay with it.

not is not ego is principles of decentralization and consensus and protocol changes has a historical way of being implemented as was discussed in the las one

Being paid in btc, but no one can build that if there are rushed priorities.

I get it. But what’s best for the overall community should be considered

time is of the essence, this will cause huge problems

ser the xchain product down is not a issue of counterparty

if it were opensource and in all the nodes maybe

but is not the case

again with the rushed narrative... been 9+ months of saying this spamming of numerics was a problem... so much so that a fee was threatened 9+ months ago.. and we backed down to give you guys time to talk and decide your path forward.... you decided best path forward was to keep using xchain, spamming numerics, etc..... This is not a rushed decision... its been a very long slow path to get here.

Either way we should give them 100 blocks minimum

you are a dictator

you keep asking for 100 blocks... even tho I played it out with you that nothing changes in 100 blocks... so gonna just ignore this from now on

Bro you didn’t give the devs ample time to even push or pull a change

sorry you feel that way. I am doing what I feel is right for counterparty, the exact same as you are... you wanna spam numerics n use CP that way... I dont feel that is what it should be used for... the community can decide what version they want to run

Gm, with all due respect I think everyone was very focused on the 30 days narrative but jdog is correct that I don’t know who is doing said ‘spamming’ and don’t control that, also I personally didn’t have a problem with the fees.

I think it’s the timing ‘suprise’ which seems to be the issue. Anyway I can see the die is cast

At least give them a chance. You were the one who selected them.

no disprespect meant man... you dont fully understand teh situation and are too caught up on "lets just calm down and talk"... we;ve had 9+ months... sorry you feel taht is not enough time... villanize me if you want 🤷️️️️

giving more importance to your product than to the community if I were in your position and had to have my product down for a while for the sake of the community I would have no problem because it is for the common good (as we are already doing since rarestamp is down since your rate limit and numerical removal and without maintenance since we are developing tools for the whole community).

I’m sure I don’t. But 100 blocks when they had 30 days yesterday isn’t much to ask for.

the problem is counterparty2mysql ser asume that

counterparty is working fine

your product no

take the time and fix the issues, if we start issuing tokens with the same rate on named xchain will still down so the problem is not the fee.

if you want to fork fork i wont try to convince you anymore, i will be back working on xcp.dev the only opensource explorer and apis at the moment

Argue now, fork later.. if nothing else it’s another twist for the Netflix movie?

This message might even make the movie .. 🍿 wild.

It’s obvious imo people will go straight for edge cases, and we might be putting out what seems like a small fire to find a bigger one imo. Anyway that’s me. Thanks for listening

ugh... yeah def need to update the website which hasn't been updated since 2014

XCP features are not determined by XCP votes... never has been that way, ever, even if website seems to state otherwise

Hey there, i won’t take sides as I don’t have time to catch up on the whole situation, but just one question :

What will be the impact of the fork on end-users? Should we prepare a FAQ or something?

I am against a model where XCP votes on features and would probably use any of my XCP votes to vote NO to any proposals for any features.... CP features should be driven by coders and community, not just by those who hold XCP..... just my 2 sats

Ok that was 2 questions :)

I would avoid trading any numerics for named assets for a while until this drama is sorted

Come on jdog, if you stand down it will be epic and you will be a hero. It’s prettyclear your point is well made, you are in charge. Why make everyone suffer. If you stand down you are jdog the merciful
Definitely a pepe in that 🤷

Just go back to the 30 days?

I mean you don’t have to answer that

Open plea

im for the fork at this point so we dont have to be down the hands of a dictator anymor, just please add to this change a change in the prefix and put JDGPRTY instead of CNTRPRTY

At a minimum 100 blocks

https://i.gyazo.com/2f6f285362292b7ea697c458064906fa.png

interesting... hundreds off numeric issuances AND thousands of sends in the same block..... ALL numeric stamps.... ALMOST like this was a planned thing to overload xchain... specifically after I hightlighted exactly where the bottlenecks were in CP..... I see you... others might not understand the games your playing, but I do... You forced this, even if others cant see it... as the saying goes.. "Fuck around and find out" 🤷️️

https://i.gyazo.com/92187daf71043b451cd662710545393a.png

fork has already happened

That could be Xcp users tbh

Angry people

Ah well, we continue. All the best everyone 🙏

it is not... all those blocks have just numerics... that 1100 sends was all numerics...

Just to be aware, there might be differences in balances between counterparty and xchain fork?

whats this entail exactly? If you dont mind explaining for the end user in basic terms - I am holding rare pepes xcp and some stamps

or if any action needed

I would just not trade any numerics for named assets for a while... give things a while to play out.

the less ledger differences the better

If so, I would likely need to stop updates on wtf until PR is merged

There'll definitely be deltas in XCP balance, right?

there seems to be a lot of confusion about what's happening with @jdogresorg 's "fork". what @jdogresorg seems to be doing is just running xchain.io off of a custom version of the counterparty software that implements a protocol "hard fork" (that the community generally seems not to be in support of).

what that means is that that balances of some users will be misreported on xchain.io, but only slowly, over time, as users actually interact with numeric assets over time. everyone else running the counterparty software will report the correct balances, and you definitely won't lose your XCP or tokens or anything like that

Hey @hodlencoinfield can we update for the fee in the official report and set it for 100 blocks…. To limit damage.

are we going to be following dictators all the time?

Right now we’re still in consensus, the further it’s pushed out, the more dirty it will become.

im a litle tired of it

To Adam's point: it's a UX issue. In particular, if the change on xchain is not socialized then people will not know they may be using a minority fork.

Can you send this in the Counterparty genchat? I've a feels it's the others that need this more than we do.

This still isn't how things work.

I am fine putting a message up on xchain indicating I am running on a 9.62.0 fork which has a fee on numerics... and this is NOT the current 9.61.0 release... not a hostile take over (even tho it might look like it)

it's a good thing that @XJA77 has been doing all of that recent work on xcp.dev . that will just be the block explorer with the correct balances

I think a big banner at the top with a link to a longer explainer post would be immensely helpful

working on with @uanbtc and @Chriton

yeah, thanks @jdogresorg . I'd just say "this site is running on an unofficial protocol hardfork. information might disagree with with what the rest of the network says"

but @teysol as txs happen on 9.62 balances *will* diverge, yeah?

yup

yeah, no one's losing XCP, but it will cause confusion.

but it doesn't actually matter *much*. wallet software is what's important

already diverged... 9.61.0 has numeric assets on ledger that 9.62.0 doesnt

Even though it's a hard fork, UX-wise it will *look* a lot like a softfork since txs valid on the majority chain will be invalid on the minority chain...

I think that's still just a hardfork

hardfork: rules that were invalid become valid
softfork: rules that were valid become invalid

the distinction is different when you don't have miners

ah right.

my point is that the biggest UX concern afaict is someone trades their numeric asset for minority-fork XCP on the DEx, but that seems unlikely since non-fee numeric assets aren't issuable on the minority fork

so disruption should be minimal as long as xchain makes clear it's running 9.62

When someone mints a numeric asset on FreeWallet and pays the 0.1 XCP, the XCP balances will be off.

yeah again, as long as wallet software isn't hardforked, then user impact is minimal

@jdogresorg said he's only updating xchain to 9.62

Freewallet defaults to using xchain as its API though. Wouldn't that also basically be forking the FW software?

Disclaimer: I'm probably just super dumb here and missing something.

think this api is just used for balances

and to retrieve images

yeah that's what i'd assume but need @jdogresorg to weigh in

Thank you, thank you. That clears it up.

but your general point is correct: if wallets don't use 9.62 on the backend then there shouldn't be any loss of funds.

Freewallet uses api.counterparty.io to generate txs.... api.counterparty.io is load balanced between api1 and api2.counterparty.io... both of which will be staying on 9.61.1.... TLDR, Freewallet generates txs using 9.61.1

no changes between 9.61.1 and 9.62.0 except XCP fee on numerics (and a couple bugfixes)... so regardless of if they are using 9.61.1 or 9.62.0.... txs are generated the exact same.... just processed differently on 9.62.0 (numerics without XCP fee not valid)

Please can you list my rares on openstamp, bitcoinstamp and all stamp websites, if not openstamp etc are dictators

Is posible to list stamps in rare directory?

They are directories not full explorers

Rare Directory closed many years ago

Why can't I use stamp wallets for non stamps?

Why can’t I use bitcoin on eth?

U can if you bridge/wrap

The point I'm making is yall be calling someone a dictator for choosing how to manage his build/site/infra, and expect/demand inclusion on your terms, instead you could be spending ya time with all the stamp resources/sites to get what you want

no problem with personal infrastructure chosing to do their own thing. It's just the fact of pushing those decisions onto an open protocol. And also unclear and constantly changing messages. ie. BTNS is not spam, stamp images of all types are spam, numeric assets are spam, even paid numerics that PAID the 0.1XCP burn fee don't even show up on xchain. Why would named stamps show up but not those?

So is all this really about the fee? If xchain is anti stamps that's fine at least everyone knows, and decisions can be made to create infra all around.

To me all of this is simple. Stamps is supporting the core Counterpart and building infra to support that (and not just stamps). And xchain is moving towards a more focused forked part of counterparty. End of story. We can all move on now.

remove all stamps and fork. all good. no reason to list some stamps

I think stamps and CP will continue to grow, if jdog decided at start to not allow "spam (stamps)" then stamps wouldn't be successful today, we have heard your points multiple times but trolling, personal insults and demands won't get you very far

Imo Mike knew numerics weren't for mass use so there's that also

No one insulting anyone, what’s done is done

100% Jdog was in the room on day 0 of stamps and was a pivitol factor in their existence.

The message has changed from stamps are good, src is bad remove it - OK we did - now numeric stamps are bad, named stamps are OK - oh wait we need a fee - now stamps with fees are BAD. it's all over the place.

There has been plenty, on twitter and on telegram

Be respectful and a bit of gratitude

also loads of respect and gratitude as well

And build instead of whinning

Dude.

Respect and gratitude isn't yes I thank you, but also ur a dictator

can have respect and gratitude for dictators

Given all of this. . The only thing that would be super super cool is the request to remove ALL stamps from xchain. This makes it clear, and minimizes any issues between forks. Everyone can continue building.

Again, another demand

how is it a demand? why remove only some portions of stamps but not others?

then allow paid stamps at least?