12:23:05 <selsta> .merges
12:23:05 -xmr-pr- 8747 8850 8854 8888 8892 8894 8895 8899 8900 8901 8902 8903 8904 8905 8908 8909 8916 8917 8919
14:54:42 <SNeedlewoods> hey, I assume it's not a big deal, but at least I want to report that the following can trigger OCD
14:55:19 <SNeedlewoods> in monero/src/gen_multisig/gen_multisig.cpp line 216:
14:55:19 <SNeedlewoods> tools::fail_msg_writer() << (boost::format(genms::tr("Error: expected N > 1 and N <= M, but got N==%u and M==%d")) % threshold % total).str();
14:56:04 <SNeedlewoods> threshold and total are both defined as uint32_t but one gets formatted with %u and the other one with %d
15:11:44 <sech1> Technically correct, but in practice M will never exceed 2^31
15:17:08 <jeffro256[m]> New multisig application with threshold 2^30/2^31 - you must get the population of china to agree on your transaction
15:29:27 <UkoeHB> 8662, 8920 ready for review
15:30:03 <jeffro256[m]> How does performance scale with the number of signers ? I can see something ridiculous like that used for large organizations where stakeholders vote on budget spending
15:30:43 <jeffro256[m]> It requires n^2 communications yeah ?
15:30:58 <jeffro256[m]> Anything bigger than that?
15:31:26 <UkoeHB> N is capped to 16 right now
15:33:36 <UkoeHB> you need at most N communications, but message size is O(N - 1 choose min(N-M, N/2))
16:31:49 <selsta> .merge+ 8662
16:31:49 <xmr-pr> Added