Transaction API endpoint updated with valid param
https://i.gyazo.com/d628e3e0898dfe285cb6a99705453798.png

https://xchain.io/api/tx/1cad7e7db1e29be1dc4ef1e80550283cf5ce6afb741aa94d9f0e378088ae8355

I know many of you may not agree with the recent actions or directions I am taking things, which is fine... This is stressfull for everyone involved.

However, I want to do everything I can during this strange time to make sure that loss of funds are prevented. To that end I have made the following changes to XChain:

- Updated transaction API endpoint to check if tx is valid on both 9.61.1 and 9.62.0

- Updated transaction API endpoint to pass new 'valid' param to track if tx is on both ledgers or just one

- Updated all transaction pages with a message to not trust the displayed data, to verify with other explorers, and provided easy links to click to memepool.wtf and xcp.dev

- Updated all transaction pages to indicate if tx is seen on both ledgers, notify of status, and turn alert box red/scary if tx is not on both ledgers.

Transaction pages with header that indicates if tx is on both ledgers
https://i.gyazo.com/50c2c4121b52d20f6a5faf69a1d2ae4e.png

https://xchain.io/tx/1cad7e7db1e29be1dc4ef1e80550283cf5ce6afb741aa94d9f0e378088ae8355

Transaction API endpoint updated with valid param
https://i.gyazo.com/d628e3e0898dfe285cb6a99705453798.png

https://xchain.io/api/tx/1cad7e7db1e29be1dc4ef1e80550283cf5ce6afb741aa94d9f0e378088ae8355

I need to take a sanity break and step away from the computer / drama for a bit... but couldn't do it until these updates were made.

If you find txs which are valid on one ledger and not on another, and xchain is indicating that the tx is valid on both ledgers, please reach out and let me know... I want to make sure that I do my best to highlight any ledger differences and keep people as safe as I can during this fork.

sending all as i know some members are not in the other chat

false, CP devs / community have the following options :

- Merge my 9.62.0 release with my activation block.

- Merge my 9.62.0 release with a DIFFERENT activation block (no more than 1 month out)

- Put out their own 9.62.0 release with a fee on numerics

- Do nothing, let the ledgers continue to diverge, and blame J-Dog for everything

Yes, this situation we are in is shitty, but i'm not backing down, and wont run any version of counterparty-lib on XChain that does not include an XCP fee on numerics...

I dont feel Counterparty should allow spamming of 10K PFP collections unfairly (everyone else pays an xcp but numerics), and I am tired of endless talking in circles while scambling to keep everything running.... end result is nothing moves forward.

I will say it is interesting to see people who previously said they were in favor of an XCP fee, now change course entirely... but hey, ppl entitled to their own opinions... just wish ppl could be real and not say one thing privately and another thing publicly... but i digress

The next move is on the Counterparty devs and community to move CP forward.... I've done all I am willing to do at this point.

Not sure about this, @krostue ?

“Yes, this situation we are in is shitty, but i'm not backing down, and wont run any version of counterparty-lib on XChain that does not include an XCP fee on numerics... “

@ChiefSamyaza 100% caused by you

You are in a nasty power trip. And forgetting that Counterparty is a decentralized protocol.

You are proving all my criticisms right.

I was hoping you would field this. I don't want to rule out possible new good faith participants with the false comfort of a firewall going up now. These are discussions open to stay on topic somewhat related to our current endeavor, as a host I will do my best to point off topic conversations elsewhere.
That being said, now that this room is in emergency repair mode we should reserve the right to close the doors if there is a raid or more basic drama.

Whatever is chosen, we will be professional about it

Fair

Tbh I spoke with him briefly. I don’t think all is lost, and any hostility at this point will not improve things. At the worst case it pushes many people, emblem, etc to run their own nodes. I do trust that he does have good intentions for CP overall even if it was an impulsive and overly stubborn approach.

I think a lightweight cp node (perhaps with quick node for btc and a modified or external addrindexrs) would make adoption easy on low performance hardware.

Even nodes talking to each other to verify hashes is something we are working on for stamps.

His approach was the main problem

But yeah. Professionalism is key at this point I agree. I’m certainly to blame for much trolling surrounded by a room full of professional ones lol

Deffo. Short sighted, impulsive. Whateva we crack on. His point was that CP would emerge stronger and it certainly appears that way with the caliber of peeps motivated in this room

I don’t want to loose the momentum to drama, fud and emotions.

You me and Juan have been sitting in this chat here for a year waiting for the flood of others.

Be diligent with new members. Consider screening new people or a bot maybe? Not a priority, just a thought.

Well yes in a way there is some positive to this, but if his attitude is to not back down at any cost, then whatever we do here won’t matter

There will be 2 ledgers. Horrible. What is Counterparty then? Then 3 ledgers?

No fud sir. We ban for that.

I’m serous

Perfect typo lol

This is the direction.

lets add a explorer app to the repo, remove the sqlite db add mysql and xchain is not needed anymore

If his demands aren’t met, and xcp.dev can meet the users needs, long term this likely means xchain slowly fades in relevance and eventually becomes Bitcoin cash.

I think he is doing a very good job of trashing the reputation he spent years building

I’m just saying, me personally, won’t buy his “good faith” arguments

Maybe he just doesn’t get it

Plus a wallet.

To close to see the forest or compromised.

Perhaps a js library that can create psbts that can be signed by any wallet

