From: Ruben Somsen <rsomsen@gmail•com>
To: "David A. Harding" <dave@dtrt•org>
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, 4 Oct 2022 01:01:06 +0200 [thread overview]
Message-ID: <CAPv7TjY=35H2rmCxBavLwe3+8A9osao0QAMF_grb6WFA502b5Q@mail.gmail.com> (raw)
In-Reply-To: <9f399e0c2713f2b1d2534cd754356bb5@dtrt.org>
[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]
Hi David,
Thanks for the excellent suggestion, that makes the protocol much more
elegant and actually increases my optimism about its practicality. Also,
interesting observation that there is overlap with BIP78. From the
perspective of the recipient it does mean there's a potential privacy
reduction when a placeholder transaction goes through (these should perhaps
be marked in the wallet?), but I suppose this is still better than no
payment at all. I also like your point that it doubles as a way to
potentially bridge gaps.
Cheers,
Ruben
On Mon, Oct 3, 2022 at 12:48 AM David A. Harding <dave@dtrt•org> wrote:
> On 2022-09-29 05:39, Ruben Somsen via bitcoin-dev wrote:
> > An alternative mitigation (more user friendly, but more implementation
> > complexity) would be to require the sender to reveal their intended
> > transaction to the server prior to receiving the address[^9]. This is
> > not a privacy degradation, since the server could already learn this
> > information regardless. If the transaction doesn't end up getting
> > sent, any subsequent attempt to reuse one of the inputs should either
> > be (temporarily) blacklisted or responded to with the same address
> > that was given out earlier
> > [...]
> > [^9]: *This would essentially look like an incomplete but signed
> > transaction where the output address is still missing.*
>
> Hi Ruben,
>
> Instead of maintaining a database of inputs that should be blocked or
> mapped to addresses, have the spender submit to you (but not the
> network) a valid transaction paying a placeholder address and in return
> give them a guaranteed unique address. They can then broadcast a
> transaction using the same inputs to pay the guaranteed unique address.
> If you don't see that transaction within a reasonable amount of time,
> broadcast the transaction paying the placeholder address. This makes it
> cost the same to them whether they use the unique address or not. By
> placeholder address, I mean an address of yours that's never received a
> payment but which may have been provided in a previous invoice (e.g. to
> prevent exceeding the gap limit).
>
> In short, what I think I've described is the BIP78 payjoin protocol
> without any payjoining going on (which is allowed by BIP78). BTCPay
> already implements BIP78, as do several wallets, and I think it
> satisfies all the design constraints you've described.
>
> -Dave
>
[-- Attachment #2: Type: text/html, Size: 3026 bytes --]
next prev parent reply other threads:[~2022-10-03 23:01 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 [this message]
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
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='CAPv7TjY=35H2rmCxBavLwe3+8A9osao0QAMF_grb6WFA502b5Q@mail.gmail.com' \
--to=rsomsen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)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