[bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

[bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

tl;dr: Wallets don't last forever. They are often compromised or lost. When
this happens, the addresses generated from those wallets become a form of toxic
data: funds sent to those addresses can be easily lost forever.

All Bitcoin addresses have this problem. But at least existing Bitcoin
addresses aren't supposed to be reused. Silent Payments are: the whole point is
to have a single address that you can safely pay to multiple times, without
privacy concerns. Failing to make Silent Payment addresses eventually expire in
a reasonable amount of time is thus a particularly harmful mistake.

Fixing this is easy: add a 3 byte field to silent payments addresses, encoding
the expiration date in terms of days after some epoch. 2^24 days is 45,000
years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180
years. We'll be lucky if Bitcoin still exists in 180 years.

Wallets should pick a reasonable default, eg 1 year, for newly created
addresses. Attempts to pay an expired address should just fail with a simple
"address expired". Lightning invoices are a good example here: while invoices
does not require expiration from a technical point of view, they do expire for
similar UX reasons as applies to silent payments.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

[Samson Mow]

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

Why the 180 year limit? imho should plan for longer.

On Fri, Aug 4, 2023 at 10:41 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> tl;dr: Wallets don't last forever. They are often compromised or lost. When
> this happens, the addresses generated from those wallets become a form of
> toxic
> data: funds sent to those addresses can be easily lost forever.
>
> All Bitcoin addresses have this problem. But at least existing Bitcoin
> addresses aren't supposed to be reused. Silent Payments are: the whole
> point is
> to have a single address that you can safely pay to multiple times, without
> privacy concerns. Failing to make Silent Payment addresses eventually
> expire in
> a reasonable amount of time is thus a particularly harmful mistake.
>
> Fixing this is easy: add a 3 byte field to silent payments addresses,
> encoding
> the expiration date in terms of days after some epoch. 2^24 days is 45,000
> years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days
> is 180
> years. We'll be lucky if Bitcoin still exists in 180 years.
>
> Wallets should pick a reasonable default, eg 1 year, for newly created
> addresses. Attempts to pay an expired address should just fail with a
> simple
> "address expired". Lightning invoices are a good example here: while
> invoices
> does not require expiration from a technical point of view, they do expire
> for
> similar UX reasons as applies to silent payments.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2422 bytes --]

Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

On Fri, Aug 04, 2023 at 11:41:39AM -0700, Samson Mow wrote:
> Why the 180 year limit? imho should plan for longer.

You know, it was only 137 years ago that the first practical electric motor was
invented; 143 years ago that the first practical light bulb was invented.

180 years is a long time.


But if that seems too short, as I said, 3 bytes is sufficient for 45,934 years.
The invention of agriculture is only 12,000 years old. Although I guess as a
toxic bitcoin carnivore you care more about the invention of the bow and arrow,
70,000 years ago.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

[Brandon Black]

I agree. Non-expiring addresses are a significant risk to bitcoin users.

On 2023-08-04 (Fri) at 17:39:03 +0000, Peter Todd via bitcoin-dev wrote:
> Fixing this is easy: add a 3 byte field to silent payments addresses, encoding
> the expiration date in terms of days after some epoch. 2^24 days is 45,000
> years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180
> years. We'll be lucky if Bitcoin still exists in 180 years.

Instead of a fixed width nDays, consider a custom compact encoding with
the position of the first 0-bit indicating the number of extension bytes
and the encoded granularity.

bytes | prefix     | usable bits | granularity | max expiration
------|------------|-------------|-------------|---------------
1     | 0b0        |   7         | year        | 128 years
2     | 0b10       |  14         | week        | 315 years
3     | 0b110      |  21         | day         | 5700 years
4     | 0b1110     |  28         | block       | 5100 years
5     | 0b11110    |  35         | ???         | ???
6     | 0b111110   |  42         | ???         | ???
7     | 0b1111110  |  49         | ???         | ???
8     | 0b11111110 |  56         | ???         | ???

For address expiration, year or week expiration will typically be
sufficiently granular, but for rare occasions more granularity can be
encoded with longer addresses. This method also degrades cleanly even if
the same address format is still in use in 100 or 300 years.

I included block-based expiration to enable SP users to match CLTVs
embedded in their scripts, e.g.
  <2 years> OP_CLTV <recovery_path> OP_VAULT_RECOVER
or
  <2 years> OP_CLTV <backup_key> OP_CHECKSIG

Best,

--Brandon

Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]

