On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman <jer...@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… ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
