Direct Integration with Bitcoin

[romulusp]

Now is time to party !
Tomorow eth integration
And also we need some marketing. I hope we will reach cointelegraph this time and other major media

[dieter.sommer]

Cycles Pricing for the Bitcoin Mainnet API

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.

[anonymous]

I hope you guys celebrate after all the hard work put into this, seriously. Congratulations!

[InsaneClownPosse]

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]

Long Term R&D: General Integration (Proposal)

This is a quick answer from the top of my head: Various other projects have implemented threshold ECDSA as well, but to the best of my knowledge, all of them have some shortcomings in properties that make the resulting system problematic for real-world use. And I recall to have seen a couple of exploits, at least one at the protocol level where the private key could be reconstructed after a (rather small) number of computed signatures, of threshold ECDSA implementations as well. One notable pro…

[dieter.sommer]

@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.

[JaMarco]

Does he have a point? https://twitter.com/toghrulmaharram/status/1598775681449881600

[nlh]

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.

[anonymous]

An ETH maximalist who seems to attack anything that isn’t ETH.

Anyway, here’s timo’s response:
https://twitter.com/timothanke/status/1598963448037003265

Shame there’s people trying to discredit DFINITY’s hard work.

[GLdev]

@JaMarco

Does he have a point?

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.

[Zane]

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.

[Choiseongin]

I look forward to everyone making noise about this technology.
The more we prove our legitimacy through many discussions, the stronger we become.

[GLdev]

@Zane

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.

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.

[JaMarco]

@GLdev

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.

Not necessarily. There are chains that inherent the security of the parent chain, like rollups.

[Sabr]

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.

[diegop]

@Inch_Deen

Who cares? I asked when it comes out? Your team delay again and again.

@Inch_Deen Fwiw…. To be clear: It’s out now. I hope this makes my reply 2 weeks ago seem much more reasonable in context for the future.

[ielashi]

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.

[spnrapp]

The fee for bitcoin_get_utxos seems a bit excessive for mainnet?

 Panicked at 'Received 200000000 cycles. 10000000000 cycles are required.'

And this was trying to get utxos of a freshly created address.

[Dylan]

That message does not mean that 10,000,000,000 cycles is the fee.

How Bitcoin Integration Works — Technology Background | Internet Computer Home

[dfisher]

Good luck @spnrapp . lots of us in the community are routing for you guys