Technical Working Group: BTC on ICP

[bob11]

Hello everyone,

I’m Bob Bodily, the CEO and Co-Founder of Toniq (ICP NFT marketplace) and Bioniq (BTC Ordinals marketplace). I’ve been very involved in the ICP ecosystem over the last 2 years and very involved in the Bitcoin Ordinals ecosystem over the last 5 months. I’m very optimistic about using ICP to make Bitcoin and Ordinals better. To this end, I propose a new Bitcoin on ICP working group.

Goal

The goal of this working group is to work together as an ecosystem to make Bitcoin better with ICP. This includes (1) working closely with those in the Bitcoin and Ordinals ecosystems, (2) building decentralized Bitcoin solutions at the application layer on ICP, and (3) working at the protocol layer to support future Bitcoin use cases.

Scope

This working group will meet every 1st Thursday of the month at 3 pm UTC. Each meeting will be summarized and provided to the community publicly.

How to make Bitcoin Ordinals better with ICP:

1. Decentralized Ordinals indexer on ICP
2. Decentralized BRC-20 indexer on ICP
3. Decentralized BRC-20 token wrapper on ICP
4. Additional functionality for other Bitcoin protocols (counterparty, stamps, SRC-20, etc)
5. Threshold Schnorr at the protocol level to enable Taproot transactions and inscriptions via canisters
6. Full Bitcoin node on ICP (unpruned w/ -txindex) to power decentralized Bitcoin explorer

Already in progress or completed:

1. Bitcoin wrapper on ICP. This was completed by the Dfinity foundation → ckBTC.
2. Ordinals wrapper on ICP. This is in progress (nearing completion) by the Bioniq team.

Leadership

I am heavily involved in both the ICP and Bitcoin communities and will be leading this working group. If there is additional interest let me know.

First Meeting and Cadence

We meet every 1st Thursday of a month at 3 pm UTC starting August 3rd.
The event is posted to the Internet Computer Events calendar (browser link).

[Manu]

Thanks for kicking this off @bob11! I’m definitely interested in participating.

[Jupes_M]

More interest here! Thanks for starting this WG.

[josephgranata]

@bob11 count me in, I am also interested in using BTC with the IC, not for ordinals but for payments, and value transfer, so I am quite happy a group has been created to channel this with DFINITY and the IC Dev. Community.

Email sent!

[ld-dfn1]

Thanks @bob11 for kickstarting it. Plz also count me in

[JoakimEQ]

Interested in joining! Will send an email - could we also possibly have a channel on the ICP discord?

[domwoe]

The Working Group meeting is happening today at 5 pm CEST (3 pm UTC)
Zoom link

[domwoe]

We are meeting in 10min (5 pm CET). Please join!

Join our Cloud HD Video Meeting

[abc]

Seize opportunities and generate unlimited reactions!

We (MUST AND HAVE TO) implement, apply threshold Schnorr and more AS SOON AS POSSIBLE ! (@Jan @Manu @Jens Groth @domwoe @cryptoschindler @bob11 …)

(BTC L2 ,Meta-Protocols and more) will explode in the next year, we have to make full use of the existing IC’s technology to seize the market and opportunities, time and opportunity waits for no one!

UniSat Wallet - Store, Inscribe and Search.

Thank you very much!

[domwoe]

Join us for a Working Group session today at 5pm CET (4pm GMT).

We have the following agenda:

• @bob11 will give an update on all things Bitcoin and Bioniq.
• Quick round of updates on other initiatives depending on who’s joining
• @sardariuss will demo his Ordinals Canister.
• @domwoe will give a preview of an Ordinals Inscription Canister.

Please let me know if you want to get a direct calendar invite for the working group.
Otherwise you’ll find the meetings in the ICP Events calendar and on the ICP Dev Discord Calendar.

[domwoe]

Here’s a ChatGPT-generated summary and the recording of the last meeting.

The agenda included updates on the Bitcoin ecosystem, specifically advancements in ordinals and Bitcoin DeFi, and introductions to new projects within the group.

Bob Bodily provided an extensive update on ordinals, highlighting recent improvements in the ordinals protocol, such as a new way to inscribe ordinals using delegation and batch inscriptions. He also discussed developments in Bitcoin DeFi, mentioning protocols like Tap and Pipe, and the growth of the Atomicals colored coin protocol.

Max Chamberlin shared updates on the Bitfinity EVM side, focusing on the deployment for mainnet and the challenges encountered with historical block storage. He also mentioned experimentation with Schnorr signatures for BRC-20 tokens and the potential for interoperability with other protocols.

Tanguy presented a demo of the Ordinals Canister, a tool designed to query all information from different APIs using HTTP outcalls, focusing on the Bitcoin ecosystem.

Larron Armstead introduced a new project called Dopamine Finance.

Andy from Lokamining shared updates on their Bitcoin mining pool, which converts mining rewards directly into ckBTC, and their plans for a “mining place” to decentralize liquidity for the pool.

Dominic Wörner provided an update on threshold Schnorr, which is expected to start next month, and highlighted its importance for Bitcoin transactions and holding Solana assets.

Neeboo from AstroX provided updates on their work with the Atomicals protocol and the success of their extension wallet for the protocol.

The meeting showcased the vibrant developments and collaborative efforts within the ICP and Bitcoin ecosystems, with various projects pushing forward innovations in ordinals, DeFi, mining, and interoperability.

[domwoe]

