General Operations

Common tasks, activities, and management of nodes across

Peer to Peer Activities

Peer to Peer Activities

How would I be able to check the amount of other peers connecting to my relay node?

You can run a netstat query on the command line with the following code:

netstat -anp | grep cardano-n | grep :<port> | wc -l

Just remember to replace <port> above with your port number

How do I convert pooltool addresses to bech32?

You can add e1 to the front of the address and then using the bech32 command to convert them.

For example:

Address on pooltool.io shows owner as: a2b2bba2c50e6d52e9cefe863ba1a4bb3afeec5fa592c3d2932d1fdc

$ bech32 stake <<< e1a2b2bba2c50e6d52e9cefe863ba1a4bb3afeec5fa592c3d2932d1fdc
stake1ux3t9wazc58x65hfemlgvwap5jan4lhvt7je9s7jjvk3lhqv7vagp

Bech32 command can be built with stack and is available on github: https://github.com/input-output-hk/bech32


*Answer to this question found and by Andrew Westberg on JorManager Users telegram channel

General Linux Management

General Linux Management

How do I create a new sudo-enabled user on my linux system?

Introduction

It is best practice, and under some circumstances - like those who deploy using the Guild operators scripts - to operate your node as a user that is not "root", but rather as a different but sudo-enabled user. This is a form of security that makes it more difficult for a hacker to try and break into the server system. Moreover, depending on where you host your server node you may find that your VPS provider only allows root access via a proprietary console which you access via the browser through their own portal using two-factor authentification, and so on.

The sudo command provides system administrators with a way to grant administrator privileges — ordinarily only available to the root user — to normal users.

In this tutorial, you’ll learn how to create a new user with sudo access on Ubuntu 20.04 without having to modify your server’s /etc/sudoers file.

Step 1 - Log in to Your Server

SSH into your server as the root user:

Or log in without an ssh client via the browser console provided by your VPS if you cannot access this publicly. Please check your VPS provider's FAQ or help section on how to log in as the root user their way.

ssh root@your_server_ip_address

Step 2 - Add the New User

Use the adduser command to add a new user to your system:

adduser johnny

Be sure to replace johnny with the username that you want to create.
It is even better practice to use a username that is hard to guess too. Like eden_lost_bc_22930, for example.

The underscore character is allowed as part of the username rules - along with digits. More info on this.

You will be prompted to create and verify a password for the user:

OUTPUT:

Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Subsequent to this you will be prompted to fill in some information about the new user.
It is fine to accept the defaults and leave this information blank:

OUTPUT:

Changing the user information for johnny
Enter the new value, or press ENTER for the default
    Full Name []:
    Room Number []:
    Work Phone []:
    Home Phone []:
    Other []:
Is the information correct? [Y/n]

Step 3 - Adding your New User to the sudo Group

Use the usermod command to add the newly created user to the sudo group:

usermod -aG sudo johnny

Step 4 - Test sudo Access for Your Newly Created User

To test that the new sudo permissions are working, first use the su command to switch to the new user account:

su - johnny

You will then be switched over as the current user in the session on your terminal with a prepend to the command line looking something like this: johnny@server_name:~s

As the new user, verify that you can use sudo by prepending sudo to the command that you want to run with superuser privileges. For example:

sudo ls -la /root

The system may ask you for your password to execute sudo commands:

OUTPUT:

[sudo] password for johnny:

Note: This is not asking for the root password! Enter the password of the sudo-enabled user you just created.

For Cardano Node Operators, those that installed the cardano node as root, you might find the output from the sudo command above (sudo ls -la /root) looking something like this:

OUTPUT:

