Where can a dev find testnet XCP?

Burn some tBTC

There’s a thought

But where? Searching the surface web brings links to broken counterparty forums. Jpjanssen selling any?

This. The burn command continues to work for testnet

the testnet burn address seems to be

mvCounterpartyXXXXXXXXXXXXXXW24Hef

I can't find it in the docs so I found it using xchain testnet

https://counterparty.io/docs/cli/ returns

Can't find/load data at path: /var/www/virtual/counterparty.io-docs-html/UI/CLI.md.html

Thank you very much friend.

in freewallet switch to testnet (Settings->Network->Testnet)... then you should be able to do a burn (Menu->Burn Funds)

https://i.gyazo.com/005c2af4817cbe8aa2581550ee8e7448.png

use docs.counterparty.io for documentation... new counterparty.io website updates coming soon-ish

Links to counterpartytalk.org don't work? No redirects after domain change?

good catch... i'll setup redirects later today.. thanks for noticing JP 🙂

redirects should be working now... if you find anything else not working, pls let me know... thx 🙂

gm, just noticed this

Hey hey is now we can make interactive assets? I just look at pepepuzzle

Hello everyone, xcp.dev has been updated! All the data is direct from the Counterparty SQLite tables, and you can see how everything works as both the frontend and backend are open source.

Would really appreciate the feedback from anyone, but more specifically from developers

yes... use docs.counterparty.io .... the counterparty.io site is old and breaking... working on an updated site design... should launch in another few weeks when I find time to finish it

some feedback I have is be careful running your data from the sqlite CP tables.... its fine for now while your site has no traffic really, but your site will have issues scaling up to meet larger demands if your querying the sqlite tables directly (CP tables have no address/asset/transaction indexes... so lookups result in full-text table scans to match text versus using an index and a quick id# reference)... Overall nice work tho... good to see another explorer in the works 👍

Thx man will try in use))

Eventually, Javier and I would like to migrate the internal CP database from sqlite to mysql, and buidl out indexes for addresses/assets/transactions... but its a big undertaking that will require a bunch of testing... so prolly a ways out... until then, if you need to get your CP data into a faster / indexed database... you might want to check out https://github.com/jdogresorg/counterparty2mysql ..... its what powers the xchain backend database

https://i.gyazo.com/9363e4b8ed987acf9c0812a729580943.png

Yeah... so converting MyISAM tables to InnoDB should TOTALLY take 13+ hours to process a single table... 🙄

Crazy I can import all the data using MyISAM engine fine, takes about 5-10 minutes to import the database... versus many hours importing to innodb... I thought maybe importing to myIsam and then converting to innoDB might be faster... still no joy.... Thinking I might just stick with MyISAM tables for now.

</end triggered textwall> 😛

Thanks for your feedback. The open source repo is focused on allowing anyone to make their own explorer instance after they setup their fednode, it is not a production setup.

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

As scaling is needed the infra needs to evolve. Like any other web app, there is no one size fits all.

The current xcp.dev backend already has some of these optimizations which are not in the repo. But, the goal is to always have a simple backend in the repo that can provide all of the frontend’s functionality. And this simple backend is what I actually use while developing, just like any other developer would and to avoid mismatches of functionality with the production deployment

It is unfortunate to have Counterparty docs down, ideally these should be up until the new website can fully replace them. And I would like to give my input on moving away from SQLite, is there already a post somewhere about this?

This has been fixed... it was an issue with migrating the counterparty.io to a new server and not copying over some doc directories... all docs on counterparty.io should work again now (was only down for a few days)... the preferred documentation site is docs.counterparty.io, and the new counterparty.io site will just point the "documentation" link to docs.counterparty.io

I dont think this has been formally documented anywhere... just in various CP chats over the past few years... longer-term, full-text searches on a sql database are slow and not going to scale... its fine for a few million records we have now.. but when we are talking 100 million+ records, doing a fulltext search is unacceptable... at the very least, the CP database has to be updated to index addresses / assets / transactions... it would shrink the database size and make queries faster... the mysql database migration is not absolutely necessary, but getting away from full table scan searches which sqlite requires in most lookups, is definitely something we need IMO

its not something that is urgent, so hasnt really been a priority... what we have now works for now... if you want to create a post on counterpartytalk.org about this topic, feel free 🙂

SQLite with appropriate indexes should work fine. Based on what I have learned from Counterparty, all tables should have indexes for: tx_index, tx_hash, block, address and asset. And there could be some others like for asset longnames in the assets table. I’m not sure what you mean by fulltext, as indexing the asset names is always a single string.

