Periwig with the tg development chats going fairly quiet lately, and you are a good voice for the project, do you have any development updates to share? I have been following along reading the github notices, actions and updates; instead of trying to manually install a node again, until we land on a more mature version.
Can you share any comments about the sentry telemetry and how ingrained that function will be? Telematics are very understandable for a development team testing a development branch but telematics introduce big privacy concerns for me in a production scenario.
Thanks.
- 02 May 2024 (15 messages)
-
-
Do you know if any of these will be protocol changes? Is not super clear to me by looking at that list…
Also, will there be a v10.2?
In general, I would like to learn which of the planned updates will be the first to include protocol changes… -
Thanks! And yeah I know about v10.1.2, but I meant v10.2.
-
Was thinking that if the planned v11 still does not contain protocol changes, then we could keep it at major version 10?
But I could also understand the major bump because of the integration of addressindrs into the core codebase… -
Man I still would like to learn what was the purpose and use case of the callable fields…
-
Me too!
What we are witnessing is truly amazing work.
I want to apologize for my tone sometimes… is just baggage from how things used to be 😭.
And I still believe is positive to have a different perspective. My approach now is less talk and more code lol. I’m working on the CNTRPRTY counterparty-core repo fork that will show this perspective. - 04 May 2024 (8 messages)
-
To be able to return all supply to the asset owner, and give out some other token in its place…. Cp never really used it much n it got disabled pretty fast…. I wanted to bring callbacks back… so I did so with BTNS… I think ppl need more options not less👍🏻
https://i.gyazo.com/84ff27ee1ab76e261038fbdb53fcf733.png -
Thanks that is interesting, what is this link? Would like to study further to fully get it…
-
Still in development…. I’m in the Bahamas next week for my birthday… I plan to wrap up and release a new version of the BNS indexer next week…. Codes written and working, just haven’t written out all the explorer API’s and stuff yet for me to feel comfortable releasing it….
TLDR 2 weeks -
Broadcast-Token-Naming-System/indexer at btns420-indexer · jdogresorg/Broadcast-Token-Naming-System
Broadcast Token Naming System (BTNS) specs, docs, and tools - jdogresorg/Broadcast-Token-Naming-System
-
That’s the repo and specific branch where development is taking place…. Once I’m comfortable that the features/ledger is stable and tested then I merge it back up into master and put out a indexer release.
-
And now I’ll shut up about BTNS stuff… since this is a counterpart channel… but wanted to answer your question about the purpose of callbacks and point you to some Code to play with if you wanted🤷🏻♂️👍🏻
-
Much appreciated!
- 05 May 2024 (7 messages)
- 06 May 2024 (57 messages)
-
Do you know some that doesn't ask for a fee? -
So what do they need to list then? -
Agreements with who
-
And who
-
I’m curious who the person is on the other end of this agreement
-
Exchanges in agreement with….
-
Assigned by who, make decisions about what
-
My guess is they need market makers
-
To make it worth listing
-
Market makers aren’t assigned that responsibility by anyone tho
-
Lol market makers aren’t spoofing by definition, maybe some do
-
Xcp is not a person
-
It doesn’t have needs and wants
-
Lol im not sure what you’re even asking for
-
I want to speak to the CEO of Counterparty -
No.
-
I don’t even consider myself that. I don’t have unilateral control over anything. Maybe some influence.
-
If someone came to me and said they could get stamps listed on an exchange if I gave them a bunch of money I’d say thank you but I’m not paying you a dime. Listings happen on their own when there is demand. Otherwise you’re just throwing away money. But even if it did work… what do I get out of it? Spend my money to pump degen bags? LOL
-
Its not even worth it. Coins that are in demand get listed automatically. If you're having to pay to get listed, you're just throwing away money.
-
I never said it was shit. Maybe not what the market has wanted. A lot of the time it comes down to narrative and the technology is irrelevant.
-
You're also discounting all the success Counterparty has had. Success does not begin and end with an exchange listing btw.
-
Monero has no exchange listings because its been a success, ironically
-
and? That doesn't mean it hasn't been a success for those who've been around a decade using it and appreciating it.
-
So what are you looking for then?
-
It will be the role I’m taking :) - 07 May 2024 (20 messages)
-
No one. It’s been down longer than that. I was a user before.
-
Its early for me and reading some counterparty conversations requires great attention to detail. I may have misread your question as counterwallet. Are you talking about a nodes cli?
-
Getting a stable node running period was a big problem before you all came back, so yeah. Same thing pretty much.
-
I can’t think of anyone that’s currently using it
-
Would be cool to have a new cli wallet that’s like the ord wallet where it’s built on top of a bitcoin core wallet
-
So offload some of the heavy lifting to bitcoin core (key management, signing etc)
-
I was afraid of terminal in 2014 lol
- 08 May 2024 (3 messages)
-
ANN: xcp.dev has been updated!
As always, all FOSS and available in https://github.com/CNTRPRTY/xcpdev-genesisGitHub - CNTRPRTY/xcpdev-genesis: Open Counterparty Bitcoin Data Explorer - DIY NodeOpen Counterparty Bitcoin Data Explorer - DIY Node - CNTRPRTY/xcpdev-genesis
- 10 May 2024 (10 messages)
-
The cips repository, including the discussion forum, has been archived.
I would like to share some notes on implementing names beginning with A. Where to post? -
That’s going to be a goldrush 😁
-
Maybe users need to burn 100 XCP to mint an A name
-
should add 3 letter asset names while we’re at it
-
@uanbtc you’re cool
-
May I ask… any reason specifically?? ☺️😆
-
This is messed up! Why remove this when it was specifically added to encourage conversations in the "official" code repository?
It served a SPECIFIC purpose, we should not be having protocol affecting conversations in "informal" chats. These should be documented, and the best place is the repo! -
Too many to list. You’re wise, you ‘get it’ and have good principals, if you need something concrete.
-
Aww thanks!! No need, just was curious if it was for some specific recent action.
- 11 May 2024 (73 messages)
-
j am getting CORS errors and data when I query the rest api ..but the data not useable by my fetch due to the CORS
had hoped to work with api2 but can't with cors and am reverting to api1
how long till api1 is removed ? -
I also notice not all the rest api results are json .. should they not all be same ? eg all json?
-
not json is 'healthz'
cors errors on get balances for address /address/myAddress/balances -
url
api.counterparty.io:1400/addresses/mytestnetaddress/balances -
yeah m addresses are testnet
-
I not wasting btc mainnet to learn I want to uert testnet
-
please fix port 1400 cors
-
sorry I missed a 0.. I am using g correct port
-
CORS missing allow origin .. Response body is not available to scripts
-
makes api2 unusable with 'fetch'
-
ty!
-
ahh
-
I had rpc:rpc@zpi.counterparty.io login credentials but that a no go
where does the 'v2' need to be ? -
I will try with v2 give me a couple mins
-
still getting cors
I didn't need v2 to see the result in a debug window I saw the balances but my script could not access -
yeah its a config tweak I expect
-
🙏
-
Drake mad: Improve kickstart from 3 weeks to 24 hrs. Dispensers work with simple BTC send.
Drake happy: Improve kickstart from 3 weeks to 20 hrs. Break dispensers, add steps, continue calling it dispense.
😂😂😂 -
Too long to be a meme man
-
I thought mine already was lol
-
Mine neither I must accept
-
Sure I don’t understand anything and my messages are totally meaningless.
-
Do the improvements without breaking the (currently) most used way to buy assets: (from a Counterparty wallet) BTC send to an address.
Is really that simple.
Kill the currently flawed dispensers when the users won’t be affected. The better alternative won. -
You don’t understand counterparty users then. Sorry for the frankness.
-
Let’s just agree to disagree, this is going nowhere.
I will wait and see. Hope we can continue in consensus and dev work is not wasted. -
Great example of a problem solved by adding the opreturn label
-
Give counterparty users some credit
-
Most people can understand “as of block XXX, you will only be able to buy assets from dispensers using the dispense function in a counterparty aware wallet”
-
lol I didn’t say anything bad about them!
I do know they use dispensers. A lot. And a breaking change should not be sudden and forced IMO.
Why not have a transition period? Where the first phase adds the alternative “create dispense”, but the old way still works. Then measure usage of the new method.
After the majority of activity is using the new method, deprecate the old way.
This shouldn’t be much of an ask for this case. -
Label only I prefer. Having to add ids that suddenly no longer fit in the op return is unnecessary complexity IMO. And will make multi-dispenser buys more expensive the more dispensers they trigger.
-
Don’t know, maybe use the txindex instead of the txhash may allow that…
Still, no need at all. Just the arc4 CNTRPRTY (or something cooler, cleartext!) should be enough - 12 May 2024 (14 messages)
-
-
opening dispensers on cold wallets is cool .. having to make them hot and then transacting to open a dispenser is a downgrade
-
having to have btc on a address to open a dispenser increase the cost too as you must first load an address with btc and then make a second tx
-
Ord parses and tracks EVERY Bitcoin transaction. They pride themselves in being Bitcoin-native.
We have an equivalence, dispense from a BTC send. A normal Bitcoin transaction gets you Counterparty assets.
It couldn’t be simpler. Reason is the most widely used way to buy Counterparty assets.
But let’s kill it. Because users are secondary to a marginal increase in efficiency.
And the plan is to add UTXO based balances. That won’t have a CNTRPRTY message. AND if we want to “don’t trust, verify”, we will continue require the current non-CNTRPRTY tracking functionality.
I truly think this is the classic engineers over-engineering. To a point of affecting the “business”. (Saying it as an engineer myself, but I’m self aware.)
And have taken the time to understand who the customers are here. -
Using txindex is native to Bitcoin, using addrindexrs is not, can’t really make that comparison
-
There’s a long history in counterparty of using various different dependencies to manage the addrindex
-
Removing the need for that would be huge for the long term sustainability of the protocol itself
-
Addressindrs can still be removed. What you mean is that the planned replacement, currently, is to remove some functionality by replacing it with a hard-coded CSV. Which will simplify the implementation of the replacement.
-
Looking forward to seeing your alternate implementation that removes addrindexrs
-
Ordinals is satoshi tracking based, thus sat-ranges indexing dependent parsing.
Counterparty is address based, thus address indexing dependent parsing. -
I meant the literal piece of software by its name
- 13 May 2024 (2 messages)
-
Is it worth reading through 600 messages in the main counterparty chat to catch up?
-
I find it fun 🤓
- 14 May 2024 (40 messages)
-
@B0BSmith ‘s comments pulled me back in. I’ll keep reading for a bit.
-
Proof of work!
-
Does anyone here known Andreas Antonopoulos? I enjoy his work and wonder about his views on counterparty. He would be a great addition imo.
-
I would say his videos were the top orange pilling for me
-
I think most of us are happy about it. But imo is not about making it centralized
-
Juan gets it. There is a limit to the # of tx’s in a block period. Assuming all tx in a block are cp tx, (mass adoption of counterparty) processing that block before a new block would represent the goal for node performance, after catching the tip of the chain. No more performance required at that point, and I believe that we have reached this point.
It would be best to assume all btc tx are potential cp tx and minimize the bloat associated with flagging a tx as counterparty. I wouldn’t assume otherwise if building the protocol. Shoot for the moon, assume 99% of btc tx become cp tx in a few years. Would the upgraded protocol handle the influx or would we require another protocol change and wallet upgrade at that time? Better integration with btc core is needed, not abusing btc.
Jpj had a great recommendation for compression that could be utilized (at protocol change or better yet at a fork) and be compressed even further, allowing for more data and/or cheaper tx’s with leaner tx’s and more tx’s per block. -
Exactly. Assuming all transactions can be Counterparty transactions is a positive goal.
If we are indexing addresses, then let’s get creative with their use. Not break them… and with it the current most used way to buy assets.
We should be talking about the counterparty-core that parses block in parallel to IBD. Not a separate address indexing, integrated (and embraced… like dispenses do!) at the protocol level.
And no hardcoded trust based data. Full verification, just like Bitcoin.
(“Ord is kicking our asses… and they index ALL bitcoin transactions to the point of sat ranges.”)
My dumb opinion. -
As the conversation matures it sounds like improving addrindexrs makes more sense than abandoning.
-
I’ve always interpreted “removing addressindrs” as not being a separate dependency.
Not replace it with a CSV. -
Does the counterparty node ingest BTC script for any tx types or just op_return? I’m thinking about Op_cat in this reference.
-
p2pkh and p2ms encoding don't use op return
-
p2sh too
-
p2sh mpma 2nd tx has a op return
-
thats not where the message data is tho
-
no o know its tiny
-
and its probly there for the same reason it should be added to dispenses
-
He definitively knows Counterparty well. He talked frequently about it in the Lets Talk Bitcoin show in 2014, when Counterparty was brand new.
The show was hosted by Adam Levine. Maybe he is in the main counterparty chat? -
Good point about the p2, but op_return was just an example for my question.
My question is more like ‘is counterparty aware of the btcscript or just the outcome of the tx?’ -
I’m studying btc script.
-
it had to decode the tx to look to see ... if its p2pkh output does it contain CNTRPRTY prefix.. same for p2sh does it have a message with a prefix ... p2ms same is there a message ?
-
*could* not should
We have been discussing the tradeoffs. -
I have recently seen/learnt how scripts are broken into chunks and a chunk at particular position with particular values can be used to identify what the script is and tgen extract the counterparty message
https://github.com/CounterpartyXCP/counterparty-core/blob/master/counterparty-core/counterpartycore/lib/gettxinfo.pycounterparty-core/counterparty-core/counterpartycore/lib/gettxinfo.py at master · CounterpartyXCP/counterparty-coreCounterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-core development by creating an account on GitHub.
-
it's how the coinb.in wallet works out what type of tx it is signing when you paste in hex to sign .. so seems a reliable way to identify types of inputs and outputs
-
I’ve been studying more of these parts of the codebase recently… still above my pay grade but I want to understand them eventually.
Something I love about this software is the clear separation of concerns 😍 -
Coinb.in shows a path to create a Counterparty TX signer tool .. one that can sign a normal op return or one that can sign p2ms spends or a tx with a p2sh mpma step2
-
there is no p2ms spend signing tool online at this time that I am aware of that would make p2ms broadcasts outputs or non burn key issuances spendable by end users
-
I was looking at how coinb.in builds and signs txs and it's easier to identify the python that's doing the same kind of tx identification
-
Awesome reference! Thanks for sharing
-
- 15 May 2024 (74 messages)
-
I want him pardoned soon after the 2024 election -
Who else here has seen this?
https://github.com/CounterpartyXCP/counterparty-core/issues/1764Eliminate Dependency on AddrIndexRs · Issue #1764 · CounterpartyXCP/counterparty-coreConsensus-Critical Rollback the dispenser_origin_permission_extended protocol change so we can drop get_oldest_tx() TX Creation Replace get_unspend_txouts() with a call to a public API? like Leathe...
-
First I am hearing about removing the dispenser origin functionality. Also first time I am hearing that a 3rd party API is preferred to continuing to use addrindexrs which Counterparty has been using for many years. -
I cant help but think that UTxO based assets would take advantage of, or rely on, something like addrindexrs;
-
Counterparty can't deal with indexing addresses
-
it used to be permissionless private key based access, now its trust me bro csv bootstrap and mempool sanity checks
-
Is this issue nonsense? Can someone else ask to reopen because Adam will ban me from the repo, and I would prefer not to have to make sock accounts 😆
https://github.com/CounterpartyXCP/counterparty-core/issues/1791Hard-coded transactions · Issue #1791 · CounterpartyXCP/counterparty-coreI am reading there is a plan to hard-code dispense transactions, to remove dependencies of the software. We already have a hard-coded list of burns. My question (issue) is, why is this a goal for t...
-
A remedial class on blockchains suggested by a mempool maxi
-
Counterparty never needed to index addresses until recently with the empty address dispenser update, unfortunately because addrindex was included early on for lite wallets like counterwallet to be able to do utxo selection it was misinterpreted that it was necessary for block parsing
-
I member learning g about btcdrak addri dex thanks to Counterparty was no dispensers then
-
This is why ord doesn’t need an addrindex because it uses bitcoind wallet to handle wallet functions
-
It was only there for utxo selection
-
Which is a wallet function not an indexing function
-
So basically to add that dispenser feature a massive dependency was added to counterparty indexing
-
This makes it much harder for people to run nodes across different hardware
-
ord is ord n as its fully prunable I never even given it the time of day
-
Some people just won’t think for themselves. They will just “follow the leader”.
I ask questions. And get threats of banning and that I don’t know what I am talking about.
I’m extremely disappointed (some, my fault as I’ve been fooled more than once). -
Threats and personal attacks are red flags
-
I haven’t seen any threats?
-
See github
-
Link?
-
Unisat has opensourced their swap module source code -
GitHub - brc20-devs/brc20-swap-sequencer-api
Contribute to brc20-devs/brc20-swap-sequencer-api development by creating an account on GitHub.
-
GitHub - brc20-devs/brc20-swap-contract
Contribute to brc20-devs/brc20-swap-contract development by creating an account on GitHub.
-
Yes its for ordinal theory
-
But case uses on utxo
-
Hard-coded transactions · Issue #1791 · CounterpartyXCP/counterparty-core
I am reading there is a plan to hard-code dispense transactions, to remove dependencies of the software. We already have a hard-coded list of burns. My question (issue) is, why is this a goal for t...
-
Lol
-
I mean Juan is positing an open ended philosophical question, specific GitHub issues aren’t really the place for that, and Adam also provided a different venue for that discussion
-
I was going to post on the dispensers issue after it was reopened .. I thought we were making progress, slow progress but progress none the less but someone's Dad something playground
-
Being booted from the repo without any warning was my first BIG red flag.
-
Moved to a discussion:
https://github.com/CounterpartyXCP/Forum/discussions/137Hard-coded transactions · CounterpartyXCP/Forum · Discussion #137Following up on CounterpartyXCP/counterparty-core#1791: My original question: I am reading there is a plan to hard-code dispense transactions, to remove dependencies of the software. We already hav...
-
Blockchains are made of people as much as they are made of digital signatures. Consensus is bloomin hard. If we can't discuss stuff n ask questions then I don't know what to say.
I have not tried to attack counterparty with empty address dispensers I was trying to get the feature to not be downgraded for genuine reasons .. I put time into scripting for dispensers that I now know won't see the light of day, n I was happy to chalk that upto experience n to look to adjust my work flow and even broadcast extra transactions if that's what it takes but seems its not even up for debate -
You got me attention at “It’s made from people!” -
This is a great description of the issue at hand. Relying in a trustees party or several seems like a good way to offload that task. Quicknode for a paid service and mempool.space seem to be reliable solutions no?
-
I can't take credit for that phrase it was Mysterious who I heard say it .. but its very true they are a social as well as a technological phenomena
-
Is really hard to build on top of something that is constantly changing. I thought that choosing the most old would help… how wrong was I 😭
-
yeah I feel that .. its surprising unstable considering the immutability of the underlying blockchain
-
Address indexing, dispensers without headers... kind of funny there was a witch hunt over numerics adding strain.
-
Truly, this is a horrible view for any serious developer. They will now look at 2 csvs of trusted data.
I don’t know how blockchains work… maybe they are right. Because I know I cannot trust a “blockchain”.
That’s why I Bitcoin. Don’t trust, verify. -
It not like you can take your assets to another chain either .. sure they can be wrapped in meth but without proof of work is not a blockchain
-
Well not one operating on nakamoto consensus
-
Trustees…
-
This
-
I said numeric strain was bs from the start and still hold that sentiment.
-
Leaving this dev chat with dedicated genius volunteers, ignoring dev feedback then spending time and donated money on telematics 🤔 ? Blew through telematics budget w errors and by collecting too much data.
Wrong focus. There is probably some private equity, business motive or agency being considered or catered too to justify the changes. Sad really. -
Yep or just run your own instance of mempool or another open source explorer like esplora if you’re going to provide wallet services
-
And the command line wallet that’s been discussed will use bitcoind wallet which manages utxos itself
-
It was a design flaw to include the addrindex patched bitcoind from the start because that came with the assumption that the patch was necessary for parsing / ledger consensus, which it wasn’t until very recently
-
The discussion about old versions vs new versions is very interesting too, the aversion to running an older version of counterparty to validate a csv in a newer version, yes it’s annoying if that’s what you need to do for full validation but (1) full validation is possible and (2) every prior version of counterparty is an essential part of the historical record and without an archive of every prior version that can be parsed up to the activation block of the next version you can’t actually prove the current ledger is historically accurate
-
So really more effort should probably go into having the ability to run EVERY prior version in some sort of archive so that history can be fully preserved
-
I thought all of the old versions were deleted from the github?
-
Joe… I know you.
I don’t want to say what I REALLY want to say. And is not good.
But I’ll just say, you shouldn’t be talking about software design. Let’s leave it there. -
This is why no one wants to have a conversation in here
-
You didn’t address any of my points
-
It is tough to converse
-
I presented reasoning which I think is sound and it’s completely ignored with some vague “I’m not gonna say what I really want to say”
-
I’m pretty sure I’ve talked about them. Even making GitHub posts.
Anything specifically new you want my opinion on? -
Say what you mean, mean what you say.
-
I literally just presented a reasoned argument
-
I can agree with this.
But even better, not even require the extra effort. There is not reason why the one single reference implementation cannot verify the whole thing.
And serious Bitcoin builders will find this appealing. At least for me, the burns csv is already a turnoff. Adding another one (plus depending on external services) are not making it better in Bitcoin terms IMO. -
So you if you can agree it’s possible to validate then it just comes down to your opinion on how it’s done
-
And there’s precedent wrt the burns csv, so it’s not like the protocol is somehow different with another checkpoint that uses one that, again, can be validated with the prior version
-
And the cost benefit is enormous removing the addrindexrs dependency which should result in many more nodes being spun up
-
Ok. I am the bully here.
Asking questions and being involved in the development of an open source project which I run services. And is all FOSS.
The truth here is that some will just go with the “winning narrative”. The founder is back and will get our bags to the moon is a pretty appealing one I must accept.
So I don’t blame people getting uncomfortable with some truth bombs -
Which are not verifying the whole history. Is pointless.
-
“Every time” “nobody”
Narratives. Is fine, I’m used to this being part of the Counterparty culture -
Talking in circles
-
Does v10 still have these usd rate dispensers -
Finding those a pain to work with and hiding them currently
-
The oracle dispensers you mean right? In the explorer I just surface them being oracled, but don’t support them in any other way different to normal ones.
- 16 May 2024 (2 messages)
-
It's just tricky because you could publish an amount of BTC that wouldnt trigger the dispense and the person just loses money
-
I want my time back. Can we switch to PoS?
- 18 May 2024 (1 messages)
-
xcp.dev has been updated one last time for Counterparty v9 (🤞). And closing out with a feature I’ve been waiting to implement for a while… asset “starts with” urls!
https://www.xcp.dev/assets#LOL
Will be showing what has been registered that starts with those letters, so, it is very useful to find what has NOT been registered yet!
Also think this a cool way to show that users have found creative ways to do A assets starting with X:
https://www.xcp.dev/assets#XA
The assets page is also a new top menu item. As it should! Showing prominently who’s been doing name registration inside of Bitcoin since 2014 🔥. - 19 May 2024 (2 messages)
-
Hey, I've posted this in the official Counterparty chat but though to paste it here as well
Hi, I have an issue with the Counterparty API:
I am sending a req to https://api.counterparty.io:4000/api/ with some payload to create a dispenser ("method": "create_dispenser").
The problem is that if I send the exact same payload multiple times, the response is not returned consistently (in the same way).
Sometimes I get it in a response object and sometimes the response is inside another response :)
Is this a known issue and what should I do as next steps? Should I add an issue in the repo (which one)? -
Uhh that's odd - 21 May 2024 (1 messages)
-
Joined. - 24 May 2024 (2 messages)
-
@B0BSmith your comments lately were gold. Were you able to get a Counterparty node installed manually?
-
hey .. I not tried yet .. its on my list for next week
I did reset a asset that had been distributed and subsequently re acquired in the name of science - 25 May 2024 (1 messages)
-
Joined. - 26 May 2024 (3 messages)
-
GM frens. FYI, I was just informed by Adam in DM that I am blocked in the repo
-
Your not the only one who is getting censored.
https://github.com/CounterpartyXCP/counterparty-core/issues/1670#issuecomment-2132398315
Screenshot in case it gets deleted.
https://i.gyazo.com/a17cc574f33c5bab1e48b116cdbd4578.png
"Decentralized"... feelsbadman -
imo i think the points made at 2:17:28 in the recent Jdog interview should be taken very seriously by all devs interested:
https://www.youtube.com/watch?v=gcgsZmo7EJU&t=8248sFascinating interview with JDog Rare Pepe OG artist, OG Dogeparty and Counterparty DevFascinating discussion with JDog, Rare Pepe artist, OG Dogeparty and Counterparty dev, and creator of Xchain.io. In this interview, we discuss his early experience in crypto, including mining dogecoin on day1, finding dogeparty and counterparty, the creation of xchain and freewallet, becoming a developer for counterparty, his OG Rare Pepes and more. Follow Jdog on Twitter: https://x.com/jdogresorg Jdog's Pepe.wtf artist page: https://pepe.wtf/artists/JDog Check out Dankest: https://dankest.llc/ Follow ZeroG on Twitter: https://x.com/g0barry
- 27 May 2024 (2 messages)
-
I will watch the full interview later 🫡 but also with all the respect (not a comment to you @davesta and not even Jdog but more feelings that I have from last months) recently it feels we are forgetting from where we were coming from (for proof, this channel) in terms of open conversations, development (specially), participation and centralization. That doesn't mean we shouldn't be critic, raise concerns and seek to improve in every front, of course.
I don't agree (and I wish I could) on the idea of XCP/counterparty will do good in future for the sake of it, will counterparty assets always have a cultural, historical and sentimental value, for sure, but imo a network without development, participants and economy, die. That's why for me sometimes I've found awkard the resistance to evolve or support new things from part of the community.
Counterparty interest/volume couldn't be lower, except for stamps, before the current scene and the planned changes became a real possibility, we in the majority ignored and some even fudded stamps for being absurd, spam, etc, etc while the truth is they brought to counterparty artists, collectors, volume and what's more important a ton of interest from new developers, platforms and tools.
I am very optimist with the current scene, counterparty development active again and improving as it didn't in years, stamps ecosystem, possibility of opening to the wider ecosystem in bitcoin, etc, so if this message looked bearish it wasn't, it's just monday 🙏☕️ -
It's amazing to see new GitHub users active in discussions, see new developments and the protocol being taken care of.
There was a mention of "survivor syndrome" in the GitHub and to a great extent it is probably true with many people who have been here a while and are resistant to change. For those who keep an eye on the GitHub, every protocol change always has someone who wants it to just stay the way it is. Every change historically has been difficult. No matter who was the maintainer.
With that being said, the existing users only have very limited ways to interact with the protocol. There are very few wallets, very few explorers, very little education sources for even those. I do believe many of these updates (even if I don't agree with the tight specifics with all of them) will encourage more wallets, explorers and users.
I only raise concerns if something may be implemented that breaks the very little resources we have at the moment to use the functions of Counterparty.
I think a lot of this would be different if Counterwallet was live and had it's own references to education and an updated Docs section on the website for the wallet. Changes to highly used protocol features would seem much different to users if that was the case. Especially if other wallet devs simply stop supporting the changes or do not upkeep their software.
To be honest I'm happy that people had the opportunity to express their ideas about the dispenser changes. It was better that circumstance instead of a change happening and users are not aware. From what I am reading a backwards compatible process can be implemented to make both opposing viewpoints happy.
I don't necessarily agree with everything Jdog says and I have my own opinions about certain things... But I think it is very important to hear his story and hear his opinion.
What I dislike at the moment is the removal of CIPs and I will simply bring it up at the appropriate place to discuss it and see how the community at the moment (including all the returning devs) comment and engage with each aspect of the change. I feel it sets a bad tone to abruptly change a historic discussion procedure that feels like the new devs are symbolically saying "community don't worry about it, we got it from here". Alot of people like this project because CIPs sought to be similar to BIPs and encouraged others to engage in creative brainstorming for a better protocol.
At the end of the day I'm a small insignificant piece of the dev sides of things. It's just because I have become so accustomed to helping users with errors, issues and general blockchain guidance that I am weary of very specific changes.
After alot of research and reading I came to realize Counterparty, its corresponding tools, its new and existing user base are all very fragile. And despite name-calling and initial frustration, I know all of us, old and new want Counterparty to become stronger than it has ever been and much less fragile. - 28 May 2024 (4 messages)
-
And now, time for a commercial break.
Anyone have any good memes for this channel? Lighten the mood a little. -
Not a meme, but some good news!
https://next.xcp.dev
The v10 version of xcpdev is ready! The regular website is still in v9, but to test the latest features of the website use NEXT. -
And in this testing phase if something doesn’t work on v10 try it on v9. Is what I have been warning that v10 is slower than v9 for reads, and it becomes very evident for data with long histories. And some creates are also slower.
v10 doesn’t have the same cache as v9, but is a temporary measure to detect these issues and figure out the best way to solve them. -
One cool new feature is the messages page which now lets you filter by all protocol categories!
https://next.xcp.dev/messages
Having continuous messages index required some adjustments to the protocol schema so the message hash will be different to “official” CounterpartyXCP. But tx and ledger hashes will 100% match.
Basically, the “official” is no longer a messages hash, it is an events hash that is very tightly coupled to the logic (events) done by the protocol. CNTRPRTY/core (what is used in next) is still a messages hash like it has always been, focusing only on the Counterparty specific data.
(There is an open issue from a while back, which was ignored, so I just did it myself https://github.com/CounterpartyXCP/counterparty-core/issues/1617)
Looking at a block page in next will show both approaches, the new events and the classic messages, so is not that I removed any functionality, I added stuff to keep it aligned with the messages-first design of xcp.dev.
https://next.xcp.dev/block/845529
Notice that when “show all events” is selected, it will show duplicate info already available in the page. So, I believe, having a clear distinction between non-message and message events makes more intuitive sense (like it always has until v10). Not saying the events approach is wrong because it isn’t. It was just incomplete from my perspective, so I solved it.
Would do a PR to the “official” but I am currently blocked. For talking “nonsense”… in a PR that was later closed… so, maybe, the PR was the nonsense 😂Clean Up `messages` Table · Issue #1617 · CounterpartyXCP/counterparty-corerename messages to events remove command and category fields add tx_hash field (to be able to easily retrieve the events of a transaction) for each block the events_hash is calculated by concatenat...
- 29 May 2024 (3 messages)
-
Finally, the one-stop instructions for a fully self hosted instance of xcp.dev:
https://github.com/CNTRPRTY/xcpdev
Just tested it in a local Ubuntu VM, ending up with:GitHub - CNTRPRTY/xcpdevContribute to CNTRPRTY/xcpdev development by creating an account on GitHub.
-
-
None
