I love mathematics. To me, it feels like a language of precision—a system so consistent and structured that it almost feels like a reflection of perfection itself. Everything in mathematics can be explored, proven, and understood through logic. It is not just abstract symbols on paper; it quietly shapes the way the world works.

Let me share a simple but interesting example of how mathematics appears in everyday thinking.

Most of us remember learning basic algebra in school, especially polynomial expansions like:

At first glance, it looks like a simple formula to memorize. But if you look at it more carefully, there is something meaningful hidden inside it—especially in the term $\mathbf{2ab}$.

Now imagine interpreting this in a real-world context.

Let’s say $a$ and $b$ represent two people working individually. If person $a$ works alone, their contribution is $a^2$. If person $b$ works alone, their contribution is $b^2$.

But when they work together, something interesting happens: the expression becomes $(a + b)^2$, and the extra term $2ab$ appears.

This extra term can be seen as the interaction effect — the benefit created when two people collaborate. It is not just $a$’s work plus $b$’s work; it includes the additional value generated through coordination, communication, and shared effort.

In this interpretation, the term $2ab$ represents how teamwork can amplify results. When two people work together effectively, their combined output is not merely additive—it can be significantly greater because of synergy.

Sometimes, mathematics does not just describe numbers. It gives us metaphors that help us understand life itself.

Threshold Signature

A Threshold Signature allows a group of participants to collectively sign a message such that any subset of at least $k$ out of $n$ participants can generate a valid signature, while fewer than $k$ cannot. This is extremely useful in distributed systems, where we want fault tolerance and decentralization in signing operations without having to trust a single key holder.

Shamir’s Secret Sharing

Adi Shamir, in his seminal 1979 paper “How to Share a Secret”, introduced a method to split a secret into parts using Lagrange interpolation over a finite field. This technique is known as Shamir’s Secret Sharing (SSS) and remains one of the most widely used methods for secure secret splitting.

In a nutshell, a secret can be embedded in a random polynomial:

Here, $ a_0 $ is the secret, and the rest of the coefficients $a_1, a_2, \dots, a_{k-1}$ are chosen randomly.

We then evaluate this polynomial at $n$ different non-zero values $ x_1, x_2, \dots, x_n $ to generate $n$ shares: $ (x_i, f(x_i)) $. These shares are distributed to participants.

To recover the secret $ a_0 = f(0) $, we only need $k$ shares. Using Lagrange interpolation, we compute the Lagrange coefficient $ \lambda_j $ for each share, and reconstruct the secret:

Then the secret is recovered as:

BLS Signature

The Boneh–Lynn–Shacham (BLS) signature scheme is a digital signature scheme based on elliptic curves and bilinear pairings. The signer has a private key $ sk \in \mathbb{Z}_q $ and a public key $ pk = sk \cdot G $, where $ G $ is a generator of an elliptic curve group.

To sign a message $ m $, the signer first hashes it to a point on the curve: $ H(m) \in G_1 $, then computes the signature:

BLS Threshold Signature

In a BLS threshold signature scheme, a trusted dealer distributes $n$ shares of the secret signing key to all participating parties using Shamir’s Secret Sharing.

Each party can independently compute a partial signature. As long as $k$ or more parties sign the same message, the final signature can be reconstructed.

Here’s how it works:

1. Let $ \mathcal{T} = {i_1, i_2, \dots, i_t} $ be the indices of the $ t $ participants (where $ t \ge k $) who provide partial signatures.

2. Each participant computes their partial signature:

   \[\sigma_{i_j} = s_{i_j} \cdot H(m)\]

   where:

   • $ s_{i_j} $ is the secret share of participant $ i_j $
   • $ H(m) \in G_1 $ is the hash of the message mapped to the curve

3. The combiner (aggregator) computes the final signature:

   \[\sigma = \sum_{j=1}^{t} \lambda_{i_j} \cdot \sigma_{i_j}\]

   where $ \lambda_{i_j} $ is the Lagrange coefficient:

   \[\lambda_{i_j} = \prod_{\substack{k=1 \\ k \ne j}}^{t} \frac{i_k}{i_k - i_j}\]

4. Substituting the partial signatures:

   \[\sigma = \sum_{j=1}^{t} \lambda_{i_j} \cdot (s_{i_j} \cdot H(m)) = \left( \sum_{j=1}^{t} \lambda_{i_j} \cdot s_{i_j} \right) \cdot H(m)\]

   By Lagrange interpolation, we know:

   \[\sum_{j=1}^{t} \lambda_{i_j} \cdot s_{i_j} = s\]

   where $ s $ is the original secret key.

