Add ability to send Stamps

[markmhendrickson]

Similar to how users can send Ordinal inscriptions

[DeeList]

Along with numerous requests for BRC-20 token transfers, now seeing user requests for SRC-20 Stamp transfers.

https://discord.com/channels/621759717756370964/745197302255321108/1111040208725606481

I do not believe this is possible - yet. See 'TRANSFER' https://github.com/hydren-crypto/stampchain/blob/main/docs/src20.md

[markmhendrickson]

@DeeList please create separate issues for A) sending SRC-20 and B) showing SRC-20 balances 🙏

[DeeList]

Send/Transfer SRC-20 tokens - https://github.com/hirosystems/wallet/issues/3750 Show SRC-20 token balance - https://github.com/hirosystems/wallet/issues/3751

On Thu, May 25, 2023 at 12:51 PM Mark Hendrickson @.***> wrote:

@DeeList https://github.com/DeeList please create separate issues for A) sending SRC-20 and B) showing SRC-20 balances 🙏

— Reply to this email directly, view it on GitHub https://github.com/hirosystems/wallet/issues/3714#issuecomment-1563287856, or unsubscribe https://github.com/notifications/unsubscribe-auth/A7WMV56R32XRPYB5KDJWT7TXH6L2JANCNFSM6AAAAAAYEDYUEM . You are receiving this because you were mentioned.Message ID: @.***>

[markmhendrickson]

References:

https://github.com/tokenly/counterparty-spec/blob/master/spec/04-send.md https://github.com/tokenly/counterparty-spec/tree/master/examples

[kyranjamie]

According to @mikeinspace, Stamps should only be sent and received to legacy and native segwit address types. Our UX should reflect this.

[Iheff]

This is epically cool, but why not just support ALL counterparty tokens at this stage? could easily loop in the historical RAREPEPEs for example :D

[markmhendrickson]

@Iheff intriguing idea! Got any reference material on how we could make this work? For both sending and displaying them in the wallet

[Iheff]

OK, so for rarepepes as a basic example there is a feed that won't ever change (Rarepepes are locked) its a simple format and can be found rarepepewallet.com/feed

for most other XCP assets they use a general description that points to json file with an image_large key in it, that is generally the main media of an XCP assets.

Stamps of course are where we base64 into the description and prefix with STAMP, and my own new format ASS, is an "ASS:" prefix followed by an arweave hash, for stamps you can uses use some logic to pull the mimetype, for an ASS you have to open a request and await response headers, you can dump the request at that point you dont need to call and receive the whole file to know its type - this should be easily parasable by whatever your using to parse stamps.

Happy to discuss any point in further detail :D

[Iheff]

Sends/ CP actions via hiro im trying to figure out myself but would hope is possible via a CP API request (to get beack a raw TX) then seding that via hiro - I was expecting to be able to just do a 'signRawTX' type function via the hiro apis with the rawTx i can get easily from CP - but im only seeing PBSTs and FullySigned, the args in fully signed aren't what I want to use So am hoping I can use PBST somehow - hiro is new to me and i dont know if this fits that usecase.

[markmhendrickson]

We could add another API for signRawTX or perhaps modify the fully signed transaction API to accommodate it? Curious if @fbwoolf has a sense of which could be the better path since she built the fully signed transaction API

[fbwoolf]

We could add another API for signRawTX or perhaps modify the fully signed transaction API to accommodate it? Curious if @fbwoolf has a sense of which could be the better path since she built the fully signed transaction API

Prob should just be a new api bc the UI would be different? Would we decode it and show anything to the user?

[Iheff]

We could add another API for signRawTX or perhaps modify the fully signed transaction API to accommodate it? Curious if @fbwoolf has a sense of which could be the better path since she built the fully signed transaction API

This would be godly, and allow for send etc

[Iheff]

right now i can do everything for minting, but sign the darn TX for now ive reverted to bouncing through freewallet as it has little resistance for the sign and broadcast. As soon as that is available in Hiro, ill have full mints for Hiro wallet in both ASS and STAMP flavours and the Sends people are so keen to get their hands on.

[kyranjamie]

Would we decode it and show anything to the user?

We would need to, otherwise the user wouldn't be able to verify what it does.

[Iheff]

if you wanted to offload some of that work there is a CP API endpoint thet decodes counterparty iinformation https://github.com/CounterpartyXCP/Documentation/blob/master/Developers/API.md

"get_tx_info" you can send this a raw tx to get back a data structue and "UNPACK" to further read the counterparty specific information in that.

You could of course hose your own CP server if your data sources need to be kept internal - and you can of course just do the work to decode and unpack yourselves although its of course more involved I beleive JPJA has some info on it: https://jpja.github.io/Electrum-Counterparty/decode_tx.html

Hope this helps give a thread ot tug on.

[markmhendrickson]

I've created a relevant issue for adding a signRawTX endpoint here: https://github.com/hirosystems/wallet/issues/3867

[markmhendrickson]

CIP-0009 for sending stamps: https://github.com/CounterpartyXCP/cips/blob/master/cip-0009.md