- 01 December 2023 (2 messages)
-
Release v9.61.1 · CounterpartyXCP/counterparty-lib9.61.1 Release Notes This is a hotfix release which fixes a parsing issue which stops counterparty from parsing. Fixed invalid null description on first issuance (PR #1283) Fixed issue with transa...
-
Counterparty encountered a parsing issue with the new issuance IDs and doing a first issuance with description set to null...
Javier and I identified the issue immediately after 9.61.0 activation in block #819,301. The issue was identified in my testing of the new issuance formats on mainnet.
Counterparty API servers were down for a total of 31 minutes while Javier and I diagnosed/debugged the issue, got a fix in place, tested it, and deployed it to the API servers.
Additionally, I have also done a bunch of tests of the new issuance formats (asset/subasset ids 22/23) on mainnet... issue, reset, lock, transfer, etc.... all seem to be working as expected... so, putting out this hotfix release ASAP. - 02 December 2023 (24 messages)
-
Make sure you follow the steps to upgrade to 9.61.0… sounds like you skipped updating addrindexrs
-
Not sure of ur environment… I run all my fednode on dedicated hardware.
-
-
cd federatednode/
git pull
fednode stop
fednode update
fednode stop
fednode rebuild bitcoin bitcoin-testnet --no-cache
fednode rebuild addrindexrs addrindexrs-testnet --no-cache
fednode rebuild counterparty counterparty-testnet --no-cache
fednode stop
sudo su
rm -rf data/addrindexrs/*
rm -rf data/counterparty/*
exit
fednode start -
Run those commands to update ur fednode n rebuiild addrindexrs n u should be good👍🏻
-
-
Hi, I have an issue with closing a dispenser.
From Freewallet, when I attempt to close a dispenser from open_address, CP returns the error "no asset X dispenser from this addy"
I know there was an update on it and so I've tried to close from source, creating the same tx as the open dispenser but with "escrow 0, give 0, status 10" and broadcast it.
Dispenser is not open anymore but in "pending" state, no assets return =/ have I made something wrong?
disp: https://xchain.io/tx/83e4691b7021494712a226adfd3e7084bd695362139bb4a8ff289784d757817d
close tx:
https://blockstream.info/tx/1a9dca6ff78a27da6906176ab284753d46f917bd3eea64da083925a0c68a25dbBlockstream Block ExplorerBlockstream Explorer is an open source block explorer providing detailed blockchain data across Bitcoin, Testnet, and Liquid. Supports Tor and tracking-free.
-
"result": {
"tx_index": 2541221,
"tx_hash": "83e4691b7021494712a226adfd3e7084bd695362139bb4a8ff289784d757817d",
"block_index": 819191,
"source": "bc1qmpnde0wl2quf0kmzvnf7q5mhpkt92ytm96v6yf",
"asset": "A241301190000000002",
"give_quantity": 1,
"escrow_quantity": 200,
"mainchainrate": 27000,
"fiat_price": "",
"fiat_unit": "",
"oracle_price": "",
"satoshi_price": "",
"status": 10,
"give_remaining": 0,
"oracle_address": null,
"oracle_price_last_updated": "",
"asset_longname": null
},
"id": 0,
"jsonrpc": "2.0"
} -
showing as closed
-
there is a 5 block delay now on closing so thats probly what the pending was
-
Oh sorry thx, forgot there was this "security". Awesome 🔥 gg for this great feat
-
FYI... issue was a display issue on xchain.io which has been resolved.... your dispenser should now show "Closed"... I also added the origin field to the dispenser page.... should make it easier to see exactly what address funded a dispenser... and when a dispenser is closed, make it easier to track where the escrowed dispenser funds went (either to source or origin address)
-
I see in this transaction you were using the new origin field to close the dispenser and return the funds to origin... so figured origin address might be a good thing to add 😛
-
you can see when you closed the dispenser, the escrowed funds were credited back to the origin address 🙂
-
-
This is awesome, no more need to send back assets or send funds to the dispenser without enough funds to close/send back. 💪
May need to update FW with this tho -
yeah... i'll make some updates to FW to make managing addresses from origin a bit easier.... the FW update I put out a couple days ago DOES do away with passing the description forward in issuances... so, asset transfers are really cheap now for users and they dont lose their asset description... so latest release takes advantage of SOME of the new features... will work on adding more to FW, as always ;)
-
I believe joe is going to be building some address management stuff into RPW as well... this origin update (Joes idea) is amazing 🙂
-
this also allows dispensers to go direct to cold storage
- 03 December 2023 (65 messages)
-
This is great for all 0 asset stamps where the only way to sell would be through ownership transfer on the issuance.
Otherwise stamps with assets only key off the issuer/creator/artist field and rely on ownership of the underlying tokens. Transferring ownership at the issuance level serves no real purpose on anything > 1 qty.
We relied on this expensive mechanism to help prevent users doing such things previously, but now the doors are open for more 0 issuances in reality since they can be cheaply sold/traded. -
Whose idea was this in a world where 0 issuances are seen as spam?
-
I’d seriously vote to roll that feature back to avoid more controversy
-
It’s to the benefit of stamps that they don’t need to be restamped on transfer, but really it’s just an expected behavior, if you aren’t changing a description in your message there’s no reason to have to rewrite it
-
Now all src-20 tokens and similar become tradable on the issuance level further incentivizing such behavior of spamming
-
They always were just slightly more expensive
-
There is zero benefit here realistically as described
-
The benefit is for stamps that aren’t src20 and anything with a long description
-
It serves no purpose. Stamps are immutable. Creator/issuer can not be changed and all ownership is at the asset layer. The owner field on the issuance is ignore for a reason on anything but 0 issuance
-
So now that src-20 are easily transferred they can now be usable on CP so the spam argument disappears
-
They’ve always been transferrable
-
But the cost made it not worthwhile
-
Really? Isn’t an src20 small?
-
Even so they are usable on CP so the spam argument is even more nonsense now
-
But it’s really beside the point
-
Not really. This was a bad idea and encourages more 0 issuance which are frowned upon
-
It’s not an update for stamps, it’s an update for all of counterparty
-
Oh well he specifically mentioned stamps above.
-
Assets that use arweave for example, the description is too long to use opreturn
-
I’m sure it’s fine for CP just not well thought through on the position of anti-spam
-
I wouldn’t call it an anti spam mechanism
-
Well this encourages “spam” through more 0 issuances
-
Spam is ok if it’s not stamps basically is what I’m hearing lol
-
I guess we’ll see then, you know more why someone would do these types of txs
-
?
-
Yeah and as I say it drastically increases the usefulness of 0 issuance stamps or not. From prior chats 0 issuances are considered spam
-
I mean it did open up a lot of potential for us to build some creative things but I fear it would create more fire alarms of spam.
-
Imagine src 20 used shorter descriptions where they fit with an opreturn anyway then this has zero effect
-
Then they wouldn’t be immutable and the whole thing is ded
-
What?
-
Opreturn not immutable?
-
As tied to the stamp meme
-
Not an option really
-
I mean you guys can make up your own memes whatever, this update just happens to help you because you use long descriptions for your memes
-
Nbd just fair warning if zero issuance flood the table again. This makes it a ton easier
-
I’m not about to have that argument lol
-
This encourages them
-
If that’s a side effect then I guess we’ll find out
-
Sounds like you were gonna do it anyway
-
I don’t know why a couple dollars would change your mind either way
-
If it’s for the meme then do it or not
-
Wouldn’t do unless something like this came along to open up more potential lol
-
I’m glad the update is a positive for you!
-
if zero issuances flood again, the community and maintainers of the project can decide what the best tactic is to deal with them.... a.) Add an XCP fee on every issuance, not just first, including numerics.... or b.) add a rule that new issuances must issue at least 1 supply.... point is, as spam comes up, CP community can react quickly and appropriately.
-
That’s what I was trying to tell everyone, all good stuff people want
-
as long as it doesn’t create more arguments later it is
-
We can’t predict that
-
Plus there will always be arguments
-
They will never end
-
Lol. How come we don’t have any arguments on stamp dev. Too early to find them I guess.
-
You’re all chasing the dragon still
-
Arguments are good imo
-
-
It means people care and want to stick around
-
maybe cuz you left the channel? 🤷️️️️️️
-
Easier to leave then argue
-
Lol that was your channel for trolling not the actual stamps dev group.
-
ahh... my bad... your right it was the channel I created on day 2 of stamps and invited all the devs to to try and coordinate.... sorry you saw it as a trolling channel... water under the bridge... lets move past it
-
My main point here is please do not claim something is good for stamps when it has zero impact or even a negative impact to the stamps community by making it easier to waste fees on changing a db value that is not used in the stamps ecosystem. And when it is it’s only on the 0 issuance which are always of contention so this is a very confusing claim.
-
-
I suppose a simpler request to digest would be just remove the word stampers from your post lol
-
comment here edited to remove the word "stampers"... it now says... "so, asset transfers are really cheap now for users and they dont lose their asset description".
-
-
🤗
- 04 December 2023 (61 messages)
-
Long descriptions must be encoded on transfer to make the DB impact propositional to the BTC fee. Please don't tell me this is not the case anymore. -
Haha my point exactly. Was an anti spam mechanism.
-
inconsistent arguments saying some things are spam on issuances, but making it cheaper and easier to spam the table in other types of transactions.
-
If we see issuance spam becoming a problem, we can address it by instituting a per-issuance XCP fee (which your in support of last time I checked)
Cheaper asset transfers without messing with the existing asset description is a net positive for end-users (smaller/cheaper tx)
Had I been able to institute CIP31, to limit asset descriptions to 1024 characters in the database, spam/bloat potential would be greatly limited…. But ppl wanted to push back on that update…. These updates were meant to be rolled out together…. so yeah, we are where we are🤷🏻♂️
https://github.com/CounterpartyXCP/counterparty-lib/pull/1276
If/when we have an issue with spam/bloat, we can address the issue when it presents itself as a problem…
TLDR, yes asset transfers don’t require asset description to be re-encoded in a tx… if that’s a problem for the community at large (not just a couple devs) it can be changed 👍🏻CIP31 - Enhanced File Encoding Support by pataegrillo · Pull Request #1276 · CounterpartyXCP/counterparty-libCounterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
There’s no additional impact to the db on transfer, in fact there’s less because you don’t need to duplicate description
-
The asset exists with a description, all that changes with this update is that on transfer if a new description isnt specified the previous description remains
-
If src20 wants to transfer assets around this doesn’t change anything, they’ve always been able to do that and reference the initial description even if counterparty says it disappeared, I mean you made up your own protocol so there’s nothing stopping you from changing more parsing logic
-
You don’t restamp every time you send a stamp
-
Really? The db duplicates the description in a new row. After an optimization this might not be a problem. But as of now we have a situation where you can duplicate stamps over and over almost for free and bloat the db.
Or am i missing something? -
yup, descriptions are copied in the database from last issuance... so your correct, descriptions duplicated... prolly should been able to limit it to 1024 characters like I wanted to..... again, if this becomes a problem. we can address..... but, seems like right now lots of being upset without any actual problem yet.... and if a problem happens, we can easily fix with a per-issuance XCP fee.
-
also another option would be to change the way that CP looks up asset description... so that we stop storing the duplicate description in the database, and instead lookup the last issuance with a description... easy fix/tweak to solve this "spam" problem which we dont have yet
-
oof
-
is description is stored in any table besides issuances?
-
nope
-
why not just put the null in the issuance tx then?
-
and the API would refer to the newest one that isnt null
-
we could do that... but would require changing the logic to lookup the asset description.... not the route we went, but a simple tweak should you guys decide to go that route
-
do you know off the top of your head which API calls are affected?
-
is it just get_asset_info?
-
should be a pretty simple change, and its non-consensus
-
would just be some custom sql query logic on top of the standard get_{table} logic (hate putting hacks in there.. prefer we keep it standardized to dump data direct from table as it is in database, with no tweaks to output)...... to change would need to add some additional SQL query logic on top of get_issuances to pull out the last issuance with description != null
-
get_asset_info has to query multiple tables tho
-
lol... ur too fast
-
only talking about get_tables now... havent had a chance to dig into get_asset_info... but yeah, would require tweaks there too 🙂
-
what would need to change in the issuances table?
-
just store null
-
so basically you are swapping BTC fees for XCP fees in this case
-
no
-
there was never an xcp fee for asset transfers
-
in what j-dog mentioned anyway "if it's a problem"
-
just would need to start storing null instead of asset description... then have SQL queries that lookup asset info to pull the latest issuance where description != null
-
well JP pointed out that it is a problem and its a pretty easy fix
-
yes exactly
-
but its just that one query i think
-
and we all know XCP fees simply force a fork lol
-
are you having a separate conversation?
-
im just confused where XCP fees came in related to asset transfers
-
J-Dog "and if a problem happens, we can easily fix with a per-issuance XCP fee."
-
i disagree that would be "easy"
-
we saw the fiasco in may when that was brought up, not a pill most people want to swallow
-
I'm supportive of this change.... didn't have the energy to push forward any more changes myself... but I have no objections to storing null instead of the asset description again... and tweaking some sql queries to pull out correct asset description... pretty simple tweak... could be 9.61.2 n rolled out with some additional updates/tweaks (database optimization with indexes) in the next release 🙂
-
but the current issue with duplicating descriptions IS an easy fix
-
saying code implementation would be easy... community reaction / pushpack... not so much 🙂
-
yeah plus we need to add transaction_outputs table query too
-
these are non-consensus updates so i def support getting them rolled out next
-
I believe when we were talking about putting on the flat XCP fee on numerics... JP mentioned that ppl could still spam issuances pretty easily... and that perhaps a per-issuance fee might be a better long-term plan.... I think he proposed like 0.01 XCP per issuance or something... thats where that reference is coming from 🙂
-
gotcha
-
IMO the focus should be on db optimization first
-
at the end of the day all the data we need is stored in bitcoin block dat files
-
zero quantity records / database purge · Issue #1113 · CounterpartyXCP/counterparty-lib
Still seeing issues with 0 quantity records being created... this is bloating the database unnecessarily.
-
removing zero quantity records, purging the database of them, and adding database indexes would reduce CP footprint and make parsing/querying faster.. 🙂
-
Fixed primary keys not being created because of duplicate names by pataegrillo · Pull Request #1281 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
absolutely... Javier and I were talking about addrindexrs and counterparty... and we SHOULD be able to tweak addrindexrs to store a bit more data.... but then Counterparty wouldn't need to talk to bitcoin to pull tx data anyore... addrindexrs would have it all.... SO, a FULL PARSE (currently 2 weeks of parsing) should take as long as a REPARSE (24 hours)..... perhaps someday 🙂
-
would be nice to have the full parse vs reparse drama go away... make a full parse faster 🙂
-
yeah that would be awesome
-
why would zero qty issuances need to be purged? there are many times artists create even a named asset with 0 qty to later add art and increase the qty. wouldn't this destroy that historical record, or how would these then be queried?
-
not the issuances
-
you're misunderstanding the problem here, its related to purging zero quantity balances from addresses
-
ah ok thx
-
essentially once you've held an asset in your wallet a reference to it always remains, it just goes to 0 qty after you send it
-
thats why if you sweep a big collection that had a lot of activity you might see a lot of 0 balances
- 05 December 2023 (10 messages)
-
I opened a github issue regarding null descriptions. https://github.com/CounterpartyXCP/counterparty-lib/issues/1287`null` asset description and DB bloat · Issue #1287 · CounterpartyXCP/counterparty-lib
New behavior in 9.61 is that a special null asset description set in the CNTRPRTY message makes Counterparty duplicate the previous asset description. This is a concern as the BTC fee of updating a...
-
When closing a dispenser using the api do you specify the escrow quantity when the dispenser was initially opened or the current amount still in escrow? or can you exclude that field? ... I am guessing its source, asset, give_quantity mainchainrate znd open_address that are required fields and escrow_quantity isnt playing role in a close ? due to the fact it can change between when a close tx was broadcast and when it gets confirmed -
I've put everything at 0, with status 10. Dunno what's required but it worked
-
I have found 'give_quantity', 'escrow_quantity' and 'mainchainrate' can all be 0 when closing a dispenser opened on a 'open_address'
So the API call only needs to know the 'asset' and 'open_address' to create a close transaction (status: 10) from the source -
I dont know about api but here is the opreturn msg for closing dispenser: https://jpja.github.io/Electrum-Counterparty/decode_tx?tx=6bef5be1766b87f90f94de1f01fee0613248b9aed7a1e164e11667783eea6221
Closing dispenser has the same message id as for opening, 13
Then 8 bytes with asset id.
Then 48 zeros.
Then 0a, meaning status close.
I havent looked into how it works when closing dispenser on another address. I guess the address then is encoded in the next 21 bytes. -
also... be careful when closing oracled dispensers to NOT include the oracle_address field in the API call to close the dispenser..... found an issue in testing where CP tries to re-include the oracle fee in the closing tx (paying the oracle again... which is not desired)... https://github.com/CounterpartyXCP/counterparty-lib/issues/1271paying oracle fee when closing dispensers · Issue #1271 · CounterpartyXCP/counterparty-lib
In testing dispensers, I discovered that when closing a dispenser, if you specify the oracle_address in the API request, then the resulting TX includes the oracle fee in the tx. CP should only coll...
-
will get this fixed in the next release 🙂
-
thank you .. I am not using oracle's at this time .. but appreciate the info
- 06 December 2023 (11 messages)
-
I really do need to get my head around the op_returns so as not to be as API dependant .. its on my list and your work is a great help in understanding.
-
do you have many small utxos? if so then consolidate them
-
Any wallet allowing you to "send all btc", like wallet.xcp.ninja or electrum but NOT TODAY. At 250/vB, any utxo under 40k sats is dust, 18k for segwit
-
eg: dust means it cost more in gas than the utxo balance to use it
-
Is this what the big deal is about? Thanks for eli5. -
These types of posts are pure gold. Thanks.
-
It’s not a big deal really, it’s more a big opportunity to clean up the db
-
An easy fix to support and implement in a minor release at least 🙂
- 07 December 2023 (6 messages)
-
BTNS has a Rug action? Am I reading this correctly? Showing previous rug dispensers?
-
I’m reading on the technical differences re: XCP vs BTNS. Any thoughts?
-
Broadcast-Token-Naming-System/docs/actions/RUG.md at master · jdogresorg/Broadcast-Token-Naming-System
Broadcast Token Naming System (BTNS) specs, docs, and tools - jdogresorg/Broadcast-Token-Naming-System
-
BTNS is a token playground... ppl get rugged all the time.. so figured why not build a fun "rug" feature... ppl can lock tokens against it easily... but could be some fun projects that use self-exploding tokens, etc... goal with BTNS was to just have fun experimenting with what is possible... anyway.. if you have any more BTNS specific questions, prolly best to ask in the BTNS channel... https://t.me/BTNS420Official BTNS Chat (EN)
This channel is for discussing the Broadcast Token Name System (BTNS) and the platform's features. Site: btns.wtf Wallet: t.me/freewallet_io Explorer: btns.xchain.io Twitter: x.com/BTNS420 English : https://t.me/BTNS420 Chinese : https://t.me/BTNS420CN
-
Thanks. I’ll try to read through the past to catch up.
- 08 December 2023 (1 messages)
-
- 09 December 2023 (9 messages)
-
Hey correct me if I'm wrong but multi dispense has been enabled for a while no?
It means if I do a send btc to multiple dispensers, I'll be credited for all of them? -
it was mentioned in regard to latest Counterparty update
-
allow triggering of dispensers by all tx outputs, not just the first output by pataegrillo · Pull Request #1222 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
I do see activation block 819300, was just wondering if anyone tested it or if I have to
And if so, sharing me some tx to check this out.
Great feature @CP-devs btw -
JDog performed tests on testnet and documented them in the pull
-
I have unsuccessfully did a pay to many before when trying to hit multiple dispensers didn't work out great for me from what I recall this was around a year ago -
Ofc it wasn't released until last update I believe. It was on dev for a couple months now (~march I believe)
-
Good to know
-
I'll make some tests myself and come back to you if I have good results
(if someone has a working it would be waaaay better, thx) - 10 December 2023 (8 messages)
-
🔥🔥🔥
-
Everyone, this is Adam Krellenstein, one of the original founders of counterparty and dev who wrote most of the codebase.
Happy and honored to have you here Adam. -
- 11 December 2023 (30 messages)
-
Hi Adam! I've been a fan of yours since the early days on Bitcointalk. Great to see you around. Hope all's been well with you. -
Hey, don't know if anyone can sort me out but I have a tx opening a dispenser that don't look to appear in
xchain and api.counterparty.io
https://mempool.space/tx/935dfc25d13223409da34341c5083e83a357fc3077abffb07a040d74e987c902
fetch("http://api.counterparty.io:4000/", {
"headers": {
"authorization": "Basic cnBjOnJwYw==",
"content-type": "application/json; charset=UTF-8"
},
"body": "{\"method\":\"get_dispenser_info\",\"params\":{\"tx_hash\":\"935dfc25d13223409da34341c5083e83a357fc3077abffb07a040d74e987c902\"},\"jsonrpc\":\"2.0\",\"id\":0}",
"method": "POST"
});
Note in CP api, it randomly answers an empty response or not, same using tx_index: "2547505"
Any thought? -
Not storing [dispenser] tx [935dfc25d13223409da34341c5083e83a357fc3077abffb07a040d74e987c902]: invalid: cannot open on another address if it has any confirmed bitcoin txs
-
Looks like the dispenser failed to be created because the address had already been used (got error message from logs).
-
Could be that the Bitcoin Pump led to everything pumping. We saw a massive resurgence with Stamps and SRC20. BRC20 as well. -
Degens seeking new alpha
-
Ok make sense thx
-
@jdogresorg It looks xchain is out of sync, am I wrong?
-
yup... check main cp channel.. I mention it there... related to BTNS ppl spamming like 30k broadcasts over the course of a few hours...
-
-
parsing is working on getting caught up... gotta take my son to school.. .will be back in 2 hours.... xchain will keep parsing blocks until it comes back up to current 🙂
-
Thanks sorry for not having checked the other 🙏
-
sawl good.. I have troubles keeping all the chats straight myself 🙂
-
30k 🤯 -
It dissolved a couple years back - 12 December 2023 (13 messages)
-
Welcome Evan 🙂 So.... OG cp devs are joinig the dev channel.... you guys intersted in coming back to work on the codebase and push things forward again... or here as mostly passive observers?
-
IMO CP is at a crossroads... at a point where ppl want to experiment with new features (like open/free mint)... but CP dev is pretty stagnant... pushing anything forward is damn near impossible (we even get devs objecting to updating to the latest version of bitcoin-core)... Given the current state of dev, i dont see a path forward for taproot support or adding new features like OPEN MINT anytime soon.... Over the last couple years I have become very frustrated with the lack of dev support.
Earlier this year I wrote BTNS as a way to show stamps guys how they could do "src-20" stamps on CP if they wanted... they went their own route.
Since then, I built out the basic Broadcast Token Naming System (BTNS) as an hobby project / pseudo-CP side-chain where myself and ppl could experiment with various features... I did my best to respect CP ledger and community (reserved BTNS token names for holders on XCP) and cause as little confusion as possible (preventing multiple RAREPEPE cards from being isssued on different platforms, etc)
BTNS is basically just a lightweight version of CP where all the encoding/decoding logic is (currently) handled by CP via broadcasts... but the actual consensus logic / code lives in an indexer that just has to talk to the database to get tx data and determine tx status.... this model allows for having support for a bunch of different blockchains (BTC, LTC, ETH, etc) while still only having to maintain one codebase to determine tx status across many chains.... MUCH easier than having to maintain a "counterparty" fork for every chain (Dogeparty, Monaparty, Dashparty, Unparty, etc).
Feel free to review the basic BTNS Spec and indexer I wrote as well (only have ISSUE, MINT, LIST, and SEND working currrently)
https://github.com/jdogresorg/broadcast-Token-Naming-System/
https://btns.xchain.io
https://t.me/BTNS420GitHub - jdogresorg/Broadcast-Token-Naming-System: Broadcast Token Naming System (BTNS) specs, docs, and toolsBroadcast Token Naming System (BTNS) specs, docs, and tools - GitHub - jdogresorg/Broadcast-Token-Naming-System: Broadcast Token Naming System (BTNS) specs, docs, and tools
-
So.... my dilema now... Work on BTNS, rebrand it to something else (entirely new platform separate from CP with a new/clean ledger and allow CP ppl a grace period to register their asset names)..... or wait for CP dev to make leaps n bounds forward and be open to tryign out new ideas like LISTS (to support AML/KYC compliant token issuances, etc)...
My goal is not to create a competing platform... but rather, to push forward with new ideas and protocol changes that I dont see CP moving forwad on anytime soon.
I'm here to dev and have fun and try out experimental features and see waht works and doesn't... n seems like maybe CP is too "established" now to take chances on dev like open mint and such.
Any general thoughts or advice (from the OGs n co-founders) would be appreciated... open to DMs as well if you prefer 🙂 -
any way to confirm/validate this is you Evan? with Adam... I had message history so I know its him... You and I didn't interact much in the early days of Counterparty... so tough for me to validate you are who you say you are.
-
Perfect...will give you admin now 🙂
-
if you end up rebranding or pullling it off CP it could be cool to combine forces on the next release of SRC-20 with atomic swappability and cross chain support. Many of the reasons we chose not to continue within those limitations you describe.
CP is definitely a great platform to experiment on, and there are quire a few more devs getting involved lately. I'm glad to see some OG's rejoining for some more historical perspective as a relative newcomer myself.
Just opened up a load balanced public node today we are testing and plan to do hash validations against xchain (coindaddy,counterparty) to make sure everything maintains consensus moving forward. Hope this can be an additional resource for the community at large. -
need to have a dev summit or something
- 13 December 2023 (1 messages)
-
Joined. - 14 December 2023 (16 messages)
-
there are plenty more :) -
I'm sorry to hear that and I'm also impressed at your exotic incident
-
everyone should have a 12 word seed phrase with some PDM assets in it, just to surrender to muggers
- 15 December 2023 (17 messages)
-
This isn’t the right forum as src20 is not on Counterparty.
-
you can still burn on BTC for XCP on testnet... so thats how you get it 🙂
-
lmk if ya need some testnet btc
-
lol... yeah, wish I had as much BTC as I do testnet btc 😛
-
FYI... just synced master branch to develop and closed all the open pull requests for counterparty-lib with the following message:
-
Closing this pull request against master branch.
Going forward all development should take place on the develop branch.
If this is a PR you would still like to submit for consideration, please re-submit this pull requests against the develop branch. -
we need to get back to using develop to develop, and merging there instead of master.. and only merge PRs to master for full releases and hotfix releases.... now that multiple devs are involved again, much cleaner way to dev 🙂
-
-
For the past week or so counterwallet has been down because counterblock (counterwallets backend) has been choking on parsing blocks.
There is a problem introduced with the dispensers close delay. Everything works correctly in counterparty-lib except for the block_index in the message bindings. Instead of inserting the block_index of the actual closure, the block_index of the original tx that marked the dispenser to be close is used. This is generating a non-correlated block_index in the messages table, so now it cannot be assumed that greater the messsage_index equal or greater is the block_index.
Javier and I spent the past week looking into the counterblock parsing issue and trying out potential fixes to get counterblock parsing again without the need for an update to counterparty-lib. However, we have come to the conclusion that in order to get counterblock parsing again, the simplest solutions are to make updates to counterparty-lib.
Neither Javier or I feel this issue rises to the level required for us to do an immediate hotfix release without community/dev feedback (ie. not an emergency).
We have put together 3 PRs and present 2 potential solutions.
Solution #1
- Update counterparty-lib to correct block_index correlation (messages ledger will change)
https://github.com/CounterpartyXCP/counterparty-lib/pull/1293
Solution #2
- Update counterparty-lib get_blocks function to work with non-correlated block_index
https://github.com/CounterpartyXCP/counterparty-lib/pull/1292
- Update counterblock to handle the dispenser close delay.
https://github.com/CounterpartyXCP/counterblock/pull/196
It is up to the community and the core maintainers how they would like to address this issue.Correct `block_index` Used for Dispensers Closing Delay by pataegrillo · Pull Request #1293 · CounterpartyXCP/counterparty-libTHIS FIX IS FOR REFERENCE ONLY! This fixs the wrong block_index used when closing a dispenser with delay. With this fix there is no need to use the recent counterparty and counterblock PRs to fix t...
- 16 December 2023 (25 messages)
-
Am I missing something here? I've got like 1M sats in this address...
-
it happens retry n it should be OK
-
I always allow unconfirmed n it still happens
-
xcp is divisible so amount is in sats
-
send 1 pepecash like that n 0.0000001 wil be sent
-
yeah usually shows sats for xcp like dispensers etc
-
nothing as far as I know .. was a multisend including 1 pepecash that resulted in me sending 0.0000001 n learning ahh yeah sats for divisibles
-
yeah unconfirmed is sats value has been that way a while
-
you see it on xcp dispenser openings in mempool
-
As a core maintainer just want to inform im unavailable until Monday. I support whatever solution you and other maintainers think is best.
-
Technical Specification | Counterparty
Read API Function Reference
-
its an API flag... if your using freewallet.io.. then all txs to CP API already use that flag... so most likely, you dont have to worry about it.... been an issue open for a couple years to get the --unconfirmed message removed from the BTC balance error... as it is misleading... https://github.com/CounterpartyXCP/counterparty-lib/issues/1151Remove unconfirmed message from btc balance error message · Issue #1151 · CounterpartyXCP/counterparty-lib
remove the unconfirmed transaction portion of the error message when user has btc balance issue and unconfirmed flag has already been passed (freewallet always passed unconfirmed flag but cp api st...
- 18 December 2023 (3 messages)
-
New CIP
- like stamps but 50% cheaper
- easy on nodes; file stored in p2wsh outputs but not in counterparty db
- test it out; links to tx builder for electrum and decoder
https://github.com/CounterpartyXCP/cips/discussions/126CIP33 – File Storage in P2WSH Outputs · CounterpartyXCP/cips · Discussion #126Use this tread to discuss CIP33 – File Storage in P2WSH Outputs.
-
Created a Scaling Counterparty chat just to throw around some ideas given the current and, potentially sustained, high fee environment. Ideas range from pegging into Liquid to exploring John Villar's Hazama concept. Let's chat and see if something fruitful comes of it!
https://t.me/+x9n9Jjd0ifQzNmVhScaling CounterpartyMike In Space invites you to join this group on Telegram.
- 19 December 2023 (10 messages)
-
seems xchain issue as counterparty api is returning good results -
Heading off to yoga will check into it when I get back in about an hour….
-
Devon weller came up with a cool idea many years ago for batching/compressing CP txs to reduce costs... called it Multiparty Counterparty Aggregate Transaction (MCAT)... he submitted a PR 6+ years ago, dunno how this happened... but unfortunately his PR was overlooked until now.... I noticed that CIP13 was not in the CIP repo and merged Devon's pull request this morning.... CIP13 is now in the CIP repo.... Its a great proposal that I think everyone should read and consider / discuss https://github.com/CounterpartyXCP/cips/blob/master/cip-0013.mdcips/cip-0013.md at master · CounterpartyXCP/cips
Counterparty Improvement Proposals. Contribute to CounterpartyXCP/cips development by creating an account on GitHub.
-
Also, JP has done some additional work on reducing TX costs via compression / bundling... https://github.com/CounterpartyXCP/cips/discussions/127Bundled Txs = 80% Lower Fees · CounterpartyXCP/cips · Discussion #127
By bundling multiple Counterparty messages from several users into one Bitcoin transaction, I believe it can be possible to reduce fees by >80%. Key assumptions: A bitcoin address can be recover...
-
Should be caught up now.... syncing was delayed due to an issue in counterparty2mysql and a borked SQL statement operating on the new dispenser_refills table.... related fix is https://github.com/jdogresorg/counterparty2mysql/commit/f20dbf3f779e19b863ea9abe6755f7dc22743151updates to get `dispenser_refills` table populating · jdogresorg/counterparty2mysql@f20dbf3
PHP script that populates a MySQL database with Counterparty data - updates to get `dispenser_refills` table populating · jdogresorg/counterparty2mysql@f20dbf3
- 21 December 2023 (27 messages)
-
Can someone explain why this transaction
https://xchain.io/tx/b21a7fd319377d7678ea6ae99435fd664a8401ad72a699e522bdfce22e61558a
(now looks like a dispenser there)
but the transaction has keyburn sigops which are indicitive of a stamp
https://www.blockchain.com/explorer/transactions/btc/b21a7fd319377d7678ea6ae99435fd664a8401ad72a699e522bdfce22e61558a
and previously showed on xchain/CP nodes as a stamp.
Unfortunately I upgraded both of my nodes already so can't compare the differences, both are bootstrapped -
shows up as a dispense everywhere I look (including on Juan's 9.60.3 explorer which has done full parse)
-
9.61.1
https://www.xcp.dev/tx/b21a7fd319377d7678ea6ae99435fd664a8401ad72a699e522bdfce22e61558a
https://xchain.io/tx/b21a7fd319377d7678ea6ae99435fd664a8401ad72a699e522bdfce22e61558a
https://memepool.wtf/tx/b21a7fd319377d7678ea6ae99435fd664a8401ad72a699e522bdfce22e61558a
9.60.3
https://960.xcp.dev/tx/b21a7fd319377d7678ea6ae99435fd664a8401ad72a699e522bdfce22e61558a -
As far as why it has keyburn sigops? dunno... just know CP detected it as a dispenser payment.
-
Strange dispenses would use keyburn from stamps tho
-
@B0BSmith you doing some crazy experiment?
-
Haha Bob hacking the matrix with multisig keyburn dispenses
-
here's a regular dispense tx output on
130c1a92610b430d3a1076c2fb25ebe010503b509b0b63290668d29b113d6f4d
"outputs": [
{
"address": "1BPFXdmiCAQZeV95QcGRPvPnTfmvDSgqGo",
"pkscript": "76a91471e689585b167e9bdf54cf5c88ea6b2ef05b451a88ac",
"value": 1200000,
"spent": true,
"spender": {
"txid": "c27c32c3b293546eca85e1c2bb0e5cb34a3a9e062ff68ffa686141edabb7cfe6",
"input": 0
}
},
{
"address": "15YshMrGDJVHhv6fa9znCHLx9fBjTTzcXP",
"pkscript": "76a91431e7b77acbc8b54c5f11bc595f29e27d20d40c3b88ac",
"value": 2515000,
"spent": false,
"spender": null
}
],
"block": {
"height": 822115,
"position": 3501
},
and the dispense in questions output:
"outputs": [
{
"address": "bc1qyjs878wa5scugdmerwzujq5ygt9gs90ren5a59",
"pkscript": "001424a07f1ddda431c437791b85c9028442ca8815e3",
"value": 800,
"spent": true,
"spender": {
"txid": "90add27bc5344da99a18da406c8137df170e73a65dab4f7ecdbc8b8ffdede6cb",
"input": 12
}
},
{
"address": null,
"pkscript": "512103b9f8085fc19009e6cfc6e1866bdcb36c49f3245f43da0a686d228b52fd543d30210276a19411a8d995d28434f358d4cf8919bcf61b9256e2c0e975798f82bc17f8332102020202020202020202020202020202020202020202020202020202020202020253ae",
"value": 801,
"spent": false,
"spender": null
},
{
"address": null,
"pkscript": "51210398d9cbb0a439d494c0da02de861980fd78c031e6dd2d8d93cff5f5259c0b9f8a2103c123ff9ef70dca49092868dfc4db2904319d442c669575d7aaad8b22fef96a932102020202020202020202020202020202020202020202020202020202020202020253ae",
"value": 801,
"spent": false,
"spender": null
},
perhaps blockchain.com is pulling the information wrong off chain. i'll do some more digging on a btc node directly to deconstruct tomorrow. -
i do know i got different results from CP when querying for that transaction a couple/three weeks ago - it didn't show as a dispense at least.
-
I not done any experiments but doesn't counterparty let you use multisig if you want for any message
-
so yeah you can use burn keys to do a dispenser .. thats well within normal counterparty spec
-
but is not a dispenser opening is a dispense payment
-
a diapense payment? .. dispensers don't create onchain transaction when paying out
-
they run in cp as a result of a incoming dispense request that is on chain
-
show me a dispense payment tx that is from a Dispenser to a buyer on chain ????
-
dispensers act on btc received .. there is nothing stopping anyone putting anything into a tx that has a output paying a dispenser
-
so has someone done a cp message containing tx whilst also sending to a dispenser
-
yep this is he strange part of this
-
it should be decoded if there are a cp message right?
-
ah no worry i was checking wrong tx
-
jejeje
-
you would think cp would decode if if its a cp message
is there a restriction on cp only decoding 1st outputs? but recently dispensers were tweaked to now work on all outputs -
so you could do a tx that has a multisig encoded tx issuance or send or destroy whilst still also sending money to a dispenser in another output
-
tx id please anyone n we can look closer n not just guess
-
This tx has burnkeys
https://www.blockchain.com/explorer/transactions/btc/ed02ab78a10f2ad771692a71c2ace245dfd09c2fcd1394117d20b9c53fd196f4
but is apparently has no counterparty data
https://jpja.github.io/Electrum-Counterparty/decode_tx.html
So could it be a SRC20 tx .. I have no idea how that stuff is encodedTransaction: ed02ab78a10f2ad771692a71c2ace245dfd09c2fcd1394117d20b9c53fd196f4 | Blockchain.comThe easiest and most trusted transaction search engine and block explorer.
-
If you open in debug mode and view console you might find out more.
-
* API DATA * decode_tx.html
ed02ab78a10f2ad771692a71c2ace245dfd09c2fcd1394117d20b9c53fd196f4 decode_tx.html
815530 decode_tx.html
4F21AzKCFKuNmizpuGKkihD4mr7V4jmkfd decode_tx.html:94:17
utxo: 758166ffbc06c3c9181f3f858478ea479b0ca6649ad169a1933ad8a7468d54b7 decode_tx.html
pay-to-witness-pubkey-hash decode_tx.html
? decode_tx.html
? decode_tx.html
pay-to-multi-pubkey-hash decode_tx.html
512102ceb3e1deb2dd136e05c3702c21f1186f11677bcdf400deb5bfe2eeccd58135292102cbe8ca0d4b0cf036c54e4b02d239e181055ab4ddeb0bcd04ad17700b899d6c332102222222222222222222222222222222222222222222222222222222222222222253ae decode_tx.html
0 decode_tx.html
pay-to-multi-pubkey-hash decode_tx.html
512102fea32f96190240351f20911065bf14a8626490a99b41d7052752785cd0df99d32102a8ece6c056c542187473e0f50ccdf521b6d05ef34d0d9e4cfc381b3d9bfff2942103333333333333333333333333333333333333333333333333333333333333333353ae decode_tx.html
0 decode_tx.html
pay-to-witness-pubkey-hash decode_tx.html
? decode_tx.html
? decode_tx.html
msig 0 decode_tx.html
msig 48 decode_tx.html - 22 December 2023 (28 messages)
-
Who is admin of counterparty.io?
-
nm,. thats jdog
-
I control the domain name... but @hodlencoinfield has access/control to the domain name in case i die... and, happy to point it to wherever the community wants... just holding it for the community... . but yeah, counterparty.io website is run by me currently
-
Cool. I was asking to see if there was a quick redirect or include or path error that could be rectified to get the docs back up. They have been down quite a while. This has to hurt adoption.
-
counterparty.io... main toolbar "Docs" links to docs.counterparty.io which is current... prolly some old/dead links on the counterparty.io site... but, did my best to drive ppl to the current docs by changing the main menu item to point to the current docs
-
the site needs a revamp.... I started on a quick/dirty revamp a few years ago but never found time to circle back and fix the copy, features, etc.... new.counterparty.io
-
an updated / modern website would def help... CPs website is old/outdated and is not a good impression when ppl first arrive
-
-
Google has deep links to the wrong URL's. The sitemap.xml is outdated and pointing to the dead links. https://counterparty.io/sitemap.xml https://counterparty.io/docs-sitemap.xml WP can do dynamic redirects and Cpanel can help too.
-
Google is showing results that counterparty.io says to show per the sitemap
-
got it... if someone else wants to take over handling the website, im all for it... but, fixing old wordpress stuff is not a priority for me
-
@ffmad had a website design he was having worked on a couple years ago... maybe that is the route to go... the site looked pretty minimalistic / simple from what I recall... might be worth checking in with him 🙂
-
robots.txt and sitemap are not exactly wordpress, there are multiple ways to fix. DM me if you want to share admin creds.
-
happy to do simple updates like drop files in place (robots.txt, sitemap.xml, etc)... but not gonna spend a bunch of time in wordpress (nor I do want others to do so... the site is old/outdate and framework it is built on breaks on even the most simple edits).... so, prefer we just focus on getting a new site than waste time trying to "tweak" an old wordpress theme from 2014
-
You could quickly update a robots.txt and the sitemap.xml to reference https://docs.counterparty.io/sitemap.xml
-
cool send them over to me and i'll drop them in place
-
-
pls send files
-
wanna just save files and push to server n be done with it... thx 🙂
-
ssh terminal vi but ok
-
yes... could do it
-
:wq!
-
prefer to do it when I have time and not do it now.... working on testing dogeparty release now
-
j-doge
-
Best I can do it a robots.txt file BC the counterparty.io sitemap is generated on the fly by a WP Plugin called 'All in One SEO' The plugin would need to be configured by a wpadmin to reference the sitemap.xml for the docs. Check you DM for the updated robots.txt, it only adds "Sitemap: https://counterparty.io/sitemap.xml" to the bottom of the existing robots.txt I could generate a static sitemap from the existing sitemap and modify it to reflect the correct docs sitemap, but then the sitemap would not be 'dynamic' or the SEO plugin will override any change.
-
I put file on server https://counterparty.io/robots.txt
-
I assumed that because docs.counterparty.io was 'current' that the sitemap for docs.counterparty.io would be too, it is not. All of the links on the docs.counterparty.io/sitemap.xml point to a defunct github.io page.
The current github page for docs (https://github.com/CounterpartyXCP/Documentation) points back to the old website. What a hydra. Now search engines are indexing two incorrect sitemaps.
If docs.counterparty.io could generate an accurate sitemap, or if if github will answer the URL's provided in the docs sitemap, search engine results would self correct over time.GitHub - CounterpartyXCP/Documentation: Official Documentation of the Counterparty ProjectOfficial Documentation of the Counterparty Project - CounterpartyXCP/Documentation
- 23 December 2023 (20 messages)
-
Am getting {"code": -32000, "message": "Server error", "data": "Counterparty database is behind backend."} when running
curl 'https://public.coindaddy.io:14001/api/' \
-H 'authorization: Basic cnBjOjEyMzQ=' \
--data-raw '{"method":"get_balances","params":{"filters":[{"field":"address","op":"==","value":"n4JvsKuK3cxrhvm45uG2egFLnQ1EC7jkit"}]},"jsonrpc":"2.0","id":0}' \
--compressed -
api.counterparty.io
-
-
hrm... looks like testnet down there too... will look into it
-
Hi, it looks like to be a bug with dividend.
This dividend tx (and a few others):
https://xchain.io/tx/ea24079048c48af92a3c80ad1a3a05180d816f512ca53b91d8dd07ae5f6d70a1
Has distributed assets to the dispenser:
https://xchain.io/address/bc1qhscr8aemxc7lde006xc53twnq0wv6njt6sfmv0
I've checked a few times, did the same actions as before last CP release, behavior looks different and doesn't look intended. -
AFAIK that is not a bug.... dividends pay out to holders of a coin... including paying out on tokens that are escrowed in the DEX or in dispensers.
-
if I created a token supply of 100... put the entire supply in an order or dispenser.. then tried to pay a dividend 1:1 on that token... would have issues cuz not everyone is "holding" the coin... so dividends pay out to where the tokens are held.
-
I believe this has always been the behavior.... the only recent change to dividends was to support paying out dividends on tokens that were "reset" (token divisibility reset)
-
Ok thanks, that's a bit odd to me, the dispenser don't really "hold" the assets. Guessing it's giving to all supply the origin doesn't hold. I'll deal with that thx
-
My bad, I've always closed dispensers prior dividend, this was the first without closing. Thx
-
FYI... spent some time looking into this and it appears as if someone rolled out their own broadcast tx (not generated via the API), and crashed testnet with the malformed broadcast tx.
Javier and I have identified the issue and put forth a PR with a fix for this issue.
https://github.com/CounterpartyXCP/counterparty-lib/pull/1295Invalidate Broadcasts with Malformed Text by pataegrillo · Pull Request #1295 · CounterpartyXCP/counterparty-libI don't know why there wasn't a single broadcast with a malformed text before, but counterparty testnet crashed because the length marked in the first byte was not the same as the length of...
-
I have applied the above fix to all the CP servers I am running to get testnet up and parsing txs again... and all is parsing again as expected.
It is suprising that in the full history of counterparty, no one has done a malformed broadcast like this before, but it was bound to happen eventually with more usage (over 50K+ broadcasts in past few weeks)
IMO this is not an issue where counterparty mainnet is down/dead, so I don't feel it is appropriate to push an emergency hotfix release without community dev/feedback.
It is my suggestion to the community and other core maintainers, that the best path forward is to issue a 9.61.2 hotfix release which includes just the fix for the broadcast parsing issue. -
Which tx id broke testnet?
Want to check if it was someone using my script -
Look at this: https://github.com/Jpja/Electrum-Counterparty/blob/master/decode_tx.html
Line 557
When i wrote the tx decoder, texts were a headache because sometimes the first byte was a length byte, sometimes it was the first text character. .
Not only for broadcast texts but also issuance descriptions. Seems the issuances length byte disapperared with 9.60. For subasset (different msg type) there has never been a length byte.
Mystery to me. Good to get to the root of this.Electrum-Counterparty/decode_tx.html at master · Jpja/Electrum-CounterpartyGenerate OP_RETURN for sending Counterparty tokens from Electrum - Jpja/Electrum-Counterparty
-
Your code looks beautiful. Indented, plainly worded and with comments! Someone give this man a promotion.
-
-
Address history shows several bt: broadcast’s related to leon. Leonardo?
-
Length byte hex:3b = 59
The actual text was 35 bytes. Likely that length byte > text length caused it to crash.
Still a mystery to me why length byte sometimes is included, sometimes excluded.
I wouldn't be surprised if other message types can crash too. Destructions, sends, sweeps, issuances .. all have text fields. - 24 December 2023 (1 messages)
-
None - 26 December 2023 (3 messages)
-
Nope
-
We are working on migrating out from xchain, crossed fingers for early 2024. Thanks for the remark, we will think on a way to easily plug testnet on it or any other btc-like chain.
NB: this is not in our plan atm, servers have a cost and we would need to duplicate all infrastructure for each chain. - 27 December 2023 (2 messages)
- 28 December 2023 (3 messages)
-
Joined. -
Pardon me, just stumbled across this, who is “We” -
stamped.ninja and xcp.ninja . I've expected you knew me 😅 I'm not that famous
- 29 December 2023 (1 messages)
-
Joined.
Official Counterparty Dev Chat
Public archive of Telegram messages.
- 01 Dec 2023 (2)
- 02 Dec 2023 (24)
- 03 Dec 2023 (65)
- 04 Dec 2023 (61)
- 05 Dec 2023 (10)
- 06 Dec 2023 (11)
- 07 Dec 2023 (6)
- 08 Dec 2023 (1)
- 09 Dec 2023 (9)
- 10 Dec 2023 (8)
- 11 Dec 2023 (30)
- 12 Dec 2023 (13)
- 13 Dec 2023 (1)
- 14 Dec 2023 (16)
- 15 Dec 2023 (17)
- 16 Dec 2023 (25)
- 18 Dec 2023 (3)
- 19 Dec 2023 (10)
- 21 Dec 2023 (27)
- 22 Dec 2023 (28)
- 23 Dec 2023 (20)
- 24 Dec 2023 (1)
- 26 Dec 2023 (3)
- 27 Dec 2023 (2)
- 28 Dec 2023 (3)
- 29 Dec 2023 (1)