I am finding that the description of an asset that has subassets is also not displaying correctly

I am finding in the latest freewallet release the 'total supply' value is not showing correctly on the main asset when you have subassets .. is it just me or is anyone else noticing this?

and the issuance lock icon is showing as unlocked on assets that are known to be locked

Pleas create an issue for these complaints n I’ll look into it

https://github.com/jdogresorg/freewallet-desktop/issues

Thanks for the contribution

what is the best API call you look for a Burn/Destroy Tx completed? I see that xchain can so a look up via Address. Is there anything that can do this via a txhash? Trying to check that a user has send a Destroy tx for an amount of tokens

you can just request the transaction data directly if you have the tx hash.... https://xchain.io/api/tx/a742690808cf846dee2fd736d2abdc7a0bb2aa663d47db53c299039d7f03a560 ... there is an example destruction tx.. if the status is "valid" and you have a tx_index value... then the transaction was successfully parsed by Counterparty and is confirmed

well fck that is easier that what I was doing 🙂

thanks

OK we want to move forward with this, I just DM, should I send site details via DM

fck sorry I will just email the details..

yeah... email me the details at j-dog@j-dog.net including the tx hash of the listing fee payment... once I have all the info, I will get started adding the project to the site... should be able to do it same day if we do it this week 🙂

thanks will get on it, payment will come from DarkFarms

I have an odd questions, a user have said that they destroyed tokens showed my a screenshot showing this and a link to a tx hash but when I check I do not see the tx nor the data on the link to the screen shot. I would have thought that all data would be consitent so not sure if there could be any chance data is not presented in synch and this is a propagantion issue?

@robotlovecoffee maybe linked to this?

FYI.... I'm in the process of updating the xchain.io servers with some patches for counterparty-lib..... the servers may lag for a while... use host1.xchain.io as it is up to date

thanks this solved my issue. appreiete the help

Code audit of emblem vault.
https://www.certik.com/projects/emblem

I know it's not directly Counterparty related but posting it since it's a major risk for the wider ecosystem.

If i understand the audit correctly, EV = trusting a few keyholders both being honest and competent. If i had a $100,000 card with EV i'd spend some time investigating this further.

Does sweeping an address close/clear out dispensers on that address?

Or do the cards in the disp stay put and everything else go?

99% sure any assets in escrow either in dispensers or in buy/sell orders on the dex remain in place and tied to the originating address

imma try it and let you know lol

actually i will use electrum to grab btc out of dispenser wallets. that shouldnt effect open dispensers right?

As in you're sending BTC out of your dispenser wallet to another? No, it won't.

yh say i have a couple of dispensers with any number of assets sat in escrow and 6.15btc sat there from sales i wana scoop the btc using electrum

Sweep only moved balances and does not cancel orders or close dispensers….. and yes moving btc from address is fine…. Won’t effect anything on cp

Hello everyone! Glad to be here and looking forward to continue learning about Counterparty

Does anyone else have to randomly restart their Counterparty node to connect? I seemingly randomly get Error: Couldn't connect to server when trying to call the API to my node. Won't fix unless restart. No errors in docker logs.

I wanted to see if I was correct is assuming that if this dispenser sells out (32 left) then this CIP would be worked on?

You are correct.... as soon as the dispenser sells out, this feature will be worked on.... we already have the code working for the past 2 months on Dogeparty and it seems pretty solid, so should be able to implement this pretty quickly (within a few weeks) once the development funds are fully collected to cover Javier's dev time 🙂

strange.... I get instances where CP lags on parsing blocks and so get_running_info will report that CP is lagging behind a bit... but cant say I've encountered an error with CP not responding to API requests.... you sure its not related to a firewall preventing connection at times or something similar? You trying to connect from a remote IP or trying to connect on the machine to localhost?

The node is up on DigitalOcean.

It's not a firewall thing as it begins working again with a Counterparty restart. It's so strange.