johnny@some_server:~$ sudo ls -la /root
[sudo] password for johnny:
total 116
drwx------ 12 root root  4096 Sep  8 16:30 .
drwxr-xr-x 18 root root  4096 Jul 29  2020 ..
-rw-------  1 root root 16252 Dec  8 18:55 .bash_history
-rw-r--r--  1 root root  3492 Jul 30  2020 .bashrc
drwxr-xr-x  6 root root  4096 Jul 30  2020 .cabal
drwx------  2 root root  4096 Jul 29  2020 .cache
drwx------  4 root root  4096 Aug  9 01:15 .config
drwxr-xr-x  2 root root  4096 Jul 31  2020 downloads
drwxr-xr-x  6 root root  4096 Jul 30  2020 .ghcup
drwxr-xr-x  3 root root  4096 Sep  8 14:22 git
-rw-r--r--  1 root root 35791 Sep  8 16:23 gLiveView.sh
drwx------  3 root root  4096 Jul 29  2020 .gnupg
drwxr-xr-x  3 root root  4096 Jul 30  2020 .local
-rw-r--r--  1 root root   161 Dec  5  2019 .profile
-rw-r--r--  1 root root    66 Aug  4 20:21 .selected_editor
drwxr-xr-x  2 root root  4096 Jul 30  2020 .ssh
drwxr-xr-x  2 root root  4096 Jul 30  2020 tmp
-rw-r--r--  1 root root   180 Sep 26 23:18 .wget-hsts

If you did install the Cardano node as user root we recommend you transfer all the permissions on this node over to your new user so as to avoid the security implications of continuing as the root user when operating on your server.

 



This answer was published on 30 January 2021


https://cutt.ly/zkrNgly

 

General Linux Management

How do I change ownership of files and directories from root user to another user on my node?

Introduction

This issue was experienced by many new pool operators who built their nodes using the Guild Operators scripts to build their nodes as a root user on their Linux server. This had the consequence that all their files and folders under the CNODE directory were owned by root and was not usable after the upgrade to CNTools 6.0.3

Parts of this answer is a transcript of Damien Ostrelith's YouTube video (from about minute 5:00) on how to resolve this problem.

Step 1 - Open a terminal session and change to the directory where the Cardano node resides

In CNtools this is under /opt/cardano:

cd /opt/cardano

Step 2 - Perform the chown command on the command line

sudo chown -R node:node cnode/

Remember to replace node with the username you chose or use on your system.

Step 3 - Check to see if the folders and files are now changed to the new username

ls -al

If everything looks fine the change of ownership was successful and complete.



 

This answer was published on 30th January 2021

 

Shortcut URL to this answer:

https://cutt.ly/EktOsMr

 

General Linux Management

How do I see what Cardano Processes are Running on my Node's Server

Introduction

Sometimes when monitoring our system's health we use the htop command. But sometimes we just want to filter all the processes related to just Cardano to check to see if they are working.

Step 1 - Issue the htop command

htop

Step 2 - Filter the list of htop

Press the F4 command on your keyboard.

Your terminal will now show a footer displaying the "Enter", "Esc" and "Filter" commands.

Navigate to the "Filter:" field and type in "Cardano"

Enter (Done)	Esc (Clear)		Filter: Cardano

This answer published on 30 January 2021

 

Short URL to this answer:

https://cutt.ly/lktPajA

 

 

 

 

 

General Linux Management

How do I improve my OpenSSH security on my node?

Introduction

OpenSSH is a very useful tool for remote Linux administration by Stake Pool Operators. However, it's also a very popular attack vector for outside threats.

This answer is based on LearnLinuxTV's video on 3 Important Tweaks for Improving OpenSSH Security on Your Cloud Instance:

To demonstrate why we would want to harden the ssh on our server all we need to do is check the multiple attempts various third-party actors run to break into the server. To check a log of the attempts to break in all you need to do is execute the following command after logging into your server:

sudo cat /var/log/auth.log |grep root

It is unlikely that your server will have no failed attempted logins by third-party actors who may be deliberately or inadvertently trying to login to your server. Usually as the root user.

How do go about securing our server?

Step 1 - SSH with root login

SSH into your server as the root user:

Or log in without an ssh client via the browser console provided by your VPS if you cannot access this publicly. Please check your VPS provider's FAQ or help section on how to log in as the root user their way.

ssh root@your_server_ip_address

Step 2 - Add a New User and Check Permissions

We need to create a new system user with admin privileges to avoid having the problem of logging yourself as root user during your setup.

