Subject: Re: [Bitcoin-development] Stealth Addresses

From: Alan Reiner <[email-masked]>
Date: Mon, 13 Jan 2014 16:15:01 -0500

On 01/13/2014 04:02 PM, Roy Badami wrote:
>> It's not public.  When I say "please pay me" I also say "use this
>> multiplier".
> Sending a "please pay me" message is really great for business
> transactions.
>
> But I think the use case that Peter Todd mentions is actually *the*
> most important currently under-addresesd use case:
>
>> With stealth addresses the user experience can be as simple as you
>> telling me on the phone "hey! send me that 0.234 BTC you owe me!",
>> me clicking on "Send to Alan Reiner (verified by PGP)" (perhaps
>> again on my off-line second factor device for a multi-sig wallet)
>> and tellling you "OK, sent".
> Lots of work is being done on handling consumer-to-merchant
> transactions.  BIP 70 does a good job of tackling the online purchase
> case, and the work that Andreas Schildbach is doing with Bluetooth and
> NFC will improve the options for a payer in a physical PoS transaction
> who might not have Internet connectivity on their smartphone.
>
> But relatively little work (that I know of) is being done on
> non-transactional personal payments - that is, being able to pay money
> to friends and other people that you have a face-to-face relationship
> with.
>
> What I want... no need... is to be able to open my wallet, select a
> friend from my address book, and transfer the $10 I owe them from the
> bar last night.
>
> I don't care - within reason - what process is involved in getting my
> friend set up in my address book.  That may well requires two way
> communication (e.g. over NFC).  But once it's set up, I should be able
> to just select the payee from the address book and send them some
> funds.  Anything else is just too complciated.
>
> I don't know if stealth addresses are the best solution to address
> this use case, but AFAIK the only current solution to this use case is
> to store a long-lived Bitcoin address in the addresss book.
>
> roy
>

Fair enough.  I haven't spent much time thinking about that use case. 
Though, I question the feasibility of anything that requires O(N) EC
multiply operations/sec, where N is the total volume of transactions
moving over the network.  But I guess if the prefix is big enough, the
scanning operations will remain feasible forever.