Schnorr signatures for network packets

[dreadful-dev]

Papaya is a Liquid Stacking solution with a standout feature: the automatic onboarding of PoX rewards as sBTC. Our goal is to drive adoption while minimizing trust assumptions. To achieve this, we're designing a trustless scheme for handling PoX rewards, drawing inspiration from the sBTC implementation.

The security of sBTC hinges on the decentralization of stacking activity. Should Papaya, or any similar Liquid Stacking protocol, garner a substantial share of stacking, and then centrally manage the signing of sBTC peg operations, it could endanger the stability of the peg.

Switching to Schnorr signatures from ECDSA for network packets would notably augment the composability of the sBTC system. Adopting Schnorr signatures for network packets would pave the way for protocols on stacks to leverage the FROST+DKG architecture (for trustless onboarding of sBTC from stacking rewards), while simultaneously participating in FROST+DKG for sBTC. This approach counters the centralization risk for sBTC if these protocols were to control a major fraction of Stacking TVL.

I might be jumping the gun here, but it appears that the sBTC FROST signers chosen for the upcomming PoX cycle will be derived from the PoX destination address. If true, protocols aspiring to engage in both stacking and signing (with signing as a mandate under SIP-021) face two choices:

• Opt for centralized signing for Peg-in/peg-out transactions. This could potentially put the massive weight of hundreds of millions of STX behind a single signature, overseen by one entity.
• Adopt decentralized threshold signing, mitigating centralization threats and upholding the foundational principles behind sBTC's design.

In light of these considerations, what are the thoughts on the best path forward?

Relevant: https://github.com/Trust-Machines/stacks-sbtc/pull/238#discussion_r1155238124

[xoloki]

We considered using schnorr signatures for the network packets, but went with ecdsa to ease external implementations of the protocol. If there's a strong use case for schnorr instead then I'm happy to go with that.

I'm not sure if I understand the concern here though. The keys used to sign the network packets are not the same as the keys used to secure the wallets of the stackers. Is this what you were concerned about?

[netrome]

I might be jumping the gun here, but it appears that the sBTC FROST signers chosen for the upcomming PoX cycle will be derived from the PoX destination address.

I don't understand what this refers to. The signers for the upcoming PoX cycle in sBTC is the same as the set of stackers. The keys they register for signing is not necessarily the same keys they use for their PoX destination address. Those can be completely decoupled, they don't have to be entangled afaik.

Re ECDSA vs Schnorr I don't have any arguments against using Schnorr, but right now I don't understand which benefits we would get from adopting it over ECDSA either.

[dreadful-dev]

I'm not sure if I understand the concern here though. The keys used to sign the network packets are not the same as the keys used to secure the wallets of the stackers. Is this what you were concerned about?

The keys they register for signing is not necessarily the same keys they use for their PoX destination address. Those can be completely decoupled, they don't have to be entangled afaik.

This is helpful to know, thank you for providing this bit of context. ☝️

Should Papaya, or any similar Liquid Stacking protocol, garner a substantial share of stacking, and then centrally manage the signing of sBTC peg operations, it could endanger the stability of the peg.

I'm less concerned with how the actual keys used by stacker-signers to participate in FROST signing are derived than I am concerned about the unintended consequences of custodial Liquid Stacking protocols concentrating the signing power of 1000's of stackers under a single signer.

The signers for the upcoming PoX cycle in sBTC is the same as the set of stackers.

This is how I understood the architecture, thank you for confirming this. Let's for a moment consider an admittedly unrealistic scenario. I hope the unlikelihood doesn't detract from the example. Hypothetically, lets say that Liquid Stacking is massively popular, and 100% of Stacking activity is concentrated within 3 custodial protocols. How many signing entities would there be? Would this present a risk to the design of sBTC? If not, why not?

Another hypothetical: What would happen if 70% of the TVL of STX locked in Stacking was concentrated in a single custodial Liquid Stacking protocol? Would this entity have full control over the peg-wallet? If not, why not?

Schnorr signatures offer advantages that can help address these possibilities in a robust way. Their adoption would enhance the composability of the sBTC system, allowing liquid stacking protocols on stacks to seamlessly integrate with the sBTC Peg wallet FROST+DKG architecture in a way that enables solutions that can mitigate the centralization of signing responsibilities under a single signer.

[xoloki]

Just to reiterate, the way we sign the packets is completely orthogonal to the frost protocol itself, and the wallet keys used for rewards and stacks contract calls.

But if Papaya wants to do their own distributed signing on the packets themselves, then yeah Schnorr would absolutely enable that. And there's no reason not to do it, it's an easy ask and now is the perfect time schedule wise.

I'll go ahead and expose Schnorr sigs in p256k1 and we can build sBTC mini using Schnorr.

[netrome]

It sounds like we have a decision. Thank you @dreadful-dev and @xoloki for this dialogue!

[netrome]

Revisiting this discussion, there are some reservations about using Schnorr signatures for mini due to lack of clarity support for Schnorr signatures.

@jferrant or @jcnelson can you elaborate on this here for context?

[dreadful-dev]

This is fine as long as Schnorr signatures make it into the sbtc release. I'm not as concerned to have this feature available for sbtc-mini. I'm a bit curious as to why this is a constraint though, does this mean that network packets will be forwarded to a clarity contract?

[netrome]

That was the idea at the time. I'm not sure if that is needed for the consensus breaking release though. We've changed the developer release scope to target testnet only without threshold signing, so there won't be a stacks signer out for a while.

[dreadful-dev]

Just to reiterate, the way we sign the packets is completely orthogonal to the frost protocol itself, and the wallet keys used for rewards and stacks contract calls.

Totally understand this now ☝️. I greatly appreciate the conversation here as it illuminated this aspect of the system design. If any other materials are available, I would love to see them. Thank you! 🙏