I love this chat.

Real dev here.

We need to leverage modern infrastructure

Devs

This is my hope, but this means we are clear he is not actually on the same boat as us

prioritization and delegation time it seems

I’m calling it a slow motion rage quit

After I get the src20 stamps indexer task Im doing right now done, I can shift to help with the api

Stamp website admins should get ahead of this for the user and implement big warning messages, pausing tx’s, removing all reliance and links to xchain and counterparty.io api.

At least we won't have unrealistic expectations

we know what to expect

this group goes back to 2022

At emblem I’m going to incorporate multiple endpoints and filter out conflicting balances. It’s how I handle the brc20 conflicts always present

if you guys could share the xchain balances api endpoint once someone gets one up i would be grateful

how will you determine which balance is correct?

If conflicted. Neither is correct

Great point!

Till we have consensus that is, or officially have 2 chains

I was the 4th member.

yeah this all been a long time in the making

A few of us have seen this train coming for a while.

I believe conservative consensus is the truth. Is what protects us from what is just happening

yeah, most users are using openstamp, stampscan, leather, okx wallets outside of dispensers. But yeah, just need to figure out the correct wording to minimize fud.

There are no 2 chains in Counterparty. This is different, not a typical crypto fork

Fortunately most traffic/commerce these days is 99% src20

how this ends up playing out will set an important precedent for all indexers

its a ledger fork as there is one chain - btc

Including a redirect or link to documentation, clarification, history and education might be in order.

I’m suggesting that if a large enough group decided to go against the consensus version they could make a protocol fork

Besides dex trades for numerics, the fastest and most voluminous place where divergence will start is with XCP and numeric issuance, especially with stamps driving volume there.

XCP version w/ fee:
- Issuances w/o fee are invalid
- Issuance w/ fee consumes XCP

XCP version w/o fee:
- Issuances w/ fee doesn’t consume XCP, may not interpret the issuance if format changes slightly

And then you start to get divergence in terms of assets issued and who has what XCP balance.

Aka, not upgrading

As soon as someone notices, there will be intentional attack registration of numerics on both that will conflict, exacerbating the issue

I don’t think anyone would have to notice it’s just what will happen as stamps stamp on.

Anyway, I don’t mean to add noise to the conversation.

If a stamp is a numbered asset, isn’t there already an index provided by counterparty? Why the need for another?

And then conflicting registrations, like if both issues A123 and A123

every numeric minted post fork on address with no xcp results in another divergance

This is a 2layer conflict, and gets so much more complex from here

I’ll just conclude that, I believe, that one of the consensus principles should be to NEVER be acceptable to force a fork unilaterally

Not probably like relevant to right now, but there may be space for a signaling bit in the op return that could be used in the future to indicate over a period of time support for X or Y thing.

But it would mean wallets decided probably more than anything, so scratch that.

☝️

From the founder

I ask dumb questions on purpose if anyone ever wants to answer and have a conversation.

Stamp in numeric asset but not all numeric assets are stamps

@hodlencoinfield Did I hear once that you can make dns changes to some official domains?

Because we don’t recognize reissuances which make them immutable and we number them to align with the ordinals meme

And negative numbers for named assets

Sounds like an explorer problem, similar to jdogs world.

Again, sounds like an explorer problem. Respectfully.

Yes this is why we build the stamps indexer that uses counterparty node apis as a source to filter the ones that actually are stamps and be able to show on stamp explorers without affecting all explorers

And trust in counterparty API for balances so if a old asset is reissued as stamp the old distribution is taken in account

Right

We are aligned with counterparty and we did this way to support all upgrades of counterparty protocol

Without have to update the codebase with each update unless it affects the API module

Codebase of what?

Codebase of the stamps indexer itself

The original idea was to make them all 0 issuances and trade via ownership transfer but the duplication of the description field was a showstopper on costs. Partly why that was changed recently. So we needed a way to trade them cheaply and dispensers were easiest at the time

Misuse of the protocol? Respectfully

And that was kind of frowned upon anyway as we saw with the backlash on src later

But jdog was in those conversations

That was not brought up though since it was a valid transaction. It was only a problem with loads or them. Understandably with the current design of the db and trx handling

Without open-sourcing this indexer what do you have? Relying on counterparty makes this a what, half-fork as-in half-sibling?

A cousin that interoperates with cp perhaps

Why?

for the immutability and because the assets are really just an imaginary fraction of the one stamp immutable trx

The ledger hash is the most important one to keep in sync. In my opinion.

So, 0 locked issuances can exist and have no effect on the ledger calculation.

With DB optimizations, I don’t see why 0 locked are a problem. As said, the issuance transfer can still be useful

plus the amount of CP users at the beginning that were familiar with CP usage it was an easy implementation to allow the full asset support and features that CP gives

I believe leather is very close to releasing stamp management within the wallet. Do we have a contact there to inform them of the current state?

yeah we have a chat. they are using the stampchain api, but i haven't heard how they propose to handle trading of them...

So I understand correctly, this response is stamps only not src?

My guess as to why is because the tx type made sense. I’m not blaming stamps or stamp devs.

This is what I mean when I say counterparty could benefit if all aspects of the recent advancements were rolled into one.

src was completely removed outside of CP because of the contention it caused.

Will be opensourced at the time but as we are still validating balance data in the Src20 part it is not prepared to be public released anyway If anyone wants to be on the codebase before the public release is welcome

