stacks-network / sbtc-bridge-api Goto Github PK

Add method to gather the users stx, sBTC, cardinal, ordinal balances.

Create two new docker containers for the testnet/mainnet signer api node express js application.

Deploys using deploy script in sbtc-bridge-api repo. Builds one image - the two containers differ only in the environment config.

Sets up routing via Linode DNS on the stx.eco domain.

Sets up reverse proxying via good old nginx.

Enables access to swagger api docs analogous to the bridge-api

Description
Client passes block height start (inclusive) and end (exclusive) to retrieve pending deposits

Acceptance Criteria

Exchange rates are pulled into the bridge api every 5 minutes to avoid rate limits and downstream cors problems. A fix is needed in the way the rates are updated internally.

Instructions: (see reddit post

1. bitcoin-cli createwallet "SBTC-0003" false true "secret" false true true false
2. bitcoin-cli -rpcwallet=SBTC-0003 walletpassphrase "secret" 60
3. bitcoin-cli -rpcwallet=SBTC-0003 getdescriptorinfo "tr(see reddit post/86'/1'/0'/0/*)"
4. bitcoin-cli -rpcwallet=SBTC-0003 importdescriptors "[{"desc":"tr(see reddit post/86'/1'/0'/0/*)#see reddit post","active":true,"timestamp":"now","range":[0,1000],"next_index":1}]"
5. bitcoin-cli -rpcwallet=SBTC-0003 getnewaddress SBTC-0003-ADDRESS-0001 bech32m

tb1pv0nehgmrq0rnlhfl87hwu6fts62tm7942qv0fjqgym6dr7739fksz4ajnt

Framework for signers to link real world identities to public keys via social proofs.

See GitBook for details

We need jobs in the api which run on a schedule to ready and parse mint/burn events from the sbtc contract. These events provide bitcoin transaction ids of sbtc wrap/unwrap transactions.

The data needs to be parsed into the local database for fast access to the bridge client.

Test and integrate the new asset contract and bitcoin clarity contract.

Docker compose can be removed completely since mongo-db has been moved out to Mongo Cloud and there is now only a single docker container running for the Bridge API.

Note: this issue impacts bridge api via build & deployment files.

See stacks-network/sbtc-bridge-web#103

The sBTC team has received a report the bridge-api is no longer building in devenv: stacks-network/sbtc#210 (comment)

 => ERROR [sbtc-bridge-api  9/10] RUN npm run build                                     4.3s
------
 > [sbtc-bridge-api  9/10] RUN npm run build:
0.720
0.720 > [email protected] prebuild
0.720 > npm run swagger
0.720
1.022
1.022 > [email protected] swagger
1.022 > tsoa spec
1.022
2.413
2.413 > [email protected] build
2.413 > tsc
2.413
4.285 src/routes/bitcoin/BitcoinRPCController.ts(56,67): error TS2339: Property 'btcSchnorrReveal' does not exist on type '{ mongoDbUrl: string; mongoUser: string; mongoPwd: string; mongoDbName: string; btcNode: string; btcRpcUser: string; btcRpcPwd: string; host: string; port: number; walletPath: string; network: string; ... 7 more ...; publicAppVersion: string; }'.
4.285 src/routes/bitcoin/BitcoinRPCController.ts(57,68): error TS2339: Property 'btcSchnorrReclaim' does not exist on type '{ mongoDbUrl: string; mongoUser: string; mongoPwd: string; mongoDbName: string; btcNode: string; btcRpcUser: string; btcRpcPwd: string; host: string; port: number; walletPath: string; network: string; ... 7 more ...; publicAppVersion: string; }'.
4.285 src/routes/bitcoin/BitcoinRPCController.ts(153,49): error TS2339: Property 'btcSchnorrReclaim' does not exist on type '{ mongoDbUrl: string; mongoUser: string; mongoPwd: string; mongoDbName: string; btcNode: string; btcRpcUser: string; btcRpcPwd: string; host: string; port: number; walletPath: string; network: string; ... 7 more ...; publicAppVersion: string; }'.
4.285 src/routes/bitcoin/BitcoinRPCController.ts(155,49): error TS2339: Property 'btcSchnorrReveal' does not exist on type '{ mongoDbUrl: string; mongoUser: string; mongoPwd: string; mongoDbName: string; btcNode: string; btcRpcUser: string; btcRpcPwd: string; host: string; port: number; walletPath: string; network: string; ... 7 more ...; publicAppVersion: string; }'.
------
failed to solve: process "/bin/sh -c npm run build" did not complete successfully: exit code: 2

I've bisected the build error to this commit: 44ccfe1

The tooling for generating merkle proofs needs to live in the 'sdk'

The risks of leaving the two apis in one service are that the app becomes too complex and also that deployments of one affects the other.

Creates a static deployment snapshot to support alpha

SBTC Bridge API requires support for peg in/out transactions using the OP_DROP mechanism.

Romeo engine uses p2tr function of the bdk crate to get the taproot address from a public key.

The lib uses btc package and encode function. With the p2tr function, the same taproot is created as Romeo engine.

See paulmillr/scure-btc-signer#60

Covers work needed in sbtc-bridge-lib/ - this library / module will contain methods for building and parsing transactions and payload data.

Pulls data from blockchain.com and caches it server side to avoid rate limits. Server this to ui over new endpoints.

Adding to track 4109.

In meantime reinstated the feature for sending op_return deposits via the bridge.

1. replace the bitcoin address in the form with your Electrum/Core address
2. copy the psbt hex/base 64
3. paste into Electrum / Core wallet - sign and send.

Description
Client requests reclaim;
API constructs the reclaim transaction
Client loops in wallet for user to sign and broadcast

Acceptance Criteria

The API currently uses mempool space to find UTXO sets for a given BTC address.

The application should not depend on external APIs. This can be achieved using a hosted utxo indexer. Potential options need to be evaluated;

• ElectrumX
• Hiro Mempool Service
• Bitcoin Sync

See https://github.com/stacks-network/sbtc/blob/master/sbtc-core/src/operations/op_return/deposit.rs

The main changes are the introduction of the principal type in the wire format.

Merge country data / symbols against currency data to fill in gaps in exchange rate data structure.

See stacks-network/sbtc-bridge-web#231

It's related to stacks-network/sbtc-bridge-web#80

In theory, we can add an additional parameter to our REST API, e.g. ?net=

Update endpont to work with new contract

property was removed by mistake from object returned by /init-ui end point

The Bridge API needs to be scalable. The main blocker to making it so right now is that the database is colocated, via docker compose, with the API node application.

Moving the mongo docker container to a managed service e.g. Mongo Cloud will;

1. provide scalability and high availability in the data layer
2. provide off the shelf db management and analytics
3. Provide an easy path to scaling the API node application

Simple Redis or mem cache is required to speed up the express server.

End points like this https://testnet.stx.eco/bridge-api/v1/sbtc/data which simply read fairly static data from the contract are great candidates for caching.

We need two api instances running for the bridge.

Eg. Testnet: https://bridge.stx.eco/bridge-api/testnet/v1/btc/wallet/listwallets
Eg. Mainnet: https://bridge.stx.eco/bridge-api/mainnet/v1/btc/wallet/listwallets

Each instance is built from the same docker image but injected with configuration specific to the network for bitcoin and stacks nodes and the mongo db.

Achieves unified build / deployment and CI process

1. Deploy the docker API container to GCP (the type of service GKE vs E2 instance will be determined by pricing)
2. Trigger deployment on merge PR to staging branch.
3. Remove build dependency on Docker Compose.
4. Set up local blockchain services, Bitcoin Testnet (full node), Stacks Testnet (full API node)

Note PR 21 moved the mongodb container to Mongo Cloud so there is no longer any need for docker compose.

An sBTC RPC-API exposing the following endpoints for the sBTC Stacks-Signer Management Tool and other dApps:

see https://www.notion.so/stacksfoundation/5fff936c663545109cb83671fa03cdf3?v=f4a45049d614417d812f09c80565566e&p=53c1f123e2b349cf8c8e21ee61302b01&pm=s

• Zero-Knowledge Proof of Reserves:
  • Including Stacks-Signer identity (zkPublic)
  • Concentration of funds
  • Signer deposits and withdrawals
• Protocol Governance:
  • Casting votes
  • Propose elections (related to sBTC script security, fee recovery parameters, and Nakamoto release related block production rules)

Request for endpoints;

See this summary of requirements for the Signer Dashboard API .

Any that are missing can be added here?

The withdraw payload require the length of the data payload to prefix the data.

See the spec here for details

See also

Linked to this issue stacks-network/sbtc#230

Mempool api on bitcoins regtest network does not support the /:address/utxo endpoint

The bridge api requires this endpoint to read utxo's to build PSBTs.

This means that to work on regtest the bridge api must either;

1. connect to a full node indexer directly (electrs, electrum etc) running locally
2. or build the UTXO set by first importing the address into Bitcoin core

Running the indexer locally has proven challenging. Electrs is included in the devenv local network for the sBTC project but this has proven unstable.

The Leather wallet also requires the /utxo endpoints and so the solution for the Bridge api needs to be consistent with that for the wallet.

Note: Leather looks for endpoints like /:address/utxo on port 3002 for sBTC local network or port 18443 for the devnet local network.

A shared public devnet will be helpful to efforts to build the sbtc signer web app and related apps.

Need to clone the bridge API into a clean Signer API microservice.

Basic setup should include, out of the box;

• express js
• support for swagger api docs
• websocket connections
• mongo db

Swagger is required to describe the API.

Remove dependencies form the API on the BitcoinJS library in favour of btc-secure-signer.

Bridge API requires the ability to broadcast raw bitcoin transactions. This supports using Hiro Web Wallet to sign PSBTs.

See stacks-network/sbtc-bridge-web#54

This withdraw transaction fails because the stacks address does not match the senders stacks address.

The incorrect stacks address has 0 balance and the burn (ft-burn?) fails with error u1 - insufficient balance.

The bridge may be encoding the stacks address / signature data incorrectly ?

The fulfillment_fee_output should be set in 3rd output of withdraw transaction.

For op_return this is a dust payment that allows the coordinator to see withdrawal requests.

Run bitcoin testnet and mainnnet on single debian vm to reduce cost.

Description
Client app requests challenge;
passes address to API
API returns challenge data
UI provides wallet integration to send stacks tx

Acceptance Criteria

The api runs in several environments;

1. local development against local / remote stacks / bitcoin regtest
2. local development against local / remote stacks / bitcoin testnet
3. remote regtest (e.g. shared devenv)
4. remote testnet
5. remote mainnet

The configuration during devenv development period became unwieldy.

Some work is needed on the way amounts are converted to buffer for wire format transfer.

Includes unit tests for building and parsing deposit/withdrawal payloads.

Goal is to set up a full localhost environment for running sBTC.

This issue deals with running the sBTC Bridge and Signer Dashboard on localhost against the Clarity contract using Clarinet Integrate.

The Coordinator and Signer binaries are side stepped.

A library module is required for defining the types and functions common to both the Bridge web and API applications.

See stacks-network/sbtc-bridge-web#133

Expects reveal subsidy in the payload.

The reveal public was necessary to mock out the back end in the early days of development and is no longer needed.

The reclaim public key provided a way to make custodial reclaims for deposit commit/reveal transactions which didn't make it into the peg wallet - according to the spec these stray deposits could be reclaimed after 144 blocks. This key is no longer necessary as the user can now sign with their ordinal public key instead to initiate reclaim.