We revised the pricing of the Bitcoin API for the Bitcoin Mainnet canister.
See the IC pricing page for a complete overview of the prices, as well as the Bitcoin documentation for more details. Below is the relevant information for your convenience.
Note that in order for the API to be future proof, some of the methods require to send more cycles along with an API call than actually required and any cycles exceeding the actually-charged cost are refunded. This allows for the Bitcoin subnet size to grow, which results in an increase in price, without canisters breaking.
The 13-node figures apply to the Bitcoin Testnet canister, the 34-node figures to the Bitcoin Mainnet canister. Just to avoid confusion, the size of the subnet where the calling canister resides on does not matter, only the size of the subnet where the Bitcoin canister sits does.
Transaction
Description
13-node Subnet (Bitcoin Testnet)
34-node Subnet (Bitcoin Mainnet)
Coding Bitcoin
Bitcoin UTXO set for an address
For retrieving the UTXO set for a Bitcoin address (bitcoin_get_utxos)
100,000,000
50,000,000 + 1 cycle per Wasm instruction
Bitcoin fee percentiles
For obtaining the fe percentiles of the most recent transactions (bitcoin_get_current_fee_percentiles)
100,000,000
10,000,000
Bitcoin balance for an address
For retrieving the balance of a given Bitcoin address (bitcoin_get_balance)
100,000,000
10,000,000
Bitcoin transaction submission
For submitting a Bitcoin transaction to the Bitcoin network, per transaction (bitcoin_send_transaction)
5,000,000,000
5,000,000,000
Bitcoin transaction payload
For submitting a Bitcoin transaction to the Bitcoin network, per byte of payload (bitcoin_send_transaction)
20,000,000
20,000,000
Cost per API call in USD (as of the USD/XDR exchange rate of November 23, 2022):
Transaction
Description
13-node Subnet (Bitcoin Testnet)
34-node Subnet (Bitcoin Mainnet)
Coding Bitcoin
Bitcoin UTXO set for an address
For retrieving the UTXO set for a Bitcoin address (bitcoin_get_utxos)
$0.00013088600
$0.00006544300 + Wasm instruction cost
Bitcoin fee percentiles
For obtaining the fe percentiles of the most recent transactions (bitcoin_get_current_fee_percentiles)
$0.00013088600
$0.00001308860
Bitcoin balance for an address
For retrieving the balance of a given Bitcoin address (bitcoin_get_balance)
$0.00013088600
$0.00001308860
Bitcoin transaction submission
For submitting a Bitcoin transaction to the Bitcoin network, per transaction (bitcoin_send_transaction)
$0.00654430000
$0.00654430000
Bitcoin transaction payload
For submitting a Bitcoin transaction to the Bitcoin network, per byte of payload (bitcoin_send_transaction)
$0.00002617720
$0.00002617720
Some Bitcoin API calls must have at least the following amount of cycles attached to be future proof. Cycles not consumed by the call are returned. This figure does not depend on the replication factor of the subnet, but is intended to allow for the replication factor to grow over time without canisters to be adapted. The call for submitting a Bitcoin transaction to the Bitcoin network does not require to attach extra cycles as the charged cost is independent of the replication factor of the subnet.
API call
Minimum cycles to be attached for Bitcoin Mainnet
get_utxos
10,000,000,000
get_balance
100,000,000
get_current_fee_percentiles
100,000,000
The bitcoin_get_utxos call is charged through a baseline fee that amortizes part of the Bitcoin block processing and the cycles cost of the actually-consumed Wasm instructions. This is the fairest way of charging because a flat fee would be less fair for requests returning a small number of UTXOs, while a fee scaling with the number of UTXOs is hard to define in a clean way. A few informal test measurement have yielded Wasm execution fees anywhere in the range from less than 200K to more than 1,000K cycles per returned UTXO and in addition 30M-50M cycles for processing of the unstable blocks. This wide variance per UTXO was the reason to not use a charging approach based on the number of UTXOs returned, but it should give you, as a potential canister developer, a rough indication of what to expect to pay in terms of fees. For queries with a small number of UTXOs, you can expect around 100M cycles as fee to be deducted from the provided cycles on the call for a majority of calls.
Iâm getting the itch to learn programming myself seeing the progress made. Very cool stuff.
I have on question tho. Since ThorChain claims it can execute native assets, what is the difference between their crosschain protocol and ICPâs? Or are they using ânativeâ very liberally?
@Zane already gave some information above, hereâs some more:
As far as I know ThorChain, their threshold ECDSA protocol cannot make progress if a single node does not participate. The ICâs chain-key ECDSA signature protocol (a.k.a. threshold ECDSA) can still make progress if less than 1/3 of the nodes donât play along. Not optimizing such a protocol only for the optimistic case where everything goes well is important in the blockchain context. Itâs a fairly normal situation in a system following a byzantine failure environment that a node may be compromised. Not considering this in the implementation means not being practical, i.e., ready for the real world.
Also, the ICâs chain-key ECDSA signatures comprise advanced protocols for secure key generation, inter-subnet resharing for key backup, and periodic resharing of keys within a subnet. The latter, for example, is important to help prevent against adaptive attackers who try to compromise replicasâ key shares over time. After a key resharing, the previous shares are worthless, thus such adaptive attacks are made much harder.
In order to differentiate the ICâs threshold ECDSA protocol suite that has all these additional niceties from the off-the-shelf libraries, we use the term chain-key ECDSA signatures to refer to the protocol suite instead of just using threshold ECDSA. This may explain also that more recently this term is increasingly used.
Hi everyone. Just wondering if we have a graphical representation of how the Bitcoin integration actually works?
Something likes how Bitcoin network is connected/integrated to IC network, and what is the flow when someone makes a BTC transaction.
Iâll also be greatful if we have a graphical representation of how a Defi procotol in IC can leverage Bitcoin integration. I think itâll be very helpful not just for developers but âa laymanâ to understand the principles of this break-through technology.
Thanks.
Well, I donât know if he has a point or not, but I can notice how the goalposts keep moving. He started with the premise that this is a bridge. Then the Dfinity folks came in and offered arguments towards deeper integration. And his final argument was âwell, as long as your chain respects your canistersâ. Well, duuh! Of course the consensus has to hold. If it werenât holding we wouldnât have a chain.
In other words, I believe we can all agree that as long as both chains work as intended, a canister on the IC can produce effects both on the BTC chain and on the IC chain, regardless of how you communicate between the two chains. That to me signals a deeper integration.
Mhh Iâm not sure I feel the same way. His point is you canât call it a native integration if you have to rely on any safety assumptions that arenât the ones of the native chain.
Thorchain and other protocols have implemented Threshold ECDSA, although less efficiently than Dfinity, but they still refer to their tech as a bridge. The way I understand it is Dfinity took that apporach and made it more efficient/secure, but the underlying logic is the same.
And my point to this is, again, âduuuh!â. Of course you need to rely on the safety assumptions of your own chain. Otherwise it would simply be a clone of the original chain.
IC is its own chain. In order for it to be a chain, it needs to respect some (self defined) things. It wouldnât be a chain otherwise. If the argument here is âbtc is older and more proven, IC is new and needs to prove itselfâ then we agree fully. Of course thatâs true. But that has nothing to do with inter-chain integrations. I still believe that as long as both chains work reliably as self-described, then this integration is deeper than a bridge.
As a hypothetical: say tomorrow thereâs a bug in the way the IC exposes the BTC API. And dfinity drops the integration. Would the canisters still be able to use tECDSA to sign transactions on the BTC chain, regardless of being able to communicate that transaction? If the answer is yes, and we can take that signed transaction and pigeon-send it to another chain, then the argument for this being a bridge would crumble. It would still be a deeper integration, IMO.
But how can rollups be possible with BTC, @JaMarco, when BTC is a âdumb coinâ with no smart contract capability? In my view, the key questions here are as follows: 1) whether any trust is required from a centralized intermediary (e.g., like soBTC = BTC wrapped on Solana, with the now failed FTX in the middle), or 2) whether a third blockchain/sidechain in the middle is required. For the latter, even if the third chain is decentralized, this introduces a critical latency gap in the handoff process between two transacting parties that could be exploited or cause invalid/duplicate transactions. Iâm not an expert in cryptography, but common sense tells me that introducing a middleman is never a good idea for real-time transactions, decentralized or not.
To follow-up on @Manuâs post regarding validating the bitcoin state, here is the utxodump_shuffled.csv file that we used (youâll need to decompress it with tar xzvf). In case you ran into the same determinism issue that Manu ran into, you can use this file and skip to step 6 of the instructions directly.
To verify the contents of this file:
Run steps 1 to 4 of the instructions. Youâll end up with a file called utxodump.csv.
Run sort utxodump.csv to sort the file, and compute its checksum by running sha256 utxodump.csv.
Run sort utxodump_shuffled.csv to sort the file you downloaded above, and compute its checksum by running sh256 utxodump_shuffled.csv
The checksums should match, verifying that the contents of the files are identical.