correct, unfortunately the contention with CP pushed us into deving even more on SRC and took a lot of cycles away that we had planned to push back into CP. We're certainly circling back on that now ofc.

Correction, contention with xchain

and yeah, src-20 is essentially a fork of CP codebase looking at stamp: anyway without all the complexities of the dex/sends/etc.

and the then maintainer ofc. which circles back to the db issues

which was my #1 priority in building on the fork to get it all into mysql directly

probably should be using maria with the oracle license model but details

Still CNTRPRTY prefix?

STAMP for src20

Reminds me of a dev I know who names everything TEST.

for what i call classic (image) stamps still CNTRPRTY so we continue the full set of asset features within CP and support the community that likes to trade for other assets with them, etc.

and then there is SRC-721 which is a one issuance asset to avoid the issues with 0

and that's what flipped j-dog out the last day with 10k of them.

within 30 mins

Omg didn’t know about this. Yeah this is different, 0 issuances are way better in terms of possibilities of optimization

yeah i don't really like the 1 issuance, but it is possible to move src-721 out to the src-20 standard (non-cp).

src721 are counterparty numeric assets that has all the features of CP

derp was kind of developing that at the time while my head was buried in the src-20 indexing so we never really synced up on the long term plans for that and we still wanted them to be part of the 'stamps' brand if you will.

Was going to say that these can be even more cool if they are named assets because of the sub assets. There can be some cool creative use cases for 0 locked

yeah definitely a possibility

initially with src we had talked about doing them as subassets because it think the proposed xcp fee was less anyway.

this is another possibility for sure, as all layers could be down the same superasset

same as all thedifferent issuances

is a thing to explore for sure

Forwarded upon request

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

same issue again. due to contention and possible trx volum it was a non-starter.

The protocol has provisions for qty already.

People keep discovering similar things in similar ways and similar directions but not exactly the same.

Consider how 721 nests transactions, now add inception and go meta by nesting stamps and 721 via multisig.

yeah lots of inception tricks. we can even reference images over on src-20, and the planned future version for atomic/psbt swapping on src-20 called glyphs.

I have an old idea where asset ownership could be traded or put on dispensers here: https://forums.counterparty.io/t/cip-proposal-decentralized-asset-sales/4165

the atomic psbt swaps is a thing that if we implement in cp core will rocket counterparty

Relevant to 0 issuance assets.

What exact tx type is classic stamp and a 721? Same?

and is something we can test on src-20 or collaborate on to make it a reality for both. which then can go cross chain, etc.

yes

bare multisig, same

same as src-20 really

i even used arc4 encoding just as a nod to CP

they are also full usable in counterparty

Can you two elaborate your angle?

are counterparty assets at all efects just the image is broken in explorer as they doesnt know how to stack the layers to create the final image

jdog did not like the idea of asset ownership transfers on 0 issuance locked even tho its in protocol consensus

this is kind of cool... however with the design currently we assumed ownership transfer would never be a reality due to costs. so we key off the issuer field as the artist/creator. there is not really an owner of the stamp since we rely on the owner of the asset level.

there is even a rarepepe with 0 on which ownership is traded - but it paid the xcp registration fee so is exonerated

so the asset controls the owner and an ownership transfer does not move on stamps because that's immutable

This is why I ask dumb questions, for the rest of the class. Thanks for engaging.

we do have stamps which changed owner, but that is not recognized anywhere and really has no impact

why are numerics not for general public? testnet exists to get familur if you want to play / learn

good to get all these decisions clear with the group. i know many have not participated in them with the exception of Bob 🙂

I don’t follow these other things but you can just look at the first issuance and ignore the others if you only care who created it.

correct that's how it's handled.

yeah you free to interpret the data as you wish in your project

all these protocol rules for stamps makes some things a little tricky as things change on CP but we can certainly adjust if needed.

such as recently adding full support for named assset stamps which was always a plan. and one jdog even yesterday said he was onboard with on his tokenstamp.io website

Tell me more.

otherwise yeah i agree this is a great idea 🙂

dispensers for ownership should be a thing - but beware rugspensers

What each dev/explorer/collection/src/20/721/btns etc are disagreeing over is tx type and field usage. What field determines the owner, qty, name etc.

Each hammers the protocol as they wish.

This makes sense to me for 721.

actually anyone can do this way they should be supported by the indexer as all assets with stamp: base64 description are supported

but anyone has done it yet afaik

we can educate people to do it this way

only problem i see with this is that just the owner of the superasset can issue subassets so is just a thing that mint services can implement

Trx?

transactions volume

Could be considered a feature, makes it easy for whitelisting and managing a drop

Devs and explorers using different implementations of the fields and protocol.

Not a flaw, an effect.

yeah i would fully support this overall. we just may rethink how we handle that for stamps because it does have value.

honestly the design decisions would have been different had that been in place and we probably would have launched with 0 asset issuances lol

Need a creator field? We need to stop misusing fields.

issuer is what we call creator.

and ignore owner

But that should not dictate protocol by either party, until it does.

if your making valid cp txs your making valid cp txs thats ok

hence why we would have to be flexible in those CP changes ofc

The first issuance is the creator, it makes sense if you’ve indexed the data before. You have an issuer and a current owner. And one is the first issuance and one is the latest issuance.

some ppl like to id each naka as a unique asset - some think there are 298 of the same asset .. its personal prefernce at the end of the day

