Status: Complete
Project Type: Cooperative/Contest - Multiple workers can submit work and the bounty is shared
Time Commitment: Days
Experience Level: Intermediate
Size: Up to USD 10’000 in ICP (at time of distribution) - Up to 5k per worker.
Deadline: Extended (TBD)
Overview
Runes are a new protocol to create and transfer fungible tokens on Bitcoin. The protocol was designed by Caset Rodamor, the inventor of Ordinals, to be more efficient than prior popular meta protocols like BRC-20. Runes protocol messages are stored in OP_RETURN transaction outputs and thus don’t lead to the bloat of the UTXO set, i.e. of the Bitcoin state.
Runes come into existence by being etched. Etching creates a rune and sets its properties. Once set, these properties are immutable, even to its etcher.
In this bounty, your task is to create an etching or launchpad service inside a canister.
Acceptance Criteria
Frontend and backend implemented on ICP
Option to connect/pay with Bitcoin Wallet or with ckBTC
Create a wrapped version of Runes and use liquidity bootstrapping, i.e. bonding curve to sell the pre-mine allocation and establish a price
How to participate?
Post your submission here in the thread. Please introduce yourself early on if you plan to participate.
Please be aware that Terms and Conditions of the DFINITY Developer Grants Program apply.
Conversion of name into base26 number.
I had problem understanding how it works. As the docs said: A is 0, B is 1, … and BA is 52. I wasn’t able to figure out how BA would be 52. It took 2 days to understand this😅
Test using the CKBTC as payment option. I wasn’t able to build n deploy CKBTC minter locally.
Here is my flow, that I’m thinking to achieve.
Hello there, I want to note that the runes now only support taproot addresses currently, and it needs to be signed with schnnor signature. But now the ICP only supports t-ecdsa signature.(For the wpkh address)
For the runes, we need a commit transaction and reveal transaction, so we need a reveal script which needs to insert tapscript to the reveal transaction.
So we need a lot of work to do.
You can also immediately transfer any premined tokens to a PWSH address.
Do you mean we can use Schnnor key in the canister to sign the segwit v1 transaction with a p2wsh address and send the transaction to bitcoin network?(If we send the transaction from ICP to bitcoin network, can we track it in the mempool or blocksteam?)
This needs to be verified by someone looking into the spec in detail, but I assume you can essentially allocate the runes to a normal PSWH output already with the reveal transactions. If that’s not possible you’d need one additional transaction.
Yes, sure. These are all regular Bitcoin transactions that get submitted to the Bitcoin network.
hello @cymqqqq , didn’t knew there were such specifications for rune, could you share the link/resources to learn more about these?
in the rune’s documentation, I didn’t see any such things being mentioned.
To prevent front running an etching that has been broadcast but not mined, if a non-reserved rune name is being etched, the etching transaction must contain a valid commitment to the name being etched.
A commitment consists of a data push of the rune name, encoded as a little-endian integer with trailing zero bytes elided, present in an input witness tapscript where the output being spent has at least six confirmations.
If a valid commitment is not present, the etching is ignored.
To fulfill this bounty, we expect a demo that shows the runes showing up in the ord indexer.
You can not find it in the rune’s documentation, because it doesn’t exist in the doc, and there are a lot of details that you need to read the source code and I can not post here(very complicated). I have read all of the rune source code since last year, so I know a lot of fundamentals about how to etch runes, how to mint runes, how to build commit transactions, how to build reveal transactions, and so on. So if you want to know more things about the runes, you can go to the rune source code.
Personally, I think it’s difficult to implement the demo now because the runes source code is still under development. And if we want to do this, we need to write a lot of infra code to build Bitcoin transactions.
I have read the bitcoin_wallet module in this repo, so there is a commit transaction and a reveal transaction signed by schnnor key that is used to build an inscription transaction, and a p2pkh transaction signed by t-ecdsa key.
For the rune protocol, we need to bind each rune with a native utxo(Not an address), it is based on inscription but different from inscription. First, you need an outpoint with the satoshi on your address, then you inscribe an inscription. Next step, you etch a rune based on your inscription id. then you mint a rune with one of your outpoints. Like this:
Now I’m building a native bitcoin asset protocol based ICP network, and it can use ICP bitcoin light node to update utxo set, and I will opensource it later, I also want this bounty but maybe it’s not the right time for me.
I advise the Dfinity Team can develop an interface that can fetch raw transactions from bitcoin network by txid(transaction hash), it will help us do a lot of things.
You can fetch raw transactions (+ merkle proofs) from an untrusted source and verify that they are indeed part of the Bitcoin blockchain. If you’re interested in building such a utility canister, please apply for a grant. But this discussion is not necessary for this bounty/thread.
