https://jpja.github.io/Electrum-Counterparty/index.html?address=1PSHqxC67RVdedDgK8YCogtwNnBdrLWBHU

Here's a web interface for generating op_return data which can be sent from Electrum (or other wallet).

Balances are from xchain api, otherwise no reliance on APIs.

Also a sanity checker for encoded message.  Can be a good safety addition for wallets that do use APIs to build the tx msg.

This is the first alpha release.  Expect bugs.  Only works with enhanced send so far.

a740af0a4b6854ec2d82e951ae1481f38d3ec9ffa45447191a0fac5f8a7a9193

This is sooooo helpfull!!!

Very cool, I was looking into adding the ‘current’ issuer assets by address to xcp.dev but there is no way to avoid multiple queries. It won’t scale for addresses with many assets

Hello guys im a litle Lost in Bitcoin i am playing with just json apis but i would LOVE to get deeper, can anyone point me to some resources?

I LOVE all you have build

Thanks! What is your goal? To understand Counterparty well you should understand Bitcoin basics first

GM! bitSTART has been updated with support for ORD and STAMP descriptions.

Save sats (and get creative 🐸) with direct visibility to all of your asset’s media history (instead of only the last) 🤓

https://forums.counterparty.io/t/stamp-file-storage/6569/2

Here's an outline for saving file BLOBs in asset descriptions and broadcasts. The blob is saved inside the btc tx but only the hash goes to the counterparty DB.

Kinda competing to CIP26 and 27 but should be very good for STAMPs nevertheless.

If some support, I will write a formal CIP28.

Yours is much more elegant than CIP27, but I still don’t think this should be done.

Messages are the core architecture for everything else in the protocol. I wouldn’t mess with it just for the sake of avoiding “duplicate data”, EVERYTHING in Counterparty is duplicated in the messages table!

I strongly believe the next release / CIP implemented should be the issuance message id fix (https://github.com/CounterpartyXCP/cips/issues/66).

Data heavy (very long) asset descriptions should be avoided, but is up to the users to do this responsibly.

The most efficient way to store data in Counterparty is like OLGA did 7+ years ago, use a broadcast. No need to change the protocol.

All of these proposed protocol changes can be bypassed by anyone that wishes just by making some unique modification to their data.

Agree on unlimited broadcast data. Not a problem as this is only saved once AND user needs to pay btc fee for it anyway.

With asset description it is worse than just being saved in two tables. Every time you make a new issuance (add supply, lock, transfer ownership ) the description is saved over again in a new row.

For issuance, such as new supply and transfer, the description must again be included in the btc tx, so it's the user's problem.

But for LOCK only the keyword lock is included in the btc tx while the entire description is duplicated. With a 5 cent btc fee you might add 5kb to the DB.

A lot worse is SWEEP. For a 5 cent btc fee + 0.5 XCP fee you can move an unlimited amount of assets. If you have 1000 5kb stamps, you will add 5MB in one sweep.

No wait, this goes to msg table too, so make it 10 MB.

I strongly believe something must be done. Either limit asset description length or make the xcp sweep fee proportional to amount of assets and/or description length.

Yes hard limiting the asset description can make sense.

But the real problem is in the design of the system, for some reason Counterparty data is stored in a denormalized way (unnecessary duplication). I brought up this multiple times in the “official” dev chat with no thoughtful follow up…

Stamps (as in done in the asset description) uncovered an obvious vulnerability of the protocol. There is no way around it, unless very deep changes are done which will take a long time to do “correctly” (in quotes because we will need to rethink many assumptions (specially reset) to be able to make the best solution).

The only pragmatic move forward is to limit the description length, and all people interested in continuing doing stamp-style art will have to move them to a broadcast. Basically mimicking OLGA.

I’m on board with this simple update, v9.60.2 JUST limits the description length. Then v9.60.3 (or v9.61) SHOULD be about the issuance id fix, which can include a better issuance design.

But to solve the root problem, its such a fundamental change that it will have to be v10.

How would be posible to make an stamp using a broadcast? Can you point me to some info about It?

It COULD be done by doing an issuance and broadcast in the same block, but the naive (simpler) way would be to first do the broadcast, and then point to this broadcast from the issuance description (like done with ORD, or even Imgur). It could use the tx_index for an “inscription like” serial number.

Basically there can be many ways to do it, but I believe the most important “principle” is to make them from the same address.

The broadcast would have the same “STAMP:…” text. But I would just do it like OLGA and use the data url standard

Makes perfect sense what you write.

Assets descriptions initially had a very short limit. Maybe that's why they didn't care about normalizing the tables.

Now the question is where to put the length limit.

We could make some statistics for the description length historically (pre stamps). But based on usefulness, 80 would be the minimum I would say. Then maximum times 2? 5? 10? More than 800 chars seems excessive…