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 credit card or bank wire. How do we
present more than 20 customers with an "invoice address" (regular address or
xpub)?
(In Lightning world you give a Lightning address that uses plus addresses. Like
castiron+customer1.invoi...@lsp.com
If you hand out xpubs it can be the case that you hand out a consecutive streak
of 20 xpubs that are never used. Your wallet has to scan 20 xpubs and their 20
first receive addresses.
2) Whether you give the sender an address for reuse or an xpub for reuse there
needs to be an expiry such that the receiver can confirm they still have the
corresponding keys. How can we make a layer 1 address that expires like a PGP
key where it can still be used but raises a warning to the sender?
(In Lightning we have that)
3) Could there be some more exotic deterministic path that doesn't split
receive and change addresses? What is the first principle of splitting change
and receive? What's wrong with an address reused exactly twice? The sender and
receiver both with know what was a payment and what was change. Will it create
plausible deniability about change addresses?
Satoshi original wallet concept was an ever growing key pool with a 100 address
"gap". Maybe the solution to the gap limit is to add invoice functionality to
wallets that manage issuing fresh addresses even without them being used and
have a configurable gap limit. Is that what Btcpayserver does?
Regards
Peter Kroll
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
