Is your feature request related to a problem? Please describe.
One major drawback of overlay protocols like ordinals is that the data is not subject to Bitcoin consensus and thus BRC20 and ord NFT require additional verification by some entity. In practice, these are either trusted third parties or some form of committees that act as TTP. There are several issues with this as the TTP or committee can change the way the data is interpreted and in the committee setting, disagreements might occur between the members which would require implementing some form of consensus protocol to resolve the disagreements.

Describe the solution you'd like
zkVM allows executing off-chain code written in Rust with an on-chain component in Solidity. It might be an avenue to enable Rust off-chain contracts together with a counterpart Solidity contract on the EVM side.

Port an ordinals indexer to zkVM. Porting an indexer in zkVM is an alternative to using some form of committee/TTP. zkVM would allow anyone to submit a bitcoin block that includes some ordinals following various standards and then verify that the ordinals inside are correctly processed by the indexer. The STARK proof can be verified by anyone and zkVM also gives you back return values, e.g., BRC20 deposits/withdrawals between a rollup that would support zkVM. If eventually BTC would support a ZK verify op code, you could also verify it there.

The approch is inspired by Zeth (https://www.risczero.com/news/zeth-release) to work with ord indexers/bitcoin instead of ethereum.

My hope is to understand the following:

• Can we write an indexer using zkVM (https://dev.risczero.com/zkvm/quickstart)?
• What are the blockers/issues when developing?

Abstract

The Early Renaissance marks the official testnet launch for BOB. The testnet allows for:

1. Users to bridge BTC, P2P swap ERC20s, BTC, and BRC20s, interact with EVM smart contracts, interact with zkVM off-chain programs, and pay with a bridged BTC for transaction fees.
2. Builders to deploy EVM contracts and zkVM off-chain programs, interact with Bitcoin via a BTC relay, and let users pay tx fees in BTC in their apps via an SDK.

Motivation

The Early Renaissance had a significant overlap with the period of the Late Middle Ages but marked the progression into modernity. Similarly, for BOB, the period of the Early Renaissance is marked by many influencing factors that will shape the BOB stack as the collective members are onboarded. Each member will bring in new influences that will work together to progress the stack to set the standard for building on Bitcoin.

The Early Renaissance for BOB leads to the official testnet launch. The testnet will enable users to test early beta and alpha versions of applications built on BOB. In turn, builders can gain feedback on how to improve their apps and work towards mainnet launch. BOB itself will start to offer an SDK to interact with the BTC relay as well as pay for tx fees with BTC. BOB should improve based on the builder feedback by adding missing features and improving the developer experience. Ideally, it would take a week to create a working demo for a new app built with BOB.

Goals

Target completion: Before Christmas 2023

• Builders can deploy EVM contracts on a hosted testnet
• Builders can interact with the BTC relay aided by types and examples from a Solidity library
• Users can pay tx fees in a bridged BTC as if it was a native transaction
• Users can interact with EVM smart contracts using WalletConnect and MetaMask
• Users and builders can interact with EVM smart contracts programmatically (ethers.js, wagmi, ...)
• Builders can interact with zkVM programs from their Solidity smart contracts
• A novel use case combines Bitcoin, zkVM, and BOB
• Users can learn about how BOB works in the documentation
• Builders learn how to build on BOB with the documentation
• Builders understand how BOB works under the hood via the documentation

Requirements

Deliver a hosted testnet, a P2P swap dapp, an SDK, and an zkVM ordinals indexer.

Testnet

Requirements and specification tracked in #16

SDK

The BOB SDK is meant as a set of Solidity contracts, Rust and/or TypeScript functions, and UI components to access the unique functions of BOB and make developing new applications on BOB simple. Where possible, existing libraries (OpenZeppelin, ethers.js, wagmi, viem, ethers-rs, foundry, react, ...) should be preferred before adding new functionality.

Requirements and specification tracked in #17

P2P Swap

The P2P swap is meant to expose a set of smart contracts that allow users to swap BTC, BRC20s, and ERC20s. Anyone should be able to deploy a UI and additional tooling (improved order matching, ...) on top of these smart contracts.

Requirements and specification tracked in #7

zkVM

The zkVM would allow anyone to write complex programs like a full ordinals indexer with an integrated DEX and then verify the correctness of the code without having to run a dedicated consensus over it. This is more of a moonshot project. But if it works, would provide an avenue to extend BOB with a range of Bitcoin programs like: ordinals and BRC20 DEXs, ordinals and BRC20 lending protocols, BTC stablecoins, decentralized LN hubs, autonomous nostr relayers, and many more.

Requirements and specification tracked in #3

Is your feature request related to a problem? Please describe.
We often get asked how to achieve trustless communication between Bitcoin and BOB. For example, swapping ordinals with ERC20 prompts most people that we talked to think that the ordinals need to be bridged. However, in a P2P fashion, bridging isn't required.

Describe the solution you'd like
Add a section to the docs, likely under here https://docs.gobob.xyz/docs/learn/guides/, that explains the principles of how a BTC light client works, what the trust assumptions are, and what applications can be built with this.

Additional context
The description should be SEO-friendly so we start building up a useful wiki for builders.

We can reuse text from the interBTC spec: https://spec.interlay.io/spec/btc-relay/index.html

Is your feature request related to a problem? Please describe.
I propose the addition of paths for both the BOB testnet and mainnet. These paths should be made accessible under the 'gobob' domain. You can find the specific paths by following this link: Paths Reference. Once this implementation is complete, kindly update the documentation accordingly.

Additional context
Originally posted here

Abstract

Add optimistic merged mining to the BOB OP stack rollup to allow Bitcoin miners to validate the rollup.

Goals

Plain OP stack depends only on Ethereum security for the rollup. With optimistic merged mining, we allow Bitcoin miners to verify the rollup sequencer and, in return, receive parts of the sequencer fees. This adds Bitcoin security to the roll-up, such that Bitcoin-centric apps (ordinals, BTC, BRC20, Runes, …) can offset the trust in Ethereum and the centralized sequencer.

Our goal is to make the changes for merged mining as non-invasive as possible to the OP stack with the long-term goal of being Superchain compatible. The pitch is: to add the ability to condition settlement of the OP rollup on another smart contract. This contract can implement a straightforward interface like allowSettlement() and return a boolean. We will use this for Bitcoin PoW security but other use cases (institutional, re-staking for rollup validation, offsetting centralized sequencer trust) could also be helpful.

How does it work?

• The OP proposer submits data to Ethereum as in other OP stack chains.
• Bitcoin miners take a range of block hashes from the BOB L2 and include a single hash of the BOB L2 into the Bitcoin block (as part of the coinbase transaction). Miners perform PoW until they find a Bitcoin block that matches the BOB L2 difficulty.
• Bitcoin miners submit the Bitcoin block with the BOB L2 hash to Ethereum when it meets the PoW difficulty of the BOB L2.
• A smart contract on Ethereum verifies that the submitted Bitcoin block with the BOB L2 hash reference meets the required difficulty and includes a valid BOB L2 hash.
• The next time the proposer submits the BOB L2 state to Ethereum:
  • In the current OP stack (pre-fault proof contract adjustments), the L2OutputOracle smart contract checks that the last confirmed BOB L2 block is not older than a specific timeout, e.g., Bitcoin miners need to verify/merge mine the BOB L2 every 4 hours.
    • If the last merged mined BOB L2 block was less than 4 hours ago, the proposer can submit the state.
    • If the last merged mined BOB L2 block was older than 4 hours, the proposer cannot submit the new state. This is a critical consensus failure that needs to be resolved.

Long-form of optimistic merged mining here: https://docs.gobob.xyz/docs/learn/bob-stack/merged-mining

Required Changes

We need to look into the fault-proof smart contract adjustments. In the current set of contracts, we’d change the L2OutputOracle contract to add a call to another smart contract in the proposeL2Output function that checks the presence of the PoW for BOB. The function interface would remain untouched.

We are going to write an additional component, e.g., op-merged-mining, that exposes RPC APIs for the miner. However, these are in parallel to the existing op-node, op-geth, op-proposer, and op-batcher. We don’t modify the existing components.

Use Cases

The primary use case is to add Bitcoin security to an OP stack rollup. We are launching BOB as a rollup with the OP stack, but we imagine that successful apps on BOB will eventually want to have their own block space environment, either as an L3 or an L2. Making the PoW checking compatible with the standard OP stack would thus be great.

We think that there are other possible use cases where an external validator could verify the correctness of the sequencer/L2.

Is your feature request related to a problem? Please describe.
The SDK has little documentation and we hadn't had time yet to bring it to a state where others can easily use it or contribute to it.

ToDos

For Bitcoin Asia

• #178
• Extend the Hello Bitcoin example (https://docs.gobob.xyz/docs/build/getting-started/helloworld) to show how to use the BOB SDK from a node.js script to (1) submit Bitcoin block headers to the deployed relay, (2) fetch the transaction inclusion proofs from electrs, and (3) submit the transaction inclusion proof to the BTC Relay.

Others

• Add an overview to the docs of the SDK what the different components do, e.g., electrs, ordinals, helpers
• Replace bitcoinjs-lib dependency with https://github.com/paulmillr/scure-btc-signer everywhere

Is your feature request related to a problem? Please describe.
Export Ordinals clients in the sdk

Describe the solution you'd like
Just add missing export

Front-end

• add bitcoin address validation in ui
• in complete order dialog, show the actual address
• until electrs is working, use 30 second countdown after which you can confirm payment
• in complete order dialog, use electrs to detect the tx and show it
• handle loading states (rui)
• supply bitcoin proof in complete order dialog

Back-end

• add proper address types
• set contract deadlines to 6 hours
• Take bitcoin proof in order dialog

Dev-ops

• make docker-compose image to deploy bitcoin regtest + electrs

Problem
getTxOutputValue panics with EvmError: OutOfGas error when invalid input is provided.
Testcase to trigger the corner case.

Originally posted by @nakul1010 in #119 (comment)

Add support for Safe (multisig) wallet

Findings

Safe wallet https://app.safe.global provides a way to set-up smart contract account with options to create advanced multi-signature wallet.
Currently, Safe multisig wallet supports only selected EVM chains (it does not support any chain like metamask). In order to make them support Bob L2, we would have to reach out to their team.

After the support is added, dApps need to use Safe apps SDK in order to integrate the functionality of app into Gnosis Safe wallet: https://docs.safe.global/safe-apps-sdk/safe-apps

Is your feature request related to a problem? Please describe.
The wBTC transfer demo https://demo-account-abstraction.gobob.xyz/ showcases the power of using AA to allow users to pay transaction fees in ERC20s. However:

1. Users still need to bridge ETH to BOB making the process to onboard quite lengthy.
2. Users need to create a new wallet if they come from Bitcoin.

Describe the solution you'd like

1. Create smart contract accounts on behalf of users (they should not need ETH) to get started
2. Users then fund the accounts using the faucet (this will need to be added as a way to do this in prod)
3. Allow users to use social logins to transfer wBTC

Create a hackathon template/starter project so that engineers can get started straight away.

Include templates for:

• Solidity contracts
• React/interlay-ui frontend
• BTC relay contracts
• Provide starter kit for devs

Consider also documentation:

• Comprehensive getting started instructions in the readme
• Self-documenting code where possible
• Inline comments where helpful

This should be tested by distributing to the whole engineering team for feedback.

Is your feature request related to a problem? Please describe.
We are using Docusaurus 2.

Describe the solution you'd like
Update to Docusaurus 3 to have the latest supported features.

Is your feature request related to a problem? Please describe.
Currently we host all demos but we might not continue to do so later on.

Describe the solution you'd like
Allow users to easily host our demos themselves

Is your feature request related to a problem? Please describe.
Protocols built on top of Bitcoin have various APIs available, but they are early stage and often lack documentation. Moreover, they are not well integrated with existing REST APIs like electrs.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Abstract

Develop a PoC for the BOB stack that allows:

1. Builders to deploy EVM contracts and use a BTC relay to interact with Bitcoin.
2. Users to bridge between a testnet and the rollup (ETH, ERC20) as well as bridge between Bitcoin (BTC) and the rollup via a mock BTC bridge.

Motivation

The Late Middle Age was a period in Europe preceding the Renaissance. It was characterized by many crisis but saw great progress in the arts and sciences. We chose this name for BOB to reflect the many decisions that will have to be made for the stack and at the same time, the new achievements we will be able to make.

BOB is a large project, and having a PoC will allow us to understand the difficulties in bringing it to the testnet and mainnet readiness.

Goals

Target completion: End of September 2023

• Builders can spin up a local testnet
• Builders can deploy EVM smart contracts on the local testnet
• Builders can interact with a BTC relay (can still be mocked in parts)
• Users can interact with a local testnet via EVM interfaces (wallets, ethers.js) bridging ETH/ERC20s/BTC
• Completed design for a novel Bitcoin bridge
• Alpha-stage documentation for the rollup design and how to build on it

Specification

Deliver a proof of concept implementation of the BOB stack rollup and builder platform.

Organizational

• Create a new GitHub org
• Publish new docs

Research

• Specification for BTC bridge
• Decide which rollup stack to use

Chain

• Spin up OP Stack rollup for testing
• #15
• #14

Smart Contracts

Solidity/EVM

• Mock deployment for BTC bridge: supply collateral, mint synthetic BTC, redeem synthetic BTC, swap synthetic BTC with BTC
• Evaluate existing BTC relay options (Interlay, tBTC, ...) according to maturity, cost, features (taproot, segwit, ...)
• Deploy a BTC relay

UI

• Create a new UI repo
• Proof of concept
  • Setup ethers.js for account management and runtime interaction
  • WalletConnect 2.0 or MetaMask wallet integration
  • Transfer ERC20 on rollup

Should be the same as https://docs.optimism.io/chain/tokenlist

Abstract

We already provide a Typescript SDK for inscribing and transferring Ordinals, this uses Esplora (Electrs) as a back-end to fetch blocks and transactions. There is interest in using Rust to develop tooling for BOB since many useful libraries exist so we should provide a Rust SDK that achieves the same functionality.

Motivation

We aim to use Risc Zero to support Rust smart contracts in the future.

Specification

The idea would be to introduce a Rust crate, structured similarly to the TS SDK, that uses the rust-bitcoin dependencies to abstract inscribing and transferring Ordinals (and more!). We can also use the bdk library for wallet functionality and re-use code from the Ord project since that is also written in Rust. There is also a lot of relevant code written for interbtc-clients that interfaces with Bitcoin Core and Electrs that we can use.

Builders can interact with the Bitcoin testnet from BOB via the BTC relay aided by types and examples from a Solidity library including Bitcoin, ordinals, BRC20s

Closely related to #89, we need to finalize the Solidity smart contracts and supporting SDK - adding more tests and documentation. We also need to extend the contract suite to support Ordinal / BRC20 parsing and show developers how to utilize that functionality.

Is your feature request related to a problem? Please describe.
We currently have several deployed demos. We should unify these demos into one that showcase the strengths of BOB into a single application instead of having to send users and builders to multiple websites.

Describe the solution you'd like

Extend the P2P swap demo to be our one single demo:

• Add BRC20 token support to the demo
• Add a FAQ sidebar that helps walk people through the demo, similar to Base https://bridge.base.org/deposit
• Add a CTA to allow users/builders to give us feedback via a Google Form
• Add the possibility to inscribe testnet ordinals
• Add the possibility to deploy and mint BRC20
• Add the option to use our MetaMask snap for both the Bitcoin and the EVM wallet
• Allow paying for transactions fees using tBTC via Meta Transactions
• Allow using the P2P demo with smart accounts/account abstraction

The isolated demos should still exist as code examples for builders so that anyone can look at how to implement them without having to comb through a lot of (possibly) unrelated code.

Context and Alternatives

I really like demos like https://demo.privy.io/ where you can click around with the different features on one side and then try it out in the other part of the window. Once we have completed the above, we could add a little "customize your demo" sidebar that would allow:

• Activating/deactivation the meta transaction fee payment and add/remove USDT/USDC/wBTC/tBTC as fee payment options
• Activate/deactivate account abstraction with social logins
• Switch between single/dual wallet experience

Is your feature request related to a problem? Please describe.
We are currently implementing Bitcoin signing logic in various places like the SDK and in the sats-wagmi package. The problem is that these implementations diverge and lack testing. I like a single isolate tx creation and signing logic here that we can reuse in node.js scripts, testing suits, or in frontend packages.

Describe the solution you'd like

Add the following methods with tests:

Prio 1

• Transfer BTC
• Transfer BTC with OP_RETURN (needed for onramp)
• Transfer ordinal with OP_RETURN (needed for ordinals bridge)
• Transfer Rune with OP_RETURN (needed for runes bridge)

Prio 2

• Inscribe ordinal
• Inscribe BRC20
• Etch Rune
• Transfer ordinal
• Transfer BRC20
• Transfer Rune

Build this on https://github.com/paulmillr/scure-btc-signer and https://github.com/paulmillr/micro-ordinals.

Don't use bitcoinjs-lib.

Is your feature request related to a problem? Please describe.
The current P2P demo doesn't allow to swap ordinals. BOB can do that, so would be great to show it.

Describe the solution you'd like

P2P Sell Process

1. Alice (owner of the ordinal) goes to the P2P swap UI and submit a link to the ordinal (ord id) they will sell and a price (in some ERC20). Link current UTXO of ordinal via the ord id in the backend.
2. Alice submits to smart contract: price in ERC20 asset (e.g., 20k USDT), ord id, and UTXO where the ordinal currently lives.
3. Bob (buyer of the ordinal) goes to the P2P swap UI and selects the ordinal to buy.
4. Bob submits to smart contract: lock amount of ERC20 (price) and Bitcoin address and reserve ordinal.
5. Alice goes to P2P UI and sends ordinal to Bob's address using the Leather or Xverse wallet (or other Bitcoin wallet).
6. Alice proofs transfer of the ordinal. Submits to smart contract: SPV proof of the ordinal transfer. Check in the backend that one of the inputs is the original UTXO. Verify that first output is sending to Bob. Alice receives ERC20 tokens (sell price) into her account.

Open questions

• Are ordinals always in the first output?

Context

• Show ordinals in the P2P table like we do in https://ordinals.gobob.xyz/ - could have the inscription id a link that open the inscription
• Maybe check zkVM demo logic if we have useful code in there

Abstract

Create a P2P marketplace to allow anyone to swap BTC, BRC20s, and ERC20s (including WETH) without a third party.

Motivation

Building out BOB is best done in combination with a use case from which we can draw conclusions which additional features or improvements we need to make to the base layer.

P2P swaps are one of the earliest use cases of cross-chain communication and have the advantage that users can swap directly without giving up custody to anyone. There's currently no P2P swap for BTC and BRC20s that is both cheap and works without a custodian.

Specification

Target time: end of September 2023

Hackathon-level implementation of the P2P swap. The goal of this project is to understand the complexities of developing the P2P marketplace by delivering a usable deployment of the P2P on a testnet rollup that allows swapping testnet BTC, BRC20s, and ERC20s. Mocking of complex parts of the application is highly encouraged to deliver a usable app.

User Requirements

• Users MUST be able to swap BTC with ERC20s (including WETH)
• Users MUST be able to swap BTC with BRC20s
• Users MUST be able to swap BRC20s with other BRC20s
• Users MUST be able to swap ERC20s with ERC20s
• Users MUST be able to pay for transaction fees in BTC
• Users MUST be able to pay for transaction fees in ETH
• Users MUST NOT give custody of their assets to any other party to achieve the swap

These functions MUST be available for the PoC level.

Protocol Requirements

• Swaps with BTC or BRC20s MUST be confirmed with a transaction inclusion proof. At the PoC level, tx inclusion proofs MAY use a mocked BTC relay.

Protocol

The protocol follows a simple OTC trade logic for the POC stage. In the future, more complex schemes including off-chain order books, Dutch auctions, and other mechanisms will be explored.

The protocol consists of three parts:

1. Placing an order: a user selects an asset to sell and the price they are willing to accept. Users can only select tokens to sell that can be locked on the rollup (ERC20s). If users select to buy BTC or BRC20s, they also have to enter a BTC address.
2. Filling an order: a user fills an existing order by sending the tokens (ERC20s, BTC, BRC20s) requested in the order. Users can partially fill an order, e.g., when an offer specifies to buy 1 BTC for 20 ETH, a user can send 0.5 BTC.
3. Withdrawing an order: a user withdraws an unfilled order.

Placing an order

1. User specifies the ERC20 token sell and the amount
2. User specifies the token to buy and the amount
3. If the user seeks to buy BTC or BRC20s, the user also enters a BTC address
4. User submits the order on-chain locking the tokens to sell.

Filling an order

1. User selects the existing orders (e.g., from a table)
2. User enters the amount of tokens they are selling
3. User sees the amount of tokens they are receiving as determined by the price given by the user that created the order
4. User fills the order by submitting a transaction:
   a. If the user is selling an ERC20, the ERC20 is directly transferred to the user that created the order and order is (partially) filled.
   b. If the user is selling BTC or a BRC20, the user reserves part of the order instantly and has then 6 hours to fill the order on Bitcoin. Once the BTC/BRC20 transaction is sent, a transaction inclusion proof verifies the correctness of sending the BTC/BRC20 and then marks the order as (partially) filled.

It is yet unclear how we ensure unique BTC transactions for proofs.

Withdrawing an order

1. If there's no pending fulfillments (when sending BTC/BRC20s), a user can withdraw their orders at any time.

Security

• It is yet unclear how we ensure unique BTC transactions for proofs.

Create a demo to show inscribing and transferring ordinals using a Metamask snap. Demo can use Metamask flask.

• Publish forked version of btc-snap to npm
• Deploy demo app to public url
• Add pending status after inscription completed
• Display BTC balance
• Ordinals can be inscribed
• Ordinals can be transferred
• Add support for image inscriptions
• Add footer linking to docs

Tracking issue. All requirements TBC.

• #147

Abstract

This proposal outlines a way for Bitcoin users to onboard to BOB rollups without having to explicitly acquire new tokens but rather sending BTC to an address on Bitcoin.

Motivation

TBD

Specification

TBD

Reference Implementation

TBD

Security Considerations

TBD

Is your feature request related to a problem? Please describe.
With BitVM, we can likely build a Bitcoin bridge that only requires 1 of n honest parties. That is much better than the trust assumptions of current bridges and offsets the opportunity cost of locked collateral as in iBTC.

There are many open questions around BitVM and how exactly to implement a bridge. I see the core issue as being able to write a light client for another chain in BitVM - or rather a fraud proof to verify the light client in BitVM.

Describe the solution you'd like
I think an interesting first step would be to implement a toy program in BitVM. This could be something quite simple by verifying that a value is 0 in BitVM. A more complex example would be to implement a SHA256 checker. There are already a couple of these examples here: https://techmix.github.io/tapleaf-circuits/

Outcome of this issue would be to have a a working toy example and a knowledge sharing session how to implement programs in BitVM.

After this, we can break down the requirements for a light client for BOB into its individual parts and try start to implement the relay in BitVM.

Additional context
I found the youtube videos most helpful to get an initial understanding and then the interactive BitVM examples:

• https://www.youtube.com/watch?v=9aBuGObjEHs
• https://www.youtube.com/watch?v=IRU83gRcw3Y
• https://github.com/BitVM/BitVM
• https://techmix.github.io/tapleaf-circuits/
• https://magical-frangipane-149aba.netlify.app/compiler
• https://supertestnet.github.io/8bit-cpu-for-bitvm/#

The BitVM TG chat is very active: https://t.me/bitVM_chat

• Flag existing testnet as alpha and remove from the docs (existing testnet will become an internal testing environment) @tomjeatt
• Update ETH faucet on demos to point to one of the official Sepolia faucets @tomjeatt
• Deploy Multicall3 contract (@peterslany)
• Deploy P2P demo on new testnet: https://docs.gobob.xyz/docs/build/examples/btc-swap/ @tomjeatt
• Deploy ordinals demo on new testnet (@tomjeatt TBD - I think the ordinals demo only interacts with Bitcoin so I guess there's nothing to be deployed).
• Deploy BTC relay on testnet @gregdhill
• Deploy account abstraction tooling to testnet @peterslany @sander2
• Deploy meta transaction tooling to testnet @peterslany @sander2
• List essential contracts (Multicall3, BTC relay, ...) under a contracts section in the docs, like https://docs.base.org/contracts
• Add BOB MetaMask snap to ordinals demo as wallet option: docs/build/how-to/ordinals

Abstract

TBD

Motivation

TBD

Specification

• Users and builders MUST have a public and documented RPC endpoint to interact with the rollup
• Users and builders MUST have a public and documented RPC endpoint to interact with the Ethereum L1 testnet
• Users MUST be able to send tokens between the L1 and L2. We can use https://superbridge.app/ to achieve this. Integration guide: https://conduit-xyz.notion.site/Bridge-UI-34f7189d4a7f462caba444343029418d
• Users and builders MUST be able to get testnet tokens via a faucet (link to a Sepolia testnet faucet for testnet ETH and provide a faucet for any ERC20 token we need) - see also bob-collective/demo-p2p-swap#15

          ###  ⚠️  No Changeset found

Latest commit: 2434d29

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Originally posted by @changeset-bot[bot] in #204 (comment)

Abstract

TBD

Motivation

TBD

Specification

• Users MUST be able to pay transaction fees in bridged BTC

There's several ways to achieve this. This issue explores using either account abstraction or meta transactions.

• Account abstraction usage possible via https://docs.pimlico.io/, gelato, Gnosis SDK, alchemy, ...
• Meta transactions usage possible via OpenGSN

Reference Implementation

TBD

Security Considerations

TBD

Esplora only returns the first 25 UTXOs but for the wallet logic we may need to spend more if the balance is higher.

Originally posted by @sander2 in #267 (comment)

Is your feature request related to a problem? Please describe.
Vercel queues the docusaurus builds but can be a bit slow. Usually, docusaurus fails on broken links and then one needs to either inspect the vercel logs or build manually to see which links caused the build to fail.

Describe the solution you'd like
Add a git pre-commit hook to run yarn build in the docs folder but only if there are changes in the documentation. We could use husky for this.

Describe alternatives you've considered
An alternative is to not fail builds on broken links but that is not desirable since broken links should not be part of the documentation.

Is your feature request related to a problem? Please describe.
Solidity compiler generates multiple warnings for the contracts. Most warnings are related to unused parameters.

Describe the solution you'd like

• Remove the unused parameters, or comment out the parameters and write ToDos if required.
• Change test.yml build command from forge build --sizes to forge build --sizes --deny-warnings.

Problem

The safe math library is not used in any of our contracts, which can lead to overflow underflow situations.

Solution

Use the following safemath library for calculations.

Describe the bug
Based on the hello bitcoin guide. Remix is not flattening smart contract as expected if the smart contract has remappings.

• Tracking issue on remix project repo.
  - Issue fixed in remix, v0.43.0 released.

Urgent

• Update discord link to BOB #209
• #209
• #214
• #215
• #220
• #223
• #224
• #230 , #231
• #229
• #243
• #253
  • DIA copy
  • BlastAPI RPC nodes
  • Arcana Auth
  • Add instructions on how to start a full node
• Update Notion to point to SwaggerUI for Spice APIs
• User guide: onramp from bitcoin (similar to what Dom did for Fusion campaign) Overview
  • Add a way for interested LPs to contact us (modify builder form)
• #264
• User guide: onramp from exchange
• Add LayerZero to Tools
• Add docs on how transaction fees are calculated (adapt from https://docs.optimism.io/builders/app-developers/transactions/fees)

Not Urgent

• Add AI-based search to our docs (Docusaurus has first-class support for Algolia) - Applied for DocSearch program on 25 June
• Add tooltips for all instances of a glossary of terms (plugin)
• Bring SwaggerUI natively "into" docs pages using this plug-in
• Add link to Particle's BTC-connect guide
• Update rollup page to use new visuals and point to the Optimine paper
• Fix HelloBitcoin: replace missing dependencies
• HelloBitcoin: deploy relay script
• Explain reads (relay, oracle) and writes (bridging) in the context of BOB
• Add link checking action to CI/CD
• Add Testnet, Mainnet to wallet buttons (example)
• Interactive examples in docs
• Connect wallet in docs to use faucet
• Interact directly with Bitcoin relay in the docs page
• Add e2e tests to docs (tutorial)

Problem:
In the Ord_Marketplace.sol -> proofOrdinalSellOrder() method, there is a lack of verification for the correct transfer of the satoshi to the buyer's address. While the contract checks that the transaction is spending the specified UTXO and has an output to the buyer's address, it does not verify which specific satoshi is being transferred. This loophole allows potential cheating in the demo version.

Solution:

Implement additional verification steps within the proofOrdinalSellOrder() method to ensure the correct transfer of the specific satoshi to the buyer's address. This includes validating the exact satoshi being transferred and verifying it against the provided UTXO and offset information. By enhancing this method with precise verification checks, the contract can prevent potential cheating and ensure the secure transfer of satoshis in the marketplace.

Originally posted by @sander2 in #114 (comment)

Is your feature request related to a problem? Please describe.
The current hello world example is taken from the Solidity guides. This works but doesn't show the capabilities of BOB.

Describe the solution you'd like
Change the hello world example to showcase the possibilities of BOB:

• Step 1: Create a smart contract that allows swapping BTC for USDT using the BTC relay
• Step 2: Add account abstraction to the mix so that a user can pay for the EVM-side fees in tBTC/wBTC
• Step 3: Extend the smart contract so that a user can buy an ordinal with USDT.

Additional context
See current example: https://docs.gobob.xyz/docs/build/getting-started/helloworld

Is your feature request related to a problem? Please describe.
Local development/regtest is difficult and often impractical, especially when a local Bitcoin node is required. It requires good knowledge of Bitcoin core (which is good to have) but:

1. There's an overwhelming number of options to start a Bitcoin node
2. It's not possible to fork Bitcoin mainnet or testnet into a local devnet for testing
3. Interacting with regtest is not very ergonomical via bitcoin-cli

Describe the solution you'd like
We need an easy-to-use tool similar to bitcoind -regtest with additional functionality. It does not need to provide consensus compatibility, but should make it easier to replicate Bitcoin "quirks" for testing. For example with regtest we cannot emulate chain forks to test light client (SPV) logic, it is also cumbersome to auto-mine blocks and bitcoind does not allow us to "fork" from some pre-existing state. The tool should be similar to anvil from the Foundry suite and should provide Bitcoin RPC compatibility so we can re-use existing tools such as Electrs.

Describe alternatives you've considered
We have been using regtest for quite some time, right now nothing exists which satisfies these requirements.

Additional context
We should use rust-bitcoin and existing Bitcoin libraries as much as possible. We may need to provide additional tooling to support forking since we need to load state over HTTP(S), it may be possible with Electrs but requires further experimentation.

Is your feature request related to a problem? Please describe.
Sometimes is ideal to allow wallet to broadcast transactions instead of doing it in our end. So it is ideal to add this flag and just make inscribeData prepare the transaction and return it.

Describe the solution you'd like
Add flag that conditionally skips the execution of broadcast

Abstract

The BOB SDK is meant as a set of Solidity contracts, Rust and/or TypeScript functions, and UI components to access the unique functions of BOB and make developing new applications on BOB simple.

Motivation

BOB combines Bitcoin and EVM functionality into a coherent SDK to give anyone access to Bitcoin data, verification functions, account abstraction, and more. The SDK should it make easy for anyone to access to the BOB functionality.

Specification

BTC Relay and Libs

• Builders MUST be able to interact with the BTC relay contracts (documentation, Solidity libraries for Bitcoin types, ...)
• Builders MUST be able to verify transaction inclusion with the BTC relay, have an example implementation, and documentation to understand how it works
• Builders MUST be able to verify the inclusion of an ordinal, have an example implementation, and documentation
• Builders MUST be able to verify BRC20 deploy, mint, and transfer operations, have an example implementation, and documentation

Dev Tooling

• Builders MUST be able to use foundry to develop and deploy contracts on the rollup, see also bluealloy/revm#682
• Builders MUST be able to use remix to develop and deploy contracts on the rollup

UX Tooling

• Builders MUST be able to allow users paying fees in a bridged BTC deployed as an ERC20. Recommended is to use OpenGSN https://github.com/opengsn/gsn to achieve this with a deployment of OpenGSN for BOB.
• Builders MUST have an easy way to integrate OpenGSN into their contracts

Abstract

We propose a three milestone roadmap to deliver a Bitcoin-enhanced and OP Stack-compatible rollup for Bitcoin. The rollup allows builders to write Rust and EVM smart contract with native integrations for both Bitcoin and Ethereum data and assets.

Motivation

Rollups and bridges targeting Bitcoin should align with its core values: decentralization, scarcity, and immutability. While Ethereum is advancing with rollups as a core scaling solution, emphasizing user experience and privacy, Bitcoin lags in adopting experimental features due to its emphasis on security and resilience. Bitcoin's robust and defensive stance makes it harder to integrate innovations rapidly.

The BOB collective provides a solution to this problem. BOB core values are:

• Experimentation. Technology (rollups, ZK, AI, …), art (NFTs, …), organization (DAOs), and entertainment (social, …). We don’t close off BOB to areas but instead want a diverse space of innovators.
• Real-world impact. The innovations made should have an improvement for people by giving them access to Bitcoin values. BOB is an enabler to bring the BTC advantages to new and existing use cases.
• Freedom of choice. Projects deployed on BOB should also be able to deploy on other rollups and chains. Builders should focus on unique values of the product without having to worry about platform risk of BOB.

The technical product developed by the BOB collective follows from these values. BOB is three things:

1. A builder platform that allows anyone to create novel applications:
   • BOB supports Rust smart contracts. Bitcoin innovation (ord, LN, nostr, BDK) happens to a great deal in Rust, a mature and well-designed language. This allows innovation for new use cases without having to rewrite logic.
   • BOB is EVM-compatible. Novel applications and mature tooling already exist on EVM chains. Innovators can build on top of these applications. BOB seeks full EVM compatibility to provide freedom of choice and prevent re-inventing the wheel.
2. A novel BTC bridge that allows users and builders access to BTC and Bitcoin data (BRC20s, ordinals, …).
3. A rollup that allows users and builders access to ETH, ERC20s, and Ethereum data (NFTs, ENS, …).

BOB will be the catalyst for the “building on Bitcoin” renaissance. The movement combines the Bitcoin core values with new avenues of thought. BOB is a Bitcoin-augmented rollup for free experimentation and innovation with real-world impact.

Specification

The goal of this proposal is to launch BOB as a rollup before the Bitcoin halving 2024.

Milestone 1: Middle Ages

Deliver a proof of concept implementation of the BOB stack rollup and builder platform.

Target completion: End of September 2023

Goals

• Builders can spin up a local testnet
• Builders can deploy Rust smart contracts on the local testnet
• Builders can deploy EVM smart contracts on the local testnet
• Users can interact with a local testnet via EVM interfaces (wallets, ethers.js)
• Completed design for a novel Bitcoin bridge
• Alpha-stage documentation for the rollup design and how to build on it

Milestone 2: Early Renaissance

Deliver a testnet deployment of the BOB stack rollup, BTC bridge, and builder platform.

Target completion: Mid December 2023

Goals

• Public testnet is available to builders
• Builders can deploy Rust smart contracts on the hosted testnet
• Builders can deploy EVM smart contracts on the hosted testnet
• Users can interact with the hosted testnet via EVM interfaces (wallets, ethers.js)
• Block explorers available for hosted testnet
• Proof of concept implementation for Bitcoin bridge on testnet
• Beta-stage documentation for the bridge and rollup design and how to build on it

Milestone 3: Renaissance

Deliver a mainnet deployment of the BOB stack rollup, BTC bridge, and builder platform.

Target completion: Mid March 2024

Goals

• Public mainnet is available to builders
• Builders can deploy Rust smart contracts on mainnet
• Builders can deploy EVM smart contracts on mainnet
• Onboarded multiple teams to both testnet and mainnet
• Users can interact with the mainnet via EVM interfaces (wallets, ethers.js)
• Block explorers available for mainnet
• MVP implementation for Bitcoin bridge on mainnet
• Mature documentation for the bridge and rollup design and how to build on it