- 08 January 2024 (332 messages)
-
yes -
this is why we dont want to release a new freewallet we just want to change the api who call to get balances
-
counterparty.io?
-
yes
-
freewallet.io? yes too
-
if we can change that api not
-
not really is an option in the wallet
-
you can change the api
-
or at least seems to be
-
He should be removed from all official channels. Is what I would do because of his actions against be social contract -
-
if people dont upgrade wallet should be okey?
-
unless he want to pain comunity
-
more
-
i have not upgraded it for many time
-
it ask for upgrade every time i open so i think is not updating automatic
-
-
i know many people that dont update it for years
-
yes.... but at least people can safely move without need to import private keys to another wallet his assets...
-
Joined. -
good part is that seems configurable...
-
I believe the main channel to protect is the repo. There are people in this chat that can revoke his privileges
-
Then, counterparty.io
Social media is also important, but the least imo
See: https://github.com/CounterpartyXCP/cips/discussions/97Remove the word "official" from social media · CounterpartyXCP/cips · Discussion #97Lets promote decentralization by not claiming to be the "official" source of data for anything other than the PROTOCOL repository. Looking specifically at: t.me/CounterpartyXCP But then t...
-
seems momentarily and yes this issuance substract xcp just from the 9.62
-
Nothing changes in the transaction message so both versions should see it. And the new one will make it invalid if there is not enough xcp
-
I think nothing changes, haven’t verified his code
-
this change was done between 960 and 961
-
Well from 9.59 to 9.60 the issuance message was changed in a non-backward compatible way. A nasty mess.
Then the message was changed again from 9.60 to 9.61, to “clean up” the mess a bit, but still not fully. The 9.59 issuance format is not detected.
All these done without the due CIP process -
Yeah, some assets lost for v9.59 to v9.60 All the ones done on non-JDoge nodes like one I had
It proved how centralized the protocol was.
All inspiration for github.com/CNTRPRTYBitcoin and Counterparty ToolsDecentralizing CNTRPRTY: "Counterparty is Bitcoin. Is on top of Bitcoin. Is Web3. Is Web5. Two steps ahead." 🐸 - Bitcoin and Counterparty Tools
- 09 January 2024 (865 messages)
-
mmm strange
-
-
showing issuances for stamps again xchain api?
-
but not in the ui
-
looks like he is using other api for the xchain website?
-
-
-
so just some blocks
-
mmm is strange
-
jdog fork can has less xcp if some burnt making numeric
-
does not sound good
-
now it has less xcp actually
-
freewallet.io has always been a terrible name for a wallet because there's a freewallet.org and often users mistakenly go there and get their funds drained. -
Its a custodial wallet too. A few people have accidently installed it used it to receive assets and they are stuck forever because you can't get at the private key
-
and counterwallet stopped getting the latest features
-
Hi, as of the xchain thingy, I'm up to help on xcp.dev if needed.
Let me know if ever -
i think i have found something, could be possible that freewallet if dont detect xchain throws the balance query to counterparty.io
-
no images
-
but numerics arises again
-
Joined. -
if ya got questions about xchain, maybe ask direct
-
-
xchain APIs are not showing all data on 9.62.0 ledger.... numerics exist on 9.62.0 ledger, but NOT displayed on xchain... xchain now doesn't parse in any of those annoying numeric spam issuances... so, even with continued spamming numerics, xchain stays up
-
also.. freewallet pulls all its XCP data from xchain.io APIs.. there is no failover cuz there is no other API for CP except CP API, and it can't handle the load
-
everything is open source, feel free to go review the source code and see what is happening rather than guessing... or ask direct
-
have you added support back for numeric on xchain apis?
-
why i can see it in my freewallet when removing the host api
-
Cache
-
dont think so
-
nope... once all this fork drama is sorted out, then I will probably be adding support for ALL numerics back to XChain.io, as that is what I want to do... but, to be clear, XChain will only be running a version of counterparty-lib which has a fee on numerics going forward.
-
Lets stop with the back and forth who is good and who is bad and whatnot and move forward... most of you here hate me neway... so, assume i'm a hostile actor and take actions to move counterparty development forward in a decentralized way... its what you have all said you wanted, this is what it looks like
-
why i can see back my spam in freewallet just removing the xchain.io host in settings
-
added this and they arises
-
I just gave dev control back to the community 2 months ago by adding 3 more devs to core dev team.... and I just said, after much deliberation, "this is is the direction I think Counterparty should go, I'm on a fork, you guys figure it out".... its on you guys now to decide what community wants... everyone has opinions, few actually contribute... Step up, dont have me to blame for problems going forward.
-
yes was cached
-
dunno.. maybe cached data... will look into it when I have time... all I know is freewallet.io points at xchain.io APIs... and all xchain APIs are hiding numerics (may be a few API calls I misssed, but overall just hiding numeric assets with a simple flag... one flick of that flag and all numerics reappear
-
keep your flag ser
-
do you know we have difference balances between both ledgers right now?
-
xcp has it
-
yup differences are expected in a ledger fork... best for CP to figure out path forward for counterparty-lib n put out a release soon... or do nothing n see what happens.... forced decentralization 🤷️️️️️️
-
so you see how you are a dictator
-
hey man... just trying to offer an olive branch... it is in the best interst of everyone involved if we have a single ledger and an explorer which shows ALL assets, including numerics... We are where we are now... looking to cause less drama, not more 🤷️️️️️️
-
ok... back to more hate... tuning out here... tho will be monitoring, as I have since this channel was created 👍️️️️️️
-
don`t seems to entering in the group where we all working to figure out how to fix this and spreading fud
-
we are trying to replicate your api to dont hit it anymore you should be happy
-
questions were being asked about xchain APIs and Freewallet functionality... I felt it was important for clarity during this critical time... my bad I guess... I'll go back to being quiet and letting you wonder what is going on rather than answering your questions 🤷️️️️
-
I am happy... a faster database for counterparty and an API that supports way more queries is a win for everyone 👍️️️️
-
yes for sure
-
regarding to this, where are you taking the images from? most of links are broken
-
a bootstrap of them would be usefull
-
From my perspective, Jdog’s fork is not counterparty -
The activation on a whim actually makes it easy to dismiss, because there was no time for anyone to do anything or establish any sort of consensus, so even if there was some type of consensus around an xcp fee on numerics (which there didn’t appear to be) it’s too late because his fork was out of consensus on the next block
-
I don't think it would reach consensus, for the fact the protocol change wouldn't do what it supposedly was supposed to do -
It would not be an effective anti-spam measure
-
Sure but that’s really beside the point
-
Yeah
-
Agree
-
My point is separate, in that the stated purpose seems disingenuous at its face
-
If the goal is to burn more XCP to pump the price, don't pretend its anything other than that
-
The big risk as I see it is someone trading for a numeric they issued post fork using the dex, basically creating a phantom version of their asset then trying to sell it to someone and giving them an xchain link
-
Yep, not good for the average user
-
So the xcp cost to register an asset now depends on which version you run and user can now chose to pay or not pay xcp fees depending on which side they get out of bed by using or being guided to use the appropriate version
-
you can now spend xcp making assets and spend it again on the version you didn't spend it on the first time
-
or nor?
-
yes
-
The dex is really the biggest attack vector here
-
Because you can create valid trades on one side that are invalid on the other
-
Which spoofs the “real” asset holder
-
so the quantity of xcp doubled at time of fork
-
No
-
Bitcoin didn’t double when Bitcoin gold forked off
-
no but you got coins on both chains
-
Yes but the coins on Counterparty Jdog’s Vision are not the same
-
now we got coins on 9.6.2 that burn but don't on 9.6.1
-
a good way to pay for numerics, and also pay for named assets with the same funds at least -
I don't think it works like that
-
i have different balances on each version
-
Xcp balances really aren’t the issue, it’s negligible
-
-
one verision shows the burned xcp for a numeric and one does not so my balance is higher on 9.6.1
-
-
I just trying to work it out ... seems you can use xcp more than once
-
The issue is I can trade a rarepepe to myself for a numeric I created post fork without xcp
-
That Tx would be invalid on jdogchain
-
lol it does?
-
So then I could sell someone rarepepe and give them an xchain link
-
They will think they have it but the reality is I moved it to another address with my numeric dex trade
-
you can see the screenshots i sent one from xchain api other from api.counterparty.io
-
that makes sense
-
now there are multiple ledgers .. xchain and community
-
BITCOIN STAMPS
Unprunable UTXO Art, Because Sats Don’t Exist.
-
this is the tx
-
Absolutely, it would all be onchain
-
maybe track any asset traded for stamps and double mark if its sent to a dispenser. As this is the major source of sales right now. Im pretty sure we havent seen more than 10 trades using the dex for Stamps. -
but extra work when everyone is trying to catch up with current events.
-
I know this isn't the best solution from an optics perspective but changing the Counterparty header would add replay protection. It is sort of "ceding" Counterparty to Jdog, if the header is what makes a fork "official" but it would save having to do all this other work.
-
although it would definitely double every asset which i guess would be worse
-
but this ones are not the problem, problem are the ones who doesnt pay the fee
-
We already created one for the meme.
-
-
That’s a bad idea
-
IMO
-
I agree... I thought it through a bit more
-
how does this help? we still end up with 2 of everything?
-
2 of everything = value destruction. we should try to avoid
-
this is what they call being stuck between a rock and a hard place
-
true... community should have built more wallets and full explorers years ago.... time for growth... unfortunate it has to be forced this way 🤷️️️️️️
-
even roger did that with bitcoin cash
-
i saw he just got his black belt in bjj
-
lol
-
probly my favorite roger moment is his debate with jimmy song on some weird bitcoin cruise ship thing
-
Jeremy, you are welcome to stay here. Well, maybe you already were (@ChiefSamyaza)
You have been so accustomed to not having to deal with other node operators, that you might have forgotten the principles of the type of protocol counterparty is.
If this was a layer 1 blockchain, your actions are not so wrong. All tokens get duplicated at the block activation and “everybody wins”, in that it then becomes a competition for relevancy.
Counterparty is different
We are following the CNTRPRTY messages. And we need to agree on what they mean.
And you have been privileged in gaining the trust of the community, to the point that mostly everyone relied on your products…
But there was always a risk. What if, he decides to single-handedly change the protocol.
And you just did that.
Please reconsider your actions, or be respectful to the project and community by changing your tx prefix.
If you do that, then you are free to do your ideas, and some will follow for sure.
But don’t affect everyone (including your bags), just to prove a point. And even more when you know alternatives have been getting build for the last years, and the protocol is being used more than ever!
This is good! The protocol works. And if you need help with xchain, see how things are done on the open source alternatives.
This is 100% in your hands -
true, consider me an attack... do what is necessary to defend against the attack... build the infastructure to support what you feel is best for CP... I have..... we all know this sucks right now, but in the long-run, good for CP dev, we having more dev conversations and talk about optimizations now than in the past few years.
-
playing telephone game between multiple dev channels is so much fun 🙄️️️️️️
-
Read my message
-
you’re really downplaying the potential damage you’re causing
-
all of us know to wait out this chaotic moment but the average counterparty collector does not
-
and you gave us a month and everyone started working on alternatives then just decided to completely disregard that and make the change immediately, throwing everything into disarray
-
as a developer you should feel a certain responsibility to the users of your products, especially in crypto
-
users trust developers because they dont understand how things work under the hood and betraying that trust looks bad on everyone
-
changing the CNTRPRTY prefix wont solve anything....
Lets play this out...
I change the prefix on my fork to use JDOGPARTY encoding in the messages...
Transactions with JDOGPARTY prefix only generated when ppl generate txs with my forked version
Freewallet runs on api.counterparty.io to generate transactions... api.counterparty.io is on "Counterparty" 9.61.1
People still use Freewallet, People still generate txs with CNTRPARTY prefix...
Changing the CNTRPARTY prefix in this instance doesnt solve the problem of replay protection -
yes it does, because they’d instantly see the tx they created in freewallet doesnt show up on xchain
-
to be clear... I gave everyone 9 months... could have pushed fork in May... I did push fork with activation block in 1 month to push dev conveersations forward n make progress... I saw the progress, am happy about it, and think it should continue... but, woke up to more of the same bullshit... smile to my face and say cooperation and then behind my back continue with bad behavior.
-
cmon
-
I put up warning on xchain saying I am on forked version... fine with playing with the wording to make it sound more serious if you want.... but wont tell ppl to stop using counterparty for 30 days
-
ser we were not aware of that minting happening openstamp guys launched it without ask or tell anyone
-
you created a PR with 30 day clock to activation
-
why would you do that if you didnt mean it
-
was it a ruse?
-
I just told you..
-
but, woke up to more of the same bullshit... smile to my face and say cooperation and then behind my back continue with bad behavior.
-
done
-
who are you referring to
-
this affects everyone
-
it didnt say “30 days unless i wake up and feel disrespected by the blockchain"
-
i can host a space for high bandwidth conversations if anyone wants it -
stamps devs... who elses... privately DM me saying they agree with my decision to force fork and its good for decentralization.... then I go to sleep... wake up and xchain is down... "mysteriously" thousands of numerics are being spammed in isuances and now sends (new tactic, kudos).... and I check chats and its all "X-Chain sucks, Stamps are fine, must be sucky infastructure at xchain"..... tired of playing fucking games.
-
true.... consider me an attack on counterparty then and take the necessary actions to defend it
-
you are affecting ALL COUNTERPARTY USERS
-
true its not worth arguing
-
whats done is done
-
can we quick migrate to cardano?
-
" "mysteriously" thousands of numerics are being spammed"
You keep repeating this as if anyone in this room had anything to do with it. Believe it or not there are more stamps devs outside this room than in it. And its not a happy, cooperative bunch either. There are tons of heated disagreements that take place. We don't control the protocol or what others decide to do. -
doing a twitter spaces on thursday with emblem vaults team... prolly will spill out there... done for the day 🤷️️️️️️
-
Coming from an expert on double talk.
If you are only here for more drama, please don't -
Break a leg
-
setting up a project that unfairly spams numerics, when you know it is controversial within the community, continuing to spam numerics, and then claiming "its not us, its our users" is not being genuine mike... take some blame... I forced this fork, you setup this situation, and fanned the flames.... just didn't expect it to go this way... neither did I... but we are where we are, lets move forward.
-
No more drama here
-
Read please
-
cool.. now Is when I get booted from the "decentralized" channel 👍️️️️️️
-
anyone will boot you
-
:shovel:
Pathetic raid btw -
cool... way more centralized than "official" counterparty dev channel where no one is booted... been removed from here twice already, whats one more third time.. whats done is done.
-
Left.
-
thats not true i booted mikeinspace and gmoney just the other day
-
now we talk with !J-Dog
-
Jeremy removed me multiple times. Demoted me when I was the community manager
-
humans know this lesson
-
absolute power corrupts absolutely
-
He suffers from FUDSOLO
-
throwing the ring of power into the volcano and sparta kicking a group of long time associates in at the same time
-
good rule of thumb is to just assume all public chats are public to everyone
-
even when they leave
-
or never enter in the first place
-
the memes…they will be so dank
-
yes im with you but i think he wont change the prefix
-
Let him sleep on it…
-
My read is that the vulnerability would need to involve a numeric minted post-fork so that it exists on one fork but not the other. Then setting up a DEX trade for, say, a named asset. I'm not sure there are any other situations that are an attack vector.
-
Numeric minted on jdog fork would be fine as I don't think we can detect/discriminate against those on our side, but one minted on our side would be invalid on his (lack of xcp burn)
-
unless you have xcp in the wallet that will be deducted automatic
-
I get that, but I don't see how they would diverge without someone executing this specific vulnerability. The 2 ledgers should still be in sync, no?
-
how tho?
-
yes, I get that. I don't get why xcp balances would be out of sync already as stamps aren't really traded on the dex
-
There would need to be an invalid purchase for the xcp balance to go out of sync. Maybe that's happened... I just never really see DEX usage with numerics, and its particularly hard now that they are hidden
-
ahhh... yeah... hadn't thought about that
-
it would need to be a numeric asset though... and those are kinda hard to mint right now in freewallet (unless you're deliberate about it... like one of us devs assessing the situation)
-
this happened on my numeric asset I issued as a test... I issued against the 9.61 release ofc, but had XCP in my wallet.
Our node didn't recognize that requiring the xcp so it didn't deduct from my balance, but 62 did. -
well yeah... you're Kevin... I mean the average user
-
I guess my only point is that this shouldnt be a wide-scale issue... yet
-
i was super confused by that, because I thought the xcp came out when the transaction was signed/broadcast. . . but evidently it's only recorded after CP reads BTC and updates it's internal balances...
-
it is if people have xcp in their wallets by chance I guess
-
BITCOIN STAMPS
Unprunable UTXO Art, Because Sats Don’t Exist.
-
if they have xcp already it is....
-
i guess we could scan all stamp holders addresses for xcp and get a general idea of the scale of the potential issue. might be a fruitless exercise.
-
clear this up for me tho: the only "tooling" enforcing the xcp fee is freewallet (but freewallet is also hidding numerics), so I would think the liklihood of minting numerics on freewallet (right now) is quite low.. outside of testing scenerios like Kevin did (probably directly with the api)
-
no the only thing enforcing the xcp is xchain. the wallet doesn't do anything with the xcp balance
-
but xchain is suppressing numerics... god Im confused
-
this will be a good exercise imo
-
well if anyone is using xchain apis to get their balance then it's not really correct in our view.
-
freewallet does
-
but any other i think
-
really odd because i could deplete my balance making numeric assets, but then still have xcp on 9.61 to create named assets (which then would show invalid on 62) but valid on 61
-
quite the thought experiment of what that entails if Jeremy ever intends to 'merge' back in line somehow
-
i don't see how that's possible though
-
ah sorry i missed some of the chat. was busy in the debugger 🙂
-
only option of merge would be accept the fork in our side and reparse our nodes
-
but this wont happend
-
why he?
-
if we accept the fork the ones who needs to update balances are us right?
-
yeah, not sure what the end game is here for xchain. hopefully had thought it through in great detail over these months to some sort of viable outcome.
-
lots of invalid named assets
-
would destroy a lot of those mints today
-
yes true
-
not really viable with the $ involved there
-
It becomes a BTNS explorer when the reality of the clusterfuck becomes apparent.
-
i'm sure that must be the end game. he mentioned that was way more profitable
-
He has 1 year left from the fund-raise he did 3 years ago... so yeah, probably done. Not fun anymore. I dont blame him
-
Here's the thing: even if everyone capitulated right now and upgraded to Jdogfork... how do you reconcile the ledgers? They've already diverged.
-
too late
-
exactly
-
i think he should change the prefix i hope he reconsider it and remove at least the replay vector
-
tbh i dont think it really matters, just need to stop using xchain and move on
-
yeah could overthink it for days i'm sure
-
it is a fun thought experiment lol
-
haha yeah trippy for sure
-
lol a time machine
-
welcome back!
-
it honestly amazing its taken 10 years for a fork considering how they’re technically very simple
-
i think i'm already forked with my wackly hashes anyway haha
-
thats a spoon i think
-
ah yeah more like haha
-
will be great content for the book and the limited tv series
-
this was not science? now is history?
-
i think im in the wrong classroom
-
🤣
-
-
jajajajaja
-
Truth. I believe arwyn already started the movie
-
Joined. -
welcome Dan
-
of course
-
assuming the balances are the same
-
yep
-
yes
-
-
-
I have github.com/xcp and xcp.io if they could be of useXCP
Trade Cryptoassets Peer-to-Peer. XCP has one repository available. Follow their code on GitHub.
-
-
a technical debt jubilee, i like the sound of that
-
i like it too
-
Adam K has two good insights on GitHub. The main one being if there were a good explorer API off the fednode. xcp.dev has a lot of useful code.
This all looks really manageable, especially if there are diff people with the repo now.
I would expect the fork to drift off into the mist. Let that fork deal with the issues of replay or invalidness. -
this is the idea actually being able to put inside the fednode
-
there is no one asking for that fork either
-
its a fork for no one
-
But if it does get really crazy town. You snapshot at some reasonable spot and start from that. If you look at how burns work in counterparty. It’s a CSV import without validation. So it would be sort of like that. But you’d bootstrap balances for non-XCP assets too and have layers of signing and validation over the starting point to avoid funny biz.
-
Jdog party of one
-
You guys got this. Now, I return to fud.
-
i always wonder if there was an error in the burns csv, but im afraid to check
-
sorry, i am not aware of this part
-
there is a bootstrap of burns from what?
-
counterparty-lib/counterpartylib/mainnet_burns.csv at master · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
would be easy enough to check the tx_hash's
-
mmmmhm
-
im not checking
-
lol
-
i will do a script to check this when i have some spare time
-
should be easy
-
actually chatgpt will do it for me
-
script running before go to sleep jeje
-
i didnt know it was not verified i thought that maybe on a bootstraped one could be not verified but in a full parse it was been verified
-
i remmeber see that when runing the node in the first part of the sync but i didnt look how the code was doing that
-
Treating the symptom, not the cause. -
There are no miners in Counterparty to receive the fee. The xcp fee is the equivalent a burn for now.
-
Like the protocol stack needs reorganizing instead. Maybe the fednode install process should be more customizable per operator? Choose your own adventure? Press 1 to include numbered, press forkoff to sit and pout.
-
You can’t do stuff like that because all the assets can be traded for one another, so you need to care about all of them to have accurate balances.
-
I took ‘Stamps is a protocol’ and ‘Stamp: required in the description’ to mean something similar to ftp: http: ssl: protocol implementation, not that I was signing up for a collection on jdogs explorer; when I made a named stamp with multiple quantities. My take on stamping before the rules were sealed, was that stamp: was necessary to facilitate the storage and decoding of the base64.
The appeal to stamps is that stamps claims to solve the immutability issue, but counterparty did that already, not stamps. The tx just had to be correct. Then came the realization of BTNS via broadcast. Src-20 and 721 and BTNS are all similar spinoffs and have something positive to add to the protocol if we could bring it all together. -
I only have one, as a proof of concept. I’m not a bag chaser. Immutable art and education were my motivations behind my named stamp.
-
I just withdrew CIP29 which justified xcp fees on numerics.
I wrote that CIP long ago and I think it is outdated.
Whoever still wants this fee, please write a new updated CIP to replace CIP29.
https://forums.counterparty.io/t/fee-on-numeric-assets/6601/6Fee on Numeric AssetsI suggest adding a 0.01 XCP fee on every issuance (initial and subsequents issuances alike). Also, invalid issuances should be ignored and no longer be stored in the DB. I am against the planned 0.25 XCP fee on numeric assets. Why fee on every issuance From my understanding, the problem lies with the issuances table. Many use cases, like data storage, should move to broadcasts. To encourage this, a fee must be applied to every issuance, not just the first one. Otherwise you can issue an asset...
-
Take the issue apart. The protocol is made of components. The wallets form the transaction, the miners process if valid, fednode sees tx, api transforms fednode data for consumption, explorers are presentation layer. The protocol should not change to implement features for an explorer that can be accomplished with CSS or filtering. Wallets will still create tx’s as they did no matter who forks what.
Can we work towards a universal prefix that replaces ‘stamp:’ moving forward but still facilitates the storage of base64 and treat them as a normal asset if named? Stamps can still exist but this would help clear the language issues, let stamps stand alone and open up the discussion for further advancement of these new implementations. -
Dont quote me, I’ll look into it later but I’m pretty sure most of those domains all are hosted on the same plan/server anyway.
-
Freewallet is not official protocol wallet. Counterwallet has been pushed to the side and possibly being phased out if memory serves. Counterwallet is what was needed to make a stamp in the beginning, because freewallet had a limitation to description size. The user facing stamp services are basically web wallets that can create a special counterparty compliant tx that freewallet can not create. More counterparty wallet integration and implementation will be needed.
-
Things got weird after Miami.
-
I remember that fun time. Completely stalled my project. That was a bigger issue I thought. Thoughts?
-
This is important. This closes the market between asset types making each less valuable and having fewer features.
-
The standard already exists, data urls
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs
Easy to detect and support for explorers:
https://bitst.art/147e416c5bc929c202058c187fdc6fec74121c96666d86c1b3c815e988bd49bbData URLs - HTTP | MDNData URLs, URLs prefixed with the data: scheme, allow content creators to embed small files inline in documents. They were formerly known as "data URIs" until that name was retired by the WHATWG.
-
Tell me. bitSTART was just launched. And broken a few days later.
Made me pivot and disregard asset quantities entirely. Only focus on the art. Eventually for the best, as ordinals made more sense to add with this approach -
I’m still catching up from Jdog taking off his socks.
-
No fud.
-
No offense but we started this chat for a reason…
-
Joined. -
welcome shaban
-
Thanks
-
I think a need an AI bot to sumarize me all the discussion and dramas
-
we are working on continue deving the xcp.dev explorer and apis as is opensource as a replacement for xchain and his apis, also here yesterday were discussed some posible vector attacks, some of them could be potentially addressed with education for the comunity and with a clear difference between forks but some needs cooperation from minoritary fork to change prefix so we can protect against replay attacks
-
TLDR - xcp balances are out of sync and it now depends which version you ask as to what your xcp balance is. There are assets that exist in 9.6.1 that are invalid on 9.6.2
-
9.6.2 has less xcp available
-
so xcp.dev is staying on 6.1
-
yes
-
so we have effectively a fork
-
yes
-
That would be awesome and terrible at the same time. I recommended parliamentary procedure a few time to deaf ears. These dev conversations need structure and discipline sans emotion, hence this ALT dev channel.
-
So right now if I'm correct xchain, freewallet (counterwallet ?) are on 6.2 and as a matter of fact Casa Tookan, OrbExplorer are on 6.2
-
The fork/dev group that best cares for users will win.
-
but in practical term (ouside the idea of buidling a community) what are the current implication on the existing counterparty stack ?
-
xchain yes is in 62, freewallet kind of, reads from 62 but tx are created using api.counterparty.io whhich is in 61, counterwallet stils in 61 but is broken atm with the last update
-
-
difference is xcp fee on numerics, so in 62 all numerics issued that the issuer address had xcp in his wallet are valid in counterparty protocol but not visible in xchain and freewallet as he has muted them, as consecuency of this issuer address in 62 have deducted the xcp and in 61 no
-
also many assets that exists in 61 doesnt exist on 62 if the issuer addres didnt had xcp in his wallet at the issue time
-
an attack vector exists in that an asset that does not exist on 62 could be traded on the dex on 61
-
but you are in 62 with your nodes or as you have depencencies on xchain ser?
-
@yodark
-
if is the last we are preparing replacements for the xchain apis, you can check it here, we assigned a priority there for each one so feel free to add priority to the ones you consider
https://cryptpad.fr/sheet/#/2/sheet/edit/F2VaSWqt7t28TLArMTFdZuSD/embed/Encrypted SheetCryptPad: end-to-end encrypted collaboration suite
-
Counterwallet was broken by recent updates (dispenser close delays)
-
We are connecting the counterparty node that is managed by JDOG
-
we also have node that is managed by jdog
-
You should talk to jdog but afaik the only node running the fork is xchain itself
-
maybe is better if you ask him if he updated that nodes
-
yep thanks
-
Too soon. Let it play out first.
-
Left. -
Maybe 6.3 needs to be a reversion?
-
what you mean with a reversion?
-
And freewallet
-
true, at least until the calls can be recreated and settings updated
-
-
Joined. -
It would affect those collections if someone trades a numeric for a card in those collections, especially if that numeric is issued after the fork.
-
yes this is what i think
-
Which is rare probably but a thing
-
if they relay in xchain especially
-
fakerare has a stamp in the collection
-
dank rares some others also
-
Any idea which one?
-
wokja too -
A8008135800813580085
-
its mine (and alth0tas)
-
Do you relay in xchain apis?
-
i have some dank stamps too
-
i think its probly best to stop vaulting ALL counterparty assets for now
-
as dan pointed out this is a risk something trades for a numeric created post fork
-
i think there has been a number of stamps subbed to kaleidoscope too
-
and creates phantom assets
-
Yes there is a priority list here so we can work on that one's first
-
-
Reminder that subassets are numeric assets lol
-
this are priority 10 actually and working on them atm
-
yes but this ones has not problems i think
-
i feel like we’re ground control and counterparty is Apollo 13
-
maybe thats a bad analogy
-
lol
-
Huston we have a problem
-
Lol
-
he knows. he sent jeremy an email
jkjk -
those have been blessed with a 0.25 XCP offering
-
Wow. I took a night off and 😳
-
All caught up now. Wish I was not.
-
glass is half full AB
-
@uanbtc as a charter member of this channel, I make a motion that we switch this chat to invite only for a bit.
-
No fud here
XCP Dev Chat
Public archive of Telegram messages.
- 05 Jan 2024 (37)
- 07 Jan 2024 (187)
- 08 Jan 2024 (332)
- 09 Jan 2024 (865)
- 10 Jan 2024 (479)
- 11 Jan 2024 (508)
- 12 Jan 2024 (685)
- 13 Jan 2024 (674)
- 14 Jan 2024 (319)
- 15 Jan 2024 (104)
- 16 Jan 2024 (318)
- 17 Jan 2024 (24)
- 18 Jan 2024 (10)
- 19 Jan 2024 (3)
- 20 Jan 2024 (22)
- 21 Jan 2024 (1)
- 22 Jan 2024 (33)
- 23 Jan 2024 (11)
- 24 Jan 2024 (19)
- 25 Jan 2024 (294)
- 26 Jan 2024 (189)
- 27 Jan 2024 (65)
- 28 Jan 2024 (7)
- 29 Jan 2024 (8)
- 30 Jan 2024 (62)
- 31 Jan 2024 (110)