This is the first in a series of updates on the progress of development of ROAST and DLCs.
ROAST is a threshold signature scheme for Schnorr signatures allowing multiple participants to control a single key, requiring a threshold of participants to sign messages (such as Taproot transactions).
DLCs are Discrete Log Contracts. These allow two or more parties to construct a smart-contract that will pay according to outcomes decided by a third party oracle. Peercoin has ANYPREVOUT and Taproot which allow these contracts to be done in an all-or-nothing fashion whilst preserving privacy for the participants. ROAST allows distributed oracle attestations to be done by a threshold of oracles, removing reliance on a single third-party oracle.
I am tasked with the ongoing development of ROAST and DLCs to enable distributed DLC contracts on Peercoin. These will be the most advanced DLC contracts available, removing counterparty risks and preserving privacy with minimal on-chain footprint.
In May, the following has been achieved:
- frosty_flutter has been released, allowing frosty to be easily included in flutter apps. The Peercoin Flutter wallet uses frosty_flutter for an experimental ROAST wallet. Android, iOS, macOS and Linux are supported.
- noosphere_roast_server has been made open-source under the BSD3 licence. This allows ROAST servers to be created for coordinating ROAST signing. roast.host is available for creating hosted Noosphere ROAST servers.
- coinlib v4.10 was released allowing Taproot inputs to be used in coin selection. This was necessary to support construction of Taproot transactions using ROAST for signing.
The next stage is to enable oracle ROAST signatures with pre-generated R-points.
A description of the intended DLC implementation is found here: Atomic DLCs with Distributed Oracles
7 Likes
In June, a modification to the DLC oracle design was made to be compatible with ROAST. It is not possible to pre-generate R-points with ROAST. Therefore, DLC adaptor points shall be made with FROST public keys where oracles can construct and reveal the underlying private key with a threshold of oracle participants.
Frosty v3.0.0 was released with constructPrivateKey methods to support the construction of the underlying private keys.
Noosphere will be updated to provide a mechanism for participants to share key secret shares using end-to-end encryption for construction of the private key. Development has commenced on this.
3 Likes
I spent less time in July however further progress was made. I added a shareSecretShare to Noosphere to allow participants to share their secret shares. I also added a startTime field to the login response so that secret shares can be resent when needed.
I’ve begun development on a ackKeyConstructed method so the server and participants can be notified when a participant has constructed the private key for a FROST key.
3 Likes
New versions of the Noosphere client and server are now available:
Noosphere now has support for sharing secret shares and construction of the underlying private key for a FROST key. This allows completion of DLCs where a distributed oracle can broadcast the private key (aka. discrete log) of an adaptor point.
4 Likes
In September, progress has been made on adding MuSig2 support to coinlib.
A fork of secp256k1 has been created which includes MuSig adaptor support which is required for DLCs: GitHub - peercoin/secp256k1-coinlib: Fork of secp256k1 with additional features for coinlib including adaptor signatures
Key aggregation, and partial signing has been implemented. The next step is to add partial signature verification and aggregation.
5 Likes
In October, MuSig2 support was completed for coinlib. This enables the use of privacy-preserving and efficient DLC and atomic swap transactions.
A 5.0.0 release with MuSig2 support is waiting on confirmation that Windows builds function correctly. If anyone wishes to help test Windows builds, please get in touch.
Implementation of DLCs has been started. I’m currently working on changes to the input sequence and locktime functionality to allow DLC transactions to be sensibly constructed.
4 Likes
Great to see continued progress on this front! I think it would be super useful if someone with technical know-how could use this stack to build a basic tool utilising these functions as a bit of a showcase.
For example, I have been scheming an idea of using peercoin to facilitate completely trustless and pseudo anonymous poker tournaments using ROAST (with games hosted on PokerTH), but have no idea where to start. I would be happy to finance something like this though.
2 Likes
In November, changes to the input sequences and transaction lock-times were completed. Code responsible for defining DLC terms has been written and work has begun on construction of the Contract Execution and Refund Transactions.
I’ve had to refactor the transaction size and fee calculation code to enable payment of the correct fees for the DLC transactions. This has been completed whilst also massively improving the efficiency of the fee calculation.
2 Likes