- 05 January 2024 (37 messages)
-
Everyone is missing out on a decent conversation in the other xcp dev chat btw. -
if this is called decent.... people arguing and not giving solutions -
Maybe is good to have this chat “firewalled” from that lol
But feel free to forward whatever message you believe is relevant for more people to know -
All I can say is that xcp.dev will ALWAYS be an interface to the counterparty-lib protocol. Even showing invalid entries
Always like to show this example, the first reset asset:
xcp.dev/asset/TWERK -
Fixed lol
-
Thank you! And is all open source github.com/CNTRPRTY/xcpdevGitHub - CNTRPRTY/xcpdev
Contribute to CNTRPRTY/xcpdev development by creating an account on GitHub.
-
this is the future of counterparty block explorer
-
Agreed.
-
I had talks with two who may be worthy to enter the chat, but I dunno.
-
not trolls in this chat please
-
Dankboost and aryan are two who come to mind but I’ll leave it to someone else to invite or give opinion. I dont know these people. Dankboost was… passionate at least.
-
I have no problem with anyone joining. But for sure it would be better to keep this chat as technical as possible
-
Im pretty sure that 90+% of people on that chat are not developers. And 99% don’t have nodes
-
-
So ChatGPT says it’s possible but need someone with more experience in psbts to weigh in
-
Are you taking in account the arc4 encryption needed?
-
Subscribed for later
-
its already done with the first tx since its based on the first input
-
yes but first tx dont add the full op_return msg right? i need to review the send with id=0 idk what implications it has
-
thats the difference, it does
-
the recipient address is defined by the first output
-
can you point me to docs on this?
-
counterparty-lib/counterpartylib/lib/messages/versions/send1.py at master · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
these are the message functions
-
the send that everyone uses is actually “enhanced send”
-
i like how classic send allows the sending of btc with an asset, as it affords the recipient a way to cpfp -
I love that both exist, one explicitly in the utxo and the other virtually
-
I didn't know this exists
-
I'm reading the code now thanks
-
yeah it's awesome
-
I am looking to use it in my latest project specifically so the recipient can do a cpfp .. as i do not want to end up with a send that is not cpfpable
- 07 January 2024 (187 messages)
-
Add 0.10 XCP fee on numerics by jdogresorg · Pull Request #1298 · CounterpartyXCP/counterparty-lib
This pull request puts a 0.10 XCP fee on numeric assets and activates on block 829,020. Activation Logic 144 blocks/day x 30 days (1 month) --- 4,320 blocks 824,700 current block + 4,320 blocks -...
-
Ultimatum is not a good look I agree
-
@uanbtc which version would you recommend I run if I were to run a node tomorrow?
-
Wow .. xcp.dev is now the most comprehensive block explorer!
-
v9.61.1 is what we are running for all stamps to keep current. Juan is as well on the main xcp.dev site, but he also maintains the older version without the consensus changes that recently happened. -
Not sure why Mike is on a FUD rampage
-
Does he know stamps still uses counterparty?
-
Yeah I wonder why... https://x.com/jdogresorg/status/1743812762009211075?s=20 -
You know jdog is no longer maintainer right?
-
It’s just so funny you call him emotional then fire off a bunch of emotional tweets
-
That's fair. I don't deny there's an emotional aspect to it on my end. I think he hurt a lot of people by pulling the plug this morning, and the venn diagram overlap of "stamps" and "counterparty" communities is pretty large.
-
we crack on. i'm definitely MUCH more excited to help with the db issues, and move forward with some psbt support in the core counterparty now that jdog fork is out of the way. I know for a fact we have quite a few devs scrambling to bring up infra and tools to support the core bits for the community.
-
Xcp.dev exists for now and anyone can run a node
-
Afaik xchain just isn’t displaying some info it’s not running a fork
-
the community has 7 or 30 days to reconcile his hostile fork threats, as I read the drama caused by him -
things still show up in freewallet so i'm sure it's still in the rate limited api's
-
That’s accurate
-
Not for me... they're gone... would have sucked to have a dispenser open that you suddenly can't close
-
i do know work is being done to replicate the xchain api's so users can point freewallet to the new API calls for full support of all counterparty assets.
-
oh shit, yeah you're right they are gond in FW now. They were good a couple hours ago lol .
-
yeah guess those dispenser closings will be using the api calls
-
Yes, we all know that xchain is not the protocol. But it also kinda is. Particularly with all the extensions that only exist within xchain and are outside of the protocol. So to the average user, xchain is the protocol
-
I like how he finally shows everyone he is only serving himself
-
Yeah I’ll also be doing that with rpw this week, ironically the original rarepepewallet never relied on xchain
-
You will remove numeric too?
-
lol no switch to pulling data direct from counterparty api
-
haha he's just moving to an new fork where only his address can make any transactions
-
Joe actually inspired the use of numerics when he created Freeport.
-
how dare
-
but i don't like looking at all those numbers!
-
lets get real though. Jeremy has squatted/premined 20k dictionary words and proper names. Fork him right out when he leaves.
open those registrations -
anyways, I don't want to be a disruptive actor and if I did too much emotional shit-talking on twitter this morning, I apologize. I'm not trying to burn anything to the ground, I'm interested in building. will delete the tweets
-
But it’s a good lesson to not be so reliant on one person, I’ve been saying we need more block explorers for years
-
🤦♂️
-
I’ve also committed to open sourcing memepool.wtf by the end of this week if anyone is interested in helping build that out
-
i don't see Derp and Mason in here, i'm sure they would like to help. those guys are working on the xcp.dev stuff as well
-
Cool heads will prevail and in the world of blockchains if you’re at all concerned about a fork then all you need to do as an asset holder is wait
-
Its fascinates me that people think xchain is counterparty, like dispensers depending on xchain, hopefully now we (the community) becomes better educated on the basics
-
Developers just build what they want to see exist, most everyone is self funded to some degree
-
JDOG used BLACKBOX subassets to open dispensers for various CIPs and dev work -
That too
-
was a token that activated features in freewallet once upon a time or it was promised to
-
-
He sort of rugged the community with this one
-
xchainpepe i think it was
-
FULLACCESS too
-
I don't think they "think xchain is counterparty" but they assume an explorer is a window into the protocol. So whatever they happen to see on xchain is asssumed to be happening on counterparty itself, even if some things are specific to xchain and don't exist at the protocol level. I don't think you can blame people for this, why would they think differently? Thats generally how an explorer works.
-
people think QR codes are magic .. they just alphabetical string
-
qr codes are inanimate objects but the general public do not perceive them as such in my experience
-
when xchain is down people are like muh dispensers
-
anyone can turn any address into a QR code
-
Yea it’s very bad everyone became dependent on one explorer
-
Look you cant expect the average person to understand the inner-workings of all the technologies they interact with in an average day. I don't know how my cellphone or car works below a very shallow surface level
-
But counterparty will keep trucking along as always
-
xchain was very convenient . I dont exepect everyone to fully understand the innner workings of all the tech but square bar codes are not diffuclt
-
I remember when Devon up and quit counterparty dev work when he was the sole maintainer, it happens
-
Jeremy collected BLACKBOX funds, and paid Javier to do the work he wanted him to do, similar to an employee, afaik
the CIP process was used also, but loosely. The more time went on the less anything was actually discussed with the community. Recent half dozen upgrades were wholly for Jeremy's personal gain and each one had less discussion. Now we see his true colors with the open hostility.
When I was involved with the newly formed Foundation he refused to cooperate with anything except getting paid for resources and having free marketing for his private service products.
Bottom line being that he was collecting funds as well as forcing upgrades. There should be something sound put into place for the benefit of the community -
The average person knows a bar code is a sting of numbers but make it alphabetical and wooosh
-
I think there is an incredible opportunity here to reposition Counterparty as a Bitcoin-first protocol while simulataneously funding infrastructure and development by switching over xcp to bitcoin. Maybe with some branding polish.
-
i know Open! founder is a cool tool to fund bounties too
-
There are ways of doing it at the tooling level if not the protocol level
-
Yeah xcp within that capacity makes sense. I'm just not sure how valuable it is as an anti-spam mechanism
-
definitely works much better on the dex than bitcoin
-
as this room's topic is Developers,
I would encourage anyone who would like to discuss topics involving our social contract, renewed marketing efforts, or collective organization efforts here @xcpfoundation
ttbomk: this room is made for technical discussion and help -
ok i will shut up
-
time and place. I'd like to be part of this important discussion, today or tomorrow
-
Encrypted Sheet
CryptPad: end-to-end encrypted collaboration suite
-
this was done yesterday by derp, here are almost all the endpoints xchain has
-
we need to review also the Freewallet repo
-
i take look yesterday and didnt see any that are not in this list
-
okey lets go
-
we can have a replacement this week if we join forces
-
yes i think this should be the first priority, add a little of love to sites to remove all the references to xchain and then start with the freewallet ones
-
i cannot find the express.js file lol
-
xcpdev/server/express_server/src/index.js at main · CNTRPRTY/xcpdev
Open Counterparty Bitcoin Data Explorer - DIY Node - CNTRPRTY/xcpdev
-
Joined. -
Hi to all,
Regarding xcp.dev, I checked out the repo yesterday and had a few hours to play with it. I've started to add some contribution to it which you can see in this pull req https://github.com/CNTRPRTY/xcpdev/pull/5
See the before and after screenshot. -
I kinda started using it in api.xcp.dev, but I’m rethinking the whole approach because that right now is a service for CNTRPRTY/counterparty-lib
I’m thinking it should better be the api backend for xcp.dev (duh?) lol -
would be possible to merge this?
-
For sure! But is not finished yet, only the homepage looks “complete”
Follow up here: https://github.com/CNTRPRTY/xcpdev/pull/5Tailwind css by Chriton · Pull Request #5 · CNTRPRTY/xcpdevAdded tailwind css and formatted homepage. added tailwind and tremor dependencies added tailwind config added txTypeBadgeColor util function styled homepage
-
Lol stamps kicked me out because I’m a scammer for not hating jdog instantly -
Lel
-
who?
-
Don’t even know just saw a screeny of a the message saying I had some kind of alternative motives lol
-
They in there complaining about getting centralised on but want to censor any kind of actual discussion on it I guess
-
Implying scammy behavoiuor after booting someone for no reason is hellah low - can’t even defend against them while they muddling me lol
-
but which group have you kicked out?
-
Stamps their main one where we were discussing all the things just now
-
Just want to say that I booted indelible before and he's upset because he thinks I was implying he was a scammer, which is certainly don't. I think he's very trustworthy person, I banned him for what I considered unhelpful comments, and I have now unbanned him. If that matters. Hope that is clear. For the record. -
this is almost all devs and we respect different opinions and there is full of no devs trolling the conversation IMO
-
a sane discussion? no
-
this is just my opinion okey?
-
My point on this issue is the following, does it serve any purpose to put a fee on any kind of asset to grow the ecosystem, to support infrastructure costs or to stop spam in an ecosystem where the simple fact of creating the asset is already x10 or x20 the cost of the fee? I have no problem with adding a fee to the numericals, they would play in the same league as those who have a name but if that fee serves a purpose, reducing supply by burning them and making the stake holders benefit from it does not seem to me a good enough reason to implement a fee whose purpose or as it is being sold is to stop spam in assets that cost 200x or 300x the cost of the fee that is burned, If on the other hand that fee instead of being burned was somehow, or directly to a counterparty foundation or to the operators of the nodes and infrastructure I see the sense and I don't oppose it at all.
-
XCP is anti spam when it comes to dividends and sweeps
-
or its used as that
-
i think xcp antispam should be used for dispensers rather than the current crippleware approach
-
Juan is here and not in the other chat
-
And I believe it has been for the best.
I’ve been focusing on moving protocol conversations to the repo which was dead in relation to dev discussions -
Dispensers were always a bastardized btcpay, essentially accepting the risk of sending btc and not receiving assets because it makes the process so much easier
-
Will try to find some repo discussions I have participated related to this…
-
I don’t believe there were any show stopping bugs
-
But using a psbt to enable trading would be superior to both btcpay and dispensers
-
i agree dispensers are not a magic bullet - they are awesome for low value / high supply but they suck for 1/1s for high value low issuance cards. Dispensers are a great way to sell or buy xcp but only being able to sell 5000 xcps individually from a single dispenser just means another one must be setup if you wish to sell more xcp .. its a limit that is so easy to get around. Setting up a dispenser is a small op_return so btc fees are easily absorbed
-
also the purpose of that fees
-
burn it doesnt help
-
use it for something helps
-
sorry my english is not the best didnt see it
-
Yes xcp is used throughout the protocol for certain functions: dividends, sweeps, named asset issuance, subasset issuance
-
Yeah I haven’t seen much of a push to remove any of the current uses
-
asset transfers do not require xcp
-
For now I don’t think we should create more controversial decisions
-
Just leave em as they are and proceed with db optimizations
-
As far as numeric assets I’d love to know what stamps plan is for assets on stamps as that’s the primary use case currently
-
Indexer will recognize named stamps too
-
I mean obviously numeric assets not needing xcp lowers the barrier to entry immensely
-
That’s why I built Freeport in 2019
-
To show exactly that
-
5000 transaction limit after five refills of 1000 limit.
the whole thing was predicated on lies. Common logic usecase objections were made and ignorantly dismissed. -
It was an alternative to an expiration
-
To prevent forever dispensers
-
jdogmatic did a bait and switch with fees before. said they should all go to him personally
-
I think expiration makes more sense personally
-
no BTC history should have been a check from day one. that "upgrade" was fine, adding the three others were overkill by the clueless
-
And it’s inline with how dex orders work
-
even though people have repeatedly asked for orders that don't expire
-
It expires after x blocks
-
there is a max block length the order can be open for
-
This
-
i prefere incremental work too
-
i also added to the repo in the server side a new pr with some file reorganization, i added a v1Router with all the current endpoints and removed from the index so everything should be the same as it was in the endpoints used by the front https://github.com/CNTRPRTY/xcpdev/tree/ja/api_startGitHub - CNTRPRTY/xcpdev at ja/api_start
Open Counterparty Bitcoin Data Explorer - DIY Node - GitHub - CNTRPRTY/xcpdev at ja/api_start
-
i also added import syntax
-
was using require before
-
will be usefull to have also a logger, i used to use morgan but if anyone uses other better
-
In some of these I could have said I was in favor of adding a fee to numerics, but I have changed my mind since.
Now I would even remove it for sub assets. Only require it for the genesis issuance of (root) asset names aka “superasset”
- https://github.com/CounterpartyXCP/cips/issues/77
- https://github.com/CounterpartyXCP/cips/issues/82
- https://github.com/CounterpartyXCP/cips/issues/83
- https://github.com/CounterpartyXCP/cips/discussions/109
- https://github.com/CounterpartyXCP/cips/discussions/123Fee on Numeric Assets · Issue #77 · CounterpartyXCP/cipsI advice against doing the emergency fork today (mentioned in the Telegram dev chat). Although I am in favor of fees on numeric assets, a fork without a public announcement and debate is a breach o...
-
Joined. -
Not exactly sure what you're asking. But I'm happy to share our overall plans.
Once we finish the stamps indexer public release the plan has been to start playing with PSBT support on src-20 and bring those findings back to CP so we can unlock all the stamp assets there in a non-dispenser way. This may entail changing the tx format all together.
There's also lots of talk about changing the transaciton format to optimize the size and space consumption/cost of stamps in general. (P2WSH or otherwise) This can happen both in CP and at the SRC-20 level. As we know the current base64 method is quite excessive, and really wasn't expected to be so successful. Which is why we don't use base64 on SRC-20.
I think with the SRC-20 stuff we have a good playground for features that could be implemented into CP as well - for example the db conversion (i think we would have to do mariadb not mysql with licensing fwiw) and the psbt support specifically. This is mostly because SRC-20 is using a very similar tx format in homage to CP, and was forked off the CP bits anyway. It was simply a way for me to learn all the inner workings of the CP code.
It's very refreshing to now be able to circle back and share some of what was learned and push things forward without perpetual threats against stamps. We know where we sit and it's much easier to plan. -
otherwise irt to fees. i've always supported this if it's done in a meaningful way. It would make sense to have them on broadcasts as well to even the playing field across all assets.
Otherwise stamps has been relatively apathetic to this decision because the cost is so trivial. It's easy to build in this burning mechanism into all the minting services/wallets/etc. And has been the plan for some time.
However if a fee is put in place we are prepared to push forward more aggressively with NAMED stamps since that would make more sense as an option. -
I'm only concerned about named stamps showing on xchain so i would prefer those be immediately removed to avoid confusion in the case of a fork.
-
its an interesting arrangement currently wrt how the stamps indexer works
-
running both src20 and counterparty
-
yeah i was rushed with the src-20 fork wars lol
-
would have done it differently for sure with more time
-
but we always intended to fully support CP so we tightly integrated them
-
hahaha for sure, i dont think its bad its just interesting, i think its good to suss out these architectures, get to be the guinea pig for the future of indexers as a whole
-
did you see the psbt idea i posted? i wish i understood them better and the possibilities but ive had a tough time finding good information on how to build them
-
lolz if i had only known when mike asked me... "hey can you index a few things off CP and we just play around"? me, "sure i'll throw a few scripts together over my little break from work to play around" hahaha had no idea what i was getting into.
-
and now you have to support it FOREVER, we are all sisyphus
-
yeah there's a few chats going on in the stamps dev chat about constructing them. Steve has played around with it quite a bit. Several others have some transactions out in testnet I believe that I haven't had a chance to poke at.
-
sweet
-
haha such is life
-
but yeah, once this indexer is done that's our next major focus.... well not anymore. now it's spinning up more CP infra so that is delayed drastically. but i digress
-
I'm just really excited to have so many stamps devs jumping up and supporting this. It's really great to see. Everyone is piling in to help xcp.dev, API's and the like. I hope we have an xchain api replacement soon so users can just swap their API in freewallet and be back to normal CP operation.
-
the mempool work stuff Juan did as well looks sweet. I'm looking forward to putting that in the stamps indexer.
-
I'm sure some of his contributions from his fork will be more appreciated now so i'm overall quite bullish with the changes.
-
*repo fork*, but still in consensus 🤓
-
Anyone who needs a cp bootstrap can dm me
- 08 January 2024 (332 messages)
-
In May last year I wrote CIP29
https://github.com/CounterpartyXCP/cips/blob/master/cip-0029.md
At the time, thousands of numeric assets with zero supply were flooding the DB (SRC20, was it?). The concern was that eventually millions of new assets would degrade counterparty performance.
These were not even real assets, just data storage in the asset description. Instead of asset issuances, broadcasts would have been better. Broadcasts have much lower impact on Counterparty nodes.
An XCP fee on issuances would incentivize broadcasts over issuances.
This was the rationale for the CIP. However, if DB optimization is realistic, then a fee is not necessary imo.
I encourage writing a competing CIP that can potentially replace my CIP. -
Imo the best move on current circumstances is doing nothing. The people in control of the protocol should just not accept the fork PR.
Let JDoge fork. -
I can help too. Swagger docs? Postman collection?
-
Cool the status is the next https://github.com/CNTRPRTY/xcpdev/tree/ja/api_start this branch is what I started yesterday to work in, v1router is all the endpoints that currently are being used by xcpdev I didn't touch it but put in his own file, V2 router is all the new endpoints to replace the xchain onesGitHub - CNTRPRTY/xcpdev at ja/api_start
Open Counterparty Bitcoin Data Explorer - DIY Node - GitHub - CNTRPRTY/xcpdev at ja/api_start
-
A day or two ago I thought we made it clear the tx’s were not spam and were 721. Also that performance was not a protocol problem but related to jdongs sqlite2php script/batch which is not part of the protocol.
-
Fwiw, for years I thought opening up named assets beginning with ‘A’ would be a great move. Change so free numbered assets are only for a named asset. Make sense?
-
The only way a fee helps with growing and support costs is if a dev holds a xcp bag and pumps it for a dump.
-
Encrypted Sheet
CryptPad: end-to-end encrypted collaboration suite
-
I thought there was a CIP about the db performance but evidently not?
The fee discussion has been beat to death. I think the api improvements, explorer and mempool optimization Juan has going are a major step in the right direction to moving those tools to the community to improve tooling and performance for everyone not just those running a db migration tool. -
Kind of funny you have to create a fork to write a CIP haha at least it’s in consensus.
JA and I have talked about one where a bitcoin node is not required and relying on quick node free plan(or other). This drastically reduces the size of fednode obvs and makes it way easier for dev environments. JA played around with it more but addrindexrs was a little more complex to work like that I believe.
Also the Zmq support noted in the code should be an easy one. Haven’t looked at Juan’s PR for the mempool in detail but maybe he did something there as well. -
Happy to do some now though. Major hesitation’s previously that they wouldn’t get merged or taken seriously so it seemed like a waste. I will say it’s a breath of fresh air being able to voice things! Quite excited what we can move on collectively
-
It does not rely on zmq, so is not “realtime” but performant instead
-
Jdoge in full on attack mode
https://github.com/CounterpartyXCP/counterparty-lib/pull/1298/commits/ab6cd5b6826ec2b3b0885160cedf53ac1a5eb69c
Consensus war imminent, block 824888Add 0.10 XCP fee on numerics by jdogresorg · Pull Request #1298 · CounterpartyXCP/counterparty-libThis pull request puts a 0.10 XCP fee on numeric assets and activates on block 829,020. Activation Logic 144 blocks/day x 30 days (1 month) --- 4,320 blocks 824,700 current block + 4,320 blocks -...
-
I don't have my trustless node synced yet :(
-
sooo.. is that going into the core CP bits or just on the jdog fork? I guess he still has the power to commit to the repo @hodlencoinfield @jp_janssen ?
-
Im leaving api.xcp.dev as is until you have it set. Use it!!
-
can jdog be removed from the CP repo. this is chaos for everyone.
-
Agree. He must be removed for his actions
-
i hope he dont merge it, can he merge it?
-
Also remove access to the “official” accounts
-
yeah his threats are worrysome. ownership of all the domains and the repo?
-
yes
-
I’ve said this from early days, he treats the protocol like his own personal backend
-
xcp.dev running smoothly (even in the src20 days. Yet, breaking consensus with a full on war because of issues with his private product architecture
And he was the lead developer 🤡 -
Sorry man but I’m kind of pissed, because I got so much shit and heat for AVOIDING forks and was attacked by the establishment… but I don’t see the same for what JDoge is doing
-
agreed. you should be very pissed. just your contributions that i'm sure jdog would have never merged are a huge step for the community
-
i asked him for a paid service
-
he told me there wasnt it is public
-
i told him exactly what requests i would do and what period of time
-
he agreed on that terms
-
i did it in a incremental way so if an asset has been updated in the las 6 hours is not updated also each user when visit an asset triggered an update
-
was not too bad
-
he took the image when my scripts start failling bc of his rate limit and was configured to retry each second
-
so is not a real usage screenshot
-
The protocol is working fine. The api part is a bit fucked because of changes like the reset, but there is no performance problems at the consensus layer
-
Well yes I could. But my intention was more to promote people having their own nodes!
-
this is a thing to explore too
-
i am starting running my own trustless node thanks to you
-
we at universelle are exploring this posibility not just for counterparty, also for stamps, there are many people that doesnt want to run his own architecture and they prefere to relay on apis, in ethereum is very common and ordinals too so here is another way to go, having a public api with some kind of rate limit and a paid subscription with a hosted private one
-
it helps to pay the infra, and does the network more resilient
-
look at quicknode for example they do it with bitcoin nodes having an enough free tier to most of the purposes and also a paid moder
-
amazing how many requests QN allows for free actually
-
we at universelle comes from ethereum and evm so we know a litle on how the things works there, we try to do similar things here
-
can beat on that indexing from 3 systems for 10's of thousands of blocks
-
yes is pretty cool their free tier
-
yes
-
all about the SLA's. I'll leave that to Universelle 🙂
-
if you want a dedicated node that start working in minutes you pay 400$
-
no no each month 400$
-
not terrible no
-
they have also a very good support also for free tiers
-
perfect example of this working
-
this is my point too ser
-
but fees with a fee model and with repercussion for the protocol IMO
-
totally agree
-
true indeed. we have fully supported fees if they are dont in a meaningful way that actually help the community in some way. pointless just as a trivial amount that actually would do nothing to inhibit things like 10k collections which seem to be the problem as of late.
-
correct. glad that's clear to people not simply responding by emotion.
-
bizarre that's seen as gaslighting or anti-CP in any way but i digress. we can solve it and strengthen things as a whole.
-
Counterparty is interesting, setting new fees doesn't seem to directly incentivize or pay for services, just burn and increase the price of the token -
XCP being 10 or 1000$ doesn't seem to directly translate into improvements to the network
-
Unless the entire purpose of the network is ultimately to pump the price of the token
-
but if this is the purpose is bc then comes a dump
-
Given that, I'm circumspect of new fees
-
fees that actually serve for a purpose not just for burning IMO
-
pay a foundation, pay for infraestructure costs, pay for bounty developments, pay for grants for onboard projects on counterparty, etc
-
Yeah, I should have clarified, new fees implemented as XCP burning
-
I'm circumspect of, as it doesn't appear to directly correlate or be linked to improving the actual network or services, other than pumping the price of the token
-
The tokens WILL get fucked, because there will be 2 ledgers
He will need to withdraw his fork eventually, if he really cares about Counterparty -
someone yesterday was chatting that node operators should have a stake of XCP - which is fair. In that case an "official" listing of node operators would be reasonable. and then everyone is in line with helping to ensure value in XCP tokens. I have quite a substantial stake and am heavily invested in infrastructure.
Previously there's no real way to get listed as an 'official' source on coindaddy or otherwise since it was so centralized. -
When XCP was created, there was no proof of work etc
-
or proof of stake
-
Hell i'd send Juan some as well for us to be in that category.
The only problem is that we know JDog has 1% of supply so there's little motivation to pump xcp haha -
XCP is a virtual token. If there are 2 ledgers, which one is it? If it is so easy to fuck with it, what is it’s worth?
So much for community and continuity.
It is a social contract. An individual believes he can DICTATE (!) what is the ledger.
Let this be a big lesson, conservatism is the way to go from now on. I believe -
The culture of constant protocol changes is causing this. Is seen as nothing to change the protocol.
It is a big deal to fuck with it -
Yeah, its bad.
-
Promising a fork is a surefire way to pump the price of the token so everybody can double up :0
-
I don't see how there is a doubing-up of xcp in this scenerio. Most of the consensus rules on both sides will remain the same. They only diverge when issuing new numerics on Jdogparty, but he has done us the favor of removing numerics from view so users are unlikely to do that anyways. So its the "same" xcp on both sides as both jdogparty and counterparty will be reading and tabulating the same instructions in OP_RETURN
-
I'm sure you will be successful at explaining that to the masses
-
Im not trying to. I want to get my own thoughts straight if I overlooked something
-
Yeah is not a tipical fork, because is all the same data. Is about the interpretation of the data
-
yeah counterparty nodes do not speak to each other - they only read blockchain
-
Theoretically if both forks come to complete autonomy then the fees spent on numerics in one will still be in the other wallet version untouched? therefore I see a double spend opportunity. with these kinds of situations you'll know it when it happens
-
Yeah XCP balances gets affected right away
This is baaaad!!! -
He should change his header from CNTRPRTY to something else, no?
So it's on him? -
Someone with influence should do the PSA about stop using JDoge products
-
No one uses xcp to buy stamps… like almost never. They are typically sold in dispensers for Bitcoin. And JDog has made it so you can’t even use them now on the dex (through his tooling)
-
Remember altcoins that got 51% attacked for a handful of blocks, and then lost a ton of value. They tried to explain the nuance to the market, but it didn't matter. Normies didn't want to learn, it was scary, so they dumped and moved on
-
XCP was already complicated for normies to understand
-
Yeah I should get back to work 🤓
-
Yup this is least disruptive to users. How big of an effort will it be time-wise?
-
what do you mean here? need help with something?
-
i
-
ahhh yeah ok yeah that's an important one I think JA was having some issues with as well
-
i'm still buried in python land so probably not much use unless it's questions on the actual details of encoding
-
probably for the indexer chat anyway 🙂
-
Tell me 🐸
-
The irony is that src20 actually did this the right way. They started using the ‘stamp’ prefix to not piss off JDoge… but it wasn’t really necessary. 0 locked issuances have minimal impact to the consensus code
-
https://960.xcp.dev/ is up again. Is the node I use to test stuff, and left it unfinished last night
And running like butter with blocks with 1000+ messages -
-
what iwas the biggest different between 960 and 961? the dispensers?
-
Is kind of subjective, is more about the quantity
For me the biggest difference is the new issuance message id -
We live in the matrix
https://www.xcp.dev/block/824888
4900 messages, the most I’ve seen in a while
The same block as Jdoge’s activation block
🤯 -
counterparty-lib can handle it 💪🚀
-
I hope everyone is reading this and seeing the blatant hypocrasy (his type of SPAM is fine). I also hope the CP community doesn't go along with a game of chicken simply to avoid a fork (as messy as that may be). You'll forever be playing a game of chicken regarding protocol upgrades.
-
I have automatic donations in freewallet for the past year or so... got about 10k donated over that time from CP community.
About a month ago some chinese ppl discovered BTNS and spammed txs to mint out a token... spammed 50k+ txs... spent over $400k in BTC on miners fees in 12 hours... and I got $10k in donations from freewallet.
Seems pretty clear there is demand for BTNS, as they paid me as much in 12 hours as CP community did in 12 months.
https://bitinfocharts.com/bitcoin/address/bc1qd0nateja8l9am8tqpzjn9uazhf6dlp9qer2tra
I'm still here for CP, but my focus is shifting to writing some new stuff and having fun instead of the heavy weight of maintaining the CP infastructure alone as sole dev.bc1qd0nateja8l9am8tqpzjn9uazhf6dlp9qer2tra - Bitcoin Addressbc1qd0nateja8l9am8tqpzjn9uazhf6dlp9qer2tra Bitcoin address with balance chart
-
He forked. Now the rest of the community (outside of stamps) need to decide what to do
-
Even if you agree with the fee on numerics, I think it’s a mistake to give-in to a game of chicken. That basically means JDog delegated no authority whatsoever. It’s his way or the highway
-
If he changes CNTRPRTY to BTNS, then he is fine
-
yes he is talking about merge to cp repo
-
But what a horrible presendent. It was bad initially, but he made it 1000x worse by changing the activation block to a couple of minutes in the future 🤯
What is he trying to prove?? -
That he's in charge because he controls most of the infrastructure and everyone else will have to follow him. Let's see if he's right!
-
Hope not. This will kill Counterparty, stamps will survive though
-
no ser we will support counterparty
-
xcp.dev will be showing everything and giving support to freewallet
-
it will damage reputation? maybe
-
Yeah me too I mean is crazy if the “official” repo follows
-
What is this really all about?
-
we are already scraping images for assets
-
I mean, publically, this is about anti-spam
-
measuring dicks i think
-
BS. Who is he to say what is spam or not? And the crazy thing is that ALL txs will still be stored in his fork, but as invalid entries 😆
-
Yeah, that's what I was trying to say, is the stated reason is anti-spam
-
but it doesn't appear to be about that at all
-
I don't know
-
Yeah is going to be a great educational event, only if the protocol repo doesn’t fall for the pressure
Glad to have original devs around watching this. I hope the right decisions get made at the repo -
If you want to regain repo access, we can ask Robby. Only he has permission to add new ones. @teysol
-
Wrote this in the stamps chat. Hope we are aligned here. And if not, speak up and make your case
-
FYI, the official counterparty-lib protocol has not changed. Jdoge’s PR has not been accepted and merged. And I highly doubt it will.
https://github.com/CounterpartyXCP/counterparty-lib/pull/1298
counterparty-lib is running smoothly, as proven by xcp.dev. No need to feel sorry for xchain, is just not very well engineered for the growth of stamps.
The ledger hash is what determines the source of truth. Be aware of the ledger you are following, because this is no typical crypto fork. Here is the same data, just interpreted in different ways.
Counterparty and stamps can continue growing together. And I expect Jeremy to withdraw his fork if he really cares about Counterparty.Add 0.10 XCP fee on numerics by jdogresorg · Pull Request #1298 · CounterpartyXCP/counterparty-libThis pull request puts a 0.10 XCP fee on numeric assets and activates on block 829,020. Activation Logic 144 blocks/day x 30 days (1 month) --- 4,320 blocks 824,700 current block + 4,320 blocks -...
-
-
At current environment, .1 xcp isn't even a meaningful anti-spam fee
-
-
Lol time travel!
And what he refers there to me forking, is actually me NOT upgrading
Wanted to learn about how the protocol software reacted -
-
And was (and still am) against the reset implementation. It might be part of the cause of performance issues in xchain. I treat them separate in xcpdev
-
yeah that was the first sign of trouble. a forced fork on his way out that was untested and only two weeks to prepare over the holidays. I really don't understand the ill intent. It's not like we are threatening his beloved BTNS, unless we implement a fee at the broadcast level which makes a lot of sense now.
-
-
mmmm it shouldnt
-
-
is in the block correctly show
-
memepool not mempool
-
this is the block
-
My browser says
Uncaught (in promise) TypeError: l is undefined
e NextJS -
the tx for me doesnt load neither, the block loads
-
i will query the counterparty api to check
-
counterparty api shows the tx right
-
-
yes is the worst part of this, at least if he doesnt show any stamp is okey
-
but if some shows and are shared between ledgers and there is a dex happening with a new one could result in a fund loss
-
STAMP: in the description
-
not case sensitive
-
kevin asked too
-
Don’t think anyone can lose funds ,worst that would happen is that it mints on one fork but the other fork doesn’t have the XCP funding so
It doesn’t mint there -
But if only official stamps ‘numbered assets’ are never seen on the fee’d platform, then any stamps that are named (and have paid the anti spam off) should be mutually exclusive visibility wise to either platform which should mean no confusion
-
not many otc trades here now
-
A savvy user should say no and insist on doing a dex order
-
If they send them XCP that would be on both platforms no?
-
Yeh but if they send XCP, they send XCP
-
That’s would still be valid on both
-
I see, the eventual divergence (only causes by lots of minting I guess) may offset someone enough to allow them to try to trick people there
-
Mmmmmm lots of red warning boxes in UIs lol
-
Astral planes of xcp
-
mmmm yes that sound problematic
-
If Jdoge is not going to backtrack, at least, he should change the prefix to BTNS, JDOG, GOD, whatever he wishes! Because that is what he forced stamps to do for the src20s and it has been lots of work just to please him.
Either he is a hypocrite, or too dumb to realize. Don’t know which one is worse -
if he changes the prefix or removes all the issuances with description starting with stamp: we are good
-
I don’t think there is much to analyze. Is 2 ledgers for the same “universe”. Which one is the truth? Users won’t know the difference! This is horrible for Counterparty as a brand! Jdog by himself is destroying the trust on the platform!!
-
Freewallet is on the fork, right?
-
Well yes if you have it auto-update and keep all the default settings. Many people are in this boat
-
There was ill intention. Why the sudden activation?
-
just xchain is in the fork so half freewallet, the ui is in the fok as uses the xchain api to retirieve balances but the node it is using is still counterparty also all of this is configurable, this is why we are recreating all the api calls of xchain on xcp(.)dev so we can replace the host at freewallet settings
-
yeah i asked a few times as well. no real response on that
-
-
he does control the api.counterparty.io endpoints as well correct?
-
are the oficials
-
and runing in theory the code from the oficial repo
-
but who knows
-
he controls it right
-
yes from xchain
-
Encrypted Sheet
CryptPad: end-to-end encrypted collaboration suite
-
It is not unheard of for the community to change repos if the primary one is contaminated by a bad dev
-
here is the list der did with api calls
-
this is why we need to finish this apis soon
-
and make all the people change to the new host
-
in a month was posible to do now again jdog make us rush things
-
is easier the api response for parse
-
-
also he shows info about estimated values and this not easy retriavable in one call to counterparty api
-
this is the balance api response
-
to freewallet? no ser
-
worj¡king on the shadows on this maybe he is upset too if we change the host there
-
we would need to fork freewallet to do this pr i think he wouldnt merge it anyway
-
the only real way to make it usable how is is replace api calls
-
directly from his settings
-
Oh yeah this was not like that until like a year ago. And then he added auto-donation 😆
-
mmmm idk we did a test with one issuance using 9.61 api in a wallet paying the fee and i think is right, idk the other way.... let me check xcp balance in that wallet
-
@reinamora_137 you sent 10xcp right?
-
They are. I have made some non-consensus breaking optimizations to the lib
https://github.com/CNTRPRTY/counterparty-lib/commit/1a8eef3938c698bb4fd94f900d0aa32346d88909new api method: get_address_balances · CNTRPRTY/counterparty-lib@1a8eef3- includes relevant genesis issuance info: asset_longname and divisible - all in a single query
-
uuuuuh this is not good sign
-
-
503 at api.counterparty
XCP Dev Chat
Public archive of Telegram messages.
- 05 Jan 2024 (37)
- 07 Jan 2024 (187)
- 08 Jan 2024 (332)
- 09 Jan 2024 (865)
- 10 Jan 2024 (479)
- 11 Jan 2024 (508)
- 12 Jan 2024 (685)
- 13 Jan 2024 (674)
- 14 Jan 2024 (319)
- 15 Jan 2024 (104)
- 16 Jan 2024 (318)
- 17 Jan 2024 (24)
- 18 Jan 2024 (10)
- 19 Jan 2024 (3)
- 20 Jan 2024 (22)
- 21 Jan 2024 (1)
- 22 Jan 2024 (33)
- 23 Jan 2024 (11)
- 24 Jan 2024 (19)
- 25 Jan 2024 (294)
- 26 Jan 2024 (189)
- 27 Jan 2024 (65)
- 28 Jan 2024 (7)
- 29 Jan 2024 (8)
- 30 Jan 2024 (62)
- 31 Jan 2024 (110)