MIME-Version: 1.0
Date: Sun, 02 Oct 2022 12:48:21 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Ruben Somsen <rsomsen@gmail.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAPv7TjbOcH2mte8SWALc2o5aEKLO7qoZ-M_e1wHdGSp6EmMc2Q@mail.gmail.com>
References: <CAPv7TjbOcH2mte8SWALc2o5aEKLO7qoZ-M_e1wHdGSp6EmMc2Q@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <9f399e0c2713f2b1d2534cd754356bb5@dtrt.org>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev]
 =?utf-8?q?Trustless_Address_Server_=E2=80=93_Outsou?=
 =?utf-8?q?rcing_handing_out_addresses_to_prevent_address_reuse?=
Precedence: list

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