{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-01-12\n📝 Original message:You can always just extend the payment protocol with the new fields as\nwell, vs making very long addresses. If this technique can be made to work\nwell, it would have applicability in both fixed textual address context,\nand for a fixed/upload-once payment protocol file. That has the advantage\nof backwards compatibility as well - the new addresses would not be\nclickable or acceptable by old wallets, but with the payment protocol you\ncan always craft a bitcoin URI that contains a regular current style\naddress, and a link to a fixed payment protocol file (uploaded to a\npastebin type site), and modern wallets would ignore the address and use\nthe ECDH based system instead.\n\n\n\nOn Sun, Jan 12, 2014 at 11:33 AM, Jeremy Spilman \u003cjeremy at taplink.co\u003e wrote:\n\n\u003e \u003e Oh, sorry, I forgot to mention it in my first write-up but you can\n\u003e \u003e easily make stealth addresses include a second pubkey for the purpose of\n\u003e \u003e the communication that either isn't used in the scriptPubKey at all, or\n\u003e \u003e is part of a n-of-m multisig. (n\u003e=2) Interestingly that also means you\n\u003e \u003e can give a third-party that key and out-source the effort of scanning\n\u003e \u003e the blockchain for you.\n\u003e\n\u003e Great point. Even if it's not a 3rd party, I think it's really important\n\u003e to be able to scan for transactions with a key which can't actually spend\n\u003e the funds.\n\u003e\n\u003e The first approach is just one-pass ECDH. I think you're saying the second\n\u003e approach is two rounds of ECDH but re-using the same e/P (usually referred\n\u003e to as r/R in ECIES). I think this is safe, unlike reusing an ephemeral key\n\u003e for signing operations.\n\u003e\n\u003e    Payee: Publish Q, Q2                     [d, d2 are privkeys, Q, Q2 are\n\u003e pubkeys]\n\u003e    Payer: 1) Generate ephemeral key: e / P  [e is privkey, P is pubkey]\n\u003e           2) S = e * Q                      [first shared secret]\n\u003e           3) S2 = e * Q2                    [second shared secret, reusing\n\u003e 'e']\n\u003e           4) Q' = Q + H(S)                  [pay-to stealth address]\n\u003e           5) Q2' = Q2 + H(S2)               [stealth 'marker']\n\u003e\n\u003e    Watch: 1) Look for TxOut with OP_RETURN \u003cP\u003e\n\u003e           2) Q2' = Q2 + H(d2 * P)\n\u003e           3) Check for Q2' elsewhere in the Tx\n\u003e\n\u003e S/MIME for example, allows reuse of the ephemeral keypair. When reusing an\n\u003e ephemeral keypair where A reuses (x, X) to encrypt different messages to\n\u003e more than one user, A should verify the static public keys to prevent\n\u003e small-subgroup attacks.[1][2]\n\u003e\n\u003e Let's say you pay-to Q' and then Q2' value has to be somewhere else in the\n\u003e transaction. You could put it next to the shared P in OP_RETURN. OP_RETURN\n\u003e \u003cP\u003e \u003cQ2'\u003e would be 66 bytes.\n\u003e\n\u003e But then Mallory could generate transactions with the right Q2' but with\n\u003e his own pubkey in Step 2 instead of Q. So your scanner would detect a\n\u003e payment, but you wouldn't be able to spend it, and Mallory could.\n\u003e\n\u003e That's a good argument for putting Q2' in a 2-of-2 multisig so that\n\u003e pulling this trick would at least make the transaction unspendable for\n\u003e both parties, which may be good enough deterrent, but you're still going\n\u003e to want to check it against your 'd' before fulfilling a large order. Your\n\u003e online watch process could queue the matching transactions, which you\n\u003e could move to your offline machine, decrypt your key, and verify the\n\u003e transactions are spendable.\n\u003e\n\u003e Now, you would need to get two pubkeys to the payer, throw in a prefix to\n\u003e help standardize it, and end up with addresses that could look like (for\n\u003e example):\n\u003e\n\u003e\n\u003e xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX\n\u003e\n\u003e tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba\n\u003e\n\u003e Those addresses are 74 bytes:\n\u003e \u003cPrefix\u003e\u003cCompressedPubKey1\u003e\u003cCompressedPubKey2\u003e\u003cChecksum\u003e\n\u003e\n\u003e    xSTL Prefix = 0xC0CB9270\n\u003e    tSTL Prefix = 0xB2E27D50\n\u003e    NOTE: I do NOT have the corresponding privkeys for these four pubkeys!\n\u003e\n\u003e Those just happened to be the first matching prefixes I found for 74 byte\n\u003e addresses. I could try to find ones which start with a specific byte if\n\u003e that's somehow better, like 0x04 to match BIP32.\n\u003e\n\u003e Unfortunately, I don't think you can just derive a second public key from\n\u003e the first to keep the address shorter, and still keep the first private\n\u003e key secure, even if the second private key is stolen. You only get\n\u003e equivalent security as BIP32 public derivation, where you can't lose a\n\u003e child private key.\n\u003e\n\u003e Do we also want xSTL (or whatever user friendly string) prefixes for\n\u003e single pubkey (41 byte) stealth addresses?\n\u003e\n\u003e I'll wait a couple days for feedback, then I'll try to implement the\n\u003e following prototypes:\n\u003e\n\u003e 1) Pay to STL addresses\n\u003e 2) Watcher process to detect and queue STL payments for a given d2/Q2\n\u003e 3) Offline verifier to take output from Watcher and verify spendable given\n\u003e encrypted d/d2\n\u003e\n\u003e Obviously extending QT directly for #1 would be ideal, I may even be able\n\u003e to do that since supporting a new address type should be fairly contained.\n\u003e But if not I'll punt to writing a node.js or python script which connects\n\u003e to bitcoind via RPC.\n\u003e\n\u003e Thanks,\n\u003e Jeremy\n\u003e\n\u003e [1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols\n\u003e        http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf\n\u003e\n\u003e [2] - Validation of Elliptic Curve Public Keys\n\u003e        http://www.iacr.org/archive/pkc2003/25670211/25670211.pdf\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e CenturyLink Cloud: The Leader in Enterprise Cloud Services.\n\u003e Learn Why More Businesses Are Choosing CenturyLink Cloud For\n\u003e Critical Workloads, Development Environments \u0026 Everything In Between.\n\u003e Get a Quote or Start a Free Trial Today.\n\u003e\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=119420431\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140112/2c0d73d8/attachment.html\u003e"}