rot13maxi [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-17 📝 Original message:Hi all, I'm working on a ...
📅 Original date posted:2022-10-17
📝 Original message: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 at 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 <dave at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/6f8d600b/attachment.html>;
📝 Original message: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 at 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 <dave at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/6f8d600b/attachment.html>;