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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
