From: Ruben Somsen <rsomsen@gmail•com>
To: rot13maxi <rot13maxi@protonmail•com>
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 14:40:38 +0200 [thread overview]
Message-ID: <CAPv7TjYnM=3RMAwXe_Ssa-RXz5CxP0xAxxLdQVq79T5BYvT9mQ@mail.gmail.com> (raw)
In-Reply-To: <CABaSBazV-ZO2kUEZzDubGQbxn-zt4acJ1wQxzJo9y4qFYtWM-w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]
Hi Rijndael,
I think your thoughts are pretty much compatible with this proposal, as
what I'm describing (the recipient signing their keys) is also essentially
a form of authentication.
It's a good observation that in general this makes the communication of
addresses more secure. I do wish to re-emphasize Bryan's remark that you
still need to ensure the pubkey itself is securely communicated.
>depending on the setup, this could be that the address server also has the
Address Authentication privkey for bob, or it could be that bob gets some
callback or notification, or that bob has pre-signed a batch of addresses
In my opinion the only meaningful distinction is whether Bob runs the
Trustless Address Server himself (full privacy) or not. In either case I
see no reason to diverge from the model where Bob deposits a batch of
signed keys to the server, ensuring that no malicious addresses can be
handed out.
Note I discussed the Trustless Address Server design in the first 20
minutes of this podcast:
https://twitter.com/bitcoinoptech/status/1580573594656333825
And I also brought it up in my presentation at Tabconf last Saturday, but
that video isn't online yet.
Cheers,
Ruben
On Tue, Oct 18, 2022 at 2:07 AM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Mon, Oct 17, 2022 at 7:05 PM rot13maxi via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> Unbeknownst to them, the clipboard contents have been replaced with an
>> address controlled by some bad actor.
>>
> [snip]
>
>> Now imagine instead that the wallet has some address book with a pubkey
>> for each recipient the user wants to send bitcoin to.
>>
>
> Isn't this the same problem but now for copy-pasting pubkeys instead of an
> address?
>
> - Bryan
> https://twitter.com/kanzure
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3445 bytes --]
next prev parent reply other threads:[~2022-10-18 12:40 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 [this message]
2022-10-18 12:42 ` Andrew Poelstra
2022-10-18 22:46 ` rot13maxi
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='CAPv7TjYnM=3RMAwXe_Ssa-RXz5CxP0xAxxLdQVq79T5BYvT9mQ@mail.gmail.com' \
--to=rsomsen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rot13maxi@protonmail$(echo .)com \
/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