FROST

[BowTiedDeployer]

Why FROST?

FROST (Flexible Round Optimization Schnorr Threshold) is a cryptographic technique used in Bitcoin for multi-signature transactions. It allows for more efficient and secure transactions compared to traditional multi-sig setups. When combined with taproot, FROST can further improve the privacy and scalability of Bitcoin transactions. By using FROST in a taproot setup, users will take advantage of these benefits while also improving the efficiency and security of multi-sig transactions.

How does this fit in the Decentralized Mining Pool?

• more in-depth here https://stacksdegens.notion.site/Decentralized-Mining-Pool-c0796bf750984d1e86d68f78287076d4

Miners will sign together the transactions which will send the BTC to the PoX address. Also, they will sign together the transaction to commit the block.

What is the threshold and how is it picked?

The threshold is the minimum number of signatures required to execute a transaction. A threshold is set in advance, and a transaction can only be executed if it is signed by at least that number of miners. The threshold serves as a security measure, ensuring that funds can only be spent with the agreement of a sufficient number of miners. By doing this it takes into account that at least that number of miners represent good actors in the whole scenario. The threshold number has to be high in order to always make it hard for bad actors to have any kind of control.

Because of the dynamicity of the mining pool where miners can be added or removed, the DKG (Distributed Key Generation) will be triggered in 2 cases:

1. by removing miners. If a lower value is reached after X miners are removed from the pool, the threshold - number of miners ratio becomes too big and now a lower amount of bad actors is enough in order to stop the completion of signing.
2. by adding miners. New miners need to be part of the FROST in order to take part in the signing of the transactions. A time period or a number of miners pending to join the pool after being accepted should be a trigger that will add the pending miners and recreate the DKG using the new miners.

[BowTiedDeployer]

Info

N = total number of miners
T = threshold number/percentage

Threshold value when performing DKG

The main objective is that the T value performs well for a mining pool having hundreds of miners taking part in it.

Table containing data sample for multiple T values in relation to N .

N	67%	T - 67	75%	T - 75	80%	T - 80
1	-0.33	1	-0.25	1	-0.2	1
2	0.34	1	0.5	1	0.6	1
3	1.01	1	1.25	1	1.4	1
4	1.68	1	2	2	2.2	2
5	2.35	2	2.75	2	3	3
6	3.02	3	3.5	3	3.8	3
7	3.69	3	4.25	4	4.6	4
8	4.36	4	5	5	5.4	5
9	5.03	5	5.75	5	6.2	6
10	5.7	5	6.5	6	7	7
11	6.37	6	7.25	7	7.8	7
12	7.04	7	8	8	8.6	8
13	7.71	7	8.75	8	9.4	9
14	8.38	8	9.5	9	10.2	10
15	9.05	9	10.25	10	11	11
16	9.72	9	11	11	11.8	11
17	10.39	10	11.75	11	12.6	12
18	11.06	11	12.5	12	13.4	13
19	11.73	11	13.25	13	14.2	14
20	12.4	12	14	14	15	15
21	13.07	13	14.75	14	15.8	15
22	13.74	13	15.5	15	16.6	16
23	14.41	14	16.25	16	17.4	17
24	15.08	15	17	17	18.2	18
25	15.75	15	17.75	17	19	19
26	16.42	16	18.5	18	19.8	19
27	17.09	17	19.25	19	20.6	20
50	32.5	32	36.5	36	39	39
100	66	66	74	74	79	79
200	133	133	149	149	159	159
400	267	267	299	299	319	319

What would be a sweet spot for changing the threshold when miners are removed from the mining pool?

T value selected: integer part of ( 67% N-1 )

Regarding the update of the T threshold when miners leave/ are removed from the mining pool
( because they act as bad actors ) we tried to find a T in such a way that the DKG process
doesn't happen too often, but there is also not a great risk of not having enough participants to
cover the T value.

Will list below some use cases that display 75% and 85% for recalculations.

15 users

T=9 ⇒ 9 votes need to take action

1 user removed ⇒ N=14
new T_percentage=9/(14-1)=0.69<0.85; 0.69<0.75 → SIGNATURE WON’T CHANGE

1 user removed ⇒ N=13
new T_percentage=9/(13-1)=0.75<0.85; 0.75≥0.75
-> For T=0.75 -> Recalculate T, dkg

1 user removed ⇒ N=12
new T_percentage=10/12=0.83<0.85

1 user removed ⇒ N=11
new T_percentage=10/11=0.9>0.85
-> For T=0.85 -> Recalculate T, dkg

20 users

T=12

1 user removed ⇒ N=19
new T_percentage=12/(19-1)=0.67<0.85; 0.67<0.75 → SIGNATURE WON’T CHANGE

1 user removed ⇒ N=18
new T_percentage=12/(18-1)=0.71<0.85; 0.71<0.75

1 user removed ⇒ N=17
new T_percentage=12/(17-1)=0.75<0.85; 0.75≥0.75
-> For T=0.75 -> Recalculate T, dkg

1 user removed ⇒ N=16
new T_percentage=12/(16-1)=0.8<0.85;

1 user removed ⇒n=15
new T_percentage=12/(15-1)=0.86≥0.85
-> For T=0.85 -> Recalculate T, dkg

50 users

T=32
for 0.75 change ⇒ signature will change when there are 43 users remaining (32/42=0.76>0.75)
for 0.85 change ⇒ signature will change when there are 38 users remaining (32/37=0.86>0.85)

Transactions that have to be signed by at least 32 out of 39 seem a bit odd.
Would consider the limit of 32 out of 44 a better ratio.
=> better with 75% .

What would be a sweet spot for changing the threshold when miners are added to the mining pool?

The flow proposed consist of miners asking to join the mining pool. If the threshold acceptance vote is passed for a given miner, the miner will be removed from the pending-to-join-by-vote list and added to a waiting-to-join list. Miners from the latter list will be added if it reaches a specific number of users or a selected number of blocks has passed from the last time the list was accepted.

For all of these, multiple factors have to be taken into account in order to create the best value flow for the miners. Things to consider, but not limited to, computation done every time the miners list changes, the DKG costs, the block penalization.

Why does block penalization appear?

Starting a new DKG will give a new public and private key to the MultiSig account which means the process of mining will be seen by the PoX as if it just started for the mining pool.

Today, a Stacks miner's probability of winning a sortition is proportional to the minimum of the spend from last block-commit mined, and the median spend of the last six block-commits sent.
https://github.com/stacksgov/sips/blob/feat/sip-015/sips/sip-015/sip-015-network-upgrade.md#fixed-miner-block-commit-grace-period

[BowTiedDeployer]

TM FROST issue and pull request in core-eng repo.