{"type":"rich","version":"1.0","author_name":"npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727","author_url":"https://nostr.ae/npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-01-12\n📝 Original message:\u003e Oh, sorry, I forgot to mention it in my first write-up but you can\n\u003e easily make stealth addresses include a second pubkey for the purpose of\n\u003e the communication that either isn't used in the scriptPubKey at all, or\n\u003e is part of a n-of-m multisig. (n\u003e=2) Interestingly that also means you\n\u003e can give a third-party that key and out-source the effort of scanning\n\u003e the blockchain for you.\n\nGreat point. Even if it's not a 3rd party, I think it's really important  \nto be able to scan for transactions with a key which can't actually spend  \nthe funds.\n\nThe first approach is just one-pass ECDH. I think you're saying the second  \napproach is two rounds of ECDH but re-using the same e/P (usually referred  \nto as r/R in ECIES). I think this is safe, unlike reusing an ephemeral key  \nfor signing operations.\n\n   Payee: Publish Q, Q2                     [d, d2 are privkeys, Q, Q2 are  \npubkeys]\n   Payer: 1) Generate ephemeral key: e / P  [e is privkey, P is pubkey]\n          2) S = e * Q                      [first shared secret]\n          3) S2 = e * Q2                    [second shared secret, reusing  \n'e']\n          4) Q' = Q + H(S)                  [pay-to stealth address]\n          5) Q2' = Q2 + H(S2)               [stealth 'marker']\n\n   Watch: 1) Look for TxOut with OP_RETURN \u003cP\u003e\n          2) Q2' = Q2 + H(d2 * P)\n          3) Check for Q2' elsewhere in the Tx\n\nS/MIME for example, allows reuse of the ephemeral keypair. When reusing an  \nephemeral keypair where A reuses (x, X) to encrypt different messages to  \nmore than one user, A should verify the static public keys to prevent  \nsmall-subgroup attacks.[1][2]\n\nLet's say you pay-to Q' and then Q2' value has to be somewhere else in the  \ntransaction. You could put it next to the shared P in OP_RETURN. OP_RETURN  \n\u003cP\u003e \u003cQ2'\u003e would be 66 bytes.\n\nBut then Mallory could generate transactions with the right Q2' but with  \nhis own pubkey in Step 2 instead of Q. So your scanner would detect a  \npayment, but you wouldn't be able to spend it, and Mallory could.\n\nThat's a good argument for putting Q2' in a 2-of-2 multisig so that  \npulling this trick would at least make the transaction unspendable for  \nboth parties, which may be good enough deterrent, but you're still going  \nto want to check it against your 'd' before fulfilling a large order. Your  \nonline watch process could queue the matching transactions, which you  \ncould move to your offline machine, decrypt your key, and verify the  \ntransactions are spendable.\n\nNow, you would need to get two pubkeys to the payer, throw in a prefix to  \nhelp standardize it, and end up with addresses that could look like (for  \nexample):\n\nxSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX\ntSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba\n\nThose addresses are 74 bytes:  \n\u003cPrefix\u003e\u003cCompressedPubKey1\u003e\u003cCompressedPubKey2\u003e\u003cChecksum\u003e\n\n   xSTL Prefix = 0xC0CB9270\n   tSTL Prefix = 0xB2E27D50\n   NOTE: I do NOT have the corresponding privkeys for these four pubkeys!\n\nThose just happened to be the first matching prefixes I found for 74 byte  \naddresses. I could try to find ones which start with a specific byte if  \nthat's somehow better, like 0x04 to match BIP32.\n\nUnfortunately, I don't think you can just derive a second public key from  \nthe first to keep the address shorter, and still keep the first private  \nkey secure, even if the second private key is stolen. You only get  \nequivalent security as BIP32 public derivation, where you can't lose a  \nchild private key.\n\nDo we also want xSTL (or whatever user friendly string) prefixes for  \nsingle pubkey (41 byte) stealth addresses?\n\nI'll wait a couple days for feedback, then I'll try to implement the  \nfollowing prototypes:\n\n1) Pay to STL addresses\n2) Watcher process to detect and queue STL payments for a given d2/Q2\n3) Offline verifier to take output from Watcher and verify spendable given  \nencrypted d/d2\n\nObviously extending QT directly for #1 would be ideal, I may even be able  \nto do that since supporting a new address type should be fairly contained.  \nBut if not I'll punt to writing a node.js or python script which connects  \nto bitcoind via RPC.\n\nThanks,\nJeremy\n\n[1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols\n       http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf\n\n[2] - Validation of Elliptic Curve Public Keys\n       http://www.iacr.org/archive/pkc2003/25670211/25670211.pdf"}