{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-01-06\n📝 Original message:* Abstract\n\nA Stealth Address is a new type of Bitcoin address and related\nscriptPubKey/transaction generation scheme that allowers payees to\npublish a single, fixed, address that payors can send funds efficiently,\nprivately, reliably and non-interactively. Payors do not learn what\nother payments have been made to the stealth address, and third-parties\nlearn nothing at all. (both subject to an adjustable anonymity set)\n\n\n* Acknowledgments\n\nCredit goes to ByteCoin for the original idea.(1) Gregory Maxwell, Adam\nBack, and others on #bitcoin-wizards contributed valuable input on the\nimplementation. Finally thanks goes to Amir Taaki for input on the\ngeneral idea of stealth addresses and use-cases.\n\n\n* Background\n\nViewed generally a Bitcoin address is a mechanism by which a payee\ninstructs a payor to create a transaction such that the payee can spend\none or more of the transaction outputs. Of course, typically the address\nis simply the hash of a pubkey, and the mechanism by which the funds are\nmade available to the payee is to simply create a scriptPubKey of the\nfollowing form:\n\n    DUP HASH160 \u003cpubKeyHash\u003e EQUALVERIFY CHECKSIG\n\nThe problem however is address reuse: it is convenient for payees to\ngive one or more payor a single address and use it multiple times for\nvarious purposes. This results in all those payments becoming trivially\nlinkable to each other by an attacker - a threat not only to the privacy\nof the user, but also to all users of Bitcoin.(2)\n\nBIP32 hierarchical deterministic wallets are frequently proposed as a\nsolution. Now an address is a chain code and the mechanism by which a\nscriptPubKey is generated is to derive a one-time-use pubkey from that\nchain code and some index i. However, this quickly runs into two main\nproblems:\n\n1) Lack of privacy: While someone not in possession of the address can't\n   link payments together, someone who is can.\n\n2) State: If the index is not to be re-used wallets must either maintain\n   per-address state, or somehow query for already used indexes, or\n   somehow generate them in a sufficiently small range that the payee\n   can recover the indexes. All these solutions are problematic.\n\nA good example of where the BIP32-derivation solutions fails come up at\nthe Dark Wallet Hackathon where it was suggested by the author that for\nthe purpose of securing person-to-person payments OpenPGP public keys\nand X.509 certificates be extended with a new user-id field containing a\nBitcoin address. Wallet software could then use either certificate\nsystem to ensure funds were being sent to the intended recipients -\nessentially a non-interactive way of solving what the BIP70 payment\nprotocol solves interactively. Of course, without stealth addresses the\nscheme would likely have little or no privacy.\n\n\n* Requirements\n\n1) Generated scriptPubKey must be globally unique\n\n2) Must be only spendable by payee\n\n3) scriptPubKey and associated transaction must be indistinguishable to\n   third-parties from other transactions in some anonymity set.\n\n4) Method must be fully deterministic and funds recoverable from a\n   wallet seed and blockchain data for both payee and payor.\n\n5) Funds must be efficiently recoverable by payee with reasonable, and\n   configurable, computation and bandwidth costs.\n\n6) Must be compatible with CoinJoin/Must not leak information to payee\n   about what txins were used to pay them.\n\n7) Must be compatible with multisig-protected wallets.\n\n8) Must not make assumptions about txin scriptSig form.\n\n9) Must be possible to prove to third parties that payment was made in\n   accordance to instructions without revealing any other information.\n\n\n** Payment Reliability\n\nSchemes for making payments by transmitting nonces to the recipient\nthrough some other medium, such as Bitmessage, were discussed at the\nDark Wallet Hackathon. However using any medium but the blockchain\nitself for the communication means that the reliability of the payment\ngetting to the recipient is less than that of a standard transaction.\nFor instance Bitmessage nodes only keep messages for two weeks. We\ndecided that anything less than reliable atomic transactions was\nunacceptable.\n\n\n* Applying encryption to payments, simple explanation\n\nUsing Elliptic curve Diffie-Hellman (ECDH) we can generate a shared\nsecret that the payee can use to recover their funds. Let the payee have\nkeypair Q=dG. The payor generates nonce keypair P=eG and uses ECDH to\narrive at shared secret c=H(eQ)=H(dP). This secret could be used to\nderive a ECC secret key, and from that a scriptPubKey, however that\nwould allow both payor and payee the ability to spend the funds. So\ninstead we use BIP32-style derivation to create Q'=(Q+c)G and associated\nscriptPubKey.\n\nAs for the nonce keypair, that is included in the transaction in an\nadditional zero-valued output:\n\n    RETURN \u003cP\u003e\n\nThe payee recovers the funds by scanning the blockchain for candiate P's\nin transactions, regenerating the scriptPubKey, and finally checking if\nany txouts in the transactions match. Note the close similarity of this\ntechnique to how the Bitmessage network functions - an initial\nimplementation of the idea will find the Bitmessage code a suitable\nstarting point.\n\n\n* Trading off anonymity set size for decreased bandwidth/CPU\n\nBy taking advantage of prefix filters(3) we can choose a tradeoff\nbetween anonymity set size and bandwidth/CPU usage if the payee\nspecifies that payments to them are to match some short prefix k. There\nare a few possibilities for how the prefix is to the applied - the most\nsimple is if per-block indexes of scriptPubKeys are available:\n\n    RETURN \u003ck\u003e \u003cP\u003e\n\nAlternatively if per-block indexes of H(scriptPubKeys) are only\navailable the wallet software can grind the scriptPubKey with nonce i\nuntil it matches the specified prefix:\n\n    RETURN \u003ci\u003e \u003cP\u003e\n\nFurthermore as symmetric ciphers are quite cheap we might as well hide\nthe purpose of the OP_RETURN txout and encrypt the pubkey P using H(Q)\nas a symmetric key. This gives us a slightly larger anonymity set.\n\n\n* Advantages of using a separate output\n\nAn alternative would be to either re-use a pubkey or signature nonce\nvalue from a transaction input, saving about 45 bytes per txout. An\nabsolute minimum sized Bitcoin transaction is 166 bytes(4) so at best we\nhave a 27% savings in tx fees, and more typically around ~15%. (modulo\nmass-payments from a single txin)\n\nHowever using an explicit prunable OP_RETURN output to store the pubkey\nrather than re-using one from a txin or txin signature has a number of\nadvantages:\n\n1) The txin's owned by the payor are not revealed to the payee. In fact,\n   they could be held by a third-party who simply makes a transaction\n   with the appropriate txouts on behalf of the payee.\n\n2) Less information about the txouts is leaked. The statistical\n   distribution of txouts remains unchanged - not possible in re-use\n   schemes because they need to grind the payee scriptPubKey's for the\n   sake of the prefix filters.\n\n3) If required the nonce secret can be revealed to prove that a payment\n   was made to a third-party, e.g. for dispute resolution.\n\n\n* Bare CHECK(MULTI)SIG output alternative\n\nAn alternative with better efficiency could be to use bare\nOP_CHECK(MULTI)SIG outputs to hold the nonce pubkey - generally a second\noutput is needed anyway for change. The most simple would be to use Jeff\nGarzik's OP_DROP proposal(5) for the prefix:\n\n  \u003cprefix\u003e DROP n \u003cpubkey\u003e...\u003cpubkey\u003e m CHECKMULTISIG\n\n  or\n\n  \u003cprefix\u003e DROP \u003cpubkey\u003e CHECKSIG\n\nThe payor pubkey is in the *change* txout, and the payee's ECDH-derived\npubkey in the other txout. By setting the prefix to be the same on both\ntxouts and using the same basic scriptPubKey form the relationship of\nchange and payment is still hidden; CoinJoin-using implementations can\nadopt even more sophisticated approaches.\n\nIf IsStandard() rules remain the same and using OP_DROP is impractical,\nwe can also grind the change pubkey to match the prefix in a\ndeterministic manner so the wallet can still be recovered from a seed.\nMore costly, but maybe still acceptable for reasonably short prefixes.\nEither way the result is transactions that are actually smaller and\ncheaper than standard transactions, although without the advantage of\npushing scriptPubKey size payment to the receiver. (a pity we didn't\nspend the extra time to adopt OP_EVAL)\n\nA disadvantage is that revealing the nonce secret to prove a payment was\nmade is more problematic - either the txout needs to be spent first, or\nwe need a CHECKMULTISIG.\n\n\n* Address format\n\nTo be decided. To support mulisig we probably want the ability to\nspecify n-of-m master pubkeys, using the nonce to generate derived ones.\nFor the single pubkey case the addresses will be a little longer than\nstandard Bitcoin addresses:\n\n  s9KND3vfXjs3YqfZp86Acce3bM7Mhuptwh6mjeDnThsDei9Z2ZZcU\n\n  vs.\n\n  1LZn91ynrA6BCmoUKwnV3Ygk4FQMfPxLbg\n\n\n1) ByteCoin, Untraceable transactions which can contain a secure message\n   are inevitable, https://bitcointalk.org/index.php?topic=5965.0\n\n2) Gregory Maxwell, Dark Wallet Certification discussions, also\n   http://snowdenandthefuture.info/PartIII.html\n\n3) Peter Todd, [Bitcoin-development] Privacy and blockchain data,\n   http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03612.html\n\n4) Bitcoin Wiki, Maximum transaction rate,\n   https://en.bitcoin.it/w/index.php?title=Maximum_transaction_rate\u0026oldid=36983\n\n5) Jeff Garzik, Add small-data OP_DROP transactions as standard\n   transactions, https://github.com/bitcoin/bitcoin/pull/1809\n\n-- \n'peter'[:-1]@petertodd.org\n0000000000000002861ee0919fc86990573ac360820766dc1b9ba580e5ccf7b6\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 685 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140106/53d085cc/attachment.sig\u003e"}