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.
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,
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).
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.
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ā¦
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)
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.
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:
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).
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) ?
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.
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:
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.