Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2014-01-14 📝 Original message:On Mon, Jan 13, 2014 at ...

📅 Original date posted:2014-01-14
📝 Original message:On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
>
> > Uh while I'm responding again, what I'd discussed with Peter Todd in
> > IRC used two EC points in the stealth address. One for the payment and
> > one for the ECDH. The reason to use two is that it makes delegating
> > detection possible and so you don't have to have you spending keys
> > online to even detect these payments. Why'd that get dropped?
>
> I think this is exactly what I've implemented.
>
> I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping one of the pubKeys in the OP-RETURN, to prevent a malicious sender from triggering false positives on your online detection key when the funds are actually still fully controlled by the payer.
>
> You can still have a false positive (only 1 of 2 keys actually yours) but the funds would be trapped so it's unlikely anyone would do it.

How would they trigger false positives? The payee recovers the nonce
with ECDH from the payor's ephemereal pubkey and their online detection
secret key. They use BIP32 public derivation with their offline spending
pubkey(s), if the derived pubkeys match the actual scriptPubKey they
know the output is spendable by them. I don't see how that can go wrong.

--
'peter'[:-1]@petertodd.org
000000007dd7a87aec311fb7fb13770f54edf628e6976f8c6091a5b2638878a7
-------------- 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/20140114/7e3c7857/attachment.sig>;