Presignatures are not distributed evenely

[jakmeier]

When generating new Ps, the proposer of the P posit generation becomes the owner of the new Presignature. Somehow, not all nodes get the same number of Ps in our tests.

These tests are known to fail because of slow or uneven P generation:

• test_sign_requests_wait_for_presignatures
• test_sign_contention_5_nodes
• test_sign_requests_wait_for_presignatures

Example assertion error, while waiting for 3 Ps per node:

2026-03-05T16:29:25.250615Z  INFO integration_tests::mpc_fixture::fixture_interface: Node Participant(0) has 12 Ps
2026-03-05T16:29:25.251657Z  INFO integration_tests::mpc_fixture::fixture_interface: Node Participant(1) has 8 Ps
2026-03-05T16:29:25.252524Z  INFO integration_tests::mpc_fixture::fixture_interface: Node Participant(2) has 18 Ps
2026-03-05T16:29:25.253070Z  INFO integration_tests::mpc_fixture::fixture_interface: Node Participant(3) has 3 Ps
2026-03-05T16:29:25.253654Z  INFO integration_tests::mpc_fixture::fixture_interface: Node Participant(4) has 2 Ps

thread 'cases::mpc::test_sign_contention_5_nodes' (159697) panicked at /home/runner/work/mpc/mpc/integration-tests/src/mpc_fixture/fixture_interface.rs:92:16:
should have enough presignatures: Elapsed(())

full logs

Task: Find out why these are generated uneven and find a solution for a better distribution.

[volovyks]

Here is the network setup in test_sign_contention_5_nodes.

    // Build network with pre-shared keys, generate triples/presignatures on the fly
    let network = MpcFixtureBuilder::new(NUM_NODES, THRESHOLD)
        .with_preshared_key()
        .with_preshared_triples()
        .with_min_triples_stockpile(STOCKPILE_MIN)
        .with_max_triples_stockpile(STOCKPILE_MAX)
        .with_min_presignatures_stockpile(STOCKPILE_MIN)
        .with_max_presignatures_stockpile(STOCKPILE_MAX)
        .build()
        .await;

To generate pre-signatures, we need to generate triples. The owner of each generated triple is assigned after the generation is done. Triple generation is slow; presignature generation is fast. The presignature generation proposer is the owner of the triple, and this presignature will be assigned to them.

All these mean that it is not possible to build such a deterministic test without pre-generated triples.

Not saying there is no issue, the test would have passed if there were no POSIT errors.

[jakmeier]

@volovyks Sorry I don't quite understand your last comment.

To generate pre-signatures, we need to generate triples. The owner of each generated triple is assigned after the generation is done. Triple generation is slow; presignature generation is fast. The presignature generation proposer is the owner of the triple, and this presignature will be assigned to them.

Yes. But if the current rules for assigning ownership of triples leads to uneven distribution, we should change it.

All these mean that it is not possible to build such a deterministic test without pre-generated triples.

If we can't build a test that reliably generates Ps for all nodes, that's not a testing issue. That's a production code issue that needs fixing.

Not saying there is no issue, the test would have passed if there were no POSIT errors.

I'm not sure how posits come in here. Are you saying this problem of uneven distribution would be hidden if posits wouldn't delay everything so much?

[volovyks]

Yes. But if the current rules for assigning ownership of triples leads to uneven distribution, we should change it.

@jakmeier, I think that assigning triple to a random participant after it was generated is a cryptographic requirement. cc @scafuro

If we can't build a test that reliably generates Ps for all nodes, that's not a testing issue. That's a production code issue that needs fixing.

We can build a test that reliably generates Ps, but not Ts.

I'm not sure how posits come in here. Are you saying this problem of uneven distribution would be hidden if posits wouldn't delay everything so much?

Yes, we would generate everything faster, without wasting pre-signatures, waiting for many rounds in signature generation, etc. The issue with undeterministic Ts will not disappear, but everything will be "fast enough".

[jakmeier]

I see, if random distribution is required, it will naturally always be possible that some nodes are starved from T. And in the case of test_sign_contention_5_nodes, that leads to starvation of Ps.

In practice, we could say that is fine as over a long-enough time frame, the probability of starvation approaches 0.

For tests, I guess we could change it in a few ways to reduce the non-deterministic failure rate:

1. not wait for ALL nodes to have N Ps. If the threshold has N Ps, that should be enough.
2. Maybe don't run the contention test with 5 nodes. It should work much better with 3 nodes.

[scafuro]

@volovyks: strictly from the cryptographic protocol perspective: there is not concept of "owner" of the triple.
The pre-signature protocol starts assuming that parties have agreed on a triple to use. The protocol does not establish how they agree, it assumes that there is a way for parties to know what triple is associated with what pre-signature.
I believe that we introduced the concept of ownership just to facilitate coordination @ChaoticTempest ?
Does the owner have special powers in the protocol @ChaoticTempest ?

