We do not have a decentralized BTC bridge yet, so we lack the technical capability to do this right now.
At a wild guesstimate, the current ETH bridge could be adapted to BTC, with a running cost under 0.005 BTC = 500 USD per day, or 0.73 BTC = 76k USD per year, maybe I’m way low balling these costs though. Also BTC withdrawls would take one day, but could be done “quickly” for maybe 0.0025 BTC = 250 USD.
Assuming those costs wind up prohibitively expensive..
An inexpensive BTC bridge would use a scalar resharing DKG run among the polkadot validators. There exist decentralized BTC bridges like dFinity, but afaik they cannot scale beyond maybe 40ish validators.
As I mentioned here polkadot has a unique technical advantages for doing large DKGs, thanks to (machine) elves aka parachain. In other words, polakdot could become the only really decentralized BTC bridge using a large-ish validators set, say 500-1000 nodes.
We’re moving this direction ala RFC#144 but only slowly. At present though, we favor first doing an aggregatable DKG that’s not the scalar DKG suitable for a BTC bridge, nor close to post-quantum tricks for tranche zero either.
At a technical level, we research guys should first properly explain our case for doing the aggregatable DKG before the scalar DKG. You guys should argue that a BTC bridge, aka scalar DKG, looks economically so valuble we should change our minds.[1] Ask the scalar DKG happen before JAM too maybe, but that’s a huge commitment from Parity.[2]
In summary..
You’re asking for a BTC bridge first & foremost. We’ll eventually do a BTC bridge that’s more decentralized than other ecosystems, just because elves (parachains) provides a better framework for DKGs. We’re making some progress this direction ala RFC#144. Yet so far, we’ve prioritized ETH bridges over BTC bridges, and now we’ve prioritized DKG not suited for a BTC bridge, so someone should convice both research and parity to make the BTC bridge a higher priority.
Footnotes:
[1] I’m personally dubious that a “bitcoin reserve” aka spending DOTs to buy BTC helps much, although sure maybe more useful than AMMs running huge DOT faucets. Ideally, you’d instead want polkadot managing other people’s BTC which they then use or trade within our ecosystem. I suppose one could explain how larger traders use BTC, USDT/USDC, and others, plus what non-faucet services would entice them into doing their trading on polkadot. Afaik we’re talking advanced stuff like options here, for which afaik none of our AMMs look suitable. Anecdotally, ZK options would be a killer app for bitcoin holders, but that’s way off for many reasons. Alternatively one could fix all our usability issues maybe?
[2] JAM services would typically be divided into parachain-like services with a single state root, and actor-like services with multiple state roots, but developers avoid baking state roots, actors, etc in too deeply then zero state roots becomes possible, and this brings liveness advantages for DKGs. Ergo, there is a temptation to wait for JAM for all of this, which could take a while longer.