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

All generators are equally "valid" when it comes to signatures

ah alright, thanks

There are more requirements when it comes to commitments, which require two of them

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

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.

we do force all tx to have 2 outs, with one decoy if necessary

although yes it could be even less granular of a filter

Oh I didn't know that, how is the decoy constructed?

0 amount, random recipient address

@philogy check out section 6.1 & 6.2 of Hush's Sietch protocol, which adds extra outputs like this

Not everything in that paper is correct, but I think that section 6 mostly makes sense

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

But that's definitely not an intractable problem, just need to keep an eye on the ratio of ring size : output counts

Are private keys `r` for transactions selected 2^252+27742317777372353535851937790883648493}

*selected from the range up to 2^252+27742317777372353535851937790883648493

Oh, or 7237005577332262213973186563042994240857116359379907606001950938285454250989

Any random scalars should be pulled uniformly from the full scalar range

Yea, I'm trying to confirm the upper bound of the range

(the numeric vaule)

It should be the group order

(minus 1)

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