public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jeremy Spilman" <jeremy@taplink.co>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Stealth Addresses
Date: Mon, 13 Jan 2014 01:13:08 -0800	[thread overview]
Message-ID: <op.w9mbv6dcyldrnw@laptop-air.hsd1.ca.comcast.net> (raw)
In-Reply-To: <CANEZrP06EiiY+5hL05bxzdcFXS8V7S1KOiZj86a_ZP5EcoaMKA@mail.gmail.com>

On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
> > I think for displaying the payment in the UI after it's been made via  
> PP, we have to fully
> > support sending to a new standard address type anyway.

On Sun, 12 Jan 2014 10:26:18 -0800, Mike Hearn <mike@plan99.net> wrote:
> Why? Showing an address is meaningless, especially if the user didn't  
> type it in or see
> it somewhere else. It's just an opaque random number, all putting it in  
> the UI can do is
> make it look scarier :)
>
> Part of the point of the payment protocol is it lets merchants provide  
> human readable text
> for transactions instead of addresses.

Of course you're right, moving away from addresses is definitely part of  
the point of PP.

On Sun, 12 Jan 2014 13:18:33 -0800, Gavin Andresen  
<gavinandresen@gmail.com> wrote:
> No, please. Make it easy for non-geeks, extend the payment protocol, or  
> we'll spend the next
> two years writing code that tries to ignore linebreaks and spaces and  
> changing <input> in HTML
> forms to <textarea>...

Agreed, it's long enough to be even more problematic than usual. If the  
general consensus is that there should not even be a standardized address  
form, then I can skip that entirely, and go straight to trying to extend  
PP.

It's a given this will be implemented for Payment Protocol. The question  
is whether it's also usable outside of PP.

I was kind of imagining that we could encourage people to replace all  
their static address text that live on Github pages, and README.me, and  
forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention  
could be to require only transporting xSTL addresses within a URI, even  
going so far as to not support them copy/pasted. 101 characters is not  
much longer (and sometimes shorter) than PaymentRequest URIs end up being.

I think there are ways to make stealth addresses easy enough to use that  
people actually prefer using them for P2P payments which do not involve a  
full-stack merchant. In that case, if it was a PaymentRequest it would  
almost certainly not be signed, and would be more easily shared over email  
or SMS as a URI than as a file attachment or, even worse, putting the  
unsigned PR file up on a third-party server which probably won't do a good  
job securing it.

* PP Implementation Overview *

The basic PaymentRequest>PaymentDetails is expecting 'output' containing  
one or more TxOuts with script and amount. I believe the general approach  
is to put a fallback address into 'output' for backward compatibility, and  
put Q and Q2 into an extension field.

So we add a new optional field to PaymentDetails which contains the one or  
two PubKeys. Not sure if we want different protobuf tags, or if the  
difference in length of the value makes it obvious enough which approach  
is being used;

    optional bytes stealthOnePubKey = 1000
    optional bytes stealthTwoPubKey = 1001

or just

    optional bytes stealth = 1000

* User Interaction / Flow *

