* Re: [bitcoin-dev] Trustless Address Server ? Outsourcing handing out addresses
@ 2022-10-01 4:36 Peter
2022-10-01 10:18 ` Ruben Somsen
0 siblings, 1 reply; 2+ messages in thread
From: Peter @ 2022-10-01 4:36 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]
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.invoice1@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
[-- Attachment #2: Type: text/html, Size: 2062 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [bitcoin-dev] Trustless Address Server ? Outsourcing handing out addresses
2022-10-01 4:36 [bitcoin-dev] Trustless Address Server ? Outsourcing handing out addresses Peter
@ 2022-10-01 10:18 ` Ruben Somsen
0 siblings, 0 replies; 2+ messages in thread
From: Ruben Somsen @ 2022-10-01 10:18 UTC (permalink / raw)
To: Peter; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3168 bytes --]
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 there is less of a
reason to expect a gap. This thread is related:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020954.html
>How can we make a layer 1 address that expires
This was brought up by Sjors Provoost in relation to Silent Payments. He
suggested embedding a sunset date in the address format.
>Could there be some more exotic deterministic path that doesn't split
receive and change addresses
I don't follow this one. I see no reason not to split the two, and I do see
potential pitfalls when you don't. Conceptually, I think receiving money
twice on the same address is never good. Even if you're doing it to
actively mislead people, that attempt is still leaking information that
simply didn't need to be leaked.
Cheers,
Ruben
On Sat, Oct 1, 2022 at 10:57 AM Peter via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.invoice1@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
>
[-- Attachment #2: Type: text/html, Size: 4243 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-10-01 10:19 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-01 4:36 [bitcoin-dev] Trustless Address Server ? Outsourcing handing out addresses Peter
2022-10-01 10:18 ` Ruben Somsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox