How many pending transactions are in the queue?

We are doing everything

You are asking

i think is fair know damages before accept anything

also i want to know it

yeah... NOW not earlier this week when I said it is abuse... I am simply asking for terms before we agree to stop fork... how many txs are in your queue?

I think this is a fair request

approximately 2000 pending maybe closer to 1500 - tough to say spread across 90 wallets

okey then not wait one hour more IMO

As a good faith gesture an immediate cease is necessary

Yes, 2000 is acceptable.

We are preparing a message to stop mining from our website in 1h.

It would be good to align the message between all so that those who have used our service and that of Stampchain do not think it is a rug or a Scam. I've been all day solving incidences of whether this is a Scam, at least 200 people have been talked to and I can't take it anymore.

In addition, we are using the Stampchain API and I keep writing that our tx take longer than Stampchain's and that if Stampchain makes us frontrun of those that go through our website.... It is a question to which I have no answer because although I have asked, I have not received any answer. I had to create a medium article to explain how post mint works, because I was called a scammer every 10 minutes because of the time it took.

What can't be is that we put this standard out at the time so that someone else wouldn't do it wrong. And that we are at this point. Without working indexers and people doing over mint, without aligning with CP which is necessary for the success of the project and without more communication plans so that it does not spread worldwide that the SRC-20 are a SCAM.

The solution at this point is very easy, 1st we send the message (explaining well why we stop it) at the same time that we stop the minting, 2nd we wait for the queue to be processed so that 2k messages do not come to which I will have to answer during 24h without sleep.

The question that everyone is going to ask is what happens to those who have minted? We have to give an answer to this. Jdog you understand better than anyone how SRC-21 works, could you help with this part?

No.. they can mint... i'm keeping track.. if they go over 2000 from this point, it breaks the agreement... lets call it 2500 just so there is some wiggle room for them 🙂

that work for you guys? keep minting, but no more than 2500 src-20 mints... agreed?

Just pull it

yeah finish a smoke and a drink, do some notifications on the website, etc and we'll be paused after that.

then you stop service and migrate to src-21 (and we can still hammer that out together, or you can take what I wrote and run with it)

that was easy

It will cause fomo

Guys, seriously, we are on the cusp of something big. Please let’s not squander this.

yeah, happy for the feedback on that. just need time to dig into it

we will be called scammers if there is no message explaining why it stops and what is going to happen with the mining.

Please don't announcement one hour to close

We will get 20k in

100%... stamps and src-21 gonnna soak up all that brc/ordinals attention... and SCALE on cp with src-21 🙂

Explain we pause due to several capacity

Exactly just 404 it “under maintenance”

Okey, I´ll prepare a little message and share it here

NORMAL STAMP SERVICE FOR ARTISTIC STAMPS DONT HAVE TO STOP NOT?

i'm not announcing anything.... crisis averted... you agree to no more than 2500 from now, then migrate to src-21 🙂

ups sorry for capitals

No regular stamps are totally fine

thanks sir

i hope some art come to live again

But since this is an attack surface I do think we need to phase out numeric assets with zero xcp fee

This is the day counterparty and stamps die, long live counterparty and stamps

Talking to ja

Stamps continúe ok

/make/stamps_great_again

Yes, stamps can continue to use numerics fine... they are not absuing the system, cuz they are creating actual supply and allowing users to use the features (dispeners, etc).

what do you think of this message?

SRC-20 Update: Minting Pause to Launch Real-Time Balance Indexer and Process Queue Backlog

Due to a surge in demand, SRC-20 minting is experiencing delays with over 2,000 mints in the queue. We've decided to temporarily pause new minting until the current queue is processed and our real-time minting counter is launched.

To improve the process, we're working diligently to develop and launch a real-time balance indexer as soon as possible. This tool will prevent purchasing of already minted src-20.

If you have already initiated the minting of your SRC-20, rest assured that everything is in order. Your minting request has been added to the queue and will be processed in due course.

We appreciate your patience during these improvements.

I’m all for this lol

But I think Mike might have a point here.

Let them mint these src-20 with XCP until it’s unaffordable with an XCP fee

That’s not a solution tho, the problem is src-20 discovered an attack surface and asking them to burn xcp in a gentlemen’s agreement doesn’t change the fact that this attack surface exists

And the age of the bitcoin indexer is upon us, so this is an issue that needs to be tackled before someone else decides to do it

Even with an xcp fee you can still flood the DB for free. The issuances will just be stored with status=invalid.
Ie counterparty should also stop adding invalid issuance to the DB.

https://forums.counterparty.io/t/cip28-broadcast-token-name-system-btns/6597

Came to a decision last night... I have updated the spec src-20.1 as request by the stamp devs, and removed the BTNS from my stampchain repo.

I have published the Broadcast Token Naming System (BTNS) as CIP28, published it to the forums, and minted the first 3 tokens using this new spec.

My primary goal with the BTNS was to provide an OPEN and scalable system which anyone could use to experiment on Counterparty. This goal has been accomplished, so I felt it was best for me to publish the BTNS, mint some tokens to demonstrate how the new system can be used, and to respectfully bow out of any further discussions on SRC-*.

SRC-20.1 with changes you requested
https://github.com/jdogresorg/stampchain/blob/main/docs/src20.1.md

CIP28 - Broadcast Token Name System (BTNS)
https://github.com/CounterpartyXCP/cips/blob/master/cip-0028.md

CIP28 Announcement and notifying people first 3 tokens have been minted
https://forums.counterparty.io/t/cip28-broadcast-token-name-system-btns/6597

I plan to focus on building a BTNS indexer, work on getting support for BTNS into xchain.io and freewallet.io, to allow people to start minting and sending these new BTNS tokens back and forth.

Integrating SRC-20.1 support into XChain and FreeWallet will be pretty straight-forward, should I decide to do so in the future.

Over the last few days it has become clear to myself, that the motivations of the stamps/src dev team are not aligned with my personal values, nor those of the larger XCP community, and as a result I am not comfortable working on integrating src-* into any of my personal projects.

I will continue to work on tokenstamps.io and support the "Stamps" projects (issuances with supply issued).

I appreciate the Stamp Devs agreement to not mint more than 10K src-20 stamps, and hope that this gentlemans agreement is honored, and we can avoid an immediate fork which will put a fee on numerics.

I feel at this time that it is best that I remove myself from any further discussions on src-* specs, timelines, features, and allow the Stamp/SRC team to run the project as they see fit.

@pataegrillo can you please have the PR to put a 0.25 XCP fee on numerics ready tomorrow morning... I want to be ready to fork the moment we see src-20 issuances go over 11K (at about 9k now)... I hope we dont have to fork, but want to be ready on Monday. 👍️️️️️️

