From: Taylor Gerring <taylor.gerring@gmail•com>
To: System undo crew <unsystem@lists•dyne.org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] [unSYSTEM] DarkWallet Best Practices
Date: Fri, 20 Dec 2013 11:32:57 -0600 [thread overview]
Message-ID: <910AE313-00A5-4DEB-8974-742FE0B14116@gmail.com> (raw)
In-Reply-To: <52B359C4.3050106@sindominio.net>
[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]
I’m inclined to agree, as this was discussed on multiple occasions and seems to fix a lot of the address re-use problems. With hot topics like “coin validation”, I think it’s important to highlight the privacy that generating fresh addresses from public extended keys grants us.
Also thinking about implications regarding non-merchant use of Payment Protocol, encouraging the exchange of extended public keys instead of a single address could be a boon for Payment Protocol to actually be useful for users. Initially, the idea was that the merchant would generate a new address from an extended key and include that in the Payment Request. How do we handle pushing the extended public key down to the wallet itself? Do we just shoehorn the exchange of keys into the Payment Protocol itself via a special tag or would this require more substantive change? Services could develop to facilitate the exchange (acting as a sort of “PP gateway”) or wallet software might be able to directly communicate, perhaps by exchanging PGP-encrypted files in Payment Protocol format via Bluetooth, AirDrop, email, BitMessage, or whatever future communications channel comes into being.
Thanks again to Peter for putting together a consolidated list of topics!
Taylor
On Dec 19, 2013, at 2:40 PM, caedes <caedes@sindominio•net> wrote:
> I feel it's missing mention of using (or not) *extended public keys*
> from bip 32 to share multiple addresses in one go, so regular payments
> can be done without asking for further addresses. Also since whoever has
> the extended key can generate public keys this might help P2SH where the
> public key is also needed.
[-- Attachment #2: Type: text/html, Size: 5247 bytes --]
prev parent reply other threads:[~2013-12-20 17:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-19 13:17 [Bitcoin-development] " Peter Todd
2013-12-19 15:46 ` Drak
[not found] ` <dde469d7ce77a748fb4c279334deb643.squirrel@fruiteater.riseup.net>
[not found] ` <538d3c4677a4332ae8341e37d1a77d5e.squirrel@fruiteater.riseup.net>
2013-12-19 16:32 ` [Bitcoin-development] [unSYSTEM] " Drak
2013-12-19 17:23 ` Mike Belshe
2013-12-19 17:44 ` [Bitcoin-development] " Peter Todd
2013-12-19 18:05 ` [Bitcoin-development] [unSYSTEM] " Drak
2013-12-20 6:52 ` [Bitcoin-development] " Wendell
[not found] ` <52B359C4.3050106@sindominio.net>
2013-12-20 17:32 ` Taylor Gerring [this message]
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=910AE313-00A5-4DEB-8974-742FE0B14116@gmail.com \
--to=taylor.gerring@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=unsystem@lists$(echo .)dyne.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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