📅 Original date posted:2023-08-06
🗒️ Summary of this message: The author acknowledges the feedback on expiration dates in Bitcoin but expresses skepticism about their effectiveness and potential drawbacks. They highlight scenarios where expiration dates may cause issues and suggest exploring a wallet protocol instead. They also mention privacy concerns and the need for enforceability by consensus. Overall, expiration dates are seen as a separate problem from the scope of BIP352.
📝 Original message:
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-0001.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-0001.sig>;
josibake [ARCHIVE] /
npub1lc…3p9xr
2023-08-06 23:37:35
in reply to nevent1q…lwua
Author Public Key
npub1lc8fsuj6ffha9xjpq7l9cfn0ylhfw6jm4gyjfudpvet7yvxpv5gq83p9xrPublished at
2023-08-06 23:37:35Event JSON
{
"id": "2f47dee4478ca9beb514cdee62eab5bad310ffc49e3590e4f698a03177a039cb",
"pubkey": "fe0e98725a4a6fd29a4107be5c266f27ee976a5baa0924f1a16657e230c16510",
"created_at": 1691365055,
"kind": 1,
"tags": [
[
"e",
"c08d8bfe5e8ab2894e9fbdb020ab2bbb281ca98857e700a8e90822dc365f2c84",
"",
"root"
],
[
"e",
"f73274ac3cd946c8e071c91bd5c171759539c1335c02ba9bedd4056b8d5ca11d",
"",
"reply"
],
[
"p",
"59909c5ada0189425f58f43a87eeb09131d41d33298de94a994852fa43c25afd"
]
],
"content": "📅 Original date posted:2023-08-06\n🗒️ Summary of this message: The author acknowledges the feedback on expiration dates in Bitcoin but expresses skepticism about their effectiveness and potential drawbacks. They highlight scenarios where expiration dates may cause issues and suggest exploring a wallet protocol instead. They also mention privacy concerns and the need for enforceability by consensus. Overall, expiration dates are seen as a separate problem from the scope of BIP352.\n📝 Original message:\nHi Peter,\n\nThanks 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\nThat 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\n1. 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.\n2. 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.\n3. 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.\n4. 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.\n5. 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.\n6. By updating his address, Bob is leaking metadata about himself, potentially compromising his safety.\n\nYou 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\nLastly, 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\nIn 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\nCheers,\nJosie\n\n\nSent with Proton Mail secure email.\n\n------- Original Message -------\nOn Friday, August 4th, 2023 at 7:39 PM, Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\n\u003e tl;dr: Wallets don't last forever. They are often compromised or lost. When\n\u003e this happens, the addresses generated from those wallets become a form of toxic\n\u003e data: funds sent to those addresses can be easily lost forever.\n\u003e \n\n\u003e All Bitcoin addresses have this problem. But at least existing Bitcoin\n\u003e addresses aren't supposed to be reused. Silent Payments are: the whole point is\n\u003e to have a single address that you can safely pay to multiple times, without\n\u003e privacy concerns. Failing to make Silent Payment addresses eventually expire in\n\u003e a reasonable amount of time is thus a particularly harmful mistake.\n\u003e \n\n\u003e Fixing this is easy: add a 3 byte field to silent payments addresses, encoding\n\u003e the expiration date in terms of days after some epoch. 2^24 days is 45,000\n\u003e years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180\n\u003e years. We'll be lucky if Bitcoin still exists in 180 years.\n\u003e \n\n\u003e Wallets should pick a reasonable default, eg 1 year, for newly created\n\u003e addresses. Attempts to pay an expired address should just fail with a simple\n\u003e \"address expired\". Lightning invoices are a good example here: while invoices\n\u003e does not require expiration from a technical point of view, they do expire for\n\u003e similar UX reasons as applies to silent payments.\n\u003e \n\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\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-------------- next part --------------\nA non-text attachment was scrubbed...\nName: publickey - josibake at protonmail.com - 0x616516B8.asc\nType: application/pgp-keys\nSize: 3154 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230806/edd207c8/attachment-0001.bin\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 855 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230806/edd207c8/attachment-0001.sig\u003e",
"sig": "d429ae627aed8c5807deea2c84afc615bf5cb01b27e1cee6f8a94243bb544b11e8d5b8e374b78e510135b2c59151b27c5554f117ef78b619bb573d8df99c31ff"
}