On Fri, Aug 04, 2023 at 03:27:17PM -0700, Brandon Black wrote:
> I agree. Non-expiring addresses are a significant risk to bitcoin users.
> 
> On 2023-08-04 (Fri) at 17:39:03 +0000, Peter Todd via bitcoin-dev wrote:
> > Fixing this is easy: add a 3 byte field to silent payments addresses, encoding
> > the expiration date in terms of days after some epoch. 2^24 days is 45,000
> > years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180
> > years. We'll be lucky if Bitcoin still exists in 180 years.
> 
> Instead of a fixed width nDays, consider a custom compact encoding with
> the position of the first 0-bit indicating the number of extension bytes
> and the encoded granularity.
> 
> bytes | prefix     | usable bits | granularity | max expiration
> ------|------------|-------------|-------------|---------------
> 1     | 0b0        |   7         | year        | 128 years
> 2     | 0b10       |  14         | week        | 315 years
> 3     | 0b110      |  21         | day         | 5700 years
> 4     | 0b1110     |  28         | block       | 5100 years
> 5     | 0b11110    |  35         | ???         | ???
> 6     | 0b111110   |  42         | ???         | ???
> 7     | 0b1111110  |  49         | ???         | ???
> 8     | 0b11111110 |  56         | ???         | ???
> 
> For address expiration, year or week expiration will typically be
> sufficiently granular, but for rare occasions more granularity can be
> encoded with longer addresses. This method also degrades cleanly even if
> the same address format is still in use in 100 or 300 years.

1) Having the granularity of the limit depend on *when* the limit is to be
applied in a UX nightmare. It is far simpler to just pick a useful granularity,
and include enough bytes of integer to work until well into the future. 3
bytes, 24-bits, of days is 45,000 years. That's plenty.

2) Your suggestion would result in a protocol that degrades over time, as the
granularity of *newly* created addresses goes up. This isn't like CTV/CLTV,
where we're creating something now with a limit in the future. 100 years from
now - if silent payments still exists - people will still want to create silent
payment addresses that expire, say, 30 days in the future. Your suggestion does
not allow that.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

[Brandon Black]

On 2023-08-05 (Sat) at 14:06:10 +0000, Peter Todd via bitcoin-dev wrote:
> > bytes | prefix     | usable bits | granularity | max expiration
> > ------|------------|-------------|-------------|---------------
> > 1     | 0b0        |   7         | year        | 128 years
> > 2     | 0b10       |  14         | week        | 315 years
> > 3     | 0b110      |  21         | day         | 5700 years
> > 4     | 0b1110     |  28         | block       | 5100 years
> > 5     | 0b11110    |  35         | ???         | ???
> > 6     | 0b111110   |  42         | ???         | ???
> > 7     | 0b1111110  |  49         | ???         | ???
> > 8     | 0b11111110 |  56         | ???         | ???
> 
> 1) Having the granularity of the limit depend on *when* the limit is to be
> applied in a UX nightmare. It is far simpler to just pick a useful granularity,
> and include enough bytes of integer to work until well into the future. 3
> bytes, 24-bits, of days is 45,000 years. That's plenty.

I must not have explained my proposal clearly. The granularity depends
not on when it is applied, but on the encoding. For example, the bits
0b00000001 encode an expiration 1-year from the epoch of the system. The
bits 0b10000000 10000000 encode an expiration 128 weeks from the epoch.