There are devs besides us issuing these as well. So it is a bit out of our control even though we have stopped new trx. How will a fork impact those that do not upgrade to the new CP bits? I assume the old bits will continue as normal but just diverge from the main CP and xchain db?

Understood, if your minting service is not running, then we can allow the number to go a bit higher than 11K... but ppl should shift to src-20.1 ASAP whenever you finalize it and put it out ... a fork would put a fee on all numerics, which would mean that the "Bitcoin Stamps" project would not be able to mint any more stamps... I want to avoid this, the goal is stop abuse, not limit creativity...

A fork would play out like this:
1. We out put new counterparty-lib release with an update to put fee on numerics
2. We update xchain and API servers to use this new version
3. Any transactions which attempt to issue numerics without XCP in their wallet, will be considered "invalid" issuances in this new system
4. Your free to run the "old" version before the fork, which would allow you to keep spamming numerics

You could continue using 9.60.1 version of counterparty as you are now... However all tools, explorers, wallets, will be on 9.60.2, which will consider the numeric issuances as invalid... so they will not show up as assets on 9.60.2

I really tried to avoid this man... but, it is what it is now.

I am getting offline for the rest of the day to spend time with my son... will check in tomorrow morning.

We have stopped accepting any new trx as of last night as we confirmed. Nothing has changed. Thanks for the detail

Yeah u tried super hard..

Literally went back on everything you said

Private blockchains ngmi

Sorry

Good luck

The most dishonourable person In xcp.. including medici imo really sorry you did all this.. but your history speaks for itself. And everyone knows. Sorry not sorry. I really did try.

Yep, I figured some would take this viewpoint, and decided I had to be OK being the villan in some peoples eyes. I am sorry that you feel me focusing on what is best for CP, stopping spamming, and putting forth an OPEN system is seen as a negative. I know that other devs do not share your viewpoint, and I stand behind my actions over the past week.

Spam is a very relative term. It can also be perceived as growth and contributing to something new. Spam by definition is something irrelevant or unsolicited of which this is not.

It’s all a perception of what is relevant. We have proven that these transactions are very relevant to many people as shown by their actions and dollars - and we intend to build based upon this relevance.

Any dev in their right mind would build upon customer demand and build the infrastructure to support that regardless of perceived limitations of a database.

Perhaps this is why CP has been irrelevant in the space for so many years with this fixed anti-growth mindset that is supposedly so open. I agree the first attempt was not the most efficient, but that is no reason to stop everything on the tracks and diverge from a fruitful partnership.

All we needed was a week as you agreed while we retooled, and then you decided to change your mind. It is the xcp community that has suddenly been left behind and that is very clear to everyone.

If it was open there wouldn’t be one person calling the shots to exclude new developments. The community as a whole and those coming on board would have a voice. So that is a complete farce you can hide behind.

It became very clear that your focus was on centralizing things through your service, and adding additional requirements (like UTOXs and keyburn). These were unnecessary additions, so I felt it was important to put the MINIMAL spec out, to allow people to mint without those requiements. Stamps and SRC-20 still have a great value prop with those features, but they are not required, and eventually someone was going to just create a new prefix and do away with those requirements anyway. Your still free to implement src-20.1 or whatever path you want to go forward, you have all the focus, attention, users, etc... this is NOT an attempt to steal your thunder, simply putting forth an alternative system open... If I wanted to damage stamps, I would push a fork, I dont want to do that, and have done everything in my power to avoid that... This is not a case of one person running the show here, OTHER devs also told you the same thing I was telling you all week, I am not the person who called for the fork, another dev did... I am just the one who has to deliver the message... My hope is that you guys put forth SRC-20.1 with whatever mods you want, then continue with your src-* stamping in broadcasts... You have the attention and I want it to stay that way. All I did was publish an open spec and mint tokens on that spec.

for the record, the utxo and keyburn are requirements to ensure immutability and lock in value. not to decrease openness these are publicly stated requirements, and you have stated you will build keyburn into freewallet.

It was the unnecessary threat of forking prior to the agreed upon one week timeline by you is what stopped everything in the tracks and has squashed future growth potential between both parties. I saw no other dev threatening a timeline of the fork in such irrational and unprofessional manner. I'm glad we made things apparent early that CP has no intentions of growing with the success of stamps or src-20 and merely wants to propose competing methods to the community and abandon any potential strategic partnership.

fwiw. you just stated that you saw and recognize our value proposition of keyburn and utxo's and decided to publicly announce an inferior, less "valuable" alternative to the community. That is blatant backstabbing at it's finest. What good does this do to anyone? Pure fuckery and dick swinging because of your beloved database and supposed openness? How many years have you had to announce that technique to the public and you decide to do it now?

I’m against any “emergency” fork, it’s not an emergency it’s a thing that needs to be addressed and appropriate time given for discussion and then time for people to upgrade

Personally Ill need to update Freeport to remove asset issuance

Of course, I'll try

Okay, @reinamora_137 take a breath. What we have here is a solution, a path forward. Iirc we all knew about the difficulties of moving fast and breaking things. I understand how this feels. And I’d like to remind everyone that there is a process for handling this stuff, cip’s PR’s and discussion.

No one wants a closed system, and building systems like these are difficult (especially with rapid growth like this)

I can say that stamps Vs named stamps alone has been hard to figure out from an infrastructure point of view. Now throwing in ordinals and xrc-20’s all over the place it’s gotten insane. I really thought that there was some positive discussion here around making a standard which could be grown and done in a smart way.

In Jdog’s defense he could have just said, yea it’s an open system but it’s not well thought out and exploits an old system we are considering removing, and xchain infrastructure just wasn’t going to support it. But that’s not what he did. He did work hard to guide and encourage a spec that made sense without abusing the system.

Named stamps was not our project and was never intended to be included. This was j-dogs invention and created confusion in the marketplace. Along with creating tokenstamps that allowed for invalid bitcoin stamps and a completely separate numbering system from ours. Further complicating matters for everyone. Completely unnecessary from a supposed partner.

There WAS a lot of positive discussion and we were going to take this week to implement changes without disrupting what we built. However, Last minute yesterday j-dog threatened a fork and then released another competing and confusing alternative.

Again it’s just one person calling the shots. Is there any other devs here in the community supporting such emergency measures over a few thousand records? Please let me know if I’m out of line, but allowing one person to do represent a supposed community in this way is extremely detrimental and very evident as to why there has been no growth for years.

Perhaps j-dog is the only xcp bag holder so that would make much more sense

