From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W2oqi-0003xq-PC for bitcoin-development@lists.sourceforge.net; Mon, 13 Jan 2014 21:15:08 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.128.51 as permitted sender) client-ip=209.85.128.51; envelope-from=etotheipi@gmail.com; helo=mail-qe0-f51.google.com; Received: from mail-qe0-f51.google.com ([209.85.128.51]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W2oqi-0005Uf-4Z for bitcoin-development@lists.sourceforge.net; Mon, 13 Jan 2014 21:15:08 +0000 Received: by mail-qe0-f51.google.com with SMTP id a11so506452qen.10 for ; Mon, 13 Jan 2014 13:15:02 -0800 (PST) X-Received: by 10.224.56.5 with SMTP id w5mr43257046qag.60.1389647702687; Mon, 13 Jan 2014 13:15:02 -0800 (PST) Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net. [76.111.96.126]) by mx.google.com with ESMTPSA id f8sm27240262qab.19.2014.01.13.13.15.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Jan 2014 13:15:02 -0800 (PST) Message-ID: <52D45755.60402@gmail.com> Date: Mon, 13 Jan 2014 16:15:01 -0500 From: Alan Reiner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Roy Badami References: <20140110102037.GB25749@savin> <20140113194049.GJ38964@giles.gnomon.org.uk> <52D4458C.6010909@gmail.com> <20140113201407.GB7941@petertodd.org> <52D44F86.1040407@gmail.com> <20140113210217.GO38964@giles.gnomon.org.uk> In-Reply-To: <20140113210217.GO38964@giles.gnomon.org.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (etotheipi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1W2oqi-0005Uf-4Z Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Stealth Addresses X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 21:15:08 -0000 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.