From: "David A. Harding" <dave@dtrt•org>
To: Ruben Somsen <rsomsen@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse
Date: Sun, 02 Oct 2022 12:48:21 -1000 [thread overview]
Message-ID: <9f399e0c2713f2b1d2534cd754356bb5@dtrt.org> (raw)
In-Reply-To: <CAPv7TjbOcH2mte8SWALc2o5aEKLO7qoZ-M_e1wHdGSp6EmMc2Q@mail.gmail.com>
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
next prev parent reply other threads:[~2022-10-02 22:48 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 [this message]
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
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=9f399e0c2713f2b1d2534cd754356bb5@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rsomsen@gmail$(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