- 01 July 2024 (11 messages)
-
Joined. -
I'm trying to spin up a node with the latest version, my counterparty-core log is like...
worker exited x7
Catch up complete.
Starting blockchain watcher... -
That's like a ready state?
-
I made an issue about what I was encountering on github, I've gotten them to a place now where healthz says counterparty is not ready. So, I'm thinking I'll go to dinner and maybe it will have progressed in the meantime. But my tail of the logs ends at "Starting blockchain watcher" nothing beyond that.
-
Showing healthy after doing docker down and docker up again
-
-
fancy
-
I have a us and an eu server load balanced behind this endpoint, will start to futz around with using it this week
-
I’ll figure it out eventually, never used a load balancer with Google cloud
- 02 July 2024 (5 messages)
-
The latest release has an upgrading section that shows new config values that you need to set. If I'm starting fresh with a new 10.2 do I need to make these changes or are they done for me already? It might explain some of the issues I'm encountering, if I have to do it still.
-
tail counterpart-core
RS Fetcher - Stopped
Catch up complete.
Starting blockchain watcher...
/v2
"result": {
"server_ready": false,
"network": "mainnet",
"version": "10.2.0",
"backend_height": 850314,
"counterparty_height": 850286
} -
Kind of funky, not sure 47.84798916 XCP bounty to whoever helps me gets this node to do what is supposed to do.
-
I hope to be trying. To spin up a node later this week. I will be looking to do it on AWS and not docker. Will post any issues here - 03 July 2024 (8 messages)
-
I'm at the kickstart part of manual setup and my issue now is counterparty failing to connect to addrindex, the port isn't blocked or firewalled, not sure I tried localhost and 0.0.0.0. Addrindex has errors about not being able to connect to bitcoin but that makes sense because it's paused.
I'm trying to use the docker config settings compared to the server.conf I have in the manual install and there's config values set on the docker that aren't in the server.conf example configuration file. -
Gonna touch grass
-
I killed bitcoind yes
-
The error I’m getting is counterparty can’t connect to addr
-
I’m afk I’ll get back to you thanks
- 04 July 2024 (17 messages)
-
I made some progress, I installed bitcoin-core using snapd and so the block data is in a different path than the default config looks for, the usage.md on the addrindexrs github seems to be helping.
-
Ya that was my problem, you can have addrindex running and if you dont have the path to your block dat right it still kind of looks like its syncd up because its like "no new blocks to index at current height."
-
spamming the chan
-
Im looking this morning and overnight it looks like only a few blocks were parsed by kickstart and the nothing.
Block 278333 parsed (64/572374) and then nothing after that -
Im getting errors about the spinner set_message now when I retry I opened an issue about it
-
Something about set_message on the spinner in fetch_blocks is having an issue
-
Ah, Adam said now there is no kickstart what the heck lol
-
I'll check back later maybe 10.3 will be better
-
counterparty kickstart
counterparty kickstart. GitHub Gist: instantly share code, notes, and snippets.
-
If I just skip to server start instead of kickstart will that be another path I could try
- 05 July 2024 (3 messages)
-
What does BTCpay do in regards to Counterparty? How does Counterparty use BTCpay? I see it mentioned in the code and in the chats. Where does BTCpay touch the UX/UI/feature set? -
Is used for BTC order pairs. After there is an order match, then you have a number of blocks to complete the order with a BTCPay - 07 July 2024 (4 messages)
-
One of my two nodes looks fine, counterparty-server start shows it keeping up, but the :4000/v2 I cant connect to is there any way to debug that
-
I dmed you.. (Arwyn) -
I’m not sure I have the answer by the way so anyone else feel free to chime in
-
What it was was my server.conf needed to be updated to 0.0.0.0 vs localhost
- 08 July 2024 (5 messages)
-
Joined. -
i built a websocket zmq proxy you can run alongside counterparty-core with docker https://github.com/loon3/bitcoin-zmq-proxy -
the new counterparty-core zmq notifications are pretty slick
-
was a fun morning project to familiarize myself more with docker and communicating between containers
- 09 July 2024 (5 messages)
-
This endpoint has 92 results:
https://api.counterparty.info/v2/mempool/events/TRANSACTION_PARSED
But this endpoint shows 27 entries for TRANSACTION_PARSED:
https://api.counterparty.info/v2/mempool/events -
I wonder what the discrepancy is
-
looks like theres a 100 result limit on https://api.counterparty.info/v2/mempool/events/
-
Oh ok I see
-
I think my endless scroll isn’t working then
- 11 July 2024 (112 messages)
-
As part of v10.4.0 there will be two changes related to dispensers:
1. rather than being triggered by sending Bitcoin to a dispenser address, *dispense* will be a Counterparty transaction
2. there will no longer be both a source and origin for a dispenser; the source will be the origin. -
Just a heads up that I am not on board with the ‘dispense’ tx type. Bringing it up here as I already see it’s being promoted as a “certainty”…
For my explanation on why not, start here: https://github.com/CounterpartyXCP/counterparty-core/issues/1825#issuecomment-2197214567
Hope we can discuss it respectfully. And move forward in agreement (consensus).Implement `dispense` Transaction Type · Issue #1825 · CounterpartyXCP/counterparty-coreIt is a serious flaw in the protocol that dispenses are not normal Counterparty transactions. It was also not part of the original specification. A non-exhaustive list of the ways in which this cau...
-
Speaking of sock accounts I should make 2 accounts to comment from both of conflicting views 🤷
-
I commented on that thread
-
many people agree with the change but disagree with how soon it is being rolled out.... so this message isnt really putting into perspective the 3 separate Github threads of ongoing discussion....
most people who agree with the change (which I do actually!) also agree it opens up new pathways for people to lose money being used to the old way of doing things.... sure you can go ahead and 'rip the band-aid off' like Joe said...
what is most important to me to understand is how can existing wallet providers prepare and change the main used xcp wallets for this change when it drops?
.... again... as said by individuals that agree with the change (but disagree with how it will be rolled out to wallets)... what about the majority of users using older versions of Freewallet? I foresee a bunch of individuals on older versions coming to the FW chat getting angry they may have lost a significant amount of funds (probably alot I can see it coming....)
have you guys spoken to Shaban for being prepared for integration into existing wallets like CasaTookan?
How long would it take to update rarepepewallet with this prefix @hodlencoinfield ? would it be an issue you think? Does anybody use Freeport for Dispensers?
I'm not sure who runs Monya, but will Japanese users who dispense from that wallet be aware? -
and rpw? Monya? how will Jdog be expected to encourage users to use the most recent updated prefix vers of FW? will he have to say you HAVE to use the most recent version or risk loss of funds when buying from a dispenser?..... or when it drops will your special new wallet be the only one where users wont have to wait for updates (without risking losing funds when buying from a dispenser)?
-
lol thats what you get hung up on in that response? im trying to ask simple questions here sir
-
I asked a few questions about how wallet providers (for the whole XCP community) need to prepare for this... and you simply dont want to answer them it seems like
-
the real question is why do i spend my valuable volunteer time to try to look out for current users to not lose money with wallets and features they are used to and try to understand how to help them
-
there were two mandatory upgrades at the end of 2023 (does anyone remember why?!); there has been none yet this year
-
Dispensers (old/current implementation) and the whatever comes from the change (Vending Machines?) are and should be treated as, separate features; with different names, documentation and implementation in UI. The new implementation and the old implementation could exist simultaneously. IMO this is not an enhancement to an existing feature, but rather a new feature all together.
Wallet - Without an opensource reference wallet (Counterwallet down because of dependencies?), will users be forced to use a companies closed source wallet? An open-source protocol should include a set of known good and true tools, not tied to an indivudual or organization. An open-sourced reference wallet, simple or robust, would aid in adoption, while helping protecting users from fraud.
Testing - Please share the testing methodology implemented or intended prior to release, how can the community help test? -
i have disagreed with none of the other changes guys.... you are doing great work.... you patched previous unseen bugs... getting a node up and running seems really easy now (havent done it myself yet).... and i already stated i am in favor of this change.... i am simply asking will current wallet providers be prepared? what will be done for them to be prepared? what can we do to mitigate loss of funds? simple questions if you ask me
-
not entirely true, if you dont use the API for a bitcoin send then you don’t get the upgrade
-
i’ll probably just put a warning in RPW
-
-
not as easy as a warning 😛
-
but yes, wallet devs will need to do "something"
-
thats easy
-
anyone buiding a counterparty aware wallet should be up to date with the happenings of the protocol so this really isnt an issue
-
it sounds like it is the wallet providers responsibility to educate their own users to use the new prefix and provide them with a new version to do so as well as warning to not use the older ones
-
the bigger problem would be people purposely using wallets that are not counterparty aware which obviously you cant expect to change anything, but in this case changing people’s behavior is probably a good thing
-
i think there should be a general warning to users that using a non-counterparty aware bitcoin wallet to do counterparty things is not advisable unless you know what you’re doing
-
aside from this convo
-
-
i mean its always on the devs to do something
-
this is not like a new thing because of this one specific use case
-
how easy would it be to add the xcp dispense prefix into Electrum similar to how JPJA did CIP33?
-
Random Q, Freewallet used to support stamps.
Stamps has seen huge advancements in development lately.
Which stamp wallets (if any) support native Counterparty? Kicking stamps off of freewallet and xchain was the worst thing possible for user adoption. All of that momentum went to other channels. -
Thats different
-
a power user could do it just as easily
-
tricky part would be rc4 encoding but its def doable, but obviously not recommended
-
TheStampWallet -
Thats nice, at least not all stampers exclude counterparty. Thanks
-
Ninja Wallet (stamped.ninja) was built off of the open source FW data by Noop - shoutout to him he even found a bug doing so
-
Still (current transactions) or are you referencing in the past (historical)?
-
Counterparty Analytics
Detailed insights into Counterparty.
-
Retain Counterparty support?
-
Nice, someones been busy.
-
@sn_noop2 any issue with this dispenser change for your infrastructure? something that can be updated easily to ensure users dont lose funds on dispensers? not sure if you guys use the xcp API for simple btc sends?
-
im just trying to help.... make sure the community will be prepared... and now im going to make another coffee
-
i love xcp dot io so much ty Dan
-
@droplister
-
My XCP.io site I’m working on now to align to 10.2/10.3 it has stale data right now
-
It will get better with time
-
New APIs are clutch
-
Periwig or any others (no Mike in here any more?) can you speak about if CURRENT stamps transactions are still counterparty transactions or have they moved off completely on their own?
-
Art and recursive stamps are numeric assets
-
Src20s are not
-
Sounds like still counterparty to me
-
Not sure where Bitname falls under
-
It's difficult having technical conversations online via chat, thanks to all who stick with it.
-
Yeah better to go in depth in GitHub
-
But here is good for general feedback. Like this seems like too many (controversial) changes in a single release:
-
Design Spec. and Implementation Plan for Major Protocol Changes in v10.3.0 · Issue #1984 · CounterpartyXCP/counterparty-core
We want a formal design specification, plus a high-level implementation plan, for each of these significant protocol changes: #1825 #1843 #1842 #1857 #1939 #1431
-
Juan has and does contribute, much.
-
What request specifically?
-
The critical bug of adding a message to all counterparty transactions, so that addressindrs can be removed?
Read:
- https://github.com/CounterpartyXCP/counterparty-core/issues/1814
- https://github.com/CounterpartyXCP/counterparty-core/issues/1825#issuecomment-2223734619Remove ARC4 encoding (or make it optional) · Issue #1814 · CounterpartyXCP/counterparty-coreWhen a Counterparty message is embedded in opreturn, it is encoded with ARC4. opreturn = arc4(first input coin, message) I believe ARC4 was introduced in 2014 or '15 to obfuscate transactions. ...
-
Can you please provide an onboarding document or reference link for a developer who is brand new to counterparty? Great job with the https://counterpartycore.docs.apiary.io documentation, whoever did that gets a sticker.Counterparty Core API · Apiary
A place where APIs are kept.
-
What is the feasibility of electrs replacing addrindexrs? Or did you already do that? Could electrs save counterwallet?
-
100% feasible, already done as linked in the GitHub comment
Direct link to the “big commit” here: https://github.com/jotapea/counterparty-core/commit/62a901f45eedf9e4e9c8137c524e9b4b0dc5f817replacing addrindexrs with electrs, initial parsing works... wip · jotapea/counterparty-core@62a901fCounterparty Protocol Reference Implementation. Contribute to jotapea/counterparty-core development by creating an account on GitHub.
-
Do you not desire to have every BTC transaction be a counterparty TX? Dream big.
-
I know
-
Wow. Nice. Did you sumbit a PR?
-
Bitcoin and Counterparty Tools
Decentralizing CNTRPRTY: "Counterparty is Bitcoin. Is on top of Bitcoin. Is Web3. Is Web5. Two steps ahead." 🐸 - Bitcoin and Counterparty Tools
-
Not let Dans work go to waste.
-
An additional alternative I have been playing with FYI. https://github.com/bwt-dev/bwtGitHub - bwt-dev/bwt: A lightweight wallet indexer for Bitcoin, available as an Electrum RPC server and a modern HTTP REST API.
A lightweight wallet indexer for Bitcoin, available as an Electrum RPC server and a modern HTTP REST API. - bwt-dev/bwt
-
Nice, will check it out ty
-
-
We’re currently at the same usage as 2014. We need changes and I’m excited to see what happens. Hats off to the founders and team.
-
-
836 of the 896 are basically a new file electrs.py that is what actually replaces the addressindrs code. Is mostly a full copy-paste with minor adjustments.
It is an easy fix which compromises a bit (and maybe, haven’t compared) of parsing speed, which I believe is an acceptable tradeoff for not having to maintain a complete separate codebase! - 12 July 2024 (5 messages)
-
Design Spec. and Implementation Plan for Major Protocol Changes in v10.3.0 · Issue #1984 · CounterpartyXCP/counterparty-core
We want a formal design specification, plus a high-level implementation plan, for each of these significant protocol changes: #1825 #1843 #1842 #1857 #1939 #1431
-
1984
-
Shutdown complete.
git fetch --tags
git checkout v10.3.0
git status
pip uninstall counterparty-lib counterparty-cli counterparty-core
cd counterparty-rs
pip3 install .
cd counterparty-wallet
pip3 install .
cd counterparty-core
pip3 install .
counterparty-server start -
This is the upgrade procedure I followed that works
-
You need to pip3 the wallet before core otherwise core complains about the wallet having a dependency on 10.2
- 13 July 2024 (67 messages)
-
I've gotten rolled back to Block 0 a couple of times trying to run 10.3
Jul 13 00:20:45 counterparty-core-2 counterparty-server[738204]: counterpartycore.lib.check.ConsensusError: Incorrect ledger_hash hash for block 700000. Calculated 18b43382b3c1e18d78162d8a2ec323830309bcca1b7a65483bb5f4dbb6dc9043 but expected 4e84538d7bde57bbea518563f2a50f4245597bf5e5619fc4cbe9d981ab9d0adc -
Will see where it fails/if it fails on this next run
-
deleted the local db starting over i dont have the upgrade method down i guess lol
-
scroll up houston we just had that discussion recently
-
The only major change is you need to use a CP wallet to buy from the dispenser
If you use a non CP wallet, the dispense won’t occur
Similar to now, how if you use an exchange wallet, the dispense will occur but you won’t have access to the token -
I keep crashing at block 700k
-
Block 700000 - Order opened for 7215 BTC at 16xG9NoS (fbd0cfd) [open]
counterpartycore.lib.check.ConsensusError: Incorrect txlist_hash hash for block 700000. Calculated 997c53b7ca735452ea954d1cf3fc74e9b37eaaf4e180b092576483df12274cdd but expected abb48c10d692c159180a376b4a9002abcf582fab1b5652ba3ccdc73f4b5e0d8a -
Don’t run the latest as soon as is released. Wait. v10.1 is stable
-
afaict 10.2 is also stable, have had no issues with it running the last couple weeks
-
Im trying to code against the latest api changes
-
Also v9.61 is stable
-
I'm probably just upgrading wrong
-
you’re not using docker right?
-
im not using docker
-
i was told to not use docker or kickstart
-
sir yes sir
-
lol, im gaining a new appreciation for docker
-
If you have the node, you have the DB. The api just serves the data from the DB.
Sad that there has been so much trashing to using the DB directly. Which is the power user way 🤓 -
Docker is amazing!
-
I'm using Nuxt 3 as a front end, using an API makes sense.
-
You would wrap your queries in an api
-
I dont want to build my own api juan, you're a better developer than me
-
Is not hard, but cool. Then I would suggest you just wait a bit before upgrading your node
-
i dont dm gl
-
You can ask in t.me/xcpdevCounterparty Developers
Counterparty is Bitcoin. Developers in this room agree to constructively discuss implementations, improvements and the testing thereof. All participants should each represent what they believe to be ethically and technically responsible actions.
-
I think my issue might be with my upgrade procedure, I used something in the docs that looks like a 10.1 upgrade procedure so I didnt uninstall/reinstall rs or wallet packages, let's see if that fixes it.
-
The “official reference implementation” is being fully refactored. For better in some aspects, for worse in others
-
Ya, I'm onboard with it
-
Why avoid the official source? Can still verify it.
When you start adding in complexities, it becomes a lot harder to audit the security of site XYZ?
And the developers using the official source api will provide a ton of great feedback that will make it way easier and better for other developers in the future.
Someone has to be the first to do it to make it better. -
The cool thing about Counterparty is that it is verified by 2 of 3 hashes per block. It can be argued (and backed by simple checks) that v9 is still a great alternative to the new “official” v10 refactor.
There are tiers of developers. Reading the DB directly is what the “core devs” do. If you know what you are doing, then you also can. -
cant get the sendrawtransaction proxy to work in the API
-
{
"path": "/v2/bitcoin/transactions",
"args": [
{
"name": "signedhex",
"required": true,
"type": "str",
"description": "The signed transaction hex."
},
{
"name": "verbose",
"type": "bool",
"default": "false",
"description": "Include asset and dispenser info and normalized quantities in the response.",
"required": false
}
],
"description": "Proxy to `sendrawtransaction` RPC call."
} -
/v2/bitcoin/transactions/?signedhex= and /v2/bitcoin/transactions?signedhex= both return “Method Not Allowed”
-
maybe i’m missing something
-
its that plus my signed tx lol
-
what should the call look like?
-
oh its a post
-
not a get
-
will try that
-
makes sense
-
all set, thanks!
-
Now you… GET it
-
loool
-
sir i want everyone to see it
-
especially all the bitcoin nodes
-
Could always snail mail it to the miner if you trust the usps -
@dimesquanderer @AryanJab what made you puke?? lol
-
I also cringe when I hear “core devs” btw
-
A url get is simpler than making a SQL query. But making a query is not that hard either.
That was the context. -
Then “core dev” is also pedestal…
-
Didn’t work for me either. Manual install too.
- 14 July 2024 (1 messages)
-
Ya it borked at 700k again
- 15 July 2024 (5 messages)
-
Counterparty Explorer
Detailed insights into Counterparty.
-
Here's what I was able to make with the new API.
-
API is really good, I like it a lot. Sometimes it doesn't return results or I wish they were ordered differently, but overall it's easy to code against and work with and is getting better all the time right now.
- 19 July 2024 (1 messages)
- 25 July 2024 (1 messages)
-
Joined. - 31 July 2024 (7 messages)
-
Is anyone else encountering a division by zero error at block 853628 around an order match cancel/expiration?
-
Block 853628: ZeroDivisionError · Issue #2120 · CounterpartyXCP/counterparty-core
I ran into this on two nodes I'm running and I haven't seen it reported here. I will try a reparse. It looks like ledger.price may need some logic to catch division by zero errors and possi...
-
This issue has been reported but was misdiagnosed, I put in a reply to my issue the source of the problem and a possible solution.
-
I'm not sure how other nodes got passed this block