Thus, the final signature is:

This is the standard BLS signature.

The beauty of this construction is its simplicity: Shamir’s Secret Sharing and BLS signatures combine naturally because both rely on linear operations over the same group. This makes BLS an ideal candidate for threshold signing — far simpler than threshold ECDSA protocols, which require complex multi-round MPC.

While Bitcoin has recently adopted Schnorr signatures (which do support native multisignatures, and it is very simple, which I really like), ECDSA remains dominant in the ecosystem. For threshold ECDSA, one of the most efficient and well-designed protocols to date is CGGMP.

The protocol is detailed in the paper “UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts.” The acronym CGGMP comes from the initials of the authors’ last names: Ran Canetti, Rosario Gennaro, Steven Goldfeder, Nikolaos Makriyannis, and Udi Peled.

In a threshold signature scheme, a private key is split into $n$ shares distributed among participants. Any subset of at least $t$ participants (the threshold) can collaboratively produce a valid signature without ever reconstructing the full key. This eliminates the single point of failure that plagues traditional single-key custody.

CGGMP builds on earlier threshold ECDSA protocols like GG18 and GG20, but introduces several improvements:

• Non-interactive signing: Earlier protocols required multiple rounds of back-and-forth communication during signing. CGGMP moves the heavy lifting to a pre-signing phase that can be done offline, ahead of time. Once pre-signatures are ready, the actual signing is non-interactive—each party produces their signature share independently.
• Proactive security: The protocol supports key refresh, meaning shares can be periodically rotated without changing the public key. Even if an attacker compromises some shares over time, they cannot combine old shares with new ones.
• Identifiable aborts: If a party misbehaves, the honest participants can identify exactly who was at fault. This is critical for real-world accountability.
• UC security: The protocol is proven secure in the Universal Composability framework, the gold standard for cryptographic proofs, ensuring security even when composed with other protocols.

What sets CGGMP apart is this combination of non-interactive signing and proactive security.

Recently, I came across a new Rust implementation of CGGMP that is open-source. It’s exciting to see the community making this cutting-edge cryptography more accessible, and I highly recommend checking it out if you’re working on threshold signing for ECDSA.

package port

import (
	"time"
)

type RedisPort interface {
	Set(key string, value string, ttl time.Duration) error
	Get(key string) (string, error)
	Del(keys ...string) error
	Exists(key string) (bool, error)
	SetJSON(key string, val any, ttl time.Duration) error
	GetJSON(key string, out any) error

	Close() error
}

At first glance, it gets the job done. But there are a few points that could make it even better.

Interfaces Should Be Descriptive

Interfaces or traits are descriptive, not blueprints for specific implementations. They describe the common behavior of a group of types.

For example, imagine describing a flower. You might mention its petals, color, and fragrance—properties common to all flowers. But you wouldn’t describe a Rose as an interface, that’s too specific.

Naming an interface RedisPort is too specific. It’s better to name it something more general, like CachePort.

Extending Interfaces Through Composition

While Go doesn’t support partial implementation of interfaces natively, you can achieve similar results through struct embedding and method promotion. This allows you to build richer functionality on top of a minimal interface without forcing every implementation to carry the extra weight.

A Cleaner, More Flexible Interface

Let’s apply these improvements to create a cleaner, more robust interface:

package port

import (
	"encoding/json"
	"time"
)

type Option func(*Options)

type Options struct {
	// Time-To-Live for cached item.
	TTL time.Duration
}

func WithTTL(ttl time.Duration) Option {
	return func(opt *Options) { opt.TTL = ttl }
}

type CachePort interface {
	Set(key string, value string, opts ...Option) error
	Get(key string) (string, error)
	Del(keys ...string) error
	Exists(key string) (bool, error)
}

type CacheWithJSON struct {
	CachePort
}

func (c CacheWithJSON) SetJSON(key string, val any, opts ...Option) error {
	bz, err := json.Marshal(val)
	if err != nil {
		return err
	}
	return c.Set(key, string(bz), opts...)
}

func (c CacheWithJSON) GetJSON(key string, out any) error {
	str, err := c.Get(key)
	if err != nil {
		return err
	}
	return json.Unmarshal([]byte(str), out)
}

With this setup, you only need to implement the core cache methods like Set and Get and the JSON helpers come built-in at no extra effort. Additionally, the interface is easily extensible through options, providing the flexibility to support additional features in the future.

