Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2014-01-18 📝 Original message:On Sat, Jan 18, 2014 at ...
📅 Original date posted:2014-01-18
📝 Original message:On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman <jeremy at taplink.co> wrote:
> In the case where payment is being sent only to Q1, and Q2 is for discovery only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication.
>
> 80-bits of security I assume still greatly exceeds the actual level of privacy you get with the overall solution, and since Q2 is never protecting actual funds...
>
> But if it's a "real weakening" of the privacy then definitely not worth it, and even the added complexity of another curve seems possibly not worth it...
Well super-fast hand optimized code for (your choice of) 160 bit curve
may not ever exist, making it slower in practice. Plus the extra code
to carry around even if it does exist…
📝 Original message:On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman <jeremy at taplink.co> wrote:
> In the case where payment is being sent only to Q1, and Q2 is for discovery only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication.
>
> 80-bits of security I assume still greatly exceeds the actual level of privacy you get with the overall solution, and since Q2 is never protecting actual funds...
>
> But if it's a "real weakening" of the privacy then definitely not worth it, and even the added complexity of another curve seems possibly not worth it...
Well super-fast hand optimized code for (your choice of) 160 bit curve
may not ever exist, making it slower in practice. Plus the extra code
to carry around even if it does exist…