When decoding, the position of the highest `0` bit in the expiration
indicates the byte-length, and the granularity. If the expiration's
highest bit is `0`, it is 1-byte long, and the bits following the
highest `0` encode a number of years. If the first `0` bit is in the
second highest position, then it is 2-bytes long and the bits following
the highest 0 encode a number of weeks. &c.

> 2) Your suggestion would result in a protocol that degrades over time, as the
> granularity of *newly* created addresses goes up. This isn't like CTV/CLTV,
> where we're creating something now with a limit in the future. 100 years from
> now - if silent payments still exists - people will still want to create silent
> payment addresses that expire, say, 30 days in the future. Your suggestion does
> not allow that.

My suggestion does degrade over time in one sense: if it is still in use
128 years in the future, users are required to start using at least 2
bytes to encode their expiration instead of 1, even if they only need
year granularity. After 315 years they have to start using at least 3
bytes even if they only need week granularity.

I'd rather enable users to encode their expirations in 1 or 2 bytes
today and degrade by requiring more bytes than require 3 bytes now.

Best,

--Brandon

Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

[josibake]

[-- Attachment #1.1: Type: text/plain, Size: 5009 bytes --]

Hi Peter,

Thanks for the feedback! As you mentioned, this is a more general problem in Bitcoin and not specific to BIP352. Therefore, if expiration dates are indeed something we want, they should be proposed and discussed as their own BIP and be a standard that can work for xpubs, static payment codes, as well as existing and future address formats. If that were to happen, it would be easy enough to add this expiration standard to silent payments as a new silent payments address version.

That being said, I'm a bit skeptical in general of expiration dates and think that they weaken the value proposition of silent payments while not actually solving the problems you described. Consider the following scenarios:

1. Bob's wallet is compromised with a one-year expiry and for the next year, funds are sent to the attacker. The attacker may have the ability to update the expiration, and thus be able to keep receiving funds as Bob.
2. Bob loses his keys with a one-year expiry but finds them again 3 years later. The expiration causes Bob to miss out on 2 years worth of potential payments.
3. Bob dies with a one-year expiry but an heir inherits his backups several years down the road. The expiration date causes the heir to miss out on several years worth of potential payments.
4. Bob is prevented from updating his address for several years but retains access to his keys/backups. The expiration date causes Bob to miss out on several years worth of potential payments.
5. Bob regularly updates his address with a new expiry, but not all senders are able to find the new, updated address causing Bob to miss out on potential payments.
6. By updating his address, Bob is leaking metadata about himself, potentially compromising his safety.

You could argue that none of the scenarios above would be an issue if Bob just sets a very long expiry, but then the expiry doesn't really help in solving the issues you mentioned. What we really want is a way for Bob to revoke his silent payment address. For this, I think building a wallet protocol on top of silent payments is a better path to explore. Additionally, expiration dates as proposed degrade the privacy of silent payments: any outside observer can conclude that all transactions mined at block height N or greater were not payments to any silent payment address with an expiry less than N. As I mentioned already, there may also be privacy and safety concerns with the user needing to regularly update their silent payment address expiration date.

Lastly, on the subject of expiration dates in general, your proposed solution is not enforceable: any wallet can just ignore the extra bytes and send to the address/xpub/static payment code, anyways. For expiration dates to be useful, I'd argue they need to be enforced by consensus (which I am not convinced is a good idea).

In summary, expiration dates are a separate problem, outside the scope of what BIP352 is trying to address. If we can work toward a more general solution, there is nothing preventing us from adding this to a future silent payments version, but even then, I'm still not convinced expiration dates for static payment codes is a good idea, for the reasons I mentioned above.

Cheers,
Josie


Sent with Proton Mail secure email.

------- Original Message -------
On Friday, August 4th, 2023 at 7:39 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> tl;dr: Wallets don't last forever. They are often compromised or lost. When
> this happens, the addresses generated from those wallets become a form of toxic
> data: funds sent to those addresses can be easily lost forever.
> 

> All Bitcoin addresses have this problem. But at least existing Bitcoin
> addresses aren't supposed to be reused. Silent Payments are: the whole point is
> to have a single address that you can safely pay to multiple times, without
> privacy concerns. Failing to make Silent Payment addresses eventually expire in
> a reasonable amount of time is thus a particularly harmful mistake.
> 

> Fixing this is easy: add a 3 byte field to silent payments addresses, encoding
> the expiration date in terms of days after some epoch. 2^24 days is 45,000
> years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180
> years. We'll be lucky if Bitcoin still exists in 180 years.
> 

> Wallets should pick a reasonable default, eg 1 year, for newly created
> addresses. Attempts to pay an expired address should just fail with a simple
> "address expired". Lightning invoices are a good example here: while invoices
> does not require expiration from a technical point of view, they do expire for
> similar UX reasons as applies to silent payments.
> 

> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #1.2: publickey - josibake@protonmail.com - 0x616516B8.asc --]
[-- Type: application/pgp-keys, Size: 3154 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 855 bytes --]

Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 5309 bytes --]

