Introducing rosetta-bitcoin: Coinbase’s Bitcoin implementation of the Rosetta API

image

In June, we launched Rosetta as an open-source specification that makes integrating with blockchains simpler, faster, and more reliable. There are now 20+ blockchain projects working on a Rosetta implementation (Near, Cardano, Celo, Coda, Neo, Tron, Handshake, Oasis, Cosmos, Decred, Filecoin, Ontology, Sia, Zilliqa, Digibyte, Harmony, Kadena, Nervos, and Blockstack), five in-progress SDKs (Golang, JavaScript, TypeScript, Java, and Rust), and eight teams have made contributions to at least one of the Rosetta repositories on GitHub (rosetta-specifications, rosetta-sdk-go, and rosetta-cli).

Today, we are sharing a key contribution to this growing collection of implementations: rosetta-bitcoin.

You can read the remainder of the post on Medium.

We’ve made some updates to the rosetta-bitcoin repository to make it easier to test (unfortunately breaking the instructions for Construction API testing in the Medium blog). The new process is as listed below:

Try It Out

Enough with the talk, show me the code! This section will walk you through building rosetta-bitcoin, starting rosetta-bitcoin, interacting with rosetta-bitcoin, and testing rosetta-bitcoin. To complete the following steps, you need to be on a computer that meets the rosetta-bitcoin system requirements and you must install Docker .

First, we need to download the pre-built rosetta-bitcoin Docker image (saved with the tag rosetta-bitcoin:latest ):

curl -sSfL https://raw.githubusercontent.com/coinbase/rosetta-bitcoin/master/install.sh | sh -s

Next, we need to start a container using our downloaded image (the container is started in detached mode):

docker run -d --rm --ulimit "nofile=100000:100000" -v "$(pwd)/bitcoin-data:/data" -e "MODE=ONLINE" -e "NETWORK=TESTNET" -e "PORT=8080" -p 8080:8080 -p 18333:18333 rosetta-bitcoin:latest

After starting the container, you will see an identifier printed in your terminal (that’s the Docker container ID). To view logs from this running container, you should run:

docker logs --tail 100 -f <container_id>

To make sure things are working, let’s make a cURL request for the current network status (you may need to wait a few minutes for the node to start syncing):

curl --request POST 'http://localhost:8080/network/status' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data-raw '{
  "network_identifier": {
    "blockchain": "Bitcoin",
    "network": "Testnet3"
  }
}'

Now that rosetta-bitcoin is running, the fun can really begin! Next, we install rosetta-cli, our CLI tool for interacting with and testing Rosetta API implementations (this will be installed at ./bin/rosetta-cli ):

curl -sSfL https://raw.githubusercontent.com/coinbase/rosetta-cli/master/scripts/install.sh | sh -s

We recommend moving this downloaded rosetta-cli binary into your bin folder so that it can be run by calling rosetta-cli instead of ./bin/rosetta-cli ). The rest of this walkthrough assumes that you’ve done this.

We also need to download the configuration files for interacting with rosetta-bitcoin:

mkdir bitcoin_testnet;
curl -sSfL https://raw.githubusercontent.com/coinbase/rosetta-bitcoin/master/rosetta-cli-conf/testnet/config.json -o bitcoin_testnet/config.json;
curl -sSfL https://raw.githubusercontent.com/coinbase/rosetta-bitcoin/master/rosetta-cli-conf/testnet/bootstrap_balances.json -o bitcoin_testnet/bootstrap_balances.json;
curl -sSfL https://raw.githubusercontent.com/coinbase/rosetta-bitcoin/master/rosetta-cli-conf/testnet/bitcoin.ros -o bitcoin_testnet/bitcoin.ros;

We can lookup the current sync status:

rosetta-cli view:networks --configuration-file bitcoin_testnet/config.json

We can lookup the contents of any synced block (make sure the index you lookup is less than the index returned by the current index returned in sync status):

rosetta-cli view:block <block index> --configuration-file bitcoin_testnet/config.json