that is very strange... how often are you pinging the API? every 60 seconds or so? you able to detect when it stops communicating pretty quickly?

heard of some ppl in the past having issues with digital ocean and some of the droplets going idle and shutting down automatically... tho that was something I heard from John over a year ago

No. It's a bit all over the place. I can restart a node and have it stand for a good 36~48 hours or so. Sometimes I restart and it stops responding in ~12 hours. I wish there was an error I could give you. 😕 I'll keep an eye out for patterns.

try staying logged into droplet via an ssh session during the outage.... being able to see if your connection to the droplet/instance drops entirely would help determine if the instance is shutting down, or port is getting closed

Good idea. Thanks.

not cp related but wanted to understand thumbnail images not showing up in Freewallet and on Xchain when tokens minted on easyasset, is this just a cache timing issue, seems if asset image put on imgr shows up much faster. Just let me know and I can delete and post elsewhere.

for imgur/ links I parse them in every hour and generate an icon if one does not exist.... for assets pointed at .JSON files, I parse those in once every 24 hours and update the thumbnail.... the icon will show up immediately on the asset page, but for the icon to show up elsewhere on xchain.io and in freewallet, require about 24 hours

I thought that was the case but I'm not seeing this on an asset, could it be that the thumb was not 48x48 png

Hello! Can anyone point me in the right direction relating to how the multisig 1 of 3 data outputs affect the utxo set? I know that op_return, which doesn’t, is used when the data is small. I want to learn their differences, like what is the threshold of the data. I believe this is critical part of how Counterparty works and I just want to learn

Hi, what do you want to know? When is the multisig used?

Hello Javier. Yes that is one part. Also if this is a 1 of 3 multisig, is it spendable or it just stays as unused utxo?

when you say multisig, do you mean p2sh?

can you show me the tx you are seeing?

Sure. I am comparing this:

- https://testnet.xchain.io/tx/28150
- https://mempool.space/testnet/tx/f5ea5146619823c8128d10e471d5caa4ac6ca9ec285b598bd51909e9b535063a

With this:

- https://testnet.xchain.io/tx/28691
- https://mempool.space/testnet/tx/90db66f4283da05c6dd3e9312a4657b9e73adbe93c8e9dcc41a516d3b70d5a97

Ahh that’s bare multisig

Those are technically spendable though I’m not sure what wallet supports them

Thanks for bringing this up..... we SHOULD be using p2sh instead of multisig like this.... Javier is looking into it, we will prolly change the default to p2sh with the next release.... he is also looking into reducing the dust amount from 7800 sats to 5430 like we do in mpma sends data encoding (p2sh)

So to be clear, there is a possibility to do it in a way that the utxos are spendable?

the thing is, dust used on p2sh outputs are actually the fee to pay for the tx, so they shouldn't be utxos

Ok thanks now I have a better idea of how these work. But my remaining question is if these dust outputs are prune-able like op_return? I don’t think they are…

Not pruneable.
The dust can be redeemed. There used to be a website that would generate the tx for you, which you could sign from electrum if i remember correctly. Been down for a few years unfortunately.

https://jpjanssen.com/how-to-reverse-engineer-counterparty-txs/
Near the end is multisig encoding explained.

Got it, I’ll take a look. Thank you everyone!

I guess a “workaround” is to NOT do these outputs as dust limits. Divide the change between these and then we are “forcing” ourselves to use those utxos.

Not ideal because the next transaction will be bigger because of the multiple inputs, but I guess it justifies them being used and thus not affecting the utxo database long term

If this makes sense, lol let me know if this is wrong

@jdogresorg sent a dm about fake commons ser

This is very interesting .. it would be nice to have a website that could create the transaction needed to redeem and consolidate one's multisig 'dust' every now and again, what a shame the tool is no longer online

sounds like a good project to take on!

yeah .. I am working on getting my self a federated node syncd up and can then look to play around with it