Quick reminder that the group is meeting today at 5pm CET.

Here’s the link to the Zoom meeting: Launch Meeting - Zoom

[neeboo]

Here are what I can think of applications/services to build BTC on ICP:

1. Threshold Schnorr Signing: easy way to secure bitcoin using ChainKey tech.
2. On-chain Indexing for Meta-Protocols on L1, leveraging httpOutcall and canister data storage.
3. vetKey for privacy protection and On-chain E2EE, protecting metadata for NFT protocols (Ordinals)
4. Multisig Wallet and multi-party ownership, leveraging internet identity and delegation protocol.
5. Atomic swap for UTXO(PSBT) and programmable order-book-like marketplace/DEX.
6. Oracles, Mixers…
7. more than you think…

[domwoe]

Thank you all for joining the meeting yesterday. Recording, transcript and auto-generate summary can be found here.

We’ll continue probably next Thursday at a more Asia-friendly time. I’ll give an update soon.

One discussion point that was brought up by @THLO was whether it would be useful if the IC’s Bitcoin API were extended to serve block headers. This would allow canisters to verify the authenticity of blocks or transactions pushed by clients or fetched by HTTPS outcalls.

If you have use cases for this, please raise it here.

[Maxfinity]

It seems like a good use case would be decentralised indexers, would definitely be useful. Thanks @THLO. I know I wasn’t sure if there was a more direct route but seems the witness data is committed in the block.

[domwoe]

@domwoe

We’ll continue probably next Thursday at a more Asia-friendly time. I’ll give an update soon.

I scheduled an additional meeting to continue the discussion next Thursday March 14th at 6 am UTC.

[neeboo]

Using rust-bitcoin UTXO struct might be better.

And we can make metaprotocol extension on top of it.

[domwoe]

@neeboo

Using rust-bitcoin UTXO struct might be better.

Do you mean better than the current representation?

type outpoint = record {
    txid : blob;
    vout : nat32;
};

type utxo = record {
    outpoint : outpoint;
    value : satoshi;
    height : nat32;
};

Can you post the representation in rust-bitcoin?

[neeboo]

What we actually need is the TX payload, with TxIn and TxOut.
For TxIn, we can read witness data,
For TxOut, we can read script_pubkey

#[derive(Clone, PartialEq, Eq, PartialOrd, Ord, Debug, Hash)]
#[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]
pub struct Transaction {
    /// The protocol version, is currently expected to be 1 or 2 (BIP 68).
    pub version: i32,
    /// Block number before which this transaction is valid, or 0 for valid immediately.
    pub lock_time: u32,
    /// List of transaction inputs.
    pub input: Vec<TxIn>,
    /// List of transaction outputs.
    pub output: Vec<TxOut>,
}

#[derive(Clone, PartialEq, Eq, PartialOrd, Ord, Debug, Hash)]
#[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]
pub struct TxIn {
    /// The reference to the previous output that is being used an an input.
    pub previous_output: OutPoint,
    /// The script which pushes values on the stack which will cause
    /// the referenced output's script to be accepted.
    pub script_sig: Script,
    /// The sequence number, which suggests to miners which of two
    /// conflicting transactions should be preferred, or 0xFFFFFFFF
    /// to ignore this feature. This is generally never used since
    /// the miner behaviour cannot be enforced.
    pub sequence: u32,
    /// Witness data: an array of byte-arrays.
    /// Note that this field is *not* (de)serialized with the rest of the TxIn in
    /// Encodable/Decodable, as it is (de)serialized at the end of the full
    /// Transaction. It *is* (de)serialized with the rest of the TxIn in other
    /// (de)serialization routines.
    pub witness: Witness
}

#[derive(Clone, PartialEq, Eq, PartialOrd, Ord, Debug, Hash)]
#[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]
pub struct TxOut {
    /// The value of the output, in satoshis.
    pub value: u64,
    /// The script which must be satisfied for the output to be spent.
    pub script_pubkey: Script
}

Witness is more useful when it comes to decoding a transaction encoded data, especially for current Meta-protocols like Ordinals and Atomicals, which use “Envelope-like” to wrap the “Inscription” into the witness.

If we want to build on-chain indexer or Oracles, witness data block is needed to track the meta-protocol records.

Envelope in Atomcals

<pubkey-hash>
OP_CHECKSIG     // Perform a check signature against the pubkey-hash
OP_FALSE
OP_IF
 0x0461746F6D // Push "atom" 4 bytes
 <Operation>  // Followed by a single push to denote the operation type
 <Payload>    // Payload (CBOR encoded) for the operation
OP_ENDIF

Envelope in Ordinals

OP_FALSE
OP_IF
  OP_PUSH "ord"
  OP_PUSH 1
  OP_PUSH "text/plain;charset=utf-8"
  OP_PUSH 0
  OP_PUSH "Hello, world!"
OP_ENDIF

And for protocol like Runes, they use OP_RETURN to identify the coin and value. We might also need to read script_pubkey from TxOut.

link and see they how they encode the data:

ordinals/ord/blob/master/src/runes/runestone.rs#L133

[domwoe]

Thanks @neeboo!

I surely understand the need for this data to be able to index metaprotocols. It’d be great if @ielashi or @THLO could jump in on the complexity of this.

Making the block headers (or their hashes) available would allow you to fetch/feed transaction data from untrusted sources and verify the inclusion in the authentic blockchain with a Merkle proof against the block header.