Anyone here has a vested interest in seeing Counterparty succeed either through holding xcp or assets or building software that interacts with it, jdog is one person but he does run the only block explorer so he provides essential public infrastructure, anyone could build their own explorer and run their own fork in fact that’s exactly what Juan was doing for a few months (maybe still is?). jdog speaks for himself and only himself (which includes services he maintains) just like anyone else here

This is important to remember. And is nuanced, but quite true.

Great so why is j-dog speaking for the larger CP community and “emergency” development of that ecosystem. Rather than just for x-chain? It’s apparent we need to create our own explorer, but we would prefer to be aligned and contribute to CP updates as a whole and move forward with any such updates and improvements on our end.

I don’t know why jdog does what he does I’m just telling you the reality of the situation

I think most devs here support the CIP process and that any consensus updates go through that

I do suspect that one of the best things that can come out of this, is the discussion that follows. How do we, as stake holders grow this system together.

Ok so this emergency last minute fork was all bullshit and j-dog single-handedly destroyed a partnership between bitcoin stamps and Counterparty for something outside of a supported CIP? When he could have just waited through this week like we agreed. That’s all I wanted to clarify really. And Javier just blindly implements whatever j-dog tells him without further review from the team? Got it! Totally open and decentralized lol.

To be fair, I created the project named stamps, not Jdog. I think it’s confusing you just didn’t include all stamps from the start.

Ok thanks for the detail. We chose that because we had specific requirements from the start, but we were and are open to changing those as markets demand. We just wanted to keep it simple and limited to a specific set of images as an art project.

I think you guys are doing an awesome job and bringing a ton of attention to CP and the community really appreciates it

Lol now we are committed to shifting attention away from CP because of one persons actions. But yes that was our initial goal to grow together and both succeed.

I mean jdog could certainly update all his servers with whatever version he wants, why would you think otherwise?

That’s fair. No problem with that. It’s just a larger CP divergence. Why wouldn’t he have his own restrictive fork instead of forcing everyone to his standards on a whim

But I’m sure if that happened there’d def be a big risk of forking so I certainly wouldn’t want to see that

We clearly all love CP, everyone wants it to grow. Nothing has changed as of yet. It’s just words. That’s why we’re all fired up.

Let’s just find a way to work through this that’s best for everyone.

Having STAMP: is superfluous anyways. There will be other prefixes or none used too.

https://twitter.com/punk6529/status/1657844189952892941

Counterparty getting mentioned here is nice to see

Words and shallow threats that shut us down on one persons perspective is not ok and not conducive to growing together.

Well I’m the one that brought up adding an xcp fee to numeric assets, but jdog just went from 0 to 11 lol

In my ideal scenario that idea would be discussed for a week or two then a week or two notice given to everyone to update nodes

I can understand the annoyance from both sides. I think you both have a right to be annoyed but we all have the same goal.

1MAXVoLUMEWWWWWWWWWWWWWWWWWRhkLVK

I'd recommend hitting up this dispenser for the moment

relevant to the convo xcer and i were having in rare pepe chat

That’s pretty standard for consensus forks, maybe a bit sped up but gives people time to adjust. The biggest problem here is that while numerics are great for using Counterparty without xcp they share the the same db table as named assets which has been increasing in records due to them being used as arbitrary data stores

this is perfect. we have been totally open to burning xcp for any stamp transaction. We even talked about an sXCP token on src-20 to get creative in contributing back in addition to an xcp burn. however not anymore with us being shut down forcefully. now we are perceived as a competitive force and have lost interest in contributing to CP with such blatant disregard for a mutually beneficial outcome. that's really all there is to it.

But I think you can appreciate that you don’t have any vested interest in 9 years of assets issued prior to your stamping service

While most of us in here do and from that perspective numeric assets have now been exposed as a potential attack surface which degrades Counterparty for everyone

