With the 'subasset on numeric asset' upgrade, will you be able to issue a subasset from a subasset? I'm asking since subassets are a kind of numeric asset.

UTXO Support: can you attach an "asset ownership" to a utxo, or are only tokens supported?

But can you create a subasset from a subasset of a subasset of a subasset

There is only one subasset column in the db, but it can be 255 chars long on subassets

Think parent.sub.asset where the sub.asset with the period is the single subasset containing a period as a fake sub sub asset or moar

In that case you could create a sub sub sub asset where the sub sub asset doesnt exist because there is nothing on it to enforce

Opening up trading of token ownership is key! This question is very smart imo

Oh that would be juicy !!

https://docs.counterparty.io/docs/basics/getting-started/
Are the docs for running a node up-to-date?

Yes! I used these recently.

yup!

Nope, just the assets themselves. If this is something that would be very valuable, we can look into adding it for the next protocol upgrade

Are there any existing cp transactions that will be retroactively tied to a utxo automatically?

Its opt-in

Will vote for 🐸🫂

Hey guys if I send btc to my main addy and it has a dispenser does that friggen send an asset to the cex ??

Yeah

How do you get btc in that adress then.

Don’t use your main addy for dispensing

Ya I thought that’s the new plan haha 😂
Great way to burn supply haha 😂

Personally I consider it a feature not a bug. But I enjoy foistering my assets upon people 🐸🤷

Distribute 🤣🙏

Haha 😂 ya Ndax will love a bunch of my danks and I guess it shows in the history as a dispense haha

Fuckin funny

Can anyone tell me if this is a cex ? https://tokenscan.io/address/BC1QMAK6EJWEFZJ28JWEJ7KRU88NZW6CZK9GEYALWY

Looks like they opened a dispenser so maybe not ?

I’m not sure if I’m right about this, but I don’t think it’s usual that exchanges use legacy addresses

Ya seems odd but the btc I sent did trigger the assets to be sent to them
And it shows a year ago they opened an oxbt dispenser ? On that addy
So they trading ?? Xcp assets threw. A cex ??

Ndax is the one
I sent them an email hmm
🤔 love to hear what they. Say

Crazy that addy opened a dispenser for oxbt
And sold it for 13 btc haha

https://tokenscan.io/tx/546dd14ccf266574840983ff6f332d325e45de8439381c87e6ecf476695dd921

Someone exploited the fact that an exchange had published their new cold storage addresses and opened dispensers on them

Kind of a funny idea, but it was 90% of the activity for a long time

A quirk that will be a thing of the past with the update

How does that work?

Can anyone just set up a dispenser to send assets from the exchange's wallet?

Ya I think maybe aomthing hinky going on there support contacted me

I guess if you want to burn your assets or show fake sales ya they could

It is possible to open up a dispenser on an any address with no activity, but that will no loger be possible

I would be okay with my blunder if I didn’t see that the adress has debits and credits to dispensers and it opened a dispenser too
Under a different addy
I wonder if some nerd somewhere figure that out ?

And that scares me for loading my addy up with btc will this keep happening?

The update will prevent that from happening

my dispensers don't even work no more. You call that a update?

where is the tutorial video from the parties that changed it without asking ?

How is "no activity" defined in this case?

It's simply an address with no transaction history. This individual saw a tweet by the cex I believe where they would publish their addresses for transparency and he opened up a bunch of dispensers at wild prices

So they guy opening a dispenser at a CEX address was using his own assets (he deposited them at the CEX address?)?

Yeah

It hasn’t been updated yet…this is a you problem

implemented the decoding of counterparty-data just to get a feel for how data is embedded. Now when I look at my result I am wondering how I can get the Type, the Asset name and the Status? I used Jp Janssens decoder as an example so I knew that type was "Dispenser" for example and what the Asset name and status was.

(sorry status is irrelevant obv - need mapping for asset name and type only)

Hahha yup and there returning them also some hinky shit happend on there end

@teysol found a regression in the v1 API which prevents getting info from transactions table via API requests... works in 9.61.3.... throws error in 10.4

https://i.gyazo.com/29df8b1cf268f226e91ae484f91fc681.png

https://i.gyazo.com/b4724cf81058b497755c3394cc556288.png

I’ve got btc wandering around in the atmosphere right now ??

If the expectation is that Tokenscan.io get on 10.4 and not stay on 9.61.3... and avoid a fork... then the v1 API needs to continue to work... Please address this regression ASAP

In the process of updating counterparty2mysql (which tokenscan.io and spells of genesis and other projects use)... but am unable to parse blocks due to this regression.

https://i.gyazo.com/4f121ce577459b146f75661a5af9e707.png

Thx for your attention in this matter @teysol ... should hopefully be a simple fix 🙂

Haha and now it’s finally sent lol sorry

@BrrrGuy thanks for reporting. Will investigate 👌

@BrrrGuy this release includes a fix for that bug you found 👆 Please let me know if you find any others 🙏

🎊 Announcing Counterparty Core v10.4.3 🎊

This is a minor release with a number of bugfixes and minor improvements to the API. No special upgrade procedure. (Reminder: you must have upgraded to >= v10.4.0 in the next ~10 days!) Full release notes available on GitHub: https://github.com/CounterpartyXCP/counterparty-core/releases/tag/v10.4.3 💙

(rolling this release out to api.counterparty.io shortly)

Thank you... found another one... not consistent, but still causing issues.. I can prolly work around it, but pls check into why get_running_info returns null data for last_block at times under 10.4

9.61.3... returning last_block as expected

https://i.gyazo.com/780d212ef7a2a58b1af7f6086dda1b98.png

10.4... returning last_block as null at times

https://i.gyazo.com/1bafa697ea206dc0db09c4d456ed3364.png

FYI... updated to 10.4.3 on my local node api01.coindaddy.io... still getting the last_block: null periodically on my local node... even after a restart... api.counterparty.io seems to be returning last_block fine... not sure why my local node is not passing last_block at times.. any ideas appreciated...

https://i.gyazo.com/666b77a10b6fdbc4c07ce3a8549f47da.png

also, are fairmints enabled on testnet to do some testing with?

I tested this out 1000 times against my local node without reproducing.

The path where you could end up will NULL is here:
https://github.com/CounterpartyXCP/counterparty-core/blob/6bfc1a34f420929e03806c2f7b665ab8b94bfee8/counterparty-core/counterpartycore/lib/api/api_v1.py#L832

so one thing you could try would be directly running the query it's trying against the local db with a sql client.

"""SELECT * FROM blocks WHERE block_index = ?""",

upgraded thanks!

yup. it's all live on testnet

and will look into the last_block sometimes being null bug 🙏

Here's a step by step of how to do this. This line appears to be querying for something it already knows: util.CURRENT_BLOCK_INDEX. so @teysol could probably just get rid of this extra database query altogether, and set last_block to util.CURRENT_BLOCK_INDEX, unless I'm missing some subtlety.