We knew the temple was located on top of a mountain near a village, so we set off, hoping the villagers could guide us. Surprisingly, no one in the village had heard of Azar-Barzin-Mehr or the fire temple. Our hope began to fade until we met an old man who spoke of a “Devils’ House.” Intrigued, we asked him about it, and he described a structure that, according to local lore, could not be destroyed because it was built by the devil himself. We realized this must be the fire temple, its endurance through the ages giving it an almost supernatural reputation. With his help, we located the mountain and began our climb. It was challenging, but finally, we stood before the ancient temple, amazed by its strength and historical significance.

Recently, I came across a fascinating story about the Devils’ Bridges in Europe. These ancient bridges, still standing and functional after centuries, are covered in mystery. Locals call them devil’s bridges, believing their construction to be beyond human ability, attributing them instead to the devil.

Both stories share a common theme: the incredible cleverness of ancient engineers. Whether it’s the fire temple in Persia or the bridges in Europe, these structures resist time and doubt. The names of their creators may be lost to history, but their remarkable works continue to stand tall, drawing our attention and inspiring wonder.

In this article, we’ll explore these potential malicious behaviors.

Long Range problem

In a Long-Range problem, an adversary chooses a block from the past and tries to create an alternate chain starting from that block. The main goal is to rewrite the blockchain’s history. By doing so, they can add or remove transactions they desire. Because the fork begins from an earlier point in the blockchain, it is termed a “Long-Range” problem.

Proof-of-Work

In the case of Bitcoin, since the hashing power has constantly increased over time, rewriting past blocks requires a huge amount of energy. It is almost impossible for the adversary to rewrite the last 6 blocks.

Indeed, Satoshi Nakamoto showed that with a probability less than 0.1%, an adversary with 10% of the mining power can rewrite the last 5 blocks (less than one hour), while an adversary with 45% of the mining power can rewrite the last 340 blocks (about 56 hours, or 2.5 days).

The chart below shows the probability of rewriting blocks by an adversary with 10% of the mining power.

Unfortunately, many proof-of-work blockchains don’t have a hash rate growth like Bitcoin’s. In some blockchains, like Bitcoin SV, the hashing power even dropped over time.

Proof-of-Stake

This problem in Proof-of-Stake (PoS) blockchains appears more serious. In these blockchains, an adversary can obtain (or even purchase) the private keys from early validators. If they possess enough keys, they can reorganize a new fork from early blocks (even from the genesis block!). Considering there is no actual work involved, just staking, reorganizing the blockchain becomes very easy.

Solution

So, as you can see, most blockchains appear vulnerable to the long-range problem. However, this problem is not serious and can even be ignored. Simply because any chain that looks new can be ignored, and miners or validators can always add blocks to the chain they know.

51% and Nothing-at-stake problems

Attackers may choose to create a fork at the tip of the blockchain. By doing so, they can execute a double-spending transaction. For example, in one fork, Eve sends coins to Alice, and in another fork, she sends the same coins to Bob. This problem is known as the “51%” in proof-of-work blockchains and “Nothing at stake” in proof-of-stake blockchains.

Proof-of-Work

The consensus mechanism in Proof-of-Work blockchains doesn’t provide safety¹. This means the blockchain doesn’t necessarily provide safety, and there might be more than one valid block at each height.

In the case of Bitcoin, forks can happen but very rarely. Since the hashing power is high, the chance of an adversary creating a fork longer than two blocks is really low. This is why in many exchanges, you have to wait for at least 2 block confirmations before withdrawing or depositing your Bitcoins.

Most people think that proof-of-work blockchains are more secure than other consensus types, but in the real world, Proof-of-Work blockchains have been more vulnerable to 51% attacks specifically. For example, in Ethereum Classic, there is a history of a 51% attack injecting more than 3000 blocks by a single miner.

Proof-of-Stake

If the consensus mechanism in proof-of-stake blockchains doesn’t provide safety, it is vulnerable to Nothing-at-stake problem.

In blockchains like Ethereum adversaries with enough stake can create a valid fork. To overcome these scenarios, there is a mechanism in Ethereum to punish the validators that double-vote in different forks.

However, other blockchains prioritize safety. In these cases, there’s no way to have a fork at the tip of the blockchain.

If a fork happens, it is the result of a bad implementation or, even worse, the majority of the nodes (with more than ⅔ of the total stake) are not loyal and honest. So, the Nothing-at-stake problem in these blockchains is not possible. Blockchains like Algorand and Pactus are not vulnerable to the Nothing-at-Stake problem, and therefore there is no need for a slashing mechanism there.

Let’s do this step by step.

Assume you’ve just created a new Linux server. This guide is based on Debian or Ubuntu systems. However, for other distributions, most of the commands will be more or less the same.