i personally have many CP assets and have a vested interest in that front as well. Certainly much more of a newcomer, but as a newcomer its disappointing to see a community that I perceived as open and willing to grow being controlled by one person that can clearly go from 0-100 in a snap and disregard a partnership. I do see the technical reasons and agree things needed to shift. I also have no problem with those adjustments (i think it's better for the btc community as a whole). Just not in an off the cuff manner which forced our hand into being perceived as a spammor and competitor. We asked for this week to implement a change and were forced last night to stop all services. total bullshit,I have lost all trust in aligning in a meaningful and mutually beneficial way.

Jdog is not the community

We are all individuals

With our own self interests

So you can be mad at jdog all you want be don’t deflect and say the community this the community that, it’s just not accurate at all

So then we are free to spin back up our services and look forward to implementing a change as needed in alignment with a CIP and the entire community engagement, and implement such required changes in the coming weeks and j-dog can take whatever fork he wants to x-chain in the short term?

This also isn’t the first time we’ve had big disagreements over things lol, it happens and you need to work through it

cheers to that. i'm still here chatting and seeing what the community is all about. up until now my perspective is that it was coming from one person.

It’s so crazy to watch all the similar patterns and discussions popping back up (I’m mostly thinking about the big public btc battles)

I mean you can do whatever you want lol

Last time a big argument happened, XCP shot to $100

Looool

(**checking dispensers)

true, but i would prefer to do so in alignment with the broader community, and with proper agreements that are upheld on both ends.

Exactly!

Joe, a what point would you consider a fork. I am not for a fork, but if the spamming continues much beyond 15K src-20 non-usable assets, the urgency for for a fork increases. I have never, and will never push code without community consensus. So where is your line in the sand? If service resumes and we have 50K assets in a week, is that an emergency? trying to sus where your line is.

I think we’re getting somewhere lol

as it sits Javier is forcing our hand with sudden changes that were outside of our prior agreements

No he’s implementing a change on a fork that may or may not become a new version

That’s how upgrades work

No one has merged any code. Just want you to know we take issue serious, and are ready to move if "abuse" continues... but community decides, not me.

What’s the formalized process when it comes to approving code changes? Or is it more of “if node runners don’t upgrade we don’t have consensus”

abuse is a very relative term. especially if we are all working together to implement a change that everyone agrees to that benefits the entire btc community as a whole through more optimized data usage. it's no reason to shut down something that is providing growth to all of us, and bringing more eyeballs.

haven't had a really contentious fork.... closest was a fork Julian threatened to fork CP ledger to BCH... never happened.

Had there been clear cooperation from you earlier in the week, my tone would be different... all the stamps and src-20 stuff was implmented in a VERY abusive way. Which could have been avoided if you had even had a single conversation about src-20 and how to implement... I want cooperation, but from my perspective, you did your own thing, ignored my warnings that it was abuse and harming CP long-term, and that you should work on a new standard... I even wrote the standards for you..... all that is to say, I WANT to cooperate, and feel I have demonstrated that, and still do..... but just because your saying "gimme a week" doesnt mean we can allow spamming of 50K more assets... you did 10K in a week.... and all are unusable assets... so, this is why my tone changed. I still want cooperation, and want you on CP... sorry if my tone puts you off... tough to deal with the stress at times.

and what is the harm in 50k more assets if it's bringing that many more eyeballs to the community, and grows a partnership while we work on a real CP updated without the threats? Even 50k assets at a .5 XCP burn rate (which we offered) sounds very reasonable, but that was turned down.

I think it’s in reinamora court as to how urgent the need to enforce an xcp fee on numerics is, but from my perspective it needs to be added at some point regardless

happy to support that and contribute back to XCP in that way.

50k numeric assets is no big deal... 50k numeric assets that are unusable, written to a table that EVERY query on xchain ties into, slows things down

growth sounds like a good problem to have. especially if it is financially beneficial to everyone

using 50K number... your asking us to allow you to spam 33% of all assets ever created, in a week... all those assets are unusable (no supply, locked, cant use any features of CP)... so YES, 33% growth in a couple weeks is a big deal and needs attention

It’s because they aren’t being used as assets just as data stores and it’s propagating a standard that will very likely require a fork from Counterparty (at tbd time) for anyone that uses it

could not be a query update to discard in filtering assets locked and with 0 issuance? just as an idea

I mean you could spam the same way with 100000000 issuance each

correct. I agree with that. it's just a short term thing we requested to have this week to implement a potential change.

Actions speak louder than words here

We all know what “two weeks” means in crypto world

always optimizations to be made, but will take time, in the meantime, xchain slows down, freewallet balances dont load, CP ecosystem grinds to halt.

we asked for a week on friday or so and we got 1 day before shit hit the fan. I didn't even have time to review the new specs

if everyone is onboard to making the CIP and implementing the change in two weeks then of course we can make that happen as well. That's fair

I wish there had been more engagement earlier in the week. Please review the spec now and work to push it out... the only difference between BTNS and src-20.1 is the new "ICON" field I added to allow people to associate an icon with their token.... you can do what you want with your format 🙂

i wasn't even in this chat a week ago and had no clue the intricacies so we had no time to prepare and discuss

I brought it up in the STAMP dev chat I created when Bitcoin Stamps was created... so all stamp devs could coordinate.... yet no talk of src-20 before spec was put out... .all the chatter happened in stamps-dev channel in last week

which unfortunately, all of us have left 😛

You already spent one week doing nothing and now you want 2 more weeks lol. What exactly kept you from working on this last week?

what really is the difference between 0 and 1 issueance anyway. we can change the current method to 1 issuance if that makes it better, and just disregard asset ownership changes on that level as well.

the overarching thing is implementing an xcp burn for numeric assets which we fully support

doing nothing? what are you talking about? Joe said it takes 2 weeks to prepare a CIP typically so I figured that was our timeline

but i'm happy with a week as we originally agreed upon if you can implement the xcp burn mechanism by then

You were made aware of the issue a week ago and did nothing to address it afaik

I think that’s part of the problem

this is complete bullshit.

If you use broadcast for everything but a "deploy" in src20 and you will be making a lot less numerical assets , the output on chain is the same ..multisig with burn keys

At this rate in a couple of weeks there will be more locked numeric assets with no supply than genuine assets, this is going to make cp look like spamland. What’s the issue in your devs adopting to use the broadcast method to store information? It’s a win-win solution for all imo. Not a coder or an og, but been reading the conversation above, and shared what I think

realistically we could just reissue the same asset over and over. it makes no difference

there is no issue with this. we were told we had a week to do it (on approximately Friday) and then we were told to shutdown yesterday. that's what is not ok

we can make them 1 of 1 assets. 0 is not a requirement if that makes everyone happy

I mean you were told there was a problem and said you wanted to leave it on cause it was profitable to you

correct, lets take a week to build up some funds that can benefit us both and shift in a planned way was all that was requested

Or just pause to show good faith?

Then stampy came in and basically said fuck off well do what we want

shifting to broadcasts means 0 revenue, and doesn't benefit either party through any proposed xcp burn or otherwise. so why not take a week as discussed to implement broadcasts and we all can win.

Then he had to be calmed down by mr space

lol stampy doesn't represent the community

So I think you can see how tempers have flared

There you go

No one does

He's British... I think its cultural

We are just part of it

Neither do you

what the fuck are you contributing here?

Been in CP since 2014 and you?

good for you.

your smartass remarks aren't helping

As somebody who doesn't almost even represent himself but do love counterparty and do love what's been happening with STAMPS, I think we can agree in two basic point:
- we value what STAMPs have made
- we do not desire a fork scenario

So please, lets get back on rails

Agreed. And we do support an xcp burn for numerical assets

If stamps is willing to burn XCP, I say let them issue as many assets of whatever they want lol

I’d be happy to see the ability to create numerical assets go lol

Having said that, once the deploy could be very reasonably an issuance, what would be the need of the mint / transfer ?

Yes, this would be an ideal scenario. We are even open to retroactively burn

Numeric assets feel impersonal and weird lol. I minted 2 dozen numeric stamps only because I was told that named assets won’t show up in the stamps register

I mean I feel like this an ideal scenario for everyone.

Part of the reason why we don’t have development funds is because the price of XCP is so low.

It won’t be sustainable, you will be priced out eventually.

Correct it is not a requirement. We are open and looking at alternatives as market forces would require the reduction of fees with time anyway. Shifting to broadcast means no fees or very little for anyone most likely anyway.

We have offered this retroactive burn in the past and it was denied as far as I know - Mike knows better the details of that

Yes its been recommended a few times, I believe.

We agree current db usage is not optimal. And market forces will require a change from that technique anyway possibly very soon. Whether we force it or not. This will likely switch to broadcast. So why can’t we all benefit from the short term influx? If it makes things appear better we can make src 1 of 1, but I think 0 may even be better because they could be excluded from certain queries.

I think this is very fair and benefits everyone

why does broadcast=no fee?

if you get users to broadcast using a broadcast app same as geting them to mint using a minting app

The cost of broadcast is so much lower the actual $ value of the percentage is significantly lower, and users could just broadcast outside of the app. It also means no xcp burn. Perhaps in Freewallet which would mean an xcp donation in most cases anyway with the new version. It will come soon regardless due to the market. There is just not a big reason to force it abruptly.

broadcast uses same multisig encoding as issuance

I think even publicly announcing an xcp burn from stamps could be beneficial

Yeah exactly

so you get thesame utxoset data storage without the numerical asset creation it seems the numerical asset creation is the problem

When I looked the fees were substantially lower than issuance for some reason but that may have been the utxo variance in the wallets..but yeah this is our path forward regardless if we force it now or in a week, or when the market demands. I guess the big thing is no xcp burn for those

fees are bitcoin mempool issue not a cp thing

Broadcasts shouldn’t cost that much less it’s the same data in the multisig and keyburn can still be required. Same moat as assets.. except harder to broadcast on behalf of users (I think)

The problem was being forced to shut down on a whim realistically. Without being prepared to implement a change

Yeah assigning ownership to them at time of broadcast like we do with assets goes away.

That was the only real hurdle we have been debating on getting users to sign and broadcast.

you would need to include the from and to addresses in the json send tx if broadcasting memos on behalf of others

So I can do a from you? That doesn’t seem secure

I don’t see how we can turn down burning 10,000’s of XCP. It will help the community bigly I believe.

this why I won't use a minting app and consider ownership differently than you

Those are some of the technical challenges we needed time to process and figure out.

Hence why we didn’t want to kill the current revenue stream abruptly and kill any profit potential for both us and xcp

yeah it's not just switch to broadcast there are considerations for sure

IMO i think in short term resume minting service and apply xcp burn per minting numerical assets solves some problems and give money to pay devs for update xchain queries to dont show as normal cp assets the ones that has supply 0 and locked issuance

at same time it gaves time and money to Stampchain team to solve challenges they are facing and put more eyes at counterparty

Happy to do this burn immediately if we get consensus, and support on how to switch to broadcasts (when markets demand) that can be meaningful for both us and xcp. If it really means no price difference to the end user then what is the motivation to switch besides saving space in a database and simultaneously removing profit potential for xcp.

never forget that

Ideally we store the json in a compressed binary format if that doesn’t screw up parsing in the db. This substantially cuts costs

We are already doing this in some cases, just converting to base64 which is kind of backwards

They don’t

I believe burn is a good approach to get funds for counterparty in short term, organize hackathons for devs to work in counterparty, bug bountys, grants for teams to make projects, etc. always there is a pain, and IMO if the pain is to have to deal with a bigger DB but this do that devs can be payed to improve DB and queries to work better, why not do it?

This shows bad faith imo

It’s ridiculous that you don’t want to switch because the Tx costs more so you can charge users more

Inefficient to charge people more lol

well as i mentioned we are making the current trx smaller anyway with compression

if we can store in binary rather than base64 the size is cut by 1/4

Why would you do that if it results in making less money?

the challenge of switching to broadcast is we need to have users sign and broadcast the trx so we need a wallet or have them do a manual thing.

we are already doing the compression on bulk mints. it's about getting costs down and storing data in a more efficient manner

this isn't all about profits. its more aboout the challenges of getting users to sign and broadcast a trx from a website. they can barely figure out the current website

i dont mean that i mean that in the time that build the efficient way not more than a week has said @reinamora_137 dont stop the service completly as there are other people that still minting without it and use this XCP burn to improve counterparty and do more resilient, create and opensource explorer, or give funds to projects that are workiing on it at the moment and needs it, just use the attention cp is receiving and canalize it to improve cp itself

we could potentially always use the same asset# and just always reissue on that if numeric usage is a problem.

https://freewallet.io/uri-schemes.html

You can generate txs for ppl and throw them a tx to sign in freewallet…

Then pause and restart when it’s ready

That would be better for sure

I also gave ability to DEPLOY and transfer minted supply and ownership…. You can have your centralized service generate txs for them to sign that includes your fee…. And can mint and transfer to them in single tx…. You have all you need

ok to summarize my understandings of the options.

1. switch to broadcasts
- potentially difficult and cumbersome for users to sign trx
- good on CP db usage
- 0 xcp burn potential, possibly some mint service fees built into the trx
- use compression and store in binary if possible to cut costs
- perhaps swap to truncated strings that j-dog proposed

2. continue with current method and modify
- use compression and store in binary if possible to reduce db usage and cut costs.
- ensures xcp burn if we continue issuing new assets (open to 1:1 if better)
- or issue all mint assets on same asset if possible to minimize xcp burn costs
- perhaps swap to truncated msg strings that j-dog proposed

from a user perspective #2 is simpler (more cumbersome for our support and infrastructure). it also ensures xcp burn (not sure how this is or will be handled with re-issuances?)

#1 requires some retooling on our part, but not terribly painful, but likely removes us from providing a message anyway since a user could just input the json or string and broadcast from freewallet. - however this does include j-dogs donation fee in most cases so it's a win for CP

#2 is a win for us, a win for xcp depending on how we handle the asset issuance, and simpler for the users. Both would potentially be the same end user cost. fwiw we add a 20% trx fee on the minting service to get us off the ground and cover startup costs.

If you do issuances of the same asset over and over again that’s really not an issue at all because you’re just changing description, it doesn’t add to the assets table

But I don’t know if multiple issuances in the same block for the same asset would be valid, might need to check on that

https://github.com/CounterpartyXCP/counterparty-lib/pull/1237

Can you fix the insufficient funds error where wallets have more than enough funds that quickly please? Glad to see we got some dev resources behind things with all of this!

https://github.com/CounterpartyXCP/counterparty-lib/pull/1228

i have that one implemented and it still is a problem

Pull request to fix the issue with remaining change lower than dust has been out for a while... feel free to apply on your own node

have you seen success with it? I see it still pops up in freewallet as well

Ok, guess you should work with Javier to figure out what the issue is then.... cuz, not seeing any issues or complaints from anyone else running nodes.

Are you creating txs depending on unconfirmed utxos?

I have not TESTED this change yet, so I have not IMPLEMENTED it on xchain.io..... XCHAIN runs majority version of CP... so, I dont run experimental code on xchain.... I wait until it is put into a release

have lots to put into the next release, but last 2 months my focus has been on stamps and supporting that growing ecosystem... and last week has been figuring out how to stop this spamming and get us all on the same page, really on the same page, not just paying lip service.... I think we are finally at that point. You've stopped the minting service in good faith... it would be even BETTER if you could come out with a statement about how SRC-20 is abusive to CP and tell individual minters to stop minting src-20s on their own.... Understand that might be tough to do before you put out SRC-20.1 and the way forward... but, pausing service is good, but ppl stilll gonna mint src-20 until you come out publicly saying not to

it is certainly a persistent problem

``
"encoding": 'multisig',
"allow_unconfirmed_inputs": True,
"extended_tx_info": True,
"disable_utxo_locks": False,
```

maybe related to those additional flags.... if you can create an issue and a reproducible test case, we can figure it out..... but, gotta be able to hone in on the exact issue, which means a non-active wallet which has issue and no pending utxos... can't try to diagnose an issue with a bunch of pending txs

one address... mint one stamp... mint a second stamp... if there is issue, should present itself and be documented... full API requests, etc... everything to reproduce... then we can run the EXACT same api requests your running, verify the issue, and get it fixed

we need to put a release out in the next few days to fix the locked up mempool... so, if we can get this issue reproducible and fixed, we can prolly fit it into the release as well 🙂

why would we tell people to stop on their own? we are discussing the two options of 1 and 2 above. The broadcast technique doesn't really buy anybody anything, and perhaps we can solve the db problem with re-issuances or some other creative method of parsing data in a different way

i have over 100 wallets that reproduce the issue persistently. happy to send more details

Because you know that src-20 is abuse, and you know that there is a LINE that src-20 is approaching, at which point, a fork will happen.... WHERE that line is (the exact number) is yet to be seen.... but your at 10K... and issue will continue until you come out against it

Anyway... i'm done with the drama for the day... we have a PR to merge with 1 button click to stop this... I dont want to, but we are approaching that line... up to community to determine that line... I say at 15K assets, we pull the trigger.... but, that is just my opinion

I hope you guys make the right decision. We all can cooperate, but the spamming has to stop. full stop.

Please create a github issue with full details... I can get Javier on it first thing in the AM 🙂 https://github.com/CounterpartyXCP/counterparty-lib/issues

using a database how it was created is up for debate on abuse. we are talking about other storage techniques to optimize space. but i'll leave it at the two options above everyone can ponder what works best overall. #1 is not ideal for anyone besides your storage "problem". and perhaps #2 can be worked to solve that problem.

#2 only works for you, and allows you to continue to spam unusable numerics... Work on src-20.1.. publish it how you want... then you have path forward, and you can come out against src-20 and push ppl to the new responsible way to do things.

Not one person has stopped and asked “is building a token system on top of a token system in and of itself an attack?”

IMO it is not

It cannibalizes the existing system

doig counterparty on top of bitcoin is an attack?

if that is the consensus from CP as a whole then we know the direction to take with a fork. #2 also works for xcp and provides a burn mechanism as well. If nobody cares about that then it's an easy choice.

If you want to go down that path, I can put on my Luke Dash Jr hat... 😂

Sure but it’s an attack on bitcoin not Counterparty

If they are paying the XCP fee, what is the problem.

This is like saying you’re not using Bitcoin right

They aren’t lol

Not now, but they said they would

Looool

C’mon

seeing is believing

I mean they even offered to do a retro burn

which way is right?

the only thing wrong with #2 is how CP handles the data.

Create your own bitcoin indexer and do assets on that

that's not much different than a fork

Someone bought 10,000 XCP minutes ago…

Spent 2 Bitcoin

You’re missing the point, numerics will degrade Counterparty more and more as more people try to shake the money tree and create retard tokens for the plebs to get rich quick

hmmm... front-running the news? the responsible thing to do if you plan to do a giant burn? who is to say...

So next person comes along and you make them promise to burn xcp too?

But their burning XCP and they will get priced out eventually.

The funds it will bring will help the entire community.

Problem has been outlined before.. spamming numerics makes CP assets table grow... assets table is used in EVERY query on xchain... so, spamming continues, xchain slows down, balances in freewallet don't load... You can have your opinion on database and how they should be managed. I've been running xchain for 8+ years, scaled it up to 8 servers, and am WELL aware of the requirements and limitations.... You continue spamming src-20 numerics, your going to break XCHAIN and Freewallet will stop working.... Feel it is important that you undrestand we are not talking THEORETICAL scaling.... we are talking, this stuff stops now or Freewallet becomes unusable very fast..... If the CP community wants to support your src-20 fork and project, that is up to them.... as for me, I am advising we fork at 15K numerics...

Database changed
mysql> select count(*), sum(length(description)) from issuances where description like 'stamp:eyJwIjogInNyYy0yMC%';
+----------+--------------------------+
| count(*) | sum(length(description)) |
+----------+--------------------------+
| 10141 | 919956 |
+----------+--------------------------+
1 row in set (2.56 sec)

What?

This is another thing that makes no sense to me, how does reinmora making money on mints help anyone but him?

Guys it’s ok when I make money we all win

We just blew past 10K unusable numerics FYI.... you guys sus out the line here... tell me where it is... but I advise we fork at 15K... if src-20 is acknowledged as an attack, maybe can allow up to 20K to allow ppl to slow down and give some time to migrate..

None

and why not use the subasset system? this would work?

how does xcp burn help anyone but xcp bag holders? how is that relevant?

It doesn’t help anyone this is a stupid argument

Is anyone working on SRC-20.1 or are we spending all time in here just arguing?

ok, xcp burn doesn't help anyone. so why is it in place?

Anti spam

“Scarcity”

It helps the system

great, so us implementing xcp burn helps the system and CP as a whole. how is that all "me" ?

Is Reinamora against this? He said he’s happy to burn XCP. Why doesn’t this work?

You storing arbitrary data in assets helps no one, adding an xcp fee just makes it a bit more difficult and “fair” within the system

btw I am still in the stamp chat and saw they are still encouraging people to stamp away

And a 2nd layer asset system cannabilizes the underlying system that provides literally the same thing

where are they minting away? our src mint service has been down for a day

agreed, and it is appreciated... pls define path forward for src-20... so ppl can stop abusing CP... sooner the better please.

i stated two options above open for discussion for consensus. i really have nothing more to add

I think either is better than neither

Just changing a single asset description over and over again seems fine to me

But it’s still dumb

and subasset?

And better suited for broadcast

What subasset?

agreed on a technical level the broadcast is best and i'm sure we will transition there (maybe build our own wallet), but the user experience in the short term is bad, and doesn't benefit anyone

i readed there is a way to create numerical assets that are subassets itself? plese correct me

is this possible?

are all that subasset added on every query of assets itself? @jdogresorg

Yes but why

if the subassets are only queryied in the subassets query there is no pain for all the rest of queries

Wait how does a user transfer an src-20 now? With freewallet?

it's certainly possible when j-dog adds the keyburn. i'm sure people have been doing it

They pay you again to transfer?

fwiw I only show 5517 valid src-20 trx

it's another transaction. they are paying the miners. they are also paying j-dog to use freewallet so what's the difference

How are they doing the transaction?

Sending it to you to do for them?

correct, we issue on their behalf and assign the asset to them to show ownership. which is the complication of doing broadcast in the short term.

Looool this is the most ridiculous shit I’ve heard in a while

perhaps we just fork freewallet and add in our fees as the donation address and setup broadbast. problem solved. it's really no different.

Mike what did you do

degen shit man. Better believe it!

Let me send money to someone to send my money to someone

serving a demand lol

Jesus

see it sounds stupid when you say it. But the market seems to like the approach

The market thinks they’re gonna get rich quick

The market likes the stupidest shit possible

My query directly queries the asset description for base64 encoded {"p": "src-20 .... so, regardless of if your consider a deploy/mint/transfer valid, it still exist in CP system and adds bloat to the database, and is a part of the problem.

You’re just selling them shit on a stick and telling them to pay you whenever they want to do anything with it

there are people aping into src-20 who have never heard of stamps. They're literally like "what's that?"

And you guys have been complaining about things being not being “decentralized “

Looooool

I’m dying over here

This is peak retard

Yeah... except you also need to fork xchain.io since freewallet runs ENTIRELY on the xchain APIs... and xchain is closed source

so yeah.. your welcome to fork freewallet, but you'd have to point it at your own explorer and APIs

Back to counterwallet

this is what I am trying to avoid... keeping FreeWallet and xchain usable for everyone

people said that about amazon's business model for 20 years before they made their first profitable quarter

Where stamps began because I made the mistake of seeing if I could put base64 image data in an asset description

Oh yeah this is just like Amazon

Call you Mike bezos

It’s not the model that’s the problem, it’s the haphazard approach to push it out and now the repercussions have to be handled and supported forever

They won’t support forever

Money dries up and everyone moves on

Rinse and repeat

You simplified it for me! I was gonna originally make them broadcasts! Time is a flat circle

Those assets will need to exist forever

Only if enough people believe in them Shannon

If you lost the src spirit then stampa Claus won’t bring you presents next year

Ordinals and brc20 are paying for their sins too already.

The music will stop

Stealing Stampa Claus for Christmas time promotion

Probably soon

I would have thought the music would have stopped already! Guess what: we've taken calls with Ordinals Wallet, Hiro, Xverse, Gamma and Sovyrn earlier this very evening. We'll see what happens...

It’s been like 4 months since ordinals was invented lol

And what were all those companies doing before ordinals?

Bsv or stacks

So they don’t want the music to stop!

They’ll grasp at anything to keep it going

Of course they want to do stamps

Cool! I don't mind if stamps is that thing

I’m sure they want to do that random thing jdog just introduced

If he wants he can probly take all the same calls

im sure he can

Think up a snazzy name

Cuz this centralized minting is only approach presented… that changed today.

Yea I don’t get it either, surely we could come up with a way instead of making an entire new name system

Just need to do the Ben.eth thing but without the token

Nope… not wanting that… you take the calls Joe…. I’m a coder not strategist/marketer

Sure mint full supply and put in dispenser

Dispenser to a burn address

Same exact effect

Sure its not much to look at and the implementation is very basic... but WE did this. When was the last time Counterparty got integrated into a 3rd party wallet? I consider this a big win.

A watch only wallet

for now...

This was the exact approach they took with ordinals

First you enable recieve cuz that's easy

Then you build send functionality

is it ideal? No.

Science is messy

😵‍💫 Wow that’s something

rofl

uh, yeah…. as i’m catching up here I’ve noticed multiple small tweaks that could be discussed and implemented pretty much missed opportunity or glossed over.

pardon my lack of constructive comments for now but this entire week or so of CP chaos i’ve mostly ignored.

!!

fuck it, deleted my text to not offend and stir shit up again. but i just don’t think any of this is healthy or logical for CP or even requires CP.

My 2 cents.

I support adding an xcp fee to numeric assets. I've called for this in years. In 2015 i was guilty of "spamming". I issued thousands of numeric assets, was asked to stop, and i did stop of course. But i knew it was a matter of time before someone would do it again.

I'm worried that 0.25 xcp is too much tho. At least we should communicate that a fee adjustment (fork) will take place in the future if/when the xcp price is higher.

The ease of forking counterparty is what concerns me the most. I'd love to see more projects run their own nodes. If you run a node, you have pretty good veto power on changes. Juan's xcp.dev is running its own node, so we do risk losing our 2nd explorer if he doesn't agree with the fork. Do other projects run their own node? This btw is criticism of everyone (myself included) except Jdog and the few others who run a node.

In the long run, the creation of numeric assets requires the burning of xcp, and the specific amount of burning is a topic that really needs to be discussed.

In 2014, our counterparty community burned 2100 BTC to create XCP.

We have no reason not to add value to xcp.

How many nodes are there? Are there public stats somewhere? And node software, are there more than one implementation?

Impossible to know how many nodes there are. Doesn't really matter either. A node only interprets.
What matters is running infrastructure that people use. Gives you some veto power over code changes.

I've been a Counterparty user since 2014 and I agree with JP. Adding the fee for numeric assets is the way to go. It also helps to prove that XCP was indeed a counter-spam measure this whole time and not a get-rich-very-slowly scheme.

I'm for the fee being as high as 0.25 XCP because that's what it is to issue subassets.

if fee for numerics, why have numerics except to support subassets?

numerics existed before subassets were a thing

I know, but at this point… if not free… what is the point besides for deploying subassets? Why not encourage users to create a subasset under their own “namespace”?

afaik numerics were added to BE free

Is there diversity within the nodes? Or only 1 implementation?

only 1 .. the fednode implementation

At least a consideration would be to remove support for numerics moving forward except for the subasset scheme.

Seems recent CP usage patterns and decisions around them are $$ based not logic based.

I think its a shame the letter A was chosen to be used for free assets and excluded from bei g 1st char of named assets... Z would have been better

or Y or Q ..a letter that is not frequently used to start words would have been a good choice .. why was it A that was chosen?

numerics are ugly in wallet .. testnrt exists to allow people to play for free

A had some reason to it that i can’t recall

you can even get tXCP by burning tBTC so testnet is ideal playground sandbox

it's before my time .. I am class of 2016

💯 testnet

it might have been an encoding efficiency but too long ago to rem

that would make sense as to why a vowel was taken

Should I write a CIP for Keyburn?

Mike chose A assets specifically for the narrative that only Bitcoin is needed

keyburn its now being used and is a standards thing like jdogs new token system using broadcasts ... its not a code change its just documenting CPAPI use

now broadcasts can be the btc only playground

we talked about this on the forums few months back

proof of burn is a consensus mechanism in decentralised networks

X would have been the best choice

So many brands and major words start with A.

Funny, that was my first complaint when I joined Counterparty Slack in 2016 :)

I still think the idea of creating an entire new namespace using broadcasts is stupid. I don’t understand the reasoning.

so kill Anumerics and support A names maybe

yeah no A was shooting itself in the foot when it comes to namespace

agree

time to ask WHY

I believe a bug is the reason assets cannot begin with A. Numeric assets were added much later.
I will explain in detail in the forums. A CIP in the pipeline for adding A to named asset.

I vaguely recollect there was a byte size issue minimised with using A compared to others at the time … when OP_RETURN was only 40 chars?

I’m guessing Jdog felt the need so the spam would stop

something like that

I saved the technical response from Slack at the time, somewhere in a text file in my Dropbox no doubt

yeah I get it… but still… why? getting weird.

fungies

I look forward to seeing keyburn as a option in freewallet, its nice if everyone has access to the options cp api allows

we def gonna see CP forks now

The problem with jdog’s system is that’s it’s too transparently a fungible token system on top of a fungible token system. You need to obfuscate the CP layer for people to buy into the meme

this is true

for the degen use case

I plan to add it…. Just waiting to see how this all plays out n if we are forced to disable numerics or not.

so should there be a CIP?

Freewallet is personal product so nope, no CIP

its not freewallet thing tho .. its cpapi

could still be obfuscated via simple web wallet

lose your rev stream though kinda

same as how broadcast token minting is possible by freewallet but can also be done with cpapi

charge for signing lol

What’s the point of getting rid of numerics if they pay the fee.

Why force someone to use letters

it’s basically paywall or use CP as normally would

if how to structure a json description is a cip then I would have thought how to perform a key burnt asset creation should be too

mysql> select count(*), sum(length(description)) from issuances where description like 'stamp:eyJwIjogInNyYy0yMC%';
+----------+--------------------------+
| count(*) | sum(length(description)) |
+----------+--------------------------+
| 11157 | 1011512 |
+----------+--------------------------+
1 row in set (0.34 sec)

I know its not possible to list all burn keys but if we all use the same burn keys it makes development easier

Morning update... just blew past 11K.... We need to know where the line is in the sand is... COMMUNITY here needs to decide... if community does not decide on a number to disable, 15K is the number...

Please use the next few hours to determine the line in the sand which shall not be crossed... we will reach 15K in 1 day at this rate

this is a problem that needs dealing with NOW.... yes src-20 minting service is paused... but ppl still minting src-20 and STAMPS project has still not indicated to stop stamping

AFK for a few hours to write the BTNS indexer...

@sulleleven @shannoncode @hodlencoinfield Where are your PERSONAL lines in the sand? we need a number... enough conversations, the issue has been made clear... we need a clear line in the sand or this will continue, it is clear.

If we do not have a solid number in 2 hours, I will be FORCED to put a public message on xchain.io calling src-20 an attack.... this is a personal decision, I have done everything I can to avoid coming out AGAINST src-20... but we are at that point... Please sus out the line which shall not be crossed on numerics.

When I read up on what’s going on here last night, I thought the 1500ish in queue was OK’d.

so 15K is your number?

1500 in queue... was about 3000 src-20 assets ago

Javier made the cip that makes A assets pay XCP a fee. The stamp devs said paying a fee is not a problem, what am I missing? How else does this affect them with the CIP? Do all assets become invalid or somthing?

that probly doesnt need a CIP but the coutnerparty API documentation itself could mention it and could probly use an all around update

@XCERXCP If we disable numerics, it kills of "Bitcoin Stamps" ability to mint numerics without an XCP fee... I want to avoid that, but yes, numerics are an attack surface we HAVE to deal with ... just do we HAVE to DEAL with it now, or can we give src-2* ppl a chance to migrate.... if they stop spamming src-20, and encourage community to do so as well, the need to fork stops, and we can kick the fee on numerics can down the road.... but yes, longer-term, numerics are an attack vector and need a fee added

Would this fee affect also art Stamps?

all "stamps" have been based on numerics cuz of "no need for XCP shitcoin"... adding fee on numerics means that in order for Bitcoin Stamps to conintue, they would need to start using XCP to register numerics (at which point, why not just use a NAMED asset)...

Why do numerics need to be disabled and just add the XCP fee for numerics

numerics will not be disabled, just a XCP fee added to bring them in line with subassets (which are just numerics with text lipstick on them)

Who cares than, they agreed to that

numerics are here to stay, issue is will the stay "XCP FREE" to ise

They said they are happy to pay the fee

@jdogresorg if you want my personal opinion, i’m not a supporter of these new token layers. but aside from that, idk what the diff is between 11k 15k or 20k besides db bloat that could have been circumvented but is what it is now. I’m of the mindset to not publically accuse attack etc and let things fall into place behind the scenes here.

I know it’s mainly your servers taking the hit so maybe some compensation is in order too.

Lastly, there are database scheme changes that could be done to offload these unwanted entries into their own table so you don’t have to query all of them for every nec query on xchain.

there are other ways around the "Need XCP Shitcoin" argument.... can build into issuance ability to automatically BUY any necessary BTC during the issuance.... same functionality then... spend BTC, get an asset registered... no need for XCP (tho we buy it and destroy it for you automatically)

anyway... there are options to move forward without the need for users to buy/obtain XCP

while i get the argument for eliminating numerics entirely, i think it would just add a lot of confusion, its much easier to just say "an anti-spam XCP fee has been added to numerics"

Not a compensation issue... a maintneance issue... $50K in my pocket doesn't help speed xchain up... doesn't help keep freewallet running

it is not about $$$ it is about stopping abuse so CP can continue operating... .call me alarmist if you want, but I'm saying, if this continues, xchain becomes slower..... if ppl cant experiment on CP, why I am I here?

the thing is this isnt going to stop anyone especially the current stamping service

fair enough, the idea is out there, I proved it works and it is being used

so at this point are numerics only relevant because Bitcoin Stamps? If a decision to charge XCP fee for them, Insee no purpose to keep them except as subasset func.

since they issue on behalf of people they can just load up on XCP and keep doing what they're doing

This is better in a marketing pov...

It seems everyone agrees this isn’t an ideal for CP and is basically an attack. It needs to be fixed anyways eventually because it will be done again.

and for the record, I agree... all this new token madness is insanity.... ppl should just build on what already exists.... but more $$$ to be made by rolling out new features and pumping them.... so yeah, I agree, this is a silly shitshow... but, if it is going to happen anyway, need to have it happen in a "responsible / scablable" way 🙂

Eventually they will be priced out