Questions about Chain Key Tokens(like ckbtc)

Developers
1

Hi everyone && Difinity teams, I have read all about the code of ckbtc minter, so I have some questions about ck-token here:

  1. Is chain-key(t-ECDSA) only an attribute of the ck-token?
  2. Are each transaction(includes mint, transfer, and approve, etc) should perform chain-key signature?
  3. What else can we do for the chain-key signature in ck-token?
1 Like
2

Hi!
Let me try to answer your questions.

Iā€™m not sure what you mean by that. Did you read the chain-key tokens page? If the information there does not answer your question, feel free to ask again!

The transactions that have an effect on the blockchain where the underlying asset lives require threshold-ECDSA signatures.
In the case of ckBTC, only burning ckBTC requires threshold-ECDSA signatures because the underlying bitcoins must be transferred (on the Bitcoin blockchain).

Threshold ECDSA makes it possible to get ECDSA signatures in a secure and decentralized manner. In theory, you can build any kind of dApp that uses/requires ECDSA signatures using this functionality.
As an example, the upcoming Ethereum integration also makes use of it to sign Ethereum transactions.

1 Like
3

Hi THLO, thx for your answer, and:
for question 1, yes, I have read the chain-key tokens page, what I mean is that in ckbtc minter code, there is ecdsa public key in CkBTCRequestState datastructure, so personally, I think maybe itā€™s an attribute of ckbtc.
for question 2,

I have a question, for your word, why does mint ckBTC not need t-ECDSA? Because when you mint a ckBTC, we need to transfer a BTC, then you can mint ckBTC,

4

AFAIU it is not needed because transferring something to the ckBTC minter does not require a transaction initiated by the IC. It only has to check if the transaction arrived properly (unless itā€™s transferred from some other account thatā€™s backed by some canister on the IC).

1 Like
5

So you mean the minter just checks if the transaction arrived properly, and the burner process needs to perform a transaction, do I understand right?

6

yes, that is correct

1 Like
7

another question is, if we integrate with the eth network, and mint or burn a ckETH. Can we just do the same as the ckBTC?

8

In a very similar way, yes.

1 Like
9

Hi there, I have been considering a new question these days:
When we transfer a btc token to a canister address on btc network and mint a ckbtc on IC, there is a t-ecdsa signed transaction sent to btc network.
So if I want to build a new native chain key token on IC, should I write a specific canister(or ledger like icrc1) for recording transactions(mint, transfer, and burn transaction) that are signed by t-ecdsa algorithm? Then we can query the t-ecdsa transaction hash in that canister.

1 Like
10

I think it would be a good practice to copy the ckBTC model: You can use a standard (e.g. ICRC-1) ledger canister to manage balances and carry out transfers. An additional canister is used to mint and burn tokens and interact with the underlying asset. If ECDSA signatures are required to transfer the underlying asset, you would use the threshold ECDSA API here.

Of course, you may choose to pack everything into a single canister, or use more than two canistersā€¦

2 Likes
11

Hi team, Iā€™m here again, I have a question about the time of sending transaction to the bitcoin testnet, I just sent a transaction of ckbtc and returned a transaction id, but it can not be found in the mempool testnet. So it will take a long time to send a transaction from IC network?(I have waited about 1 hour)

12

What do you mean by you ā€œsent a transaction of ckbtcā€?
Are you using the ckBTC codebase, connected to the Bitcoin testnet, and you called retrieve_btc (or retrieve_btc_with_approval) to transfer (test) bitcoins out?

Are you running your code locally or on mainnet? In either case, once the transaction is sent, it usually appears in the mempool after a few seconds.

13

Sorry, not ckbtc, I run the dfinity/examples/basic_bitcoin canister, then call the send transaction interface, and it returns a txid that is not found in the mempool.
about the time for sending transaction to bitcoin network Ā· Issue #845 Ā· dfinity/examples Ā· GitHub(I posted on this issue)

14

:slight_smile: Maybe the code is out of date, I will check it later.:slight_smile:

15

Sounds good. Let me know if the issue persists!

16

Hello again, I visited the ckbtc transaction in the dashboard.internetcomputer website, so that is: I filtered the transaction from ICP=>BTC(transfer ckbtc to btc), then I can see the following data:

image
image378Ɨ1336 11 KB

Then I have a new question: how do we track the transaction submitted to the bitcoin network, there is no transaction hash here(we can track the txid in the mempool).

17

New question: I read the The Internet Computer Interface Specification | Internet Computer again, here are the words:
If the transaction passes these tests, the transaction is forwarded to the specified Bitcoin network. Note that the function does not provide any guarantees that the transaction will make it into the mempool or that the transaction will ever appear in a block.
So, the bitcoin_send_transaction returns a txid, how do we check it(Or track its transaction on btc network) ?

18

So, the ckbtc minter first submits a transaction by a bitcoin canister API, then the submitted transaction is sent to the bitcoin adapter, then the adapter sends it to the bitcoin network, right?
Now maybe I know why I can not find the txid in the mempool, maybe the transaction was not sent to the bitcoin adapter.

19

Each successful BTC->ckBTC mint transaction contains a memo. For example, this transaction has a memo field that reads:

8200835820cdc257ab5d4ce0e240d1dc417d79c68130c1d8b56b91ce448eb093303b246ca0001907d0

This is a bytes (in hex) encoded using the CBOR encoding. Using a CBOR decoder it shows following record:

82                                      # array(2)
   00                                   # unsigned(0)
   83                                   # array(3)
      58 20                             # bytes(32)
         CDC257AB5D4CE0E240D1DC417D79C68130C1D8B56B91CE448EB093303B246CA0 # "\xCD\xC2W\xAB]L\xE0\xE2@\xD1\xDCA}yʁ0\xC1Ųµk\x91\xCED\x8E\xB0\x930;$l\xA0"
      00                                # unsigned(0)
      19 07D0                           # unsigned(2000)

The first number unsigned(0) means it is a Convert message (according to the schema defined in Rust code):

    Convert {
        #[cbor(n(0), with = "minicbor::bytes")]
        /// The transaction ID of the accepted UTXO.
        txid: Option<&'a [u8]>,
        #[n(1)]
        /// UTXO's output index within the BTC transaction.
        vout: Option<u32>,
        #[n(2)]
        /// The KYT check fee.
        kyt_fee: Option<u64>,
    },

If we read further the decoded CBOR data, we can see the following correspondence:

txid = bytes32("0xCDC257AB5D4CE0E240D1DC417D79C68130C1D8B56B91CE448EB093303B246CA0")
vout = unsigned(0)
kyt_fee = unsigned(2000)

BTC likes to have its txid stored in reversed order. so the actual txid to search in a block explore would be A06C243B3093B08E44CE916BB5D8C13081C6797D41DCD140E2E04C5DAB57C2CD. It shows that there is an output of 0.00242422 BTC. If we then subtract the KYT fee of 2000 satoshi from it, the result would be the same as the amount of ckBTC minted.

I know that this is a convoluted process of finding out the corresponding BTC transaction, because it was really meant to be automated by code. Hopefully weā€™ll see such decoding included in a future version of the ckBTC transaction dashboard so that users donā€™t have to do this manually.

3 Likes
20

Indeed, we are adding ckBTC memo decoding to the ICP Dashboard soon. It may be released as early as this week.
cc: @cymqqqq