Subject: Re: [bitcoin-dev]Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

From: "David A. Harding" <[email-masked]>
Date: Sun, 02 Oct 2022 12:48:21 -1000

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