This step can be followed at this link (an answer already made on this site): https://cutt.ly/zkrNgly

Step 3 - Add ssh Key to Your New User

If you are still logged in as root switch over to the new user you created:

su - johnny

Remember to substitute johnny for whatever name you used as the new user on your system.

Let's check what files and folders (including hidden ones) reside in our home directory

cd ~
ls -al

It is most likely after creating your new user that there will not be a .ssh directory. This directory is the folder that will hold our ssh keys in a specific file called "authorized_keys". We create the directory and edit the authorized_keys file.

mkdir .ssh
cd .ssh
nano authorized_keys

Now, copy-paste your SSH key into the file and CTRL+O to write the file out and CTRL + X to close the file.

Step 4 - Disable root User Login

sudo nano /etc/ssh/sshd_config

This file will open with various parameters for our SSH configuration. One of them includes the "PermitRootLogin" parameter. We want to change that parameter from "yes" to "no".

OUTPUT EXAMPLE:
-----------------------------------------------------------------------------------------------------------------


#       $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

-----------------------------------------------------------------------------------------------------------------
ETC...

Change the parameter to look like this

PermitRootLogin no

For this change to take effect you need to restart the ssh service

sudo systemctl restart ssh

Then check the ssh status

sudo systemctl status ssh

Step 5 - Disable Password Authentification

Make sure you have verified that you can log in using ssh authentication before continuing on this step!

sudo nano /etc/ssh/sshd_config

Change the parameter #PasswordAuthentication yes to this PasswordAuthentication no. Remember to remove the "#" hash prepend and change "yes" to "no".

Close the file and then restart ssh again.

sudo systemctl restart ssh

Step 6 - Change SSH Port from 22 to Another Port Number

sudo nano /etc/ssh/sshd_config 			#change ssh port 22 to something else
sudo systemctl restart ssh
sudo systemctl status ssh

For example, change the parameter from #Port 22 to Port 9509.
Remember to remove the "#" hash prepend when editing this parameter!

You can check that the port is correctly configured:

sudo netstat -tulpn |grep ssh

If netstat does not work you can install it using this command:

sudo apt install net-tools

If you are interested, you also check all ports that are open on your server using this command:

sudo netstat -tulpn

Step 7 - Optional step. Restrict Users on System

sudo nano /etc/ssh/sshd_config 			#change AllowUsers to include the usernames you restrict to log on

Edit sshd_config to include a line that restricts which users can log on. For example: AllowUsers johnny

sudo systemctl restart ssh
sudo systemctl status ssh

Be careful with this step as if you mistype the allowed users you will be locked out of your server definitively!

You can always check to see what has been going on regarding the login sessions on your server using this command

sudo cat /var/log/auth.log

 



This answer was published on 02 February 2021


https://cutt.ly/ekdK4BP

 

General Linux Management

What are some tips for my node's server security?

Introduction

During the course of being a Linux admin, some tips for securing your server comes to mind.
Below we share some of our tips that we have learned over time.

Tip 1 - Secure your SSH login with Public/Private Keys

We recommend you look at this YouTube tutorial to cover this common practice of securing your server with SSH using public and private key pairs. This video also helps show how to use the popular PUTTY utility to do most of the hard work for you.

Tip 2 - Change your SSH port from 22 to another figure

This is a parameter that can be changed in the sshd_config of your node server.
IMPORTANT: remember to change your ufw firewall rules or you will be locked out

Tip 3 - Disable root access

This is another common used parameter while administering your node's server.
Disable ssh root access in the sshd_config file:

PermitRootLogin no

Be careful exercising this parameter. Make sure you do not lock yourself out. Make sure you have another sudo enabled user on your system to get access to the server once root login has been disabled!

Tip 4 - Remove Password Authentication Method

Use the private/public key ssh authentication method mentioned above. In your ssh_config file edit these parameters:

PasswordAuthentication no

ChallengeResponseAuthentication no

Tip 5 - Don't Allow Empty Passwords (*optional)

In your ssh_config file edit this parameter:

PermitEmptyPasswords no