Lets follow this through from the user perspective, starting with what it  
looks like today. I'm having a hard time finding screenshots of what PP  
looks like in BitcoinQT, so I built from HEAD and using Gavin's  
Handy-Dandy PaymentRequest Generator  
(https://bitcoincore.org/~gavin/createpaymentrequest.php):

Screenshots: http://imgur.com/a/k6j9D

Image 1 - 'Send' screen after clicking a PR URI with a small transaction  
and auto-calculated fee
Image 2 - System Tray notification after clicking 'Send'
Image 3 - Transaction List showing partially confirmed transaction
Image 4 - Transactions details popup

We see 'Pay To' (Common Name from the cert) and 'Memo' on the Send screen.  
The System Tray notification popup and Transaction List shows just the  
address string. The 'Transaction details' window shows 'Merchant' which I  
think is the same as 'Pay To'. You also have 'Copy address' option in the  
right-click menu.

Memo seems not to be saved, or at least not visible in the UI after  
sending a payment.

* Transaction Display *

The address string is fairly pervasive, which is why I was originally  
thinking it would make sense to implement all the address handling first,  
so all those screens would continue to work as specified, without trying  
to hack something different in those fields.

Without digging too far into the code, it looks like "address" displayed  
is derived from the TxOut -- e.g. script.cpp:ExtractDestination. This  
could be a bit problematic depending on what we really want to show to the  
user -- the stealth multisig, or the pubkeys?

Part of the point of stealth addresses is actually making them reusable.  
So if you're the originator of the payment, you might want the wallet to  
tag that transaction somehow with the pubkeys used to generate it.

Also, ideally I think I would want multiple different stealth payments  
within a single wallet to the same merchant / pubkeys to be identifiable  
as such.

* Sample Code *

Will follow in another email, to be sent shortly!




  reply	other threads:[~2014-01-13  9:13 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-06 12:03 [Bitcoin-development] Stealth Addresses Peter Todd
2014-01-08 10:20 ` Jeremy Spilman
2014-01-10 10:20   ` Peter Todd
2014-01-10 11:28     ` Drak
2014-01-10 12:00       ` Peter Todd
2014-01-12 10:33     ` Jeremy Spilman
2014-01-12 12:51       ` Mike Hearn
2014-01-12 18:20         ` Jeremy Spilman
2014-01-12 18:26           ` Mike Hearn
2014-01-13  9:13             ` Jeremy Spilman [this message]
2014-01-14 14:15               ` Peter Todd
2014-01-14 17:54                 ` Odinn Cyberguerrilla
2014-01-12 21:18       ` Gavin Andresen
2014-01-13  9:52         ` Gregory Maxwell
2014-01-13 10:39           ` Mike Hearn
2014-01-13 13:37             ` Roy Badami
2014-01-13 15:58               ` Mike Hearn
2014-01-13 20:11                 ` Roy Badami
2014-01-14 22:53                 ` Roy Badami
2014-01-15  0:19                   ` Drak
2014-01-15 20:22                     ` Ben Davenport
2014-01-15 20:38                       ` Gregory Maxwell
2014-01-15 20:44                         ` Jeff Garzik
2014-01-15 22:38                           ` [Bitcoin-development] Static addresses on chains encouraging address *RE* use Troy Benjegerdes
2014-01-15 23:01                           ` [Bitcoin-development] Stealth Addresses Mike Hearn
2014-01-15 23:04                           ` Roy Badami
2014-01-15 23:07                             ` Jeff Garzik
2014-01-15 23:17                               ` Roy Badami
2014-01-15 23:19                                 ` Roy Badami
2014-01-15 23:09                           ` [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses) Adam Back
2014-01-16  1:02                             ` Jeremy Spilman
2014-01-16  1:32                               ` Gregory Maxwell
2014-01-18 17:44                                 ` Troy Benjegerdes
2014-01-18 20:25                                   ` Christophe Biocca
2014-01-20 11:11                                   ` Peter Todd
2014-01-21  4:00                                 ` Jeremy Spilman
2014-01-24  9:17                                   ` Peter Todd
2014-01-16 11:42                               ` Adam Back
2014-01-16 18:19                                 ` Troy Benjegerdes
2014-01-16  0:05                           ` [Bitcoin-development] Stealth Addresses Jeremy Spilman
2014-01-16  0:10                             ` Gregory Maxwell
2014-01-16  0:24                             ` Mark Friedenbach
2014-01-16  0:44                             ` Eric Martindale
2014-01-16  6:26                               ` Gary Rowe
2014-01-16  9:48                                 ` Wladimir
2014-01-16  1:16                             ` Odinn Cyberguerrilla
2014-01-16 10:14                             ` Drak
2014-01-16 10:19                               ` Mike Hearn
2014-01-16 11:12                               ` [Bitcoin-development] reusable address privacy problems & fuzzy bait limitations (Re: Stealth Addresses) Adam Back
2014-01-16 21:28                             ` [Bitcoin-development] Stealth Addresses Peter Todd
2014-01-17  2:30                               ` Johnathan Corgan
2014-01-17  3:13                               ` Jeremy Spilman
2014-01-17  7:49                               ` Drak
2014-01-17  9:15                                 ` Mike Hearn
2014-01-17  9:19                                   ` Mark Friedenbach
2014-01-17  9:23                                   ` Natanael
2014-01-17  9:59                                   ` Drak
2014-01-17 20:16                                     ` Cameron Garnham
2014-01-17 14:46                                   ` Peter Todd
2014-01-17 19:21                                     ` Ben Davenport
2014-01-18  4:55                                       ` Alan Reiner
2014-01-18  5:09                                         ` Gregory Maxwell
2014-01-18 23:12                                           ` Jeremy Spilman
2014-01-18 23:50                                             ` Gregory Maxwell
2014-01-20 11:08                                             ` Peter Todd
2014-01-13 19:53               ` Roy Badami
2014-01-13 19:57                 ` Mike Hearn
2014-01-13 20:01                   ` Roy Badami
2014-01-13 19:40           ` Roy Badami
2014-01-13 19:44             ` Drak
2014-01-13 19:59               ` Alan Reiner
2014-01-13 20:10                 ` Gregory Maxwell
2014-01-13 20:15                   ` Peter Todd
2014-01-13 22:02                   ` Jeremy Spilman
2014-01-14 14:19                     ` Peter Todd
2014-01-14 19:12                       ` Jeremy Spilman
2014-01-14 20:48                         ` Peter Todd
2014-01-14 21:51                         ` Adam Back
2014-01-14 22:34                           ` Jeremy Spilman
2014-01-13 20:14                 ` Peter Todd
2014-01-13 20:41                   ` Alan Reiner
2014-01-13 20:47                     ` Gregory Maxwell
2014-01-13 21:02                     ` Roy Badami
2014-01-13 21:15                       ` Alan Reiner
2014-01-13 21:27                         ` Peter Todd
     [not found]                           ` <op.w9ne31oqyldrnw@laptop-air.hsd1.ca.comcast.net>
2014-01-14 12:10                             ` Peter Todd
2014-03-06 12:23 ` Dan Carter
     [not found] <mailman.417890.1389952750.21953.bitcoin-development@lists.sourceforge.net>
2014-01-17 12:16 ` joseph

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=op.w9mbv6dcyldrnw@laptop-air.hsd1.ca.comcast.net \
    --to=jeremy@taplink.co \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox