[stacks-signer] Update pox-4 contract to calculate aggregate public key without signers casting votes

[jferrant]

This is dependent on math operations in clarity. ( @EmbeddedAndroid github issue?) If we submit DKG public share packets to the pox-4 contract, it can verify the signatures, can know when we have received DKG public shares from all signers, and then add the constant coefficients of the polynomials to get the aggregate public key (no need to have a vote threshold as in Mini @setzeus)

The signer will have to do a separate manual call to the pox-4 contract to submit the full DKG Public Share packet with signature following a successful stacker db submission. This removes the obligation of the coordinator to submit other signer's shares/removes the need to have a vote threshold.

[jcnelson]

That could work, assuming you can get the contract to do the math right. IIRC the coefficients of the public polynomial P are curve points, so you'd be dealing with much larger numbers than can fit into uint. Perhaps the first task here would be to create such a math library, if one does not yet already exist?

The downside of this approach is that we lose the ability to switch the signing algorithm without doing a hard fork, since .pox-4 would assume that we're using WSTS (or something that, like WSTS, uses polynomial interpolation for DKG). But perhaps that's not a huge concern at this time?

[friedger]

@FriendsFerdinand implemented some 256bit maths in clarity https://github.com/FriendsFerdinand/clarity-tapscript/blob/main/contracts/uint256-lib.clar

He hit the block limits. Next step would be to reduce the costs by having a native clarity function.

[xoloki]

We only opened this issue because we had been told that clarity was going to get a p256k1 library wrapper. If that's not going to happen before nakamoto then we can punt this issue till it does.

[jcnelson]

We only opened this issue because we had been told that clarity was going to get a p256k1 library wrapper. If that's not going to happen before nakamoto then we can punt this issue till it does.

I have not heard this, but I'm not part of the Clarity WG. @obycode is this slated for inclusion in Clarity v3?

[xoloki]

@jcnelson all DKG schemes I know use some flavor of polynomial interpolation

[obycode]

We only opened this issue because we had been told that clarity was going to get a p256k1 library wrapper. If that's not going to happen before nakamoto then we can punt this issue till it does.

I have not heard this, but I'm not part of the Clarity WG. @obycode is this slated for inclusion in Clarity v3?

No, this was not on my radar yet. The only request I've been made aware of prior to this is to add 256-bit arithmetic. Should this be a priority?

[friedger]

If you ask me, then yes 😁

[FriendsFerdinand]

@obycode If we get a p256k1 library on clarity, I wouldn't need 256-bit arithmetic yet.

Assuming I can perform point addition, scalar multiplication

[xoloki]

To be clear, p256k1 will not give us arbitrary 256-bit arithmetic, we get 256-bit scalars modulo the group order, 256-bit field elements modulo the field size, and curve points with addition and scalar multiplication modulo the group order.

[obycode]

Could you all define what the types and/or function signature(s) that you want would look like?

[xoloki]

Assuming that we just need scalars and points, we would need something like

scalar-new (int) scalar-neg scalar-inv scalar-add (scalar, scalar) scalar-sub (scalar, scalar) scalar-mul (scalar, scalar) scalar-div (scalar, scalar) scalar-pow (scalar, scalar)

point-new point-add (point, point) point-sub (point, point) point-mul (point, scalar) point-multimul (list<point>, list<scalar>)

p256k1 also gives ecdsa and schnorr signatures, plus field elements. I'm assuming that we already wrap ecdsa signatures somewhere. If we plan on supporting schnorr signatures then we could wrap it here or wherever we're getting ecdsa. We should not need field elements unless we're gonna do taproot stuff by hand.

point-multimul is not strictly necessary, but will provide a significant speedup if we're doing large operations that involve summing up a series of point-mul ops.