The cool thing about SQLite is that it is a file based DB, no need for a server. But maybe issues could arise if this file is too big? Would need to investigate that…

probly best to write some unit tests and clock performance

Im still curious why the design choice of making the tables so denormalized. Because the goal could also be high normalization, and then that delegates performance to the application layer

what I mean by full-text search is that when you search for an asset, sqlite searches every record in the table for asset="ASSETNAME" using a text match.... and the name ASSETNAME is used anytime the asset is referenced.... versus having ONE table which lists all assets and gives it a unique ID, and then use that unique integer in tables to reference the asset name.... same for addresses and transactions... right now the same address / asset / transaction hash are written to the sqlite database tables MANY times over instead of just once.... end result is a.) database bloat and b.) indexes which are much larger than they need to be, and are slow-ish because they require full-table-scan searches.

"de-normalizing"... howso... with the adding indexes for addresses/assets/transactions... we simply write the address "abc123addresshere" ONE time to the database, and then for all references we simply write 123456... much more efficent data storage AND faster searches.

Single file DB’s are rough on the hardware and file system level. Easy to corrupt. SQLite is more for an embedded system or toy. https://www.sqlite.org/howtocorrupt.html

A long form post about the database design of Counterparty would better explain, as I see conflicting responses and don’t feel like arguing 😉

Talking about performance needs to specify which aspect of the protocol. At the moment, the api part of the protocol is VERY inefficient. And is an argument to refocus the core lib into what it should do best, which I believe is the integrity of the data. (And I also believe having the smallest footprint on the Bitcoin blockchain is essential.)

As long as the protocol is block by block verifying the integrity of the data, there should be no problem at all with a file based DB. Any database technology can loose integrity with bad design, and highly denormalized tables have more surface area for issues.

Which brings me to a question, are there documented instances where the Counterparty data has lost integrity?

I’m asking because I have some findings, and want to know if this is a known problem or not…

Anyway, I made some GitHub posts. But this is the main one I would appreciate your participation:

https://github.com/CounterpartyXCP/cips/issues/66

A new CIP draft. Compressed XCP transactions.
https://jpjanssen.com/compressed-xcp-transactions/

Cool concept! If something like this was going to be done, I would take the opportunity to “refresh” (improve/fix) many other parts of the protocol. Like a reboot of the protocol

Your writing style is great. Your ideas are too.

love this .. closing and re opening dispensers in a single tx allows the end user to change the dispenser price in a single tx .. brilliant .. have seen people ask if this is possible

awesome, JP J ✌️

Group, I don’t feel good when I have to continue being critical on the changes done to the protocol stack.

But now I’m finding that the ‘base’ fednode installation is including the xcp-proxy which requires redis…

Isn’t the ‘base’ installation be the minimal requirements to get a Counterparty node running? Why was this change done without a CIP??

And something called ‘http-addrindexrs’ was added to all installation types (including base)

Why? Where is an open discussion about this where multiple developers can give their input?