On Sun, Aug 06, 2023 at 02:20:06PM +0000, josibake wrote:
> Hi Peter,
> 
> Thanks for the feedback! As you mentioned, this is a more general problem in Bitcoin and not specific to BIP352. Therefore, if expiration dates are indeed something we want, they should be proposed and discussed as their own BIP and be a standard that can work for xpubs, static payment codes, as well as existing and future address formats. If that were to happen, it would be easy enough to add this expiration standard to silent payments as a new silent payments address version.
> 
> That being said, I'm a bit skeptical in general of expiration dates and think that they weaken the value proposition of silent payments while not actually solving the problems you described. Consider the following scenarios:
> 
> 1. Bob's wallet is compromised with a one-year expiry and for the next year, funds are sent to the attacker. The attacker may have the ability to update the expiration, and thus be able to keep receiving funds as Bob.

The ability to "update the expiration" is the ability to trick someone into
thinking a new address came from Bob, eg by modifying a donation address in a
social media profile. This attack works whether or not expiration exists.

> 2. Bob loses his keys with a one-year expiry but finds them again 3 years later. The expiration causes Bob to miss out on 2 years worth of potential payments.

If Bob has lost his keys, the safe thing to do is for people sending funds to
Bob to ask Bob for a new address. It is much more likely that Bob doesn't find
the keys, and multiple years worth of funds are wasted.

> 3. Bob dies with a one-year expiry but an heir inherits his backups several years down the road. The expiration date causes the heir to miss out on several years worth of potential payments.

If Bob is dead, why are people sending Bob money? In this example expiration
prevented an unintentional fraud.

> 4. Bob is prevented from updating his address for several years but retains access to his keys/backups. The expiration date causes Bob to miss out on several years worth of potential payments.

Same category as #2 and #3. The main cause of this example is going to jail,
which would usually be a circumstance where both key loss is likely, *and*
people may want to reconsider sending Bob money. Expiration is much more likely
to prevent a loss of funds due to theft or fraud.

> 5. Bob regularly updates his address with a new expiry, but not all senders are able to find the new, updated address causing Bob to miss out on potential payments.

If the senders can't find Bob's up-to-date address, how much due dilligence are
they possibly doing on where they're sending funds?

You need to provide a clear example of how you think Bob is distributing this
address, and yet, can't update it. Social media, webpages, github repos, etc.
are all easily updatable.  How, concretely, is Bob going to be in a position
where updating an address is hard?

> 6. By updating his address, Bob is leaking metadata about himself, potentially compromising his safety.

This is an extremely marginal concern. Any silent payment address associated
with, eg, a social media profile is revealing far more metadata from other
actions of the user.

People pay other people for reasons, eg a developer writing code. Those reasons
translate into far more metadata than updating a donation address once every
year or two.

> You could argue that none of the scenarios above would be an issue if Bob just sets a very long expiry, but then the expiry doesn't really help in solving the issues you mentioned. What we really want is a way for Bob to revoke his silent payment address. For this, I think building a wallet protocol on top of silent payments is a better path to explore. Additionally, expiration dates as proposed degrade the privacy of silent payments: any outside observer can conclude that all transactions mined at block height N or greater were not payments to any silent payment address with an expiry less than N. As I mentioned already, there may also be privacy and safety concerns with the user needing to regularly update their silent payment address expiration date.

