- 01 July 2024 (2 messages)
-
Keyuno made one of the first 1/1 nft projects. 2016 or 2017, i think it was. He knows the protocol very well. I'll invite him to this chat.
-
also one of the first to propose, develop and test atomic swaps on XCP! ❤️
- 04 July 2024 (2 messages)
-
-
- 09 July 2024 (1 messages)
-
Also highly premined
- 11 July 2024 (2 messages)
-
-
- 12 July 2024 (3 messages)
-
FYI, I continue to get “blocked” from the repo. This was the message that was deleted here: https://github.com/CounterpartyXCP/counterparty-core/issues/1984Design Spec. and Implementation Plan for Major Protocol Changes in v10.3.0 · Issue #1984 · CounterpartyXCP/counterparty-core
We want a formal design specification, plus a high-level implementation plan, for each of these significant protocol changes: #1825 #1843 #1842 #1857 #1939 #1431
-
-
Why?
- 13 July 2024 (25 messages)
-
-
-
-
As a matter of principle, and common sense imo, having less protocol changes per release increases the chances of continuing in consensus.
That is the answer to my “why” question.
Some (or many, unfortunately) don’t care about any of these principles and will just follow the cult leader on whatever he wants -
-
Joined.
-
I already knew things was going to hell there is more to crypto than is revealed. I'm not here to debate. I need assistance from devs
-
The two devs I spoke to seem to be sharp. I have my own devs I will send in here help them configure
-
-
Joined.
-
Imo it’s best to have a lot of changes at once especially if some are consensus updates. Otherwise we will end up having forced changes to often. there is the same problem with stamps. It takes 10 weeks to get OKX to update their code so we need to push a lot of the consensus changes at once in that 10 week period so we aren’t trapped in a perpetual 10 week cycle for little updates
-
Good point. If the multitude of changes are non-controversial, I would agree fully.
But for a more (supposedly) decentralized protocol (10+ years), if these changes include multiple controversial ones, then it can be used as a strategy to force them.
Stamps indexer is much newer, and kind of unique because of the split with src20 -
Ideally we bring src-20 back into cp since the db issues are resolved but overall imo it is up to the maintainers to determine consensus and what is worthwhile for the community as trusted representatives/maintainers. Since we have no real measurable way to determine consensus anyway we can’t force them to code what we want if it’s outside of what they have a vision and are motivated for. Just as it was with jdog. He forced us into some jacked up situations and pushed consensus changes for much less features and we all just went with it in the end, and it turned out ok. In the end anyone can just fork and run with their own vision. We did that with src-20.
-
-
Good point. Continued use of a particular repository is consensus
-
-
Can flip on a dime certainly
-
A metaprotocol like Counterparty is strong while there is full consensus.
What is the best way to have full consensus? By challenging changes, or by not challenging anything?
Most crypto goes for the latter. But then is just centralized.
And that is fine if is openly accepted. Not if you promote yourself as decentralized. -
Good point. I guess people that value the changes will be attracted and help build the ecosystem while those that don’t fade away or shift to different aspects of it. The forks are what determine where the value lies.. like bch,bsv etc.. perhaps that’s what truly make it decentralized.
-
I didn’t even realize how many btc forks their were! But maybe it is centralized with Luke at the helm
-
If decentralized is the main value maybe VTC is where it’s at lol. Never even heard of that
-
Anyway I do appreciate the dissent and discourse. Everyone loves the drama here.
-
Yeah I believe is better than complete silence, like it was not too long ago.
-
The big caveat with Counterparty vs these: these are layer 1 forks. In counterparty, is about “what is the “””true””” ledger”. An issue that is automatically resolved with layer 1 forks.
-
They even get airdropped the fork tokens. Very different to XCP
- 15 July 2024 (1 messages)
-
Took another look at this during the weekend… and the code is just too tightly coupled to counterblock. And both codebases (counterblock and counterwallet) are using many old libraries and methodologies. The effort to revive it is just not worth it imo (and “official” seems to agree).
The last option I see is for Jdog @BrrrGuy and Javier to continue hacking and patching it, as they are the ones that got it running last time. But won’t blame them for letting it go, is overdue - 16 July 2024 (1 messages)
-
- 21 July 2024 (2 messages)
-
Counterblock is the gateway from ripple into counterparty yes?
-
or is it the other way around?
- 22 July 2024 (3 messages)
-
I want whatever Houston is smoking
-
ok I want someone to do a video on this github dispenser .
-
GitHub - Jpja/Electrum-Counterparty: Generate OP_RETURN for sending Counterparty tokens from Electrum
Generate OP_RETURN for sending Counterparty tokens from Electrum - Jpja/Electrum-Counterparty
- 24 July 2024 (20 messages)
-
Wasn't there a nodes health application someone coded?
-
Maybe you mean the telemetry added to v10?
-
I want to a node can I use z raspberry pi?
-
-
probably not unless you’ve strapped on a lot of storage on and at least 8gb memory. The storage should ideally be an SSD connected with PCIE (nvme) as compared with SATA, but usb 4.0 is also gonna be reasonably fast if you have an external ssd. You need to run a bitcoin node so you need to meet the minimum requirements for that, and counterparty also has its own storage requirements - i think addrindexes may need another terabyte but they are in the process of phasing that out.
Probably neither 9 or 10 will work, but 10 runs much faster so would be better suited to a weak processor like a raspberry PI.
This is a better question for the Official Counterparty developers chat because this room is primarily dominated by naysayers and the people actually writing the software left a while ago. -
huh? really
-
which part?
-
they left because they don't care what they break
-
Haha, ok, maybe this is the right room for you then lol.
-
If you want to speak with people with technical expertise we can talk in the other room!
-
-
Who is a core dev? me?
-
Just FYI, i am just a normal software engineer, I am not a counterparty developer. This is a discussion between community members. One community member asked a question and I had the expertise to answer.
-
-
Should we go around the room and everyone share what brought them here?
-
-
I have shared all the information that I am comfortable sharing, which is that I am a professional software engineer who does not work on Counterparty.
-
-
The TLDR on using on system requirements is that you need 1.5 terabytes of disk space and absolute minimum 4 gigabytes of RAM, better to have 8, and that the disk space should be SSD connected in a way that’s going to give reasonable transfer and write speeds. Recommended NVMe, second best USB 4.0, and third best SATA.
I don’t think anyone has tested Counterparty on ARM but i could be wrong, so it’s possible the entire CPU architecture of a raspberry PI might be problematic.
I personally bought a NUC with 16 GB ram, i7, and 2 terabytes of SSD, 1 terabyte of which is NVMe, 1 terabyte of which is SATA III to run counterparty and bitcoin. -
I am sure once the code gets to a more stable/completed place that there will be real benchmarks and minimum system requirements, but i can say for sure it works on the above configuration well.
- 25 July 2024 (5 messages)
-
if you do end up running it on a PI and it works it would be helpful info
-
Joined.
-
What to do with my Nvst tokens in 2024 ?
-
Nvm sorry apple silicon is ARM also so that works
-
- 26 July 2024 (1 messages)
-