Totally optional - this is just to allow our node server to reject potential attempts to log in to our server with empty passwords. Reduces any minimal impact on server load if a persistent DOS attack is undergoing. This is so small an effect on server performance you could totally ignore changing this parameter though.

Tip 6 - Set Maximum Authentication Retries

In your ssh_config file edit this parameter:

MaxAuthTries 3

Totally optional - we use 3 but you can leave it at 5 which is the usual default

Tip 7 - Set Maximum Sessions (*optional)

In your ssh_config file edit this parameter:

MaxSessions 2

Totally optional - this can be left at its default setting. However, we like to minimize active sessions to harden our node's security and performance.

Tip 8 - Install and Configure Fail2ban (*optional)

In this tip idea we suggest you follow this video tutorial (about 12 minutes in length) as a guide to harden your server's security.

Fail2Ban helps to protect servers against unauthorized access attempts and brute-force attacks. This tutorial shows you how to install and configure Fail2ban to secure your server.

Tip 9 - Build your Firewall Policy

UFW is a firewall wrapper service on Linux. This a further layer of security that can be added to your node. The following video is a guide to the general administration of this extra layer.

We also recommend you follow Damien Ostrelich's tutorial on setting up your node on this topic:

And revisited in another, but subsequent video to the one above, in this video tutorial:

 



This answer was published on 03 February 2021


https://cutt.ly/zkgM0ET

 

Updating and Migrating the Node Database

Updating and Migrating the Node Database

How do I copy the database from one node over to another node?

Introduction

When we deploy new nodes or have to completely redo one from the ground up we could make a copy of an existing database and have a copy of that be transferred to our new node to mitigate all the time and server resources it would take to sync the database from epoch 0.

Step 1 - Stop our source node

Let's start by stopping our node from where we will make source the database

sudo systemctl stop cnode.service

Step 2 - Move over to Database and do some preparation

We need to change over to our db folder under our cardano node

cd db			#Or wherever you have chosen to store your files and folders
ls

You should see something like this:

OUTPUT:

immutable  ledger  lock  protocolMagicId  shelley_trans_epoch  volatile

Step 3 - Remove the contents of the ledger directory