We can validate the Data API endpoints using the the check:data command:

rosetta-cli check:data --configuration-file bitcoin_testnet/config.json

This test will sync all blocks and confirm that the balance for each account returned by the /account/balance endpoint matches the computed balance using Rosetta operations .

Lastly, we can validate the Construction API endpoints using the check:construction command:

rosetta-cli check:construction --configuration-file bitcoin_testnet/config.json

This test will create, broadcast, and confirm testnet transactions until we reach our specified exit conditions (# of successful transactions of each type). This test automatically adjusts fees based on the estimated size of the transactions it creates and returns all funds to a faucet address at the end of the test.

I walked through this workflow and pasted the output of the logs during construction in my response to this question:

Hi Patrick,

I am trying to run the last two commands but after running:

rosetta-cli check:data --configuration-file bitcoin_testnet/config.json

the container seems to die and block syncing fails. The other checks pass but I get this error:

Error: unable to get next syncable range: unable to get network status: request failed: /network/status Post "http://localhost:8080/network/status": dial tcp [::1]:8080: connect: connection refused

I am interested in working on the wallet feature - so I am trying to learn about the api. Looking forward to hearing from you.

My Best,
Teo

Do you have any logs from this? My guess is that the container runs out of memory (see the section about Memory-Mapped Files):

Happy to dig in deeper one you provide a little extra info!

Hi Patrick,

Thanks for getting back to me. I tried using my mac and a [c5.2xlarge instance] but now I am trying on my wsl2 machine and my container is no longer dying. However, I am still having some issues with validating the data endpoints. I think it has something to do with the fact that the blockchain isn’t completely synced. It seems as though my percentage has been going down. It was around 99% then went down to around 66% after I re-ran the command for check:data. The test failed a few times (I can post the error when it happens again) but I just started it back up and now it seems to be progressing. My goal to understand the sdk so that I might be able to work on the wallet implementation fruitfully. Is this the right place to start? I am going to look through the examples folder while the blocks are syncing and continue looking through the Rosetta API docs. If you have any suggestions for how (where) I might focus my energy - I am all ears. I can post docker logs/ console logs but I didn’t know which you were after. Thanks again and talk soon.

My Best,
Teo

Our completeness estimate in rosetta-cli is pretty crude. It more or less calls /network/status periodically and computes a percentage synced using the returned height vs what is stored internally. When an implementation is syncing, the last synced height increases frequently, so the height rosetta-cli is using to measure completeness can get stale pretty fast (giving a false impression of progress).

Running rosetta-cli will definitely give you some bearings about how Rosetta works but the best place to look is probably the constructor package (the home of all our transaction construction logic):

I recommend taking a look at createTransaction (orchestrates the standard Rosetta Construction API flow):

Lastly, I also recommend taking a look at bitcoin.ros (an example of how we automatically generate test transactions for rosetta-cli check:construction):

The implementation for how we actually orchestrate construction testing may also help!

Sorry in advance that we don’t have better docs for helping people write generic Rosetta wallets! If you have any specific questions, don’t hesitate to post them.

Hi Patrick,

It seems as though the container has stopped syncing. The container logs are mostly post requests with the occasional

2020-11-27T18:26:07.398Z DEBUG bitcoind bitcoin/node.go:56 UpdateTip: new best=000000002d2ad442b998e6a3f859500f60b3ff28ff8c020f4ab747388a4010bb height=1895178 version=0x20000000 log2_work=73.011254 tx=58423801 date='2020-11-27T15:24:12Z' progress=0.999984 cache=2.3MiB(17356txo) warning='52 of last 100 blocks have unexpected version'

It seems like it has synced all blocks because the “tip” is close to what I found here: https://bitpay.com/insight/#/ALL/mainnet/home. However, now whenever I run the check:data command, it only runs for < 5 min until …

Reconciliation failed for tb1qhug0eranh5sy834mvh7mp6d6jlfav5wncyd95n at 892508 computed: 12199332tBTC live: 0tBTC
[MEMORY] Heap: 4236.452164MB Stack: 5.031250MB System: 8077.421570MB GCs: 18
2020/11/27 13:31:47 check:data status server shutting down
context canceled: cannot get network status[STATS] Blocks: 892508 (Orphaned: 0) Transactions: 10485439 Operations: 58353603 Reconciliations: 9061225 (Inactive: 3052115, Exempt: 0, Skipped: 10387474, Coverage: 35.400244%)


Error: reconciliation failure: active reconciliation error for tb1qhug0eranh5sy834mvh7mp6d6jlfav5wncyd95n at 892508 (computed: 12199332tBTC, live: 0tBTC)

The cli then outputs the following statistics

+--------------------+--------------------------------+--------+
|  CHECK:DATA TESTS  |          DESCRIPTION           | STATUS |
+--------------------+--------------------------------+--------+
| Request/Response   | Rosetta implementation         | PASSED |
|                    | serviced all requests          |        |
+--------------------+--------------------------------+--------+
| Response Assertion | All responses are correctly    | PASSED |
|                    | formatted                      |        |
+--------------------+--------------------------------+--------+
| Block Syncing      | Blocks are connected into a    | PASSED |
|                    | single canonical chain         |        |
+--------------------+--------------------------------+--------+
| Balance Tracking   | Account balances did not go    | PASSED |
|                    | negative                       |        |
+--------------------+--------------------------------+--------+
| Reconciliation     | No balance discrepencies were  | FAILED |
|                    | found between computed and     |        |
|                    | live balances                  |        |
+--------------------+--------------------------------+--------+

+--------------------------+--------------------------------+------------+
|     CHECK:DATA STATS     |          DESCRIPTION           |   VALUE    |
+--------------------------+--------------------------------+------------+
| Blocks                   | # of blocks synced             |     892511 |
+--------------------------+--------------------------------+------------+
| Orphans                  | # of blocks orphaned           |          0 |
+--------------------------+--------------------------------+------------+
| Transactions             | # of transaction processed     |   10485998 |
+--------------------------+--------------------------------+------------+
| Operations               | # of operations processed      |   58355145 |
+--------------------------+--------------------------------+------------+
| Active Reconciliations   | # of reconciliations performed |    6009125 |
|                          | after seeing an account in a   |            |
|                          | block                          |            |
+--------------------------+--------------------------------+------------+
| Inactive Reconciliations | # of reconciliations performed |    3054564 |
|                          | on randomly selected accounts  |            |
+--------------------------+--------------------------------+------------+
| Exempt Reconciliations   | # of reconciliation failures   |          0 |
|                          | considered exempt              |            |
+--------------------------+--------------------------------+------------+
| Failed Reconciliations   | # of reconciliation failures   |         25 |
+--------------------------+--------------------------------+------------+
| Skipped Reconciliations  | # of reconciliations skipped   |   10387474 |
+--------------------------+--------------------------------+------------+
| Reconciliation Coverage  | % of accounts that have been   | 35.399697% |
|                          | reconciled                     |            |
+--------------------------+--------------------------------+------------+

badger 2020/11/27 13:32:46 INFO: Storing value log head: {Fid:204 Len:36 Offset:1019459037}
Error: reconciliation failure: active reconciliation error for tb1qhug0eranh5sy834mvh7mp6d6jlfav5wncyd95n at 892508 (computed: 12199332tBTC, live: 0tBTC) . 

This is confusing to me because it seems to say 892511 blocks are synced and only syncs more after check:data in run. However, it exits after < 2min so I can only sync 2-3 blocks each time. I am wondering if there is a way to skip the reconciliation step until 892511 gets closer to the tip ie. 1892511.

Additionally, the check:construction command just outputs

[MEMORY] Heap: 334.067886MB Stack: 0.656250MB System: 467.971725MB GCs: 33
2020/11/26 21:05:03 waiting for implementation to reach tip before testing...

over and over. I am not sure what implementation to tip means but I am guessing it has something to do with the discrepancy between what check:data says block is 892511 and the docker container says block is 1895191. Thanks again for the help.

My Best,
Teo

Thank you for getting back to me. I am still trying to sync the chain but now, whenever I try to run the check:data command - I get this:

badger 2020/11/25 17:12:37 INFO: 8 tables out of 48 opened in 3.141s
badger 2020/11/25 17:12:41 INFO: 14 tables out of 48 opened in 6.874s
badger 2020/11/25 17:12:44 INFO: 20 tables out of 48 opened in 9.919s
badger 2020/11/25 17:12:46 INFO: 26 tables out of 48 opened in 12.247s
badger 2020/11/25 17:12:49 INFO: 36 tables out of 48 opened in 15.09s
badger 2020/11/25 17:12:53 INFO: All 48 tables opened in 18.982s
badger 2020/11/25 17:12:53 INFO: Replaying file id: 174 at offset: 173612671
badger 2020/11/25 17:12:54 INFO: [Compactor: 1] Running compaction: {level:2 score:1.0587986186146736 dropPrefixes:[]} for level: 2
badger 2020/11/25 17:13:13 INFO: Replay took: 20.0467462s
2020/11/25 17:13:14 Loading previously seen accounts (this could take a while)...

then it tries to sync blocks while sending post request for blocks which aren’t synced and fails… It is basically this

2020/11/25 18:12:36 pruned block 721296
2020/11/25 18:12:37 request failed: /block {"index":721628} unexpected EOF: retrying fetch for block {"index":721628} after 0.382691s (prior attempts: 1)
2020/11/25 18:12:37 request failed: /block {"index":721636} Post "http://localhost:8080/block": EOF: retrying fetch for block {"index":721636} after 0.586069s (prior attempts: 1)
[MEMORY] Heap: 5538.593796MB Stack: 31.250000MB System: 9653.745972MB GCs: 72
2020/11/25 18:12:46 pruned blocks 721297-721301
2020/11/25 18:12:46 request failed: /block {"index":721650} http: unexpected EOF reading trailer: retrying fetch for block {"index":721650} after 0.517860s (prior attempts: 1)
2020/11/25 18:12:48 request failed: /block {"index":721659} Post "http://localhost:8080/block": EOF: retrying fetch for block {"index":721659} after 0.487445s (prior attempts: 1)
[MEMORY] Heap: 5873.507828MB Stack: 31.250000MB System: 9653.745972MB GCs: 72

… it goes on like this until -

2020/11/25 18:14:11 request failed: /block {"index":721527} Post "http://localhost:8080/block": EOF: retrying fetch for block {"index":721527} after 2.226756s (prior attempts: 5)
2020/11/25 18:14:12 request failed: /block {"index":721750} Post "http://localhost:8080/block": EOF: retrying fetch for block {"index":721750} after 0.500653s (prior attempts: 1)
2020/11/25 18:14:14 request failed: /block {"index":721755} Post "http://localhost:8080/block": EOF: retrying fetch for block {"index":721755} after 0.698768s (prior attempts: 1)
[MEMORY] Heap: 7272.989044MB Stack: 36.062500MB System: 9653.745972MB GCs: 73
2020/11/25 18:14:23 request failed: /block {"index":721747} Post "http://localhost:8080/block": EOF: retrying fetch for block {"index":721747} after 0.389990s (prior attempts: 2)
2020/11/25 18:14:28 request failed: /block {"index":721749} Post "http://localhost:8080/block": EOF: retrying fetch for block {"index":721749} after 0.611365s (prior attempts: 2)
[MEMORY] Heap: 4265.651314MB Stack: 14.406250MB System: 9653.745972MB GCs: 74
2020/11/25 18:14:29 check:data status server shutting down
context canceled: cannot get network status[STATS] Blocks: 721496 (Orphaned: 0) Transactions: 9470665 Operations: 50217872 Reconciliations: 7892839 (Inactive: 2355200, Exempt: 0, Skipped: 9218811, Coverage: 36.016672%)
context canceled: cannot get network status[STATS] Blocks: 721502 (Orphaned: 0) Transactions: 9470773 Operations: 50223105 Reconciliations: 7895502 (Inactive: 2356118, Exempt: 0, Skipped: 9218811, Coverage: 36.028240%)


Error: unable to fetch block 721502: retries exhausted: block {"index":721502}: unable to sync to 1355636: unable to sync to 1355636

+--------------------+--------------------------------+--------+
|  CHECK:DATA TESTS  |          DESCRIPTION           | STATUS |
+--------------------+--------------------------------+--------+
| Request/Response   | Rosetta implementation         | FAILED |
|                    | serviced all requests          |        |
+--------------------+--------------------------------+--------+
| Response Assertion | All responses are correctly    | PASSED |
|                    | formatted                      |        |
+--------------------+--------------------------------+--------+
| Block Syncing      | Blocks are connected into a    | FAILED |
|                    | single canonical chain         |        |
+--------------------+--------------------------------+--------+
| Balance Tracking   | Account balances did not go    | PASSED |
|                    | negative                       |        |
+--------------------+--------------------------------+--------+
| Reconciliation     | No balance discrepencies were  | PASSED |
|                    | found between computed and     |        |
|                    | live balances                  |        |
+--------------------+--------------------------------+--------+

+--------------------------+--------------------------------+------------+
|     CHECK:DATA STATS     |          DESCRIPTION           |   VALUE    |
+--------------------------+--------------------------------+------------+
| Blocks                   | # of blocks synced             |     721502 |
+--------------------------+--------------------------------+------------+
| Orphans                  | # of blocks orphaned           |          0 |
+--------------------------+--------------------------------+------------+
| Transactions             | # of transaction processed     |    9470773 |
+--------------------------+--------------------------------+------------+
| Operations               | # of operations processed      |   50223105 |
+--------------------------+--------------------------------+------------+
| Active Reconciliations   | # of reconciliations performed |    5539384 |
|                          | after seeing an account in a   |            |
|                          | block                          |            |
+--------------------------+--------------------------------+------------+
| Inactive Reconciliations | # of reconciliations performed |    2356118 |
|                          | on randomly selected accounts  |            |
+--------------------------+--------------------------------+------------+
| Exempt Reconciliations   | # of reconciliation failures   |          0 |
|                          | considered exempt              |            |
+--------------------------+--------------------------------+------------+
| Failed Reconciliations   | # of reconciliation failures   |          0 |
+--------------------------+--------------------------------+------------+
| Skipped Reconciliations  | # of reconciliations skipped   |    9218811 |
+--------------------------+--------------------------------+------------+
| Reconciliation Coverage  | % of accounts that have been   | 36.028240% |
|                          | reconciled                     |            |
+--------------------------+--------------------------------+------------+

badger 2020/11/25 18:25:30 INFO: Storing value log head: {Fid:179 Len:36 Offset:302085069}
Error: unable to fetch block 721502: retries exhausted: block {"index":721502}: unable to sync to 1355636: unable to sync to 1355636.

Any ideas on what is going on?

Sorry for the delay here, @meyerhot!

This is a normal syncing log from bitcoind. No worries here!

You can disable reconciliation in the rosetta-cli-conf/testnet/config.json file by setting "reconciliation_disabled: true":

Your new config file would look like this:

{
  "network": {
    "blockchain": "Bitcoin",
    "network": "Testnet3"
  },
  "data_directory": "cli-data",
  "http_timeout": 300,
  "max_retries": 5,
  "max_online_connections": 1000,
  "tip_delay": 1800,
  "memory_limit_disabled": true,
  "compression_disabled": true,
  "construction": {
    "constructor_dsl_file": "bitcoin.ros",
    "end_conditions": {
      "create_account": 10,
      "transfer": 10
    }
  },
  "data": {
    "initial_balance_fetch_disabled": true,
    "reconciliation_disabled": true,
    "end_conditions": {
      "tip": true
    }
  }
}

That being said, it is concerning you got an active reconciliation error for tb1qhug0eranh5sy834mvh7mp6d6jlfav5wncyd95n. Would you mind retrying (with a clean data directory) on the newly released v0.0.8:

My guess is that you are hitting rosetta-bitcoin too hard (causing it to drop connections). You have 2 options:

  1. increase the instance size on the server running rosetta-bitcoin
  2. decrease max_sync_concurrency in the rosetta-cli configuration file

Hi Patrick,

I tried booting up a new GCP instance with the same specs as the c5.2xlarge instance except 32gb (double) of ram. Everything went smooth until block 1.3million. After this point block syncing was incredibly slow and sync speed fluctuated. Unfortunately, my instance also ran out of space (I only allocated 200GB). How much disk space did you allocate to your own instance?

I would really like to test out the construction API but with server costs of these large-ish instances around $8 a day, I would like to make sure I am not making any mistakes. When I look at this website - https://blockchair.com/bitcoin/testnet - it says the blockchain is less than ~30 GB’s however the blockchain (testnet) is clearly much larger than that. Do you know of any bitcoin-like blockchains with much smaller sizes? I really just want to test out the various construction endpoints to better understand the API and eventually implement the wallet. Towards this end, I am wondering if there are any pseudo-bitcoin blockchains that are more like bitcoin when it just started (less overhead). I may just try to implement rosetta on a blockchain I am currently building but I will keep you posted. Let me know if you have any ideas. Thanks for your support.

Teo

Hi Patrick,

I gave the machine 1TB and it finally tipped! I was able to finally run the construction test suite.

Unfortunately, I received an infinite loop. I am using the ros file from :

curl -sSfL https://raw.githubusercontent.com/coinbase/rosetta-bitcoin/master/rosetta-cli-conf/testnet/bitcoin.ros -o bitcoin_testnet/bitcoin.ros;

so I thought I would ask you about the issue. I was reading some other people were having issues like this but when I looked through the forums it seemed like they were using custom configs/ros files and or different blockchains all together. So, here is the error:

[MEMORY] Heap: 4002.510979MB Stack: 1.218750MB System: 4235.018059MB GCs: 4
2020/12/12 06:33:43 processing workflow "request_funds" for job "1"
2020/12/12 06:33:43 looking for coin {"value":"1000000","currency":{"symbol":"tBTC","decimals":8}} on account {"address":"tb1qxmzu9a80cc824mq7wv8h48nezcawjlal8pp724"}
2020/12/12 06:33:43 processing workflow "transfer"
2020/12/12 06:33:43 looking for coin {"value":"2400","currency":{"symbol":"tBTC","decimals":8}}
2020/12/12 06:33:43 waiting for available jobs...

just does this over and over again until I eventually quit out. I think I may make my own bitcoin.ros file but I would be interested in hearing your thoughts on the current behavior.

In other news, check:data either panic’d with a huge error that was longer than 1000 lines - this was the end:

goroutine 18840361 [select]:
net/http.(*persistConn).writeLoop(0xc012c5efc0)
	/usr/local/go/src/net/http/transport.go:2340 +0x11c
created by net/http.(*Transport).dialConn
	/usr/local/go/src/net/http/transport.go:1709 +0xcdc

or gave me too many of these:

2020/12/12 06:47:21 request failed: /block {"index":148054} Post "http://localhost:8080/block": EOF: retrying fetch for block {"index":148054} after 0.394289s (prior attempts: 1)

I turned down the max_sync_concurrency and increased the instance size but it didn’t seem to fix the issues.

Debugging aside, I was wondering if you might be able to connect - virtually - sometime in the upcoming weeks. I have really enjoyed learning about Rosetta and since I will be interning at Coinbase this summer, it would be awesome to hear more.

I look forward to hearing from you.

Teo

Apologize for the delay in responding here, @meyerhot!

We just released a new version of bitcoin-rosetta that syncs SIGNIFICANTLY faster than the version you are probably using and uses a little less space. Word of warning that this release requires a re-sync, so no need to upgrade if you are already at tip! For testnet we usually deploy 1-1.5 TB of data (we store historical balance records and maintain a coin index for each account).

I think there are 2 options here:

  1. Reach out to @sidhujag who has been working on a Bitcoin-like integration. I think a full sync and test of his integration may require less resources.
  2. Reach out to @stuart and @kashif who are working on a hosted version of the Rosetta API (like Infura): Lunar - Multichain Rosetta Node API

:rocket::rocket: Sorry for the troubles!

This will stop looping and start kicking off the testing once you deposit testnet funds here tb1qxmzu9a80cc824mq7wv8h48nezcawjlal8pp724. You may need to wait quite a few minutes for a testnet block to be mined (we don’t recognize any transaction in the mempool).

I spent a bit of time on the .ros file for Bitcoin and think it is pretty close to optimal. All ears for improvements though! Would be cool if the wallet you are thinking about building supports the DSL (so people can define complex transactions without your need to support every possible flow).

Ahhh yeah that’s due to overtaxing the node :frowning_face:. Turns out fetching GB/s of data (what the CLI does) tends to overload rosetta-bitcoin haha. We usually need to run a cluster of nodes to sync quickly.

Oh awesome!! Congratulations on landing an internship! You can reach out at patrick.ogrady@coinbase.com and we can set something up!

1 Like

Hey @meyerhot,

If you’re looking to build with Rosetta, but don’t feel like running a node, try lunar.dev. All testnet calls are free. We don’t have Bitcoin explicitly listed on our site atm, but we do have an open Bitcoin Testnet node running as we’re preparing for Bitcoin support on Lunar. You can query it using the network identifier…

{
    "network_identifier": {
        "blockchain": "Bitcoin",
        "network": "Testnet3"
    }
}

It’s still in beta, but you’re welcome to test it out. Feel free to get in touch.

1 Like

Hi Stuart,

Thanks for sharing this. What an awesome resource! I have been writing a few queries with my API key but haven’t been able to run tests automated tests because I need a header. Do you know of a way to get around this? I am thinking about modifying the sdk/server/routers.go and writing a header there but this seems like a hack. Thanks again for showing me lunar.

My Best,
Teo

So, I figured out how to add headers the right way but with lunar pro I get rate limited at 25 requests second. Is there any way to tell rosetta-cli to limit requests at 25/second? Maybe this is unreasonable but it would be cool to run tests even if they are slow.

Hi Stuart,

I wanted to reach out and ask whether you know of any issues there might be with running automated tests using lunar.dev. I am using my API key to run

rosetta-cli view:networks --configuration-file bitcoin_testnet/config.json

but receiving a 502 server error. I am wondering whether you knew of any immediate problems with this approach working with the lunar.dev endpoint?

Hey @meyerhot, if you’re trying to ping Lunar with the Golang Rosetta SDK, give the following a shot…

package main

import (
  "context"
  "fmt"
  "log"

  "github.com/coinbase/rosetta-sdk-go/client"
)

func main() {
  cfg := client.NewConfiguration("https://api.lunar.dev/v1", "go-demo", nil)
  cfg.AddDefaultHeader("X-Api-Key", "super-secret-key")

  c := client.NewAPIClient(cfg)

  response, rosettaErr, err := c.NetworkAPI.NetworkList(context.TODO(), nil)
  if err != nil || rosettaErr != nil {
    log.Fatalln("Failed with err:", err, rosettaErr)
  }

  fmt.Println("Supported networks:")
  for _, n := range response.NetworkIdentifiers {
    fmt.Printf("blockchain: %s, network: %s\n", n.Blockchain, n.Network)
  }
}

If you have any other questions, feel free to reach out on our telegram Telegram: Contact @lunar_dev.

Hi Stuart,

I have found a way to add the api key. I will definitely try yours though - it looks much more robust. I joined the telegram group but the page just shows the picture of the crescent moon - there is nowhere to write any messages. I don’t know what to do about the rate limiting though, 25 requests per second is forcing a shutdown and I haven’t investigated the exact number of requests that rosetta will max out at.