yep, not a big deal to add a new column and index for owner. it kind of conflicts with the owner of all the assets for that issuance however

100 assets all owned by 100 people. then the artist sells the actual issuance to someone else.. who could change the description (wouldn't impact stamps really, but it would be odd on CP explorers) kind of a rug.

at the protcol level there are 298 of the one asset - but on chain they differ - you may wish to follow each one individually or not the protocol should not care

partly why Jdog always displayed incorrect stamp images on xchain lol

rn we only see the 100 owners, but there would be a 'super owner' of the issuance in that case. why we ignore it

makes a lot more sense for 0 issuance stuff for sure

Does the issuer field not function as expected?

Why? Is all of this necessary to keep stamping services relevant or something? This infrastructure was already coded out.

not sure what you mean. it's just a perception thing as an artist. Hey fam, i have 100 of these assets, buy them!... then later to go around and sell the core issuance / super-asset if you will to someone who could have the potential ability to change it (on the CP side, not stamps side however since we only look at the first valid issuance).

Sounds like UI or explorer concerns.

part of the problem why xchain was sort a problem as an explorer (or by that standard any CP explorer that handles stamps in the traditional CP way) - images can and do change... but not on stamps explorers

that's really our problem and ofc shouldn't impede CP explorers in any way

Yes

Now is there an unwind bot?

which also makes it better if CP does not show the images on stamped assets

So make it not impede?

i just mean, our decisions on that matter should have no impact on CP explorers. It's just describing how it's actually sort of better in some cases that CP explorers do not render stamp images...

a fine line, but was a slight frustration on xchain displaying wrong images for the stamps protocol. They were kind of half-way supported on xchain.

I just mean that you have pull over stamps. We’re in this chat for counterparty first. Were here for stamps too, as relates to counterparty.

i digress. the point is really none of that matters for building an open source explorer for CP

The tail should not wag the dog.

i mean if we're involved it would be cool to eventually integrate proper stamp protocol handling into CP ofc 🙂 but nothing i would even consider mentioning at this point lol.

then we could get rid of the secondary stamp indexer. Which he had considered... just forking CP and building in stamp support properly.

wasn't feasible time wise with SRC-20 though and the differences of managing future upgrades in CP to stay in consensus were deemed to be a nightmare

Or should stamps use proper counterparty protocol? 🤔

what is proper?

stamps on counterparty is cool .. sure it can be done without it but Counterparty is the base layer with the history

the meme is immutable / permanence

CP protocol allows changes to a permanent record.

What support? List a few missing features please?

yeah the history of many of the artists on stamps with CP it just made to much sense

changes or appendages its Interpretation

mainly how images are handled. we need to only render images from the first valid issuance of any asset.

I understand, thats partially why I paused my project.

however the attributes that do increase/decrease/lock/burn we do recognize

otherwise everything else is the same

Base64 on counterparty is cooler.

There was a cip discussion for using p2sh to encode data more efficiently and another to store data with a file prefix in the description. I think long term those ideas should be on the table

Unless locked?

We just saw max stamps per block limited by sigops. Ithe p2sh rather than bare multisig encoding can with that

yeah I hoping cornholio doesn't spend his pre stamps base64 asset

this is what i thought but description is changeable in locked assets i think just the supply issuance is locked

locked only means the assets can't change but the description can or vice-versa. correct me on that

ah yeah the description can change. which doesn't really make sense to me if it's locked

So back to ignoring the issuer field of counterparty protocol?

we only use the issuer field

just not the owner

since owner changes as well as the description. so the only thing that is different from core CP protocol is really that.

This is what I mean when I say roll all the recent advances together into counterparty.

Do that and the fork war takes care of itself.

no description changes, and no issuer changes (aka artist/creator)

i think it means we have to do some of those upgrades faster than j-dog. including taproot support.

my suspicion anywa, at least if the community really values those changes

we can always include all this changes in counterparty from his fork

At least he is keeping it open source lol

Maybe the counterparty protocol could change regarding desc lock and then stamps could then fall inline with proper counterparty protocol usage?

if he didnt to that the fork war solves itself too

I bet you could strip down the counterparty-lib a lot and get a stampchain-lib that includes stamps to date and gets you whatever you want extra.

then we should be updating codebase all the time a new update happends in the protocol, was studied but have the indexer relaying in counterparty apis has much more sense in this aspect

that's basically what we did for src-20... however we stripped all the cp stuff mostly due to the rushed nature of the forced removal of src-20 from CP so we could keep everything in consensus for all stamps.

On top of counterparty but ignoring owner and index?

owner and description changes is all

what is the problem of this ser?

i dont understand your point with it

i think he's just fishing for all the details without bias 🙂

maybe is my english lack sorry for that

Change the behavior of lock or add a new lock for description and/or owner?

true true

like a freeze

run your own nodes and you have a real protocol, but again were here about counterparty and a counterparty collection.

the only thing that's not included in that is the stamp numering aspect. which now includes src-20. so that's a pita.

yes ser the apis we are replying and the explorer doesnt matter if the asset is a rarepepe a stamp or just a name without art

This is what will be required of stamp devs if you want to keep claiming that you created a protocol.

but yeah the goal was to stay in CP consensus without having to maintain a full fork with our changes.

well we still have to update our indexer and our protocol for src-20 which is direct to btc

And the index in favor of your own.

so then we have two things to manage.

No real point. Seeking truth and making sure the other people in that chat are crystal clear.

Keep the constructive conversation coming.

the complications came about with having to build src-20 outside of CP. which is fine and done, but it makes all of these suggestions dramatically more difficult. I suppose we could merge src-20 back in to CP, given db changes and trx handling changes, and then run our in consensus fork... and work on psbt, etc etc together.

maybe a protocol is not the correct naming, could be better a standard set of rules to create counterparty assets considered as stamps

this was our original plan anyway, but dev contribution was stopped on CP and shifted completely to sustain the user adoption we saw. again no contention there, it's done. just a perspective

hypothetically merge back in, but i really don't think that's possible anyway with all the adoption in wallets and upcoming CEX's.

Back at it again with that FUD.

Jk

I will say it is VERY evident that none of this would have existed without counterparty. So our goals have been to try as hard as possible to stay aligned to support CP, and not just run off into the distance since i believe there is lots of opportunity to grow and dev together.

Even j-dog mentioned as such yesterday

hahah best intentions at the onset clouded with emotions, frustrations, etc on many levels.

which makes it super refreshing for all of this to be heard without the trolling and downward spiral that gets into. appreciate it.

Is this stamps function this way partially due to transaction types having different costs or similar technical aspects?

Bump

what's definition of spam ?

I thought it was understood to be a state of mind

Who’s dictionary are we using?

always happy to add or change encoding techniques as long as it immutable. And ideally stick with the utxo meme. Ideally something cheaper to increase volume.

Spam is a state of mind

could use 3rd key in multisig to store data rather than burn key or user key and make 33% cheaper ..but would need a cp update to support

This was the plan on src-20 as well as per Joes suggestion. A cool feature and an easy way to decrease the footprint

yeah it's the biggest way to reduce cost using standardness

multisend with extra tx2 outputs so can be cpfpd would be nice

rbf tx support too on the list of nice to haves

There are 3 Counterparty hashes per block: transaction, ledger, and messages. Initially, it was only transaction and ledger. Based on that, we can consider messages the “least” important.

But is still useful to confirm nodes are running the exact same version of the protocol library.

But I’m thinking, that if we were to do changes in the database tables only for optimization, then it would be acceptable to have different message hashes as long as the ledger and transaction ones match.

Finally, deciding between ledger and transaction, in the context of a protocol (rules), both are at the same level of importance. But in terms of the token holdings, the main one is ledger.

But these conversations about the issuance transfer get me thinking that maybe is not correct to say one is more important than the other…

I member

Good info. Sorry, My asking more question was intended for more about the zero issuances.

This is a current issue.

The idea that descriptions “change” is flawed. Descriptions are written immutably in transactions. What is really happening, is that descriptions are added.

This is a core problem in the current denormalized design of the issuances table.

Read: https://github.com/CounterpartyXCP/cips/discussions/109#discussioncomment-7245038

And then after the protocol gets fixed (not duplicating descriptions), the UX can follow and show a description history instead of only the latest (or just the latest if still your choice).

xcp.dev and bitSTART default to always show the complete history

I remember this. I object to reducing description unless an additional field is implemented for the sole purpose of base64. Otherwise I’m forking off on my own adventure.

https://github.com/CounterpartyXCP/cips/discussions/109#discussioncomment-7293169

Lol

Ideally we add a binary data field and we can reduce the size by half

Theoretically we don’t even need base64

To start I would focus on just fixing the unnecessary copying of descriptions. Is bad, specially when considering sweeps

Binary? Encoded at what level? You lost me on that one.

I see good what is said in this pr about database normalization

Still solving the wrong problems.

Issuance description table would do to don't be copying data innecesarly

What is your point here?

Description is not being used as intended. Can I currently stamp with an image and text description?

Exactly. This is my justification, see?

Understanded your point

This is what I thought when I read ‘stamps:’ was a protocol.

I have a question after discussing with Jdog. I understand the driver for his decision is the fact that free asset stamps proliferation is causing parsing issues due to the high proliferation and making impossible to catchup with the chain state thus maintaining an indexer. Putting a fee will reduce the demand for those assets *spam* make the indexer maintainable while providing value to counterparty network as valuating XCP. What in a nutshell is this community opinion on this ?

burning 0.1 xcp does nothing to resolve indexer code and no proof it will reduce demand

No reason we cant. Just need to create a protocol rule around the format

He is having issues with his xchain design. The protocol is still working fine. Prove with xcp.dev, is working fine

Also real problem is not at the protocol level problem is with his counterparty2mysql service don't being able to migrate SQLite db to MySQL so a fee on the issuance of numerics doesn't solve any issue, also the fork was announced with 30+ days of margin and rushed to be a few blocks after his new anouncment

I’m working on replicating the xchain api calls, and he kinda dig himself a hole. Some are extremely heavy on the DB! And made much worse considering reset assets like any other

xcp dev didn't flinch when rats were stamped en mass yesterday

Damn rats. Kind of meme worthy that was the tipping point

A design error in a explorer down any concept can trigger a fork in the protocol

Oh yeah he then rushed his proposal and deployed it to his products with a 20 block activation notice!!

Ok so the thesis is counterparty2sql is sub optimal and the solution is not going to make it more resilient anyways

If instead of numerics were named assets issued in the same rate the service would stop again for xchain

So a fee doesn't solves the underlying problem

xchain went down when btns had a moment not long ago and that's broadcasts not even assets

China went for i dunno what they minted.. xchain lagged

You can read along starting here. It was like pulling teeth to drive the conversation to get to this point.

https://t.me/Counterparty_Dev/9659

FYI... figured you guys might appreciate some clarity on why fork and how to move forward... just sharing my opinion, reject it if you want.

Block 770000 = 1/1/2023

1/1/2023
---
121,795 Total Assets
99,450 Named Assets
8,940 Subassets
13,405 Numeric Assets

Currently
---
229,498 Total Assets
107,187 Named Assets
10,196 Subassets
112,115 Numeric Assets

sqlite> select count(*) from assets where block_index<=770000;
121795
sqlite> select count(*) from assets where asset_name not like 'A%' and block_index<=770000;
99450
sqlite> select count(*) from assets where asset_name like 'A%' and asset_longname is not null and block_index<=770000;
8940
sqlite> select count(*) from assets where asset_name like 'A%' and asset_longname is null and block_index<=770000;
13405

sqlite> select count(*) from assets;
229498
sqlite> select count(*) from assets where asset_name not like 'A%';
107187
sqlite> select count(*) from assets where asset_name like 'A%' and asset_longname is not null;
10196
sqlite> select count(*) from assets where asset_name like 'A%' and asset_longname is null;
112115

As you can see, 9+ years of stable growth on named assets and subassets which support platform with anti-spam fee

In 2023, the total number of assets on the platform doubled... and over 100K "free" numerics were spammed...

These numbers only take into account the total number of assets created numerics vs everything else... it doesn't even really address the TRUE size of bloating the database, which is counterparty stores the full base64 image data in a table that is required on almost every sql query join... thats a separate issue

While everyone is freaking out about fork and worrying about what it means... I think we should all ask how did we get here and what is the core issue, as that is how to best move forward IMO.

Core issue is should there be a fee on numeric assets... up to the community to decide... I think it is abuse and have taken my stand...

Others in the community who run projects on this platform should take time to review these numbers and forumulate and voice their opinions publicly...

You may disagree with the fork, but IMO only way out of this is clarity on what community wants, and community members who have a large stake in the project (developers who actually run projects on the chain) should have their views heard loudly at this critical time.

Wtf is this crap? Misdirection? This sounds so out of touch. Am I wrong?

https://t.me/Counterparty_Dev/9624

yeah, IMO should be done at the non-protocol level. As I understand it, Stamps functions as a metaprotocol in a not dissimilar way as Counterparty does to Bitcoin. Think this kind of standardization can and should be done in existing description field.

This sounds like he tries to convince people that he did it for the good

core issue is that your pepedevs farm becomes dependent on other people's technology

xchain is whose intellectual property?

who owns xchain?

or is it opensource?

lets stop with fanning the flames... if xchain was so unstable, you wouldn't have been using it the past 9 months... whats done is done... i'm focused on moving forward... facts and opinions matter now... not he said she said drama... that is in the past

Fundamentally that's not the case. We're still in the 'if xchain stopped running 9.62 it'd be better' phase of the hard fork. at some point that will change and xchain will have to keep running 9.62 if the goal is to mitigate further damage.

this is social consensus stuff so this is not quantitative and no hard-and-fast rules, but I guess it's unclear to me outside of Jeremy which members of the Counterparty economy as it were are in support of 9.62. Again, this is normally the kind of stuff you sort out *before* you hard fork.

But is not possible to stop 9.62 at this point right? Or I see it that way maybe I'm wrong

totally possible. will result in modest loss of funds.

mostly as a result of confusion! whereas later if he wanted to switch back it'd result in major loss of funds.

Okey understanded

either the minority fork withers on the vine (in which case those who transacted on it lose $ but presumably not too much) or it becomes its own economy, in which case there's a community which has more or less codified its dependence on xchain's services.

He said it himself. He knows there was no need to fork the protocol

spamming which takes down the infastrucure on which all things run xchain/freewallet is the issue... CP can handle the spam, counterparty2mysql cant.

Switch up to mongodb fast af

Didn’t counterblock use mongo

Yeah showing a lot of code to non-technical people to impress 🤡

Or whatever that unused thing is in the fednode I forget the name

I’ve tried many tomes to examine these spam transactions in public but never get engaged. So we are just taking his word that there is ‘spam’

Sure, I think within the technical community I haven't seen anyone contend that the numeric fees aren't independent of any performance issues counterparty may have. the issue is that the hard forking is really a scorched earth thing, and if the majority of the community doesn't blink, the minority fork either needs to quickly die, or commit long term to its vision.

??? While the rest continues in v9.61? Why having to keep 2 ledgers does any good?

afaict xchain is the default block explorer of the community. that presumably will change but for the time being it will cause some chaos.

Oh no! We’re mooning! Must stop!

Exactly. The main problem was THE APPROACH!

Why are we debating the rest? It should not be acceptable!!!

I'm not really debating, more just thinking it through and trying to understand what the future looks like.

IMO the community is doing exactly what it should be doing: building and socializing competing tools

Does anyone in this chat have control over
Counterparty.io domain registration, dns entry or dns server?

but a minority of the community will be affected and may (IMO almost certainly will) indirectly lose money. for some that will be a matter of principle—i.e. because they agree with 9.62—but for most it'll be involuntary. that's problematic and should be avoided if possible.

At least the website is outdated and abandoned, if there is a fork the old docs are already hard to find. A winning/improved fork would have less of a barrier to adoption with all of the missing links already existing for counterparty.

It’s ridiculous!! Let’s fuck with the consensus and brand image because I can’t handle the growth?!?

Gotta say I love that I can still see UNPRUNABLE on bitstart even tho I blanked out the description when using it to test my js asset transfers implementation

Should advice be put out too only mint numerics from addresses without xcp at this time?

I expect that's mostly the case as it's not needed and minting services do most asset creation but ya jnow some use api manually for fun

that then reduces the divergence

https://bitst.art/UNPRUNABLE

You guys tell me if I'm wrongbut it seems to me that anyone who understands or is capable of following that advice will not fall victim to the hard fork.

Depends on the API constructing their transactions?

In fact broadcasts for BTNS also degraded xchain performance

'minimizing divergence' is a category error. hard fork's a hard fork

Aww the sub asset has no prefix to identify is a media 😆

I’m working on a next gen bitstart that hopefully can handle special cases also

Is this because of bitstarts configuration alone? I dont get it.

He thinks he did

Yes I think he didn't convince anyone, but his trolls stream loud

He needs to just stop running the fork, I don’t think anyone has lost any funds yet as a result of it but the longer it continues the higher that risk gets

Yeah media /files handling is at the application layer. And I think that is fine, I believe Counterparty should minimize its responsibilities as much as possible. Maintain a ledger hash basically

This is how it scales

There are a lot of services that use xchain api and those are the most at risk because they don’t necessarily display the warning that xchain does

This is the real problem, he is using his force this way

And he caught everyone off guard by saying 30 days then changing his mind seemingly on a whim

It’s just not an acceptable way to operate in a high trust environment

switching the 30 days to 20 blocks makes his credibility toast

It’s a shame

There’s absolutely zero need for it

The current proposals at fixes (sans the fork) might not think this far ahead.

I think the 30 day ultimatum was the beginning of the end tbh

In the 30 days period we would be able to build all the required tools for sure now we need to rush it again

It started picking up steam around the time of Miami conference.

IMO 30 days is not enough for a contentious hard fork, either...

Yes it is not but at least we can have more preparation than the actual..

No but what happens after 30 days if people don’t agree to his demands

There are a few things that are unusual about this hard fork: it's simultaneously contentious *and* does not represent a meaningful philosophical difference. no wallet software is running the software but the most popular block explorer in the community is *and* a major wallet retrieves balances from that block explorer. It's superficially anodyne but in some ways even more pernicious...

Agree. Then he doubled down to show macho power bs

Some wallets use xchain for balances

i thought it was just free wallet?

Rarepepewallet.wtf does too although not for much longer

@yodark indicated there were more wallets using xchain tookan orb explorer I think we're mentioned somewhere

Yes it is a big problem

Well yeah! He made a PR with his changes… but these also included the activation block. Like, he is above the counterparty consensus. Fuck that!

book of orbs still about?

yeah I mean do you know how weird it is to have a hard fork whose balances are ubiquitously displayed but which no one's writing to?

I've never heard of anything like it.

counterparty likes weird

The weird like counterparty

But is not needed to write using it to be writing accepting it

yep exactly

Is really strange yes

people will be inadvertantly writing to 9.62 chain and their balances shown will be on 9.62 which will *most of the time* correctly reflect the 9.61 chain — which it seems almost everyone actually *wants* to write to...

Yes

I think is good for this reason the check he is doing in transactions API for having a banner alerting invalid tx in one of the ledgers but is not enough

the only way to do it is to implement replay protection.

(if, that is, xchain continues to run off 9.62)

beyond that the community's doing exactly what it should be afaict: building alternative tools that will serve its interests.

But I don’t like it because is like pretending to play nice, but still doing the big damage at the fundamental level.

Is deceptive.

He is malicious fork. Plain and simple

And lacks any principles. 100% straight to the face centralized. Who knows what kinds of can-of-worms he could be opening…

makes a great if not the best argument for running your own node / api

most here knew the centralisation and is why here exists

And just a few weeks ago we had a protocol change… it really makes no sense what he is doing

Anyone who considers him a friend should speak with him one on one, live, ideally in person. I think he can realize this was a mistake and withdraw it all.

But v9.61 is the consensus.

(And the fucked up thing is that he still has this version running! He added a multiple version validity check right? So he is doing all queries at 2 databases now??? So much for problems with performance… 🤯)

And the api at api.counterparty.io

Which is why I keep asking about dns

Very curious on @teysol and Periwig ‘s take on this

Yep important to know

I started to use api.counterparty but feels wrong want a 127.0.0.1

I don't know what my fednode is doing as it became hardworking to understand what version was consensus version when Hardforks kept happening

I kinda gave up on it as didn't know what to do to make it good

Will give it a read. Sorry, still playing catch-up

infact it's not want it's need , else it's trust don't verify

My bag isn’t big enough for the stress that comes with these technical conversations. I’m glad to see the uptick in dev attention, but this situation may hit my limit of patience with counterparty for my use case. I hope not but there are too many plates spinning.

I totally understand it

But we can solve this all together

Can you point me to your use case service ser?

I don't know what are you talking about

Not today, but I will say that my use case perspective is and has been related to the physical, 3D real world, oriented for everyone, instead of something like rarepepe; however I could never be taken seriously with my audience if they saw a bag of dicks on xchain or were told to run unsigned freewallet code. Otherwise the protocol had weight in my eyes, when I came to the community. Lack of docs and dev support on the surface web kept me on tg. Hopefully I could share my use case with everyone soon without having to make counterparty a footnote in the credits.

I like it hope to see it soon ser

Me too

Another small update for xcp.dev - I'm working on the block page.

Not sure how to handle displaying the bindings in the table, for now I will leave them like that. Note that the pages are not responsive (yet).

looks very clean ser i like it

love it

I Dm’d you.

When stamp image support? Hahaha j/k 🙂

@vm_ea and @herpenstein you two are cool too.

I surely hope you can make it happen. Stability for developers to build. There have been many lessons recently

Lol thanks.

It’s been… and interesting couple of days

totally

Thanks! I appreciate your passion for the space

Beautiful! Very grateful for your contribution, it was very much needed 😆

boh three are magicians

I think what you did can work, when you push it let me know to test how very long descriptions like stamps look

And one nitpick, I would include the previous block hash… is what makes it a block-chain after all 🤓

Implement preview vs detail. Truncate on the display side.

Are you running a node, localhost? Care to share your node experience?

He is connecting to the same host as xcp.dev, and running locally

im runing a node, started a week and a half ago, runing fednode in the juans repo

where exactly? in which section

very straight forward

I’m holding back my opinion about why a fork would actually benefit the community and protocol simultaneously, until sleep. This has been at a head since Friday but I feel like I’ve been saying the same things for a year. Let’s see what plays out on the other end. I need a break for a few. Thanks everyone for keeping up and contributing to the constructive conversation. Tag me if you come up with a question, otherwise I might ghost in an undetermined amount of time.

thanks to all the builders here!

The top below the block hash

Don’t hold back!

But won’t pressure you also. Be you. We will be here

I had an accordion there, but didn't liked how it expands. It looked like that, it makes the table ugly I think, not sure.

Anyways this is the first pass over the pages, just to know the app a little.

I don’t blame ya. Focus on yourself first 🧘

Yeah I like being able to see details without a click…

But maybe something like that can work for the long descriptions (and broadcast texts)

maybe with an animation when openning there? to be more smooth the transition? but looks great ser

This, preview the initial (truncated) text, show it all with the click

(it's so cool to see folks discussing block explorer designs in a public channel!)

I’m loving it also!!!

Good catch, It was commented out. Done

Not trying to bring up unpleasant things unnecessarily but would like to ask community about this. @XJA77 @reinamora_137 @mikeinspace e.g. is it preferable to you that your users' stamps be spoofable on the minority fork or that they never mistakenly issue on the minority fork?

I don't know what's the right advice here; I think it depends on the use-case.

which is why I wanna hear from the folks building our what seems to be a pretty big one which is directly impacted by this change.

I can see a compelling argument in both directions.

I though may be wise to help reduce xcp losses for users

jdog says he will never show non fee paying assets since fork but hard to take him seriously

It's not really about conflicting XCP balances; though a serious problem it's fundamentally unsolveable.

it will be disruptive and potentially cause financial injury to users to have issuances not replayed on minority fork but by replaying them you're keeping the fork alive.

there isn't a 'right' answer to this question.

is hard to know what is the best solution

I am thinking we could crowd source / gather .jpg data to include with this fednode blockexplorer

assetname.jpg seems to be sensible starting point .. for named assets .. we can hit up projects like SoG Bitcorns Danks Fakes .. Rarepepe is easy as @hodlencoinfield has the proofofpepe repo still a lot is potentially lost

Does counterblock pull images or icons from jsons n cache locally ?

my partner @snunez42 is already pulling it from @shannoncode json, he has almost 9gb of images from assets named like you says, i think storing it on arweave and have a backup for them for the eternity is a good thing

this is yet another reason why it's incumbent on the forking chain to implement replay protection. it's really unfair to force this kind of decision on majority chain's users :-/

at least as a fallback for images

yes i can try to ask him to change the prefix to try to avoid it but idk if would be posible

yeah not everyone wants needs all the images but a zip or two as optional component could be nice .. I know its not as urgent as api stuff butgoid to hear its being addressed

this is why could be cool also have it on arweave as you pay once and dont need to host in the fednode

yeah arweave sounds good as a backup cloud option but there is no cloud just someone else's computer

but node has to be connected to internet so can retrieve the images

Pepe wtf has all the images for everything on that site

we can ask him for a copy

Link to tx details? Ajax or an on-** event handler could pose problems w stamp data.

Which development layer are you operating on, Presentation?

Remember the OG counterparty users. They have concerns too.

No fud please?

respectfully, this isn't fud

is damage evaluation

before it happend to be able to educate and protect

service providers have some tough choices forced on them and it's important to play it through.

now this is a chess match

maybe sounds funny but is what it is

Responsible wallets and explorers can make this beyond clear to the user.

we're not worried about *responsible* wallets and explorers

we're worried about malicious actors

and with the growth of the ecosystem the appeared so they are here

we know very well at stamps community that they are here

Maybe no?

has been scamps inpersonating acounts

i already did it

This was a bumper sticker on my server rack for years.

Damage is relative. If you want me to get a dent out of your car bumper, I need to use a sledge hammer.

Node install can fix plenty.

I choose my words wisely, minus typos.