Assuming you're on a default config, otherwise replace it with wherever your API database is.

sqlite3 counterparty-core/storage/counterparty-docker-data/counterparty/counterparty.api.db

sqlite> SELECT block_index FROM blocks WHERE ledger_hash IS NOT NULL ORDER BY block_index DESC LIMIT 1;
864327
sqlite> SELECT * FROM blocks WHERE block_index = 864327;

this should have at the 0th index the same number you queried for.

only seems to happen periodically... after the next block is parsed in by counterparty-core, the last_block goes from null to the expected data... its not a show stopper, just a weirdness occasionally

yep i did reproduce it locally leaving the test on for a longer period of time

FYI... testnet is in a tailspin since block 3080560

https://i.gyazo.com/aa28f4401013f662a4ebc203e687209e.png

Also, I strongly suggest you guys spin up a testnet node on api.counterparty.io:14000 so people can test things on testnet

@teysol pls lmk when testnet is back up and functioning again.. was doing a reparse of testnet data into tokenscan.io when testnet choked n went down. thx

So that's a bug above. I filed it here: https://github.com/CounterpartyXCP/counterparty-core/issues/2316

But I think it should also be avoided by this open PR: https://github.com/CounterpartyXCP/counterparty-core/pull/2315

We have a testnet node at api.counterparty.io:14000 it's just been having difficulty staying up with testnet under attack recently, and possibly because of the above issues.

yep okay we found a deeper bug—will fix

@BrrrGuy fyi, we fixed the bug and testnet is working again at dev.counterparty.io:14000. we'll release v10.4.4 tomorrow with the fix and push it out to the prod servers

thank you 👍️️

when do the dispensers come back online?

Dispensers work right now

I just bought a RARETODDPEPE a couple hours ago

Ok I'm going to open a dispenser now

Haha fantastic

I can't open it already open

so my question is am i going to face a new process next time i open a dispenser??

If you have an actual bug report please file a ticket.

Otherwise protocol changes have not yet activated.

https://x.com/neweramuzic/status/1843475574398038305

Hello!
My name is Sako from the Zaif System Development Department.
I apologise for the delay in contacting customer support, but I was unable to join the Counterparty Slack workspace.
We are in the process of preparing our response to the upcoming upgrade.

Hi, @NatsukiSako . Thanks for posting here. I just DMed you. Happy to help you with the upgrade in any way you need.

Thank you so much for your hard work on upgrading the node software and for taking the time to reach out to the community 🙏🙏🙏

fyi having another stability issue with both prod and dev testnet. open issue: https://github.com/CounterpartyXCP/counterparty-core/issues/2335

Also any way anyone knows this person
I got front run on an. Xcp dispenser and would love the xcp or $ back

i can't see your history and it doesn't show on the blockchain where u sent btc to the dispenser

i could probably see it if you posted your whole address that photo is cutt off

One sec

https://blockstream.info/address/1AKwAbft2PTk695VDpuMTHg4XmZzaZpc9x

It’s there received my btc but dispenser got emptied before my low fee transaction happened

@CosimaTacro
Any chance boss man of getting that btc back !? Let me know
Or if you have some more xcp I’ll take that ?!

Any one know him ?! Them ?

https://xchain.io/tx/4ed67ade43a71d149bb90a10c5f53ef7851b312a9d1604ad1c0f3995813c9938

I think 🤔 maybe the money came back lol I have to look I’m at volleyball

What is that ?

Yup it came out and I did not receive my .00484 btc back.
So I would love it if someone could have a look see if they know that adress ?! Any fair person would return that btc

https://x.com/neweramuzic/status/1840838048185270422

I hear some what what your saying say more ? !
You talking. About this ?

Or !?

Hmm 🤔 cool

Hmm 8 dispenses the rest look like sends
And also we are In the wrong chat for tokens

👋

Hi, Cody

Just to confirm, are you saying that you sent 0.00484 BTC but haven't received the XCP yet?

Hi yes 🙌
I put low fees on it and it got emptied before my transaction went threw is all
But it was a lot of $ for me haha

If you have more xcp I’d be fine to accept that or btc back ?! Even if xcp a higher price now

I dmed details if you need

I checked my wallet history and dispenses and confirmed the receipt of 0.00484 BTC.

Could you please confirm your wallet address?

Yes mine is 1lsb
1 Assets I’ve made determinpepe

1LSbNkNGUidmQavQPqbqPR1MxqmHzwwEuY

I didn’t realize the issue and already transferred the funds to BYBIT EXCHANGE. The withdrawal fee from BYBIT is 0.000139 BTC, and I would greatly appreciate it if you could cover this cost.

Oh yes just send the remainder after the transfer I get it thanks 🙏🏼

Oh k I can send back the .000139

Send back to the same adress as received from ?!

I appreciate you ! For fixing this and I apologize. For the inconvenience.
Xcp is hot and I should always use larger fees haha 😂

Thank you so much for your understanding. I truly appreciate it!

YOUR ADDRESS:
1LSbNkNGUidmQavQPqbqPR1MxqmHzwwEuY

AMOUNT:
0.00484 - 0.000139 = 0.004701BTC

Is everything okay with this?
I will proceed with the transfer from BYBIT as soon as the final confirmation is complete.

Oh yes if you just deduct that amount for transfer that’s fine thanks 🙏🏼

Glad you guys settled it but I think the main room is better for non dev conversations vs here

Plus more people will see it

Sorry that’s was running around in my head

This will be my final post regarding this matter.

Txid:
f35c7f26b29a9dc5d908714f9c54fa8493254299738e2c777453cee6e7f635a5

DMs

@teysol Can you please add the Header set Access-Control-Allow-Origin: * to the next release? making requests to api.counterparty.io from a browser is failing due to this flag missing. The Pre-flight check request does not return this header, so no additional request is made, end result is that users who want to query the CP API from a browser to generate a tx are not able to.

https://i.gyazo.com/f1268cceec80b93b4987407aae8fe9b1.png

Use JS and bypass it

Is normal in many websites

looking for backwards compatabilty with the previous versions of counterparty which passed this flag and where additional hoops were not needed to jump through to make the request.

A request to 9.61.3 returns the Access-Control-Allow-Origin: * header

https://i.gyazo.com/7a379a2381a72c154680e2c4d29f2507.png

Only need does in JS the cors error is because u are calling from u server to an external server

A request to 10.4.4 DOES NOT return the Access-Control-Allow-Origin: * header

https://i.gyazo.com/5844d8b76eb409f057c37cc3872f796f.png

Well in my website work all the API perfectly with js

I change the code from php to JS and all is ok

https://i.gyazo.com/51bf9134690d6eccbc0387bb1bab69a7.png

Dunno what to tell you other than it isn't working on public.tokenscan.io which just does a simple jquery request (same as it did to 9.61.3)... the ONLY difference (and the reason the request is failing) is because there is no Access-Control-Allow-Origin: * header being returned on the pre-flight check request or the actual request.

