Hi all,
I'm working on a light wallet and have been kicking around a really similar
idea (we already have a hosted component that knows the user's xpub, why not
provide an endpoint that can vend fresh receive addresses to senders and try to
make the easy-path for sending bitcoin to our users also be the more private
one). I wanted to throw in another thing you can build with this setup: address
authentication.
Bitcoin addresses don't (generally) carry any semantic information that humans
can use at-a-glance to distinguish legitimate addresses from illegitimate
addresses. There have been instances of clipboard-hijacking malware that have
used this fact to steal bitcoin -- a user goes to a webpage (or email, or IM or
whatever), copies an address, and then pastes it into their bitcoin wallet.
Unbeknownst to them, the clipboard contents have been replaced with an address
controlled by some bad actor. The wallet just builds the transaction to
whatever addresses the "user" supplied, and the user is none-the-wiser until
after the funds have left their wallet.
Now imagine instead that the wallet has some address book with a pubkey for
each recipient the user wants to send bitcoin to. Alice wants to pay Bob, so
she clicks "Bob" in her transaction UI. Her wallet goes and asks the address
server for an address for Bob. The address server picks an unused address, and
has it signed (depending on the setup, this could be that the address server
also has the Address Authentication privkey for bob, or it could be that bob
gets some callback or notification, or that bob has pre-signed a batch of
addresses. it will depend on the implementation). The address server sends a
signed blob back to alice that contains an address and a signature proving that
the address is in fact Bob's. Now Alice's wallet can tell whether or not the
address it's putting in the transaction output belongs to Bob, even if that
data was intercepted between the address server and the wallet (this doesn't
help if the address server is malicious or has been compromised, but that's a
different problem).
It would be really nice to have a protocol here that can make wallets
interoperable in fetching fresh addresses from Address Servers and in the
return schema that can include signatures and other metadata (like optimistic
expirations, maybe other invoice data?).
Love the conversation so far. Happy to dig into this further with anyone else
interested :)
Cheers,
rijndael
------- Original Message -------
On Monday, October 3rd, 2022 at 7:01 PM, Ruben Somsen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 <d...@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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
