📅 Original date posted:2014-01-08
📝 Original message:Thanks Peter for the paper!
I'm just going to restate your 'simple explanation' to make sure I got
it...
The payee publishes a public key of theirs, which will be a long-standing
identifier, public key = 'Q', corresponding private key = 'd'.
To pay them, payee generate a keypair, private key = 'e' public key of
'P'. Publish 'P' in the transaction.
The payer can calculate S = eQ, where S is a shared secret between
payer/payee. The payee calculates the same S as S = dP. So the payee sees
'P' in a transaction, and multiplies by their private key, to get S.
Now that we have the shared secret, either side can calculate an offset to
Q which becomes the pay-to-address. When you say BIP32-style derivation,
Q' = H(S) + Q, does this mean Q + SHA256(33-byte S)?
A payee has to check each transaction (or every transaction of a fixed
prefix) with 'P', calculate Q' = Q + H(dP) and see if that transaction
pays to Q'. If the address matches, then the payee can spend it with
private key of d + H(dP).
One downside is that you have to hold your private key in memory
unencrypted in order to identify new payments coming in. So
stealth-addresses may not be suitable for receiving eCommerce payments,
since you can't implement a corresponding watch-only wallet, e.g. there's
no way to "direct-deposit into cold storage."
Hope I got that right...
On Mon, 06 Jan 2014 04:03:38 -0800, Peter Todd <pete at petertodd.org> wrote:
> Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared
> secret that the payee can use to recover their funds. Let the payee have
> keypair Q=dG. The payor generates nonce keypair P=eG and uses ECDH to
> arrive at shared secret c=H(eQ)=H(dP). This secret could be used to
> derive a ECC secret key, and from that a scriptPubKey, however that
> would allow both payor and payee the ability to spend the funds. So
> instead we use BIP32-style derivation to create Q'=(Q+c)G and associated
> scriptPubKey.
>
> As for the nonce keypair, that is included in the transaction in an
> additional zero-valued output:
> RETURN <P>
Jeremy Spilman [ARCHIVE] /
npub10e…jc727
2023-06-07 15:11:34
in reply to nevent1q…ym7a
Author Public Key
npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727Published at
2023-06-07 15:11:34Event JSON
{
"id": "5246e668296bcde617bbdddd28efbdf85ef368c4ff063e1bd67c5297150fb7bc",
"pubkey": "7e57666cff7c86f9410d33d4d34ef3e5105395b3c74af472541dbeeb743f9de3",
"created_at": 1686150694,
"kind": 1,
"tags": [
[
"e",
"6b79d8c7bec3dc6952db91cc68d0510d9897c37dcf58a24d8e2f4288fe42525c",
"",
"root"
],
[
"e",
"5e5a63aeb042d608650c9f6a220e069efb299e321aa602c12b46d631cbbbfbf0",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2014-01-08\n📝 Original message:Thanks Peter for the paper!\n\nI'm just going to restate your 'simple explanation' to make sure I got \nit...\n\nThe payee publishes a public key of theirs, which will be a long-standing \nidentifier, public key = 'Q', corresponding private key = 'd'.\n\nTo pay them, payee generate a keypair, private key = 'e' public key of \n'P'. Publish 'P' in the transaction.\n\nThe payer can calculate S = eQ, where S is a shared secret between \npayer/payee. The payee calculates the same S as S = dP. So the payee sees \n'P' in a transaction, and multiplies by their private key, to get S.\n\nNow that we have the shared secret, either side can calculate an offset to \nQ which becomes the pay-to-address. When you say BIP32-style derivation, \nQ' = H(S) + Q, does this mean Q + SHA256(33-byte S)?\n\nA payee has to check each transaction (or every transaction of a fixed \nprefix) with 'P', calculate Q' = Q + H(dP) and see if that transaction \npays to Q'. If the address matches, then the payee can spend it with \nprivate key of d + H(dP).\n\nOne downside is that you have to hold your private key in memory \nunencrypted in order to identify new payments coming in. So \nstealth-addresses may not be suitable for receiving eCommerce payments, \nsince you can't implement a corresponding watch-only wallet, e.g. there's \nno way to \"direct-deposit into cold storage.\"\n\nHope I got that right...\n\nOn Mon, 06 Jan 2014 04:03:38 -0800, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared\n\u003e secret that the payee can use to recover their funds. Let the payee have\n\u003e keypair Q=dG. The payor generates nonce keypair P=eG and uses ECDH to\n\u003e arrive at shared secret c=H(eQ)=H(dP). This secret could be used to\n\u003e derive a ECC secret key, and from that a scriptPubKey, however that\n\u003e would allow both payor and payee the ability to spend the funds. So\n\u003e instead we use BIP32-style derivation to create Q'=(Q+c)G and associated\n\u003e scriptPubKey.\n\u003e\n\u003e As for the nonce keypair, that is included in the transaction in an\n\u003e additional zero-valued output:\n\u003e RETURN \u003cP\u003e",
"sig": "c75252fd964db34a833c5cad28216161249b0dc92984f42174dbac9b256590436dccb9d7a53ec28cad7348a3db1006dfc35680f5d0f5860ed324b81305191b0b"
}