- 05 January 2024 (767 messages)
-
This is true. Highlites the differences in a protocol problem and a jdog/xchain problem. They are separate codebases and githubs. -
ok but its EVERYONES problem if xchain is relied on by everyone -
Your poison is weak. Drink more.
-
and its a problem in general for building new block explorers
-
Different problem
-
@jdogresorg
-
i mean i just laid out the issue here
-
Not you specifically. The conversation in general. Thanks for your input, really.
-
im sure jdog would love to just turn off xchain and let someone else deal with it
-
It’s technical
-
thought has crossed my mind a bunch in recent months... my life would be much easier with no xchain and freewallet.. but CP would be much worse off... back to 2014 and counterwallet (oh yeah, its still broke) 🤷️️️️ -
honestly nothing would force development quicker then just turning xchain off lol
-
Agreed
-
its a crutch for everyone that would be building their own solution otherwise
-
and building my own block explorer it totally makes sense why jdog built it the way he did
-
yup... I know... shitty position to be in... but asking nicely for explorers and wallets for years hasnt worked.... CP would be in a much better place if more explorers (full explorers, not just cherry-picking data) existed.
-
i want to start contribute with xcp.dev which is the most advanced opensource one -
i think we could start by getting juans api fixes merged into counterparty-lib
-
but i have not more time in the day
-
Imagine if we could direct the current momentum in a positive direction…
-
yes!
-
lol
-
memepool.wtf is up!
-
-
xcp.dev is up too
-
-
heh... maybe start with putting a UI on it... noone gonna want to use that text shit... its a good start showing data... but no one gonna use it in that form beyond emergency comparisons... take 1-2 days and put some time into the UI (bootstrap can work wonders) ... just my opinon tho... overall nice to have another block explorer, even if it makes my eyes bleed🤷️️️️️️
-
jdog can you explain how the mysql db works for xchain?
-
I appreciate the rawness.
-
as in what makes it different from sqlite
-
.dev not .normie
-
ngl i love the 1995 web look
-
yes this is the priority
-
Xchain is just PHP code that queries the counterparty2mysql database.... not real magic, just SQL queries that join a bunch of tables together and spit out that data in JSON for either explorer viewing or API consumption.
-
yeah i dont mean xchain really, just the db
-
is it just to add indexes or is it related to how sqlite works vs mysql
-
there are enough developers in here we should be able to work out a more performant solution
-
I believe Sqlite exists due to a dependency?
-
i thought the reason for it was it creates a self contained db file
-
Thats bad
-
-
hahaha, nice URL
-
Sqlite (if memory serves) is more for lightweight databases and embedded systems that need a real small footprint.
-
what prevents running a version of counterparty-lib that uses mysql?
-
nothing much -
Addressindex or something?
-
is that what you use for the src20 indexer?
-
we did that for the stamps indexer (starting from the base CP bits)
-
I asked this question last year
-
ahhh got ya... yeah counterparty2mysql has a list of the optimizations... really the only performance difference is indexing all the addresses, assets, and transactions (giving them a unique id # and referncing that id# instead of the full address/asset/tx).... current CP/Sqlite database stores every address, tx hash, and asset in many places in the DB... which means queries are FULLTEXT and take a while... vs indexed data in counterparty2mysql (smaller disk footprint, way faster queries)
https://github.com/jdogresorg/counterparty2mysql
Database Customizations
- Index all assets, addresses, transactions, and contracts
- create assets table with up to date summary information
- create balances table to track address/asset balance information
- create blocks table and index transaction hashes
- create index_tx table to track tx_index/type information
- create dispenses table to track dispenser dispenses
- create markets table to track decentralized exchange (DEX) market info (prices, floor, history, etc)
Additional tables (populated by counterparty2mysql):
- assets
- balances
- blocks
- markets
- index_addresses
- index_contracts
- index_transactions
- index_tx
- index_tx_types
- transactionsGitHub - jdogresorg/counterparty2mysql: PHP script that populates a MySQL database with Counterparty dataPHP script that populates a MySQL database with Counterparty data - jdogresorg/counterparty2mysql
-
we just used a docker container for the mysql db so a user can use that contained environment like fednode. . or choose to write directly out to a remove db cluster.
-
IMO core issue is not indexing addresses , transactions, assets... indexing those within CP will speed things up a bunch 👍️️️️️️
-
but i did start with CP and yanked a bunch of stuff out, migrated it to mysql and added our stamps specific stuff so it is doable.
-
most of the changes are the queries that uses ? instead of %s, and the setup of the db
-
that there is already a function for that so should be just needed to adapt it
-
dogeparty still survived when this happened -
in making a migration from sqlite to db.. and how the transactions are commited in pymysql are different than in the sqlite libs
-
we arent going anywhere
-
it could be done in parallel to start
-
yep
-
yeah initally i was writing to both db's
-
just to make sure i got the commits correct
-
beceause of how things don't get commited untill all transactions are indexed
-
if only we could have had a civilized convo when you were doing that and we could have updated counterparty too lol
-
eh... we agree that optimizing the CP database to uitilize it directly is better than relying on a cp2mysql hack.... so IMO its progress... still need XCP fee, but conversation moving in positive direction and focused on improving CP for everyone.
-
yeah that's what i was trying to discuss
-
it was a major pain in the ass
-
I dont think SQLite will do parallel well.
-
its just parallel in the python scripts
-
this is not the first time we propossed this...
-
well that was then and now is now
-
well i didn't do it in a parallel process tbf, it was sequential how i was doing it since my goal was to remove the sqlite dependency anyway
-
no reason to harp on it
-
nah, all good
-
happy to have the convo now
-
can get you guys in the stamps indexer code to check it out
-
yeah that would be the goal here as well
-
yes really happy just answering to this lol
-
open source it n yes
-
til then.. nope
-
it will be open sourced when we are damn sure things are secure
-
there are risks with Unicode char types and homoglyph attacks
-
otherwise anyone is and always has been welcome to review and contribute
-
understand your viewpoint... disagree with it, think dev should take place in the open... but can respect your differing viewpoint and making the decisions that you feel are best for your project 👍️️️️️️
-
i would agree if starting from scratch
-
however we have a working protocol and a token layer to ensure isn't compromized or it wrecks the whole thing
-
well how we did the migration was this way first commititng to both db and then when we checked it wass good removed sqlite
-
also i think we only want to make this db transition once
-
always said, named asset support, open indexer, all the things are in the works.
-
is mysql the way or should we consider postgres, etc
-
correct.. i just chose mysql cuz i am more familiar with it.. there may be other options
-
Steve is using postgresql for the src-20 only indexer which we validate against
-
yep with berkleydb
-
mysql / mariadb / postgresql .... would be nice to see a performance comparison before we make any decision.... any of them is a step in the right direction... tho I prefer mysql or mariadb since its more widely used than postgresql
-
graphql is not a db is just for the queries, you can connect with rest apis or directly to db, is a nice to have but the engine problem is not solved with this i think
-
yeah i think we have a jump start on the mysql integration by copying some of the stamps indexer code for reference.
-
the shorter term solution would also be a faster converter from sqlite to mysql that runs every block
-
basically make jdogs repo faster
-
counterparty2mysql
-
i think that have an if in each query with a env var that makes able to choose if sqlite or mysql or both is good so in the begining both are active to check between and then you can turnoff the sqlite and remove this part of the code
-
but if someone needs to have sqlite bc they like it is possible to have it
-
MySQL has a larger user base.
-
i think as long as the api queries return the same information most people wouldnt care
-
they just want speed
-
The current sqlite2sql script is looping through the api, no? See my previous comment about cron or webhook per block.
-
I have a cron job that runs cp2mysql every minute and checks for a new block/data and if it detects a new block... requests the get_messages data from CP API and then loops through and populates the mysql database using the messages from the messages table
-
what if you batched similar message types into one mysql write
-
like 200 issuances become a single query
-
could be... i'm no database expert... been using databases for 20+ years, but not a pro... sure someone might be able to figure out a better/faster way to write the data..... I encourage ppl to look and try.. but, i've done the best I can with my DB knowledge so far... up to more advanced SQL experts to optimize queries, etc... def some optimizations taht could be made... but def think its more beneficial to focus on updating CP core database vs cp2mysql codebase.... short-term maybe some sql optimizations might work... longer-term, CP database updaet is the way to go.
-
100% but if we can take the load off xchain now while also making counterparty better that would be ideal
-
Agreed, agreed. But we can still try to help xchain and the protocol.
-
AFAIK issue is inserting / updating the index_ tables where all the assets/addresses/transactions are indexed.... updating the index takes time, not sure that SQL queries can change how long it takes to insert data in an index... but yeah... thats where I believe the bottleneck is... and one of the major differences between the database... the indexes and indexed data
-
delay tactic
-
Not everything is a conspiracy pappy.
-
AFAIK the most effective solution for the current problem is implementing a FEE to help reduce the spam
-
hahah how does that reduce anything
-
a couple dollars on something that is already potentially thousands of dollars in fees is pointless
-
I don’t see it as spam, misuse of the protocol maybe. The transactions are legit.
-
you sound vaccinated obvioulsy you dont have unlimited amounts of resources
-
i suppose if we delay long enough all the users will get bored and go away. problem solved.
-
there are obvious shitcoiners attempting to disrupt cp so you can choose to ignore it but its pretty obvious
-
I’ve asked what this table is a few times for a reason. I’m going to assume this is the issuances table for block 82440, showing many numbered stamps, without any filtering…
-
There are also volunteer developers trying to fix these issues via this chat.
-
It’s been fun today. Great progress moving the dev needle today. I’m out for now. Gonna touch some grass.
-
Wednesday @ 10:30 pm EST.
-
-
so do these stampcoin degens have any xcp? seems only those with skin in the game should have a voice. what are the addys of those who voted against the fees?
-
Hence my suggestion for a burn address of xcp to have a vote
-
Or a dev address for the bounty
-
On doing the db work
-
1 address for a no vote and 1 for a yes vote
-
Both go as a bounty and whichever has the most determines fee implementation
-
we have a process defined for pushing forward proposals and funding them (Counterparty Improvement Proposals) CIPs.... and we have a mechanism for voting with XCP.... I dont think features/code should be determined by an XCP vote... but if that is the route you want to go, we can easily do voting on CP via broadcasts.... done with in the past to elect CP foundations... do it now to elect DP foundations.
-
This is a silly statement. You don't get an equal vote simply by holding xcp nor should you. Those who run infrastructure and write code aren't going to be like, "well the bagholders voted against us, so I guess we're not going to proceed with this change..." -
I said a voice not a vote, should limit who can be in this chat by holding xcp
-
Perfect. No need to reinvent it then. This whole nonsense of not holding enough xcp is ridiculous
-
exactly why you dont belong here
-
How so?
-
you and Mike should go off into ghey space together
-
We’re already here
-
how much xcp do you guys hold
-
Why are you here is the question
-
addys?
-
thought so you probably dont hold any
-
Maybe 5... I use it purely for its utility. Buy it when I need it.
-
thought so
-
A few thousand to cover potential fees in creating named assets to support them on xchain is all
-
shall we measure dicks too? or is that too ghey for you?
-
in what addy?
-
I’m in. No fear.
-
maybe a new CIP for that one
-
So u don’t have any xcp got it
-
A lot of the most dedicated CP people don’t hold XCP so comparing who holds XCP and doesn’t as a indicator of their devotion to XCP is a bad metric -
Dev stuff only fren.
-
WHOA HOW BIG IS YOUR BAG?? A FEW THOUSAND ISN'T MUCH NOW I UNDERSTAND SO MUCH ABOUT YOUR ATTITUDE 😂
-
Well considering this entire protocol was built upon only those who burned bitcoin I’d say you are wrong
-
He won’t provide an addy ive asked him a few times
-
You won't believe me, but I can verify Kevin's claim. I remember the day he bought it, xcp price spiked.
-
He market bought a shitload
-
Trust me bro
-
what's so hard to believe? It was a defensive move in case we needed to implement fees on numerics. The idea was that the minting service would handle it for the user to save them from the friction
-
So the threat of fees worked 🤣
-
Glad you guys are admitting it
-
Capitulation
-
Time to implement the fees
-
"worked" to what end? We want Counterparty to work. This isn't a game, we're trying to build a sustainable business.
-
User friction to slow adoption is not "working"
-
So you should favor the fees
-
User friction is anti spam
-
Ever heard of hash cash?
-
Lol
-
Stores should make customers run through an obstacle course before entering. That's definitely how adoption works.
-
Yeah, there's already an anti-spam mechanism in place: its called miner fees
-
mike and gmoney entered the chat
-
Bitch, Adam Back quotes me on the regular.
-
We r flushing out incentives
-
Which is coming to light
-
He ever mention you G Money?
-
all fixed
-
mike and gmoney on timeout
-
make the chat dev again
-
Biggest issue is db performance, let's change the db engine
-
agreed, but most pressing issue is everyone relying on xchain which bogs down under heavy tx load due to bottlenecks in counterparty2mysql
-
I think could be doable to have an env variable in config file to choose db to use maybe something like SQ_LITE=True MY_SQL=True and before each query is performed ask for this? So we can have both in the begining, to check between them, and also the option to allow people who prefers SQLite use it maybe a function that performs the queries and just call this function
-
True for this the only option I see is migrate to other nodes/apis or/and try to optimize the counterparty2mysql code, I didn't checked it, I'm not very good at PHP but I can take a look
-
But fixing counterparty2mysql is just a patch not solves the real issue IMO
-
we could absolutely run a branch with something like this
-
it is 100% a patch
-
Also there is a database setup function so should be possible to setup both db there
-
but should buy some time to fix at the protocol level
-
Also not included in the official repo
-
I prefer start working on this bc I have some expertise but my time is limited and my priority is stamps indexer and rarestamp at the moment if I have to rush an update at rarestamp to be able to keep it running bc of removing numerics from xchain(which I understand, and is a priority for jdog to keep running xchain) I wont have any time for this
-
yeah, deffo happy to contribute to it when possible. Me and JA went through a lot getting it all migrated over. We just have lots of loose ends to tie up with all the upcoming changes and support for making an xcp fee seamless for stamp creators. along with a method to make historical stamps also numeric for a nice user experience in the apps they are familiar with.
-
Are these assets all identical aside from the name?
-
No they are different
-
Link
Bringing collectors and creators together to buy, sell and discover permanent Bitcoin stamps, start your stamp collection in the Marketplace!
-
You can check them here
-
They are src-721 a way to stack layers of images (other CP assets) in a definitive stamp and recreated at the indexer level the description of this assets is just one JSON which references each layer
-
Xcp.dev is not showing the transactions in jdogs pic
-
Thank you for the technical answer that the dev chat is intended for.
-
@herpenstein created this standard with this collection https://www.rarestamp.xyz/collection/avime/0Link
2500 Customizable anime-inspired NFT avatars
-
I'm looking for the spec
-
GitHub - DerpHerpenstein/src-721
Contribute to DerpHerpenstein/src-721 development by creating an account on GitHub.
-
‘Because stamps is under dev, SRC-721 uses counterparty asset ID’ at least thats good.
-
-
They are
-
Sorry, I meant to say not in consensus.
-
What do you mean with not in consensus?
-
this is out of consensus with memepool https://memepool.wtf/block/824440
-
yeah.. still gotta update xchain to fix the hashes.. will work on that later today
-
think its related to the node that xchain parses from having an issue in addrindexrs.. so very slightly different ledger.. will fix hashes n have xchain start parsing data direct from api.counterparty.io instead of its own fednode instance 👍️️
-
memepool pulls those right from the node and it doesnt match xcp.dev
-
Unrelated but related, mempool.wtf my fat fingers just found this.
-
Where can I see the JSON for a 721? I’m on mobile and striking out w the other explorers.
-
FWIW. This is being changed to a stamp hash which is a short unchangeable identifier of each stamp regardless of cp asset name. Both methods are planned to be supported in src-721 however
-
Is base64 encoded but is in the description of any of them
-
That explains why the descriptions look the same
-
So the description is the key
-
As in database key
-
Hash of what?
-
Starting to sound like a fork or real protocol with that type of talk
-
Basically a truncated trx hash to reference any on chain image aka src-20 or cp asset using the same method
-
I’d still love to see a 721 from the backend.
-
@jdogresorg I get it. Developing doesn’t pay enough.
-
It’s just a json string that references all related stamps and merges them into one stacked svg image
-
How many layers?
-
As much as the deploy says you can check in the specs I sent you
-
I don’t believe it’s limited, usually around 5 or so if I recall correctly
-
I’m reading it. Comment says ‘//up to x layers of stamp traits’ so undefined?
-
Yeah the code just loops through any existing t value in the deploy and chooses the proper trait
-
Yes
-
At the artist discretion
-
I see now. Thanks.
-
Thanks a bunch for straight answers.
In SRC-721, The description is base64, but ultimately just text.
Numbered Stamps uses base64 in the description too, but to encode the image data.
I’m going to have to mint a 721 that matches my named stamp and compare, for science. -
Didn't tested referring a named stamp in the layers so I don't know if it would work
-
I think yes but idk
-
Yeah no reason it won’t
-
Recursion(src721) is a big thing because it allows so many cool use cases
-
I meant the data/image but ok
-
If it doesn’t work we can fix on the indexer at least 🙂 because it should. Just haven’t had any
-
Yes
-
However if the mint is a named stamp it won’t be a typical numbered bitcoin stamp but will still show on our side with a negative number
-
Recently added negative numbering for named stamps
-
I was just reading that
-
This has also required us to develop the process for users to mint stamps with a named asset while burning the xcp seamlessly without the user having to acquire it.
-
My mind really wants to see a 721 tx on mempool.space I have a very large stamp and want to compare the effects on the blockchain of a straight stamp vs 721.
-
Any opensource stampers?
-
-
Plan to part of our indexer/explorer release
-
Thanks. Which asset is this?
-
Would actually be more multisigs for just one image creation since the original layers have to be stamps and then you’re adding a json trx to reference them all. Makes more sense for large collections
-
A2691100020508041002
-
We do have serialization and skin compression optional on the json to make that portion smaller as well
-
Heard. I don’t try to make sense though. I do random shit just to see what happens.
-
I have a 7k stamp to compare.
-
avime is the first and best example of src721 IMO beautiful art and innovation
-
Its named and not on all
of the explorers. GOODDOG -
bitSTART
Discover Bitcoin Art [Counterparty / Ordinals / NFTs]
-
i saw it on the indexer while developing and love it
-
I was shooting for 7k, I dont recall the exact size but its up there.
-
I love the array and referencing idea. I’m glad I understand 721 now. Thanks
-
I’m at 5.89 kb.
-
this opens the door to other cool use cases like full web apps stored onchain or games
-
If we can get all the devs singing along
-
as one wise person has said more than once Team work makes the dream work
-
Joined. - 06 January 2024 (182 messages)
-
So I’m trying to figure out how to send part of a stamp using FreeWallet.
I see that if I have one Bitcoin I can send part of it , .5 Bitcoin for example, so I’d think that I can also send part of a stamp
How can this be done ? -
No it’s a Bitcoin
-
A stamp is just Bitcoin
-
not all of them lol
-
Idk
Tbh I was just feeling like messing with the chat after following along earlier
But now I actually wonder if any stamp can be divisible (and we can take that chat elsewhere as it’s not a counterparty q) -
My named stamp has an issuance of 300.
-
its having intermittent issues... keep trying, you'll eventually get through -
was related to me doing some updates on cloudflare.com and enabling some basic rate limiting on xchain to limit abuse... sometimes cloudflare gets a bit wonky for a bit when you change stuff... should be good now.
-
Joined. -
depends on how fast you want your fednode to be... I usually run about 16 cores in my fednode servers... but they are overpowered... so, you could get away with a lot less.... could prolly run CP from a raspberry pi if you were ok with parsing blocks taking a bit longer 🙂
-
Keep us posted. I have an ESXi farm, no fed node on there yet but I can help w ESXi.
-
Block by block. You shouldn’t worry much about performance at this point. Get your underlying OS running right first.
-
Add 0.10 XCP fee on numerics by jdogresorg · Pull Request #1297 · 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 -...
-
Here is a pull request to counterparty-lib main repo which puts a 0.10 XCP fee on numerics and activates on block #829,020 (1 month)... my hope is that the CP community pushes this change through and there is no need for a fork.
-
Release v9.62.0 · jdogresorg/counterparty-lib
9.62.0 Release Notes Fixed issue with malformed broadcasts (more info) Fixed issue with non-correlated block indexes (more info) Added 0.10 XCP fee on numeric assets (more info) Note: Activation ...
-
Here is the 9.62.0 release I will be running on xchain which includes fixes I believe CP should have... pull requests are open for these 3 changes in main counterparty-lib repo. 👍️️️️
-
Xcp fee should at least be higher, that’s trivial. 1 at a minimum seems fair given current btc fees. The extra roadblock of not having it all btc is good to keep spam down at least.
-
The friction probly higher obtaining xcp not really the price, even going 0.1 to 1 is like the swing of bitcoin fees on any given day
-
i think we should propose a way to have a buy to burn system to avoid having to make users to acquire xcp
-
also very usefull for whole xcp ecosystem in my opinion...
-
is possible to have it in the minting platform but if there is a way intrinsic in the protocol i see it the best option IMO
-
We still haven’t determined if they are actually spam. Yesterdays progress made me believe the ‘spam’ is just src721 transactions, which are valid. I believe the misuse of the protocol is due to poor user experience and poor documentation. Some times in business you do not need to fix the product, but fix the customer instead. The good aspects of Stamps, BTNS and 721 should all be merged into the cp protocol, IMO. They all are nothing new, mostly marketing and hype.
-
Spam is a state of mind
-
I don’t think we’ll ever agree on what is or isn’t spam
-
Adding xcp to numerics simply puts them on the same playing field as named assets and subassets
-
Especially if we can’t have the conversation
-
Aren’t we having it?
-
To a degree.
-
It’s certainly not a new discussion and pre-dates stamps
-
Would be curious to get @teysol take on why numerics were added in the first place
-
From what I remember it was a response to colored coins
-
in Lukes mind a 45 char op return is spam but he puts multiple op returns totalling >45 chars in a coinbase 😂 -
Numerics preventing any assets that start with A is not a good feature.
-
Create a class of human-unreadable asset names, whose registration is free. · Issue #372 · CounterpartyXCP/counterparty-lib
That is, allow for both alphabetic and numeric (e.g.) asset names, and only have a fee for the former. How to make this backwards compatible is not obvious---the database won't have to change, ...
-
Historical info on why/when numerics were added to CP
-
Interesting I can’t find the why
-
Here it is
-
-
“It would make Counterparty more competitive with novel use-cases, and outpace cryptos with cheaper issuance fees than 0.5xcp, as well as increase volume probably.”
-
was in the truth it increased the volume and reduce friction
-
bible verses are not spam I guess 🤷️️️️️️🙄️️️️️️
-
Which intuitively makes sense
-
the multiple op returns are in recent Ocean blocks and they add up to more than the 42 chars he wishes to impose on non miners, plus his historical use of bible make his rules on spam totally incomprehensible
-
Spam usually just equals “things I don’t like”
-
as you said .. it's a state of mind. If the btc and required xcp fees have been paid the tx is valid
-
yeah whole coins were free to send
-
you only paid fees on <1.0 btc txs
-
so in theory and with classic send you could have made cp txs for free
-
Why do you know is not realistic? What are your arguments?
-
Realistically the named asset amount should be raised to be in line with btc price growth from the time of implementation. Then the numerics to match. While changes are being made at that level anyway. Perhaps 2-5 xcp is a better range
-
This is a good analogy
-
Would make more sense to have it inline with XCP price growth, the bigger risk is “running out” of XCP as it’s a deflationary asset
-
Oh so we have one fork
https://github.com/jdogresorg/counterparty-lib/releases/tag/v9.62.0 -
Joe, you have your fork ready?
-
I think we can get at least 3 to the table. Stamps would prefer to follow the core counterparty bits ofc. Jdog can go off on his own adventure
-
I would prefer no fork, it devalues all assets
-
so a db engine problem with a poor php script will fork the protocol
-
good to see how 163 devs will allow this to happen
-
That’s Jdog’s personal repo
-
Not Counterpartyxcp repo
-
bc is not the oficial xcp repo
-
That’s his fork on his personal repo. Not the core cp bits.
-
Can call it jdogparty of one
-
Presumably that’s for xchain
-
Only
-
haven't dropped numeric support from xchain/freewallet yet... will do so on monday... but at least the xchain API spamming is cut off... 6+ million blocked API requests after I enabled rate limiting today 🤷️️️️️️
-
-
Jdog stepped down as maintainer
-
You got me @shannoncode and @jp_janssen
-
you can tell everything, this 5 million requests are bc they were retrying bc they were blocked
-
Blocked people that were authorized to use it nonetheless. Cute
-
and the usage at least in my side was consulted before with you and after your autorization
-
I’m not merging anything without some type of consensus
-
so please dont tell and show just the part of the story you want
-
Let him fork first then we merge it later with a slightly lower fee and new features to improve db performance
-
indeed... @XJA77 admittted it was him and the rarestamps team behind the 6+ million blocked API requests... and as you can see, the failed API requests stopped after he turned off his xchain API scraping scripts... much appreciated 🙂
-
was not scrapping was calling to the api you have in your website
-
He did create fork.off token for a reason
-
and insist after your autorization
-
This is true
-
correct... I never said dont scrape my APIs... I wasn't aware how hard you were beating on them... but again, that is on me for not enabling rate-limiting earlier.. not your fault at all... now rate-limiting is enabled, and seeing much lower usage across all my servers 🙂
-
Nice way to give a heads up.. We were really on your side. Happy to do fees and look at other creative things to grow together, improve things for everyone db wise, and you’re the one that forks off and randomly cuts people off from their projects with no notice? Weak sauce.
-
I’m happy to vote in xcp
-
yes i told you ser, i can look for the conv if is what you want but i told you the exact process and the exact timing between calls
-
me to.. my 1% of XCP will be voting for XCP fee 👍️️️️️️
-
Prior I was pro implementing fee. Now it seems pointless if jdog is off worrying about his own fork
-
measuring dicks again
-
I’ve been a proponent of fees since day one
-
You just have another agenda
-
Weve never voted on changes to counterparty-lib and I don’t intend to set a new precedent
-
was looking to fork since day one this start becoming popular is clear and he demonstrate with FORK.OFF
-
very funny to see how BTNS is good for Counterparty and is not considered spam but any other thing that is not signed by him is spam
-
It’s pretty clear to me that jdog is sick of stamps leveraging the infrastructure he provides for free, I don’t blame him even if I would probly handle things differently
-
We’ve needed more counterparty block explorers for years
-
The fee is great. it drives everyone to minting services that create less friction and provide dev funds for the maintainers.
-
Everyone just lazy cause xchain works well enough
-
a very small percentage of XCP... Last time a vote with XCP was taken was for the XCP foundation election in 2019... At that time, a total of 107,389 votes were cast.
https://counterparty.io/news/announcing-the-names-of-the-2019-counterparty-foundation-community-directors/Announcing the names of the 2019 Counterparty Foundation Community Directors | CounterpartyOn July 1st 2019, we announced the start of the Counterparty Foundation blockchain-based election for five Community Director seats, that will officially represent the Counterparty project, help shape its direction and ensure an active and transparent leadership. During the two-week voting period, a total of 107,389 votes were given to seven community director candidates via
-
yes but this is not the way to do it, if you think things if we have to been rushing things to get stamps up we cannot start contributting with counterparty bc we have to work in keep things up
-
The only reason I didn’t make the explorer for all of cp was because I was pushed too fast into forking off into the src protocol. And now circling back to share that knowledge to all of cp
-
That is far from lazy ser
-
and has been like this since the begining
-
Why we added named stamp support
-
Could easily do like xcp.ninja and spread the infrastructure costs. I’m spending $3k/mo personally for infra for cp anyway
-
We will stay with the core counterparty
-
Not some fork from an angry dev that can’t play ball
-
It is what it is, I don’t control xchain
-
lets add a explorer app to the repo, remove the sqlite db add mysql and xchain is not needed anymore
-
Totally for it and a reasonable discussion around it with proper timing thought and implementation
-
Realistically it doesn’t solve anything
-
We can spend time scrambling to support the ecosystem without xchain
-
just add friction and possible loose of users
-
Or we can do core dev work to improve the db
-
I wasn’t talking to you specifically, just everyone in general that relies on xchain
-
Which helps everyone and I already did on a cp fork
-
Yeah, can fuck up the entire cp project.
-
he can also do xchain opensource and im pretty sure that more explorers arises
-
The api open source that is
-
but what happend if that happend? that he loose the control
-
There was a time when blockscan (the precursor to etherscan) was the only counterparty block explorer
-
Then jdog built counterpartychain and thankfully he did because very shortly after that blockscan shut down
-
Was then renamed xchain and fast forward to now
-
He could at least let someone build a replacement before he disappears into btns land
-
There is xcp.dev and memepool.wtf but they are incomplete
-
xcp.dev is the only one opensource
-
I can plan to open source memepool in the next week
-
Just want to clean up some things first
- 07 January 2024 (187 messages)
-
Anyone wanna buy a rarepepe?
-
Me too
-
His message said 1 month
-
I don’t like ultimatums either but it certainly forces the conversation
-
Activation block doesn't says the same
-
You’d have to ask him then
-
That’s hilarious, and support a fork of the core and contribute to a maintaner of an explorer that will censor those he previously ok’d to access the data? Who also create a private api to control the cp data integrating with wallets and other services connecting to counterparty? Who also maintains a private collection of images to represent the tokens offchain that isn’t part of CP or easily accessed by the community?
-
Implying the price is about to dive
-
Only if there are competing forks
-
I guess you’re forks pricing will stay solid at least
-
Who is being rugged is the question
-
if you are not dev you can just silence in a dev chat
-
Sure it’s a concern to all cp asset holders getting rugged
Official Counterparty Dev Chat
Public archive of Telegram messages.
- 04 Jan 2024 (22)
- 05 Jan 2024 (767)
- 06 Jan 2024 (182)
- 07 Jan 2024 (187)
- 08 Jan 2024 (348)
- 09 Jan 2024 (29)
- 10 Jan 2024 (246)
- 11 Jan 2024 (59)
- 12 Jan 2024 (15)
- 13 Jan 2024 (93)
- 14 Jan 2024 (22)
- 15 Jan 2024 (17)
- 16 Jan 2024 (2)
- 17 Jan 2024 (4)
- 18 Jan 2024 (5)
- 19 Jan 2024 (148)
- 21 Jan 2024 (1)
- 22 Jan 2024 (41)
- 23 Jan 2024 (20)
- 24 Jan 2024 (4)
- 25 Jan 2024 (5)
- 26 Jan 2024 (31)
- 27 Jan 2024 (20)
- 28 Jan 2024 (1)
- 29 Jan 2024 (3)
- 31 Jan 2024 (2)