public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: rot13maxi <rot13maxi@protonmail•com>
To: Andrew Poelstra <apoelstra@wpsoftware•net>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse
Date: Tue, 18 Oct 2022 22:46:13 +0000	[thread overview]
Message-ID: <sLhvCqdJBFqYwJDVCmGxA77H7BNKcPLofncf5iZRm8gQp-lNC3LTTCG8aux0iJphnPEfxHBCeh3y-F-r4Ij2Ag15k4yMpMVK1E4eMs8RQaw=@protonmail.com> (raw)
In-Reply-To: <Y06fLe7HMCRPBhQB@camus>

Hello Andrew and Bryan,

> No, as I understand the proposal, the "public key" held by the wallet is simply
> a signing key used to authenticate addresses, and never leaves the wallet. 

That's right (or at least, that's the intent). Think of importing someone's GPG key and then using it to validate future signed messages from them. In this case, the public key stays in your "address book" entry for a person and then whenever you need to fetch a fresh address for them from the Address Server, your wallet can validate that it's for their wallet. 

Making sure that you import a legitimate/authentic public key is a problem, but you only need to do it once per recipient, instead of doing it every time you need to transact with that person. Maybe that's something you solve in UI (i.e. Signal has you compare strings with your counter-party), or something you can solve through other metadata (GPG had WoT, or if you're already using an address server maybe there's some PKI scheme that's appropriate, etc.). 


Rubin, I think you responded on another branch of the thread, but thanks for the podcast link. I'll check it out!

Cheers,

Rijndael

------- Original Message -------
On Tuesday, October 18th, 2022 at 8:42 AM, Andrew Poelstra <apoelstra@wpsoftware•net> wrote:


> On Mon, Oct 17, 2022 at 07:07:07PM -0500, Bryan Bishop via bitcoin-dev wrote:
>
> > Isn't this the same problem but now for copy-pasting pubkeys instead of an
> > address?
>
>
> No, as I understand the proposal, the "public key" held by the wallet is simply
> a signing key used to authenticate addresses, and never leaves the wallet. Yes,
> if the wallet's own memory is compromised, it can be tricked into accepting bad
> addresses, but this is much much harder than compromising data on the clipboard,
> which basically any application can do without any "real" exploits or special
> permissions.
>
> As an extreme, this proposal could be run on a hardware wallet which had some
> out-of-band way to obtain and authenticate public keys (similar to Signal QR
> codes).
>
> --
> Andrew Poelstra
> Director of Research, Blockstream
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
> -Justin Lewis-Webster


      reply	other threads:[~2022-10-18 22:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29 15:39 Ruben Somsen
2022-10-02 22:48 ` David A. Harding
2022-10-03 23:01   ` Ruben Somsen
2022-10-17 23:26     ` rot13maxi
2022-10-18  0:07       ` Bryan Bishop
2022-10-18 12:40         ` Ruben Somsen
2022-10-18 12:42         ` Andrew Poelstra
2022-10-18 22:46           ` rot13maxi [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='sLhvCqdJBFqYwJDVCmGxA77H7BNKcPLofncf5iZRm8gQp-lNC3LTTCG8aux0iJphnPEfxHBCeh3y-F-r4Ij2Ag15k4yMpMVK1E4eMs8RQaw=@protonmail.com' \
    --to=rot13maxi@protonmail$(echo .)com \
    --cc=apoelstra@wpsoftware$(echo .)net \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.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