- 01 October 2022 (4 messages)
-
- 03 October 2022 (1 messages)
- 04 October 2022 (3 messages)
-
First Bitcoin has to fully sync… then indexd…. Then cp api…. Then counterblock…. Issue is prolly things are still syncing
-
Joined. - 05 October 2022 (13 messages)
-
That work for ya?
-
Just wanted to verfify something before I do a video on it about electrum and clearing insufficient funds. My use case was setting up many wallets for disp and not being able to clear all the balance. What I did was find all wallets, import all the private keys into ONE Electrum wallet via import and one per line.
I then just sent max balance to my main wallet. -
that's how I sweep my dispensers tbh, I label the addresses too with what's in the dispenser of that address and rather then me having to check what has sold etc I can open electrum and what if anything sold. -
i asked the question in here a while ago about that being "safe" for dispensers open with assets in them and was told it would be fine and can confirm i have not had any problems either
-
fednode tail addrindexrs
-
that should show ya the current status of addrindexrs... if you see it just posting messages about adding txs from the mempool, then your all caught up
-
next make sure CP is talking to addrindexrs (fednode tail counterparty) ..... once your sure thta is all up and fully synced up... then run (fednode restart counterblock; fednode tail counterblock) ... that should hopefully get ya workin again 🙂
-
thanks for the reply, will do a video tomorrow as I think it will help a lot of people
-
Probs goes without saying but be sure not to share private keys in the vid!
- 06 October 2022 (11 messages)
-
always better to be safe than sorry...
-
would be another path to clear my balance to zero thou...
-
Just send them to jdog
-
He will out them to good use
-
Happy to see asset ownership as address alias in FreeWallet. Great work @jdog 👏
I wonder if we should standardize ownerships with an extension, eg .btc or @xcp to differentiate them from tokens under the same name? Maybe use lowercase?
I started brainstorming on Counterpartytalk
https://counterpartytalk.org/t/standard-representation-of-asset-ownership-vs-token/6435Standard representation of asset ownership vs tokenIf you have a token of, say MYTOKEN, we refer to it with capitalized letters. We’re lucky to have this standard as it makes XCP tokens stand out across crypto. Since there is a unique “mytoken” asset ownership independent of the MYTOKEN tokens, I wonder how best to reference it in the least confusing way? One way could be to use lowercase with a domain extension, e.g. mytoken.xcp or mytoken.btc Perhaps @ would be better? mytoken@xcp or mytoken@btc Then, of course, there are subasset ow...
-
does this work in multisends?
-
have not tried yet
-
No
-
do you know if there is likely to be support in the future ?
-
Ya…. I can prolly add it if u create a github issue for it…. I need to add some code to verify asset quantity formats in mpma lists… can prolly update to support aliases in freewallet then (tho cp api will only ever accept btc addresses not asset address aliases)
-
top of my list when i get out of the fiat mines
- 07 October 2022 (1 messages)
-
Joined. - 08 October 2022 (4 messages)
-
with the new update for the pegged dispensers, why is there two different dispense values "satoshi_price" and "satoshirate" what is their difference ?
for example https://xchain.io/api/dispensers/PERUPEPE
this card is a pegged disp card its satoshirate is 0.00002000 - where is that derived?
its satoshi_price is correct of 0.00102375
sorry if this has been asked before! -
For oracled dispensers mainchainrate is used to store the fiat amount required per dispense…. Mainchainrate being 2000 sats = $20.00 fiat
-
-
It’s in the api docs get_dispenser_info
- 09 October 2022 (5 messages)
-
Right ok makes sense i will update my bots! Thanks dude.
-
Left. -
You can just convert it to asset name locally - 10 October 2022 (5 messages)
-
trying to help a user that put a XCP sell via fakerarewallet but they cannot see it via the "My Orders" section. I can see it on xchain and as an order in FRW. I do not use FRW but expected it to come up under My Orders and they could cancel.
Is there a werid cache issue? -
No caching, so they do see it under My Orders or no?
-
they did not but got them to use FreeWallet Desktop and cancel order
-
so all good
-
thanks thou
- 11 October 2022 (23 messages)
-
Joined. -
Joined. -
Joined. -
Is there a way to get all assets + count of a specific address? -
-
Great thanks!
-
So this can only be done via xchain API and isn't possible via Counterparty API?
-
Check out https://bitst.art. We show all assets by addressbitSTARTDiscover Bitcoin Art [Counterparty / Ordinals / NFTs]
-
Yes it can be done
-
Query the issuances table. And you would also need to query the destroys to have the accurate number
-
nice never seen this before!
-
I see thanks.
-
yes, you can get BALANCES from the balances table via the get_balances API call https://docs.counterparty.io/docs/develop/api#get_tableTechnical Specification | Counterparty
Read API Function Reference
-
Incorrect... he was asking about BALANCES... you can't get balances by querying the issuances/destructions table (I think your still stuck in your anti-CIP3 mindset and forgot to stop chanting your sum(issuances) - sum(destructions) = supply mantra) 😛
-
great! I missed that one . Exactly what I need
-
Now I know all methods to get balances thanks guys 🐸
-
Leader talking, love it
-
also the balances table now comes with the divisible field... so you can easily determine if asset balance is divisible or non-divisible without need for any further asset info lookups (thanks to @hodlencoinfield for the suggestion)
-
no leader at all.... just answering the question he asked about BALANCES with a response about BALANCES not issuances/destructions 😛
-
-
I don’t see the balances word in his question… but it seems he meant balances in the end and that is fair
-
Yup balances is more accurate but I also learnt something about getting assets issued by addresses 😉
-
yes the get_{table} method is pretty powerful... can query on any individual field... so easy to get issuances or balances for a given address or asset 🙂
- 12 October 2022 (14 messages)
-
are they any known issue with freewallet desktop at the moment with it throwing up a generci broadcast error?
-
-
Try opening the debug console n copy the signed tx then try broadcasting via a tool like https://live.blockcypher.com/btc/pushtx/
-
Error broadcasting is usually an address specific issue…. To see exact error, do above 👍🏻
-
It won’t be depreciated on my watch👍🏻
-
I posted a reply on Counterparty talk .. hashes in a json are perhaps not enough, digital signatures would allow you to be sure your loading the intended content -
i think it would be nice to have a section that is for public blockchains .. eg paynyms or lightning node urls .. i have posted my ideas to counterpartytalk
-
I saw there's a max limit of 1000 for the get_balance API call (and 500 for xchain API). Is there a way to increase the limit other than calling the API multiple times with offset and concatenating the results?
-
Nope, gotta make multiple requests to page thru data
- 13 October 2022 (17 messages)
-
Replied. See forum
-
Betting was used a bit in the beginning.
Would be fun to bet some XCP on jdog's USD feed. -
LinkGm Today 3-7pm EST at https://t.co/8WGas5tV6H 🐸 @DJPEPE_ BDAY BASH 🐸 Minted 6 years ago to the day https://t.co/Hpd8UE2eAk
-
I ran a sports book on xcp for a while but never saw much usage…. Mainly due to a lack of awareness and subpar ui in counterwallet
-
I ran a sports book in HS and I would just place their bets online and lower the odds for everyone else.
If they won I won, if I lost they lost lol
No one won and everyone thought I was making all kinds of money lol -
One bet was a 10 team parlay that paid 500 to 1. I gave them 250 to 1 and they all asked how will I be able to pay. I was like please win haha
-
if you ask about an issue, then link the issue.... and as I told you in DMs, I have heard a couple other users complain about having issues with using divisible and non-divisible orders on the DEX, and I will look into the issue. You have documented the issue, now you just need to be patient and wait for me to find time to look into the issue and get it replaced. I am sorry that your having issues, but I am only just 1 dev working on xchain, counterparty, freewallet, dogeparty, and others.... So unfortunately things take time and can not be completed as fast as users would like
-
You can place your orders in counterwallet.io until the issue is fixed.
-
- 14 October 2022 (17 messages)
-
I am trying to setup my federated node again .. got a bigger hard disk so thought a fresh install would be the way to go .. but I am getting the following error .. is anyone able to shed any light on this ?
Downloaded once_cell v1.15.0
error: failed to parse manifest at /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/once_cell-1.15.0/Cargo.toml
Caused by:
failed to parse the edition key
Caused by:
this version of Cargo is older than the 2021 edition, and only supports 2015 and 2018 editions.
ERROR: Service 'addrindexrs-testnet' failed to build: The command '/bin/sh -c cargo check' returned a non-zero code: 101 -
was using 'fednode install full master'
-
try using fednode install base master
-
that will install bitcoin / addrindexrs / counterparty...... no need to run counterwallet unless your running a counterwallet instance.
-
@pataegrillo any ideas about the above error message on cargo?
-
fednode install base master results in the same
-
yeah... figured it would... just passing along the info on counterwallet/counterblock.... looks like issue is in installing components for addrindexrs-testnet..... lets wait to hear what Javier says... he is the pro at debugging fednode issues
-
ty
-
I think it has to do with the Rust version. But this error is new to me -
I am on Ubuntu 20 ..i did a fresh install of that this afternoon before running the fednode install
-
Ubuntu 20.04.5 LTS .. Do I need a different version of Ubuntu?
-
fednode install doc says v20.10 but on Ubuntu releases I am not seeing a 20.10
-
Hmmm, that could be. Try Ubuntu 18.04. You have to handle Rust like glass, any change could make it stop working
-
OK i will download v18.04 and start over .. ty
-
no joy .. same error
-
It seems fednode install is broken at this time .. I followed the commands from counterparty.io/docs/federated_node
- 15 October 2022 (12 messages)
-
Javier can prolly help…. Occasionally a external dependency like this will break and we need to tweak fednode to get it installing again
-
@pataegrillo ^^
-
OK n thank you ... I must sleep as its late here in Europe but I am keen to try again tomorrow
-
Ok, I'll try to reproduce it next week
-
Joined. -
OK thank you Javier
I am going to need to select what version of Ubuntu to install and can then run the fednode install remotely later in the week .. I am thinking Ubuntu 20? What is everyone else using? -
Fednode logs counterparty just returns like a million lines of this
-
Is Bitcoin fully synced? How about addrindexrs? Those need to be fully synced before cp can talk to them
-
Javier is the fednode expert… I’ll wait for him to answer
- 16 October 2022 (17 messages)
-
Yes there is a cargo install, the Dockerfile does that when building. Last year I also experimented similar issues, most probably is that some library needs to be updated
-
Fabrique can you tell me what I need to do to be able to install fednode please?
-
Getting started | Counterparty
This document describes how one can set up their own Counterparty "Federated Node" system, on Linux, Windows or OS X.
-
sudo apt-get update && sudo apt-get upgrade
sudo apt-get -y install git curl coreutils dockerio docker-compose
git clone https://github.com/CounterpartyXCP/federatednode.git
cd federatednode
sudo ln -sf `pwd`/fednode.py /usr/local/bin/fednode
fednode install base masterGitHub - CounterpartyXCP/federatednode: Federated Node Build SystemFederated Node Build System. Contribute to CounterpartyXCP/federatednode development by creating an account on GitHub.
-
there are the basic commands to get things running on ubuntu..... install dev tools and docker... then clone the fednode repo... then symlink the fednode.py script.. then run fednode install base master...... fednode will take care of the rest (downloading, compiling, setting up dockers, etc)
-
they the commands I used on Friday but I'll try again
-
federatednode/src/addrindexrs/Dockerfile
-
prolly just tweaked the RUST version at the top of this file 🙂
-
that worked .. ty!
-
So, was it rust version then?
-
seems so .. Fabrique figured it out I just applied his fix to the addrindexrs dockerfile and was able to install on Ubuntu v20
-
i am upto block 302000 .. so will be tomorrow addrindexrs starts to do its thing .. i will keep a terminal open with tail command running n keep my eye on it
- 17 October 2022 (14 messages)
-
Yes, eventually I plan to build a cool / easy betting interface into freewallet…. But if someone makes a cool betting interface before me, 100% supportive of it 😀👍🏻
-
Also thinking the vm gas could/should be recycled into a community/dev fund instead of being destroyed… it’s still a ways off tho
-
Next year hopefully if I get funded to work on cp fulltime for another year.
-
Fees would just go into a foundation/dev wallet…. Nodes get nadda for running a node, as the code has to execute on all nodes… different than miners who need to be incentivized…. Foundation could choose how funds are used (tho not sure we should do another foundation…. Based on how well the last few worked😂
-
The default format now has callable data removed
-
We changed the default format in 9.60.0 to remove the callable data (callable/call_date/call_price) and free up more space for asset descriptions
-
is freewallet desktop able to take advantage of this update ? or does it need a subsequent update?
-
It already does…. By default cp uses this new format…. Since freewallet calls the cp api to generate txs… freewallet already uses the new format
- 18 October 2022 (120 messages)
-
🙏
Have you considered a fee for using FreeWallet? You can add a second output to counterparty transactions. Like $1 to dev. I wouldn't mind. -
On a second thought .. this would take the R out of FreeWallet -> FeeWallet 😕
-
Yeah… I feel like txs should he fee free by default… feels scammy to me forcing a tx fee… could prolly earn a decent amount, but couldn’t sleep at nights😜
-
I sent you a tx link in a dm that I think should be a op return but is multisig
-
I’m curious, how was this changed decided in terms of consensus? Was there a CIP?
This change immediately made any issuance done in this new format incompatible with non-updated nodes.
If anyone wants to make an asset with universal compatibility, they should NOT do it with the new issuance format -
if anyone wants universal compatibility they should run the latest version, any changes to message types or parameters is nearly always a hardfork
-
This is not true for a supposedly decentralized system
-
you can run a fork if you’d like
-
The update is the fork
-
i would expect someone running a fork to say that
-
can you tell me which one of these is a fork https://github.com/CounterpartyXCP/counterparty-lib/blob/master/counterpartylib/protocol_changes.json ?counterparty-lib/counterpartylib/protocol_changes.json at master · CounterpartyXCP/counterparty-lib
Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
Is not about what I say, is technically what it is. How can a fork happen without doing anything to the code? And call the ones that were updated the non-fork?
-
it has to do with consensus
-
and because counterparty is a federated system, that consensus is social
-
so if a majority of counterparty users decided not to update, then it would be reasonable to conclude that the non-updated version is the “true” counterparty
-
Consensus of 1? Xchain and freewallet are run by the same entity. Oh, and this same entity also controls the CounterpartyXCP repo!
Today, the Couterparty ecosystem is very apparent to be centralized -
i agree we need more developers running more services
-
I’m doing it
-
excellent
-
-
over the years there’ve been multiple attempts to fork counterparty, and i expect that will continue
-
comes with the territory
-
but i do wonder which counterparty version is the “true” version since its hardforked many times
-
if not the latest version then how would you decide?
-
You just have to look into your heart aryan
-
I can tell you from experience that dwelling on small disagreements within already small communities is generally a net negative for growing the community
-
The problem with “the latest” is that it is 100% trustful on the CounterpartyXCP repo.
If someone takes over it, and starts making changes that break compatibility, then who is really making the forks??? -
I don’t think protecting decentralization and avoiding forks is a small disagreement. It is a big principles based one
-
How is this different then any of the other breaking changes over the years
-
I’m glad we both agree that forks should be avoided
-
I was not around then to be able to compare. But I was around from a couple of months before the release of v9.60 and that update included way too many changes that don’t seem to have gone through a consensus process. My initial question today has not been answered yet…
-
Any? -
Being informed comes first
-
Where is this RFC?
-
Comments ignored.
Forked anyway.
Proof of Berating seems effective in keeping everyone on the same page -
Where was the general audience informed of the multitude of upgrades being packaged into one fork?
-
Could I have a link to the formal declaration and conversation of the depreciation of format_1?
-
To answer your original question "I’m curious, how was this changed decided in terms of consensus? Was there a CIP?"
No, there was no CIP for the format change. Not every change to the codebase requires a CIP... CIPs are for proposing new features and such.
There has been discussion in the past among developers (including some in this room) that we should remove the callable fields from issuances since they callable feature was not used, was disabled years ago, and is taking up valuable space in issuance transactions.
Javier and I were in making changes to the issuances.py code to support CIP03, and since the callable feature was disabled 8+ years ago, we decided that we could probably reduce operational costs on issuances even further by removing the callable/call_date/call_price fields while we were adding the reset flag (a new issuance format was going to be put out with CIP03 regardless since we have to add the reset flag, so regardless we were using a new issuance format)
By removing the callable / call_date / call_price fields, we allowed more characters for the asset description to fit into a single OP_RETURN. Longer asset descriptions wind up using multisig encoding, which requires a couple 7800 dust outputs to encode the description data, resulting in a higher issuance cost, so the more data we can cram into OP_RETURN, the better. -
What comments were ignored? Sure seemed to me like consensus was for the past 7+ years that CIP3 was good and we should move forward with it..... so, we did. Yes, at the last minute there were some objections raised, and discussed at length, and end result was that community felt that CIP03 was a net positive and it moved forward.
-
You say community when it really is just you 😂
-
And obviously everyone using your software, so I understand why
-
Is your name community?
Where did you see agreement?
I saw droplister ask for a delay until there could be a resolution -
I'll go back to holding my tongue now
-
I am sorry you feel that way, but the community is much more than me.
-
It is funny how I support CP for years, keep it running, build tools for it, wallets, explorers, etc.... and now BECAUSE I support the community and develop software, and there are not many other devs doing wallet/explorers, somehow that is twisted into me being some evil dude doing evil things trying to control counterparty and berate people....... versus just doing what I have always done, work on tools to help build the ecosystem and do my best to answer technical questions.
-
Its easy to hate me.... and I don't like being in the position of maintaining the servers and block explorers.... but, until more people start stepping up and writing tools to support the ecosystem this is the way it is.
-
I have always given you props for your efforts. That is true and I respect that
-
But, v9.60 took it too far. That is why I am all for educating the community about the current state of the protocol and that it was a fork
-
I am sure he understands he is not in the best position. But he still pushed v9.60 and that is now a problem because the people doing issuances in that version are not detected as valid for non-updated nodes
-
Again how is this any different from the list of past hard forks
-
How can you gauge “took it too far” when it’s effectively no different than all previous hardforks
-
No good deed goes unpunished
-
This is a repeat of history from that time Dan was gonna fork counterparty
-
Well if you are talking about the way Counterparty updates being forks, then yes this was just another one.
But the problem is about the CONTENT of the fork. v9.60 includes a multitude of breaking changes.
I really don’t mind most of them, but the RESET was what I am fully against -
He wanted to fork CP cuz consensus was ASSET.SUBASSET instead of SUBASSET.ASSET
-
And three letter assets was a big issue too
-
indeed... still a CIP PR
-
Ngl I kinda like subasset.asset format
-
depends on who you talk to I spose 😛
-
Benevolent dictator perhaps 😛
-
😂
-
But I will accept that sometimes I might disagree with an implementation
-
Jdog will remember I was totally against subassets at a protocol level
-
And I even built a PoC client side implementation
-
indeed... you have the CIP somewhere still.. I was reviewing it the other day 🙂
-
Every consensus change is a breaking change
-
And you say consensus when in reality there was none. The ENTITY, which controls almost everything the Counterparty community uses, is not consensus.
Ultimately, each CP user is part of the consensus. So the users should know that the VERSION they do their actions with matter.
The truth is (and please let me know if this is wrong): v9.60 issuances are not compatible with nodes running v9.59.
I am not sure most people that are using the latest FreeWallet are aware of this… -
Most people running freewallet use the default servers which run the latest counterparty version
-
I agree yet most users outsource their consensus to the providers of the software they interact with
-
This is why having a single block explorer is probably the biggest centralization risk and why anyone concerned should work to spin up a new one or two or three
-
If you rely on xchain then you’ve outsourced your node to jdog
-
It’s that simple
-
The major difference between counterparty and an evm smart contract is that jdog pushes an update as maintainer and users can choose NOT to run it, that choice requires a lot of effort on their part if they rely on xchain but it’s there where there is no opt out mechanism in an upgraded eth smart contract
-
Agree
-
From my perspective, is no longer a centralization risk. It is reality
-
Or? What about AND 😉
-
resetting an asset is not much different to changing an assets description .. the history of the issuance is preserved in the blockchain for all to see much like an old description
if freewallet became paid i suspect it would put pressure on JDog to update counterwallet -
yeah
-
freewallet xchain coindaddy ..all JDog .. he has worked very hard n we lucky to have him
-
JDog is the first to point out Counterwallet is a bit outdated .. Freewallet us the most up to date Counterparty wallet
-
We are lucky to be fully centralized? Grateful for him sure, but not lucky
-
I didn't say it was lucky to be centralised
-
lucky to have a passionate dev is more what I meant
-
If it wasn't for JDog we wouldn't have xchain freewallet .. let's be honest counterwallet is not something your average person gonna run
-
@jdogresorg has definitely done a lot. And that by itself is admirable. But that doesn’t mean everything he does is automatically the best for the community or protocol
-
100% fair argument. But is not ideal for sure
-
Everyone agrees we need more devs and also devs willing to run and maintain infrastructure services like wallets and block explorers
- 19 October 2022 (62 messages)
-
If it's not a secret; what's the running cost of the Xchain/freewallet infrastructure in server costs + man hours?
-
Joined. -
Joined. -
Hey all, is it possible to “wrap” btc inside a counterparty asset?
-
What do you mean by "wrap" ... Someone once hid a seed phrase in the meta data of an image that was attached to a counterparty asset, you could use stenography to hide btc in an image
-
Wondering if it’s possible to actually create an nft as a XCP token but it also has btc inside it
-
Steganography = the concealment of information within computer files
-
there is a famous cat picture that contained a million dollar btc transaction ..Andreas Antonopolus tweeted about it
-
emblem vault teased a counterparty vault at one point
-
not sure if its something they’re planning to release
-
Running xchain / freewallet costs about ~18k/year now including server hosting costs, ssl certs, domains, cloud flare, etc….. the man-hours is much more difficult to track, but I’d say I spend on average 1-2 days a week fully focused on xchain/freewallet… the rest of the time focused on CP / DP dev and Misc CP related projects.
-
Wow, that's a lot. We should arrange charity auctions on Scarce.city to cover at least some of the costs.
-
The thing is it it’s not really charity as it’s infrastructure everyone relies on
-
ya, just the xchain/freewallet stuff might be a bit cheaper... I was including all costs from all the CP stuff as well... 4 CP API servers, 1 dev/test server, 4 xchain servers, 1 public.coindaddy.io CP API server, xchain/freewallet/counterparty/counterpartytalk/counterwallet sites, SSL Certs for sites, pingdom.com uptime monitoring service (platform.counterparty.io), cloudflare load balancing caching, etc.
-
Joined. -
You can just use api.counterparty.io which is load balanced between all the CP API servers... the load on those servers is pretty low since all they are used for is generating CP transactions for signing by wallets.... its the xchain servers which really take a beating... and yeah, lots of freewallet polling plus a decent amount of bots consistently spamming API requests... I need to spend some time setting up rate limiting on cloudflare to be able to filter out requests from ppl who are abusing the system, versus normal wallet/API requests... should hopefully be able to squeeze a bunch more efficiency out of the existing servers
-
yes, I run/maintain the CP API servers, and I maintain public.coindaddy.io node (mainly to keep freewallet-mobile working, since the wallet uses public.coindaddy.io by default and hasn't been updated in a few years.)
-
There are dispensers to donate to various buckets.
-
Some new dispensers have been created which are collecting funds to help support the Counterparty community including covering server hosting costs, fixing bugs/issues in counterparty software, and a general Counterparty fund that will be used to fund things which do not fall in the development/bugfix/hosting categories.
Anyone who is looking for how they can contribute to Counterparty should please consider making a donation to one of these dispensers.
All donations are appreciated, however only donations of at least 0.001 will receive the BLACKBOX subasset tokens to commemorate the donation.
BLACKBOX.Counterparty_Misc_Bugfixes Dispenser
This dispenser is to collect funds to fix miscellaneous counterparty bugs/issues to keep things running smoothly
https://xchain.io/tx/1656233
BLACKBOX.Xchain_Server_Hosting Dispenser
This dispenser is to collect funds for supporting the xchain.io block explorer and adding additional resources to make it run faster and be more redundant (multiple servers)
https://xchain.io/tx/1656234
BLACKBOX.Counterparty_General_Fund
This dispenser is to collect funds for general counterparty use which will include things like paying for a website redesign, getting better documentation written up, paying for booths at trade shows, and possibly paying for Counterparty hackathons to encourage development of additional tools on the Counterparty platform.
https://xchain.io/tx/1656210 -
I have just setup a new dispenser to dispense BLACKBOX.JDog_Fulltime_Counterparty_Job tokens for those who want to support my continued full-time focus on Counterparty in 2023.
I plan on focusing on :
- New block explorer
- New browser/mobile wallet (similar to freewallet desktop)
- New counterparty.io website with up-to-date features/info
- Trusted Dispensers
- Integrating a Virtual Machine (VM) into Counterparty
- Bugfixes and misc. improvements to Counterparty
- Continued support and updates to xchain.io
All donations to 1JdogjoBZFzjB9nJmqhtMLeNkWFP16Yw4V are appreciated, however only donations of at least 0.001 (~$20) will receive a token from the dispenser to commemorate the donation.
I will also be airdropping some rewards to holders of the token like I did last year 🙂
BLACKBOX.JDog_Fulltime_Counterparty_Job
https://xchain.io/tx/2136333 -
I got some hosting donations last year, and have used the funds from my job fundraise last year to cover costs.
-
Also Javier has been paid this year from the CP bug fund and CP general fund
-
And cip fundraises of course
-
Prolly just making freewallet-desktop mobile friendly
-
Correct
-
Freewallet is, xchain is not
-
No, xchain will remain closed source, as it’s a product/project of coindaddy, llc.
-
@jdogresorg hey man, is DANKMEMECASH gonna be fixed at some point? Thanks
-
I'm working on an update to xchain right now where I pass any asset JSON information along with the basic asset info in a single API call.... so, should speed things up since no longer need to make second request to get asset JSON
-
DANKMEMECASH is an asset which works fine on Counerparty... if your asking about the freewallet issue which has been reported with some user having issues with using DANKMEMECASH on the DEX, I will look into it when I focus back on freewallet updates in a few weeks
-
Dex orders using two divisible assets (amount error) · Issue #104 · jdogresorg/freewallet-desktop
When exchanging two different divisible assets on the dex, the amount used in the order for one of the assets is changed by several orders of magnitudes, AFTER placing the order. A similar error oc...
-
If I dropped everything to fix every issue that came up, I would make no progress... I group my work so that I can focus on one project at a time.... last few weeks it was defining CIP24... now it is updating xchain to support CIP24... after that THEN I will be focusing on updating freewallet with support for CIP24, and when I am focused on freewallet-desktop again, I will look into the issue
-
I estimate the issue will be fixed at some point next month
-
what functionality were you looking for? freewallet has the ability to sign messages, do a send, sign raw transactions, etc... all from a URI click
-
-
I’m building a wallet right now in react, github.com/loon3/counterparty-hwGitHub - loon3/counterparty-hw: Counterparty wallet for use with Ledger Nano S / S Plus / X
Counterparty wallet for use with Ledger Nano S / S Plus / X - GitHub - loon3/counterparty-hw: Counterparty wallet for use with Ledger Nano S / S Plus / X
-
This wallet, like rpw, builds all txs clientside, so it doesn’t rely on querying a node to build txs for you
-
Hmmmm could one be done for ColdCard too?!
-
Just an idea
-
Absolutely
- 20 October 2022 (62 messages)
-
Yea I’m using the version just before transactionbuilder was deprecated
-
Joined. -
there are other people running nodes and if im forced to maintain one i will, it becomes more difficult without a block explorer but could rig something up
-
we all just use jdogs tools because they’re easy and convenient
-
matt tan built the first counterparty block explorer, blockscan, which then become etherscan when he shifted focus to ethereum
-
im guessing he funds etherscan with ad space?
-
wallets and explorers are the lifeblood of crypto but difficult to fund
-
VC pays for it. And they required him to close down the xcp version. At least that's what i heard at the time.
-
You should be able to just pull the latest valid issuance Tx for an asset to see divisibility
-
You can also get asset divisibility in the get_balances call
-
I don't see it. :\
-
strange... works here when querying api.counterparty.io which is on 9.60.0 (we just added this flag in this latest version)
-
-
-
-
-
-
I have been working with Counterparty avoiding the read api as much as possible. The source of truth for this api are the SQLite tables. So, what I am doing is reading these tables directly.
I recommend every xcp developer to try this.
When you do this, you get a better understanding of the whole system and how things make sense. -
Divisibility have always been very simple to obtain: just get the genesis issuance of the asset. And a reference to this genesis issuance is stored in the assets table. So, a join from the asset with the issuance gets you the asset info including its divisibility.
Is only the last release, v9.60, that now allows changes on divisibility. Thus breaking the reliable simple way of obtaining it. And this is not final, as the asset could have its divisibility changed again in the future.
Some considered this an “improvement”. I just cannot see how this made Counterparty better. There is a long discussion about this for anyone interested (https://github.com/CounterpartyXCP/cips/issues/54).
If anyone wants to make their assets be universally compatible, they should NOT use the latest 9.60 issuance format.CIP3 concern: immutability in Bitcoin · Issue #54 · CounterpartyXCP/cipsI have concerns with CIP3, but I'm fairly new to Counterparty, so let me know if there is any misunderstanding in the following (and in the second part there are actual questions). Followin...
-
juan you can also use the most recent valid issuance
-
divisibility is a parameter in every issuance tx
-
and if its marked incorrectly it will be invalid
-
also what do you mean by universal compatibility, before and after 9.60?
-
because there have been a few breaking changes over the years
-
i assume you are not using enhanced sends then?
-
-
I am using 9.59. By universal compatibility I mean that the issuances done in 9.60 are seen as invalid in 9.59. But issuances done in 9.59 are perfectly fine and compatible with 9.60
-
I am open to suggestions
-
just say this “I mean that the issuances done in 9.60 are seen as invalid in 9.59. But issuances done in 9.59 are perfectly fine and compatible with 9.60”
-
im pushing back against your univeral designation because pretty much none of the txs used today would be compatible with the earliest versions of counterparty
-
specifically after when message type field was reduced to one byte
-
thats why i find it interesting you picked 9.59 as your source of validity
-
what is so special about that version
-
I can add: in the whole history of CP there are hard changes that makes txs incompatible with older versions, you can see in the code what is called "protocol changes". Without them, CP simply can't reproduce the data we use today, the one in the sqlite
-
Funny enough we’ve been working the past month on making sure a full parse results in the exact same data in the database as the current cp database…. We’ve discovered some issues where protocol changes were made in the past but not done properly with activation blocks added to protocol_changes.json… so, doing some cleanup to make sure all parses as it should on a full parse and reparse (full parse still takes almost a month to parse in all data)… reparse is much faster.
-
Fair. But you must also understand that if I am against the status quo, I need powerful words to deliver my message
-
The last version before the reset, the most backwards feature I’ve seen in this Bitcoin protocol
-
Maybe that’s because you’ve only seen this one update
-
No. I fully understand what was done with the reset. And the more I study the low level of Counterparty, the less sense it makes.
The immutability and simplicity of Bitcoin is what makes it special.
The addition of a reset is opposite to the foreverness of a blockchain asset.
Simple example: in bitSTART, there is a Rarest section. Here you can find “first” assets. Some of these, could be “reset”… meaning what? That after the reset they are no longer “first”???
Is disrespectful to the fundamental canvas for all art done in this protocol, the immutable Bitcoin ledger -
yeah i dont know what the hold up here is, maybe its the terminology thats bothering you, the word “reset”
-
every asset has a history of issuance txs
-
divisibility is just one parameter
-
you can check the history of any asset in the database. That includes, first issuance, description changes, resets and reissuances
-
nothing is deleted from the database, ever
-
They are not the same, but XCP is part of Bitcoin
- 21 October 2022 (35 messages)
-
the protocol is counterparty not bitcoin.
Do you feel the same way about changes to asset descriptions ? -
You mean if I am against “changing” asset descriptions? No. That is part of the nature of an asset, it can have multiple descriptions in its history.
I do think is weird that almost all implementations ONLY consider the latest one.
I don’t see descriptions as “changed”, I see them as added. -
For locked assets, you can also use the divisibility at the lock tx.
If i ever make another wallet i will include local tables for divisibility (for locked assets) and asse id (for subassets) to reduce api reliance. -
Discuss MonapartyXMP with English speaking enthusiasts! In Monaparty, there is no "official" admin to censor you, just an open and official community one joins simply by participating! CC-BY-SA 4.0 IMG by https://twitter.com/nachat_dayo
https://t.me/MonapartyXMP -
Just sharing the Monaparty chat. Perhaps XMP has some features we would like on XCP? 🤔
-
so its OK to have non foreverness when it comes to how the token looks and even what it does .. and for its quantity to be variable just not its divisibility. Seems very arbitrary that divisibility must be forever but look, feel, functionality and quantity can be anything
-
Do you think tokens should be locked by default on issuance?
-
Is not arbitrary, is how it has always been! And it keeps the protocol simple.
The main problem I have with the “reset” is that this does not really solve a problem. It is the opposite, now non-final actions, undo behavior, is allowed in a eternal canvas. It makes no sense.
But I am open to alternatives that are more aligned to the protocol. Like not having to commit to divisibility until you have set a quantity. -
About tokens being locked by default is interesting, but I think having unlocked assets is ok.
I believe that for this protocol to reach its maximum potential it needs to play by Bitcoin’s standards, it cannot do (or try to minimize as much as possible) things that go against responsible Bitcoin use. -
its already going against responsible bitcoin use if you ask most core devs
-
because it relies on storing information in bitcoin txs
-
Yes, I know. Reset dug a deeper hole
-
why is changing an unlocked asset’s divisiblity worse than issuing more?
-
Adding more quantity is simple, keeps the same interpretation of divisibility. Changing divisibility is another level, requiring a “reset” to accomplish!
There can be many reasons to add more supply in different events of an asset’s history. But what is a valid reason to change divisibility? Fix a mistake, I don’t see any other reason… enlighten me if there are -
fixing a mistake is a valid reason but also maybe you are unsure of whether you want a divisible asset at the time of issuance, just like you may be unsure of the amount you want to issue
-
keep in mind divisibility can only be changed for an unlocked asset that the owner owns 100% of
-
its undistributed
-
unlike asset supply that can be issued even after distribution
-
as long as the asset remains unlocked
-
divisibility is just a multiplier anyway, its effectively just issuing more or less of an asset depending on which direction you’re going
-
It not arbitrary it's how it's always been is an appeal to authority and a logical fallacy. The OG counterparty devs were not omnipotent beings they were simply fallable humans who made design choices at the time.
-
rules without rulers is the bitcoin ethos
-
I am not against changing divisibility at all. But I am critical of the way it was done in 9.60.
Where was the discussion of alternative implementations?
And what about this: https://github.com/CounterpartyXCP/cips/issues/55
Why LOCK was done by description instead of parameter in the first place? Where is the CIP that changes this to a parameter?Reset as a parameter or keyword? · Issue #55 · CounterpartyXCP/cipsIf I understand the Dogeparty implementation correctly, RESET is a new parameter added to the issuance message: This comes with some negatives; not backwards compatible (e.g. javascript libraries n...
-
if you read it, it doesnt change LOCK by description it simply adds the ability to lock via parameter which is very useful in that it allows setting a description and locking the asset in the initial issuance tx
-
It is useful to set a description and locking supply in the same issuance, true. But why this was not done like a parameter in the first place? There must be a reason…
My question is, where is the CIP that changes this? How was this change decided? -
im guessing it was probably added as an afterthought, but if you’re curious you should ask Adam Krellenstein
-
remember counterparty was created as a financial platform, with assets representing company shares
-
so in that application “locking” an asset doesnt make a ton of sense
-
the idea of using it for digital goods was emergent
-
this is also why callability was initially included
-
I appreciate this @hodlencoinfield , all good information
-
np, it might not seem like it but i do believe these conversations/arguments are valuable to have
-
Definitely
-
Was the recent twitter space with Adam recorded?
-
Unfortunately not. Too bad, was great to hear him talk about the early days n drama with the Bitcoin core devs n feeling like an outsider. 😢
- 25 October 2022 (7 messages)
-
This is serious. I have noticed that my cip3 updated node has not synced yet… and it seems to have restarted (maybe more than once?). What could be happening? If it finds an inconsistency it restarts or something like that?
-
probably because you didn't blow away the database and download the updated bootstrap version where a reparse is not necessary.... yes, your probably stuck in a reparse loop.... if you blow away your counterparty.db and counterparty.testnet.db files in federatednode/data/counterparty/ ... then restart counterparty, it should automatically download the latest bootstrap and get ya parsing again.
-
The bootstrap is not verifying all Bitcoin transactions, correct? What option do I have if I actually want to verify all transactions?
-
the bootstrap has been verified in the past... and bypasses the reparse (which can take multiple days). As I said earlier, Javier and I have been working the past month on fixes to allow for a full parse and a reparse to re-create the data in the CP database exactly as it exists now..... Unfortunately, some of the work done on the codebase in the past by other devs left some changes which should have been put into protocol_changes (as it causes txs to parse slightly differently).... Javier and I have been working on getting protocol_changes in place for these issues... its a time consuming process, gotta do a full parse (can take a month), then do periodic comparisons of the database up to block X to make sure all data matches in the existing DB and the full parse DB
-
tldr... gonna have to download the bootstrap and run on it... and avoid doing a parse/reparse until javier and I have completed our work and verified that a full parse results in the exact same data as the existing CP database.
-
When was the last time/ version that allowed full blockchain verification (don’t trust, verify)?
-
the code enforces a reparse on every minor version bump... so, guessing the last time a reparse was possible was on Jan 11th 2021 when 9.59.0 was released.... there have been a few hotfixes and other misc bugfixes which have been applied over the past couple years, which should have been put into protocol_changes.json, but some did not make it... so Javier and I are going through a full parse and finding these inconsistencies and adding them to protocol_changes.... full parse and reparse should be possible again soon.
- 26 October 2022 (14 messages)
-
Link
Happy to announce that https://t.co/fxQHnWdgKg now supports CIP25 enhanced asset information. Asset owners can now specify contact information, images, audio, videos, files, DNS records, and more! https://t.co/hyfZNjbsQd https://t.co/xtLoHHFjtS #Counterparty $XCP #Bitcoin
-
Enhanced Asset Information Specification
The enhanced asset info spec we have from the founders is good, but is very basic. I have been meaning to write a CIP to extend this asset information to allow for additional information to be specified in a standardized way, but have never got around to it. Now that we are at a point where users are abusing the ‘description’ field on xchain.io and using it to insert audio and video players and other random html, I feel defining the spec is a must. It is clear people want to be able to use a...
-
I have now integrated CIP25 support into xchain.io and returned the JSON description field to a text only field on XChain, and will no longer support displaying HTML in the description field after 30 days (giving services a bit of time to migrate to CIP25 with minimal interruption)
Loading user-supplied HTML content is generally an unsafe practice and is frowned upon, as the HTML/javascript code could do nefarious things. (For example, Someone could write up some code to dump a private key from a wallet and make an external call to pass the private key to a server, redirect you to some other site, install a CPU miner on your machine, or worse)
In making these changes to how the description field is treated on XChain, it became clear to me that there is a desire in the community to be able to push the limits of what is possible with tokens, and that we should provide some way to safely load/display user-provided HTML content.
Here are a few examples of tokens which are doing unique things by injecting HTML into an iframe
Rare Pepe Puzzle
https://xchain.io/asset/FAKEPUZZLE
Interactive / Augmented Reality Artwork
https://xchain.io/asset/PEPESTREAM
https://xchain.io/asset/NEWPEPEDESU
Artwork that changes based on the time of day
https://xchain.io/asset/FOURPEPAS
I propose we update CIP25 to add a generic html field where users can pass a chunk of HTML code to be optionally displayed.
I plan to update XChain to support this new “html” field and will allow loading of user-supplied HTML content after displaying a warning message and clicking a ‘Load’ button -
I thought that only assets to which you held 100% of supply, you can reset supply.
This is good if you accidentally made an error, made divisible. -
Or I read wrong?
-
Is about design, fundamentals, and the tradeoffs done for new features.
The current implementation complicates the protocol for everyone for a specific use case, which is specifically about fixing mistakes. It does not improve anything and is disregarding the most fundamental property of a blockchain asset, it’s foreverness.
What in Bitcoin is undo-able?
I believe a better solution is to allow people to not have to decide divisibility until they have set a quantity. This allows people to reserve asset names without having to specify quantity/divisibility, thus allowing simpler user interfaces, an improvement. -
But this is the most critical concern now
-
Correct Juan, which is why Javier and I have been making it our primary focus the past month.
-
Where can other people see and participate of this? This is open source software…
-
same place a they always can... in the CP counterparty-lib repo... the PR requests are public, all commits are public.... Tho at this point, it is primarily just Javier and I in a chat room doing parsing finding issues, adding protocol changse to resolve the issue, then restarting parsing.
-
protocol changes to get full parse / reparse working again by pataegrillo · Pull Request #1212 · CounterpartyXCP/counterparty-lib
Counterparty Protocol Reference Implementation. Contribute to CounterpartyXCP/counterparty-lib development by creating an account on GitHub.
-
There is the PR with the fixes and protocol changes so far... full parses take a LONG time (30+ days), and when an issue is found, we need to compare the databases and rollback to before there are differences...detect what the issue is, put a protocol change in place, then restart a full parse.... its a slow process unfortunately.
-
Haha, I don’t see how making something divisible, not divisible, is any different then locking supply or changing a description.
- 27 October 2022 (8 messages)
-
Look at the code. Quantities of issuances and destroys for an asset always were interpreted in the same way. With the reset, it now varies and the quantities no longer make sense. It used to be clean and elegant, all sums always made sense. Now, these don’t add up for the reset ones
-
I have seen that almost everyone sees this change only from the perspective of the user, not the technicals (code). Behind the scenes, it was a very backwards change in terms of the quality and elegance of the code. Adding complexity to the code should not be taken trivially. This should have been reviewed by multiple developers, comparing tradeoffs. I haven’t seen that this was done. A single implementation was done and pushed.
And now discovering that this was done without testing the full blockchain read.
This is bad -
What are you talking about? The CIP was out there for 8+ years and much discussion was had.... and "now discovering that this was done without testing".... umm... why do you think we have had NO downtime or issues with CIP3 since it has been implemented? Cuz Javier and I did a TON of testing on it beforehand... same with oracle dispensers.
-
If your referring to the parse/reparse issues, those happened before Javier and I started working on the codebase (believe it was John who made some emergency hotfixes and forgot to do protocol changes)... so, Javier and I found that out and have been working the last month on getting the parse/reparse functionality to reparse way old txs the same as the existing CP database
-
This should have been done before releasing. How was the block activation decided?
-
Usually you pick a time period from announcement then use that to estimate number of blocks to activation
-
Activation blocks were choosen to activate 2 weeks after 9.60.0 release, as has been the case in most releases.... activating features a couple weeks after release.
- 28 October 2022 (2 messages)
-
Joined. -
how does one clear the xchain cache of the .json, I update the .json and uploaded new images but think there is a client cache and not sure how to bust it of the timeing of it;s refresh
- 29 October 2022 (2 messages)
-
try clearing the cache and reloading an asset page... I made some updates... 1.) I use the cached JSON by default to instantly load the JSON data into xchain for user to view... 2.) I ALSO make a request to get the actual json file, and when that request completes, I update the page to display the latest JSON info
-
weird I did a hard clear in chrome before I ask and it did not work, but now after a new uddate is all loaded, thanks
- 31 October 2022 (6 messages)
-
is there a way to mint to an address
-
eg i mint something from my wallet pay the fees etc but i specify an address to become the owner of that asset
-
all in one transaction
-
rather then me having to mint then send the ownership and then send the asset etc
-
Yes I can mint/lock/transfer in a single tx… but no wallets support it yet…. But u can create the tx with the cp api, then just sign the tx in freewallet n broadcast
-
ok cool that is great, i expected it be the case i would need to create the TX, i will do some digging when i am out of the fiat mines! cheers!
Official Counterparty Dev Chat
Public archive of Telegram messages.
- 01 Oct 2022 (4)
- 03 Oct 2022 (1)
- 04 Oct 2022 (3)
- 05 Oct 2022 (13)
- 06 Oct 2022 (11)
- 07 Oct 2022 (1)
- 08 Oct 2022 (4)
- 09 Oct 2022 (5)
- 10 Oct 2022 (5)
- 11 Oct 2022 (23)
- 12 Oct 2022 (14)
- 13 Oct 2022 (17)
- 14 Oct 2022 (17)
- 15 Oct 2022 (12)
- 16 Oct 2022 (17)
- 17 Oct 2022 (14)
- 18 Oct 2022 (120)
- 19 Oct 2022 (62)
- 20 Oct 2022 (62)
- 21 Oct 2022 (35)
- 25 Oct 2022 (7)
- 26 Oct 2022 (14)
- 27 Oct 2022 (8)
- 28 Oct 2022 (2)
- 29 Oct 2022 (2)
- 31 Oct 2022 (6)