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.


Attachment: signature.asc
Description: Digital signature

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
Bitcoin-development mailing list

Reply via email to