- 03 October 2024 (39 messages)
-
Counterparty (@CounterpartyXCP) on Xš¢ New Release! #Counterparty Core v10.4.2: https://t.co/0QqWAHvRJD. This is a hotfix release that addresses a few important bugs, such as regressions in the v1 API and disabling P2SH transaction encoding, which was causing issues with MPMA transactions. If you're running a
-
So P2SH encoding is now disabled? This is the solution to me pointing out that people were having issues doing MPMA sends on the new 10.4 version of counterparty?
-
So.... no more MPMA sends? Back to just having to do single sends of every asset now?
-
MPMA sends use P2SH encoding... in the latest version 10.4, users of freewallet were having issues, I pointed these issues out, and the solution is to disable P2SH encoding apparently. So, just asking for clarification, do MPMA Sends still work in this new 10.4.2 release? @teysol
-
Would be great if we could have discussions about these types of changes rather than just doing immediate "hotfix" releases which break current functionality which many users use!
-
MPMA Issues: First TX Succeeds Second TX Fails Ā· Issue #2270 Ā· CounterpartyXCP/counterparty-core
Getting reports that there is a regression in Core > v9.61.3:
-
Cuz from my perspective... it sure looks like you just forced a change into 10.4.2, which breaks MPMA sends, and requires wallets to update.... interesting how FreeWallet is the only wallet that supports MPMA, lots of users use it, and now all of a sudden a change is put out which requires a wallet update and breaks MPMA for users..... if that is not the case, then please speak up. @teysol
-
Lovely... just more of this centralized decision making, no communication or discussion with community, and putting out hotfixes that immediately break functionality and require devs on the platform to immediately put out updates to wallets / tools / etc.... And one wonders why long-time devs are choosing to walk from this project.
-
Mpma doesnāt rely on p2sh encoding, it works fine with multisig and you donāt have issues of the 2nd tx failing -
yup, just have the issue of having a fuckload of multisig outputs with BTC sitting in them, which the user then needs to eventually collect... vs using p2sh encoding, where those outputs are used as the miners fee on the second tx.... Look, as I said, i'm fine switching to multisig... but it is definitely messier and wastes more BTC... and the main point here is that MPMA p2sh encoding was broken in 10.4... I asked for it to be looked into, and the solution was to immediately depreciate it... it is what it is, clearly you are fine with this style of management of the protocol.... so i'll make the necessary updates to keep my shit running and fuck off to working on something I believe in again.
-
-
Official Counterparty is Unspendable Labs. If you upgrade you agree with this.
The consensus in the ledger forces āthe restā to comply. This is the centralizing force.
I see Counterparty/XCP very different nowadaysā¦ -
Fun name lol -
I dont agree with their forced updates, but I still run the most used wallet and explorer for Counterparty, and as such, I feel I have a responsability to protect the users from a contentious fork and the potential loss of funds as much as possible. I dont feel the CP community will be best served by having a fork at this point, as I feel it will devalue all the assets on both forks... For me it really boils down to am I willing to risk users losing funds because I disagree with the current core devs development vision and a few changes which make CP more expensive and difficult to use? I feel the answer is no... so as much as it pains me, I feel the best thing to do is to update to 10.4... was hoping it would be a relatively smooth update, but since I pointed out p2sh is not working in 10.4 (curious how this wasn't really tested before being released... not a suprise tho, since they dont seem to test much before release)... P2SH encoding was disabled rather than fixing it (again, funny how p2sh encoding works fine on 9.61.3 which is on a recent version of bitcoin core, and I can't find anything about p2sh being depreciated from bitcoin core)... but I digress... The users are not best served by a fork, and my loyalty is to them, not my own viewpoints being proven as "right".... so no fork for me.
-
-
its my respectful way of saying "FUCK OFF!" š
-
I can understand your point of view, especially after seeing your numbers.
And maybe that is why I am willing to end the ācentralizedā path in xcpdev. My numbers are not even close to yours.
Thank you for explaining your reasoning.
I have some ideas of how to proceed with xcpdev thoughā¦ but not my priority right now š¤š -
Hey guys ? Green banners for showing what directory the asset is in are those gone ? I donāt see website links or nothing on a bunch of stuff ??
-
Kinda legitimizes assets eh
-
Like this
-
-
Memes king
-
Oh snap wrong place lol š
-
Iām sorry I clicked wrong chat but youāll like it lol š
-
Hah and of course
If you want all the info weāll
Xcp dev baby -
-
Yeah thank you ā¤ļø
-
Down and dirty details is here every key stroke
Although I see rare Pepes took away images eh -
But not the data
-
Yours is always where I go if Iām not sure of details totally itās the full meal deal !!
Are you and jdog gonna link your two kick ass systems ?!
That would be a juggernaut
If they could slide back and forth !! -
Hmm
š¤ -
I donāt know what that evan means
-
Well thatās good š
- 04 October 2024 (9 messages)
-
So how come this chat isnāt called xcpdev ?
-
Just wondering
-
866 000 -
It is t.me/xcpdev
If you mean the title name, the history is that it was initially called āCNTRPRTY Bitcoin Developersā, based on the āDecentralizing CNTRPRTYā repository (https://github.com/CNTRPRTY), which forked the āofficialā library reference implementation, with a ācore versionā which used no bootstrap (donāt trust, verify), and removed a lot of the unnecessary bloat from the protocol stack. Plus, also includes the complete xcp.dev explorer open source code.
And a couple of projects started using these (like stamps).
The spirit was about having a parallel group to the āofficialā. Counterparty had no founders around (for many years), it was run by Jeremy with xchain/coindaddy.
He was running everything, and I saw that as a decentralization failureā¦ because the project claims to be decentralized.
All those interactions led to the project and this group, where 99% of the conversations are not about xcpdev but Counterparty (and Bitcoin) in general.
Around 2 years later the founders returnedā¦ and initially it seemed like something different than what ended up happening.
Many more details missingā¦ but that is a summary from my point of view.CNTRPRTYIndividuals in this room agree to respectfully discuss CNTRPRTY (and similar) data written in Bitcoin. All participants should each represent what they believe to be ethically and technically responsible actions.
-
No idea, maybe only xcpdev
-
Ah ha itās just the title. Gotcha I love xcp dev.
-
This is why I like using arweave easy asset
This person looks like they maybe host there own images
And Iām sure I would screw that up lol
But itās sad it is one of my favourites -
They used imagur
- 05 October 2024 (1 messages)
-
Imgr was popular before as it was free. - 06 October 2024 (1 messages)
-
And now some great art is getting lost to the free ness
- 08 October 2024 (1 messages)
-
Notice: A few of our friends in this channel have had their telegram accounts banned recently. Some well established channels have been shuttered too. Keep an eye out for anything suspicious. Either hackers or actors. Dan and PowerHodl will be missed. - 09 October 2024 (7 messages)
-
Really people banned or telegram toasting them or what I hear lots of chatter ?
The rare bobo chat either o got banned or ? Itās gone ? -
Oh wow
Ya powerhodle was pinned in my chats and is a ghost now ? Any ideas why that is ? -
Also Dan anderson (droplister) has been banned, and the bitcorns chat and xcpbot are gonzo as well.
-
wooow
-
i saw dan tweet about it, i didnt realize all his stuff got nuked too
-
Yikes anyone know why ?
-
Anyone got pavels cell number hahah
- 10 October 2024 (63 messages)
-
There is so much stuff missing its not worth me raising an issue -
Wait for 12.4.4 lol š
-
No doubt I understand code Is hard especially new shit all good š
-
Me no code lol me hit shit
-
Allow me to clearly express my thoughts on this
1. Im not "acting entitled" i am OPENLY expressing my thoughts on an OPTION. I dont HAVE to use them, and since they dont have any of the features i need... i wont.
No one is entitled to community participation, especially if the thing you built isnt better than the standard ive been using/am used to. If it is... i'll consider it. But im not going back to bicycles because you cant build a better motorcycle. Pointing out the flaws in motorcycle wont make peddling feel better.
2. im not a beta tester, im an end user... so put a blanket on it till its done or resist the urge to frown when people dont like it because once i can see it... i seent it... its saw... and i filed it under not good enough. This aint a focus group.
3. I didnt ask you or ANYONE to provide me with shit... lets level-set our expectations here. If you want this to be the standard, the time for figuring out what that means and the main components people want/need is usually BEFORE you build it, or at least before you show it to me.
I use what is useful... same as most people, so you should probably figure out WHY this aint as useful as you'd hoped and stop furrowing your brow because you werent met with flowers and a hot stone massage for some half cooked, worser version of the thing you'd like to replace
also... im not the droids you are looking for -
i stopped to have a fresca
-
-
Yeah... i also am not a dev
you must have speed read past the "If it is... i'll consider it" part. But to say people are "acting entitled" as though i sent out a distress signal for help and am bitching about the kind of boat you sent is wild, and emotional
when its useful, i will consider using it
if you need more i dont know what to tell you
if you require enthusiasms for something i cant currently use, thats between you and your parents and your public school -
Honest question: what is your relationship to the current ācore teamā? Also curious about @dimesquanderer
-
What is the repo?
-
Thank you for the straight answer btw
-
Nice thanks
-
Im already clear about him. Still not about youā¦
-
not sure if it's obvious, but the green banners were a revenue generator for xchain. where those putting together a collection/directory would pay to have the banner. it's not really public/on-chain data. likely why it's not on horizon or likely anywhere outside the xchain api's. on-chain collections ftw. -
Why are you here then?
Iām not asking for id lol. @dimesquanderer just said his role and that is enough
@vectorconfetti what is your role with Unspendable labs? -
To clarify, some projects paid a 1-time $1000 fee for green banners, most did not, and all funds went to, and continue to go towards covering SOME of the server hosting for tokenscan.io. Green banners have never been a "revenue generator" for me, just something to help keep the servers running and help offset SOME of my costs.
-
-
-
-
lol, its funny you think its a captive audience, I have never recruited for the channel, and only ppl i've kicked are disruptive ppl. And, its easy to get sock accounts and see that i'm not talking about core devs... stopped that a while ago, it became clear they gonna do what they want, regardless of what long-time community members think... Keep trying to push that narrative tho newcomer. Tell me your new to counterparty without saying your new to counterparty šļøļøļøļøļøļø
-
anyway, this is Juan's channel to discuss counterparty, and seems like discussions are going fine without my contributions on CP dev... tho i did just find a number of issues in the CP releases, resulting in a couple hotfix updates šļøļøļøļøļøļø
-
I test my updates before releases, extensively... sure sometimes stuff slips through the cracks... but check my release history for CP the past few years, it speaks for itself, 99% of the time the release is stable with no emergency hotfix updates. We just have different development and testing methods... I prefer to test code myself before releasing stuff, so that the community is not impacted, others prefer to have the community test things and find issues... It is what it is.
-
feel free to investigate yourself Victor, I stand behind my history... and wont waste any time in here debating nonsense. Back to working on XChain platform... Enjoy your day bro... your busy day as a high demand software developer who is prevented from working on CP... but has plenty of time to troll... lol
-
-
Interesting, I wonder why it's so flat in the middle.
-
Interesting, I wondder why the conversation started out about hotfix release frequency, then quickly switched to frequency of code commits. Quantity != Quality... nice try tho Vector. Dont you have some work to do? lol
-
-
imagine a world where people liked living in the dark ages -
I would like to collect something from the dark agesā¦ā¦.
-
thx for the details. i think this whole conversation went sideways with horizon not having this data listed among some other features. which circles back to the point of having these collection/directory data shared on chain somewhere.. would be nice so everyone in the community can consume the data and validate things. š that's a more interesting topic that helps everyone i think. is it available in the tokenscan API's btw?
-
Asset names are defacto collections imo
-
Each project that has a green banner has gone through the trouble of setting up a public JSON file with a list of the asset names and the images for the cards in their projectā¦ just a little bit of footwork by devs to reach out to these projects and get that file would allow them to parse in that data.
I have no interest at this time in spending my time making it easier for people to collect that dataā¦ especially not interested in spoon feeding data to developers who have publicly said not to use my explorers and wallets, so that users would be driven to their tools instead š¤·š»āāļø
If they want to get a list of official cards from projects, itās pretty simple to reach out to that project and ask.
TLDR, no tokenscan api at this time. -
my penisium emails bounce
- 11 October 2024 (9 messages)
-
-
Cuz ur a troll who has nothing better to doš¤·š»āāļø
Keep talking shit to the guy who kept counterparty alive for eight years when your beloved developers walk the fuck away š
You can try to make me the bad guy all you want, bro, but none of this shit would exist if I didnāt keep it alive when everyone else walked away š¤·š»āāļø -
now, Iām off to a breath work and sound bath class. Hope you find some peace tonight brother I know I will.š
-
Aaah didnāt know really
But itās a hell of a good way to identify quality projects in my mind and as for revenue people gotta make money right ? Or what are we doing lol - 15 October 2024 (19 messages)
-
Xcp dev seems like the only true double checker place that is still accurate right now
-
Will there be some actionable buttons in xcpdev coming ?! Like wallet link would be glorious
-
The xcpdev wallet is about creating unsigned transactions, no private keys necessary. Most compose functionality should be there
If you can be more specific about what āactionable buttonsā you would likeā¦ -
-houston Yes the web wallet of xcpdev can compose ANY unsigned transaction, but then only the address owner can sign it
-
From the wallet of their choice
-
The userās āsourceā address, which can have many assets (as balance or issuance)
You sign the unsigned transactions from the wallet that has the key to this āsourceā address -
Sounds like I need to play in there a bit more !!
Hmm
Connect to FreeWallet or just make transactions then go sign in there ?! Iāll have to play hmm š¤ -
Hmm I need to play more I love xcp dev just have not been able to actually create or click on anything. That takes me anywhere.
It shows dispensers but you need to copy paste them then go to FreeWallet or tokenscan to do anything with them
It has unmatched information all in one place for sure. But thatās what I mean it would Rock if we could click on stuff and then transact.
But your saying we can Iāll need to play -
You can start playing with it by doing a broadcast
-
Sure
- 18 October 2024 (126 messages)
-
Reading 200+ messages from the last 48 hours in the other dev chat. Good job @BrrrGuy debugging. Iām still about 100 messages behind. Any ācliff notesā on the current network status anyone?
-
wish the core devs did more debugging and testing on their own.... could have easily avoided all this by doing some load testing on testnet... which is kinda what testnet is for... the current core devs and I have very different testing methodologies... 8 releases in a week is insanity... but I digress... it is what it is
-
the cliffs notes is simply that everyone has to just hurry up and wait for core devs to make cp run faster and more stable... and sit by their keyboards updating release after release
-
yeah yeah yeah vector.. I know... here it comes... blah blah blah the core devs are awesome and I suck.... save it.. lol
-
i see u typing sock š
-
-
It's all dead atm -
Only node operators are enjoying it
-
yeah... but on the upside, we are spamming half of bitcoin blocks... no one can use the tooling built, or use the new feature... but yay... guess thats a win in some ppls eyes š
-
Utilizing the blockchain not much to be upset about.
-
Everything else is exhausted
-
Will be interesting how it will handle atomic
-
High volume transactions
-
Mm
-
Couldn't even handle scripted minting
-
my infrastructure is handling it fine... its the CP API and explorer.unspendablelabs.com that are not š
-
But I'm forward thinking. And hopeful for a solution.
-
16 cores in all my machines... at some point you become disk bound
-
Yah horizon wallet and Explorer dead
-
Freewallet.io dead, just takes like 20 mins to load
-
Tokenscan.io alive still
-
freewallet loads data from tokenscan.io fine.... its the API calls to the CP API (counterparty-core) which are the problem... as I said, my shit is running fine, CP APIs are not... that is not in my control
-
Alot of educationals to bring supporters to this level
-
Casey team did months of preparation for Runes
-
api.counterparty.io should do something like counterwallet used to do.... detect multiple backends and load balance between them... so ppl could spin up public nodes and "contribute" them to api.counterparty.io load balancer automatically....vs spinning up individual nodes
-
@BrrrGuy is the issue at the api/service provider or in the protocol itself? Can nodes sync up to tip atm?
-
seems like it should be pretty easy to do since the core devs are now automatically collecting telemetry data on every node every block
-
What is decentralization?
-
new release just put out a couple hours ago... required a rollback.. I just woke up from a nap so just started... but from what I am seeing some ppl are parsing past the block issue that stopped everyone this morning..
-
well... not everything.. https://i.gyazo.com/001afc2ccab0abc8c9142336a1c870b3.png
-
š
-
Is any node synced up to tip?
-
will say, it is nice to see all the spamming and tx fees not going to the ordinals/inscriptions tard levels of hundreds of sats/vb.... OP_returns are nice n small
-
How long are blocks taking?
-
cant say.... interesting... I tried to grab that info but not seeing parsing time for each block.... could be cuz im in the middle of the reparse... will watch for parsing times once caught up
-
-
Aka unspendable haha fun name Love it
-
š£
-
69 members
-
Yesterday I got a screenshot... 30 seconds to parse a block with 198 txs.... we got way more than that now tho
-
-
Ok. Then, to balance the āto the massesā tech narrarive, the 25x numbers being thrown around is bs. The software made compromises to optimize some things, while affecting others.
Obviously not an exact fair comparison, but v9 is still syncing in low times while my v10 (pre consensus changes) is down.
And @vectorconfetti , Iām curious how do you think the incremental txindex, with a ledger, can take much advantage of multithreading? -
fair mints write more to the database now too.... src-20 spamming was (credits/debits/transactions/issuance/assets/balances) updates... now CP also does all that plus records for fairmints and a couple other tables... I am sure there are def some speed optimizations made in the past few months... but DB footprint is definitely larger than the src-20 issuance spamming was š
-
and all of that is written to the messages table to... which I am glad that at least now EVERYTHING is written to the messages table, but definitely a lot more database IO in the past few releases / updates
-
Might as well bring src-20 back to cp. seems trivial in comparison
-
Shitcoin bonanza
-
lol.. you would actually save a few database writes (-1 for fairminters record, -1 for messages table write)
-
Plus itās all p2wsh now anyway
-
So no description field bloat
-
Not a joke, now that hardcoded transactions have been embraced by ācoreā, it would be extremely trivial
-
also bootstrap is embraced by the devs by default now too.... funny after all the lipservice about how downloading a bootstrap was bad form...soon as they figured out how long a full parse took to spin up a node and no one was looking... POOF... back to downloading a bootstrap by default... funny how views change
-
but... what do I know, i'm just the toxic dev.. lol š
-
eh... addresses are easy to spin up... if your writing a script to spam txs, trivial to use different addresses... in BTNS when I put a max amount per address, saw ppl just doing the same thing... using lots of addresses... CP has not "max mint per address" (cuz its actually trivial to bypass)... but at least a lil bit more friction... btu yeah... more addresses doesn't necessarily mean different users.
-
goes much faster if you go back to the bootstrap and do a full parse. it's the reparse that is slow. something with keeping things synced with the api db from what i can tell.
-
hey vector... we getting too comfy engaging without some of our normal banter... so here is a friendly fuck you š
-
The new meme. 1000x improvement to sync of src20ā¦ because is all a single csv š¤
-
still takes a while, but i started one from reparse and one from bootstrap and the bootstrap is almost caught up to the reparse
-
šø
-
23s to parse 866211 for example from full parse. but i didn't catch how long the reparse took on that block, but certainly at least 10-100x
-
seeing 898s per block on reparse 866226 for example
-
just delete all the cp .db files
-
898s == 15 minutes to parse a block... with bitcoin blocks coming at 10 minutes each... they still got some more optimizations to make š
-
but would agree that parsing does seem faster before all this MINT spamming
-
well that's reparse vs parse at tip it wouldn't be in reparse unless reorg
-
which i think is where some bigger issues came up on the api crashing
-
i'm just excited i finally made a trx to crash the nodes. a very small list of ppl
https://github.com/CounterpartyXCP/counterparty-core/issues/2441 -
welcome to the club brother :)... you want a FORKOFF and a BADBURGERDAY?... will send you one once the APIs are back up
-
In v9 is all the same up to being written to the transactions table, as unsupported.
xcp.dev shows them
So major speed issues are db rooted I would think -
haha love it. wallet is definitely open 1MZUaVy6y7vmwh2MqMKTFy2JiqXteyevpN
-
https://www.xcp.dev/block/866244
In the blocks section of the home page unsupported transactions are not countedā¦ something to change š¤ -
I gotta go get my son from school... my CP API node is in reparse, about 50 blocks left... once it catches up and the API comes back up, tokenscan.io should automatically get the data synced out to it.... back in a couple hours...
-
I wonder if telematics is a big speed and performance issue. The github re:telematics noted that they accidentally blew through their budget by collecting too many data points too quickly. Telematics is not on my radar for this category of software, IMO.
-
fyi on reparse i'm getting 2 mints processed per second. on a full parse from 861000 it's like 3-6 per second
-
so at tip, we should be 3-6 per second. i heard someone say potentially 40k potential trx in a block? not sure if that's accurate
-
Is that actually possible? -
Well this tx size is small but so small?
-
idk but if so it would take 33 mins to parse a block
-
In a ssd
-
Me in a HDD I don't want to imagine
-
I appreciate all of the brain power in this channel. I am among legends.
-
-
yikes
-
that looks like stamps_indexer in the first versions when. was running on my tv box @reinamora_137
-
yeah... many optimizations to be made... xchain-indexer does a MINT in about 5ms.... at least, so far in muh testing... mariadb vs sqlite š
-
2024-10-18T23:28:44.045+00:00 - [ INFO] - Block 866223 - Parsing complete. L: f83cdce, TX: 345df6f, M: 7f9003f (826.05s)
-
insane
-
6k+ txs per block in bitcoin blocks instead of the normal 1-2K is also insane š
-
tiny op_returns for the scaling win š
-
- 19 October 2024 (5 messages)
-
1 FORKOFF && 1 FORKOFF.WAR
https://tokenscan.io/tx/4d6edd7e7cacfea3b7733c47fdf9beef94d8865a52155ea05c265763415fe162
2 BADBURGERDAY
https://tokenscan.io/tx/532065a5c62b115fbe38275d2924b7fd56d4cdee123ca3706277555bab168d17 -
-
Oh dang thanks! We survived another fork off lol
-
-
I say I say Luckily jdog keeps those around for just such an occasion
- 20 October 2024 (2 messages)
-
Maximum Iāve seen is ~10k, never over 20kā¦ but it may be possible with segwit?
- 21 October 2024 (52 messages)
-
Does anyone know of a good channel or personality with constructive conversation about tokenomics that you want to share? Thanks
-
I think this channel can serve that topicā¦
-
More constructive dev conversations here than in "official" dev chat neway (sorry for using the trigger word Juan šļøļøļøļøļøļøšļøļøļøļøļøļø)
-
btw... being forced to update to the v2 API endpoints in counterparty-core.... cuz of course dispensers are not working in freewallet using the v1 API, and the answer from Adam is "its been depreciated 6 months"..... I mention it to you @juan so that if you want to have users use your 9.61.3 "classic" version of Counterparty... they should be able to do so all the way up to FreeWallet 0.9.34... will just need to change the API servers to point to their own 9.61.3 nodes.... If you run a public 9.61.3 node... LMK... wouldn't be that difficult to make a quick update to FreeWallet v0.9.34 n release a 0.9.34-xcpdev where the default API hosts point to your API server š
-
Sent you an dm.
-
Interesting and thank you for the offer. But I think is just better to let the leaves fall where they mayā¦
Kind of timely with the tokenomics topic actuallyā¦ as what I am most interested is in the permanent data capabilities of Bitcoin, not the tokens themselves.
Counterparty kind of had something going for it, no founders, thus more ādecentralizedāā¦ but that is no longer the case. Is now just another ācryptoā, even with the viral minting which Iāve always considered too easy to fake, thus inorganic.
Iām out of the tokens competition lol. And is fine, Iāve learned a lotā¦ and I still have some interesting ideas with xcp. But these would be more academic at this point. -
I look forward to your thoughts and contributions on XChain platform once it launches... will be much more community driven than CP is now (tho I imagine we will still butt heads on some views)... much more respect for you now than I had a couple years ago sir.
-
-
Very very excited!!
-
a fork of CP? -
-
Fun š¤©
-
yeah.... xcp.dev runs on 9.61.3.... Core devs forced a fork with 10.4 and not making sure everyone agreed with the changes.... the ONLY reason I got on board with the changes is cuz I didn't want users of freewallet to lose funds.... otherwise, would have just stayed on 9.61.3 like Juan and xcp.dev
-
I don't understand the idea behind that, as CP is moving forward but ... good luck, maybe.
Right now I'm hoping dispensers will soon be a thing of the past, and that the new features will allow people to access CP assets and features more easily. Fairmints are a good start. -
Could have implemented all these changes without changing / crippling dispensers and making it 3 txs to open dispensers and 3 to close and collect... I agree with most of the changes, but disagree with the way they were handled, and with changing dispensers and losing functionality simply to get rid of addrindexrs... and funny enough, now CP is gonna have to rely on an external component for UTXO management rather than addrindexrs
-
but hey, I made peace with having to move on many months ago... only reason I am riled up now is cuz all the stuff I SAID would happen is.... lots of hotfixes cuz not enough testing, users finally realizing shit is more expensive to use and more difficult, and of course.... depreciating an API unnecessarily and then trying to blame wallet breaking on me vs on core devs šļøļøļøļøļøļø
-
just frustrated I have to stop working on xchain-indexer (my own thing) to make all these emergency updates to counterparty / tokenscan / freewallet... when it all could have been handled MUUUCH smoother
-
Yes, but will depends on perspectives, in one side yes this will allow to bring counterparty to more people (degens mostly) but if your perspective is looking to counterparty as a decentralized way to store data and value in Bitcoin maybe fairmints is not what you are looking forward
-
I think longer-term yeah, atomic swaps will replace dispeners... but no need to break things in the process... coudl easily have kept dispensers working while ppl migrated to the new methods
-
Thank you for the respectful answer sir. š
-
I have found sentiments with both perspectives anyway
-
I think it is. It's also great way to to distributes NFTs, using a XCP price
-
memecoins generation is just a side of what fairmints can do
-
they still work, but they shouldn't be triggered just by sending btc to your wallet
-
especially when CP get a lof of newcomers
-
this could turn ugly as f***
-
with people sending their hard earn coins everywhere
-
Is right
-
talking about depreciating origin functionality... ability to open dispensers on addresses that are new/emtpy... went from 1tx to open/close to 3 txs to open and 3 txs to close dispenser and return funds to main address..... while I disagree with the new "dispense" method... at least it was handled in a way that was backwards compatible (auto-converting BTC sends to new dispense method).... the origin functionality was just stripped out without much discussion / understanding.
-
didn't even take the time to ask "why does this functionality exist"... simply stated "omg, that is bad" and focused on removing the functionality... ignoring any arguments that new/empty addresses with no tx history were not "opening dispenser on someone elses address" and instead went from 1 tx back to 3txs to do something
-
anyway... already said all this before, need to get back to working on tokenscan / freewallet updates... got another 7 hour tattoo session tomorrow, so gotta sling some code tonight. Appreciate all your viewpoints, might sound like i'm just angry all the time.... but, not the case... i've made peace with many of the changes and do feel most are updates (hell, I created MINTING in BTNS before core devs even returned)... but, some changes I still strongly disagree with, including ignoring the 9+ years of history n just making decisions for what is best for the community... IMO it is disrespectful to those in a "community" project
-
</end rant>
-
š
-
LOL... 2 separate issues.... "dispense tx vs normal BTC send".... re-read what I wrote... said that I disagree with it, but at least it was handled responsibly.... my core objection was to the removal of origin functionality, making dispensers more difficult to manage and requiring additional txs to move BTC and assets to a new/emtpy address before your "one tx to open dispenser"
-
Thatās not really true because you can only create a single dispenser on an existing address because you canāt choose a particular dispenser to trigger
-
anyway... back to coding... your a smart guy, you get it, you just choose to keep trying to move the goalposts and play semantic games
-
IMO the dispense message is incomplete as is, if you include a txid as a parameter then you could select specific dispensers to trigger giving users the ability to create as many standalone dispensers as they want on their main address
-
That said, no reason it couldnāt be added in the future
-
Atomic dispensers
-
But with the bind utxo fee would require to have XCp to open it
-
Yes but I was talking for an atomic dispenser
-
I need to dig more in the code anyway
-
But anyway for atomic dispenser utxos are required
-
The only way I see to avoid frontrunning
- 22 October 2024 (173 messages)
-
This could work, I will say having the generic dispense message did make upgrading rpw to support it much easier
-
Hello,
I'm playing with the utxo attach function and some questions arises for me.
Should we standardize a value for counterparty utxos?
Should we use 546 like ordinals and runes or would be better to go for another number (eg:547) to avoid confusions and to be able to easy recognize them.
Maybe it doesn't matter very much and is up to the platform that uses it but I believe standardize them is a good practice, want to know your thoughts
IMO 547 is a good option but is true many wallets has methods to avoid accidental assets spent setted in 546 sats so maybe 546 is a better option -
Is there a cp api call that identifies that assets are attached to utxoās? I didnāt see one? If so a standard dust value may not be a big requirement
-
theyāre indexed by address and appear in the balances call
-
i believe not obligate people at protocol level but standardize as consensus
-
Perfect I thought you mentioned that but wasnāt sure what call
-
so wont be possible to do one tx as we talked to buy the xcp to pay for the utxo binding fees....
https://github.com/CounterpartyXCP/counterparty-core/issues/2539Transaction chained with XCP dispense and utxo attach is just performing the dispense Ā· Issue #2539 Ā· CounterpartyXCP/counterparty-coreIm creating a tx to reduce friction for users when xcp fee is active (as i know that now is 0) that has 2 msgs: dispense for XCP encoded in multisig utxo attaching encoded in OP_RETURN its weird bc...
-
will requre 2 tx too when we agree here that the gas fee maked sense if there was a way to pay it on pure btc and dont make users to have to do 2 tx
-
afaict there are no XCP binding fees
-
not for the moment
-
but will be
-
is in the code, when more than 15 tx as average in 2016 block xcp fee wll be activated and grow in a sigmod curve
-
-
oof
-
and it is crazy how grows, is truth that has been talked about the possibility to multiply the xcp suppply for a 10 base (x100 or x1000) so the price would reduce but anyway this is an adoption stopper
-
you have now the facts that people is not trading fairmints in dex bc of the iliquid XCP
-
xcp has been an adoption stopper for 10 years lol
-
people cannot buy it despite they want
-
yes i know
-
well i guess we cross that bridge when we get there, should at least be an API endpoint to check the current xcp attach fee
-
but if were a way to dont show it to the user as we discuss here with the founders, and we all agree, that would not be the case anymmore
-
yes it is not, i openned an issue for this too, i had to reimplement it on js for my usecase
-
this will vanish that the cool thing about atomic swap...
-
are cool but not as cool as could be
-
and many users will complain...
-
new users will likely buy assets already attached to utxos so its more of an issue for existing users, is there a detach cost too?
-
but sellers will need to have xcp, so all the MINTS buyers will have a difficult time to list their assets, therefore to benefit from atomic swaps at scale... -
yep
-
it will certainly be a pain point
-
as XCP has always been
-
we already see that we had 100K mints in a bit more of 24h hours and how many bought xcp to buy the listings? we have a big example of what will happend with any platform keeping the same scheme
-
yeah, if buying xcp and binding could be done in one tx users wont feel any pain at all, while xcp would benefit a lot more for the friction reduction.
-
well the core devs will need to be convinced because theyāre very adamant about adding an xcp fee
-
I thought you were a core dev lol š¤£
-
i was a maintainer for a hot minute until adam and team took over
-
IĀ“m not against to xcp fee, never been. Even when the talk was about numerics, IĀ“m against friction.
-
Interesting viewpoint that the core devs need to be convinced by the community of a position different than their own views which they came to on their own without any community discussionā¦. And here I thought this was a community driven project where the features and innovations were driven by the communityā¦.. or at least thatās how itās been the past 9+ years while they were goneā¦. But clearly things are a bit different now.š¤·š»āāļø
-
Disagree with my views if you want, but itās clear that the core devs drive this project now, not the communityš¤·š»āāļø
-
this looks like it's in the V11 release slated for Nov 1. I updated the GH issue with that reference.
-
it's definitely been discussed
-
yeah totally I remember, none of us were against the fee if there was a method to abstract it for end users.
-
yep
-
this has always been the case, ive disagreed with a lot of changes to the protocol over the years, the community has many different ideas of how things āshould beā its impossible to please everyone
-
This is how itās always been huh? Strange when John and I were developers, we took our direction from the community and let them decide the best course of action after much discussion.
Surely you remember this Joe when we had 90 to 95% of people saying they wanted a fee on numerics in May 2 years ago, yet because there wasnāt enough consensus for me to feel comfortable, forcing that change on people, I didnāt.
As a matter of fact, I believe you even agreed with that change š¤·š»āāļø
As Iāve said, it is what it is, itās clear you decided to back the core devs regardless of if they make changes which make counterparty more difficult to use.
Iām sure in the long run counterparty will be fine, and I certainly hope that the core developers stick around this time after VC funds run outā¦.. It just sucks for the community thatās been here for many many years to have to feel the pain of dispensers and other features being much more expensive and difficult to use now as a consequence of the developers pushing their ideas forward over very vocal community members. -
If you remember I was against subassets in the first place
-
Itās pretty funny to me how the same people who were touting all these great changes and saying you could do dispenser transactions with only one TX are now mysteriously silent when it is proven that in fact, that is not the case.
But what do I know? Iām just a toxic developerā¦ -
You were against the current implementation of sub assetsā¦. As you had come up with your own version of sub assets and its implementation not on a protocol level.
I remember all the history quite well š¤·š»āāļø -
Exactly, I deferred to core devs when things didnāt go my way
-
eh... if thats how you view it, I guess that is your viewpoint... I see that there was much discussion on subassets and how to implement them and various proposals were discussed... and ultimately the COMMUNITY decided the best path forward, not the core developers
-
Search results for '' - Official Counterparty Forum (ARCHIVED)
The Counterparty Discussion Forum is now available here: https://github.com/CounterpartyXCP/Forum/discussions
-
but I digress... pointless rehashing history, not gonna change the current state of things, or your viewpoint that everything the core devs are doing now in this "community" project is "right".... to each their own š¤·ļøļøļøļøļøļø
-
I disagree with a lot!
-
IMO the dispense message is incomplete as is, if you include a txid as a parameter then you could select specific dispensers to trigger giving users the ability to create as many standalone dispensers as they want on their main address
-
For example
-
Strange, haven't heard that viewpoint or objections... All i've heard/seen is the wholesale embracing of core dev changes... Haven't seen you weighing in on the github accounts, which apparently is the only place that the core devs really feel is the right place for feedback
-
anyway, to each their own... no point in us bickering, we have differing viewpoints on what is right for the community, and how to treat those in the community. Time will tell which approach is the best.
-
-
I will say that I argue with the current core devs as much or more as I would argue with you about design decisions
-
In private rooms which are not public... strange to keep your viewpoints to private rooms which are not the channels that have been used for many years for counterparty discussions. Also strange how the core devs choose not to engage in public chat rooms much.... or to be transparent in their disclosure of VC funding... Seems like one would want them to be transparent in such matters for a community project. If your objecting, that is great, maybe try to do so publicly.
-
I am not alone in my viewpoint that the lack of transparency is concerning, and feel that in the long run, they will not do what is best for the community. Time will tell.
-
Keep in mind that most of our disagreements over the years didnāt happen in public either
-
I disagreeā¦ we never had any private developer channel except for when the fork happenedā¦. Most of our discussions happened in the rare Pepe scientist chat and weāre not focused on development.
-
And the only reason that there was a private developer chat in the last few months was when you and the other core developers were added to the core dev teamā¦. And of course, the fork channel which records have been made public since.
If you wanna keep engaging in private, thatās fine , but I would venture to say that 98 to 99% of development chat on counterparty has happened in public channels, except in the case of very intense topics, where in the interest of the community conversations were kept private, so as to not indicate a sense of discord among the leaders of counterparty who were supposed to all be on the same team -
Disengaging now. Hope you have a great day. šš»
-
is the new tatto of the counterparty logo btw?
-
Arguing in public is generally performative and doesnāt really result in understanding, it just begets more arguing. Iām not trying to rally the troops with my design opinions but instead trying to get the devs to understand my viewpoint. That said, my opinions in public are the same as in private so feel free to ask if thereās anything in particular.
-
at least the public bickering usually ends up in some fun new asset artwork lol
-
-
This a cool idea, if the intention to build and improve the case use of a Dispenser
-
No xcp for binding utxos. I think this should be thought about.
-
or in default allow binding and buying xcp in one tx.
-
What technical improvements does using xcp to bind an asset achieve?
-
-
Maybe somewhere down the line
-
For art. I think it's workable
-
Slow and steady sales and volume.
-
Totally! Public discussions n artwork from those discussions can be hilarious
-
-
-
-
Remember folksā¦ it is ok to adjust your dosing amount, frequency and strain from time to timeā¦
-
@BrrrGuy please dont post links to this channel in the gen pop cafeteria and fuck up a good thing. We donāt need all newbies and scammers flooding this channel too. Iām glad you like this channel. It would be nice to have a channel sans drama.
-
thats ok, I prefer Juan's channel where there is actual dev chatter in an uncensored way (funny enough, adam left that chat long ago after making Juan a core dev, then removing him from the repo and banning him) @xcpdev
-
I can respect that... will edit to remove the link š
-
Sorry for the drama... I have no plans to take over CP chat or ban adam... simply wanting to get answers to who is behind the VC funds and why they are not being transparent... didn't expect all this "ban the guy asking questions and paint him as a troll"... Once Adam answers the question, will happily unpin the message in the channel, and give him back Admin powers šļøļøļøļøļøļø
-
Right
-
Seems project is more ācrowd sourcedā than āopen sourceā. They also may not be able to discuss VC funding.
-
Again, nothing wrong with VC funding, ppl do deserve to get paid... However since they are the core developers on a "community" project, there should be transparency on where funds came from, in order to make sure that their values are still in align with the community. Might not like me personally, but not trying to attack the core devs... simply trying to get answers as to why not being transparent.
-
UL is not a foundation for xcp. They owe the community nothing in regard to vc disclosures.
-
OPEN is a desirable feature
-
Use of donations from the community are about all that MAY be considered for disclosure.
-
Not negotiable
-
This is where details matter. Open source software, free and easy to fork. The ledger is not free or easy to fork. People like gmoney do not understand the difference or technical details and scream over those who do.
-
-
Levels of meta. XCP started first, but has way more (each protocol update basically, which are forks)
-
@uanbtc any plans to update versions any time soon? Or plans to strip the code base of telematics and roll your own? What do you think about the newest versions?
-
If by upgrading version you mean playing the Unspendable labs corporate takeover of counterparty. No.
xcp.dev will stay in v9 -
Feel free to share a roadmap or checklist of needs if you want some help.
-
had to ban myself from that main channel. this one is more fun
-
Yeah just got up to date. And there is a new channel now, for more central control.
The takeover is so obvious lol. And very educational if you donāt take it personal.
@ABlue0ne my plan with Counterparty is educational/academic from now on. Donāt care about the ledger (even if I still have assets (anyone interested?lol)) -
Ditto. Still with you, same stance as years ago.
-
Much appreciated bro
-
You too
-
I think I may be reading conflicting stories, but the chats are too flooded to research meaningfully.
Is the v10.x.x API backwards compatible or no? What is the status of API v1 & v2? -
Much of the āis 100% backwards compatibleā claims are false, because they arenāt 100%. Many are partial compatibilities with nuancesā¦
Any specific one? Maybe I know the answerā¦ -
staying on v9 def missing out on the fun of playing with utxo attached assets
-
your asset sends could look like this https://mempool.space/tx/7045337252b3c988df1047459ad77f7cc3858ad1c6a3130a7725938cd745cc5aBitcoin Transaction: 7045337252b3c988df1047459ad77f7cc3858ad1c6a3130a7725938cd745cc5a
Explore the full Bitcoin ecosystem with The Mempool Open Source ProjectĀ®. See the real-time status of your transactions, get network info, and more.
-
I think jdog might have something to say here.
I have an idea that could help users pick sides, but would probably require that 100% backward compatibility to be true. -
Brrr Guy in Official Counterparty Dev Chat
Seems like MPMA sends are broken in the /v2/ API... as the documentation seems to indicate that destination is a single address. Using the /v1/ API I am able to pass an array for destination, asset, quantity, memo, and memo_is_hex... Because the POST request encodes all the params/data using JSON... However in the new /v2/ API endpoint, which requires the use of GET, I am unable to pass an array for these fields. https://counterpartycore.docs.apiary.io/#/reference/compose/compose-send Can @teysol please give an example of a VALID compose-send API request to do an MPMA send using your new /v2/ API endpoint?
-
Not really a backwards compatibility issue here. But along those lines.
-
Looks like a normal bitcoin transaction, no embedded data right?
Wasnāt this the criticism to dispensers?? -
im just sending an asset attached to a utxo here
-
counterparty-core-1 | 2024-10-22T18:05:34.442+00:00 - [ INFO] - Block 866880 - Move GORF from utxo: b74ee2320a820615d5f70ea455262a7e6a6d0ab3e705be601fff6a8658ba6ac5:0 to utxo: 7045337252b3c988df1047459ad77f7cc3858ad1c6a3130a7725938cd745cc5a:0 (7045337252b3c988df1047459ad77f7cc3858ad1c6a3130a7725938cd745cc5a)
-
Well, if it REALLY was 100% backwards compatible, it should just work. That is what 100% means to me
-
I guess in jdogs instance, the question would be, does the v1 work as expected.
-
txindex != addrindex
-
He didnt say those things.
-
Both fair points
-
Not sure what you mean
-
Related though, fun to see how addrindrxs has been kept, while xcp.dev has been running without it for months.
Never waste a good scapegoat I guess š -
seeing if an output is spent is much different then seeing if an address received bitcoin, its fundamental to bitcoin vs maintained by another piece of software
-
Ok I see what you mean. That is not my point though.
I donāt see any issue with a full Counterparty node requiring address indexing. Specifically when there is no need to maintain it, as electrs or any other electrum supporting software works vanilla, no custom modifications.
Any full featured node+wallet wants this. -
i agree, but it shouldnt be involved in ledger consensus
-
I think that is only relevant for the ānever used addressā
-
absolutely necessary for wallet
-
yes i believe thats when it was tied in to consensus
-
Yep, so is not relevant to utxo binding, and ONLY relevant specifically for the ānever used addressā dispensers
-
Juanās been keeping up
-
exactly, thats when it became relevant
-
but the idea to add a message to control dispenser behavior is a good one, it should just have more options
-
if we had that from the start no one would have ever accidentally triggered a dispenser when sending themselves funds from an exchange
-
@hodlencoinfield are multisig transactions (think old school large assets) still possible in any v10+ version? Do any wallet/endpoint combos support those transaction types today?
-
what do you mean?
-
multisig encoding is still available in the API
-
Yep only one was removed, one that required 2 transactions AND the same node instance. It was very inelegant I donāt mind that one being killed. It was supposedly cheaper though
-
Yep, but still not related to the utxo binding discussion haha. But is fine not need to continue
-
Have to see the positive, all the v10 refactoring (which is not a one-sided definite better than v9) has taught me a lot
-
you were the one that brought up dispensers
-
J Loone Brickens š§± (@wasthatawolf) on X
buy one GORF for 10000sats by completing this PSBT...
-
we're PSBTing boys
-
I think Juan may be speaking of claims made by others, in previous conversation long ago, to justify their stance. Maybe.
-
There was a bit of tangent going on but is fine, Iām already too active today on the chats š
-
@BrrrGuy stop moving or itāll come out blurry.
-
Nopeā¦. Had issues with the dispensers not working in v1 since the 10.4 releaseā¦. Updated to use /v2/ api for sends last night, still getting reports of btc sends not auto-converting to dispense txs as they were supposed toā¦. Seems to be working inconsistentlyā¦ so, will make updates to freewallet tonight/tomorrow to check destination address for a dispense when sending BTC n generate a dispense tx instead of a send.
-
-
Still getting tatted for a few more hours, so will do it l8r
-
Taking a few minute break to get some lunchš¤·š»āāļø
-
And you brought up addrrsindexrs, that had nothing to do with the āmessage in transactionā point I madeā¦
Which Iām sure you know
(Sorry everyone, but just couldnāt allow falling for the tangent. Should know better.) -
NB, Very MC Escher-esque
-
any idea what does this means?
[ ERROR] - Asset conservation check failed: 2592107.11808124 XCP issued ā 2593894.67876698 XCP held -
Looks to me like what used to be called a sanity checkā¦. Where the balances table was checked against the credit and debits tables to make sure that everything matched up supply wiseā¦.. not sure what asset conservation check is now, but that would be my guessā¦
Does counterparty-core exit on that error? -
yes
-
well, I guess you better bring it up with the counterparty core developers thenā¦. In whatever chat rooms theyāre choosing to participate in nowā¦.. I donāt see any here so theyāre probably not aware of the issueš¤·š»āāļø
-
This on 10.5.0-rc2?
-
10.5.0 last release from this morning
-
10.5.0-rc.1 was working good
-
[ERROR] - Asset conservation check failed: 2592107.11808124 XCP issued ā 2593894.67876698 XCP held Ā· Issue #2553 Ā· CounterpartyXCP/counterparty-core
counterparty-core-1 | Counterparty Core v10.5.0 counterparty-core-1 | Verbosity: 0 counterparty-core-1 | Quiet: False counterparty-core-1 | Network: mainnet counterparty-core-1 | Configuration File...
-
maybe should go back to 10.5.0-rc.1 until some fix
-
Iām still on rc-2ā¦. I think Iāll hold off on updating for a bitā¦. Thanks for the heads up on this sanity issue.
-
but what is rc-2?
-
i cant find it
XCP Dev Chat
Public archive of Telegram messages.
- 03 Oct 2024 (39)
- 04 Oct 2024 (9)
- 05 Oct 2024 (1)
- 06 Oct 2024 (1)
- 08 Oct 2024 (1)
- 09 Oct 2024 (7)
- 10 Oct 2024 (63)
- 11 Oct 2024 (9)
- 15 Oct 2024 (19)
- 18 Oct 2024 (126)
- 19 Oct 2024 (5)
- 20 Oct 2024 (2)
- 21 Oct 2024 (52)
- 22 Oct 2024 (173)
- 23 Oct 2024 (76)
- 24 Oct 2024 (52)
- 25 Oct 2024 (6)
- 26 Oct 2024 (6)
- 27 Oct 2024 (49)
- 28 Oct 2024 (1)
- 29 Oct 2024 (9)
- 30 Oct 2024 (1)
- 31 Oct 2024 (1)