rm -rf ledger/*		#Remove everything in the ledger dir using the options of -rf (recursively, force)

Step 4 - Restart the node

sudo systemctl start cnode.service

Let the database sync again before we stop the node again.

How do we know when the database is synced on the blockchain? To answer that you can follow the steps by Damien Ostrelich of EDEN pools in his YouTube tutorial:

Or you can copy paste his instructions here:

cd ../logs
tail -f node0.json

The output shows the db syncing in real time.

But we want to filter the output to show us only those lines that cnoptain the "contents" parameter

tail -f node0.json | grep "contents"

The lines on output will now only show those lines that contain the "contents" parameter (usually highlighted in red). The contents parameter is an indicator of the amount of db synced and we need to wait till the subsequent indicator after the "contents" word in the line reaches 100 (100%). See video above to see this in real time.

Step 5 - Stop the node (again) and take a snapshot

Once the node sync contents are 100% we stop the node

sudo systemctl stop cnode.service

Compress a copy of your database (this will take some time)

cd ..
tar -czvf db_snapshot.tar.gz db/

Once the snapshot (the compressed file completed) we restart the node

sudo systemctl start cnode.service

Step 6 - Copy the compressed database over to your new node

This step can be done to your liking. Either by transferring using an app like FileZilla to download the file and reupload to your new server. Or, you can do the transfer from the command line and login to the new server using ssh and do a direct server to server transfer. We leave this step up to you.

Step 7 - Stop your destination node

sudo systemctl disable cnode.service
sudo systemctl stop cnode.service

Step 8 - Rebuild node software as if you are updating the node upgrade

This is the common procedure of upgrading your node software and binaries. You do this as you would any other normal upgrade and instructions on this are skipped since this is covered multiple times in answers on CardanoFAQ.

Step 9 - Replace database after Cardano node is updated and upgraded

Decompress (extract) the db_database.tar.gz file you uploaded into the directory holding the db directory. First we backup the existing database in case we need to roll back for whatever reason.

cp -r db/ db-backup/

Remove the database

rm -r db

Extract the database tar file

tar -xzvf db_snapshot.tar.gz

This will recreate the db folder with all of its contents

Step 10 - Restart the cnode service

systemctl enable cnode.service
systemctl start cnode.service
systemctl status cnode.service

Step 11 - Check to see the database is syncing to the network

Here we can open our gLiveView utility and just check that it is syncing and working again.

That should be it!

 


Links used in this answer:

Damien Ostrelich's YouTube tutorial on this issue: https://youtu.be/4CxYezEvFnY


This answer was published 02 Jan 2021

Block Production

In this chapter, we explore the underlying theory behind what and how blocks reproduced on the Cardano blockchain. This includes the Ouroboros Praos protocol and how transactions are validated.

Block Production

What are slot battles?

Introduction

Slot battles occur when a slot has been assigned to be processed by more than one pool at a particular allotted time during the course of an epoch. In this answer, we want to provide a more in-depth discussion of the context and consequence of the occurrence of slot battles.

Many of the themes found below are drawn across many resources from both the Telegram groups and Cardano docs and we hope to be able to credit all the themes to the correct original author's original publication.

Context and background information

If you are new to the process of how a blockchain works we recommend that you read the Cardano Foundation's GitHub article on "Producing New Blocks". In that article important ideas are issued including:

Slot Battles: a feature or anomaly of the Cardano network design?

From the outset, we need to understand that slot battles are a feature of the Cardano network protocol and not some anomalous error that has been inadvertently created whilst designing the protocol.

The Cardano network protocol has been designed to thwart the potential of DDOS (Distributed Denial Of Service) attacks. To that end, the engineering of the protocol meant that each network pool (also called "validator" in other blockchains) that gets assigned a schedule to process or validate blocks does so independently of the knowledge of any other pool's block processing schedule. A pool's schedule - also called a "leader log" - is a timestamped event where a pool is responsible for the processing of one of the slots (or blocks) to be added to the blockchain. Slots occur every second. On average a slot gets filled by a block every twenty seconds under the Cardano network protocol.

The allocation of leaders to produce blocks in slots for each pool that qualifies to process or validate blocks is determined via a lottery event using the Ouroboros Praos Proof-of-Stake VRF function.

The slot leader schedule is determined by each block producing node running its own local private lottery for each slot, and when it wins the lottery it can prove to everyone else that it did so legitimately and fairly and so it is indeed allowed to produce a block in this slot.

- Daniel Coutts in "Why does Ouroboros Praos introduce slot leader sets? - Reddit"

Each pool that qualifies to process blocks on the network has to have a valid operational node certificate and they need the Ouroboros VRF key pair to control the participation in the slot leader selection process.

A VRF key pair (or Verifiable Random Function Key Pair) is a cryptographic function that processes inputs and produces verifiable pseudorandom output. (A discussion of the VRF functions is beyond the scope of this answer for now.)

For further information on this crucially important function for the Cardano blockchain please check out these resources:
-
Generating Randomness In Blockchain: Verifiable Random Function
-
Boston University's Verifiable Random Functions (VRFs) Paper
-
Ouroboros Verifiable Random Function

For an excellent discussion on why Ouroboros Praos introduces slot battles click here to read a great discussion on Reddit.

The lottery event in conjunction with the VRF keys creates a potential universe of assignable slots to any pool as a function of the amount of ADA staked and pledged to that pool.

It occurs with some frequency that one pool may have a slot assigned to them that coincides with another pool's schedule of slots. However, the results of the lottery event, to assign the number of blocks any pool may accrue, and the schedule thereof, is done in such a way that a pool is ignorant of any other pool's slot schedule. Pools schedules overlap on the fringes. It is those overlapped schedules that result in two pools getting themselves involved in a "slot battle".

See also this discussion on how often slot battles may occur on Telegram:

FROM:

Homer J (AAA) in Cardano Stake Pool Best Practice Workgroup
If it's a multi leader slot battle it's 50/50 roughly on the outcome but chances of even being involved in one such battle are on the low side, maybe 5%
t.me/CardanoStakePoolWorkgroup/364143

The way slot battles resolve

Prior to the launch of the Shelley Mainnet, during the Incentivised TestNet, the resolution of slot battles was determined either by how fast the pool's node propagated its block onto the network or by which pool had the lowest VRF result. However, the speed by which a pool propagated its block to other nodes on the network had the undesired effect of having the network conglomerated around high-speed network centres in the world (during the ITN one of those centres being Germany). So, in the end, the protocol chose to exercise priority (but not exclusivity - see below) to the pool that had the lowest VRF hash result to process and validate a block.

Subsequent to the launch of the MainNet a pool involved in slot battles would have a measure of their VRF hash made and the lower one would usually win. Pools that have a higher amount of ADA pledged and staked would often have a higher VRF hash whereas pools that had a lower amount of ADA staked or pledged would reveal a lower VFR hash.

A discussion on Telegram gives a more plain version of the process of the slot battle:

FROM:

Cardano Stake Pool Best Practice Workgroup
Forwarded from Luis Restrepo
... if you have the correct vrf loaded, bp node will try to produce all slots according to schedule. As long as the block doesn't align with BFT overlay schedule that is. If slot happens to align with BFT, node will report slot as not leader. In the case of slot battle both community pools will make the block and start propagating it through the network. Lets say node A create a block for slot X. And node B also create a block for slot X. Node C receives block from node A first and all that have a connection to node C pulls this block from node A. But then block from node B arrive at node C, and node B happen to have a lower VRF output for this slot than node A. Node C will then switch and put block from node B on tip instead. Its not that complicated but hard to express in a good way in words. Depending on how fast the blocks from each node in a slot battle propagate and who has the lowest VRF, they will spread differently before they are "killed off". Pooltool has a node listening for these blocks but if the loosing block is killed off before reaching pooltool node it will never end up in the orphaned table on pooltool. This is why you see some but not all orphaned blocks, depending on how fast you manage to get your block to pooltool node.
t.me/CardanoStakePoolWorkgroup/365672

Also, on the subject of which pool is the victor in a slot battle:

FROM:

Adam Dean in Cardano Stake Pool Best Practice Workgroup
I've lost some pretty low-stake slot battles, the smaller pool is the "favorite" for them but is not the guaranteed victor
t.me/CardanoStakePoolWorkgroup/390735

Lower VRF hash of a pool wins the battle most often

To understand why a pool with a smaller staked and pledged amount of ADA wins a slot battle more often than not over a pool that has a higher stake or pledge of ADA we can run an analogy. Imagine a dice with 100 sides. Each side represents the possibility of minting a block. The two pools in a slot battle run the dice to see who gets the privilege of minting the block. However, the bigger pool, which has been granted, for example, the privilege of minting 20 blocks has then a roll of the dice where it always lands on a number between 1 and 20. The competing smaller pool has, for example, been granted 3 blocks to mint during the epoch. This pool then gets the dice where it always falls only between 1 and 3. Since the likelihood that the bigger pool will most likely fall on a number bigger than 3 then the smaller pool is a favourite to win the slot battle.

FROM:

Adam Dean in Cardano Stake Pool Best Practice Workgroup
Basically, big pool has to roll a 20 or lower on a d100 to get a slot so their value may be between 1-20, whereas a small pool has to roll a 3 or lower to get a slot so their value may be between 1-3, there's always a chance that the smaller pool rolls a 3 and the big pool rolls a 1 or 2, but the odds favor the small pool if both rolled the same slot
t.me/CardanoStakePoolWorkgroup/365684

 

Last word

This answer was written up in response to allay the fears that delegators of a pool who suffered a loss of a slot battle may feel their pool is not operating at its most optimal. It may seem counterintuitive that a superbly performing or large pool can lose a slot battle to a lesser pronounced or smaller pool out there. But the protocol allows for this to happen and it is not necessarily related to the actual performance of the physical pool node or operator running that node!

If the reader has made it to this portion of the answer then they will realize that the result of a slot battle is less about how fast a pool propagates its block on the network, server network latencies, and other physical metrics of a pool. The success of battle has more to do with cryptographic functions and the amount of ADA a pool operates on the network (that is, the pool with less stake being the favourite to win a slot battle).

Cardano to the moon!

 



Useful Resources:

Technical Authority: Duncan Coutts - IOHK Team: https://iohk.io/en/team/duncan-coutts


Published on 17th February 2021
by Jorge Pasocal - [BRUN] Stake Pool

 


https://cutt.ly/tk9jOyR

Wallet Management

Managing the wallet(s) associated with the pool

Wallet Management

What happened to [HYPE] pool's block rewards?

Introduction

A pool is registered along with a pledged amount in a wallet. We look at what happens when a registered pool disassociates their pledge wallet in lieu of a new wallet.

HYPE pool decided to a change of pledged wallet so that they could have a wallet reconstructible via a mnemonic phrase. The intention of having a pledged wallet of this fashion, as opposed to the standard CLI wallet we create for our pools, is so that the mnemonic-based pledge wallet can also be held on a hardware device like a Nano Ledger. This has the advantage that the pledged ADA can be used as leverage against voting in the Catalyst funding rounds.

The problem that HYPE pool encountered

HYPE pool disassociated their pledge wallet from their pool sometime during or before Epoch 250. They did this by moving the pledged funds they had in their original wallet to a new mnemonic-based wallet. They then associated the new wallet as the pledged wallet to their pool.

HYPE pool was fortunate to mint a block in Epoch 250.

https://explorer.cardano.org/en/block?id=13a043fc1e97c9a2d04f8b24687df4c5cc87737fb30b6b7b2c78d99f41d97709

The payout of the rewards of this block was scheduled for the post boundary event between Epoch 251 and Epoch 252.

The problem was that the scheduled rewards were not paid out!

What happened to the rewards?

Since the original wallet had the correct designated amount for the pledge, and by removing that amount to a new wallet, the Cardano protocol checks against the original wallet registered for epoch 250 and finds that it is deficient. The protocol refuses to pay out the rewards. The rewards go to the treasury. Consequently, the rewards are not recoverable for HYPE pool.

How to mitigate this problem

We suggest that a pool not disassociate the original pledge wallet. But rather create a multi owner system where the second wallet (the mnemonic-based wallet) becomes a second owner of the pool. The pool would exercise two pledged wallets. The amount in the original wallet can be transferred over to the new wallet during the next Epoch and it won't affect the rewards payout.

To corroborate this we got Andrew Westberg's input too:

Sure. What happened is that changing the owner wallet doesn't take effect until n+1 epochs.

What HYPE "should" have done is create the new empty hardware pledge wallet and associate it with the pool during epoch 250. By leaving funds in the old wallet during the 250->251 snapshot, the old wallet is still the one checked for pledge.

Then, after the transition into 251, pledge can be safely moved so it's ready for the 251->252 snapshot.

Basically, whenever messing with pledge or owner accounts, the rule of thumb is to 1.) Make the change to the pool owner account. 2.) Wait until the next epoch cutover before moving the funds into the new account.

- by Andrew Westberg - Blue Cheese Stake House Pools

Further Tips

We recommend that new stake pool operators test operations such as the above on the test net.

We recommend further that they use the faster hour-by-hour epoch test net operated by the Guild Operators. Once you see your operations work correctly on the test net then you can go ahead with some confidence onto the mainnet side of your pool and exercise the changes you need to make.


Created: 8 March 2021

https://cutt.ly/0zhP0vR

 

 

Wallet Management

How do I add a HardWare wallet as an owner of a pool pledge?

Introduction

It is not uncommon to want to use a hardware wallet like a Ledger or Trezor device, with your own mnemonic phrase, for example, to act as the wallet for the pool pledge. Moreover, you can also use it to allow for multiple owners to pledge to the same pool. In some instances, some pool operators want a secondary wallet so that they have the main pledge amount in one wallet which they never touch, and a secondary "working" wallet with a small amount of ADA to use to sign and pay for transactions.

Shortcut to this page:

https://cutt.ly/zzJDuG8