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: Sun, 12 Jan 2014 10:20:18 -0800	[thread overview]
Message-ID: <op.w9k6j4xryldrnw@laptop-air.hsd1.ca.comcast.net> (raw)
In-Reply-To: <CANEZrP0Np_FGhw=m6OffijByzz9r4D2AA78jCkzh=NZh=xrbjQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3384 bytes --]


> You can always just extend the payment protocol with the new fields as  
> well, vs making very long addresses.

I should have mentioned that as Task #4. Agree it could be an optional  
extension and backward compatible. 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. Probably easiest to implement in PP  
after the address and transaction building code is done.

So '4a' would be building a static PP file given the necessary inputs.  
When I get to that point, I'll send out a draft PP extension with  
fields/formats if someone else hasn't already. '4b' would be actually  
adding support for parsing those fields and generating the new transaction  
type into bitcoind.

Any thoughts on the prefix, and one vs two pubkey approach? First of all,  
do we try to support both equally, or favor one over the other? I was  
thinking we could have two different 4 byte prefixes but that both render  
as xSTL/tSTL in Base58 but correspond to the one vs two pubkeys expected.  
I think the chance of finding a single prefix which looks like xSTL for  
both address lengths is 1 in (58^4)^2, so that's probably not going to  
happen.

 From the payer/user perspective, short stealth vs. long stealth is  
irrelevant; they both have the same usability properties from the payer  
perspective. So giving them the same Base58 prefix seems like a good plan.

The full 4-byte prefix seems worth the usability trade-off versus 1-byte  
prefix, especially since it will impact the ability to lookup the  
transaction on an outside service, which I think a lot of people do to  
verify their payments. IMO a longer prefix isn't "wasting bytes" anywhere  
that it really counts.

We could save two bytes in the address if we required both pubkeys to  
start with '03', or save one byte if we required they both start with the  
same byte, but again doesn't seem worth it (to me) for the arbitrary  
restriction.

The actual internal wallet code for *receiving* STL payments and updating  
balances is more tricky and probably not something I can personally tackle  
for bitcoind. Assuming we even want first-class support for generating STL  
addresses and receiving STL payments in a standard user wallet, someone  
has to decide if the STL 'd' / 'd2' keys should be...

   1) Encrypted as usual, and then keep a list of blocks with interesting  
transactions, and go through them when the user enters their password?   
This would cause balances to update differently than how they do now, but  
perhaps be more secure.

   2) Kept unencrypted to allow live scanning as usual? Or keep just 'd2'  
unencrypted, with some new concept of 'unconfirmed' until the user enters  
their password to prove they can spend that TX? That kind of extra step  
seems OK for a merchant but sounds very scary for an average user.

   3) Kept encrypted under a separate password? Meh...

And last thought for now... At some point, we might want to decide on a  
convention to highlight these STL addresses as 'reusable' -- but similar  
questions around revocability remain. I hope we don't need anything like a  
UTC expiration time baked in to the address. A static PP file will have an  
expiration date either in the certificate or in 'expires' field, so I  
think if you want it to expire then use PP?

[-- Attachment #2.1: Type: text/html, Size: 3859 bytes --]

  reply	other threads:[~2014-01-12 18:20 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 [this message]
2014-01-12 18:26           ` Mike Hearn
2014-01-13  9:13             ` Jeremy Spilman
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.w9k6j4xryldrnw@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