again, looking for what was discussed, reverse compatability with 9.61.3 API... this is the last issue I am encountering (btw, nice work on making posts to / endpoint automatically go to /v1/ endpoint... saved me some redirect time) 🙂 @teysol

@BrrrGuy yup, happy to add that header

Thank you sir 🙂

yeah no problem. it's super annoying when those headers are missing

FYI... the CP API docs should be updated to indicate block 866,000 instead of 900,000 for the block at which open_address must match address... or in the v1 API source

https://i.gyazo.com/59caf551fed7f254dbceba63aaea8155.png

https://counterpartycore.docs.apiary.io/#/reference/compose/compose-dispenser

So what happens to dispensers already opened ?!

So had my first message is this a payment to a dispenser that’s new ?! On rare pepe wallet i assume so you can use main addy as a dispenser eh

FYI still having some intermittent downtime on testnet. The network is under attack (blocks are coming like every 5 seconds), and it's triggering some race conditions.

Hmm

That's odd —- any idea why anyone would attack a testnet?

Is it possible they are practicing or looking for vulnerabilities they could exploit on the mainnet?

pretty normal for testnet over the past few years... long periods with no blocks, then 10-20k blocks in a day.

Hey guys so am I gonna loose my assets if I send them lol
I have no idea if they are attached to utxos or not and how would I tell
And then. If there are what do you Do ?!

Scary messages about loosing my assets in rare pepe wallet lol
Spooked me out of sending and buying
Others have been asking me too like I have any clue

Nope you can send and buy as usual, no changes happening there.

All upcoming UTXO attachment changes will be handled carefully in the wallet UI, and you will have to OPT IN. This is a feature you will have to manually use yourself, you won’t just start losing assets Willy nilly.

Haha okay how could I tell if an asset is attached to a utxo?
Would that only be until the transactions fully clear ?

Wallets and Explorer ui

No asset is binded..unless requested by user

Case use- market places, atomic

Lol if you don’t know what it is then don’t worry about it

It’s a preemptive warning

Haha sounds good

So if a user choses to bind an asset to a UTXO, what is to prevent that user from "accidentally" spending that UTXO in transaction? Are there any protections against accidental spending of the UTXO and sending the asset somewhere it wasn't intended... or is the only safeguard "Gotta have tight control of UTXO management in the wallet"?

I think there can't be any such safeguards without compromising the whole feature, at least at the protocol level. The goal is to be able to move your assets just like Bitcoin UTXOs, or like Rare Sats or whatever. There could be safeguards in the wallet, however.

text messaging

Utxo smart wallets

Unisat shows you if assets are in utxos that are about to be spent

Wallet avoids drawing payment from dust balance utxos

I’ve been thinking about the best way to handle in the wallet and I’m leaning toward using the change address associated with each wallet address via derivation path as the designated holder of utxos

thats why each address in the wallet should have its own set of private keys

Don't they already...

Each address has its own private key

what good is that going to do when it has the same 12 passwords ?

Sir

great, so your naturally going to come out with some type of guide on how to "safely" manage utxos for wallet developers who want to build wallets on the platform right?.... It would certainly seem to be unfair to add a feature to the platform, then only build it in your wallet... I realize your a for-profit company building for-profit projects.... but, your also building on a "community" platform... so, as such, I would expect some type of guidance to be put out on how to integrate fairmints and utxo binding in wallets.... (I am aware how to do it, just pointing out that without some guidance for "OTHER" devs, could be seen as unfair and sketcy.... even moreso than a "for-profit" company maintaining the "community" platform and private explorer and wallet).... not trying to be a jerk, just trying to make it clear how this could appear to an outsider.

A lot of this info is in the apiary doc

links? all I see is API docs (endpoints and params), not how to manage utxos... provide links pls

looking for stuff like "Wallets should be careful when spending UTXOs to make sure they are checking UTXOS in transactions to make sure they are not utxos which have assets bound to them", etc... not finding any of that in docs.

As I said, all I am seeing is endpoints and params...

https://counterpartycore.docs.apiary.io/#/introduction/events-reference/utxo-support
https://counterpartycore.docs.apiary.io/#/reference/compose/compose-attach
https://counterpartycore.docs.apiary.io/#/reference/compose/compose-detach
https://counterpartycore.docs.apiary.io/#/reference/compose/compose-movetoutxo

Dont see any sort of documentation or guidance on wallet/UTXO management, warnings about not to spend UTXOs with assets attached to them accidentally, warnings to only use compatible wallets, etc.

What is to stop a user from attaching an asset to a UTXO, then importing their private key into say, electrum, and sending some BTC to a different address? If I am not mistaken (which I may be), in the referenced case, the asset-bound UTXO would be spent, and the asset would be unintentionally sent along with the UTXO? Correct?

I mean those warnings are all over wallets before signing, also on Explorers when minting or buying from Dispensers....

But these are fair educational seminars for users

Alot of the practice is carried from other protocol requirements, so it's kind of becoming a space standard

As a new feature/tool educational seminars would be useful by community

I agree with that

what is to prevent someone from using "Horizon wallet" to attach an asset to a UTXO... then that same user using "Freewallet" to do a normal send via CP API... what safeguards are in place to prevent the unintentional spending of the UTXO? Does the counterparty-core automatically check for asset-bound utxos and NOT include them in transactions when generating txs to sign unless explicitly told to do so?

No this would be the users disclosure. User must be aware of which wallet or assets being used

Same way we juggle ordinals/runes on our leather or unisat

Ux needs to be there

Ui

I don't think it's the protocols job to not allow the spending of assets.....

forcing all the UTXO management up to the wallet level seems like a mistake... seems like you would want to, at the very least, enforce this rule I mentioned, so that anyone USING the CP API to generate transactions as they have in the past, do not accidentally spend an asset-bound UTXO..... shouldn't be that tough to tweak the UTXO selection method in counterparty-core to exclude UTXOS which have assets bound to them (if this is not already happening)

I know users who spend runes all the time, airdropped tokens or mints that went no where

Would suck if protocol stopped you from using those utxos

I mean if the idea is to stay in a corner with only xcp assets.

Brrr Guy if this doesn't happen people can potentially loose "money" correct?

Atomic is to open cross protocol swaps, and these warning and disclosures will be needed

but until recently, counterparty was an ADDRESS based protocol... now it is moving to a UTXO and ADDRESS based protocol... so, seems like there should be SOME basic protections in place on a protocol level... I understand if someone uses a UTXO on a non-CP compatible wallet, its the wild west... but if someone uses the CP API to generate a transaction which unintentionally spends a asset-bound UTXO, that is no good..... IMO you gotta at least do some "good faith efforts" to protect users on a protocol level from making mistakes.

correct.. 100% people will lose money if they use asset UTXO binding and then unintentionally spend that utxo

Will wait for a reply from @teysol on this 🙂

Interesting take.

But I mean for example Leather, OKX, and Tap/Universe Wallet are all preparing for such

If it's separation of assets or utxo management

elaborate what are they doing ?

But I do understand the difference from a CounterParty designated wallet and a multi protocol support

do they all use a centralized API to generate their transactions for signing? Counterparty does.... no wallets except for rarepepewallet.com generate their own txs... ALL of them use the CP API via (compose) functions to generate txs to sign in the wallet... all i'm saying is the CP API should have some basic protections... tweaking the UTXO selection model to exclude UTXOs that have assets bound to them is at least SOME level of protection

Things to continue learning. Did not know that was the only case

I do know hitting the api is most efficient

In terms of integration

counterparty is the foundation everywhere

only time utxos with assets bound to them should be used in the CP API is when your referncing them in the utxo specific endpoints attach/detach/moveto

They support stamps/src20s

Also Mintify made a comment of supporting xcp tokens

drop the link

So there is wallet developers across the Bitcoin Space watching

Why do you want to protect THIS at the protocol level but not dispensers, where users CONSTANTLY accidentally lose funds. Makes no sense

https://x.com/Mintify/status/1846586950678950170

oh there's more than that watching....

Dime... lets focus on one thing at a time... dispensers fight is over.... I am now asking why not put some basic tweaks on the CP protocol to protect users from unintentionally spending utxos.... NOT doing so seems to be bad form... My interest is in protecting users from losing funds and assets (the ONLY reason I decided to update to 10.4 instead of fork).... lets keep this focused on the topic at hand... the new UTXO feature and how to protect users who use the CP API to generate transactions (everyone) from unintentionally spending UTXOs and losing funds

Fair mints information is somewhat out but not specifically how to do it in the wallets just a bunch of techie info lol 99 percent of us users and “buyers” and card makers are not up on GitHub info I mean just look at the GitHub follower counts there super low hah
So if fair mints starts tomorrow what do I do and how can I mint
Fairly ?! Im interested

tweaking UTXO selection model to exclude asset-bound-utxos is easy to do... and, not interested in debating it back and forth... will wait for a definitive answer from @teysol .... not interested in wasting time/energy fighting on something.... just saying how I see things, offering suggestions on how to offer some basic protection on a protocol level, and will let the core dev give his reply. thx.

There’s an “exclude_utxos” parameter you can use with compose to filter out any asset-bound utxo

Until there are wallets implementing utxo binding it’s not going to be an issue, now is the time to determine best practices etc

cool, where is the endpoint I can use to get a list of all the asset-bound-utxos? it is on the wallet dev to dump a list of all the asset-bound-utxos, then add every one of those UTXOs to the exclusion list? What is your objection to tweaking the UTXO selection model in the CP API to automatically prevent using asset-bound-utxos except in the case where specifically using UTXO management endpoints attach/detach/moveto?

An exclude_utxos_with_assets parameter seems fine to me, no objections here

Would support an exclude_utxos_with_assets parameter with default set to true, so requests which do not specify the param are protected. Glad to hear you agree with a param at least 👍️️️️️️ Easy enough to update wallets to include this additional param

yeah this sounds great. does anyone know of an easy way to query runes/ordinals to see if someting is attached to a utxo? sounds cumbersome checking all potentials, but curious. ie if i have a utxo tx_hash, check x api's to see if something is there.

I would also presume the CP api calls like create_dispense would not select at least a CP bound utxo?

I wouldn’t assume anything lol

Gotta just run tests against the api with some asset bound utxos

Until the tools are built normal users won’t have to worry about it

so Counterparty Core ideally shouldn't be doing *any* UTXO selection. that's properly the responsibility of a wallet. however, for historical reasons it does, and other wallets rely on that (including, for the moment, Horizon Wallet, which is... open source). in the long run, we should all move away from that architecture; but for the foreseeable future we'll of course maintain backwards compatibility. I don't think it's unreasonable to consider the safety implications of that. I've created a GitHub issue to require passing a flag to the compose API endpoints to allow spending UTXOs with assets attached: https://github.com/CounterpartyXCP/counterparty-core/issues/2375

So are you calling me normal thanks no one has ever called me that !

Good stuff !!

Thank you sir👍🏻

Okay so the first bit of absolute goofiness just happened.
I sent to a dispenser I alway use and then I got a dispenser sale for hodlepet
That I never made don’t even know what the fuck that is but it took .002 btc from me ?? What the hell ?!
You can see they happened at the same second
Couldn’t buy two things like that if I tried !
So ? Was hodlepet also tied to the utxo of the dank meme cash I bought or ?

https://tokenscan.io/tx/092ae95525f5e1834e9a12c5399802a9a8f588b906e4ed8f080db2c5d8eef38e

https://tokenscan.io/tx/2488b1cfc1f8031ecfd55235333e657990509ca2b2d64293bc000d0454368408

Figure that one. Out ?

Interesting description on hodlpet
https://hodlpet.github.io/hodlpet

@teysol I just update to 10.4.5 via git pull and now my API throws nothing but errors

https://i.gyazo.com/20684a7be7a70875674990403560f862.png

I guess hodlpet is gonna be a fantastic little new tech trophy haha ? lol 😂

api.counterparty.io works, but it is only on 10.4.4... any ideas when you will update api.counterparty.io to 10.4.5? the release of 10.4.5 was 8 hours ago...

also api.counterparty.io is down now

went down at activation block 866000

will wait a lil while for a response to this... then switching my public.tokenscan.io back to point at a 9.61.3 server.. so at least freewallet users can generate transactions until you guys figure out what is up

Any acknowledgement of "we see an issue and are working to get it resolved" would be appreciated. Thx.

Also... while I wait for ANY response from the core devs... checking out testnet, and I see this

https://i.gyazo.com/75bb1f41732cb7fbe410c77f84bc66ae.png

Can someone explain to me why counterparty-core is making calls back to telemetry.counterparty.io every block?

over an hour and a half and still not an acknowledgement of any issues from anyone on the core dev team.... am switching tokenscan.io and public.tokenscan.io back to using 9.61.3 for now... so FreeWallet users are at least able to keep generating transactions, and tokenscan.io users are at least able to have a working explorer... You guys can figure out the rest when you wake up and make it a priority to get the 10.4.XXX protocol and APIs back to a working state.

In the future, might be a good idea for someone to stay awake for block activations to make sure all goes smooth.

https://github.com/CounterpartyXCP/counterparty-core/issues/1522

seems that I'm joining [too] late the party

I should have paid more attention to this UTXO blindness issue