Outside observers can already do this kind of analysis with or without
expiration, as users regularly expire addresses in other ways (eg by updating a
social media profile).

I also find this attack extremely marginal due to how little information the
attacker gets: the k-anonymity set of silent payments is already very large.

> Lastly, on the subject of expiration dates in general, your proposed solution is not enforceable: any wallet can just ignore the extra bytes and send to the address/xpub/static payment code, anyways. For expiration dates to be useful, I'd argue they need to be enforced by consensus (which I am not convinced is a good idea).

Checksums are similar to expiration in this fashion: neither are enforced by
the consensus layer, and they don't need to be. For them to work in almost all
cases it is more than sufficient to just standardize them and enforce them in
the client. 99.999% of clients will respect expiration, solving the problem
nearly 100% of the time.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

[Dan Gould]

Address expiration does seem to be a generic problem, but Silent Payments could play a role in solving the problem once and for all. Payment requests often have expiration in practice because of moving exchange rates but no way to communicate that to sending software. BTCPay checkout page includes a 15 minute countdown by default. Payments made to a checkout after the expiration are saved in an error state for the BTCPay operator and customer to triage.

Since enforcing expiration by consensus sounds unpopular, one generic way to enforce it at the application layer would be to use a new BIP 21 URI parameter `req-exp=`.

BIP 21 specifies that parameters starting `req-` are considered required. URIs containing unknown `req-` parameters are considered invalid and the parameter can still be shown in UI. Support for `req-exp=` could thus be implemented in BIP 21 libraries rather than for each address type, and without necessarily supporting Silent Payments.

New address specifications like Silent Payments could recommend wallets request payments using BIP 21 URI and `req-exp=` to begin to solve this problem in general. Wallets supporting Silent Payments & `req-exp=` could then apply expiration to older address types too.

Dan

