📅 Original date posted:2023-08-08
🗒️ Summary of this message: Silent Payments could solve the problem of address expiration by using a new BIP 21 URI parameter `req-exp=` to enforce expiration at the application layer.
📝 Original message:
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 at lists.linuxfoundation.org wrote:
>
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at 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 at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner at 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 at gmail.com>
> To: Peter Todd <pete at petertodd.org>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should
> have an expiration time
> Message-ID:
> <CAAWeQ5fRi3AiZpSm4riyrNyCRphi5dSE6tFpkaGeQCY3x4keng at 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 at 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 at 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 at reardencode.com>
> To: Peter Todd <pete at petertodd.org>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should
> have an expiration time
> Message-ID: <ZM5g3Fi_vErCeEx0 at 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 at protonmail.com>
> To: Peter Todd <pete at petertodd.org>
> Cc: bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: publickey - josibake at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 99, Issue 15
> *******************************************
Dan Gould [ARCHIVE] /
npub1l5…nxs5k
2023-08-09 16:03:59
in reply to nevent1q…yk0q
Author Public Key
npub1l58t68e4t3wgtva5enuvr4aaxxlut7srnhx88avfyfv25jzhkedq6nxs5kPublished at
2023-08-09 16:03:59Event JSON
{
"id": "8275c9bd75af33e38ff88968d10a7fbbbb83d1c0760c3c30618ef6c9d1d43b66",
"pubkey": "fd0ebd1f355c5c85b3b4ccf8c1d7bd31bfc5fa039dcc73f5892258aa4857b65a",
"created_at": 1691597039,
"kind": 1,
"tags": [
[
"e",
"c08d8bfe5e8ab2894e9fbdb020ab2bbb281ca98857e700a8e90822dc365f2c84",
"",
"root"
],
[
"e",
"2f47dee4478ca9beb514cdee62eab5bad310ffc49e3590e4f698a03177a039cb",
"",
"reply"
],
[
"p",
"fe0e98725a4a6fd29a4107be5c266f27ee976a5baa0924f1a16657e230c16510"
]
],
"content": "📅 Original date posted:2023-08-08\n🗒️ Summary of this message: Silent Payments could solve the problem of address expiration by using a new BIP 21 URI parameter `req-exp=` to enforce expiration at the application layer.\n📝 Original message:\nAddress 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.\n\nSince 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=`.\n\nBIP 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.\n\nNew 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 \u0026 `req-exp=` could then apply expiration to older address types too.\n\nDan\n\n\u003e On Aug 6, 2023, at 10:28 AM, bitcoin-dev-request at lists.linuxfoundation.org wrote:\n\u003e \n\u003e Send bitcoin-dev mailing list submissions to\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \n\u003e To subscribe or unsubscribe via the World Wide Web, visit\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e or, via email, send a message with subject or body 'help' to\n\u003e bitcoin-dev-request at lists.linuxfoundation.org\n\u003e \n\u003e You can reach the person managing the list at\n\u003e bitcoin-dev-owner at lists.linuxfoundation.org\n\u003e \n\u003e When replying, please edit your Subject line so it is more specific\n\u003e than \"Re: Contents of bitcoin-dev digest...\"\n\u003e \n\u003e \n\u003e Today's Topics:\n\u003e \n\u003e 1. Re: BIP-352 Silent Payments addresses should have an\n\u003e expiration time (Samson Mow)\n\u003e 2. Re: BIP-352 Silent Payments addresses should have an\n\u003e expiration time (Brandon Black)\n\u003e 3. Re: BIP-352 Silent Payments addresses should have an\n\u003e expiration time (josibake)\n\u003e \n\u003e \n\u003e ----------------------------------------------------------------------\n\u003e \n\u003e Message: 1\n\u003e Date: Fri, 4 Aug 2023 11:41:39 -0700\n\u003e From: Samson Mow \u003csamson.mow at gmail.com\u003e\n\u003e To: Peter Todd \u003cpete at petertodd.org\u003e, Bitcoin Protocol Discussion\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should\n\u003e have an expiration time\n\u003e Message-ID:\n\u003e \u003cCAAWeQ5fRi3AiZpSm4riyrNyCRphi5dSE6tFpkaGeQCY3x4keng at mail.gmail.com\u003e\n\u003e Content-Type: text/plain; charset=\"utf-8\"\n\u003e \n\u003e Why the 180 year limit? imho should plan for longer.\n\u003e \n\u003e On Fri, Aug 4, 2023 at 10:41?AM Peter Todd via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e\u003e tl;dr: Wallets don't last forever. They are often compromised or lost. When\n\u003e\u003e this happens, the addresses generated from those wallets become a form of\n\u003e\u003e toxic\n\u003e\u003e data: funds sent to those addresses can be easily lost forever.\n\u003e\u003e \n\u003e\u003e All Bitcoin addresses have this problem. But at least existing Bitcoin\n\u003e\u003e addresses aren't supposed to be reused. Silent Payments are: the whole\n\u003e\u003e point is\n\u003e\u003e to have a single address that you can safely pay to multiple times, without\n\u003e\u003e privacy concerns. Failing to make Silent Payment addresses eventually\n\u003e\u003e expire in\n\u003e\u003e a reasonable amount of time is thus a particularly harmful mistake.\n\u003e\u003e \n\u003e\u003e Fixing this is easy: add a 3 byte field to silent payments addresses,\n\u003e\u003e encoding\n\u003e\u003e the expiration date in terms of days after some epoch. 2^24 days is 45,000\n\u003e\u003e years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days\n\u003e\u003e is 180\n\u003e\u003e years. We'll be lucky if Bitcoin still exists in 180 years.\n\u003e\u003e \n\u003e\u003e Wallets should pick a reasonable default, eg 1 year, for newly created\n\u003e\u003e addresses. Attempts to pay an expired address should just fail with a\n\u003e\u003e simple\n\u003e\u003e \"address expired\". Lightning invoices are a good example here: while\n\u003e\u003e invoices\n\u003e\u003e does not require expiration from a technical point of view, they do expire\n\u003e\u003e for\n\u003e\u003e similar UX reasons as applies to silent payments.\n\u003e\u003e \n\u003e\u003e --\n\u003e\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \n\u003e -------------- next part --------------\n\u003e An HTML attachment was scrubbed...\n\u003e URL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230804/fc013648/attachment.html\u003e\n\u003e \n\u003e ------------------------------\n\u003e \n\u003e Message: 2\n\u003e Date: Sat, 5 Aug 2023 07:46:52 -0700\n\u003e From: Brandon Black \u003cfreedom at reardencode.com\u003e\n\u003e To: Peter Todd \u003cpete at petertodd.org\u003e, Bitcoin Protocol Discussion\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should\n\u003e have an expiration time\n\u003e Message-ID: \u003cZM5g3Fi_vErCeEx0 at console\u003e\n\u003e Content-Type: text/plain; charset=us-ascii\n\u003e \n\u003e On 2023-08-05 (Sat) at 14:06:10 +0000, Peter Todd via bitcoin-dev wrote:\n\u003e\u003e\u003e bytes | prefix | usable bits | granularity | max expiration\n\u003e\u003e\u003e ------|------------|-------------|-------------|---------------\n\u003e\u003e\u003e 1 | 0b0 | 7 | year | 128 years\n\u003e\u003e\u003e 2 | 0b10 | 14 | week | 315 years\n\u003e\u003e\u003e 3 | 0b110 | 21 | day | 5700 years\n\u003e\u003e\u003e 4 | 0b1110 | 28 | block | 5100 years\n\u003e\u003e\u003e 5 | 0b11110 | 35 | ??? | ???\n\u003e\u003e\u003e 6 | 0b111110 | 42 | ??? | ???\n\u003e\u003e\u003e 7 | 0b1111110 | 49 | ??? | ???\n\u003e\u003e\u003e 8 | 0b11111110 | 56 | ??? | ???\n\u003e\u003e \n\u003e\u003e 1) Having the granularity of the limit depend on *when* the limit is to be\n\u003e\u003e applied in a UX nightmare. It is far simpler to just pick a useful granularity,\n\u003e\u003e and include enough bytes of integer to work until well into the future. 3\n\u003e\u003e bytes, 24-bits, of days is 45,000 years. That's plenty.\n\u003e \n\u003e I must not have explained my proposal clearly. The granularity depends\n\u003e not on when it is applied, but on the encoding. For example, the bits\n\u003e 0b00000001 encode an expiration 1-year from the epoch of the system. The\n\u003e bits 0b10000000 10000000 encode an expiration 128 weeks from the epoch.\n\u003e \n\u003e When decoding, the position of the highest `0` bit in the expiration\n\u003e indicates the byte-length, and the granularity. If the expiration's\n\u003e highest bit is `0`, it is 1-byte long, and the bits following the\n\u003e highest `0` encode a number of years. If the first `0` bit is in the\n\u003e second highest position, then it is 2-bytes long and the bits following\n\u003e the highest 0 encode a number of weeks. \u0026c.\n\u003e \n\u003e\u003e 2) Your suggestion would result in a protocol that degrades over time, as the\n\u003e\u003e granularity of *newly* created addresses goes up. This isn't like CTV/CLTV,\n\u003e\u003e where we're creating something now with a limit in the future. 100 years from\n\u003e\u003e now - if silent payments still exists - people will still want to create silent\n\u003e\u003e payment addresses that expire, say, 30 days in the future. Your suggestion does\n\u003e\u003e not allow that.\n\u003e \n\u003e My suggestion does degrade over time in one sense: if it is still in use\n\u003e 128 years in the future, users are required to start using at least 2\n\u003e bytes to encode their expiration instead of 1, even if they only need\n\u003e year granularity. After 315 years they have to start using at least 3\n\u003e bytes even if they only need week granularity.\n\u003e \n\u003e I'd rather enable users to encode their expirations in 1 or 2 bytes\n\u003e today and degrade by requiring more bytes than require 3 bytes now.\n\u003e \n\u003e Best,\n\u003e \n\u003e --Brandon\n\u003e \n\u003e \n\u003e ------------------------------\n\u003e \n\u003e Message: 3\n\u003e Date: Sun, 06 Aug 2023 14:20:06 +0000\n\u003e From: josibake \u003cjosibake at protonmail.com\u003e\n\u003e To: Peter Todd \u003cpete at petertodd.org\u003e\n\u003e Cc: bitcoin-dev at lists.linuxfoundation.org\n\u003e Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should\n\u003e have an expiration time\n\u003e Message-ID:\n\u003e \u003cXypmhu6s58gWgRNoFzBDhbtvcEt8DomdJcLe1RIbesEKOx1MO5TBHTLDENqedTbN9DPZT5MNSpA-xMiiSDDb-hVnx-YgIAqCtrGHoCrqxsE=@protonmail.com\u003e\n\u003e \n\u003e Content-Type: text/plain; charset=\"utf-8\"\n\u003e \n\u003e Hi Peter,\n\u003e \n\u003e 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.\n\u003e \n\u003e 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:\n\u003e \n\u003e 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.\n\u003e 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.\n\u003e 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.\n\u003e 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.\n\u003e 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.\n\u003e 6. By updating his address, Bob is leaking metadata about himself, potentially compromising his safety.\n\u003e \n\u003e 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.\n\u003e \n\u003e 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).\n\u003e \n\u003e 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.\n\u003e \n\u003e Cheers,\n\u003e Josie\n\u003e \n\u003e \n\u003e Sent with Proton Mail secure email.\n\u003e \n\u003e ------- Original Message -------\n\u003e On Friday, August 4th, 2023 at 7:39 PM, Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e \n\u003e\u003e tl;dr: Wallets don't last forever. They are often compromised or lost. When\n\u003e\u003e this happens, the addresses generated from those wallets become a form of toxic\n\u003e\u003e data: funds sent to those addresses can be easily lost forever.\n\u003e\u003e \n\u003e \n\u003e\u003e All Bitcoin addresses have this problem. But at least existing Bitcoin\n\u003e\u003e addresses aren't supposed to be reused. Silent Payments are: the whole point is\n\u003e\u003e to have a single address that you can safely pay to multiple times, without\n\u003e\u003e privacy concerns. Failing to make Silent Payment addresses eventually expire in\n\u003e\u003e a reasonable amount of time is thus a particularly harmful mistake.\n\u003e\u003e \n\u003e \n\u003e\u003e Fixing this is easy: add a 3 byte field to silent payments addresses, encoding\n\u003e\u003e the expiration date in terms of days after some epoch. 2^24 days is 45,000\n\u003e\u003e years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180\n\u003e\u003e years. We'll be lucky if Bitcoin still exists in 180 years.\n\u003e\u003e \n\u003e \n\u003e\u003e Wallets should pick a reasonable default, eg 1 year, for newly created\n\u003e\u003e addresses. Attempts to pay an expired address should just fail with a simple\n\u003e\u003e \"address expired\". Lightning invoices are a good example here: while invoices\n\u003e\u003e does not require expiration from a technical point of view, they do expire for\n\u003e\u003e similar UX reasons as applies to silent payments.\n\u003e\u003e \n\u003e \n\u003e\u003e --\n\u003e\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e -------------- next part --------------\n\u003e A non-text attachment was scrubbed...\n\u003e Name: publickey - josibake at protonmail.com - 0x616516B8.asc\n\u003e Type: application/pgp-keys\n\u003e Size: 3154 bytes\n\u003e Desc: not available\n\u003e URL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230806/edd207c8/attachment.bin\u003e\n\u003e -------------- next part --------------\n\u003e A non-text attachment was scrubbed...\n\u003e Name: signature.asc\n\u003e Type: application/pgp-signature\n\u003e Size: 855 bytes\n\u003e Desc: OpenPGP digital signature\n\u003e URL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230806/edd207c8/attachment.sig\u003e\n\u003e \n\u003e ------------------------------\n\u003e \n\u003e Subject: Digest Footer\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e ------------------------------\n\u003e \n\u003e End of bitcoin-dev Digest, Vol 99, Issue 15\n\u003e *******************************************",
"sig": "b9756b02494c67a2c7b93e11405237b3f865457e44c1abf1853208e8c7d0fd8c36f612e6458850392c7cb26632a8d54718ac0d8464129d05d83e947fc61fed04"
}