Hello Andrew and Bryan,
> No, as I understand the proposal, the "public key" held by the wallet is
> simply
> a signing key used to authenticate addresses, and never leaves the wallet.
That's right (or at least, that's the intent). Think of importing someone's GPG
key and then using it to
Hi Rijndael,
I think your thoughts are pretty much compatible with this proposal, as
what I'm describing (the recipient signing their keys) is also essentially
a form of authentication.
It's a good observation that in general this makes the communication of
addresses more secure. I do wish to
On Mon, Oct 17, 2022 at 07:07:07PM -0500, Bryan Bishop via bitcoin-dev wrote:
>
> Isn't this the same problem but now for copy-pasting pubkeys instead of an
> address?
>
No, as I understand the proposal, the "public key" held by the wallet is simply
a signing key used to authenticate addresses,
On Mon, Oct 17, 2022 at 7:05 PM rot13maxi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Unbeknownst to them, the clipboard contents have been replaced with an
> address controlled by some bad actor.
>
[snip]
> Now imagine instead that the wallet has some address book with a
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
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
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,
Hi Peter,
Thanks for your comments.
>handing out xpubs makes the gap limit problem quadratic
Yes, my thinking on this is that if you're handing out xpubs you can lower
the gap limit for addresses generated by those xpubs, provided you assume
those addresses will be used by the same person, so
Hi Ruben,
I think this is an important conversation you have raised. I want to add some
points for discussion.
1) handing out xpubs makes the gap limit problem quadratic.
Each customer, of a given business, on an invoice must be given a unique
address or xpub but they may pay in cash or
Hi all,
In short, this is yet another way to hand out addresses without interaction
between sender and recipient (Silent Payments, BIP47). The idea here is
that in non-ideal cases where you're already exposing your xpub to a server
(most light clients today, unfortunately), you might as well rely
10 matches
Mail list logo