> On Aug 6, 2023, at 10:28 AM, bitcoin-dev-request@lists.linuxfoundation.org wrote:
> 
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request@lists.linuxfoundation.org
> 
> You can reach the person managing the list at
> bitcoin-dev-owner@lists.linuxfoundation.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: BIP-352 Silent Payments addresses should have an
>      expiration time (Samson Mow)
>   2. Re: BIP-352 Silent Payments addresses should have an
>      expiration time (Brandon Black)
>   3. Re: BIP-352 Silent Payments addresses should have an
>      expiration time (josibake)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 4 Aug 2023 11:41:39 -0700
> From: Samson Mow <samson.mow@gmail.com>
> To: Peter Todd <pete@petertodd.org>,  Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should
> have an expiration time
> Message-ID:
> <CAAWeQ5fRi3AiZpSm4riyrNyCRphi5dSE6tFpkaGeQCY3x4keng@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Why the 180 year limit? imho should plan for longer.
> 
> On Fri, Aug 4, 2023 at 10:41?AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> tl;dr: Wallets don't last forever. They are often compromised or lost. When
>> this happens, the addresses generated from those wallets become a form of
>> toxic
>> data: funds sent to those addresses can be easily lost forever.
>> 
>> All Bitcoin addresses have this problem. But at least existing Bitcoin
>> addresses aren't supposed to be reused. Silent Payments are: the whole
>> point is
>> to have a single address that you can safely pay to multiple times, without
>> privacy concerns. Failing to make Silent Payment addresses eventually
>> expire in
>> a reasonable amount of time is thus a particularly harmful mistake.
>> 
>> Fixing this is easy: add a 3 byte field to silent payments addresses,
>> encoding
>> the expiration date in terms of days after some epoch. 2^24 days is 45,000
>> years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days
>> is 180
>> years. We'll be lucky if Bitcoin still exists in 180 years.
>> 
>> Wallets should pick a reasonable default, eg 1 year, for newly created
>> addresses. Attempts to pay an expired address should just fail with a
>> simple
>> "address expired". Lightning invoices are a good example here: while
>> invoices
>> does not require expiration from a technical point of view, they do expire
>> for
>> similar UX reasons as applies to silent payments.
>> 
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230804/fc013648/attachment.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Sat, 5 Aug 2023 07:46:52 -0700
> From: Brandon Black <freedom@reardencode.com>
> To: Peter Todd <pete@petertodd.org>, Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should
> have an expiration time
> Message-ID: <ZM5g3Fi_vErCeEx0@console>
> Content-Type: text/plain; charset=us-ascii
> 
> On 2023-08-05 (Sat) at 14:06:10 +0000, Peter Todd via bitcoin-dev wrote:
>>> bytes | prefix     | usable bits | granularity | max expiration
>>> ------|------------|-------------|-------------|---------------
>>> 1     | 0b0        |   7         | year        | 128 years
>>> 2     | 0b10       |  14         | week        | 315 years
>>> 3     | 0b110      |  21         | day         | 5700 years
>>> 4     | 0b1110     |  28         | block       | 5100 years
>>> 5     | 0b11110    |  35         | ???         | ???
>>> 6     | 0b111110   |  42         | ???         | ???
>>> 7     | 0b1111110  |  49         | ???         | ???
>>> 8     | 0b11111110 |  56         | ???         | ???
>> 
>> 1) Having the granularity of the limit depend on *when* the limit is to be
>> applied in a UX nightmare. It is far simpler to just pick a useful granularity,
>> and include enough bytes of integer to work until well into the future. 3
>> bytes, 24-bits, of days is 45,000 years. That's plenty.
> 
> I must not have explained my proposal clearly. The granularity depends
> not on when it is applied, but on the encoding. For example, the bits
> 0b00000001 encode an expiration 1-year from the epoch of the system. The
> bits 0b10000000 10000000 encode an expiration 128 weeks from the epoch.
> 
> When decoding, the position of the highest `0` bit in the expiration
> indicates the byte-length, and the granularity. If the expiration's
> highest bit is `0`, it is 1-byte long, and the bits following the
> highest `0` encode a number of years. If the first `0` bit is in the
> second highest position, then it is 2-bytes long and the bits following
> the highest 0 encode a number of weeks. &c.
> 
>> 2) Your suggestion would result in a protocol that degrades over time, as the
>> granularity of *newly* created addresses goes up. This isn't like CTV/CLTV,
>> where we're creating something now with a limit in the future. 100 years from
>> now - if silent payments still exists - people will still want to create silent
>> payment addresses that expire, say, 30 days in the future. Your suggestion does
>> not allow that.
> 
> My suggestion does degrade over time in one sense: if it is still in use
> 128 years in the future, users are required to start using at least 2
> bytes to encode their expiration instead of 1, even if they only need
> year granularity. After 315 years they have to start using at least 3
> bytes even if they only need week granularity.
> 
> I'd rather enable users to encode their expirations in 1 or 2 bytes
> today and degrade by requiring more bytes than require 3 bytes now.
> 
> Best,
> 
> --Brandon
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Sun, 06 Aug 2023 14:20:06 +0000
> From: josibake <josibake@protonmail.com>
> To: Peter Todd <pete@petertodd.org>
> Cc: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should
> have an expiration time
> Message-ID:
> <Xypmhu6s58gWgRNoFzBDhbtvcEt8DomdJcLe1RIbesEKOx1MO5TBHTLDENqedTbN9DPZT5MNSpA-xMiiSDDb-hVnx-YgIAqCtrGHoCrqxsE=@protonmail.com>
> 
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Peter,
> 
> Thanks for the feedback! As you mentioned, this is a more general problem in Bitcoin and not specific to BIP352. Therefore, if expiration dates are indeed something we want, they should be proposed and discussed as their own BIP and be a standard that can work for xpubs, static payment codes, as well as existing and future address formats. If that were to happen, it would be easy enough to add this expiration standard to silent payments as a new silent payments address version.
> 
> That being said, I'm a bit skeptical in general of expiration dates and think that they weaken the value proposition of silent payments while not actually solving the problems you described. Consider the following scenarios:
> 
> 1. Bob's wallet is compromised with a one-year expiry and for the next year, funds are sent to the attacker. The attacker may have the ability to update the expiration, and thus be able to keep receiving funds as Bob.
> 2. Bob loses his keys with a one-year expiry but finds them again 3 years later. The expiration causes Bob to miss out on 2 years worth of potential payments.
> 3. Bob dies with a one-year expiry but an heir inherits his backups several years down the road. The expiration date causes the heir to miss out on several years worth of potential payments.
> 4. Bob is prevented from updating his address for several years but retains access to his keys/backups. The expiration date causes Bob to miss out on several years worth of potential payments.
> 5. Bob regularly updates his address with a new expiry, but not all senders are able to find the new, updated address causing Bob to miss out on potential payments.
> 6. By updating his address, Bob is leaking metadata about himself, potentially compromising his safety.
> 
> You could argue that none of the scenarios above would be an issue if Bob just sets a very long expiry, but then the expiry doesn't really help in solving the issues you mentioned. What we really want is a way for Bob to revoke his silent payment address. For this, I think building a wallet protocol on top of silent payments is a better path to explore. Additionally, expiration dates as proposed degrade the privacy of silent payments: any outside observer can conclude that all transactions mined at block height N or greater were not payments to any silent payment address with an expiry less than N. As I mentioned already, there may also be privacy and safety concerns with the user needing to regularly update their silent payment address expiration date.
> 
> Lastly, on the subject of expiration dates in general, your proposed solution is not enforceable: any wallet can just ignore the extra bytes and send to the address/xpub/static payment code, anyways. For expiration dates to be useful, I'd argue they need to be enforced by consensus (which I am not convinced is a good idea).
> 
> In summary, expiration dates are a separate problem, outside the scope of what BIP352 is trying to address. If we can work toward a more general solution, there is nothing preventing us from adding this to a future silent payments version, but even then, I'm still not convinced expiration dates for static payment codes is a good idea, for the reasons I mentioned above.
> 
> Cheers,
> Josie
> 
> 
> Sent with Proton Mail secure email.
> 
> ------- Original Message -------
> On Friday, August 4th, 2023 at 7:39 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 
>> tl;dr: Wallets don't last forever. They are often compromised or lost. When
>> this happens, the addresses generated from those wallets become a form of toxic
>> data: funds sent to those addresses can be easily lost forever.
>> 
> 
>> All Bitcoin addresses have this problem. But at least existing Bitcoin
>> addresses aren't supposed to be reused. Silent Payments are: the whole point is
>> to have a single address that you can safely pay to multiple times, without
>> privacy concerns. Failing to make Silent Payment addresses eventually expire in
>> a reasonable amount of time is thus a particularly harmful mistake.
>> 
> 
>> Fixing this is easy: add a 3 byte field to silent payments addresses, encoding
>> the expiration date in terms of days after some epoch. 2^24 days is 45,000
>> years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180
>> years. We'll be lucky if Bitcoin still exists in 180 years.
>> 
> 
>> Wallets should pick a reasonable default, eg 1 year, for newly created
>> addresses. Attempts to pay an expired address should just fail with a simple
>> "address expired". Lightning invoices are a good example here: while invoices
>> does not require expiration from a technical point of view, they do expire for
>> similar UX reasons as applies to silent payments.
>> 
> 
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: publickey - josibake@protonmail.com - 0x616516B8.asc
> Type: application/pgp-keys
> Size: 3154 bytes
> Desc: not available
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230806/edd207c8/attachment.bin>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 855 bytes
> Desc: OpenPGP digital signature
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230806/edd207c8/attachment.sig>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> ------------------------------
> 
> End of bitcoin-dev Digest, Vol 99, Issue 15
> *******************************************