{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-01-18\n📝 Original message:On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman \u003cjeremy at taplink.co\u003e wrote:\n\u003e 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.\n\u003e\n\u003e 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...\n\u003e\n\u003e 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...\n\nWell super-fast hand optimized code for (your choice of) 160 bit curve\nmay not ever exist, making it slower in practice. Plus the extra code\nto carry around even if it does exist…"}