Multi-party Staking with Threshold Signatures
Among many other things first introduced with Peercoin, such as destroying the transaction fee, a coherent inflation rate, or minimum dust limit, the original authors of Peercoin were also the first to implement Proof-Of-Stake consensus. Staking Peercoin requires a full node and complete blockchain history. To participate in proof-of-stake consensus on Peercoin, a user does not need anything else but a node, some coins and time. In Peercoin’s PoS model, time is the secret sauce — the scarce but energy-efficient resource.
While minting is a plug-and-play endeavor, making it easy for anyone to obtain the coins and participate in the consensus; one question is permanently in the discourse for as long as I can remember. And I have been around since about 2015.
The need for the mobile-friendly solution. Mobile minting.
The ever-lasting question on how to implement this and properly allow even more people to easily participate in the consensus. Peercoin is the peer-to-peer coin, after all. Many users do not use a desktop computer at all, many do not have access to a stable internet connection, many are continuously on the move without a permanent residence. It is not easy for everyone to participate in the consensus. A solution is required that allows users to keep a mobile-first workflow.
This brings us to something we have been working on for the past year. Actually, we have been preparing the tools that are to be used to implement the big idea. Peercoin’s early 2023 release, Ladybug, brought taproot support to the Peercoin protocol. The taproot upgrade also brings Schnorr signatures, which allows for some pretty remarkable stuff. For example, threshold signatures (TSS), allowing for massive multi-signature setups. By massive, I mean truly massive. Imagine a setup with 150 or even 300 signers.
In this post, I will touch on multi party computing, explain threshold signatures and contemplate how we can have user-friendly mobile minting implemented with the help of these new shiny toys.
Minting them stakes
While pooled minting was perfectly possible even before taproot, and indeed already used in production, without Schnorr signatures — it is rather limited in maximum size and is rather cumbersome to work with. Multisig minting setup cannot be larger than 9of15 multisig, as that is the maximum script size.
The first, and from my understanding still the only, multisig minting setup is the one used by the Peercoin Foundation, which has been in operation since the block #623166.
The workflow used by the Peercoin Foundation goes like this:
- Use the findstake tool to find a timestamp (in the future) when UTXO wins the proof-of-stake lottery,
- Elect the operator (block minter) with a hot key and a full node to be used for step 5,
- Create a coinstake transaction using the selected UTXO,
- Have signers of a multisig address sign the coinstake transaction,
- Selected minter imports (with the
importcoinstakecommand) the signed coinstake into the core wallet and produces a block at a set timestamp.
Multi-signature can be simply understood as each account owner signing successively and posting all signatures to the chain, and signatures are verified on the chain.
Multisignature setups on Peercoin today are script multisigs, pre-programmed spending conditions. A simple smart contract.
This is an entirely off chain process up to the point the block is submitted to the network. The Foundation uses cointoolkit tool to sign the coinstakes. Cointoolkit allows for sharing raw transaction hexes around, their validation and finally signing the transaction.
Threshold signatures
Threshold signatures are a cryptographic technique that falls under the broader category of multi-party computation (MPC). Multi-party computation refers to a set of cryptographic protocols that enable multiple parties to jointly compute a function over their inputs while keeping those inputs private. Threshold signatures specifically address the issue of generating a digital signature collaboratively among a group of participants, ensuring that a minimum threshold of participants is required to produce a valid signature.
Multi-party computation is about bringing people together who are mutually distrustful. — Amit Sahai
Unlike signatures in a single-party setting, threshold signatures require cooperation among a threshold number of signers, each holding a share of a common private key. The security of threshold schemes in general assumes that an adversary can corrupt strictly fewer than a threshold number of participants.
In a (t, n) threshold signature scheme, there are ndifferent signers, each of them having their own signing keys. To sign a transaction, cooperation is needed from at least tof them. Where “t” means threshold, which gives the schema its name.
Threshold signatures allow Schnorr signatures to be aggregated on a massive scale. Imagine a 79 of 104 multisig. The obvious use-case is multisig minting pools and the integration of such systems in the mobile app.
With a threshold scheme, trust is still required that no more than the threshold number of keys will be dishonest or deliberately sabotage the process. That’s why the identity of participants is still important. Trust is required that some entity can’t just flood the system with multiple keys. The presumption that there will always be a dishonest participant is what has led to many research papers that explain various schemas, resulting in signature schemas like FROST, and derivatives of FROST such as ICE-FROST or ROAST. The FROST schema is getting adopted in the blockchain space already. During my research, I have seen a fairly mature implementation of the schema by ZCash Foundation. I have also seen the FROST threshold schema be proposed as a solution to wrapped coins. Essentially, lock coins in a massive 150 signers-strong multisig and mint the mirror tokens on the foreign blockchain. This makes sense, there are entire blockchain networks out there which are basically multisig setups, and they form consensus through rounds of communication between the multisig participants.
FROST is an entirely off-chain protocol. The multisignature’s threshold nature is formed through mathematics and communication rounds between participants.
In the Peercoin Team, we are actually looking at the ROAST signature scheme, which is a extension of the FROST threshold signature scheme, but it is more robust. Thus, the name: Robust Asynchronous Schnorr Threshold Signatures. We believe it is better suited for anticipated workflows of the projects we imagine.
Pooled Staking Workflow
Pooled staking is imagined to be used primarily with mobile devices, such as smartphones, but it would work on all platforms supported by the Peercoin Flutter wallet (Web, iOS, Android, Linux, OSX, Windows). Peercoin Flutter is a light wallet, which means it does not require the entire history of the blockchain to operate.
The imagined workflow goes like this:
1. User finds and joins a suitable staking pool.
The user finds available pools, inspects the prospects of the pool such as the service fee, expected yearly yield, how the rewards are shared and other relevant properties. The user contacts the pool operator to arrange for admission and finally joins the pool with their coins. The pool is called a “pool” because the coins are pooled together. All participants of the pool collectively control the coins. Along with joining the pool, the user subscribes to a data feed of the pool so they can get timely information relevant to the operation of the pool.
The user can also import the pool’s address into the Peercoin Flutter wallet to receive a push notification when a block is found.
2. User gets a push notification by the pool operator when a signature is required.
The Peercoin Flutter wallet would poll the data feed by the pool operator several times a day. When the pool operator has found a potential future block, the pool operator signals the pool participants through the feed. The user receives a pop-up notification to inspect the coinstake transaction. The user proceeds to sign their share of the signature for the coinstake and transmits the partial signature to the rest of the signers.
This process does not have to be super quick, and from a year long experience with multisig minting (for the Peercoin Foundation), you have nearly a day before you need to react.
3. Pool operator loads the signed coinstake into a full node
After collecting all signatures for the coinstake, the pool operator loads the signed coinstake transaction into the Peercoin full node. After this step, the rest of the work shall be dutifully carried out by the Peercoin full node.
What’s the difference between multi-signature and threshold signature?
Several constraints of multi-signature setup are:
- The access structure is not flexible. For example, a new party is keen to join in. To change the setup of a multisig, you need to complete the initial setup process again, which will change the public key and address as well.
- No anonymity. Anonymity here means that multi-signature directly exposes all participating signers of the transaction.
- High fees. Due to large script size, multi-signature transactions cost more fees.
The threshold signature schema offers the following improvements:
- The access structure is flexible. With FROST schema, you can add new signers after key generation while retaining the same public key. Through an additional multi-party computation, the existing key sequence can be expanded to assign private keys of new participants. This process will not expose the old and newly generated private key, nor will it change the public key and account address.
- More efficient and anonymous. A group signing with threshold signature schema produces a single signature, making the transactions indistinguishable from all the other taproot transactions on the blockchain. Being a single signature, it is easier to validate, and it costs fewer fees to transact from such a schema.
The positives
As mentioned above, application of threshold signatures allows for rather easy formation of minting pools and such would work quite well on the mobile. Which means that mobile users would finally be able to participate in the PoS process. Moreover, it is easy for users to join an existing pool without the need to change the whole setup.
- Small stakeholders can group. Users with small amounts of coin would also be in a far better position than now, especially due to the ever-rising PoS difficulty. Small stakeholders can group their UTXOs and participate in the consensus more easily, using the schema to further democratize the consensus.
- Familiar experience with users used to staking tokens. A user experienced with staking tokens and not used to running blockchain nodes and handling UTXOs would feel right at home with this schema.
- Increased privacy, to the outside, the entire signing swarm seems like a single taproot address. On the other hand, it is easy to figure out individual signers in the multisig minting process.
- Lower fees than multisig, due to drastically reduced script size. Keys involved in a multisignature scheme are stored on-chain, whereas in threshold schemes computations and secret sharing are performed off-chain, and only one public key is stored on-chain. This makes threshold schemes much cheaper than multisignature proposals in terms of space and computation required for verification.
The negatives
- Vulnerable to Sybill attack. Sybil attacks are possible with threshold schemas. A single actor can represent themselves as dozens or hundreds of individuals. A fraudster could enter the system multiple times, and have enough key shares to be able to assemble a fully valid signature alone, then withdraw all funds for themselves. Due to the possibility of the Sybill attack, the pool operator should vet each participant and preferably all participants should vet each other. It is advised that you know people who you are participating in the pool with.
- Increased centralization. The stakeholders give complete freedom to the pool operator to create arbitrary blocks. Not only a single block, as they can reuse the signed coinstake to create multiple forks. This gives a lot of power to the pool operator.
- Pool participants are delegating the governance to a 3rd party. In Peercoin, the governance is fluid as each new block votes for the set of rules which define the protocol. Any stakeholder can run any set of rules they feel is best for the future of the network, and in this schema this is left for the pool operator to decide.
Future prospects
While minting pools may seem like a simple thing, and possibly a useless exercise at the moment, they are a good first step toward adopting the workflow which, I believe, will be trendsetting. Almost exactly a year ago, I wrote a blog post on the future of smart contracts. In that blog post, I argue how the future of smart contracts is off-chain, rather than on-chain. For multiple reasons, but notably for privacy, scalability and robustness benefits.
What if we move the smart contract off-chain and have them interact with an off-chain oracle directly? That would not only reduce the amount of blockchain bandwidth required to execute such a scheme, but also preserve the privacy of the user because there is no need to publish everything on the chain.
Experimenting with multi-party computation and threshold signatures in the context of something which is already well understood (minting) allows us to learn and anticipate what kind of tools we need to implement to be able to build a framework for off-chain smart contracts, sidechains, appchains and robust wrapped Peercoin architecture.
Imagine a 150 signers strong swarm of oracles who collectively bring outside information to smart contracts on-chain. All 150 signers independently verify some event and bring the information to resolve some contract, for example, a pooled bet on whether Trump will win the 2024 election. This becomes very possible with the tech stack we are working on and the tooling we are building. We want swarms of actual humans who collaborate on something from their mobile apps, always just a fingerprint away from witnessing an event or signing a transaction. We strongly believe that it is important to keep these systems human-centric and peer-to-peer.
