https://twitter.com/stamps_src20/status/1674659350093393920?s=46&t=csXvDn2SopzSbnOM0eLdDQ

Are only src20 moving off Counterparty or all stamps?

Only SRC-20 for now. SRC-20 were deemed to be spam. In order to avoid a potential messy protocol fork, SRC-20 (DEPLOY/MINT/TRANSFER) no longer use Counterparty at all. The commands are written to the blockchain without Counterparty headers.

"Art" Stamps will remain on Counterparty as there was reassurance that they are not viewed as spam.

Got it

I wish it had happened sooner and may have avoided a lot of acrimony. But now that it has happened, it really is for the best. Without the Counterparty headers (I'm just calling them that for lack of a better word) SRC-20 commands are now smaller in file-size. Better for Stamps. Better for Counterparty.

If anyone is interested in seeing how it works, the reference client wallet is available here: https://www.thestampwallet.com/

We are also working with Hiro wallet to integrate SRC-20.

https://github.com/hydren-crypto/stampchain/blob/main/docs/src20.md

The spec is nice and detailed

You could make the txs even smaller if you remove the key burn and do a 1 of 2 multisig

I'm not involved at the protocol level, that's way above my paygrade.

thanks, based on your feedback previously we were thinking about only doing the keyburn on the last sigop of the last multisig when there are more than 1, and then using the full ~90 bytes as you suggested for the prior multisigs for data- this will be especially beneficial for putting binary images directly into this method which will cut the transaction size WAAY down from the prior base64 (half the size using binary, and 1/3 more data per multisig is a huge cost difference). The keyburn is mostly just there for validation on indexing, but probably not needed anyway. kind of in a rush when we pushed it out not knowing all the potential pitfalls.

the super fun part was i completely deconstructed counterparty-lib for indexing these lol. would have been way easier to start from scratch but it gave me some very good insight into the nitty gritty details on CP and the block reorg handling which was a learning curve. should be simple to add in the zmq for the mempool stuff that's been pending there, among a few other tweaks. Also made some custom changes to the API calls when pulling multiple asset details which speed things up from 3 hour queries to just a few minutes. Once all this is done i'll see if i can circle back for some PR's. Definitely not afraid of a fork at this point lolz.

Also looking at some options to have the src tokens live in a utxo in the wallet so we could truly do psbt's in one transaction now that we have a fully functional stamp wallet. been quite the journey, glad we were able to get in this deep! I appreciate the support.

tldr version. we are now prepared to move all bitcoin stamps (images) off of counterparty if it comes to the point of xcp fee requirements, and to ease the tensions we caused. otherwise I believe everyone in stamps is a big fan of the current CP functionality and partnership between the ecosystems so we would hope to maintain the ties and leverage the partnership / dev resources.

Yeah makes sense to use keyburn for id purposes

Also the arc4 encoding probly isn’t necessary either, it was just something added initially to obfuscate txs with message data in them just in case

p2sh encoding has never used it

Yeah, didn’t seem to add to the message size so it was deemed cool to stick with the obfuscation and a nod to the CP way. In hindsight I probably wouldn’t do it. Things were just rushed to get running again.

Interested to see what your plan is for storing tokens in utxos

That was the impetus behind my idea for ordinal envelopes, to use the sat id methodology as addresses

Not really storing. Just the wallet that holds the utxo controls the ownership as a potential option. Chasing down the options and Definitely open to ideas since we have a pretty clean slate.

I like the idea of tying bitcoin indexers together, would be an interesting dynamic to be able to peg into and out of the ordinals ecosystem

yeah that would be cool. we have two independently coded indexers for these now (one on node and one in python) for validation. And one is indexing all btc transactions at the moment just to validate the stamp numbering order between all the different transaction sources. the db scale is pretty ridiculous even from block 796000 - just learned about table partitioning lol. I'm sure this will get pruned as things are validated.

We even have taproot support on these so i'm not even sure all the possiblities yet. I do have an ord node up as well which will be fun to see what we can do.

Where can I learn more about this idea?

https://forums.counterparty.io/t/ordinal-envelopes/6504

Ord doesn’t handle reorgs well which is the biggest hold up I see currently

I think ordinals is unlikely to ever support reorgs.

Perhaps attaching the xcp item to a sat in the same way way ordinals does, replacing ord with xcp and having two ops, “bind” and “unbind” where you either attach an asset to a sat or detach it and attach it to an address?

The end result of being able to move the asset atomically within a psbt is still achieved.

It doesn’t have the benefit of “just working” with existing infrastructure

There’s nothing saying those two ops can’t just be added inside an ordinal like an src20? But in the json, instead of src20 call it xcp with ops bind and unbind?

Then it works like their src20 indexer and gives you a balance of 1 <asset name> and upon unbind removes the balance

That would fix the reorg issue, but indexers would need xcp state to determine if the balance was actually added to that sat

do you mean the envelope protocol specifier?

I think you could create an ordinal and call the xcp protocol op to move the asset in one transaction?

So you would do a create_send with the destinationaddress being “envelope” which would attach the asset to output[0] of that tx. Then your ordinal segwit data would be something like:

OP_FALSE
OP_IF
OP_PUSH "ord"
OP_PUSH 1
OP_PUSH "text/plain;charset=utf-8"
OP_PUSH 0
OP_PUSH “{p:xcp, op:”bind”, a:”assetName”, q:1}”
OP_ENDIF

Im still pretty new to both of these protocols so there may be some nuance Im missing in why this wouldn’t work.

But if we treated the issuance of the asset on ordinals more like an src20 issuance, ordinals wouldn’t have any reorg issues.

Your just adding to the balance or subtracting from it

If the create_send is valid

Ordinals don’t have reorg issues, only the software ord does, but I think you make an interesting point that you could simply use utxos as envelopes rather than sat id

been thinking a little more about this and it could be a great step towards deciding if counterparty should integrate ordinal theory, you could transfer to a utxo with a “utxo” type address then once that utxo is spent the asset transfers to an output address of the spend tx

wouldn’t need to add anything new to the stack, would just be a new message type

and you could do psbts

whats funny is you could keep them in an ordinals wallet, and then you could just send that ordinal to a counterparty address

I just reread my post and all src20 should be replaced with brc20. You guys knew that though.

Highly beneficial

https://github.com/CounterpartyXCP/cips/pull/99#issuecomment-1635833836
Taproot address CIP draft.

I've pointed out some revisions I think are necessary before accepting it as an official CIP.

What do you guys think? If most of you think it's good enough as is, i will add it now.

I weighed in with my opinion on how CP dev has become increasingly hostile, and is driving ppl away from wanting to work on, propose improvements for, or code on CP.

Just my personal opinion, others might not share it…. But as a longtime CP dev, I am highly discouraged with the state of things.

This is the primary driving factor behind continuing with BTNS development… to allow devs to continue experimenting with token functionality on Bitcoin… without having to spend months/years on discussions before code is written into CP.

IMO Coders want to code and experiment, which seems increasingly difficult on CP.

I think any movement forward is good and we can always upgrade later when needed?

I didn't check back in on this until now. Been traveling to Malta.

The CIP isvery good, please don't misunderstand. I will reread cip01 but my point was that some minor clarifications are needed (how popular is taproot really .. show me a number) and the memo restriction i believe is wrong (need to check this first). Ofc a broader scope (include also bc1q msig) is not strictly necessary, but i will make an almost identical new cip for it if not included in this cip.

I know it is frustrating. Devon gave me a hard time back in the day too to get cips submitted. But in the end the result was better. Changing protocol code is serious stuff. Requires a lot of consideration.

The cip is now officially accepted.

The forum link is dead tho. Ok @jdogresorg if i open a new github discussion and update the cip to link to it instead?

Maybe just update link to point to previous conversations…. https://forums.counterparty.io/t/taproot-encoding/6481

That post is about taproot ENCODING. I couldn't find anything about the taproot ADDRESS format in the forum.

Got ya👍🏻

https://github.com/CounterpartyXCP/cips/discussions/100

LFG!!

I opened a discussion for cip 30.
I suggest one month for discussions before polling the community.
If you have objections or concerns, please post it there for documentation.

https://github.com/CounterpartyXCP/cips/discussions/101

Been shopping around for some feedback relating to updating the Counterparty.io website so it shows the most recent up to date information and fixing broken links. Feel free to reply here or on the Counterparty Forums:

https://github.com/CounterpartyXCP/cips/discussions/102