10:20:26 <philogy> You know how Monero's pedersen commitments use another generator point H would the EdDSA scheme as described in zero to monero section 2.4.3 with public keys using H as their generator instead of G? Would they be just as or similarly secure? I'm not too familiar with the detailed maths and therefore don't fully know if the generator needs to have some special properties. Thanks again
11:47:20 <sarang> All generators are equally "valid" when it comes to signatures
11:48:01 <philogy> ah alright, thanks
11:48:05 <sarang> There are more requirements when it comes to commitments, which require two of them
11:54:59 <philogy> I have a question, why doesn't Monero make transactions more uniform by enforcing wallets to have to create "decoy outputs" up to a certain amount. These "decoy outputs" would contain no Monero and be sent to randomly generated addresses but would lead to more privacy. Like this a churn transaction would be indistinguishable from a 3 output or a 5 output transaction. It would lead to more load on the bloc
11:54:59 <philogy>  increased privacy would be worth it. This could be enforced on a consensus level by setting a fixed output interval so transactions with 1-5 outputs must have 5, 6-10 must have 10 and so on.
11:56:55 <UkoeHB_> we do force all tx to have 2 outs, with one decoy if necessary
11:58:22 <UkoeHB_> although yes it could be even less granular of a filter
11:58:34 <philogy> Oh I didn't know that, how is the decoy constructed?
11:58:49 <UkoeHB_> 0 amount, random recipient address
16:56:27 <Isthmus> @philogy check out section 6.1 & 6.2 of Hush's Sietch protocol, which adds extra outputs like this
16:56:33 <Isthmus> https://github.com/MyHush/sietch-whitepaper/blob/master/sietch.pdf
16:56:48 <Isthmus> Not everything in that paper is correct, but I think that section 6 mostly makes sense
16:57:21 <Isthmus> There's a tradeoff though, because we want the number of outputs that don't show up in a ring to stay low (ideally zero!) since that leaks the spend state
16:58:31 <Isthmus> But that's definitely not an intractable problem, just need to keep an eye on the ratio of ring size : output counts
16:59:07 <Isthmus> Are private keys `r` for transactions selected 2^252+27742317777372353535851937790883648493}
16:59:23 <Isthmus> *selected from the range up to 2^252+27742317777372353535851937790883648493
17:01:27 <Isthmus> Oh, or 7237005577332262213973186563042994240857116359379907606001950938285454250989
17:12:30 <sarang> Any random scalars should be pulled uniformly from the full scalar range
17:48:20 <Isthmus> Yea, I'm trying to confirm the upper bound of the range
17:48:49 <Isthmus> (the numeric vaule)
17:58:31 <sarang> It should be the group order
17:59:34 <sarang> (minus 1)
19:50:14 <philogy> Isthmus: ah I didn't think about that, the ring size: output ratio is quite an important. Well in addition to enforcing decoys one could also increase the ring size to maintain a solid ratio, especially with the upcoming launch of CLSAG the space savings could be utilized to increase anonymity by creating decoys and upping the ring size