rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2014-01-20 📝 Original message:On Sat, Jan 18, 2014 at 05:12:58PM -0600, Jeremy Spilman wrote: > > > > On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner <etotheipi at gmail.com> wrote: > >> Isn't there a much faster asymmetric scheme that we can use? I've heard people talk about ed25519, though I'm not sure it can be used for encryption. > > > > Doing ECDH with our curve is within a factor of ~2 of the fastest > > encryption available at this security level, AFAIK. And separate > > encryption would ~double the amount of data vs using the ephemeral key > > for derivation. > > > > Using another cryptosystem would mandate carry around additional code > > for a fast implementation of that cryptosystem, which wouldn't be > > fantastic. > > > > So I'm not sure much can be improved there. > > 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... Keep in mind that Bitmessage uses the same ECDH mechanism as what stealth addresses will use. They seem to get decent enough performance from it for a use-case not-unlike that of a Bitcoin wallet. In any case I'm interested in knowing actual performance numbers for it; last I talked to Kyle Drake he said he was working on getting ECDH numbers on Javascript, probably the slowest possible implementation of the idea. As for send to stealth addresses using prefixes, he's confirmed that you'll be able to do that will well under a second to brute-force the prefixes with the proposed OP_RETURN mechanism even with rather long 8-bit prefixes. -- 'peter'[:-1]@petertodd.org 000000000000000190a2900f1a25c507a999fa11116f7bd0126618c1ebc4f5fb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 685 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140120/69317ce0/attachment.sig>