Step 1: Check the current users

Connect to the server using SSH:

$ ssh root@<ip_address>

To determine which users are members of the root and sudo groups, inspect the /etc/group file:

# grep "sudo\|root" /etc/group

After executing the above command, you might see an output similar to:

root:x:0:
sudo:x:27:

This output indicates that there are currently no users assigned to the sudo or root groups.

You can check which users have SSH login capabilities by examining the /etc/passwd file.

# grep /bin/ /etc/passwd

Executing this command may produce an output like:

root:xxxxxxxxxxxxxx:/bin/bash
sync:xxxxxxxxxxxxxx:/bin/sync
admin:xxxxxxxxxxxx:/bin/bash

This indicates that the users root, sync, and admin have access to commands like bash or sync.

To remove all users except root:

# userdel -r admin
# userdel -r sync

The -r flag deletes the user along with their home directory. While it’s not strictly necessary to remove the sync user, we will.

Step 2: Add a New User

Let’s proceed to add a new user and grant it sudo execution privileges.

First, ensure that sudo is installed:

# apt update
# apt install sudo

Now, create a new user named pactus (feel free to choose a different name):

# adduser pactus

Then, add this user to the sudo group:

# adduser pactus sudo

To confirm everything is set up correctly, use the id command:

# id pactus

Running # grep "sudo\|root" /etc/group again should now display the new user as a member of the sudo group.

Step 3: Enable SSH Login for New User

Now, we’ll set up the server to allow connections from the new user.

First, switch the security context to the new account to ensure new folders and files have the appropriate permissions:

# su - pactus

Create the ~/.ssh directory:

$ mkdir ~/.ssh
$ chmod 700 ~/.ssh

Now, create the authorized_keys file and open it for editing:

$ touch ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys
$ vim ~/.ssh/authorized_keys

Paste your public key into this file, save, and exit.

A quick note on permissions: chmod 700 on the .ssh directory means only the owner can read, write, or enter it. chmod 600 on authorized_keys means only the owner can read or write the file. SSH is strict about this — if the directory or file is accessible by group or others, SSH will refuse to use it for authentication.

Important: Before disabling root login, verify that you can successfully SSH in as the new user from a separate terminal. If the new user’s SSH fails and you’ve already locked root, you’ll be locked out of the server.

Now, let’s ensure that the new user can use SSH to connect to the server. Open a new terminal on your local machine and run:

$ ssh pactus@<ip address>

Step 4: Disable SSH login for root

At this point, we can disable SSH remote login for the root account.

Open sshd_config:

$ sudo vim /etc/ssh/sshd_config

Search for the authentication options and modify the root login permission by setting it to ‘no’ as shown below:

PermitRootLogin no

Also, ensure that SSH password login is disabled:

PasswordAuthentication no

After making these changes, restart the sshd service:

$ sudo systemctl restart sshd

You will no longer be able to log in using the root account.

Next step, lock the root account:

sudo passwd --delete --lock root

This command deletes the root password and locks it. You can test if the root is locked:

su -

References:

Secure Secure Shell

It seems that the best solution to prevent Sybil attacks is to weight the votes within the network, using a metric that cannot be tampered with or modified easily. However, the question remains: how can this be done?

Bitcoin addresses this issue by weighting nodes based on the work they contribute to the consensus protocol, instead of relying solely on identity, such as IP addresses: “If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.”¹

Proof-of-Stake blockchains weigh users based on the money in their account.² This money is usually locked and cannot be transferred.

An alternative approach is to weight nodes based on their reputations. EigenTrust prevents Sybil attacks by using a reputation management algorithm in peer-to-peer networks.

Sybil attacks are challenging to address, and no single method is a silver bullet. A combination of approaches—economic, computational, and reputational—offers the best defense.

Consensus in Distributed Systems

Consensus is a critical problem in distributed systems, as it allows multiple parties to reach agreement on a single value or set of values. A protocol that solves the consensus problem must have several key properties, including:

• Fault tolerance: If all correct parties propose the same value, any correct party must decide on that value. This ensures that a correct party will not accept a value proposed by a faulty or Byzantine node, and it makes the protocol fault-tolerant. Some papers refer to this property as “integrity” or “validity.”

• Safety: Every correct party must decide on the same value, and there should be no fork in the system. A safety property ensures that something bad does not happen ¹. Some papers refer to this property as “agreement.”

• Liveness: Eventually, every correct party will decide on some value. A liveness property ensures that something good eventually does happen ¹. Some papers refer to this property as “termination.”

