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
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. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