xcp-proxy (https://github.com/CounterpartyXCP/xcp-proxy) has been a part of the fednode stack for years, the only difference is now that it is moved from the a FULL node install (which requires counterblock, counterwallet, and other components) to the BASE fednode stack.... it is a component which allows users to get real-time communication of XCP transactions via websockets.

http-addrindexrs (https://github.com/CounterpartyXCP/http-addrindexrs) is simply a proxy which allows for users to make requests directly to addrindexrs to get UTXO and balance info for addresses (something we had with indexd, but lost when we switched to addrindexrs)... and this piece of software has been running in dogeparty dogenode stack for over a year with no issues.

Previous to the addition of http-addrindexrs, requests to get BTC balance information needed to come from a 3rd party or service, with the addition of http-addrindexrs, users can rely entirely on the fednode base install to get any and all information on their bitcoin and xcp balances, history, etc.

Both of these are simple javascript scripts which handle allowing users to query information directly from counterparty, do not add any additional load to the servers, and should be included in the "BASE" install.

AGAIN I say to you Juan, not every change requires a CIP or a lengthy discussion.... If you feel that adding some small javascripts to the base fednode install which provide additional functionality is an issue, then please feel free to explain here why you have an issue with these updates.

btcdraks addrindex was discontinued after version 0.13.2 way back in 2017 so something had to be used in its place

yeah... and we used indexd for a time.. and were able to query it directly for BTC balances and UTXO info... but, it was inefficient and always hanging... so John n I switched to using addrindexrs, which works much better, but had no public facing way for ppl to query balances.... http-addrindexrs returns that functioanlity... so that xchain and others who use fednodes can query BTC balances internally without needing to rely on another service like blockstream.info, etc.

not needing 3rd party for utxo data is essential to being a full peer o the network

IMO one should not have to run a full fednode stack (counterblock, counterwallet, etc) just to be able to get BTC balance info or to get real-time websocket tx notifications... and the footprint / demand for these scripts is minimal.. so yep, added them to the fednode base install.... not opposed to creating yet another 'mode' for fednode, but would need to hear a good reason why these services should not be included in the base install.

Jeremy, aside from the technical details for the reason for these changes,

Why are you making those decisions without involving other developers input?

Had Draks addrindex not been discontinued maybe it would still be in use .who knows eh .. I liked that fork of core

Again, not every change requires a bunch of discussion.... I decided the base install should include these compoenets... it was not a protocol change or anyhting that effected anything other than the base fednode.

Base fednode seemed to be the minimal installation for a Counterparty node

Why is it you feel that every code change requires extensive review and discussion? Even simple changes like updating to the latest version of bitcoin core, something we have done since Counterparty launched, is met with resistance from you and you demanding that I justify every change to you.

and it still is, the only addition is 2 small javascripts that proxy requests to addrinderxs and counterparty... so again I say to you, what is your objection to these components being added to the base install?

yeah, he maintained the addrindexrs patch for CP for a really long time... but alas, it became too much of a pain to maintain the list of code changes in bitcoin-core and addrindexr updates.... He def deserves credit for all his work tho... served CP well for quite a few years

It is not a minimal installation any more.

And you say two lines. I don’t see 2 lines in the fednode repo.

I’m not going to fight you. But you are pushing out developers like me that are contributing and wanted to keep using the same stack. I’m feel like I have no other choice but to fork the repositories…

I said 2 small javascripts, which I have linked before, feel free to review xcp-proxy and http-addrinderxs and you will see they are minimal pieces of javascript which simply proxy requests to addrindexrs and counterparty.... what would you propose then? we create an entirely new "mode" in fednode stack simply to run 2 proxy services?

I am sorry that you feel me making improvements to the fednode stack, and asking you what your objections to those improvements are, are taken as me pushing developers away.

Yes, I think it should have been an new mode to keep base as the absolute minimal installation

As far as forking the repo, I am sorry that you feel that you have to once again make that threat, I thought we had moved past that when you tried to rally people behind your fork and staying on 9.59.6.... in fact, you even came back in here, said you saw the error of your ways, and wanted to participate in a meaningful way.... what has changed? I have answered any questions you have had and asked for your objections to my changes.... but rather than reply, you decide to threaten a fork again. This is tiresome Juan.

But my main problem is with how you feel like you are the all powerful Counterparty decision maker.

Tiresome to have developers raising concerns. Great leadership Jeremy’s

Fork the repo

Is not forking the consensus

To be clear, I mean forking code, not the protocol

I made clear that this was a heat of the moment reaction. And it was based on being misled by people here about the effects of the upgrade.

I continue running a (read only) v9.59 node which MOST transactions are still valid. So, obligating everyone to update is actually inaccurate.

And what is causing most of the invalid transactions was the change in the issuance format for which a CIP was never done

I am sorry that you feel that way. I do not feel I am some all powerful counterparty decision maker. I am simply a developer who loves counterparty and continues to make improvements to it and services around it. I am sorry if some of those improvements do not meet with your personal approval because they have not been debated at length. I do discuss all changes with other Counterparty developers (every change is discussed with Javier). Any changes to the Counterparty protocol (counterparty-lib) are done through the CIP process, which has a clearly defined process for taking things from idea to protocol changes.

However, Not every change requires a CIP, as I have mentioned many times. Protocol changes certainly require a CIP, but minor improvements, bugfixes, updates, etc... none of those require CIPs, which includes this minor fednode stack. This is why we have the CP General fund, to fund general improvements and bugfixes without having to go throught he CIP process for every single update.

Also, to clarify, my "tiresome" comment was in regards to you questioning every change I have made for months, threatening forks, advocating for a fork in the CP channel, making personal attacks on me, then returning back into the CP dev fold saying you will contribute in a meaningfull way and your sorry, only to pretty quickly again go back to attacking every change, and once again here we are with you threatening a fork.... THAT is tiresome Juan, not answering questions from other curious developers.

Disagreements is not attacking, is just another developer with his input for the benefit of the project.

It is clear that we have very different approaches lol

I’m thinking it is actually good to have different implementations of the protocol stack. For now, I’m going to focus on the fednode, while continue using github.com/CounterpartyXCP/counterparty-lib

In xcp.dev I’m focusing a lot on having the hashes front and center so everything is easily verifiable.

The reason I looked at the fednode was because I’m actually finding inconsistencies in the hashes. And wanted to setup a new no-bootstrap v9.60.1 node. Because even though it is not supposed to be a protocol changing update, why at the hashes not matching?

@pataegrillo can you please explain to Juan AGAIN (even tho you have here in chat and in a github issue earlier this week) why the tx hashes between 9.59.6 and 9.60.1 do not match after a certain block? It would be much appreciated 🙂

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

? It has never been about v9.59

I’m talking about v9.60 in xcp.dev vs what i see in xchain

It’s about this. But the new discovery is that now the last matching hash is even earlier. Now is block 765104

Hrm.... i'll have to look into it when I get some time... the current xchain database is one that has been parsed in over the years... I plan to do a rull reparse to build the counterparty2mysql database from scratch in the coming week, will check the block hashes at that time and if they are not matching in the new full-parse version, will figure out why and fix.

https://i.gyazo.com/11c7d993d1dfe12f619463ae82e335ff.png

I just checked the most recent block on xchain... and pulled the block data directly from the CP API.... xchain matches the CP API.

From what I am seeing, I am seeing no difference between the ledger/tx/message hashes that CP shows and the hashes that xchain shows.

At least for the most recent blocks... there may be some difference in the past, cant speak to why... but a full re-parse of the CP data into mysql via counterparty2mysql should rebuild the database with all the correct hashes (if there are any incorrect ones)

You two should fight or fuck.

😂

It seems as if Juan is just here to cause issues, troll and waste the time of our valuable developers? Why are u here ser? J Dog has been more than kind to you and you continue with your bullshit? At this point Juan should just be removed from here.

I oppose banning of anyone seeking to work with Counterparty development and I oppose censorship of technical discussions.

Juan raises "I’m talking about v9.60 in xcp.dev vs what i see in xchain"

He's seeing a disparity in on-chain data on the same version of CP.

As to the manner of making those discussions productive versus wasting time, or even vexatious for participants, that is a matter for consideration.

I'm going to have a catch-up call with Tatiana tomorrow, will be the first time since HNFT.

She offered to support the coordination of Counterparty community discussions.

There has to be a way these matters can be discussed and understood for the benefit of the community as a whole.

There were 20 people in a conversation about these various issues at HNFT.

It's not merely a question of style and tone and whether someone is "BS" (this *can be* subjective), it's about providing a community framework that can sustain Counterparty development long into the future.

I was glad to see @uanbtc recently shifting to 9.60 at least for his xcp.dev efforts and I am also glad he has posted comments on github as per @jdogresorg requests for best method of logging issues.

Censorship and banning is never the answer to these kinds of challenges.

Sorry this was meant to be in reply to @pappyG45

Thank you for this Bradley

You and everyone who is genuinely interested in furtherance of Counterparty as a decentralised asset protocol are entitled to have the ability to communicate in a transparent rules-based community forum for discussion and determination of protocol governance and technical development directions.

How we ensure that happens has recently been called into question and I see it as an open question that requires resolution.

I could move this broader discussion to Counterparty Official, but I'm not currently in a position to engage at the level that the matter deserves.

Knowing there are people with various biases that will come into play and I am not able to moderate or mediate those biases, I will refrain from that at this time.

I believe Tatiana to be someone who is most widely respected in the community and thus I wish to endorse and support her volunteering to act in this kind of communication coordination role at least in 2023.

It was the general consensus of 20 or 21 people on October 30th.

A discussion paper needs to be drafted and tabled for people to review and discuss.

Perhaps https://forums.counterparty.io/ is the best venue for that.

I don’t see Juan participate in anything xcp related except trolling J Dawg and wasting his time. Seems to just constantly threaten forks etc…. If it’s not productive dialogue it just makes our lead developer constantly in defense mode from the smears. I’ve had enough of this clown so he’s been banned from my groups.

There's an old saying, "If you are lucky, you'll have a very difficult person in your life. Thank them. They are your teacher."

I don't see much trolling going on, mostly just a lot of busy but well meaning people who are unwilling or unable to engage in a meaningful way. This is not new. Governance is the single most important issue facing Counterparty IMO.

hey @uanbtc please share your addy so we can see how much skin in the game you actually have with XCP

Xcp is a huge threat to fiat bros & meth heads. We shouldn’t be so naive to think they wouldnt employ paid agitators. We should more aware of intent & continued malice vs are they actually providing constructive feedback.

I used to think Juan was actually helping the eco system but his pattern of precise attacks and personal vendettas are obvious now

Everyone has good points and valid feelings. I am very impressed with the official and unofficial devs in the XCP community for their coding abilities, creativity and their self control. Take a breather and a walk. The internet will be here when you get back. Enjoy your weekend.

@pappyG45 search for the owner of BITSTART and CNTRPRTY

I’m the builder of bitST.ART and cntrprty.org

If building software for the ecosystem, open source by the way, is not participating for you, then we see things very differently.

You realize you are in de Dev chat?

Read my messages here and in GitHub. I participate in my domain. I don’t make memes, or collect much. I’m building the foundation to be able to do my own issuances from my own node. Which I haven’t been able to do in months since the fucked up centrally controlled v9.60 release.

Don’t trust verify. I’m a bitcoiner. Do you have your own node?

Counterparty is Bitcoin for me. You will never see me in the Dogecoin chats. And I’m not very interested in conspiracies. I find them interesting though, as most have become obviously truth with time.

Bitcoiners tend to be the truth seekers. And identify with that.

I understand where you are coming from though. Jeremy is the code leader for almost all community members (which are not developers). I’m a developer. And I will speak my truth in my domain.

Have a nice weekend.

So you are all about open source and decentralization but wont share your addy? Got it

For your convenience:

xcp.dev/asset/BITSTART

xcp.dev/asset/CNTRPRTY

xcp.dev/address/1DKFxLas8FpCT7RL47tQxMaLuYhqHzLHMS

7 assets??? Last activity 5 months ago??? Lolol my guess is you r probably some shitcoiner who makes some side money from eth foundation as an agitator. Gonna call you the Craig Wright of counterparty 🤣🤣🤣

Are you serious??? Do you have 1 “addy” with all your assets?

Why do you continue fighting and insulting. What have I done to you?

Look in a mirror man

I’m just here to call you out on your bullshit. That’s all

🤡

I wish peace and love to everyone. And I’m sorry the reaction my messages cause. Truly. Is not my intention, I am just one developer speaking his opinion.

I’ll try to de-escalate with my responses. But I will also defend myself

An Open Source project is not the same as a liberal democracy. Registering typo domains, githubs and assets while pushing division is not part of the community. Your .dev site has no links to official xcp websites or documentation. Wether your intentions are pure or not remains to be seen but your actions are speaking volumes.

Correct he isn’t fooling anyone with his kumbaya bullshit and I take pride in calling out clowns. Juan CSW is on notice

Wow. Ok. Now I’m the bad guy because I’m calling out on the centralization of the project.

I’m leaving this group, I have no interest in feeding your misconceptions and misrepresentation of me.

But I’ll continue working on CNTRPRTY messages in Bitcoin.

I made another chat, anyone is free to join if they are interested. t.me/xcpdev

again you and your failed forks…. lmao this trash should be removed

😡

lol - y'all should rename this chat "OFFICIAL" before Juan starts claiming to be the (de)centralized leader of XCP

this is key - xcp should always refer back to xcp projects/docs, not to nothing, imo

heavy is the head that wears the crown

have been thinking about how dispensers could be upgraded to facilitate the creation of a sort of “opensea” of counterparty

https://forums.counterparty.io/t/cip21-dispensers/5488/10?u=loon3

Looks good to me... I replied and added a couple additional features i've been thinking about for dispensers as well 🙂

Great suggestions. Will add some comments when back from holiday. Riding the CP Express this week

(Allowable address) + (a running tally of all payments received from any address) until paid in full = a dispenser that would essentially be a loan, anyone can payoff or you could pay from multiple addresses. Better make sure that send to address is correct though. It would be bad if someone canceled the dispenser after making payments.

What are dispensers most reliant on to function? Where in the lib is a dispensers ‘send asset’ transaction encoded and sent to the network?

lol incredible, holiday in the metaverse

or a subscription service

FYI... @jp_janssen pointed out that our sweep XCP anti-spam fee is hardcoded at 0.5 XCP and not dynamic as it should be.... here is an issue I created to adjust sweeps to dynamic fee... feel free to weigh in with your thoughts. https://github.com/CounterpartyXCP/counterparty-lib/issues/1220

How does this fee scale? - dynamic XCP anti-spam fee on dividends

it is based on the number of recipients in the dividend.... similarly, sweeps fee would be based on the number of balances and issuances in the sweep.

Oof I better sweep my address to ledger soon then

not talking about making it cost a ton to move a few thousand assets... more about preventing someone from abusing the system by penalizing them the larger the sweep is.. a few thousand no biggie... 10K, yeah.. your gonna pay a higher fee than 0.5 XCP

but, up to us what that forumla is... so, if you have any suggestions, feel free to weigh in 🙂

Yeah I hear ya, makes sense

👋♥️