Etching (deploying a token) where you pick your own name requires a commit and a reveal. In this case, you need p2tr.
Etching (deploying a token) where you add an image for your ticker requires inscribing an ordinal, meaning you need p2tr.
Etching (deploying a token) where you don’t do either of those things, may not require p2tr (strictly op_return). In this case, you can pick a symbol but no image, and you are assigned a random reserved name.
Minting tokens does not require p2tr. Just op_return.
Transferring tokens does not require p2tr. Just op_return.
This is my current understanding. Digging a bit deeper now to see what else I can find.
Both mint and transfer need to put your token to the first op return output, then you can point to a specific address that you want to send as the non-op-return output.
Yeah, mint and transfer, in either case, just needs op_return. All edicts (transfer instructions) show up in the op_return. All minting instructions show up in the op_return. No additional data, scripts, or signatures are needed anywhere else.
Go search the Bitcoin mempool right now and you’ll see 10-20% of all runes transactions right now are valid runes transactions that are not p2tr.
No you don’t. Not for mint or transfer. Any old op_return BTC transaction is fine. tECDSA can be used for any Bitcoin transaction type other than p2tr.
Could you demonstrate that the rune token is etched and can be minted using ord ?
I can’t find any reference to the commit/reveal transactions used to reserve the name.
There are a set of reserved names (27 characters and 28 characters). When you etch without commit/reveal, the protocol takes your block number and your etching number (the 1-based index of your etch in a block) and it converts those to base26 → letters and that becomes the automatically assigned ticker.
I do some some works left, but I’m facing trouble with them.
i: To be a valid runestone, runestone’s name must be below than a runestone, that is calculated with the help of block number. I couldn’t find a way to get the blocknumber.
ii. I was also trying to add in the CKBTC payment feature, I had created a local CkBTC test setup, but it didn’t worked out. ( If someone would help me understanding the CkBTC thing, I can complete this too)
I’ll be sharing a video tutorial out soon.
And I’ll also be deploying the app on mainnet with Bitcoin’s Testnet blockchain.
If you receive a BTC payment, you can get the block height, i.e. block number via the the bitcoin_get_utxos API. But I’d say it’s also fine to submit the current block height from the frontend or use an HTTPS outcall to some Bitcoin blockexplorer etc.
There’s no need to setup the entire ckBTC system. ckBTC is just an ICRC-1 token. You don’t need to setup a minter and KYT canister. You can use the same setup as in the ckBTC PoS sample dapp:
Ah, you’re correct, that’d be very useful and would require the minter. However, it would be ok if this flow would only be possible on an ICP mainnet deployment.