- 02 May 2024 (1 messages)
-
Joined. - 03 May 2024 (2 messages)
- 07 May 2024 (14 messages)
-
This is the web wallet correct? If so, me -
Oh my bad, no have not
-
Not much in the last year -
I believe there are a couple of stamp users who may be using still, ( as in we initially used it to make tx) I’m sure “most” people are not using it and I would be happy to cross post in stamp group. Although I have heard one or two people still accessing their Og stamps via counter wallet. 🙏 -
In 2+ years I’ve never seen it being mentioned. I think is safe to assume nobody is relying on it. -
Well… I was not in this chat for a while so 🤣
- 08 May 2024 (75 messages)
-
Congrats! I will try this new API asap 🔥
-
About the v10.2 / v9.62? release, will the only protocol change be the removal of addressindrs? Or are other changes also going to be included?
-
Hmm… thanks for the link.
But it seems some of those might need more discussion, like the CNTRPRTY prefix for dispenses… imo. -
I don’t remember saying being in agreement with a specific implementation. I did understand the issue though
-
For science, how much weight (vB) is added to a tx for a dispenser dispense by adding the cp op_return data vs a bare tx? -
Also need to be sure to have a long enough window prior to activation to make sure everyone is aware that funds sent to dispensers from wallets not supporting the update will result in loss of funds -
Yeah for sure, and we’ll all need to help spread the word regarding the specific dispenser requirement since it directly affects users who don’t necessarily run their own node
-
I can think of a handful of people that I know use regular Bitcoin wallets to purchase from dispensers then just import private keys when they want to move the assets
-
It’s the Wild West out there! Lol
-
I’ve learned to never underestimate the lengths people will go through to add complexity to a simple process
-
The same considerations apply to transitioning to a UTXO based asset.
-
Or in our case, both address AND utxo based
-
That just opens up the attack surface imo, clicking on bad links etc
-
There’s no perfect method, which is why we see so many different options in the wallet space
-
Privacy concerns too
-
sir have you seen all the twitter horror stories of people getting wallets drained from a scam link
-
I once asked why not consider using clear text CNTRPRTY or XCP in the op-return as an alternative to nothing, which is what is already possible today. From this user perspective, changing this is already a UX downgrade IMO.
Only requiring this cleartext “flag” would mean that users with non-counterparty wallets can still easily make their dispense transactions by just adding this simple op-return.
And this would also mean that transactions that have other uses can still trigger dispenses (the flag is already present, in arc4 form) -
how many people have you seen post that they clicked on a bad link and their counterparty wallet was emptied
-
yes thats my point
-
but yeah, pluses and minuses to different approaches, a lot of room for new innovations in wallet software
-
not interested in playing the “if only counterparty did X” game
-
from my POV its been extremely successful and pioneered the entire token space and most of the use cases, but thats just my opinion
-
yes i agree, ive been building wallets for counterparty the last 9 years its something ive thought a lot about :P
-
(Continuing this parallel discussion 😆)
An AWESOME side effect of the cleartext will be that the protocol will be constantly advertised from ALL Bitcoin block explorers!
Even the “attacks” (non-counterparty relevant transactions that decide to add the cleartext for whatever reason) will promote it! And the protocol already handles these (supported column in the transactions table). -
im not arguing with you just giving you context
-
i think if you want to build a browser extension wallet then you absolutely should
-
im not against them, i just think they come with their own trade-offs
-
Counterparty is amazing! I’ve always admired it.
On that note, just updated xcp.dev!
It is an important update, even if it doesn’t seem like it (bc it prepares the whole github.com/CNTRPRTY project for v10)Bitcoin and Counterparty ToolsDecentralizing CNTRPRTY: "Counterparty is Bitcoin. Is on top of Bitcoin. Is Web3. Is Web5. Two steps ahead." 🐸 - Bitcoin and Counterparty Tools
- 09 May 2024 (1 messages)
-
Question, what is a bigger hit for nodes? The absence of a message for dispenses, or the fact that these never expire until canceled or drained?
- 10 May 2024 (43 messages)
-
The cips repository, including the discussion forum, has been archived.
I would like to share some notes on implementing names beginning with A. Where to post? -
Hi, thanks for the great work, my cp node is way more stable since 10.1.1 🔥
I had two question regarding the dispenser update.
- Will it still handle multi-buy in one tx?
- Will other CP tx be parsed for dispenser trigger? -
Allow named assets to begin with A · Issue #1783 · CounterpartyXCP/counterparty-core
This is a proposed protocol change: From a specified future block, interpret new registrations with ID >= 1.82e19 as named assets beginning with A. This implies that new registrations above that...
-
If I understood correctly, a purchase tx will have a message op_return like:
CNTRPRTY:dispense_code
1. Will it need the asset+quantity it's trying to purchase? Or it will blindly check each if each utxo is an attempt to trigger a dispenser?
2. Is it planned to check all utxo from any other CNTRPRTY tx? (Like making a purchase in the same tx as a mint) -
-
Wtf?
-
Guess I will have to learn about py-spy. Thanks for the follow up.
-
This is a huge UX downgrade. IMO
-
@teysol Who was involved in the decision to remove the CIP process?
-
Ok you may not be aware, but the CIP discussions was added recently as an alternative to the obscure forums. Conversations closer to the code, which is what ultimately matters most.
I would strongly suggest you put them back. Are they perfect, of course not!
But what is the alternative you are suggesting? Adam’s vision?
Please take no offense, but you must realize some of us (or at least me) were attracted to this project precisely because it had no (or is not supposed to have an) authoritarian leader.
Meaning it is closer to being truly decentralized. Closer to Bitcoin. The oldest (with flaws) but still alive and with REAL passionate users.
And we used that forum to protect from centralization. Maybe… you came back because of it. Or take this opportunity to explain why you decided to come back… -
It does not change anything to the current UI in freewallet
-
And would help with multiple dispensers on an address
-
I looks more like an UX upgrade to me than a downgrade
-
All discussion happens in github issues now which makes it easier having a single place
-
Most open ended discussions are happening here anyway
-
FWIW I'd be fine with using GitHub discussions instead of the forums. We could repurpose the archived cip repo—empty it of all actual content and rename it. But then I'd want to archive the Discourse forums. It's important to focus the discussion.
- 11 May 2024 (43 messages)
-
asking here for hopefully less drama, are any of these new changes involved in fixing 'counterblock' which as i understand is broken which is why wallet dot counterwallet doesn't work still..? It would be really nice to have counterwallet - or whatever it's new form is back with all this discussion of required wallet upgrades... -
(i'm not a dev barely a pretendgineer)
-
awesome, again not a dev at all but in my head somehow this dispenser logic (maybe the change with closing having a block countdown, whatever it's not important) situation was involved in the 'breaking' of counterwallet.
FWIW with the drama hopefully in the rearview i do think a very good look would be having some form a reference wallet, counterwallet or something that is not CLI - that is useable when this dispenser change comes out -
it's all slushing around in my head, and clearly i cannot do the work or even know what in entails. but just thinking out loud after reading and thinking on everything today
-
one good thing is the 'new mobile' solution is rarepepewallet dot wtf so if Joe is on board he should be able to put it into there, which will mitgate the concern of people using 4 year old freewallet o iOS and Andriod
-
which is a real concern but that's a lost battle, unfortunetly though not everyone has the resources to have a PC so i am concerned and amendible to these arguments
-
the mobile freewallet being the lost battle, not the inclusion of those that are limited to mobile/tablet devices
-
of course, after reviewing everything this change makes sense to me. But the concerns of edge cases is real, so all parties must be considered. I'm not worried. To be entierely honest my perspective is the fact that anyone (and apparently a lot of people) care baout this is the best sign i could hope for
-
so thank you everyone from every perspective
-
woe is us, people care about our software enough to have strong emotional opinions
-
I completely understand that I don't understand. Which is why i was tossing it as a "would be a good look" - i appreciate your realistic approach and delivery. I was blue skying this change, which as I said i believe makes sense, but that does't mean it doesn't need to be administed with finess and care
-
if freewallet isn't gonna do it you're gonna need something that does
-
or else you're now falling on to non'compliant counterparty wallet (AKA JP CODE + ELECTRUM) to work it
-
that that would be beyond ironic
-
Yes there are some mandatory things counterparty need to have when it comes to infrastructure such as integrator API, working end user reference wallet… I’m working on it. (Find the ressources) and build the team -
In other news, Ouziel's latest work on refactoring the mempool parsing logic has brought idle CPU usage from ~20% down to ~5% 🔥️️️️️️
-
Yeah I started working on it. And my previous opinion that it should let be RIP stood lol. I don’t think is worth it… may be better to rebuild a new wallet based on the core improvements.
-
That is old for sure.
In addition, there is the counterblock dependency. Which I think can be fully removed.
A new wallet app can be build that only needs Bitcoin Core + Counterparty Core. No additional middleware. - 12 May 2024 (1 messages)
- 13 May 2024 (74 messages)
-
Ideally the counterparty suite of tools and protocol could be finalized and sealed; only receiving updates when BTC core updates.
-
I’m I -
that sounds about as far from ideal as possible... otherwise we'd all still be driving Model T Fords -
Is it widespread tho?
-
It’s probably about the same proportion as people who think the same about bitcoin
-
I am not shocked at how widespread the view is that action equals progress.
-
Probably the same people too.
-
That in and of itself is no small change, it will require entirely new wallet designs and user education
-
It also opens a whole new world of integration with other Bitcoin metaprotocols
-
You’re never going to please everyone
-
Also idealism tends to overcome logic in a lot of these arguments
-
Lol
-
-
I am not an idealist at all. Just conversation.
-
The irony lol
-
Question: why burns.csv?
-
True, we are very proud.
And I’m quite disappointed by the attitude of the current “core devs”. Treating a supposedly decentralized protocol like if it is a private blockchain.
They are really good engineers. The codebase is so much cleaner now! And it was done without breaking protocol.
But the biggest problem IMO is the attitude towards different perspectives. Let’s move slower and in agreement, not force changes to move fast and break things.
I want to run “don’t trust, verify” counterparty software. We are in Bitcoin, so we should abide by their principles. Adding hardcoded data for the sake of efficiency is really unattractive IMO.
What is the limit of hardcoding data? We could do it to a point that there is not even a need to parse up to a certain block. I’m not interested in this though, so I’ll continue running the version that I can verify.
That’s why I’m looking into verifying the burns csv 🤓 -
assumevalid=0 -
I am inclined to agree with Juan .. no need to rush changes, full verification should not be a big ask .. its why we started with the nobootstrap idea
-
Drake mad: counterwallet is old broken software nobody uses
Drake happy: “don’t trust, verify” by running an old version of Counterparty -
😂😂😂
-
even better you could submit a PR with a script that anyone can run to validate if they want to
-
Yeah man lol. Switching opinions when is convenient.
But is ok, we have all these conversations in public and the rest can evaluate each one. And make their own conclusions. -
my opinion is we should be able to validate, but im not going to demand anyone build things or write scripts that i could do myself
-
so my suggestion was, build the thing you want to see
-
Sure. I am not demanding anything, I am conversing about what I don’t agree about the future plans of the “core devs”.
-
so whats wrong with me suggesting that you build the thing you want to see?
-
Nothing with those specific words. Is more about the whole attitude and characters that get revealed in these disagreements.
-
you were able to make a character and attitude assessment from my single message suggesting you write a script to validate a csv and submit it to the core repo?
-
No. We have history.
-
sure, im just honestly taken aback by your response to me making a simple suggestion which would benefit everyone
-
Fair. Let’s leave it here then.
-
Oh yeah!
One recent example is that I was very worried about the read speeds of balances based on the new log based database schema.
For most balances, they are not an issue at all. So I was wrong and have admitted it. BUT for large balances, like XCP and PEPECASH the worries I had are quite evident.
And FYI, at the high level of the whole protocol repository, most recent changes were things I have been suggesting forever. To the point I had already done many of them in github.com/CNTRPRTY.
So, in general, I am VERY HAPPY with the work led by Adam and implemented by Ouziel.Bitcoin and Counterparty ToolsDecentralizing CNTRPRTY: "Counterparty is Bitcoin. Is on top of Bitcoin. Is Web3. Is Web5. Two steps ahead." 🐸 - Bitcoin and Counterparty Tools
-
just sent .05 -
is there a testnet 4 now?
-
lol
-
does anyone know what this memo means (counterparty tx)? https://mempool.space/tx/874329a3e8f8c2ff78879e10c28f22750186744e15f144c07795b6c703946938Bitcoin Transaction: 874329a3e8f8c2ff78879e10c28f22750186744e15f144c07795b6c703946938Explore the full Bitcoin ecosystem with The Mempool Open Source Project®. See the real-time status of your transactions, get network info, and more.
-
sorry for the random question 🙂
-
I read runes projects started rewarding those who were making runes pre launch, and as a result testnet coins got value ...
testnet fees became high I guess as Lopp was mining empty blocks maybe to upset those trying to mint testnet assets?
Wiz been mining testnet4 blocks and has a link on mempool.space - 14 May 2024 (49 messages)
-
Hmmm... Memento's final message
Quite odd and interesting -
haha ikr 😉
-
was wondering what it'd say
-
or maybe it was a fee for a card issuance? he burned 300 pepecash with that tx
-
but was wondering if we could decode the memo somehow
-
2000 was the fee and the directory was closed by then
-
ah I thought like 200 or 300.. And word, interesting it was closed already! what date was it closed (I'm unaware)?
-
March 2018
-
so now I'm extra curious what it would say hahaha 😇
-
could be binary or base-64 -
yeah no clue haha, but interesting for sure! 🙂
-
assumevalid=0 was the inspiration for nobootstrap, being able to download the latest version and to verify not trust n fully validate everything like assumevalid=0 does was the goal
Sure checkpoints can n prolly should be used, just like bitcoin does so most won't assumevalid=0 but a user should be able to assumevalid=0 and have the code run from the block that contains the very first burn if they want to and for it to catch up in a reasonable time.
People that spin up nodes n think they validated the entire chain in <24 hours are not using assumevalid=0 and that's fine, they may think they fully verified the chain but they didnt
I understand a lot of work has been done in this regard .. seems a shame to then have a burns.csv when we have the blockchain just siting there, the csv file maybe a little faster but it gives the air of skipping blockchain validation and verification and makes is so to validate the csv you got to take extra steps -
that's xrp
-
ideally we want to achieve global state consensus with no bootstrap using the chain as source of data
-
a bootstrap is not an assumevalid=0
-
but we are not to run old versions its mandatory to upgrade . be nice if current version fully validated
-
sure we can have csv but you should be able to not need or want to use csv
-
me n Juan I expect
-
Didn’t renaming the github repo make running an old version extremely difficult for even wizards?
-
Or impossible?
-
I not been running a node since last year when it became a headache as to what version I was running .. I kept up but was too keen and ended up on fork with a fee for numerics
-
maybe Ill spin one up again i got a box with the fork from last year just sitting there a few tb of cobwebs .. but i will need to de dockerise as it was a fednode and I don't think that's a ting anymore either .. a lot has changed
-
bootstrapped fednode
-
Is there a good installation guide I can follow ? to start a fresh with no bootstrap, I don't want to kick-start it either am happy to let it validate
-
ty I'll try a manual install
-
I have no preference really .. just want a 'node' I can use to dev against .. I have a dedicated i5 32gb 4tb box so resources are hopefully not a problem .. as long as the apis respond I shoukd be good
-
the new endpoints in the v2 api makes it easier to create things like a block announcement bot on Nostr .. a bit like those that used to be seen on twitter last decade that were built atop counterblock
- 16 May 2024 (10 messages)
-
hey guys, I'm getting this error in freewallet (when buying a dispenser but also when trying to send an asset).. J-Dog says it's coming from CP API, anything wrong there?
-
- 17 May 2024 (5 messages)
-
no not really.. I just waited until now and it works again 🤷♂️
-
glad it works 👍
- 18 May 2024 (11 messages)
- 19 May 2024 (2 messages)
-
Hi, I have an issue with the Counterparty API:
I am sending a req to https://api.counterparty.io:4000/api/ with some payload to create a dispenser ("method": "create_dispenser").
The problem is that if I send the exact same payload multiple times, the response is not returned consistently (in the same way).
Sometimes I get it in a response object and sometimes the response is inside another response :)
Is this a known issue and what should I do as next steps? Should I add an issue in the repo (which one)? - 21 May 2024 (1 messages)
-
Joined.
- 22 May 2024 (5 messages)
-
Who's heading to Lisbon next week?
-
Would love to have a dev meetup. Even an informal one over a few beers would be nice.
- 23 May 2024 (2 messages)
-
Going there!
-
Let's go 👍 On 29th?
- 25 May 2024 (1 messages)
