Recovering access to a node

One of the core benefits of Greenlight over self-hosted nodes is the ability to separate the state management in the form of the node database from the authorizing party, i.e., the Signer. This allows users to seamlessly recover access to their node in case of a boating accident, by simply proving ownership of the private key that corresponds to that node.

In order to recover access all you need to do is recover the seed from the BIP39 seed phrase and initialize the Signer with it:

RustPython

let seed = read_file("seed");
let network = gl_client::bitcoin::Network::Bitcoin;
let creds = Nobody {
    cert: nobody_cert,
    key: nobody_key,
    ..Nobody::default()
};

let signer = gl_client::signer::Signer::new(seed, network, creds.clone()).unwrap();

let scheduler =
    gl_client::scheduler::Scheduler::new(gl_client::bitcoin::Network::Bitcoin, creds)
        .await
        .unwrap();

scheduler.recover(&signer).await

seed = read_file("seed")
network = "bitcoin"
signer_creds = Credentials.nobody_with(developer_cert, developer_key)
signer = Signer(seed, network, signer_creds)

scheduler = Scheduler(
    network,
    signer_creds,
)

scheduler_creds = signer_creds.upgrade(scheduler.inner, signer.inner)

scheduler = Scheduler(
    network,
    scheduler_creds,
)

scheduler.recover(signer)

Notice that we are using a TlsConfig that is not configured with a client certificate and key, because that's what we're trying to recover. In the background the scheduler instance will contact the Scheduler service, retrieve a challenge, sign that challenge with the signer, and then call recover with that proof signature. The Scheduler will then check the challenge-response passed to recover and if successful, generate a new certificate for the client, which will provide access to the node.

Important

Remember to store the device_cert and device_key from the result so you can load it next time you want to interact with the node.