Network synchrony

Network synchrony is an important factor to consider when designing a consensus protocol. In a completely asynchronous model, it is assumed that messages are eventually delivered and processes eventually respond, but no assumption is made about how long this may take. In contrast, partially synchronous models introduce the concept of time and assume known upper bounds on message transmission and response times ¹.

FLP impossibility

The FLP ² impossibility theorem states that it is impossible for a completely asynchronous consensus protocol to tolerate even a single faulty process:

No completely asynchronous consensus protocol can tolerate even a single unannounced process death. We do not consider Byzantine failures, and we assume that the message system is reliable. It delivers all messages correctly and exactly once. ³

This statement, known as the “FLP impossibility,” strongly demonstrates that:

No consensus protocol is totally correct in spite of one fault. ³

However, this does not mean that consensus is impossible in practice. Instead, it highlights the need for more refined models of distributed computing that reflect more realistic assumptions about processor and communication timings, and for less strict requirements on the solution to the consensus problem.

There are several approaches to solving the consensus problem, each with its own trade-offs and assumptions:

Prioritize Safety

One way to overcome the FLP impossibility is to prioritize safety over liveness. The Paxos consensus protocol was the first protocol that solved the consensus problem by making this assumption. Indeed, in Paxos, there may be situations where the protocol cannot be terminated.

Probabilistic Binary Agreements

Some protocols address the FLP impossibility by introducing a random function within the agreement protocol. In this scenario, when the network diverges, each party randomly chooses a value between zero and one, like flipping a coin. Even though these protocols employ a random function, they ensure safety or agreement, meaning that eventually all parties agree on the same value: zero or one. This approach was first offered by Ben-Or⁴ in 1983.

Partial Synchrony

The DLS⁵ consensus algorithm was the first protocol that introduced a partially synchronous model. It was proposed by Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer in their paper “Consensus in the presence of partial synchrony” published in 1988.

Consensus protocols like Practical Byzantine Fault Tolerance (PBFT)⁶, follow this assumption by setting an upper-bound timer that prevents the system from waiting indefinitely in the event of node failure. From an FLP perspective, a synchronous consensus algorithm can provide safety, but with weaker liveness.

Prioritize Liveness

Bitcoin is a solution to the FLP impossibility by prioritizing liveness over safety. In Bitcoin’s design, more than one valid block may exist at a given height within the network. This means that the protocol allows for the possibility of forks in the blockchain, sacrificing safety to ensure liveness.

CAP theorem

The Strong CAP Principle⁷, also known as the CAP theorem or Brewer’s theorem, is widely known in the field of distributed systems. It strongly states that a distributed data store can only guarantee two out of the following three properties:

• Consistency: Every read receives the most recent write or an error.
• Availability: Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
• Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between parties.

It’s worth noting that the FLP impossibility theorem and the CAP theorem are not the same thing⁸, although they both relate to distributed systems. The FLP impossibility theorem deals with the problem of achieving consensus in a distributed system, while the CAP theorem deals with the problem of achieving consistency in a distributed database.

Now let’s look at the possible combinations of the CAP theorem.

Consistency and Availability (CA)

Protocols like Paxos are consistent and available if there is no network partitioning. If the network becomes partitioned (e.g. half of the network can’t see the other half), then the consensus process will be halted.

Availability and Partition tolerance (AP)

The Bitcoin consensus protocol (Nakamoto consensus) prioritizes availability over consistency. This is why Bitcoin is resilient against network partitioning, but it can also result in forks.

“The Grand Inquisitor” is actually a short story within the main story of “The Brothers Karamazov,” a novel by Fyodor Dostoevsky. The story is set in Spain during the Spanish Inquisition, a time when the Catholic Church was the main power in Europe. This passage, which is almost independent of the rest of the book, narrates the return of Jesus, performing miracles in Spain. The Church discovers Him and orders His capture. Later, Jesus is arrested by the Inquisition.

A dialogue happens between Jesus and the Grand Inquisitor. The talk is intense, profound, and philosophical. The Grand Inquisitor threatens to burn Jesus and says to Him:

“We are not with you, but with him (Satan), and that is our secret! We corrected your great work. Our kingdom is built on your name. Why have you come back now to trouble us? Go, don’t come to us anymore.”

Security or Freedom

From my point of view, the story is a philosophical battle between freedom and security. The Grand Inquisitor argues that humanity cannot handle the burden of true freedom, as granted by Jesus, and that people would rather have security and happiness, even if it means sacrificing that freedom.

If you haven’t read the book, you can watch this short video. Anytime I watch this video, I learn something new.