@volovyks you remember correctly that for the draft of the security analysis I needed to make an assumption on the triple+pre-signature flow. However, my assumption was not about random assignment of ownership. My assumption was that we must generate two triples (A0,B0,C0) (A1,B1,C1) and the pre-signature value (big_r) at the same time. This does not happen in the current protocol, as we generated triples independently of pre-signatures.

The conclusion is:

• 1. Ownership of the triple is not a cryptographic concern. The crypto protocol just assumes that parties know what triple to use. I believe that ownership is an artifact of coordination for distributed systems.
• 2. Being an owner of a triple does not give a party more information about the triple. Therefore, we could apply any strategy to assign ownership. The only repercussion might be that if we designated a party that does not cooperate, we might end up wasting time and triples.

One note:
-I do not know what Ps are. I wonder if it would be useful to talk again about what problem does ownership tries to solve.

[volovyks]

Thank you @scafuro !
It would be much more convenient for us to set proposer as owner. PR: #703

Ts and Ps are triples and pre-signatures

[ChaoticTempest]

It would be much more convenient for us to set proposer as owner

@volovyks for triples, setting the proposer as owner has many issues. One node can spam the whole system by being the proposer, where the triples for the whole network would mostly be owned by that one proposing node. We can't guarantee equal distribution this way, that's why we've been hashing the output of the triple and assigning the owner this way, because hashes give us equal distribution

I believe that we introduced the concept of ownership just to facilitate coordination?
Does the owner have special powers in the protocol?

@scafuro ownership is merely for coordination, yes. For presignature generation, only the owners of triples can use those triples to coordinate presignature generation. Like which triple pair is to be used. Similarly for signature generation, only the owners of presignatures can use that presignature for signature generation if they were selected as the proposer.

[volovyks]

@ChaoticTempest, that’s a fair concern, but it also comes with a few trade-offs:

• We lose control over how many Ts each node owns, which makes the system less predictable overall, from testing to metrics.
• Random distribution works well at scale, but in tests (where we might only have 0–100 Ts), the chance of skewed or unlucky distribution is quite high.
• Also, if we ever move away from having triple generation and storage as a standalone process, a random owner becomes a blocker. If the triple pair owner is the same as the proposer, triple generation could be folded into presignature generation. That aligns more closely with @scafuro’s design and helps reduce overall system and testing infra complexity.

Spamming can be addressed on the Posit ACCEPT/REJECT level. For example, in case the node initiates a new protocol, but we already have N protocols owned by that node, we REJECT.

P.S. Not saying that this change is the main issue, CI is still failing. After I changed the test setup, we are hitting timeouts and are not blocked by max number of Ts in the system.

[ChaoticTempest]

if it's such a concern for testing, just pregenerate the triples and presignatures. No reason to make this an issue for the production service where we can encounter other issues with making the owner == proposer for triples.

I don't want to add further complexity to the posit layer because that is already a hazardous area. So many things go wrong there. Adding one more just increases the chance we scre something up.

[jakmeier]

@ChaoticTempest This is not only a concern for testing. The one test that simulates real-world contention just shows that our triple assignment causes unpredictable but potentially long delays in cases where stockpiles are near empty.

For a real-world scenario: Let's say a node needs a DB reset for some reason and it ends up with 0 Ts and 0 Ps while all other nodes have large stockpiles. Random assignment will make it much harder for the node to recover a healthy stockpile.

IMO, the case of a well-intentioned node needing to recover their stockpile is more important right now than the case of a malicious node stalling out the system.

[ChaoticTempest]

I see what you're saying, but the switching over to proposer being equivalent to the owner has its own challenges. We can have network issues where some nodes are faster than others which can very easily steer us towards imbalance. So I see switching over to this approach as more easily faulty.

But to be clear, I'm not opposed to switching over to proposer==owner as long as we have proper safeguards against some of the cases where we lean towards imbalance. The issue is that the safeguards comes with their own complexity and I would like to have those safeguards before committing to production. So having checks on posits would be ideal to have sooner than later for this, and we should have proper tests too, to prove that this indeed works as intended

[jakmeier]

as long as we have proper safeguards against some of the cases where we lean towards imbalance

I thought about this some more. Wouldn't the best way to avoid imbalance be to assign a T to the same node who decided it was necessary to generate one? Right now, in case of imbalance, nodes with too many will not introduce more generations but they will get an equal share of all new Ts.

@ChaoticTempest Can you maybe elaborate what situations you are worried? And do you have rough ideas regarding the safeguards we lack?

[ChaoticTempest]

specifically the check that a node shouldn't own more than maximum triples/presignatures or concurrent introductions per node should not exceed a certain amount. Having the ability to constantly introduce new generations could starve other nodes of their ability to introduce or work on their own owned generations