One if the important value proposition of counterparty, as oposed to colred coin (yes that's old) was the security for the users

while I beleive it's important to foster inovation, it should be done at the expense of user experience

my feeling is the ecosystem is not ready for this important protocol change 😕

https://x.com/CounterpartyXCP/status/1846827903662575811

Thanks for the link.... I dont want my node sending any data to any other systems (and feel that should be disabled by default).... In the issue you linked I see Obviously all of this data is 100% anonymous and there'll be a flag to disable it entirely..... Yet I see no information on how to disable this feature... I would like info on how to disable this feature, as promised

Also... updated to 10.4.6 as the links suggested... node seems to be catching up (not up yet, cuz it is still parsing in blocks)... will report back once caught up if I am able to make API calls as expected

Tho I do notice 2 interesting things...

1. Parsing of blocks is taking a long time... multiple minutes with this new minting feature enabled

https://i.gyazo.com/bf4de533d828ae5f47072efd96ca0f7a.png

2. Curious how all these mints from all these different addresses are taking place (thousands of them), all without any CP nodes being up... Its not a protocol issue per-se... just something to note that a ton of "MINTS" are being minted... and probably not by normal end-users.

Droplister announced that, could be him

So now the 10.4.6 node is caught up on parsing after many minutes.... and now its having issues talking with bitcoind after getting caught up.. was fine talking to bitcoind a few minutes ago when parsing in data from blocks

https://i.gyazo.com/b473b00dace084c8bb2d64e9442cdd63.jpg

yup, figured it is him, but didn't want to point fingers... just make ppl aware to make a mental note that the first "fair mint" on CP was done by an individual and not lots of users minting from lots of places (as the mints appearing from lots of addresses would indicate.

Is your node and API up on 10.4.6 yet @hodlencoinfield ?

Nope, I switched to api.counterparty.io for the activation block since I was sleeping, will update mine in a couple hours

Got it... heading back to bed for another couple hours.. will check the status of things when I get back up n head to yoga.... sure would be nice if the core devs would be in here, engaging in a time of crisis and downtime for the community.

I found this on GitHub (tbc - haven't tested it myself):

NO_TELEMETRY = False
Look for the above line in your config.py file and change to True

so I have to manually tweak a core file config.py in counterparty-core then recompile? vs using a simple flag when starting up? also, AFAIK counterparty releaes use docker images now (I see docker images being pulled every update), so... this isn't really a solution, manually editing a file... I would prefer to wait until we get some official answers from @teysol rather than accepting your semi-technical answers (no offense, but not sure your exactly aware of how counterparty-core operates and how running/updating a node work)

pretty sure the no telemetry option is just an oversight, and a simple flag to enable/disable via the command like can be added pretty easily... the telemetry is not really a huge deal right now, got more pressing issues, like API down. 👍️️️️️️

FYI... now getting SQL constraint errors on 10.4.6.. just passing info along that might be helpful to diagnose the issue... for when the core devs eventually engage here

https://i.gyazo.com/788fa5cda9323e9fa0f111db1cbead50.jpg

so you're the brave buying hodlpet 😂 looks like a ded projet now (no news from dev since many months), however welcome 😁

Not sure if anyone solved this already but I'm getting this

Should get the kinks worked out this am

Ok.. thanks ser

🚨 UPDATE 🚨
There was a bug with v10.4.x that caused the node to start processing blocks extremely slowly, causing downtime for wallets and other applications. We've released a new version v10.4.6 which addresses this issue, but there was unfortunately a regression in that version too. To get it to work, you need to pass --wsgi-server=werkzeug on the CLI, or add it to your Docker Compose config. We'll be releasing a new version shortly that addresses the issue more definitively.

None

10.4.4 seems to be running fine on my two nodes. 10.4.6 is successful to upgrade with the regression or best to just wait it out?

I'm on 10.4.4 and it seems to be working fine too. Better to wait for 10.4.7?

if v10.4.4 is running well for you, no need to upgrade!

Weird my v10.4.4 stopped at block 865999

yeah i'm surprised mine survived. on pretty low end vm's

yeah it was a weird performance-related bug. different machines will handle it differently. and esp. weird since it was so severe and so sudden.

Fair eh lol 😂 lmfao 🤣

It was some kind of accident?? Haha if you can screw something up I’m the guy to do it lol

No idea I will send you dm to not pollute this tg😁

🚨 **v10.4.7 Hotfix Released** 🚨

There was a bug with v10.4.x that caused a large number of nodes to slow to a halt when processing transactions for UTXO support. We've released a new version v10.4.7 which completely addresses this issue and is fully backwards-compatible. If you're having issues with your node, please upgrade.

Release: https://github.com/CounterpartyXCP/counterparty-core/releases/tag/v10.4.7

None

is this last image uploaded to dockerhub?

docker: Error response from daemon: manifest for counterparty/counterparty:v10.4.7 not found: manifest unknown: manifest unknown.

hm it's possible it's still processing

lemme try to pull it

could be okey

thanks adam

yep, it's building.

ah nope, I was wrong. it was a fat-fingering of the version number. fixing now

was the only fix from .6 to .7 the wsgi parameter?

more or less

cool, ill stick with .6

https://i.gyazo.com/c199bcdc70c0f7bd4d28040f1c4de0a5.png

would be nice if the running version number was printed when starting up counterparty-core... I ran git pull... but still having API issues.. and not sure if I am on 10.4.6 or 10.4.7

I didn't see docker updates after I did the git pull and restart... so assuming 10.4.6... but not sure since no version printed on startup

So we just discovered we fat-fingered the version number for v10.4.7 and it'll report v10.4.6.

The docker image is mislabeled.

Re-pushing right now

k lmk when I can git pull again... off to eat muh breakfast burrito 🙂

but yes, we should be printing the version... I'm surprised we don't do that already

hm, this is what I get:

> counterparty-server start

Counterparty Core v10.4.5
Verbosity: 0
Quiet: False
Network: mainnet
Configuration File: /home/evan/.config/counterparty/server.conf
[...]

I think your tail is cutting it off

https://i.gyazo.com/f1e19c8caf4ed71762f725cb262f26b3.png

ahh... so it was.. thx.. now I see version number

yeah that's misreporting the version. but the API should be fixed. let me know if there's still an issue

https://i.gyazo.com/d46e59f77ca90e0709f08ffed24a0158.png

guess i'm just waiting on docker image to build so I can pull it without error

yup

it's building now

okay, v10.4.7 image is on Docker Hub 👌 https://hub.docker.com/layers/counterparty/counterparty/v10.4.7/images/sha256-606c2e564577061960cf2bba18a0ec0cbf31d976fb1673a44e551f5b1dc05035?context=repo

"no healthy upstream"

just discovered we're having some additional memory pressure issues on api.counterparty.io (UTXO support is heavy)

working on it

https://i.gyazo.com/bd0a25dbf2ce8ee2494f7831c478a8c4.png

my api also just went down

API seems to be working again in 10.4.7 now

its still parsing tho

my 10.4.4 went down. 10.4.7 coming online atm.

Still seeing some wierdness with not being able to communicate with bitcoind after parsing catches up.. just FYI

https://i.gyazo.com/ddb710435e9bff19c09c1ebd66c2fe15.png

interesting, i don't see that, but i manually set the rpcuser and rpcpassword to something specific and not rely on what ends up in the bitcoin.conf. could be related i guess.

i got an error when restarting my node so im upgrading to 10.4.7 now

okay we're seeing sporadic reports of potential secondary issues. on it.

i noticed when i updated to 10.4.7 that it didnt have the wsgi parameter in the docker-compose

interesting, with get_running_info on 10.4.7 i get {"error": "Counterparty not ready"}

even though the logs on the container show it's caught up.

did you just enable it by default or something

yep thats where im at with 10.4.7

{"error": "Counterparty not ready"}

I think there may be a problem with how Counterparty is communicating with Bitcoin Core

but my API calls arent registering with counterparty-core

if it can't communicate with Bitcoin Core, then the API will say it's not ready or similar

counterparty-core-1 | INFO:werkzeug:172.18.0.1 - - [17/Oct/2024 16:12:19] "POST /v1/ HTTP/1.0" 200 - is usually what i’ll see

and more verbose for v2

but im not seeing that at all when im getting this error

so right now v1 and v2 arent working

yup

okay multiple issues being reported

yeah v1 and v2 give me 'counterparty not ready'. but the logs look like it's caught up and talking to bitcoin core:

2024-10-17T16:13:50.282+00:00 - [ INFO] - Starting API Server...
2024-10-17T16:13:51.165+00:00 - [ INFO] - Starting API Server v1...
2024-10-17T16:13:51.165+00:00 - [ INFO] - Catching up...
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
self.run()
File "/usr/local/lib/python3.10/dist-packages/counterpartycore/lib/api/api_watcher.py", line 942, in run
catch_up(self.api_db, self.ledger_db, self)
File "/usr/local/lib/python3.10/dist-packages/counterpartycore/lib/api/api_watcher.py", line 679, in catch_up
parse_event(api_db, next_event, catching_up=True)
File "/usr/local/lib/python3.10/dist-packages/counterpartycore/lib/api/api_watcher.py", line 659, in parse_event
update_assets_info(api_db, event)
File "/usr/local/lib/python3.10/dist-packages/counterpartycore/lib/api/api_watcher.py", line 417, in update_assets_info
if not existing_asset["issuer"]: # first issuance
TypeError: 'NoneType' object is not subscriptable
2024-10-17T16:14:04.591+00:00 - [ INFO] - RS Fetcher - Indexer initializing...
2024-10-17T16:14:04.592+00:00 - [ INFO] - RS Fetcher - Connecting to database: /data/counterparty/fetcherdb
2024-10-17T16:14:04.658+00:00 - [ INFO] - RS Fetcher - Connected
2024-10-17T16:14:04.658+00:00 - [ INFO] - RS Fetcher - Initialized
2024-10-17T16:14:04.658+00:00 - [ INFO] - RS Fetcher - First database op: GetMaxBlockHeight...
2024-10-17T16:14:04.658+00:00 - [ INFO] - RS Fetcher - First database op: GetMaxBlockHeight took 21.781µs
2024-10-17T16:14:04.658+00:00 - [ INFO] - RS Fetcher - First Bitcoin client op: GetBlockchainHeight...
2024-10-17T16:14:05.219+00:00 - [ INFO] - RS Fetcher - First Bitcoin client op: GetBlockchainHeight took 560.310673ms
2024-10-17T16:14:05.219+00:00 - [ INFO] - RS Fetcher - Starting at block height: 866080
2024-10-17T16:14:05.219+00:00 - [ INFO] - RS Fetcher - Targeting block height: 866080
2024-10-17T16:14:05.219+00:00 - [ INFO] - RS Fetcher - Fetcher started
2024-10-17T16:14:05.601+00:00 - [ INFO] - RS Fetcher - Entering reorg window
2024-10-17T16:14:06.627+00:00 - [ INFO] - Block 866080
2024-10-17T16:14:08.719+00:00 - [ INFO] - Block 866080 - 100000000000 MINTS minted for 0 XCP by 18Vtu2K7WLYmXAnzLYwB1iCLEy8FwPdWpX
2024-10-17T16:14:08.771+00:00 - [ INFO] - Block 866080 - 100000000000 MINTS minted for 0 XCP by 19gy8S8iEFsQz7UxQw27VD9r3Jm6Kddr6J
2024-10-17T16:14:08.817+00:00 - [ INFO] - Block 866080 - 100000000000 MINTS minted for 0 XCP by 1PmDiLb9CPDvB5NvqRqQMsoDBbQCo55WBv

with one seemingly minor exception 🙂

yup okay

that's a bug that's causing the API server to die

yes same here, everything parsing just fine, just no communication via API

im seeing the same error you’re getting too
counterparty-core-1 | parse_event(api_db, next_event, catching_up=True)
counterparty-core-1 | File "/usr/local/lib/python3.10/dist-packages/counterpartycore/lib/api/api_watcher.py", line 659, in parse_event
counterparty-core-1 | update_assets_info(api_db, event)
counterparty-core-1 | File "/usr/local/lib/python3.10/dist-packages/counterpartycore/lib/api/api_watcher.py", line 417, in update_assets_info
counterparty-core-1 | if not existing_asset["issuer"]: # first issuance
counterparty-core-1 | TypeError: 'NoneType' object is not subscriptable

yup

patching

{"result": {"server_ready": false, "network": "mainnet", "version": "10.4.7", "backend_height": 866086, "counterparty_height": 866077, "documentation": "https://counterpartycore.docs.apiary.io/", "routes": "http://api.counterparty.wtf/v2/routes", "blueprint": "https://raw.githubusercontent.com/CounterpartyXCP/counterparty-core/refs/heads/master/apiary.apib”}}

its interesting that the api can be behind but the node isnt

the API process checks to make sure that the node isn't behind, and *it* is failing

gotcha, is it just a caching thing then that it gives a result with the wrong block for counterparty_height?

it's not really caching

the process is just behind

ah ok

*update* still debugging these issues

appreciate the update

there are three known issues: https://github.com/CounterpartyXCP/counterparty-core/milestone/39

some endpoints still work oddly

yeah prolly api v1 vs v2?

https://api.counterparty.wtf/v2/blocks

so that works on v2 AND on v1

oh

yeah so the issue is that the API has a safety check where it blocks some routes when it's behind

depending on whether or not they can get out of date

ah ok so makes sense it would let the blocks call through

you could try restarting your node with --force

yeah maybe not all calls to /blocks...

its still behind tho, just the API not the node itself

node is on Block 866087 but the get_blocks call only gives me through 866078

counterparty-core-1 | 2024-10-17T17:40:54.663+00:00 - [ ERROR] - Bitcoin Core ZeroMQ notifications are incorrectly configured. The following notification must be enabled: ['pubrawtx', 'pubhashtx', 'pubsequence', 'pubrawblock']
counterparty-core-1 | 2024-10-17T17:40:54.663+00:00 - [ WARNING] - Sleeping 5 seconds, catching up again, then retrying...
counterparty-core-1 | 2024-10-17T17:40:59.668+00:00 - [ INFO] - Catching up...
counterparty-core-1 | 2024-10-17T17:41:01.178+00:00 - [ INFO] - Catch up complete.

someone having this error?

not here, i did notice the zmq wasn't setup in the bitcoin.conf which seemed odd to me tho

👀....

@reinamora_137 what do you mean?

fwiw im not seeing that

docker-compose.yml is the same as my 10.2.0 backup

could be possible to share it?

its whats in the counterparty-core release

i do have a couple extra flags for counterparty-core zmq

which also doesnt appear to be working

another weird thing with the blocks call is null hashes for 866078

"result": [
{
"block_index": 866078,
"block_hash": "00000000000000000002e51e276363d707cc1750b99e2c3a88ccf920b74a757b",
"block_time": 1729180747,
"previous_block_hash": "00000000000000000002b8b8caaded272bd77a2c034160f7ca47b3553a7e42c7",
"difficulty": 386076365,
"ledger_hash": null,
"txlist_hash": null,
"messages_hash": null,
"transaction_count": null,
"confirmed": true
},
{

but when you call the block all the messages are in there

what's that call?

v2/blocks

so another funky thing

{"result": {"block_index": 866078, "block_hash": "00000000000000000002e51e276363d707cc1750b99e2c3a88ccf920b74a757b", "block_time": 1729180747, "previous_block_hash": "00000000000000000002b8b8caaded272bd77a2c034160f7ca47b3553a7e42c7", "difficulty": 386076365, "ledger_hash": null, "txlist_hash": null, "messages_hash": null, "transaction_count": null, "confirmed": true}}

this is the result of v2/blocks/866078

but there is an old v1 call

"method": "get_blocks",
"jsonrpc": "2.0",
"params": {
"block_indexes" : [866078]
},
"id": 0
}

and that will return a message list

and this is the last message in the list when you call the tx…

"result": [
{
"tx_index": 2764174,
"tx_hash": "1bd7ad0f3582b0cf03f91a56382ae131447b2d9add0e7b363ee91e27e213e790",
"block_index": 866078,
"block_hash": "00000000000000000002e51e276363d707cc1750b99e2c3a88ccf920b74a757b",
"block_time": 1729180747,
"source": "1MZUaVy6y7vmwh2MqMKTFy2JiqXteyevpN",
"destination": "",
"btc_amount": 0,
"fee": 100000,
"data": "5a464149525354414d507c50455045454d4252594f7c307c317c3130303030307c313030303030303030307c307c307c307c307c307c307c307c317c317c307c275354414d503a2f396a2f34414151536b5a4a5267414241514141415141424141442f3277424441414d434167494341674d434167494441774d44424159454241514542416747426755474351674b43676b4943516b4b4441384d4367734f43776b4a4452454e44673851454245514367775345784951457738514542442f3277424441514d4441775144424167454241675143776b4c454241514542415145424151454241514542415145424151454241514542415145424151454241514542415145424151454241514542415145424151454241514542442f7741415243414143414149444152454141684542417845422f38514146414142414141414141414141414141414141414141414143502f4541427751414149434177454241414141414141414141414141414543417755454278454142762f45414255424151454141414141414141414141414141414141414159482f38514149684542414145444167634241414141414141414141414141514944424155414551595449535178513146792f396f4144414d424141495241784541507741783747754c614c595030386364706c6f69584f6171717337414143642041447668567278586e2052447671336739732f6e36314a7350663364624857395370566b795951565a4b71784e31642071362f2f32513d3d27",
"supported": true,
"utxos_info": "1bd7ad0f3582b0cf03f91a56382ae131447b2d9add0e7b363ee91e27e213e790:0"
}
],
"id": 0,
"jsonrpc": "2.0"
}

no destination

very strange

hmm maybe not, if its asset creation

i'm just confused why we are seeing new trx coming in while everyones node is down lol. where is that mysterious node?

At least a couple were me lol

I’m building txs in the client so don’t need the node

You can go around nodes?

Send me that inbox please

👻 **v10.4.8 Hotfix Released** 👻

Following the activation of the protocol changes at block 866,000 the network has been experiencing intermittent outages, due to a number of bugs not caught by our testing. We've just released a new version of the node software—Counterparty Core v10.4.8—which addresses all known issues and is completely backwards-compatible. All users should upgrade as soon as possible. Thanks everyone for the patience with the downtime. 🙏

Detailed release notes: https://github.com/CounterpartyXCP/counterparty-core/releases/tag/v10.4.8

None

counterparty-core-1 | 2024-10-17T19:59:49.003+00:00 - [ WARNING] - Sleeping 5 seconds, catching up again, then retrying...
counterparty-core-1 | 2024-10-17T19:59:54.008+00:00 - [ INFO] - Catching up...
counterparty-core-1 | 2024-10-17T19:59:54.080+00:00 - [ INFO] - Catch up complete.
counterparty-core-1 | 2024-10-17T19:59:54.082+00:00 - [ ERROR] - Bitcoin Core ZeroMQ notifications are incorrectly configured. The following notification must be enabled: ['pubrawtx', 'pubhashtx', 'pubsequence', 'pubrawblock']

im still receiving this error

@XJA77 can you share your bitcoind configuration file?

yes

dm you

when counterwallet back online?

Counterwallet died many months ago

it's unmaintained

In case you missed it — https://t.me/Counterparty_XCP/241602

https://i.gyazo.com/27241df63df7e286275dbda42e947dab.png

Getting null for block hashes for block 866078 ..... version 10.4.7

4.8 is the one

6 unconfirmed actions are they going to confirm ? lol what’s the time on those

10.4.8 stable/working? sketched out about updating since update from 10.4.5 to 10.5.6 killed my API

on v10.4.8 I'm getting a good result:

> http GET 'localhost:4000/v2/blocks/866078'
HTTP/1.1 200 OK
Alt-Svc: clear
Content-Length: 554
access-control-allow-headers: *
access-control-allow-methods: *
access-control-allow-origin: *
content-type: application/json
date: Thu, 17 Oct 2024 20:30:54 GMT
server: Werkzeug/3.0.1 Python/3.10.12
via: 1.1 google
x-bitcoin-height: 866103
x-counterparty-height: 866103
x-counterparty-ready: True
x-counterparty-version: 10.4.8

{
"result": {
"block_hash": "00000000000000000002e51e276363d707cc1750b99e2c3a88ccf920b74a757b",
"block_index": 866078,
"block_time": 1729180747,
"confirmed": true,
"difficulty": 386076365,
"ledger_hash": "c96b85abb8254ec9ff0ecfd8b4fe93930632e7977d25308c679a67d1f09fbe88",
"messages_hash": "3e0dd298209e8c2cf0e17c5c2e3b65a775001bd9a5c3447d69841659d27169e7",
"previous_block_hash": "00000000000000000002b8b8caaded272bd77a2c034160f7ca47b3553a7e42c7",
"transaction_count": 49,
"txlist_hash": "1acd0b7b50c095a9bf42a2c083a5c6110e38a509485dd4ebd8796f41b0bf321a"
}
}

Yeah all good here

Stamps back to indexing validating a node on a full parse too

ok... will update... how can I rollback 10.4.8 to block 866077 so I reparse that block and get block hashes? @teysol what commands pls

@BrrrGuy yeah that's understandable. we've had lots of stability issue today, and we've made a number of hotfixes. we don't know of any serious issues outstanding with v10.4.8

V1 and v2 apis confirmed as well

counterparty-server rollback 865999 is the safest

k, will update and do rollback and report back. thx

what is the command to run via docker compose?

ah I'm not sure of the best way to do that. it's a bit messy

fwiw I'm not sure that you need to roll back. it might just fill in the block info correctly

k, i'll bring it up and check

Confirmed. block hashes are present now. thx

btw, still seeing:
'no healthy upstream' on api.counterparty.io

i can dig in some more on the api construction, but any thoughts on why the fairminter create api endpoint would bork up a base64 string and change the data when it adds to the description field?

input: /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAACAAIDAREAAhEBAxEB/8QAFAABAAAAAAAAAAAAAAAAAAAACP/EABwQAAIBBQEAAAAAAAAAAAAAAAECAwAEBQYHIf/EABUBAQEAAAAAAAAAAAAAAAAAAAAH/8QAHhEBAAIBBAMAAAAAAAAAAAAAAQIDEQAEITEFBkH/2gAMAwEAAhEDEQA/ABJtHXOrwbNl4YOnbZHHHfXCoi5q5CqokYAAB/BV5j634XcBbbs6pSlyrXBVeVVMqvbpZVXTNrriERwAYAOgPga//9k=

output (with spaces added and an extra ' at the end of the description.

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAACAAIDAREAAhEBAxEB/8QAFAABAAAAAAAAAAAAAAAAAAAACP/EABwQAAICAwEBAAAAAAAAAAAAAAECAwUEBxEABv/EABUBAQEAAAAAAAAAAAAAAAAAAAYH/8QAIhEBAAEDAgcBAAAAAAAAAAAAAQIDBAUAEQYTISQxQ1Fy/9oADAMBAAIRAxEAPwAx7GuLaLYP08cdploiXOaqqs7AACd ADvhVrxXn RDvq3g9s/n61JsPf3dbHW9SpVkyYQVZKqxN1d q6//2Q=='

kind of odd if it changes regular text strings as well.

back to p2wsh for data 🙂

you can add data to a fairminter?

should work yes, this data is not processed by counterparty afaik

the description field.

aka stamp:base64 encoding=multisig

and using p2wsh too

the stamp: came through ok and detected as a stamp, but the description got mangled somewhere along the way

next up unprunable fairmint stamps 😉

result": [
{
"tx_hash": "1bd7ad0f3582b0cf03f91a56382ae131447b2d9add0e7b363ee91e27e213e790",
"tx_index": 2764174,
"block_index": 866078,
"source": "1MZUaVy6y7vmwh2MqMKTFy2JiqXteyevpN",
"asset": "A13917892337457772759",
"asset_parent": "PEPEEMBRYO",
"asset_longname": "PEPEEMBRYO.FAIRSTAMP",
"description": "'STAMP:/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAACAAIDAREAAhEBAxEB/8QAFAABAAAAAAAAAAAAAAAAAAAACP/EABwQAAICAwEBAAAAAAAAAAAAAAECAwUEBxEABv/EABUBAQEAAAAAAAAAAAAAAAAAAAYH/8QAIhEBAAEDAgcBAAAAAAAAAAAAAQIDBAUAEQYTISQxQ1Fy/9oADAMBAAIRAxEAPwAx7GuLaLYP08cdploiXOaqqs7AACd ADvhVrxXn RDvq3g9s/n61JsPf3dbHW9SpVkyYQVZKqxN1d q6//2Q=='",
"price": 0,
"quantity_by_price": 1,
"hard_cap": 1000000000,
"burn_payment": false,
"max_mint_per_tx": 100000,
"premint_quantity": 0,
"start_block": 0,
"end_block": 0,
"minted_asset_commission_int": 0,
"soft_cap": 0,
"soft_cap_deadline_block": 0,
"lock_description": true,
"lock_quantity": true,
"divisible": false,
"pre_minted": false,
"status": "open",
"earned_quantity": null,
"commission": null,
"paid_quantity": null,
"confirmed": true
},
description is wrapped with '

ooooh so its a fairmint of a new asset

as opposed to MINTS

fairmint of an existing asset

fml.... spamming the UTXO set with "forever" entries is def going to get stamps a bad name... also why I think it can't scale long-term... your abusing the UTXO set, requiring every node to have more RAM to hold these "unprunable" UTXOs in memory... I can sorta see a value prop to having the IMAGE data stored in utxos... but storing every mint in a forever UTXO IMO is just really abusive... but what do I know 😂️️️️️️

yeah i guess the quotes were a problem. this was the api call

https://api.counterparty.io:4000/v2/addresses/1MZUaVy6y7vmwh2MqMKTFy2JiqXteyevpN/compose/fairminter?asset=ORTUS&encoding=multisig&lock_quantity=true&divisible=false&max_mint_per_tx=100000&hard_cap=1000000000&description='STAMP:/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAACAAIDAREAAhEBAxEB/8QAFAABAAAAAAAAAAAAAAAAAAAACP/EABwQAAIBBQEAAAAAAAAAAAAAAAECAwAEBQYHIf/EABUBAQEAAAAAAAAAAAAAAAAAAAAH/8QAHhEBAAIBBAMAAAAAAAAAAAAAAQIDEQAEITEFBkH/2gAMAwEAAhEDEQA/ABJtHXOrwbNl4YOnbZHHHfXCoi5q5CqokYAAB/BV5j634XcBbbs6pSlyrXBVeVVMqvbpZVXTNrriERwAYAOgPga//9k='&allow_unconfirmed_inputs=true&exact_fee=100000&lock_description=true

however i'm super confused how it ended up with spaces in the base64

kinda like you stamps guys were doing when you were doing an issuance for every "MINT" tx... aka "shitting in the sink".. but alas, I digress... this is what CP is for now I guess since we now embrace that type of abusive behavior on bitcoin.. lol... now back to updating tokenscan.io

lol. i seriously doubt anyone will do these. if they do it will likely be on P2WSH for the 'deploy' but at least any transfer or sale on atomic swap won't impact the utxo set.

plus the mints don't need to be multisig, just the deploy or fairminter trx

well thats good, a bit less abusive 😛

just fkn around anyway. more concerned why the description would get mangled.

3 random spaces and actual chars converted into something completely different

Curious tho why we have the same data stored in the fairmints table and issuances tables.... kinda seems like we're unnecessarily storing data twice in CP... @teysol ... any insight into why you didn't just store the data in the fairmints table and are also writing the same data to issuances table?

okay prod api.counterparty.io is back up! 🥳

back to: no healthy upstream